<luismbo@...> wrote:
> We're not even testing if the callback moves or not. Our libtest is
> not saving the callbacks' address.
>
> Here's the a testcase, using sb-alien (sort of):
Thanks. The problem is that the callback support assumes that
#'SB-VM::ENTER-ALIEN-CALLBACK can never move [*]. Which is no
longer true on x86 and x86-64 as of a few releases ago, since
everything is in the dynamic space by default, and will get
relocated when the core is saved [**].
A workaround is to run PURIFY once before creating any callbacks. The
proper solution would be adding a level of indirection into the
generated callback wrappers. Maybe make 'SB-VM::ENTER-ALIEN-CALLBACK a
static symbol, so that it will be guaranteed to not move, and then
emit instructions to peek into its symbol-function slot.
[*] The callback wrapper generator generates an assembly instruction with
a hardcoded address:
(inst push (get-lisp-obj-address #'enter-alien-callback)) ; function
[**] #'SB-VM::ENTER-ALIEN-CALLBACK will be in a non-collected
generation in the dynamic space, so luckily it can't move
during normal execution.
--
Juho Snellman

I'm Cc-ing cffi-devel and sbcl-devel, since I'm sure more people will =20=
be interested in this and hopefully others will help in figuring this =20=
out.
On 2005-dec-31, at 13:59, Thomas F. Burdick wrote:
> I noticed in the #lisp logs that you're having problems preserving
> callbacks across image saves. SBCL already goes to quite a bit of
> effort to make sure this works. =46rom C's point of view, the =
callbacks
> will never move. But because your library is in lisp, and persists
> across image saves, from its point of view, callback objects can move
> at arbitrary times. Instead of storing SAPs, you should store the
> alien-value object that alien-lambda returns. If you actually need
> the SAP, get it only when you need it, using alien-sap.
We're not even testing if the callback moves or not. Our libtest is =20
not saving the callbacks' address.
Here's the a testcase, using sb-alien (sort of):
luis@...:/tmp$ cat sbcl-callback.lisp
(use-package :sb-alien)
(define-alien-routine "qsort" void
(base system-area-pointer)
(nmemb int)
(size int)
(compar system-area-pointer))
(defparameter *callback*
(sb-alien::alien-lambda int
((a system-area-pointer) (b system-area-pointer))
(let ((x (sb-sys:signed-sap-ref-32 a 0))
(y (sb-sys:signed-sap-ref-32 b 0)))
(cond ((> x y) 1)
((< x y) -1)
(t 0)))))
(defun test ()
(let ((array (alien-sap (make-alien (unsigned 32) 10))))
(dotimes (i 10)
(setf (sb-sys:signed-sap-ref-32 array (* i 4))
(nth i '(7 2 8 9 6 1 10 3 5 4))))
(qsort array 10 4 (alien-sap *callback*))
(dotimes (i 10)
(format t "~A " (sb-sys:signed-sap-ref-32 array (* i 4))))
(free-alien (sap-alien array (* (unsigned 32))))))
luis@...:/tmp$ sbcl --sysinit /dev/null --userinit /dev/null
This is SBCL 0.9.8.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/&gt;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (load "sbcl-callback.lisp")
T
* (test)
1 2 3 4 5 6 7 8 9 10
NIL
* (sb-ext:save-lisp-and-die "test.core")
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /tmp/test.core:
writing 1584 bytes from the read-only space at 0x01000000
writing 1368 bytes from the static space at 0x05000000
writing 22609920 bytes from the dynamic space at 0x09000000
done]
luis@...:/tmp$ sbcl --core test.core
This is SBCL 0.9.8.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/&gt;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (test)
debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR: memory fault
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-KERNEL::MEMORY-FAULT-ERROR)
0]
Any pointers? Well, I'm off to party. Happy new year!
--=20
Lu=EDs Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=3Dpt

On Thu, 29 Dec 2005 16:48:10 +0000, Christophe Rhodes <csr21@...>
wrote:
>Hi,
>
>I've merged in the portable changes for the Win32 port already: that's
>a rather grand way of saying that I removed the <<EOF documents in the
>build scripts and replaced them with inputs from lisp files.
>
>I've put the remainder of the patch (heavily based, obviously, on
>Alastair's patch for sbcl-0.9.8) at
><http://www-jcsu.jesus.cam.ac.uk/~csr21/sbcl-win32-0.9.8.4-take1.patch.g=
z>.
At the moment, your server is not responding.
>This is what I would like to call "merge candidate 1": it looks
>plausible, it's not too horrible, and I hope it does what it says on
>the tin. Essentially the only real worry I have is that no-one other
>than Alastair has yet reported a successful build; hopefully that will
>change in the not-too-distant future.
>
>Interested parties should please read the patch, send comments, try to
>build it and report success or failure.
>
>Cheers,
>
>Christophe
>
I'll try to test it out on NT4 on monday. A *very* isolated NT4 box is
the newest and only MS-Windows system I have left. If there are not a
lot of testers, I wouldn't mind tossing together a XP machine for just
testing. If it's needed, let me know.
JCR

Travis Cross wrote:
>
>>i.m.o. it would be better to change with-timeout to use FLET so as
>>not to duplicate the body.
>
>
> Even if the body is not duplicated in the expansion, the deleted call to
> the flet bound function would be noted by SBCL. This note, since it
> would refer to code not in the original source, would be even less clear.
I haven't tried it just now, but I recall doing this in the past in
similar cases for this reason. Because the call to the FLET function is
not in the original source, there should be no note. The code may be
different in sbcl, but in cmucl we only give a note for a list form if
that form is "original source", which means that it is EQ to part of the
form originally returned by the reader.
But the note we're getting doesn't make any sense either. It seems like
the source path is getting messed up somehow.
This is the CMUCL code:
(defun note-block-deletion (block)
(let ((home (block-home-lambda block)))
(unless (eq (functional-kind home) :deleted)
(do-nodes (node cont block)
(let* ((path (node-source-path node))
(first (first path)))
(when (or (eq first 'original-source-start)
(and (atom first)
... atom hueristics ..))
(unless (return-p node)
(let ((*compiler-error-context* node))
(compiler-note "Deleting unreachable code.")))
(return))))))
(undefined-value))
When this approach fails is mainly with macros like duplicate code, as
though one copy may be deleted, it does not reach the certain futility
required to justify a note. Due to the hueristics for atoms it can also
cause spurious warnings for things such as references to local variables
that happen to have the same name as an argument variable.
Changing the macro semantics to avoid the need for dulication would also
work.
Rob

Travis Cross <travis@...> writes:
> (handler-case (princ "foobar")
> (error (e) e))
>
> which produces:
>
> ; in: LAMBDA NIL
> ; (SB-KERNEL:FLOAT-WAIT)
> ;
> ; note: deleting unreachable code
> ;
> ; compilation unit finished
> ; printed 1 note
> foobar
> "foobar"
Last time I tried looking at this (October 2003, in case people want
to search the mail archives) I failed to make headway.
The FLOAT-WAIT is needed in order to ensure precise floating point
exception reporting. (It might be necessary on the x86-64, I don't
know). On the x86 architecture, a floating point exception is
reported by the CPU on the /next/ floating point instruction, not the
one causing the exception; so the float-wait is necessary to ensure
that any floating point exceptions that are going to be signalled have
been signalled.
As for why it's showing a deletion note, I'm at least slightly
baffled, because you will find that if you redefine handler-case at
the repl (unchanged; you might need to load src/cold/chill.lisp first)
the code deletion messages go away.
The last thing I remember trying was copying the macro expansion tree,
on the assumption that it might be an artifact of constant sharing
between handler-case's and handler-bind's macroexpander code confusing
the compiler note heuristics. According to
<http://www.caddr.com/macho/archives/sbcl-devel/2003-10/2660.html&gt;,
this didn't help.
Cheers,
Christophe

Rob MacLachlan wrote:
> This test is somewhat hueristic, but the idea is that insofar as
> possible, dead code introduced by macros should not cause a note.
That is good to know. I was unaware that there was any magic that goes
on here. As a rule, I treat the note as constructive, even with code
generated by macros. Usually, if a macro is causing code to be deleted
in my application, the macro could be written in a better fashion.
> If SB-KERNEL:FLOAT-WAIT doesn't appear explicitly in the source code
> being compiled, then there shouldn't be an unreachable code note, at
> least not for that particular source location.
This does seem to violate the principle of least surprise to the
developer. The simplest case of this at work is the code (on x86):
(handler-case (princ "foobar")
(error (e) e))
which produces:
; in: LAMBDA NIL
; (SB-KERNEL:FLOAT-WAIT)
;
; note: deleting unreachable code
;
; compilation unit finished
; printed 1 note
foobar
"foobar"
This is not a result of the with-timeout code. The expansion of
handler-bind creates a call to sb-kernel:float-wait that occurs _after_
an unconditional call to return-from (generated by handler-case). This
creates hopelessly stranded code.
Both handler-case and handler-bind add a #!+x86 (float-wait) to be
evaluated after the body forms. In the case of handler-bind, this
(float-wait) occurs after the non-local exit made after the form passed
to handler-case is evaluated.
To clarify, the full expansion of the above is:
(block #:g1040
(let ((#:g1041 nil))
(declare (ignorable #:g1041))
(tagbody
(let ((sb-kernel:*handler-clusters*
(cons
(list
(cons 'error
(lambda (sb-impl::temp)
(setq #:g1041 sb-impl::temp)
(go #:g1042))))
sb-kernel:*handler-clusters*)))
(multiple-value-prog1
(progn
(return-from #:g1040
(multiple-value-prog1 (princ "foobar")
(sb-kernel:float-wait))))
(sb-kernel:float-wait))) ;;; <<--- *deleted* *code*
#:g1042
(return-from #:g1040
(let ((e #:g1041))
e)))))
The last float-wait is the one that is nailing us. I would be greatly
interested if someone here would explain what exactly float-wait does
and why it is necessary in certain code locations for x86 (and not x86_64?).
> In this case, the macro with-timeout is definitely going to cause
> dead code notes, but the top-level source context of the note should
> be something that explicitly appears in the orginal source.
I certainly agree.
I could imagine these notes being immensely confusing and discomforting
to someone new to SBCL. I believe both issues raised here should be
resolved.
> i.m.o. it would be better to change with-timeout to use FLET so as
> not to duplicate the body.
Even if the body is not duplicated in the expansion, the deleted call to
the flet bound function would be noted by SBCL. This note, since it
would refer to code not in the original source, would be even less clear.
In my opinion, with-timeout should simply timeout immediately if passed
a non-positive value for `expires`. If I have code that has the
possibility of passing 0 or -1 to with-timeout, I would be expecting it
to signal a sb-ext:timeout condition. A simple patch to achieve this is
attached.
In fact, allowing code to rely on this artifact (passing 0 or negative
numbers to with-timeout to prevent timeout checking) just feels dirty ;)
As far as handler-case / handler-bind goes, I would like to better
understand (sb-kernel:float-wait) before proposing a patch.
Cheers,
-- Travis

If SB-KERNEL:FLOAT-WAIT doesn't appear explicitly in the source code
being compiled, then there shouldn't be an unreachable code note, at
least not for that particular source location. This test is somewhat
hueristic, but the idea is that insofar as possible, dead code
introduced by macros should not cause a note.
In this case, the macro with-timeout is definitely going to cause dead
code notes, but the top-level source context of the note should be
something that explicitly appears in the orginal source.
i.m.o. it would be better to change with-timeout to use FLET so as not
to duplicate the body.
Rob

Patch for review.
* rename MAKE-SYMBOL to %MAKE-SYMBOL
* add MAKE-SYMBOL that calls %MAKE-SYMBOL and copies the string if it is=20
not simple
* add DEFTRANSFORM on MAKE-SYMBOL with SIMPLE-STRING argument
=2D Is there a better place for the DEFTRANSFORM?
G=E1bor

Dimitry Gashinsky wrote:
> ; in: LAMBDA NIL
> ; (SB-KERNEL:FLOAT-WAIT)
> ;
> ; note: deleting unreachable code
I'm not familiar with 'sb-aclrepl, but my guess is that this has to do with
the CLX hack in the sb-ext:with-timeout code.
(sb-ext:with-timeout 5
(princ "foo))
expands into (timer.lisp):
(IF (> 5 0)
(LET ((#:TIMER975 (MAKE-TIMER (LAMBDA () (CERROR "Continue" 'TIMEOUT)))))
(SCHEDULE-TIMER #:TIMER975 5)
(UNWIND-PROTECT (PROGN (PRINC "foo")) (UNSCHEDULE-TIMER #:TIMER975)))
(PROGN (PRINC "foo")))
which clearly does in fact delete code. This issue seems to generate a lot of
messages about deleting sb-kernel:float-wait when sb-ext:with-timeout is
combined with handler-bind and related macros. The reason that the message
only shows up on x86 platforms is the handler-bind macro includes a special case
for x86 (defboot.lisp):
;; Wait for any float exceptions.
#!+x86 (float-wait))))
I am not familiar with why this particular hack for CLX was needed, and it
does seem to generate a substantial amount of needless notes and messages.
Without fixing this bug, this noise can be muffled by wrapping any calls to
sb-ext:with-timeout with:
(locally (declare (sb-ext:muffle-conditions sb-ext:code-deletion-note)) ...)
This is, of course, an ugly hack in and of itself.
Cheers,
-- Travis

"Tobias C. Rittweiler" <tcr@...> writes:
> [3] Neither SBCL nor CMUCL seem to be able to recognize that
>
> (READ-FROM-STRING <CONSTANT>)
>
> is a constant expression which can me reduced on compile
> time.
That's probably because it isn't, for several reasons.
Firstly, anything that's preceded by the read-eval #. macro must be
evaulated at run-time, not compile-time.
Secondly, the bindings for the readtable, *read-eval*, *package*, and
the like, must be those prevailing at run-time, not compile-time.
Thirdly, interning is a side effect, and should not happen at
compile-time; if a token with an explicit package qualifier is inside
the string constant, the package need not exist at compile time.
As against the difficulty of solving these problems, say by optimistic
evaluation guarded by assertions, one must measure the likely benefits
for real code, which are approximately zero, unless I miss my guess.
Cheers,
Christophe

Hi SBCL hackers, CMUCL hackers [and hi Paul]
this mail will be about how conformingly the two implementations SBCL
and CMUCL have implemented the various CASE and TYPECASE forms, or in
general how they behave confronted with relatively braindamaged
applications of those forms. That's why I'm writing to the mailing lists
of both projects. (And, Paul, I'm writing to you, too, because you may
want to check whether that's something for your ANSI compliance test
suite.)
So let's have the cases down.. and let's see what CLHS dictates about the
allowed keys in any of the CASE, CCASE or ECASE forms:
``keys---a designator for a list of objects. In the case of case, the
symbols t and otherwise may not be used as the keys designator. To
refer to these symbols by themselves as keys, the designators (t)
and (otherwise), respectively, must be used instead.'' [1]
As a consequence, something like the following is prohibited:
(case (read-from-string "otherwise") ;; See [3] (off topic remark)
(foo 'FOO)
(otherwise 'FAKE-OTHERWISE)
(bar 'BAR)
(otherwise 'OTHERWISE))
Comparing SBCL, CMUCL and CLISP with respect to their behaviour, results
in the following table:
| SBCL | CMUCL | CLISP
------+------+-------+-------
case | PASS | ERR | ERR
| | |
ecase | PASS | WARN | WARN
| | |
ccase | PASS | WARN | WARN
PASS means that just 'FAKE-OTHERWISE is returned.
An error might look like this exemplary one:
CMUCL> (case (read-from-string "otherwise")
(foo 'FOO)
(otherwise 'FAKE-OTHERWISE)
(bar 'BAR)
(otherwise 'OTHERWISE))
#<SIMPLE-ERROR {58B34305}>
Error in function LISP::CASE-BODY:
T and OTHERWISE may not be used as key designators for CASE
A warning might look like this one:
CLISP> (ecase (read-from-string "otherwise")
(foo 'FOO)
(otherwise 'FAKE-OTHERWISE)
(bar 'BAR)
((otherwise) 'OTHERWISE))
WARNING: OTHERWISE used as a key in (OTHERWISE 'FAKE-OTHERWISE), it
would be better to use parentheses.
FAKE-OTHERWISE
(Notice how the last clause (being slightly different) is not being
complained about.)
First conclusion: SBCL has to be somewhat tweaked to obtain
conformance. I'd have done that myself actually, but I wasn't as sure
about the next issue, ie. about TYPECASE &c [2]:
What's a reasonable behaviour for the case when someone attempts to
pursue an unreasonable intention like the following:
;; for CMUCL: (without-package-locks
;; (CMUCL people, please see [4])
;;
;; for CLISP: (without-package-lock ("COMMON-LISP")
;;
(sb-ext:without-package-locks
(deftype otherwise () `(or symbol list))
(typecase (svref (make-array 1 :element-type 'otherwise
:initial-element 'bar) 0)
(otherwise 'BANG!)
(symbol 'SYMBOL)
(list 'LIST)
(otherwise 'OTHERWISE)))
Trying again in the three beforementioned implementation, results this
time in this table:
| SBCL | CMUCL | CLISP
------+------+-------+-------
typecase | PASS | BUG | PASS
| | |
etypecase | PASS | WARN | WARN
| | |
ctypecase | PASS | WARN | WARN
PASS means that 'BANG! is returned.
A warning might look like this one:
CLISP> (without-package-lock ("COMMON-LISP")
(deftype otherwise () `(or symbol list))
(ctypecase (svref (make-array 1 :element-type 'otherwise :initial-element 'bar) 0)
(otherwise 'BANG!)
(symbol 'symbol)
(list 'list)
(otherwise 'otherwise)))
WARNING: OTHERWISE used as a key in (OTHERWISE 'BANG!), it
would be better to use parentheses.
WARNING: OTHERWISE used as a key in (OTHERWISE 'OTHERWISE), it
would be better to use parentheses.
BANG!
(This seems to be the same warning as emitted by CCASE or ECASE
above. It's true here as well, though, because a type specifier may be a
list.)
BUG stands for a rather quirky behaviour as CMUCL just skips over the
first clause (OTHERWISE 'BANG!) and produces the following macro
expansion:
(LET ((#:G1762
(SVREF (MAKE-ARRAY 1 :ELEMENT-TYPE 'OTHERWISE :INITIAL-ELEMENT 'BAR) 0)))
#:G1762
(COND ((TYPEP #:G1762 'SYMBOL) NIL 'SYMBOL)
((TYPEP #:G1762 'LIST) NIL 'LIST)
(T NIL 'OTHERWISE)))
That results in return 'SYMBOL, obviously. Judging from the source code
[5], I'd bet that that's simply a bug.
Now, the question is what behaviour is the best? I think, it's
justifiable to rise a style-warning in any case which states that if
it's really what you want that you're doing, you should put parentheses
around the TYPE (or KEY for that matter.)
What's your opinion?
-- tcr
[1] http://www.lispworks.com/documentation/HyperSpec/Body/m_case_.htm
[2] http://www.lispworks.com/documentation/HyperSpec/Body/m_tpcase.htm
[3] Neither SBCL nor CMUCL seem to be able to recognize that
(READ-FROM-STRING <CONSTANT>)
is a constant expression which can me reduced on compile
time. I.e. while in (CASE 'FOO (FOO 'FOO) (BAR 'BAR)) the
unreachable code segment (BAR 'BAR) is seen and deleted,
no such hint is given for (CASE (READ-FROM-STRING "FOO") ...)
[4] CMUCL people: Unfortunately,
(without-package-locks
(deftype otherwise () `(or symbol list))
(typecase (svref (make-array 1 :element-type 'otherwise
:initial-element 'bar) 0)
(otherwise 'BANG!)
(symbol 'SYMBOL)
(list 'LIST)
(otherwise 'OTHERWISE)))
didn't work for me when passing that into the REPL (i.e. a condition
was thrown); I had to manually SETF LISP::*ENABLE-PACKAGE-LOCKED-ERRORS*
to NIL. I'm on CMUCL 19a. Did I do something wrong?
[5] CMUCL people: Are you aware that the argument ERRORP to CASE-BODY is
pretty much unused and seems to be superseded by ALLOW-OTHERWISE?

Hi all,
I have a simple annoyance which I am trying to get rid off. When I
start sbcl on x86 I get:
[12:31:07]$ sbcl
This is SBCL 0.9.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/&gt;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
; in: LAMBDA NIL
; (SB-KERNEL:FLOAT-WAIT)
;
; note: deleting unreachable code
;
; compilation unit finished
; printed 1 note
Which is caused by this in my .sbclrc:
CL-USER(1): (ignore-errors (require 'sb-aclrepl))
; in: LAMBDA NIL
; (SB-KERNEL:FLOAT-WAIT)
;
; note: deleting unreachable code
;
; compilation unit finished
; printed 1 note
NIL
CL-USER(2):
It does not happen on x86_64.
Can I get rid off this note with some declare?
Regards,
DiG
--
((lambda (lambda) `(,lambda ',lambda)) '(lambda (lambda) `(,lambda ',lambda)))

On 29. Dez 2005, at 17:48, Christophe Rhodes wrote:
> Essentially the only real worry I have is that no-one other
> than Alastair has yet reported a successful build; hopefully that will
> change in the not-too-distant future.
FWIW, my self-build-on-windows experiments progressed to a cold-
sbcl.core that passes the (* 2 3) test but hangs when reading from
files, so make-target-2 didn't happen. I used cygwin; the only
stumbling block was that -mno-cygwin had to be added to OS_LIBS in
Config.x86-win32 as well as to CFLAGS.
I'll try a cross-build from Linux (following Alastair's recipe) next
so I can start with a win32 version with working ensure-directories-
exist; this should speed up the build process somewhat :)
Regards,
Rudi

Gábor Melis wrote:
> Modifying print.lisp to work with strings instead of simple-strings
> slowed FPRINT-PRETTY and FPRINT-UGLY 70% and 20% so I suggest we live
> with our ANSI given right to copy the string:
Yes, no sense optimizing the weird case.
Paul

Juho Snellman <jsnell@...> writes:
> * Make the default *MAX-SAMPLES* smaller, for example enough to cover
> * It's possible to print a progress message on each iteration
> * Add a new :LOOP keyword parameter to the macro, which can be
> I'm currently leaning towards making all of the above changes, but
> wouldn't mind a second opinion on this.
I'd prefer the last two, but am fine with all three.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

There's been some grumbling on #lisp about the SB-SPROF:WITH-PROFILING
macro. Specifically, it'll loop the body form until it has collected
SB-SPROF:*MAX-SAMPLES* samples (which can be overridden with
:MAX-SAMPLES). Since the default value of *MAX-SAMPLES* is rather
large, this'll give the impression of SB-SPROF freezing completely.
Furthermore for some profiling tasks iterating the body multiple times
is inappropriate.
Some remedies that come to mind:
* Make the default *MAX-SAMPLES* smaller, for example enough to cover
30 seconds of profiling. (But this will make using the interface
through START-PROFILING / STOP-PROFILING more tedious, since the
sample buffer will no longer be large enough for any feasible
profiling run)
* It's possible to print a progress message on each iteration
of the WITH-PROFILING with the :SHOW-PROGRESS keyword parameter,
which currently defaults to NIL. Changing the default to T
would make it obvious
* Add a new :LOOP keyword parameter to the macro, which can be
either T (loop until the sample count is exceeded), an integer
(loop N times) or NIL (just one iteration). The default would be
T for backwards compability.
I'm currently leaning towards making all of the above changes, but
wouldn't mind a second opinion on this.
--
Juho Snellman

Cyrus Harmon <ch-sbcl@...> writes:
> In any event, the current behavior seems more correct and makes ppc
> happy. I'm not sure what THS is seeing on MIPS that makes this not
> work, but I'm curious know what we can do to fix it.
Shouldn't these things be defined as vm-support-routines, just like
the various helper functions for calling out into C? Then they can be
defined per-backend (and with the help of a little #!+/#!-, per
OS/ABI.
Cheers,
Christophe

Thiemo Seufer suggested that this might break callbacks on platforms
that can cope with unaligned doubles. I thought I would move the
discussion from #lisp to sbcl-devel since I'm on the road and my
#lisp access is rather sporadic and so folks in different time zones
can weigh in.
So the initial algorithm was:
1. offset <- 0
2. get value of current arg of at offset
3. increment offset by the size of the _next_ arg, not the current arg
so if we had a double followed by an int we would get values at
offset 0 (correct) and 4 (wrong, should be 8) and for an int followed
by a double we get values at 0 (correct) and 8 (wrong, should be 4).
I fixed this by bumping offset by the size of the current arg. THS
said "Are you sure you change doesn't mess up arches which can cope
with unaligned doubles?" I would think, if anything, it's the
opposite where if doubles have to be aligned the stack, this fix
would break them. if args of int, double are at 0,8 (with the double
aligned on an 8 byte boundary) this will not work. One place to fix
this would be in alien-callback-argument-bytes where we have a list
of types that we make sure we bump up to the next aligned size. We
don't do this for double, so the assumption is that doubles do not
have to be 8-byte aligned here. If that were to be the case, we would
need to add them somehow, so perhaps this has to be arch/os specific.
In any event, the current behavior seems more correct and makes ppc
happy. I'm not sure what THS is seeing on MIPS that makes this not
work, but I'm curious know what we can do to fix it.
Thanks,
Cyrus
On Dec 22, 2005, at 1:07 PM, Cyrus Harmon wrote:
>
> And here's the patch..
>
> I have only tested this in conjunction with the rest of my callback
> fixes, but it should work either way. I'd like to see the whole lot
> of them checked in, but even without the rest, this is probably the
> right thing to do.
>
> Cyrus
>
>
> Index: target-alieneval.lisp
> ===================================================================
> RCS file: /cvsroot/sbcl/sbcl/src/code/target-alieneval.lisp,v
> retrieving revision 1.37
> diff -u -r1.37 target-alieneval.lisp
> --- target-alieneval.lisp 15 Oct 2005 12:55:53 -0000 1.37
> +++ target-alieneval.lisp 22 Dec 2005 21:04:17 -0000
> @@ -799,12 +799,12 @@
> (sb!kernel:get-lisp-obj-address result-
> pointer))))
> (with-alien
> ,(loop
> + with offset = 0
> for spec in argument-specs
> - for offset = 0 ; FIXME: Should this not be AND
> OFFSET ...?
> - then (+ offset (alien-callback-argument-bytes
> spec env))
> collect `(,(pop argument-names) ,spec
> :local ,(alien-callback-accessor-form
> - spec 'args-sap offset)))
> + spec 'args-sap offset))
> + do (incf offset (alien-callback-argument-bytes
> spec env)))
> ,(flet ((store (spec)
> (if spec
> `(setf (deref (sap-alien res-sap
> (* ,spec)))
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Hello!
What is the right way to automatically remove bogus handlers?
In my server I (ADD-FD-HANDLER <listening-socket> :input
(PERFORM-WORK)), followed by (ADD-FD-HANDLER <accepted-socket> :input
(PERFORM-WORK)) to leave slime REPL free. Everything is fine until
client quits and condition is signalled. Of course I can choose
REMOVE-THEM restart manually, but is it possible to do it automatically?
Where do I (HANDLER-BIND)? I beg your pardon, but I'm not very good with
condition system yet...
Thanks for your opinions. Merry Christmas and a Happy New Year!
Dmitri