5 ms·

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 t

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.

mepian 7y ago
SBCL is open source, so you are free to improve the support for Solaris.
- mark_l_watson 7y ago
  Also, the SBCL maintainers can be hired for custom help or support - one of my customers did this, with good results.
  - Annatar 7y ago
    I'm a private person in this capacity, so paying someone to reverse the breakage is out of the question. It's an outrage that something like that was allowed to happen in the first place. If this were my software, not only would I fix it immediately, but I would be deeply ashamed of myself for allowing it to happen. We as programmers should start taking responsibility for our actions.
- Annatar 7y ago
  I would if I knew how; it sure wasn't for lack of my trying to do so, but I don't know enough to pull it off. By the way expecting that something be fixed by a non-specialist just because something is open source and expecting someone to sink their extremely valuable free time so someone could break and destroy that work again, well, that's not only despicable, it's extremely infuriating. All the more infuriating as SBCL wouldn't exist without Solaris, which means someone already broke it at least once and here you come expecting me to not only know what to fix, but invest my life into something where my effort would likely be broken upstream again. This needs to be taken up by the core SBCL team. Meanwhile, pity the time I used to report bugs which just sit there unhandled.
  - rjsw 7y ago
    If none of the core SBCL team use Solaris then they won't know that SBCL doesn't work on it. I'm sure that people will suggest things to try if you post details of what you have done to get it to build. Leave out words like "despicable" though. Your account info states that you want to work with the Solaris successor projects, debugging a complex application is a good way to learn more about an OS.
    - Annatar 7y ago
      I've left as much information as I could, but nobody even bothered taking on the bug. The other bug was "fixed" but no information was provided on when it will be rolled into the next release, so that's not useful either, especially since Lisp cannot be built without a working Lisp first, which doesn't work now, so I've no way to test the fix. Working on debugging C code and assembler is one thing, working on debugging Lisp another: I have to master Lisp first, but without working SBCL that's not possible and I'm not switching to an inferior OS just to master something I can't later on deploy on illumos / Solaris. I'd spend an inordinate amount of my free time for dubious gain, something I can no longer afford, so much so that I've stopped sinking my precious free time into computers. Why does software often fail to gain acceptance, respectively why does it become successful? Availability.
      - rjsw 7y ago
        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.
        Annatar 7y ago
        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 months since I've opened those bug reports for i86pc and sparc and there are still no new releases: http://www.sbcl.org/platform-table.html http://www.sbcl.org/platform-table.html I wouldn't have written what I have about SBCL and dismal support for Solaris if I hadn't tried to build, debug, package and research it and research throughly I did. As a professional engineer, the first thing I did was read all the documentation and all the INSTALL instructions I could find as well as any other documentation and bug reports I could locate using multiple search engines; the official documentation is very poor for such a big and serious project and in my opinion as an engineer, not very professional at all, especially when compared to corporate documentation efforts. This creates an additional hurdle for someone looking to master Lisp and do so using SBCL. Pity the two intense weeks of my spare time; what a waste of my life since I'm none the smarter or more knowledgeable for it.
rjsw 7y ago
SBCL works fine on BSD variants, and the project makes submitting patches easy enough.
_ph_ 7y ago
I have run a server software written in SBCL on Solaris for many years. In which sense is the Solaris support lacking?
- Annatar 7y ago
  SBCL goes straight into a debugger on i86pc and on sparc it just core dumps immediately. It cannot be built from source on either of those platforms.
  - _ph_ 7y ago
    Then this is a regression in newer SBCL versions.
    - Annatar 7y ago
      That's exactly what I've been trying to say all along. It needs serious attention from the core SBCL team.
kazinator 7y ago
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.
- Annatar 7y ago
  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.
  - kazinator 7y ago
    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.

mepian 7y ago

SBCL is open source, so you are free to improve the support for Solaris.

mark_l_watson 7y ago
Also, the SBCL maintainers can be hired for custom help or support - one of my customers did this, with good results.
- Annatar 7y ago
  I'm a private person in this capacity, so paying someone to reverse the breakage is out of the question. It's an outrage that something like that was allowed to happen in the first place. If this were my software, not only would I fix it immediately, but I would be deeply ashamed of myself for allowing it to happen. We as programmers should start taking responsibility for our actions.
Annatar 7y ago
I would if I knew how; it sure wasn't for lack of my trying to do so, but I don't know enough to pull it off. By the way expecting that something be fixed by a non-specialist just because something is open source and expecting someone to sink their extremely valuable free time so someone could break and destroy that work again, well, that's not only despicable, it's extremely infuriating. All the more infuriating as SBCL wouldn't exist without Solaris, which means someone already broke it at least once and here you come expecting me to not only know what to fix, but invest my life into something where my effort would likely be broken upstream again. This needs to be taken up by the core SBCL team. Meanwhile, pity the time I used to report bugs which just sit there unhandled.
- rjsw 7y ago
  If none of the core SBCL team use Solaris then they won't know that SBCL doesn't work on it. I'm sure that people will suggest things to try if you post details of what you have done to get it to build. Leave out words like "despicable" though. Your account info states that you want to work with the Solaris successor projects, debugging a complex application is a good way to learn more about an OS.
  - Annatar 7y ago
    I've left as much information as I could, but nobody even bothered taking on the bug. The other bug was "fixed" but no information was provided on when it will be rolled into the next release, so that's not useful either, especially since Lisp cannot be built without a working Lisp first, which doesn't work now, so I've no way to test the fix. Working on debugging C code and assembler is one thing, working on debugging Lisp another: I have to master Lisp first, but without working SBCL that's not possible and I'm not switching to an inferior OS just to master something I can't later on deploy on illumos / Solaris. I'd spend an inordinate amount of my free time for dubious gain, something I can no longer afford, so much so that I've stopped sinking my precious free time into computers. Why does software often fail to gain acceptance, respectively why does it become successful? Availability.
    - rjsw 7y ago
      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.
      - Annatar 7y ago
        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 months since I've opened those bug reports for i86pc and sparc and there are still no new releases: http://www.sbcl.org/platform-table.html http://www.sbcl.org/platform-table.html I wouldn't have written what I have about SBCL and dismal support for Solaris if I hadn't tried to build, debug, package and research it and research throughly I did. As a professional engineer, the first thing I did was read all the documentation and all the INSTALL instructions I could find as well as any other documentation and bug reports I could locate using multiple search engines; the official documentation is very poor for such a big and serious project and in my opinion as an engineer, not very professional at all, especially when compared to corporate documentation efforts. This creates an additional hurdle for someone looking to master Lisp and do so using SBCL. Pity the two intense weeks of my spare time; what a waste of my life since I'm none the smarter or more knowledgeable for it.

rjsw 7y ago

SBCL works fine on BSD variants, and the project makes submitting patches easy enough.

_ph_ 7y ago

I have run a server software written in SBCL on Solaris for many years. In which sense is the Solaris support lacking?

Annatar 7y ago
SBCL goes straight into a debugger on i86pc and on sparc it just core dumps immediately. It cannot be built from source on either of those platforms.
- _ph_ 7y ago
  Then this is a regression in newer SBCL versions.
  - Annatar 7y ago
    That's exactly what I've been trying to say all along. It needs serious attention from the core SBCL team.

kazinator 7y ago

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.

Annatar 7y ago
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.
- kazinator 7y ago
  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.