4 ms·

As for Lisp on Illumos, which Lisp did you try? Now before I get into the details, let me just state for the record that I've ported 200+ (if not more) freewar

by Annatar 10y ago

As for Lisp on Illumos, which Lisp did you try? Now before I get into the details, let me just state for the record that I've ported 200+ (if not more) freeware packages to Solaris, and I modify, compile and link a lot, so this was not my first "walk in the park"... First I tried CMUCL. And after some patching, I got it to work. But only 32-bit. And it would core dump a lot. Because the GCC compiler at the time didn't support DWARF 2 (it seems to support it now, but I'd have to build GCC again), compiling with -g was basically worthless for debugging, so I ditched it, because I didn't feel like disassembling x86 assembler that day. Then I tried CLISP, and that was a lost cause, it was so busted that it wouldn't even build. The last thing I tried was Steel Bank Common LISP, SBCL. Unfortunately, just like other LISP's, SBCL isn't self hosting, and it requires a working LISP to build itself. In my case, that would have been CMUCL, except that I abandoned that a while ago when it became clear that it would only work 32-bit and that it crashed. It's a shame, I really think that ANSI Common LISP is the future. However, I am primarily a schemer, and if you're excited about lisp-1s, hygenic macros, tail calls, call/cc, and case sensitivity, you may want to look into scheme. My understanding is that Scheme is not 100% LISP compatible, but even worse, that it runs as bytecode on a Java virtual machine. As soon as I see a language running on a virtual machine of any kind, I'm done. That won't enter my systems or my network. If I cannot compile it into straight machine code binary executable, that's it, it's out of the window, and never to return. Not on my watch! Is my finding correct, or is there a Scheme to ELF machine code binary executable compiler out there? If none of the above run at their latest version, which I very much doubt, you could always try lx zones as a last resort. I created an lx-branded zone for the first time a few days ago and was just absolutely speechless with regards to how everything just works. The Linux applications literally think they're running on Linux. The only things which gave it away as not being Linux was the completely made up kernel version and /native, containing native illumos binaries that would be in /usr/{bin,sbin} on illumos. It blew my mind.

qwertyuiop924 10y ago
First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does. >My understanding is that Scheme is not 100% LISP compatible, but even worse, that it runs as bytecode on a Java virtual machine. As soon as I see a language running on a virtual machine of any kind, I'm done. That won't enter my systems or my network. If I cannot compile it into straight machine code binary executable, that's it, it's out of the window, and never to return. Not on my watch! Is my finding correct, or is there a Scheme to ELF machine code binary executable compiler out there? ...ummm... wow. It's history time. Lisp isn't a language or a standard. It's a family of languages. When you say Lisp, you're talking about Common Lisp, which is one of the two popular lisp standards today. The other is Scheme RnRS, with R5RS and R7RS being the most widely implemented. Scheme isn't Common Lisp compatible, as it is a totally different language, although still a Lisp. Some people believe that Scheme shouldn't be regarded as a lisp, but those people are crazy. Scheme prides itself on minimalism, originating in academia, and designed for PL research and education, and so, much like POSIX, every implementation extends it in a different direction. Some Schemes are suitable for Real Work, others are not. As scheme is a standard, it has been implemented for a variety of architectures. While it does run on the JVM, that implementation isn't very good. You're probably thinking of Clojure, which is JVM. There are several schemes that compile to native code. Gambit and Chicken are the most popular. While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI. If you can live without native compilation, Guile, at least, is worth looking at. As for Chicken vs Gambit, it's pretty evenly stacked. I know Chicken better than I know Gambit, but I'll try to give a good comparison: FOR CHICKEN: -Chicken uses Cheney-on-the-MTA compilation meaning that re-entrant continuations (think setcontext/setjmp but better) are no slower than any function call. -Chicken has a really, really good library repository. For a scheme, anyway. -Chicken has fairly good POSIX integration -Previous versions of Chicken have definitely compiled on OpenSolaris. -Chicken has an almost ungodly helpful maintainer and community, with active mailinglists and IRC. AGAINST CHICKEN: -Chicken isn't reentrant -Chicken has no pthread support, only supporting fork(2) and pre-emptive coroutines. -Chicken has a really good compiler. You'll see why this is a mark against it in a minute. FOR GAMBIT: -Gambit has compiler that generates really, really, really good native code. -Gambit is, I think, reentrant -Gambit has okay POSIX -Gambit has Termite, which is erlang-style coroutines, in addition to a Chicken-like system. Guile is the only scheme I know that has pthread support, and it's not in this comparison. AGAINST GAMBIT: -Gambit's continuation implementation is slower and more limited than Chicken's. -Even with BlackHole and SchemeSpheres, the two module sets it has, Gambit is behind Chicken in modules -Gambit's FFI is harder to use than Chicken's. -I don't know how well Gambit supports Solaris.
- Annatar 10y ago
  First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does. One of them didn't work for either i86pc (that's what we call the x86 and x86_64 platform on Solaris) or sparc, and my requirement is that it has to build and run on both exactly the same, as 50% of my server park is UltraSPARC, and 50% various forms of intel-based processors. But I'd have to look at that again. Something didn't work, or else I would be running SBCL by now. While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI. Now see, that is a severe step back for me: I had bytecode back in 1984, except then the "virtual machine" was called "Commodore BASIC", and "bytecode" was known as tokens, which is what they really are when you learn about AST parsers and trees in computer science at the university. So when I see "bytecode", that's a throwback. And a very bad, bad throwback, masked with pure brute force in terms of massive amounts of memory and processing power. It was a very bad and inefficient, slow solution then, and even with all this processing power and memory, it's a very bad and inefficient, slow solution now. I have never, and will never tolerate that. No amount of programming pleasantness and syntactical sugar will change that. The way forward is clear to me now: ANSI Common LISP.
  - qwertyuiop924 10y ago
    ...Did you miss the 1/2 of my post where I talked about two of the best native-code compilers scheme had to offer? Gambit and Chicken are both fantastic, and compile to C, no bytecode anywhere. Also, your understanding of bytecode is deeply, deeply wrong. It's accurate to an extent, true, but Bytecode isn't the same thing as an interpreter, and can be much faster. But even if bytecode is unacceptable to you, as it does indeed sacrifice performance and I won't deny that, I just gave you 2 native code compilers. Did you just not notice that, or is there a reason you found them unacceptable?
    - Annatar 10y ago
      I managed to miss it! FAIL. Based on what you wrote, Chicken is out - I want reentrant. ... I got Gambit to compile, simple expressions appear to work - but I cannot figure out how to compile them to a binary executable. cat t.scheme (define Hello "Hello") gsc t.scheme file t.o1 t.o1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available ./t.o1 Segmentation fault (core dumped) ...so that needs more research. I also haven't tested on sparc.

