On Mon, 28 Nov 2005, Cyrus Harmon wrote:
> The following patch contains my sbcl-interpretation of rtoym's recent
> callback changes to CMUCL.
> 2. We had problems with callbacks given arguments shorter than int. We were
> putting the args in the wrong end of the int. This is fixed. CFFI tests for
> short, ushort, char, uchar showed the problem and are now fixed.
> 3. We weren't incrementing the offset for multi-word args so 64-bit args were
> hosed. This is now fixed. CFFI long-long and u-long-long tests showed the
> problem and are now fixed.
Do you have tests for (2) and (3)?
> If the ppc-callback committee could look this over, I'd appreciate it.
;-) You're on it.
Re: your questions on the sbcl-internals:
* API status:
I don't think the API is going to change significantly. While I have made
notes and have a decent idea what a future-proof (vrt. extensibility) API
would look like it is hopelessly incompatible with the rest of SB-ALIEN.
Hence _my_ current plan --which I've been hoping to get around to
implementing "any day now" for a month or more-- is to clean up what we
have, export it, and call it a day. ...but as usual the person doing the
work calls most of the shots: so if my situation persists someone else may
have different ideas.
In a more distant future I see SB-FOREIGN as the way to go, implementing a
more extensible API: Win32 port is going to need this, I think, given the
various calling conventions. By SB-FOREIGN I don't mean rewriting all of
SB-ALIEN, but building a new layer on top of it, and then slowly migrating
the guts to the new package too while keeping SB-ALIEN as the
compatibility layer for old code.
* SBCL-CALLABLES in CVS:
I think it can be safely killed, yes. I'm less sure of what it takes to
do that (delete a CVS module on SF).
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."