Page 1 of 1

Some SBCL Windows binaries

Posted: Sun Feb 22, 2009 11:41 am
by anta40
When I was Googling for SBCL v1.0.25 Windows binary, I found this page:
http://cid-ab3d364d1e6a27e7.skydrive.li ... .aspx/SBCL

You can find the binaries of SBCL v1.0.22 up to 1.0.25 there.
Good thing if you're too lazy to compile it yourself... :mrgreen:

Re: Some SBCL Windows binaries

Posted: Sun Feb 22, 2009 5:39 pm
by nuntius
Just a friendly reminder that SBCL still has a handful of known bugs on MSWin. Supposedly they aren't terribly hard to fix, and require no lisp knowledge. Just a willingness to learn some x86 assembly and MSWin internals.

Re: Some SBCL Windows binaries

Posted: Sun Feb 22, 2009 11:55 pm
by anta40
nuntius wrote:Just a friendly reminder that SBCL still has a handful of known bugs on MSWin.

really?
well i'm still learning lisp, and not using it extensively, so probably i haven't met one
nuntius wrote:Supposedly they aren't terribly hard to fix, and require no lisp knowledge. Just a willingness to learn some x86 assembly and MSWin internals.
i don't know whether to laugh or cry... :mrgreen:

Re: Some SBCL Windows binaries

Posted: Mon Feb 23, 2009 11:08 pm
by nuntius
So I chatted with Alastair Bridgewater at tonight's Boston Lisp meeting; here were the big three showstoppers
- serve-event
On a POSIX (e.g. linux) system, you open a file and pass its id to select() when polling for events. On MSWin, you get one file handle for reading and writing, and another file handle for event processing... Serve-event is used for useful things like the Slime repl.
- memory map
Traditionally, sbcl allocates the maximum memory as a contiguous heap at startup. This is dicey on MSWin since MS wisely chose to make DLLs relocatable instead of position independent (a la unix .so's). The DLLs often fragment the memory address space so badly that sbcl fails to allocate its heap. This seems to affect some users more than others, depending on which DLLs are loaded where; sbcl simply won't load when it happens; it often takes a reboot to clear (standard MSWin cure-all). The fix is to make sbcl work with several heap slices instead of one contiguous block.
- external formats
"Real OSs" use \n as the end-of-line marker. MSWin uses \r\n (possibly because old macs "thought different" and chose \r). SBCL doesn't read lines properly on MSWin, resulting in the \r appearing as if it were text. This may or may not be a problem for you depending on editor settings, usage requirements, etc.

Alastair says all of these have known solutions; he just hasn't had time to finish them. He submitted rough sbcl patches for one of them several months ago, but nobody picked it up and finished it.

Most other known bugs were platform-agnostic (or at least universally broken).

Re: Some SBCL Windows binaries

Posted: Mon Mar 23, 2009 2:44 am
by aerique
I wouldn't mind donating some money to this cause.