In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011) • Hacker News Board

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#121

Post by Annatar » Mon, Jul 15, 2019, 9:16 PM UTC

rjsw wrote: post #118

Annatar wrote: post #115

Earlier quoted context omitted.

SBCL documentation states that it can be built with another Lisp, but that is not true: I've tried with CCL and it failed spectacularly. I couldn't find a working version of CLISP for Solaris 10 for sparc and i86pc. Guys, I've built hundreds of packages for Solaris 10 on both sparc and i86pc the number of which can easily compete with the number of packages on "OpenCSW" and I'm telling you that SBCL is so broken on t…

CLISP should build from source, it seems to be getting built fine by Joyent pkgsrc bulk builds. Their build of SBCL is failing in C code [1], maybe a Solaris expert could fix this. The usual reason that SBCL stops building is that something has changed in the OS. [1] http://us-east.manta.joyent.com/pkgsrc/public/reports/upstre...

But nothing has changed on my build servers which are running Solaris 10, so OS change cannot be the cause; without additional information, that leaves us with one or more breakage(s) caused by someone in the core SBCL team.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#122

Post by kazinator » Mon, Jul 15, 2019, 9:16 PM UTC

Annatar wrote: post #23

s_Hogg wrote: post #13

Why is HN this interested in Lisp anyway? Not saying it's a good or bad language, just don't quite get why it receives as much attention as it does.

Because it can easily solve or altogether eschew a lot of the issues that object-oriented JavaScript developers are struggling with and that's barely scraping the tip of the iceberg of problems which Lisp doesn't suffer from. Alas one of the problems Lisp does quite acutely suffer from is that SBCL has become a defacto standard and its support for anything that isn't GNU/Linux (like Solaris / illumos) is dismal.

SBCL is not alone in neglecting Solaris. For instance, the GNU Debugger is not usable on Solaris any more. And it won't even read core files post-mortem. There is an open bug for this, unsolved.

My TXR runs on Solaris (Intel x86, note). I roll a build for Solaris 10 for every release.

TXR Lisp isn't an implementation of Common Lisp, however.

I build on Solaris because by doing so, I can tick off a little mental checkbox: "[ ] Runs on at least one OS that has Bell Labs Unix DNA".

It's only x86 because I don't have a port of jmp.S for SPARC. A quick an dirty port could be done using setjmp/lonjmp, without delimited continuations. (Or maybe even with?)

I've had to debug a few things in the past that showed up only on Solaris. For that it was worth it to have that Solaris port; but the debugging was difficult without GDB. For instance, most recently, a GC-related bug (potentially affecting all platforms) only reproduced, by chance, on Solaris.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#123

Post by rjsw » Mon, Jul 15, 2019, 10:14 PM UTC

Annatar wrote: post #120

rjsw wrote: post #119

Earlier quoted context omitted.

That platform table doesn't represent what will build, only which binary packages are on Sourceforge. I'm running 1.5.4 on NetBSD/amd64 and can build it on i386, sparc, ppc, arm and arm64.

NetBSD also happens to be a completely different operating system and pkgsrc is likely to contain NetBSD-specific patches.

I don't build from pkgsrc.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#124

Post by rjsw » Mon, Jul 15, 2019, 10:14 PM UTC

Annatar wrote: post #121

rjsw wrote: post #118

Earlier quoted context omitted.

CLISP should build from source, it seems to be getting built fine by Joyent pkgsrc bulk builds. Their build of SBCL is failing in C code [1], maybe a Solaris expert could fix this. The usual reason that SBCL stops building is that something has changed in the OS. [1] http://us-east.manta.joyent.com/pkgsrc/public/reports/upstre...

But nothing has changed on my build servers which are running Solaris 10, so OS change cannot be the cause; without additional information, that leaves us with one or more breakage(s) caused by someone in the core SBCL team.

Did you look at the build log I posted ?

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#125

Post by em-bee » Tue, Jul 16, 2019, 4:52 AM UTC

xrd wrote: post #95

srean wrote: post #92

Earlier quoted context omitted.

Oh I did not mean to say I hate the Dummies series. I had picked one up, something on personal finance if I remember correctly. I was quite pleasantly surprised that the author did not speak to me as if I am a dummy.

That's my experience with them as well. But, I've resisted looking at them even knowing that because I resisted calling myself a dummy. They are huge sellers, so I'm in the no minority with that opinion obviously.

i find the title entirely off-putting

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#126

Post by lispm » Tue, Jul 16, 2019, 6:35 AM UTC

Annatar wrote: post #116

rjsw wrote: post #113

Earlier quoted context omitted.

There are regular SBCL releases, something that is fixed will appear in a month or less. If you don't have a working SBCL you can bootstrap it using CLISP or cross-compile from a different OS such as FreeBSD.

CLISP doesn't work on Solaris either and I've no FreeBSD nor the spare time to figure out how to get it to work. The only Lisp which works is CCL but when I tried to build SBCL with it, the build failed spectacularly. I then went to use CCL but all the getopts examples are for SBCL and since I'm still learning Lisp I couldn't figure out how to make them work on CCL. So I'm busted. Post scriptum: it's been around six…

> The only Lisp which works is CCL

How about ABCL?

> I wouldn't have written what I have about SBCL and dismal support for Solaris

