33 ms·

CLisp needs maintainers

94 points by ghostDancer 11y ago

jordigh 11y 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 11y 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 11y 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 11y 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 11y 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...
edem 11y ago
I'm a bit confused. What is the relationship between CLisp and ANSI Common Lisp?
- orodley 11y ago
  CLisp is an implementation of ANSI Common Lisp.
  - edem 11y ago
    Thanks for the clarification.
- jordigh 11y ago
  CLisp is a GNU implementation of common lisp. Other popular free implementations include SBCL and CMUCL, both of which have made recent releases. GCL is the other GNU common lisp, which also made a release more recently than CLisp.
  - zachbeane 11y ago
    This is true in the same sense that the GIMP is the "GNU Image Manipulation Program". It's just a label, and a license choice, without much real meaning behind it. GCL is also called "GNU Common Lisp". CMUCL is not popular any more. SBCL is popular, and so is Clozure CL.
    - jordigh 11y ago
      Hm, indeed, I was expecting to see CLisp follow the GNU coding standards, but it doesn't seem to. I know GIMP does, though, and it consistently uses GNU terminology (free software, not open source, etc). Being GNU does mean something for most GNU packages. In Octave we also follow most of the GNU coding standards, for example, and we benefit from FSF and GNU infrastructure.
      - kazinator 11y ago
        CLISP, historically (which takes us back to 1987), did not start out as GPL-ed software, and certainly wasn't part of the GNU Project. First it became GPLed, over a heated dispute with Stallman w.r.t. its use of the GNU Readline library. Evidently, it is now part of the GNU Project. (So there is justification in referring to it as "GNU CLISP".) Programs aren't going to switch their coding style just because they join the GNU Project.
