From: Raymond W. <Ray...@fa...> - 2001-04-24 07:11:52
|
William Harold Newman writes: > On Mon, Apr 23, 2001 at 07:38:18PM +0200, Raymond Wiker wrote: [ snip ] > Try SB-EXT:POSIX-GETENV. It's not quite compatible with yours, > since e.g. it returns NIL instead of the empty string when there's > no match, but it might do the job. > > (I've used the POSIX prefixes because although I want to use the > universally used cryptic Unix abbreviations, I also want to avoid > conceptual collisions with Lisp concepts like lexical > environments.) SB-EXT:POSIX-GETENV does indeed look like it would do the job. It does actually have the same behaviour as my version: NIL is returned for a non-existing variable, and the empty string for an existing variable which is not set. > > I've also spent some time on porting the multiprocessing > > facility (Lisp threads) of CMUCL back to SBCL. It is now in a > > state where I can compile and load it and run some of the tests > > in mp-tests.lisp. If anybody else is interested in looking at it, > > I would be more than happy to share what I've got so far :-) > > That's pretty impressive. Hum. I may have overstated my success with the MP package somewhat :-) The current state of affairs is that it *some* of the tests appear to run correctly, while some of the others fail. Still, it's a beginning. > I'm not motivated to work on MP, since I'm plenty busy scratching > my itch for a Lisp which works for single-threaded stuff. However > (and given my previous writings about how things belong in > libraries and how I wouldn't work on multithreading and so forth, I > should probably clarify this!) I do think it's important, and as > far as I'm aware there's no reasonable way to put Lisp MP into a > standalone library, so if you or others want to work on it, it > could probably be done in the main branch, or before it's > completely stable, at least merged into the main branch > periodically. Before it's merged at all, I'd probably want the > multithreaded branch to be stable enough that it's at least > somewhat useful (though it sounds as though you may actually be > there already!). And I'd want anything anything expensive (like > locks on streams or symbol tables) or potentially flaky to be > conditionalized on SB-MP, so that it wouldn't impact > single-threading builds much. (I'd also be delighted if there could > be good regression tests for it, but one of the minor reasons that > I'm not so psyched about working on it is that there are so many MP > issues that are hard to test.) It seems that the MP functionality *can* be split off from the main SBCL code and put into a separate library. There are only something like 4 references to MP functionality in the rest of the code, and I guess that the surrounding code could be copied into the MP fileset (as a temporary measure, at least) and modified as necessary there. I'll post a little more details on this from my home machine. //Raymond. -- Raymond Wiker Ray...@fa... |