Instead of doing this for every new platform, could SBCL just target NSPR,
which has the benefit of being incredibly comprehensive and actively
supported and maintained? Is the MPL/GPL dual license of NSPR a problem fo=
If it COULD use NSPR (basically act like a C program with a runtime
assembler), SBCL would run on:
...and transparently offer...
I'm not well enough aware of how threading is currently implemented on Linu=
(why are kernel threads used instead of the pthreads interface, does SBCL
need the signals pthreads would use?), but it seems like adapting the guts
ONCE to an open-source portable runtime would solve many perennial issues
On 2/5/06, Christophe Rhodes <csr21@...> wrote:
> Jeremy Shute <shutej@...> writes:
> > Is there a laundry-list of what needs to be done to make SLIME work?
> > Right now SLIME can't get the user ID...
> Off the top of my head, briefly (since I have just returned from
> * sockets. At present sbcl on windows can't open sockets, and I'm
> pretty sure that slime depends on that.
> * fd-handlers. slime has three modes of communicating with sbcl-like
> lisps: :spawn, depending on threads; :sigio, depending on
> roughly-posix signals, and :fd-handler, depending on something a bit
> like select(). select() is apparently an absolute pain to implement
> on windows, because each of sockets, pipes and file handles behaves
> differently. Note that I am only repeating what I have heard; I
> know nothing about windows programming.
> * a few miscellaneous environmental bits and pieces, like some kind of
> notion of home directory, a temporary place for slime fasls, and the
> > Who's working on it, and how can I help? (I'm in the process of
> > getting SBCL to build on WIN32...)
> I think there are some people working on this kind of thing in their
> spare time, but with no real ETA. (I would hope that they are reading
> this list).