by Annatar 10y ago

qwertyuiop924 10y ago

First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does. >My understanding is that Scheme is not 100% LISP compatible, but even worse, that it runs as bytecode on a Java virtual machine. As soon as I see a language running on a virtual machine of any kind, I'm done. That won't enter my systems or my network. If I cannot compile it into straight machine code binary executable, that's it, it's out of the window, and never to return. Not on my watch! Is my finding correct, or is there a Scheme to ELF machine code binary executable compiler out there? ...ummm... wow. It's history time. Lisp isn't a language or a standard. It's a family of languages. When you say Lisp, you're talking about Common Lisp, which is one of the two popular lisp standards today. The other is Scheme RnRS, with R5RS and R7RS being the most widely implemented. Scheme isn't Common Lisp compatible, as it is a totally different language, although still a Lisp. Some people believe that Scheme shouldn't be regarded as a lisp, but those people are crazy. Scheme prides itself on minimalism, originating in academia, and designed for PL research and education, and so, much like POSIX, every implementation extends it in a different direction. Some Schemes are suitable for Real Work, others are not. As scheme is a standard, it has been implemented for a variety of architectures. While it does run on the JVM, that implementation isn't very good. You're probably thinking of Clojure, which is JVM. There are several schemes that compile to native code. Gambit and Chicken are the most popular. While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI. If you can live without native compilation, Guile, at least, is worth looking at. As for Chicken vs Gambit, it's pretty evenly stacked. I know Chicken better than I know Gambit, but I'll try to give a good comparison: FOR CHICKEN: -Chicken uses Cheney-on-the-MTA compilation meaning that re-entrant continuations (think setcontext/setjmp but better) are no slower than any function call. -Chicken has a really, really good library repository. For a scheme, anyway. -Chicken has fairly good POSIX integration -Previous versions of Chicken have definitely compiled on OpenSolaris. -Chicken has an almost ungodly helpful maintainer and community, with active mailinglists and IRC. AGAINST CHICKEN: -Chicken isn't reentrant -Chicken has no pthread support, only supporting fork(2) and pre-emptive coroutines. -Chicken has a really good compiler. You'll see why this is a mark against it in a minute. FOR GAMBIT: -Gambit has compiler that generates really, really, really good native code. -Gambit is, I think, reentrant -Gambit has okay POSIX -Gambit has Termite, which is erlang-style coroutines, in addition to a Chicken-like system. Guile is the only scheme I know that has pthread support, and it's not in this comparison. AGAINST GAMBIT: -Gambit's continuation implementation is slower and more limited than Chicken's. -Even with BlackHole and SchemeSpheres, the two module sets it has, Gambit is behind Chicken in modules -Gambit's FFI is harder to use than Chicken's. -I don't know how well Gambit supports Solaris.

Annatar 10y ago
First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does. One of them didn't work for either i86pc (that's what we call the x86 and x86_64 platform on Solaris) or sparc, and my requirement is that it has to build and run on both exactly the same, as 50% of my server park is UltraSPARC, and 50% various forms of intel-based processors. But I'd have to look at that again. Something didn't work, or else I would be running SBCL by now. While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI. Now see, that is a severe step back for me: I had bytecode back in 1984, except then the "virtual machine" was called "Commodore BASIC", and "bytecode" was known as tokens, which is what they really are when you learn about AST parsers and trees in computer science at the university. So when I see "bytecode", that's a throwback. And a very bad, bad throwback, masked with pure brute force in terms of massive amounts of memory and processing power. It was a very bad and inefficient, slow solution then, and even with all this processing power and memory, it's a very bad and inefficient, slow solution now. I have never, and will never tolerate that. No amount of programming pleasantness and syntactical sugar will change that. The way forward is clear to me now: ANSI Common LISP.
- qwertyuiop924 10y ago
  ...Did you miss the 1/2 of my post where I talked about two of the best native-code compilers scheme had to offer? Gambit and Chicken are both fantastic, and compile to C, no bytecode anywhere. Also, your understanding of bytecode is deeply, deeply wrong. It's accurate to an extent, true, but Bytecode isn't the same thing as an interpreter, and can be much faster. But even if bytecode is unacceptable to you, as it does indeed sacrifice performance and I won't deny that, I just gave you 2 native code compilers. Did you just not notice that, or is there a reason you found them unacceptable?
  - Annatar 10y ago
    I managed to miss it! FAIL. Based on what you wrote, Chicken is out - I want reentrant. ... I got Gambit to compile, simple expressions appear to work - but I cannot figure out how to compile them to a binary executable. cat t.scheme (define Hello "Hello") gsc t.scheme file t.o1 t.o1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available ./t.o1 Segmentation fault (core dumped) ...so that needs more research. I also haven't tested on sparc.