Unfortunately, a niche language implementation & OS combination.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#127

Post by Annatar » Tue, Jul 16, 2019, 7:28 AM UTC

rjsw wrote: post #124

Annatar wrote: post #121

Earlier quoted context omitted.

But nothing has changed on my build servers which are running Solaris 10, so OS change cannot be the cause; without additional information, that leaves us with one or more breakage(s) caused by someone in the core SBCL team.

Did you look at the build log I posted ?

I sure did: it's due to changing the code but not using the correct macro definitions and compiler options from what I could see (I'm on a mobile telephone, on vacation, so lots of the log is cut off). But you also have to realize that Solaris 10 is much older than illumos and I'm telling you that the build breaks on both.

I actually patched that and got past it, half a year ago. The build broke somewhere else after that and it was in Lisp so I had no idea how to fix it. This breakage is just a simple endianess "pre-flight check". SBCL's problems are much more serious then this: they broke it but good.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#128

Post by Annatar » Tue, Jul 16, 2019, 3:51 PM UTC

kazinator wrote: post #122

Annatar wrote: post #23

Earlier quoted context omitted.

Because it can easily solve or altogether eschew a lot of the issues that object-oriented JavaScript developers are struggling with and that's barely scraping the tip of the iceberg of problems which Lisp doesn't suffer from. Alas one of the problems Lisp does quite acutely suffer from is that SBCL has become a defacto standard and its support for anything that isn't GNU/Linux (like Solaris / illumos) is dismal.

SBCL is not alone in neglecting Solaris. For instance, the GNU Debugger is not usable on Solaris any more. And it won't even read core files post-mortem. There is an open bug for this, unsolved. My TXR runs on Solaris (Intel x86, note). I roll a build for Solaris 10 for every release. TXR Lisp isn't an implementation of Common Lisp, however. I build on Solaris because by doing so, I can tick off a little mental check…

I might be able to help you with jmp.S since I know SPARC assembler.

By doing builds on Solaris, you are ensuring your code remains clean and honest because Solaris and illumos are reference implementations of just about any open standard imaginable. If it works there, it's highly probable that the code is standards compliant.

For debugging, you can use dbx, which comes included with Sun Studio, which is a gratis download. If you compile with GCC, you'll have to use gdb. At least I couldn't figure out what Sun engineers did to their version of GCC to make it emit DWARF 2 debugging format.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#129

Post by Annatar » Tue, Jul 16, 2019, 3:56 PM UTC

lispm wrote: post #126

Annatar wrote: post #116

Earlier quoted context omitted.

CLISP doesn't work on Solaris either and I've no FreeBSD nor the spare time to figure out how to get it to work. The only Lisp which works is CCL but when I tried to build SBCL with it, the build failed spectacularly. I then went to use CCL but all the getopts examples are for SBCL and since I'm still learning Lisp I couldn't figure out how to make them work on CCL. So I'm busted. Post scriptum: it's been around six…

> The only Lisp which works is CCL How about ABCL? > I wouldn't have written what I have about SBCL and dismal support for Solaris Unfortunately, a niche language implementation & OS combination.

I get an existential crisis when I read "niche implementation" in the context of one of the most important operating systems which changed computing forever and which is a reference implementation for just about any open standard imaginable and that on an IT site full of IT professionals.

Never tried ABCL but will look into it when I get a chance.

Re: In May 2009 O'Reilly agreed to publish a book about Common Lisp (2011)

#130

Post by kazinator » Tue, Jul 16, 2019, 5:57 PM UTC

Annatar wrote: post #128

kazinator wrote: post #122

Earlier quoted context omitted.

SBCL is not alone in neglecting Solaris. For instance, the GNU Debugger is not usable on Solaris any more. And it won't even read core files post-mortem. There is an open bug for this, unsolved. My TXR runs on Solaris (Intel x86, note). I roll a build for Solaris 10 for every release. TXR Lisp isn't an implementation of Common Lisp, however. I build on Solaris because by doing so, I can tick off a little mental check…

I might be able to help you with jmp.S since I know SPARC assembler. By doing builds on Solaris, you are ensuring your code remains clean and honest because Solaris and illumos are reference implementations of just about any open standard imaginable. If it works there, it's highly probable that the code is standards compliant. For debugging, you can use dbx, which comes included with Sun Studio, which is a gratis dow…

Knowing assembler isn't so much a problem; I wrote the PPC and ARM variants in there without being versed in ARM or PPC assembler. I just don't understand the SPARC register windows well enough to be confident it would work.

Originally, I used setjmp and longjmp. The motivating reason jmp.S exists at all is that at one point I added delimited continuation support to the language. Delimited continuations are captured by copying segments of the stack into heap objects. Continuations are revived by copying back to the stack; but at a different location: the current stack top. Here is where setjmp/longmp became inadequate on Glibc/Linux systems. Glibc's setjmp applies an XOR mask to the pointers stored in jmp_buf, using a secret word (that is different with each process invocation). This is to make certain exploits difficult or impossible. But when we revive a continuation, we need to find inner pointers (from the stack back to itself) and fix them up, including the pointers in a jmp_buf. If these are masked by an XOR, that's a problem.

For any unsupported platform, the thing to do would be to try to just target the C library setjmp and longjmp instead of adding code to jmp.S.