Some SBCL Windows binaries

Discussion of Common Lisp
Post Reply
anta40
Posts: 19
Joined: Fri Oct 10, 2008 10:27 pm
Contact:

Some SBCL Windows binaries

Post by anta40 » Sun Feb 22, 2009 11:41 am

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:

nuntius
Posts: 538
Joined: Sat Aug 09, 2008 10:44 am
Location: Newton, MA

Re: Some SBCL Windows binaries

Post by nuntius » Sun Feb 22, 2009 5:39 pm

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.

anta40
Posts: 19
Joined: Fri Oct 10, 2008 10:27 pm
Contact:

Re: Some SBCL Windows binaries

Post by anta40 » Sun Feb 22, 2009 11:55 pm

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:

nuntius
Posts: 538
Joined: Sat Aug 09, 2008 10:44 am
Location: Newton, MA

Re: Some SBCL Windows binaries

Post by nuntius » Mon Feb 23, 2009 11:08 pm

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).

aerique
Posts: 10
Joined: Sat Jun 28, 2008 9:06 am
Location: Delft, Netherlands
Contact:

Re: Some SBCL Windows binaries

Post by aerique » Mon Mar 23, 2009 2:44 am

I wouldn't mind donating some money to this cause.

Post Reply