Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
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).