Subject: Re: Hello / CLISP flying into outer space ? :-)

From: [email-masked] (Erann Gat)
Date: Thu, 20 Jul 95 09:34:56 PDT

>Maybe reliability is more an issue than speed.

This is true, although to be honest the actual reason we are using
CLisp for prototyping is that I learned about CLisp before learning
about GCL and ECL.  If I had it to do over again I would probably
use ECL because it has threads (assuming I could get the threads to
work -- so far I haven't been able to :-)

>Just imagine the embarassement if the software dumps core while
>running for real in outer space...

Actually, that's not necessarily a fatal problem.  By using a watchdog
timer the system can be made to automatically reboot if it hangs.

The main obstacle to actually flying CLisp is that the source code
is just so *huge*, and has so many nested ifdefs that it's nearly
impossible to figure out what is going on.  The V&V (verification and
validation) people are going to go seriously nonlinear when they see it.

E.

---

From: Marcus Daniels <[email-masked]>
Date: Thu, 20 Jul 1995 21:11:50 GMT

>>>>> "Erann" == Erann Gat <[email-masked]> writes:

Bruno> Maybe reliability is more an issue than speed.

Yeah, I've got some features I've been subconciously avoiding.  On
IRIX 5.3 I've had problems with hash-tables of compiled-closures
(after hours of runtime). On NEXTSTEP m68k, I've had crashes with
various "big things" like multimegabyte bit vectors and
hash-tables. This last one (m68k) seems to be specific to generational
GC.  I can't remember a crash on Linux that didn't turn out to be
either Linux mmap bugs or C compiler bugs.  I can't remember any
non-generational-GC CLISP/Linux crashes at all.

With CMU-CL on IRIX 5.3, without optimization.. for that matter
without compiling. I've found crashes are more frequent than with any
configuration of CLISP I've used.

Bruno> Just imagine the embarassement if the software dumps core while
Bruno> running for real in outer space...

Erann> Actually, that's not necessarily a fatal problem.  By using a
Erann> watchdog timer the system can be made to automatically reboot
Erann> if it hangs.

Check out some space shuttle television coverage!  NASA has got great
catch-phrases like "power cycle the persistent copy telecommunications
system" (translation: flip the power switch on the fax machine).

But seriously, you could install a core-dump handler to also write
.mem files.  And/or always run the system under a GDB debugging stub
(something I should get in the habit of doing).

Erann> The main obstacle to actually flying CLisp is that the source
Erann> code is just so *huge*, and has so many nested ifdefs that it's
Erann> nearly impossible to figure out what is going on.  The V&V
Erann> (verification and validation) people are going to go seriously
Erann> nonlinear when they see it.

One could write a batch program to unifdef the sources (per
specified platform), and build a "CLISP-lite".
Such a tool might be helpful for people doing new ports.

---

From: Raymond Toy <[email-masked]>
Date: Thu, 20 Jul 1995 17:57:16 -0400

>>>>> "Marcus" == Marcus Daniels <[email-masked]> writes:

    Marcus> One could write a batch program to unifdef the sources
    Marcus> (per specified platform), and build a "CLISP-lite".  Such
    Marcus> a tool might be helpful for people doing new ports.

A bit off-topic, but for me, the best thing for porting would be if
the comments in the code were in English---I haven't learned to
read German yet. :-)

But seriously, I had thought about making a few changes to clisp like
putting in the XP pretty printer, and making type contagion work ala
Steele, but I stopped because I couldn't read the comments.  Of
course, that's my problem, not yours.

In any case, clisp has been a wonderful lisp.  It's never crashed on
me, and it's reasonably fast for what I want.  (It was even faster
than CMULISP with proper declarations for some bignum work I was
doing.  Numeric work is only marginally slower than CMULISP unless I
painstakingly add all the appropriate declarations, in which case
CMULISP becomes faster.)

Ray

---

From: Marcus Daniels <[email-masked]>
Date: Thu, 20 Jul 1995 22:40:15 GMT

>>>>> "RT" == Raymond Toy <[email-masked]> writes:

RT> A bit off-topic, but for me, the best thing for porting would be
RT> if the comments in the code were in English---I haven't learned to
RT> read German yet. :-)

A bit further off topic, I've been working on adding support for GNU
gettext.  The package has a fairly impressive Emacs mode called
`po-mode'.  It shows you translation strings in parallel with the
"original" text (of course, CLISP has three sets of "original"
strings).

I've already had to modify the preprocessing program (comment5) to
expand special comments, for the sake of non-gettext configurations.
So, it seems possible to manually go through the sources, tagging
textual comments, so that xgettext could add them to the po files.
Then one day a German "translation team" with time on their hands
(heh, right!!!) could translate CLISP's comments to other
languages.

The result would be that in Emacs a CLISP developer editing a CLISP source
file could have a window showing translations for all comments and
message strings in their mother tongue.