lutz.euler@... (Lutz Euler) writes:
> Sorry for warming up this thread after two weeks. First, many thanks
> for fixing the bug! As you surely will have noticed, now the compiler
> emits a note (tested under sbcl-0.8.19.28 on x86-64):
Thanks for this. In the end I used a slightly different rewrite: from
(1- (ash 1 c))
to
(ash #xff...ff (- c n))
which I think has all the desired properties. The fix was merged in
sbcl-0.8.20.2.
Cheers,
Christophe

Currently code entered at the REPL is evaluated in a special "interactive"
environment with a separate hardcoded policy:
(safety 3) (debug 2) (compilation-speed 2) ... rest at 1
Inconsistently, the debugger command loop uses the global policy.
Additionally, it is not currently possible to affect global policy in
any other way except by PROCLAIM/DECLAIM in the REPL as both COMPILE-FILE
and LOAD bind SB-C::*POLICY*.
I propose the following:
* Remove the separate interactive policy, as it only serves to confuse.
* Process initialization files with READ & EVAL, not LOAD, so that
global policies, startup package, etc. can be modified by them.
* Remove binding for SB-C::*POLICY* from LOAD. However, since this means
that third-party code can eg. globally set (SAFETY 0), make top level
OPTIMIZE declarations signal style-warnings under LOAD, and add information
about changed policy to :VERBOSE output from LOAD.
Thereafter current file-local effect could be achived with
(eval-when (:compile-toplevel) (proclaim ...))
The two first changes are essentially orthogonal from the third, but not
from each other, as AFAIK one of the reasons for the interactive
environment magic is the inability to change global policy from
initialization files.
The second change is IMO required even in the presense of the third, since
it makes little sense to bind anything around the initialization file
processing.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

Hello,
Nikodemus suggested I run some questions / suggestions by sbcl-devel
regarding the callbacks "patch". In particular one thing I'd like to
see improved before it can be "merged" is the API. Right now the API
looks like:
* define-alien-function to define a new callback
* alien-function is the type specifier, I think
* alien-function-sap returns the SAP pointing to the callback
* alien-function-alien is the alien object for the callback, I think
* alien-lambda is a lambda which creates a callback and returns its SAP
* with-alien-functions creates callbacks within its dynamic contour
* remove-alien-function deletes a callback, I think
* alien-function-incompatible-redefinition is signaled when attempting
to incompatibly redefine an alien
* alien-function-incompatible-redefinition.{name, old-type, new-type}
are accessors for that condition object
These names really do not fit into the established SBCL naming style.
My own personal preference as far as names goes (which I think SBCL
upholds) is to have the right words in the right order to describe what
the function does. define-alien-function is an awful name as far as
that's concerned. We already have define-alien-routine which defines a
C function; define-alien-function is just similar enough to be
massively confusing.
My proposal is as follows:
* define-alien-callable-routine defines a callback
* alien-callable-routine is the name of the alien-callable routine
* alien-callable-routine-sap is the SAP pointing to the alien-callable
routine
* alien-callable-routine-alien is the alien object in question
* alien-callable-lambda is a lambda which is alien-callable
* with-alien-callable-routines binds alien-callable routines within its
dynamic contour
* remove-alien-callable-routine removes the alien-callable routine in
question
* alien-callable-routine-incompatible-redefinition is the condition
which is signaled when attempting to incompatibly redefine an alien
callable routine
* alien-callable-routine-incompatible-redefinition-{name, old-type,
new-type} are accessors for the condition slots
I think the words "alien-callable" are the right words in the right
order, as far as this goes. I'd also like to specify a few loose ends:
* alien-callable-lambda returns something of type
alien-callable-routine, which is what it already does, not a SAP as the
documentation string actually says. (Sigh: when the code and comments
disagree, they're usually both wrong.)
* remove-alien-callable-routine shouldn't return NIL if the
alien-callable-routine which is passed to it can't be removed. It
should signal an error of some type. Returning NIL here is just bad
form.
* I'm not sure we need a special condition with these condition slots
for redefinition. Do people think this is useful?
Moving beyond API design, the challenges (such as they are) for
integrating callbacks are:
* Cleaning it up; making the comments not lie and the functions conform
to the API that gets defined by hashing this out. In particular
grepping for FIXME in the current patch [*] is a good nonexhaustive way
of determining what might need fixing. But in my readover tonight, I've
come to the conclusion that basically every comment and documentation
string here should be looked upon with suspicion.
* Likely picking new file names for at least some of these files
* Moving it into host-2; changing definitions to use the bootstrap
macros; moving package things into package-data.lisp-expr and putting
the build order into build-order.lisp-expr
* Documenting it (this is important)
* There is a bug regarding short integers on the C stack on the
PowerPC; this definitely affects callbacks but likely also calling out.
But this is probably separate work for someone (me) to ponder over.
Also, Rick Taube has mentioned that (* t) arguments to callbacks aren't
working right on OS X. Neither of these is probably worth debugging
before most of the cleanup is done as this patch can at least be useful
to the x86 users.
I'm hoping this doesn't take more than a month :-)
[*] http://pinhead.music.uiuc.edu/~hkt/sbcl-af-2004-10-22.tgz
--
Brian Mastenbrook
bmastenb@...
http://cs.indiana.edu/~bmastenb/