josh giesbrecht writes: 

> Larry Clapp wrote:
>> http://www.advogato.org/person/crhodes/diary.html?start=92 
>> 
>> "[...] if there are Lisp-interested Windows hackers out there, more
>> eyes and hands would be very welcome." 
>> 
>> The very definition of a Request for Gardener, if you ask me.  :) 
>> 
>> -- Larry
> 
> I talked to nyef on #lisp (who I think is the Alastair Bridgewater 
> spoken of in that diary entry, but someone correct me if I'm mis-mapping 
> IRC handles to reality), asking about this, and he said that he was 
> waiting until he had his Windows port code checked into SBCL's head.  He 
> was going to send a note to the list when he felt it was ready for the 
> extra attention.

Indeed. There are a couple of "easy" tasks on the TODO list, but the only 
one that can be worked on without being able to at least run the lisp side 
of the build is to test the contribs. For item 4a (lisp-side exception 
handling), you would need a build tree that has produced a cold-sbcl.core 
file, and you would spend your time making a change, "slamming" it, 
producing a new cold-sbcl.core, running make-target-2, and testing your 
change. 

Actually, thinking about it, you can redefine the functions in the warm 
core, so you'd probably be better off copying out handle-win32-exception 
into a separate file and loading it into a clean instance each time, then 
causing an exception in order to test it. Then, once the behavior is nailed 
down, put it back where it came from and do a full build to make sure it 
still works. 

You don't get the nice happy emacs+slime environmnent becuase sockets don't 
work (item 3 on TODO), and you can't work on sockets until FFI is minimally 
fixed (item 1 on TODO, which requires compiler hacking that I'm reading up 
on today). And even after all that, it might turn out to be really easy to 
crash SBCL or lock it up using slime... Although thinking about it, perhaps 
not when using serve-event dispatching (if that even works). 

I'll put "writing Linux-hosted build instructions" on my personal TODO list. 
And hopefully soon someone will figure out how to build entirely on Windows 
(it can't be that hard, can it?) 

> I don't think that TODO list is actually getting actively checked off 
> when things are completed.  That said, he did mention that at the time 
> (a few days ago), no one had done Easy step #2 yet, and that would be a 
> useful contribution.  I don't know if it's still undone or not, but if 
> it is then a newbie Gardener could probably contact him and contribute 
> in that way.  (I was interested, but I'm not going to have time to do 
> much until after New Year's.)

Oh, the TODO list is being kept up to date. It's just that the tasks 
multiply over time. Note that item 8 is actually marked as done. Item 4 used 
to just be a note that "signal" handling was probably not robust. Well, now 
the basic code to reflect exceptions into Lisp is in place, and there are 
five separate items for each of the remaining tasks in this area. Just 
getting that far took a few days. 

I'm working on stuff roughly in order of importance for getting a system I 
can use to develop software on. This means I'm going to work on FFI and 
sockets before I go back to fixing up exception handling unless fixed 
exceptions turn out to be required before the SBCL developers will commit 
the base patch (and, in all honesty, they probably won't be required). I 
will probably try to fix callbacks before sockets for similar reasons. 

And no, the contribs are still untested. Expect any of them that requires 
the FFI to fail miserably, and a couple of the others likewise. 

> Since this work was all being done outside of the main SBCL development 
> at the moment, it's not as clearly tracked, and I don't think there's a 
> dev mailing list or anything specifically for the Windows port.

Indeed not. And there probably won't be, since we're aiming to bring 
everything (or at least the basics) into the main SBCL tree after the 
December release. 

Okay, the other reason there isn't a mailing list for the windows port is 
that only one person is working on the windows port. When the developer can 
read his own mind he doesn't need to resort to email to tell himself what's 
up. 

>   - josh g.

 --Alastair Bridgewater 

_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners

Reply via email to