4 ms·

Well, I just started reading Land of Lisp a few weeks ago. It recommends CLisp. I'm quite new to all of lisp, so, let's take a look: $ hg clone http://hg.c

by jordigh 12y ago

Well, I just started reading Land of Lisp a few weeks ago. It recommends CLisp. I'm quite new to all of lisp, so, let's take a look: $ hg clone http://hg.code.sf.net/p/clisp/clisp Wow, that took a long time to clone. How big is the thing? $ du -hs clisp 147M clisp $ cd clisp $ hg branches default 15611:5c63938ef493 Hm, a moderate-sized repo, only 15611 commits and no branching to speak of. Let's look at the latest commits, $ hg heads changeset: 15611:5c63938ef493 tag: tip user: Sam Steingold <sds@podval.org> date: Wed Oct 22 12:04:12 2014 -0400 summary: Fix bug#668 posix:file-state always return NIL for :rdev What! Last commit was from October last year? Clearly development has slowed to a standstill. Who is generally in charge around here nowadays? $ hg churn -r "date('2010 to today')" sds 313529 ************************************** sds@podval.org 194383 ******************** vtz 2723 * ampy 801 haible 758 elliottslaughter@gmail.com 627 vtzankov@gmail.com 279 bruno@clisp.org 239 cvs2hg 46 So for the past 5 years, it's been almost all the work of sds, Sam Steingold. Huh. I was expecting Bruno Haible to still be involved, but he seems to be doing almost nothing nowadays. Well, it's not unusual for a free project to be the labour of only a single person, but it's typical to have a lot of small drive-by contributions. Almost nobody except sds has done anything for CLISP for the last five years, which could explain why there have been no releases. But there's been a lot of work being done! Look at all those lines of code that have been modified! Maybe all they really need is a release manager. Well, does the thing build right now? $ ./configure ... ./configure: libsigsegv was not detected, thus some features, such as generational garbage collection and stack overflow detection in interpreted Lisp code cannot be provided. Please install libsigsegv like this: ... Okay, fine, I'll install it. Let me try again, $ ./configure ... ./configure: libsigsegv was not detected, thus some features, such as generational garbage collection and stack overflow detection in interpreted Lisp code cannot be provided. Please install libsigsegv like this: ... What? Didn't I just do that? $ apt-cache policy libsigsegv-dev libsigsegv-dev: Installed: 2.9-4 Candidate: 2.9-4 Version table: 2.10-4+b1 0 -1 http://ftp.ca.debian.org/debian/ unstable/main amd64 Packages *** 2.9-4 0 500 http://ftp.ca.debian.org/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status Okay, maybe my version of libsigsegv is too old. But a version newer than Debian's oldstable is mighty demanding of a package whose development has slowed down to nothing. So at this point I'm considering if I want to debug their build system or not. I might. Or perhaps someone else will. My conclusion is that CLisp development is almost dead, yet there certainly is something worthwhile releasing here since the last release in 2010.

rjsw 12y ago
And that is why people shouldn't use configure [1]. [1] https://www.varnish-cache.org/docs/2.1/phk/autocrap.html https://www.varnish-cache.org/docs/2.1/phk/autocrap.html
- jordigh 12y ago
  Turns out that configure was just caching the past test for libsigsegv. I cleared the cache and was able to build. The test suite ran for a good chunk of time but segfaulted. So it doesn't look like CLisp is beyond all hope, just a little lonely.
  - masukomi 12y ago
    Yeah, I brew installed it on my mac and, despite the world seeming to prefer SBCL I've been rather happy with it.
- taylanub 12y ago
  >Some day when I have the time, I will rip out all the autocrap stuff and replace it with a 5 line shellscript that calls uname -s. And packagers will everywhere will hate you for it. I've recently written many GNU Guix package recipes, and packages using Autotools are the ones I tend to have the least headaches with. CMake and Waf are so-so I think, perhaps lacking in maturity, but I didn't have that much experience with them. Custom/hand-written Makefiles and ./configure scripts are the worst. Just learn Autotools, get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD. Even if only targeting GNU and BSD systems, there is already enough diversity and library detection boilerplate to make it worth using a proper build system, and Autotools is the most mature one out of the bunch. It's even more important for unconventional systems like Nix/Guix where software is to be built in very special ways, where hard-coded assumptions in build systems hurt, especially if a custom one; if it's a known one then even if hard-coded it will probably conform to some typical pattern of use of that build system so one can use tooling to automatically fix packages using that build system, and in the case of Autotools that isn't necessary in first place because everything is parameterized and flexible to hell and back. Also please do use pkg-config. Like Autotools, it's not perfect either, but I could write another two paragraphs on how helpful it is in bringing consistency, toolability, etc. into build/packaging systems...

by jordigh 12y ago

rjsw 12y ago

And that is why people shouldn't use configure [1]. [1] https://www.varnish-cache.org/docs/2.1/phk/autocrap.html https://www.varnish-cache.org/docs/2.1/phk/autocrap.html

jordigh 12y ago
Turns out that configure was just caching the past test for libsigsegv. I cleared the cache and was able to build. The test suite ran for a good chunk of time but segfaulted. So it doesn't look like CLisp is beyond all hope, just a little lonely.
- masukomi 12y ago
  Yeah, I brew installed it on my mac and, despite the world seeming to prefer SBCL I've been rather happy with it.
taylanub 12y ago
>Some day when I have the time, I will rip out all the autocrap stuff and replace it with a 5 line shellscript that calls uname -s. And packagers will everywhere will hate you for it. I've recently written many GNU Guix package recipes, and packages using Autotools are the ones I tend to have the least headaches with. CMake and Waf are so-so I think, perhaps lacking in maturity, but I didn't have that much experience with them. Custom/hand-written Makefiles and ./configure scripts are the worst. Just learn Autotools, get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD. Even if only targeting GNU and BSD systems, there is already enough diversity and library detection boilerplate to make it worth using a proper build system, and Autotools is the most mature one out of the bunch. It's even more important for unconventional systems like Nix/Guix where software is to be built in very special ways, where hard-coded assumptions in build systems hurt, especially if a custom one; if it's a known one then even if hard-coded it will probably conform to some typical pattern of use of that build system so one can use tooling to automatically fix packages using that build system, and in the case of Autotools that isn't necessary in first place because everything is parameterized and flexible to hell and back. Also please do use pkg-config. Like Autotools, it's not perfect either, but I could write another two paragraphs on how helpful it is in bringing consistency, toolability, etc. into build/packaging systems...