kazinator 11y ago
I sent a bug report to the clisp-list mailing list just days ago, but it didn't come through. Date: Mon, 04 May 2015 07:20:34 -0700 To: Clisp list <clisp-list@lists.sourceforge.net> Subject: Invalid backquote reduction: ,',@x Hi all, I've discovered that (admittedly, an old version) of CLISP is reducing a certain backquote syntax according to a hare-brained user expectation instead of diagnosing en error. Pardon me if this has been fixed more recently. In a double backquote, if you quote a splice, and then unquote the quote, the unquote and quote cancel out naively. (Is that, by chance, my doing???) CLISP: [1]> (let ((a '(1 2 3))) ``(a b c ,',@a)) '(A B C 1 2 3) Of course the above quote form then eval-s to (A B C 1 2 3). Clozure CL: ? (let ((a '(1 2 3))) ``(a b c ,',@a)) (LIST* 'A (LIST* 'B (LIST* 'C (LIST (QUOTE 1 2 3))))) ? (eval *) > Error: Too many arguments in form (QUOTE 1 2 3) . The Clozure output (IMO correct) illustrates precisely what wrong, so I almost don't have to say anything more. The construct ',@a is (QUOTE ,@A) which stuffs zero or more things into the QUOTE syntax where there should be exactly one, potentially resulting in an incorrect quote syntax. So given (UNQUOTE (QUOTE (SPLICE A))), then only if A generates exactly one item, are we justified in "canceling" the QUOTE and UNQUOTE! In other cases, it is invalid and should be diagnosed as an abuse of QUOTE. * * * Is there a possibility that this could be documented as an extension? I think it's too much of a special case in its present form, because it only works when the QUOTE form is an immediate argument of the UNQUOTE, as seen from this CLISP output: [2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a))) (LIST 'A 'B 'C (LIST (QUOTE 1 2 3))) We might imagine that a possibly meaningful extension (which swiftly reveals itself to be otherwise) along these lines: "If a splice is the child, direct or indirect, of an unquote, then the unquote *and all intervening syntax* distributes over the splice, as if by replication over the elements. That is to say ,(syntax ,@form) is treated as if it were ,(syntax ,(first form)) ,(syntax ,(second form)) and so on, where form is evaluated only once, and the number of unquotes depends on the size of the output of form. According to the above rule, we would then expect: [2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a))) ;; FANTASY: (LIST 'A 'B 'C (LIST (QUOTE 1)) (LIST (QUOTE 2)) (LIST (QUOTE 3))) The problem is that this interferes with existing semantics; the structure ,(syntax ,@form) already has firm meaning, which is that form is evaluated to create arguments which are substituted into SYNTAX, and then this is unquoted, leading to the evaluation a single instance of SYNTAX as an operator. When SYNTAX is QUOTE, no special exception can be made; ,(quote ,@form) must also mean "zero or more arguments into quote which is then evaled in the next round, possibly leading to a quoting error".
616c 11y ago
You will see that a few people ask: why care in the face of such impressive native code compilers: Steel Bank, Clozure, and Embedded (although maybe ECL is short for something else; ironically they also needed a new maintainer as the previous guy became busy): porting and bootstrapping. https://www.common-lisp.net/~bmastenbrook/new-sbcl/porting.html https://www.common-lisp.net/~bmastenbrook/new-sbcl/porting.h... With CLISP that worked on ARM, I am not sure how much slower it would have been to port SBCL to ARM architectures, which is less <1 year of usable, even though CCL had it for years (and why I started compiling CCL using the AUR mechanism on Arch Linux prior to using SBCL in the official repos, for later playing with RPi stuff). So, thanks for the awesome Lisp, and thanks to you guys specifically because it is niche and thankless with so many jokes about the Lisp/CL community. Even on HN, you can hear the mumbling when people post Lisp articles. (hail (clisp))
- jordigh 11y ago
  Thanks, I was looking for an excuse to try to help CLisp. This might be it.
  - 616c 11y ago
    Cool. And that is coming from me, someone who knows like %1 of anything CL/Lisp related. Unrelated side bar for initiated: is the actual capitalization of this thing (beyond the terminal of course) CLisp or CLISP? http://clisp.org/ http://clisp.org/ So I noticed that the original title of this link (at least when I started reading) was CLisp, and it had not even occurred to me it was C( language) Lisp maybe, but still I though the caps must br wrong. On their site it is full CAPS, even though that peeves a lot of Lispers who will tell you that is like original Lisp Lisps (or LISP Lisp family languages, to be funny). So can someone chime in and tell us?

94 points by ghostDancer 11y 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 11y 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 11y 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 11y 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 11y 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...

edem 11y ago

I'm a bit confused. What is the relationship between CLisp and ANSI Common Lisp?

orodley 11y ago
CLisp is an implementation of ANSI Common Lisp.
- edem 11y ago
  Thanks for the clarification.
jordigh 11y ago
CLisp is a GNU implementation of common lisp. Other popular free implementations include SBCL and CMUCL, both of which have made recent releases. GCL is the other GNU common lisp, which also made a release more recently than CLisp.
- zachbeane 11y ago
  This is true in the same sense that the GIMP is the "GNU Image Manipulation Program". It's just a label, and a license choice, without much real meaning behind it. GCL is also called "GNU Common Lisp". CMUCL is not popular any more. SBCL is popular, and so is Clozure CL.
  - jordigh 11y ago
    Hm, indeed, I was expecting to see CLisp follow the GNU coding standards, but it doesn't seem to. I know GIMP does, though, and it consistently uses GNU terminology (free software, not open source, etc). Being GNU does mean something for most GNU packages. In Octave we also follow most of the GNU coding standards, for example, and we benefit from FSF and GNU infrastructure.
    - kazinator 11y ago
      CLISP, historically (which takes us back to 1987), did not start out as GPL-ed software, and certainly wasn't part of the GNU Project. First it became GPLed, over a heated dispute with Stallman w.r.t. its use of the GNU Readline library. Evidently, it is now part of the GNU Project. (So there is justification in referring to it as "GNU CLISP".) Programs aren't going to switch their coding style just because they join the GNU Project.

kazinator 11y ago

I sent a bug report to the clisp-list mailing list just days ago, but it didn't come through. Date: Mon, 04 May 2015 07:20:34 -0700 To: Clisp list <clisp-list@lists.sourceforge.net> Subject: Invalid backquote reduction: ,',@x Hi all, I've discovered that (admittedly, an old version) of CLISP is reducing a certain backquote syntax according to a hare-brained user expectation instead of diagnosing en error. Pardon me if this has been fixed more recently. In a double backquote, if you quote a splice, and then unquote the quote, the unquote and quote cancel out naively. (Is that, by chance, my doing???) CLISP: [1]> (let ((a '(1 2 3))) ``(a b c ,',@a)) '(A B C 1 2 3) Of course the above quote form then eval-s to (A B C 1 2 3). Clozure CL: ? (let ((a '(1 2 3))) ``(a b c ,',@a)) (LIST* 'A (LIST* 'B (LIST* 'C (LIST (QUOTE 1 2 3))))) ? (eval *) > Error: Too many arguments in form (QUOTE 1 2 3) . The Clozure output (IMO correct) illustrates precisely what wrong, so I almost don't have to say anything more. The construct ',@a is (QUOTE ,@A) which stuffs zero or more things into the QUOTE syntax where there should be exactly one, potentially resulting in an incorrect quote syntax. So given (UNQUOTE (QUOTE (SPLICE A))), then only if A generates exactly one item, are we justified in "canceling" the QUOTE and UNQUOTE! In other cases, it is invalid and should be diagnosed as an abuse of QUOTE. * * * Is there a possibility that this could be documented as an extension? I think it's too much of a special case in its present form, because it only works when the QUOTE form is an immediate argument of the UNQUOTE, as seen from this CLISP output: [2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a))) (LIST 'A 'B 'C (LIST (QUOTE 1 2 3))) We might imagine that a possibly meaningful extension (which swiftly reveals itself to be otherwise) along these lines: "If a splice is the child, direct or indirect, of an unquote, then the unquote *and all intervening syntax* distributes over the splice, as if by replication over the elements. That is to say ,(syntax ,@form) is treated as if it were ,(syntax ,(first form)) ,(syntax ,(second form)) and so on, where form is evaluated only once, and the number of unquotes depends on the size of the output of form. According to the above rule, we would then expect: [2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a))) ;; FANTASY: (LIST 'A 'B 'C (LIST (QUOTE 1)) (LIST (QUOTE 2)) (LIST (QUOTE 3))) The problem is that this interferes with existing semantics; the structure ,(syntax ,@form) already has firm meaning, which is that form is evaluated to create arguments which are substituted into SYNTAX, and then this is unquoted, leading to the evaluation a single instance of SYNTAX as an operator. When SYNTAX is QUOTE, no special exception can be made; ,(quote ,@form) must also mean "zero or more arguments into quote which is then evaled in the next round, possibly leading to a quoting error".

616c 11y ago

You will see that a few people ask: why care in the face of such impressive native code compilers: Steel Bank, Clozure, and Embedded (although maybe ECL is short for something else; ironically they also needed a new maintainer as the previous guy became busy): porting and bootstrapping. https://www.common-lisp.net/~bmastenbrook/new-sbcl/porting.html https://www.common-lisp.net/~bmastenbrook/new-sbcl/porting.h... With CLISP that worked on ARM, I am not sure how much slower it would have been to port SBCL to ARM architectures, which is less <1 year of usable, even though CCL had it for years (and why I started compiling CCL using the AUR mechanism on Arch Linux prior to using SBCL in the official repos, for later playing with RPi stuff). So, thanks for the awesome Lisp, and thanks to you guys specifically because it is niche and thankless with so many jokes about the Lisp/CL community. Even on HN, you can hear the mumbling when people post Lisp articles. (hail (clisp))

jordigh 11y ago
Thanks, I was looking for an excuse to try to help CLisp. This might be it.
- 616c 11y ago
  Cool. And that is coming from me, someone who knows like %1 of anything CL/Lisp related. Unrelated side bar for initiated: is the actual capitalization of this thing (beyond the terminal of course) CLisp or CLISP? http://clisp.org/ http://clisp.org/ So I noticed that the original title of this link (at least when I started reading) was CLisp, and it had not even occurred to me it was C( language) Lisp maybe, but still I though the caps must br wrong. On their site it is full CAPS, even though that peeves a lot of Lispers who will tell you that is like original Lisp Lisps (or LISP Lisp family languages, to be funny). So can someone chime in and tell us?