I've decided that it's time to look at yet another programming
language. ;-)
Is there some place to download the most current version of the Common
Lisp HyperSpec (if its license permits this)?
For practical experiments, I think I need a Common Lisp
implementation, too. For political reasons, the implementation has to
be Free Software, and the license of the run-time library must be
compatible with the GPL.
What about CMUCL? The web pages appear to be unmaintained. Is
the implementation itself still being maintained? It looks more
interesting than GNU CLISP because of its more complete CLOS
implementation, native code compilation, and multi-processing support.
Is there something else I should know? Up to now, I favor statically
typed languages (in particular Ada), and I've got mixed experiences
with dynamically typed ones (especially Python). And my previous
(non-CL) Lisp projects quickly became non-transparent, just after the
first thousand lines.
From: Dr. Edmund Weitz
Subject: Re: Learning Common Lisp
Date:
Message-ID: <667qhme6.fsf@agharta.de>
Florian Weimer <··@deneb.enyo.de> writes:
> I've decided that it's time to look at yet another programming
> language. ;-)
>
> Is there some place to download the most current version of the Common
> Lisp HyperSpec (if its license permits this)?
>
> For practical experiments, I think I need a Common Lisp
> implementation, too. For political reasons, the implementation has to
> be Free Software, and the license of the run-time library must be
> compatible with the GPL.
>
> What about CMUCL? The web pages appear to be unmaintained. Is
> the implementation itself still being maintained? It looks more
> interesting than GNU CLISP because of its more complete CLOS
> implementation, native code compilation, and multi-processing support.
>
> Is there something else I should know? Up to now, I favor statically
> typed languages (in particular Ada), and I've got mixed experiences
> with dynamically typed ones (especially Python). And my previous
> (non-CL) Lisp projects quickly became non-transparent, just after the
> first thousand lines.
See <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html#AEN59> and
<http://groups.google.com/groups?selm=m3y9mzeh2u.fsf%40bird.agharta.de>
for a couple of answers. Also:
1. The 'news' section of the CMUCL website lists some mirrors. The
CMUCL is active, it's just the website that has been partially down
for months now.
2. You can download the CLHS from Xanalys' website, but see
<http://groups.google.com/groups?selm=sfwvgftux7g.fsf%40shell01.TheWorld.com>
on how to get the most current version.
What 'political reasons' prevent you from trying out commercial
versions? I'd say that, e.g., the trial version of LispWorks is MUCH
easier for beginners than CMUCL or CLISP. If you adher to the ANSI
standard, you won't have any problems to transfer your code to an
implementation that fits your 'political needs' should you want to
distribute some software later.
Good luck,
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> 2. You can download the CLHS from Xanalys' website, but see
> <http://groups.google.com/groups?selm=sfwvgftux7g.fsf%40shell01.TheWorld.com>
> on how to get the most current version.
Together with your hyperspec.el version (from
<··············@bird.agharta.de>), this works nicely. Thanks.
> What 'political reasons' prevent you from trying out commercial
> versions?
I've decided not to invest time our money into proprietary software.
Obviously a political decision. ;-)
(Experience shows that I've got the tendency to uncover language
implementation bugs, so there's certainly an amount of work specific
to an implementation involved.)
> I'd say that, e.g., the trial version of LispWorks is MUCH easier
> for beginners than CMUCL or CLISP.
Why do you think so?
Florian Weimer <··@deneb.enyo.de> writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
....
> > I'd say that, e.g., the trial version of LispWorks is MUCH easier
> > for beginners than CMUCL or CLISP.
>
> Why do you think so?
Perhaps because it comes with a ton of interactive browsers (class
browser, object browser, process browser, and several more), a very
nice interactive GUI-based debugger, a fully-integrated Lisp-savvy
editor, a native windowing interface (that happens even to port well
between Unix and Windows), and a very simply designed IDE that is
dead-easy to figure out. It feels, at least to me, like a real,
properly packaged, modern, GUI-based language-product.
I'm not trying to knock clisp as a lisp--it seems very zippy for a
byte compiled implementation, and it's implemented for a number of
systems. But it doesn't come with tons of bells and whistles to
support beginners. There is simply a difference between a "language
implementation" and an "environment", and what LispWorks offers is an
environment (language+gui). If you can't see the difference between
LispWorks and CLISP, you plainly haven't tried LispWorks because it
would be really, really apparent.
(I can't speak to CMUCL; I haven't used it so don't know what it's GUI
status is. I have heard many great things about its compiler, but
again, Dr. Weitz's remarks above are about support for beginners--and
beginners simply don't need a tightly optimized compilation of "hello
world".)
Further, even at the language level, LispWorks is doing substantially
better error diagnostics in my opinion. That's not a fixed property of
clisp and could change over time, but in my experience clisp is not heavy
on helpful diagnostics about unused or misused code. Again, nothing wrong
with that--the language doesn't require it, and implementors have to make
their priorities according to what users need, but still, it does make a
difference.
Kent M Pitman <······@world.std.com> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
>> ···@agharta.de (Dr. Edmund Weitz) writes:
> ....
>> > I'd say that, e.g., the trial version of LispWorks is MUCH easier
>> > for beginners than CMUCL or CLISP.
>>
>> Why do you think so?
>
> Perhaps because it comes with a ton of interactive browsers (class
> browser, object browser, process browser, and several more), a very
> nice interactive GUI-based debugger, a fully-integrated Lisp-savvy
> editor, a native windowing interface (that happens even to port well
> between Unix and Windows), and a very simply designed IDE that is
> dead-easy to figure out.
But I'm not struggling with the IDE, I'm struggling with the language.
I don't think browsers will help me here.
> Further, even at the language level, LispWorks is doing substantially
> better error diagnostics in my opinion.
I tend to agree, without even looking at LispWorks. The error
reporting facilities of both CMUCL and CLISP are abysmal. Unless
there is a hidden switch I missed to enable line number and column
reporting, not only beginners will have a hard time figuring what's
causing these funny error messages. (Although it seems that is a
challenge to generate meaningful diagnostics for Common Lisp code,
even more than with other languages.)
Florian Weimer <··@deneb.enyo.de> writes:
> But I'm not struggling with the IDE, I'm struggling with the language.
> I don't think browsers will help me here.
>
> > Further, even at the language level, LispWorks is doing substantially
> > better error diagnostics in my opinion.
>
> I tend to agree, without even looking at LispWorks. The error
> reporting facilities of both CMUCL and CLISP are abysmal. Unless
> there is a hidden switch I missed to enable line number and column
> reporting, not only beginners will have a hard time figuring what's
> causing these funny error messages. (Although it seems that is a
> challenge to generate meaningful diagnostics for Common Lisp code,
> even more than with other languages.)
This sounds like you're struggling with the environment, to me. CMUCL
has a powerful environment, but it's not obvious how to use it without
reading (and rereading from time to time) the manual.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Florian Weimer <··@deneb.enyo.de> writes:
> I tend to agree, without even looking at LispWorks. The error
> reporting facilities of both CMUCL and CLISP are abysmal. Unless
> there is a hidden switch I missed to enable line number and column
> reporting, not only beginners will have a hard time figuring what's
> causing these funny error messages. (Although it seems that is a
> challenge to generate meaningful diagnostics for Common Lisp code,
> even more than with other languages.)
Line-based error reporting is something that only really works for
static languages.
CMU CL will show you the exact point in the source code where an error
is encountered, even at run-time using the debugger SOURCE and VSOURCE
commands. It also gives you a short summary of the location at the
time it is invoked. Take a look at the CMU CL User's manual for an
overview of the debugger.
The compiler will report errors with surrounding context as well.
While I agree that LispWorks is a much better integrated environment,
I'd hardly consider CMU CL error reporting abysmal.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> Line-based error reporting is something that only really works for
> static languages.
TeX has line-based error reporting (together with traceback
facilities), and it's a dynamic language, at least as far as the
syntax is concerned. ;-)
I agree that such error reports are not always helpful in the way that
they point to the correct location, but I think one could do much
better than just writing the name of the enclosing definition and the
problematic symbol.
> CMU CL will show you the exact point in the source code where an error
> is encountered, even at run-time using the debugger SOURCE and VSOURCE
> commands. It also gives you a short summary of the location at the
> time it is invoked. Take a look at the CMU CL User's manual for an
> overview of the debugger.
Look at the following code, with a rather obvious error:
| (deftype foo ()
| (integer 0 9))
|
| (defun bar (baz)
| (declare (type foo baz))
| baz)
My version of CMUCL (cmucl-3.0.5, part of Debian GNU/Linux) results in
the following output:
| Compiling DEFTYPE FOO:
|
| Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.
|
| Restarts:
| 0: [ABORT] Return to Top-Level.
|
| Debug (type H for help)
|
| (KERNEL:%COERCE-TO-FUNCTION INTEGER)
| Source:
| ; File: target:code/fdefinition.lisp
|
| ; File has been modified since compilation:
| ; target:code/fdefinition.lisp
| ; Using form offset instead of character position.
| (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
Why a call this kind of reporting abysmal? The only context
information presented is "Compiling DEFTYPE FOO", it doesn't tell the
reader exactly where the problem is encountered. I'd prefer to have
something like:
| foo.lisp:2:4: the function INTEGER is undefined
I know it's difficult to implement this, and it probably carries
additional run-time overhead for the general case, but such features
are extremely desirable for beginners and casual users.
> The compiler will report errors with surrounding context as well.
The surrounding compiler context (revealed by inspecting the stack
after the crash) isn't helpful either in this situation.
Florian Weimer <··@deneb.enyo.de> wrote in message news:<··············@deneb.enyo.de>...
>
> Why a call this kind of reporting abysmal? The only context
> information presented is "Compiling DEFTYPE FOO", it doesn't tell the
> reader exactly where the problem is encountered. I'd prefer to have
> something like:
I'm fairly sure that the compiler actually *does* tell you where the
error occurs. It tells you that it occurred compiling DEFTYPE FOO,
and (if you ask it, or possibly by default) it tells you the path down
to where the actual error was, in terms of macros that got expanded
and so on. This is enough information to find the error, either for
you or, more usefully, for the programming environment. I don't know
if ilisp is smart enough to parse the errors and point you at the
appropriate source, but Hemlock definitly was, and the commercial CL
environments still are. If you're really constrained not to use the
environment (which many people are, since they are constrained to not
use commercial systems or hemlock (which may not really work any more,
anyway)) then you either want to get ilisp to be able to understand
this stuff, or be willing to search for '^(deftype.*foo' or whatever.
--tim
Tim wrote:
> I'm fairly sure that the compiler actually *does* tell you where the
> error occurs. It tells you that it occurred compiling DEFTYPE FOO,
> and (if you ask it, or possibly by default) it tells you the path down
> to where the actual error was, in terms of macros that got expanded
> and so on.
In my experience clisp, cmucl, lispworks and allegro all do this.
Although not transparent, this is certainly much less difficult than
on some c/c++ systems that I have tried to debug.
> This is enough information to find the error, either for
> you or, more usefully, for the programming environment. I don't know
> if ilisp is smart enough to parse the errors and point you at the
> appropriate source,
No. Not AFAIK anyway. This is something I would like to add.
:)w
··········@tfeb.org (Tim Bradshaw) writes:
> I don't know if ilisp is smart enough to parse the errors and point
> you at the appropriate source, but Hemlock definitly was, and the
> commercial CL environments still are. If you're really constrained
> not to use the environment (which many people are, since they are
> constrained to not use commercial systems or hemlock (which may not
> really work any more, anyway)) then you either want to get ilisp to
> be able to understand this stuff, or be willing to search for
> '^(deftype.*foo' or whatever.
I'm not sure about the super-recent releases, but Hemlock was working
pretty recently, certainly in the Debian-stable package, and I think
it works in 18c. All the little crappy things in GNU Emacs are
starting to drive me crazy (this happens cyclicly, and is how I
started using Hemlock in the first place), and I'm seriously
considering giving it up for coding purposes, and switching back to
Hemlock. So, if there's any Hemlock bit-rot in the current CMUCL,
I'll probably try to fix it up pretty quickly (unless I resign myself
to Emacs again).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Bradshaw wrote:
> Florian Weimer <··@deneb.enyo.de> wrote in message news:<··············@deneb.enyo.de>...
> >
> > Why a call this kind of reporting abysmal? The only context
> > information presented is "Compiling DEFTYPE FOO", it doesn't tell the
> > reader exactly where the problem is encountered. I'd prefer to have
> > something like:
>
> I'm fairly sure that the compiler actually *does* tell you where the
> error occurs. It tells you that it occurred compiling DEFTYPE FOO,
Ah, you fell into CMU CL's little trap. The error did *not* occur
while compiling DEFTYPE FOO, but while compiling the function BAR.
(Try it: delete the defun and compile-file. No complaints, and a
good thing too.)
And if you ask for a backtrace then it's, ummm, not very
helpful.
I do think Florian has a point here...
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) wrote in message news:<·······························@g.local>...
>
> Ah, you fell into CMU CL's little trap. The error did *not* occur
> while compiling DEFTYPE FOO, but while compiling the function BAR.
> (Try it: delete the defun and compile-file. No complaints, and a
> good thing too.)
>
Yes, I did. But I think my point in general is OK - there may be odd
cases where CMUCL (or other Lisps) report errors really badly, but in
general the information is adequate, even though it is not line/column
based but form-based.
--tim
On Mon, 03 Dec 2001 08:22:58 +0100, Florian Weimer <··@deneb.enyo.de>
wrote:
[about improving error reporting in CMU CL]
> I know it's difficult to implement this, and it probably carries
> additional run-time overhead for the general case, but such features
> are extremely desirable for beginners and casual users.
I guess the usage of most Common Lisp development environments is not
optimized for beginners or casual users. Common Lisp is intended as a
language for developing industrial strength applications.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso <·······@mclink.it> writes:
> I guess the usage of most Common Lisp development environments is not
> optimized for beginners or casual users. Common Lisp is intended as a
> language for developing industrial strength applications.
Hmm, I don't want to develop "industrial strength applications"
(whatever this means; as an industry, the software industry has got a
rather bad reputation). I want to have software that works and which
I can write in a reasonable amount of time. I've got a solution for
the first part, but not yet for the second.
Florian Weimer <··@deneb.enyo.de> writes:
> > CMU CL will show you the exact point in the source code where an error
> > is encountered, even at run-time using the debugger SOURCE and VSOURCE
> > commands. It also gives you a short summary of the location at the
> > time it is invoked. Take a look at the CMU CL User's manual for an
> > overview of the debugger.
>
> Look at the following code, with a rather obvious error:
>
> | (deftype foo ()
> | (integer 0 9))
> |
> | (defun bar (baz)
> | (declare (type foo baz))
> | baz)
Note that the definition of foo isn't erroneous in itself: If you
defined the function integer before the defined type was used, this
would be perfectly valid.
That said, this is also a special case, in that CMU CL doesn't report
the name for DEFTYPE definitions (unlike e.g. DEFMACRO or DEFUN
definitions) in the backtrace:
> | Compiling DEFTYPE FOO:
> |
This is admittedly confusing, because the error doesn't occur in
compiling the deftype form, but _before_ converting the defun form.
Normally the compiler will inform you of the form it is converting and
then compiling, but since the deftype expansion happens very early on
in the process, it seems that we break into the debugger, before we
know what the form is that we want to convert, and hence, are able to
output the infromative line.
> | Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.
> |
> | Restarts:
> | 0: [ABORT] Return to Top-Level.
> |
> | Debug (type H for help)
> |
> | (KERNEL:%COERCE-TO-FUNCTION INTEGER)
> | Source:
> | ; File: target:code/fdefinition.lisp
> |
> | ; File has been modified since compilation:
> | ; target:code/fdefinition.lisp
> | ; Using form offset instead of character position.
> | (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
The next thing to do when encountering such an error, is to print a
backtrace. Sadly, as you note, for this particular error, it isn't as
informative as it could be, because the deftype transformer function
is unnamed:
> > The compiler will report errors with surrounding context as well.
>
> The surrounding compiler context (revealed by inspecting the stack
> after the crash) isn't helpful either in this situation.
0] BACKTRACE
0: (KERNEL:%COERCE-TO-FUNCTION INTEGER)
1: (NIL (FOO))
2: (KERNEL:TYPE-EXPAND FOO)
3: (KERNEL:VALUES-SPECIFIER-TYPE FOO)
4: (KERNEL:SPECIFIER-TYPE FOO)
5: (C::PROCESS-TYPE-DECLARATION (FOO BAZ)
[ ... etc ... ]
0] D
(NIL (FOO))
[ This is your culprit, but alas its name is not displayed ]
1] VSOURCE 10
#'(LAMBDA (#:WHOLE-0)
(BLOCK FOO
(LET* ()
(UNLESS (<= 0 (LENGTH (THE LIST (CDR #:WHOLE-0))) 0)
(COMMON-LISP::DO-ARG-COUNT-ERROR 'DEFTYPE
'FOO
(CDR #:WHOLE-0)
'NIL
0
0))
(LET* ()
(#:***HERE*** (INTEGER 0 9))))))
[ Furthermore the source is only output in expanded form, so this
isn't as informative as well ]
I'll look into improving error reporting for DEFTYPE problems.
That said, for more "normal" errors, the situation shouldn't look
quite as bleak:
(defmacro foo ()
(integer 0 9))
(defun bar (baz)
(foo)
baz)
* (compile-file "demo2.cl")
Python version 1.0, VM version Intel x86 on 04 DEC 01 04:36:23 am.
Compiling: /tmp/demo2.cl 04 DEC 01 04:36:17 am
Converted FOO.
Compiling DEFMACRO FOO:
File: /tmp/demo2.cl
In: DEFUN BAR
(FOO)
Error: (during macroexpansion)
Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.
Converted BAR.
File: /tmp/demo2.cl
In: DEFUN BAR
(DEFUN BAR (BAZ) (FOO) BAZ)
--> BLOCK
==>
BAZ
Note: Deleting unreachable code.
Compiling DEFUN BAR:
Byte Compiling Top-Level Form:
In: LAMBDA (#:WHOLE-0 #:ENV-1)
(INTEGER 0 9)
Warning: Undefined function: INTEGER
File: /tmp/demo2.cl
In: DEFMACRO FOO
(INTEGER 0 9)
Warning: Undefined function: INTEGER
Warning: This function is undefined:
INTEGER
Compilation unit finished.
1 error
3 warnings
1 note
demo2.x86f written.
Compilation finished in 0:00:01.
#p"/tmp/demo2.x86f"
T
T
*
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> That said, for more "normal" errors, the situation shouldn't look
> quite as bleak:
> In: DEFUN BAR
> (FOO)
> Error: (during macroexpansion)
> Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.
I agree, this looks quite helpful. It's a bit funny that I triggered
the DEFTYPE problem, but as I told you, I've got the tendency to
uncover defects in the software I use (and I don't believe in yet).
Florian Weimer <··@deneb.enyo.de> writes:
> > That said, for more "normal" errors, the situation shouldn't look
> > quite as bleak:
>
> > In: DEFUN BAR
> > (FOO)
> > Error: (during macroexpansion)
> > Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.
>
> I agree, this looks quite helpful. It's a bit funny that I triggered
> the DEFTYPE problem, but as I told you, I've got the tendency to
> uncover defects in the software I use (and I don't believe in yet).
Yeah, I know, I've got the same talent. :)
And we're always interested in bug reports, so as Kent suggested,
report any other strange/unhelpful error messages as bugs via the
mailing lists at cons.org.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Florian Weimer <··@deneb.enyo.de> writes:
> not only beginners will have a hard time figuring what's causing
> these funny error messages. (Although it seems that is a challenge
> to generate meaningful diagnostics for Common Lisp code, even more
> than with other languages.)
Would you mind giving us one or two examples of error messages that
are funny and not very meaningful?
Florian Weimer wrote:
> Kent M Pitman <······@world.std.com> writes:
>
>> Florian Weimer <··@deneb.enyo.de> writes:
>>
>>> ···@agharta.de (Dr. Edmund Weitz) writes:
>> ....
>>> > I'd say that, e.g., the trial version of LispWorks is MUCH easier
>>> > for beginners than CMUCL or CLISP.
>>>
>>> Why do you think so?
>>
>> Perhaps because it comes with a ton of interactive browsers (class
>> browser, object browser, process browser, and several more), a very
>> nice interactive GUI-based debugger, a fully-integrated Lisp-savvy
>> editor, a native windowing interface (that happens even to port well
>> between Unix and Windows), and a very simply designed IDE that is
>> dead-easy to figure out.
>
> But I'm not struggling with the IDE, I'm struggling with the language.
> I don't think browsers will help me here.
>
>> Further, even at the language level, LispWorks is doing substantially
>> better error diagnostics in my opinion.
>
> I tend to agree, without even looking at LispWorks. The error
> reporting facilities of both CMUCL and CLISP are abysmal. Unless
> there is a hidden switch I missed to enable line number and column
> reporting, not only beginners will have a hard time figuring what's
> causing these funny error messages. (Although it seems that is a
> challenge to generate meaningful diagnostics for Common Lisp code,
> even more than with other languages.)
Your guessing is right - it is really difficult to provide exact
source-locations in relation to an error in a language that provides
macro-facilities like Lisp. LispWorks provides optional source-level
debugging mode (default is to have it on). The LispWorks graphical
debugger shows you a window with a backtrace of the situation where the
error occured. With source-level debugging enabled you can double-click on
the stack-frame and if that frame has an actual representation the
editor-window pops up with the corresponding expression highlighted.
ciao,
Jochen
--
http://www.dataheaven.de
Florian Weimer <··@deneb.enyo.de> writes:
> But I'm not struggling with the IDE, I'm struggling with the language.
> I don't think browsers will help me here.
I have to agree with Florian here. I just took up Lisp a few weeks
ago, in my spare time. I put LispWorks, ACL, CLISP, and Corman on my
machine (W2K), to see which one I could use while concentrating on the
language itself and learning my way around. I chose CLISP as an
inferior Lisp within Emacs, and the Hyperspec within my browser, side
by side. It's working quite well, and I am seeing only those elements
I want to see: the language and my code (I might have chosen CMUCL,
but AFAIK it is not available on my platform).
I want to learn the basics very well before I move on to the "higher"
concepts. LispWorks and Allegro both look great, and I plan to use one
or the other some day, but I feel they have too much stuff in the way
for a raw beginner like myself. When I become fluent in the language,
I expect that I will find them welcome aids. Right now, Emacs and some
books are more than sufficient for me to use while learning.
--
dave
Florian Weimer <··@deneb.enyo.de> wrote in message news:<··············@deneb.enyo.de>...
> But I'm not struggling with the IDE, I'm struggling with the language.
> I don't think browsers will help me here.
I think they will, because they give you better insight into what is
going on. Being dynamic is very important to Lisp, and one way that
it's dynamic is that you tend to spend a lot of time trying stuff and
seeing what happens rather than the static approach of spending hours
up front typing everything in and then running it all. So things like
class browsers are incredibly useful tools because they let you
actually see what is going on inside the system, similarly GF / method
browsers & so forth. I think this approach to Lisp programming
started with the Lisp machines and continues to this day, and it's a
very powerful one - even if it is not the only one.
> I tend to agree, without even looking at LispWorks. The error
> reporting facilities of both CMUCL and CLISP are abysmal. Unless
> there is a hidden switch I missed to enable line number and column
> reporting, not only beginners will have a hard time figuring what's
> causing these funny error messages. (Although it seems that is a
> challenge to generate meaningful diagnostics for Common Lisp code,
> even more than with other languages.)
Typically line and column information is completely gone by the time
the system actually sees the code. What you do (or can) have is form
information - which form in the source was this bit of object code
associated with? Given editor support like Emacs has this can enable
pretty good source-level debugging. Of course macros can make this
significantly more complex. Note that in an incremental language like
Lisp, line number information is of limited use, as the code can move
around between when it was compiled and when it was run, and this is
*often* the case: much better to record information like definition
and then a path to the form that caused the error inside the
definition. Empirically it turns out that experienced Lisp people
*don't* have a hard time understanding the error messages.
--tim
Florian Weimer <··@deneb.enyo.de> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Florian Weimer <··@deneb.enyo.de> writes:
> >
> >> ···@agharta.de (Dr. Edmund Weitz) writes:
> > ....
> >> > I'd say that, e.g., the trial version of LispWorks is MUCH easier
> >> > for beginners than CMUCL or CLISP.
> >>
> >> Why do you think so?
> >
> > Perhaps because it comes with a ton of interactive browsers (class
> > browser, object browser, process browser, and several more), a very
> > nice interactive GUI-based debugger, a fully-integrated Lisp-savvy
> > editor, a native windowing interface (that happens even to port well
> > between Unix and Windows), and a very simply designed IDE that is
> > dead-easy to figure out.
>
> But I'm not struggling with the IDE, I'm struggling with the language.
> I don't think browsers will help me here.
I didn't make a statement about you personally. You didn't say "I am
a beginner and why do you think this helps me?" to which I would have
said "I haven't a clue what helps you as an individual and I have no
opinion on that". You are just not a statistical sample. Any small
number of users can be an exception to any generalization. However, I
think most people, absent a special passion for open source, which
probably breeds and above-average tolerance for text-based interfaces,
will want something flashier. And I stand by the intent of my
statement, which is that I personaly would not direct someone to the
environment you are talking about.
This is not to disparage text-base interfaces. I use Emacs all the time.
But if someone asks me for a good text editor for Windows, I *know* they
are asking for Word or WordPerfect or FrameMaker or ... and *not* Emacs.
If I try to convince them to use Emacs, it is out of evangelism to a new
religion, not out of responsiveness to their question.
> > Further, even at the language level, LispWorks is doing substantially
> > better error diagnostics in my opinion.
>
> I tend to agree, without even looking at LispWorks. The error
> reporting facilities of both CMUCL and CLISP are abysmal. Unless
> there is a hidden switch I missed to enable line number and column
> reporting, not only beginners will have a hard time figuring what's
> causing these funny error messages. (Although it seems that is a
> challenge to generate meaningful diagnostics for Common Lisp code,
> even more than with other languages.)
CL is not a line oriented language, so I suppose this could be true.
I don't think the "meaningfulness" of a diagnostic is affected by
line-oriented messages, but I suppose the locality could be. It begs
the question of what line number to cite for an error where macros are
involved and/or where code is created by code execution rather than
being found directly in a file. Program-writing programs _have_ no
source line to refer back to.
Nevertheless, I think rather than cast vague aspersions on any
unintelligible error message, nor pretty much any other problem you
see, you should REPORT the problem as if was a bug and hope that it
will be fixed. When people tolerate problems rather than report them
and demand fixes, I pretty much think they themselves create the
environment they live in.
We often talk about the usability of the Lisp Machine systems. One
thing that made that environment great was that people sent LOTS of bug
reports and the community was extraordinarily responsive to what got
reported. When I arrived at Symbolics, someone told me I was expected
as an employee to spend about 10% of my time reporting bugs, that this
was an ordinary expectation of all users. I think it showed in the
quality of the result.
Florian Weimer <··@deneb.enyo.de> writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
>
> > 2. You can download the CLHS from Xanalys' website, but see
> > <http://groups.google.com/groups?selm=sfwvgftux7g.fsf%40shell01.TheWorld.com>
> > on how to get the most current version.
>
> Together with your hyperspec.el version (from
> <··············@bird.agharta.de>), this works nicely. Thanks.
I posted a follow-up with a slightly better version, see
<http://groups.google.com/groups?selm=m38zcncrqf.fsf%40bird.agharta.de>
or <http://weitz.de/files/hyperspec-naggum.el>. (Does the same thing
but doesn't make me blush that much when I look at the code... :)
> > I'd say that, e.g., the trial version of LispWorks is MUCH easier
> > for beginners than CMUCL or CLISP.
>
> Why do you think so?
This was just from my personal experience. I consider myself still to
be a CL newbie and after playing with CLISP, CMUCL and the trial
versions of ACL and LW it looked to me as if LW suited my way of
learning and experimenting best. I especially liked their graphical
debugging and introspection tools and I think it's very well
documented and supported (even if you're only a non-paying user of the
Personal Edition). Your mileage may vary of course.
Best regards,
Edi.
Florian Weimer <··@deneb.enyo.de> writes:
> Is there some place to download the most current version of the Common
> Lisp HyperSpec (if its license permits this)?
As discussed here recently, the newest "editorial version" of the
HyperSpec comes as part of Xanalys LispWorks Personal Edition, which
can be freely downloaded from Xanalys' web-site.
The slightly older editorial version 3 HyperSpec (the only differences
to the newer version are background color, filenames and improved
indexing, AFAIK) can be downloaded seperately from Xanalys' web-site:
http://www.xanalys.com/software_tools/reference/HyperSpec/index.html
Note that the real contents is the same, i.e. the contents should be
textually equivalent to the ANSI Common Lisp standard. FWIW, I still
use Version 3.
> What about CMUCL? The web pages appear to be unmaintained. Is
> the implementation itself still being maintained? It looks more
> interesting than GNU CLISP because of its more complete CLOS
> implementation, native code compilation, and multi-processing support.
While there is currently a slight (technical) lull in the updating of
the web pages, both the web-site, and the implementation are being
maintained regularly. You might want to subscribe to the relevant
mailing lists at cons.org, both for informational purposes, and to get
a gauge on CMU CL related activity.
> Is there something else I should know? Up to now, I favor statically
> typed languages (in particular Ada), and I've got mixed experiences
> with dynamically typed ones (especially Python). And my previous
> (non-CL) Lisp projects quickly became non-transparent, just after the
> first thousand lines.
Common Lisp gives you lots of support in keeping large systems
maintainable (one of its key strengths, IMHO). That said, you will
have to invest some time to learn project management techniques for
CL, which differ somewhat from those of non-similar languages. Sadly
there are no currently available books specifically on those aspects,
so you will have to rely on c.l.l (both archives and current
discussions) to give you guidance.
Of the books that are currently available, I think that The Art of the
Metaobject Protocol by Kiczales, et al, (see below) is one of the best
books to learn about design techniques for non-trivial object-oriented
systems. To quote from an earlier news posting by myself
(msgid:<··············@orion.bln.pmsf.de>):
> You might want to get both of the following books, the first of which
> gives a very thorough introduction to CLOS (including some non-trivial
> usage techniques), and the second describes the Metaobject Protocol,
> which is a layered de-facto standard for a reflective substrate upon
> which CLOS is built, which is itself implemented in CLOS, and hence
> contains many non-trivial real-world implementation techniques:
>
> * Keene, Sonya E.: Object Oriented Programming in Common Lisp
> - A Programmers Guide to the Common Lisp Object System
> http://www.amazon.com/exec/obidos/ASIN/0201175894/
> http://www.amazon.de/exec/obidos/ASIN/0201175894/
>
> * Kiczales, Gregor et al: The Art of the Metaobject Protocol
> http://www.amazon.com/exec/obidos/ASIN/0262610744/
> http://www.amazon.de/exec/obidos/ASIN/0262610744/
>
> [Note that the links to Amazon.com are purely for reference purposes,
> and are neither an endorsement of Amazon.com, nor are they part of
> any partner-program, hence I don't profit from books purchased
> through them.]
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> Sadly there are no currently available books specifically on those
> aspects, so you will have to rely on c.l.l (both archives and
> current discussions) to give you guidance.
Hmm, I've got rather strange views on the software development
process, so not being able to read a book on this subject is probably
not such a big problem. ;-)
> Of the books that are currently available, I think that The Art of the
> Metaobject Protocol by Kiczales, et al, (see below) is one of the best
> books to learn about design techniques for non-trivial object-oriented
> systems.
Hmm, I'm not interested in OOP per se (my CLOS reference was perhaps a
bit misleading). My main interest in Common Lisp is the expectation
that it is rather straightforward to write parsers and transformers
for little and not-so-little domain-specific languages.
Florian Weimer <··@deneb.enyo.de> writes:
...
> Hmm, I'm not interested in OOP per se (my CLOS reference was perhaps a
> bit misleading). My main interest in Common Lisp is the expectation
> that it is rather straightforward to write parsers and transformers
> for little and not-so-little domain-specific languages.
There is one thing that is worth noting. Common Lisp makes it easy to
"define" little languages for which the parser is the Common Lisp
system itself. If you define a little language irrespective of the
Common Lisp system you are in no beteer shape than using Perl or other
stuff. The grat advantage of Common Lisp (and other Lisps as well) is
that if you use the system, you can avoid worrying about parsing
altogether.
E.g. I recently bumped into a nice Elisp package `else-mode'. The
author (who did know Common Lisp, or the ELisp CL package) went all
the way to define a "line based" tiny configuration language, plus a parser
for it implemented in ELisp.
All of this (I mean *all*) could have been defined with a single
DEFMACRO.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
>> Hmm, I'm not interested in OOP per se (my CLOS reference was perhaps a
>> bit misleading). My main interest in Common Lisp is the expectation
>> that it is rather straightforward to write parsers and transformers
>> for little and not-so-little domain-specific languages.
> There is one thing that is worth noting. Common Lisp makes it easy to
> "define" little languages for which the parser is the Common Lisp
> system itself. If you define a little language irrespective of the
> Common Lisp system you are in no beteer shape than using Perl or other
> stuff. The grat advantage of Common Lisp (and other Lisps as well) is
> that if you use the system, you can avoid worrying about parsing
> altogether.
Can someone provide patterns/hint/pointers on
how to implement parsers and transformers of domain-specific languages?
For now, I've found "Pragmatic Parsing in Common Lisp" paper only.
--
Unix and C are the ultimate computer viruses.
Max Ischenko <···@malva.com.ua> writes:
> Marco Antoniotti wrote:
>
>
> >> Hmm, I'm not interested in OOP per se (my CLOS reference was perhaps a
> >> bit misleading). My main interest in Common Lisp is the expectation
> >> that it is rather straightforward to write parsers and transformers
> >> for little and not-so-little domain-specific languages.
>
> > There is one thing that is worth noting. Common Lisp makes it easy to
> > "define" little languages for which the parser is the Common Lisp
> > system itself. If you define a little language irrespective of the
> > Common Lisp system you are in no beteer shape than using Perl or other
> > stuff. The grat advantage of Common Lisp (and other Lisps as well) is
> > that if you use the system, you can avoid worrying about parsing
> > altogether.
>
> Can someone provide patterns/hint/pointers on
> how to implement parsers and transformers of domain-specific
> languages?
If your domain specific language looks like
(defhybrid automobile (vehicle)
((v :accessor v :direction :output)
(p :accessor pos :direction :output :intial-value #L(45 23))
(a :accessor acceleration :direction :in-out :initial-value 0)
(state :accessor state
:direction :output
:initial-value 'steady
:type (member steady accelerating decelerating))
)
(:equations
(= (d v t) (* a t))
(= (d p t) (* v t)))
(:behavior
(loop (parallel (case-when
((= a 0) (sustain state 'steady))
((minusp a) (sustain state 'decelerating))
((plusp a) (sustain state 'accelerating)))))))
then "parsing" in CL just requires the definition of a macro DEFHYBRID
and a set of functions manipulating the sub S-exprs (which constitute
a sort of AST. (For those interested, the above is a mixture of
Esterel - with its synchronous semantics - <http://www.esterel.org>
and something like SHIFT, <http://www.path.berkeley.edu/shift>)
In any other case, you need to define you regular (augmented) CFG
grammar and construct a viable lexer + parser. It is true that some
of this things are relatively easy, but not that much.
> For now, I've found "Pragmatic Parsing in Common Lisp" paper only.
This paper solves the C/YACC/Perl/etc problem. You are given (have
defined) a language and you need to parse it.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
>> > stuff. The grat advantage of Common Lisp (and other Lisps as well) is
>> > that if you use the system, you can avoid worrying about parsing
>> > altogether.
>>
>> Can someone provide patterns/hint/pointers on
>> how to implement parsers and transformers of domain-specific
>> languages?
> If your domain specific language looks like
> (defhybrid automobile (vehicle)
;skipped, thanks for example.
> ((plusp a) (sustain state 'accelerating)))))))
> then "parsing" in CL just requires the definition of a macro DEFHYBRID
> and a set of functions manipulating the sub S-exprs (which constitute
> a sort of AST. (For those interested, the above is a mixture of
> Esterel - with its synchronous semantics - <http://www.esterel.org>
> and something like SHIFT, <http://www.path.berkeley.edu/shift>)
> In any other case, you need to define you regular (augmented) CFG
> grammar and construct a viable lexer + parser. It is true that some
> of this things are relatively easy, but not that much.
Now I seems to understand what you (and others) have meant. Thanks.
>> For now, I've found "Pragmatic Parsing in Common Lisp" paper only.
> This paper solves the C/YACC/Perl/etc problem. You are given (have
> defined) a language and you need to parse it.
Yes, that is my case.
--
BOFH excuse #373:
Suspicious pointer corrupted virtual machine
Florian Weimer wrote:
> I've decided that it's time to look at yet another programming
> language. ;-)
It's always time to look at yet another programming
language. (Some people would add "... until you've
learned Common Lisp".)
> For practical experiments, I think I need a Common Lisp
> implementation, too. For political reasons, the implementation has to
> be Free Software, and the license of the run-time library must be
> compatible with the GPL.
>
> What about CMUCL? The web pages appear to be unmaintained. Is
> the implementation itself still being maintained? It looks more
> interesting than GNU CLISP because of its more complete CLOS
> implementation, native code compilation, and multi-processing support.
If you're just learning, either will do you fine. But CLISP
may give you an unbalanced idea of what works fast and what
doesn't in a typical Lisp implementation, since "native"
stuff will be much faster than anything you can write in
Lisp. It's by no means unbearably slow, though; if you can
put up with Python, for instance, you should be pretty
content with CLISP's speed.
The deficiencies of CLISP's CLOS aren't likely to bother you
for at least a while.
CMU CL is actively developed, though there hasn't been a
release for quite some time. (If any CMU CL developers
are reading this: Surely there has been enough improvement
since 18c for it to be worth considering a new release?)
It has an extremely good compiler.
I think the CLOS implementations in the commercial CLs
are more polished than those in either CMU CL or CLISP.
On the other hand, CMU CL's type inference is excellent
and its handling of floating-point stuff is second to
none; and CLISP's bignum implementation (based on GMP)
is very impressive.
> Is there something else I should know? Up to now, I favor statically
> typed languages (in particular Ada), and I've got mixed experiences
> with dynamically typed ones (especially Python). And my previous
> (non-CL) Lisp projects quickly became non-transparent, just after the
> first thousand lines.
If the Lisp in question was either emacs lisp or Scheme,
then you probably shouldn't extrapolate. CL is a very
different language from either of those. (Still more so
if the Lisp in question was Autolisp, I think.)
As to other things you should know... I recommend that you
learn to use ILISP (an emacs package for interacting with
Lisp systems) in parallel with learning CL.
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> (If any CMU CL developers are reading this: Surely there has been
> enough improvement since 18c for it to be worth considering a new
> release?)
Good timing. There's just been a flurry of discussion about a new
release on the cmucl-imp list today. And just in time, too, because
I've managed to hose my installation that I keep somewhat-in-sync with
the development sources (eg, DISASSEMBLE crashes just after the
arg-parsing-point. I'm pretty sure it's something stupid I've done,
but I haven't tracked it down, partly because I find it easier to read
Sparc assembler, so I just use DISASSEMBLE on 18c on a Sparc :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ················@pobox.com (Gareth McCaughan) writes:
>
> > (If any CMU CL developers are reading this: Surely there has been
> > enough improvement since 18c for it to be worth considering a new
> > release?)
>
> Good timing. There's just been a flurry of discussion about a new
> release on the cmucl-imp list today. And just in time, too, because
To be brutally honest, that wasn't a total coincidence. I'd been
procrastinating about starting the release discussion, and Gareth's
message was just enough to push me over the brink... ;)
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ················@pobox.com (Gareth McCaughan) writes:
> >
> > > (If any CMU CL developers are reading this: Surely there has been
> > > enough improvement since 18c for it to be worth considering a new
> > > release?)
> >
> > Good timing. There's just been a flurry of discussion about a new
> > release on the cmucl-imp list today. And just in time, too, because
>
> To be brutally honest, that wasn't a total coincidence. I'd been
> procrastinating about starting the release discussion, and Gareth's
> message was just enough to push me over the brink... ;)
Oops, I even checked the timestamps on the news posting and e-mail, to
see which came first. I guess that effort was wasted since I misread
them...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas Burdick wrote:
> ················@pobox.com (Gareth McCaughan) writes:
>
> > (If any CMU CL developers are reading this: Surely there has been
> > enough improvement since 18c for it to be worth considering a new
> > release?)
>
> Good timing. There's just been a flurry of discussion about a new
> release on the cmucl-imp list today.
Cool.
Um. Perhaps now is therefore a bad time to mention a bug
I found a couple of days ago and have been too disorganized
to report properly.
On my machine (Athlon, FreeBSD, plenty of memory), CMU CL 18c
chokes when it tries to compile the following:
(defun f (n)
(declare (fixnum n))
(expt 2.0 n))
Deleting the declaration or replacing "2.0" with "1.0" or "2"
makes it compile without complaints.
When asked to compile the code as it stands (type it in,
and then say "(compile 'f)"), what it says is this:
| * (compile 'f)
| Compiling LAMBDA (N):
| Arithmetic error X86::FLOATING-POINT-EXCEPTION signalled.
| Trapping conditions are:
| :OVERFLOW :INVALID :DIVIDE-BY-ZERO
|
| Restarts:
| 0: [ABORT] Return to Top-Level.
|
| Debug (type H for help)
|
| (X86:SIGFPE-HANDLER #<unavailable-arg>
| #<unavailable-arg>
| #.(SYSTEM:INT-SAP #x47FFF838))
followed by the usual debugger prompt. The same happens
if I put the code in a file and COMPILE-FILE it.
--
Gareth McCaughan ················@pobox.com
.sig under construc
>>>>> "Gareth" == Gareth McCaughan <················@pobox.com> writes:
Gareth> On my machine (Athlon, FreeBSD, plenty of memory), CMU CL 18c
Gareth> chokes when it tries to compile the following:
Gareth> (defun f (n)
Gareth> (declare (fixnum n))
Gareth> (expt 2.0 n))
Gareth> Deleting the declaration or replacing "2.0" with "1.0" or "2"
Gareth> makes it compile without complaints.
Gareth> When asked to compile the code as it stands (type it in,
Gareth> and then say "(compile 'f)"), what it says is this:
Gareth> | * (compile 'f)
Gareth> | Compiling LAMBDA (N):
Gareth> | Arithmetic error X86::FLOATING-POINT-EXCEPTION signalled.
Gareth> | Trapping conditions are:
Gareth> | :OVERFLOW :INVALID :DIVIDE-BY-ZERO
Gareth> |
Gareth> | Restarts:
Gareth> | 0: [ABORT] Return to Top-Level.
Gareth> |
Gareth> | Debug (type H for help)
Gareth> |
Gareth> | (X86:SIGFPE-HANDLER #<unavailable-arg>
Gareth> | #<unavailable-arg>
Gareth> | #.(SYSTEM:INT-SAP #x47FFF838))
This definitely doesn't happen on my x86 build using sources from June
or so of this year.
I don't have an x86 18c version available right now, but I think this
bug is caused by the compiler trying to derive the type of the result
of (expt 2.0 n) for n a fixnum, which causes an overflow to happen in
the computation which wasn't properly caught. Replacing 2.0 with 1.0
doesn't cause an overflow and replacing 2.0 with 2 doesn't use the
floating-point unit to do the computation.
This bug caused errors in really weird places and equally bizarre
backtraces because on the x86, floating-point exceptions are not
signalled until the *NEXT* floating-point instruction, which could be
anywhere.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Gareth" == Gareth McCaughan <················@pobox.com> writes:
>
> Gareth> On my machine (Athlon, FreeBSD, plenty of memory), CMU CL 18c
> Gareth> chokes when it tries to compile the following:
>
> Gareth> (defun f (n)
> Gareth> (declare (fixnum n))
> Gareth> (expt 2.0 n))
> This definitely doesn't happen on my x86 build using sources from June
> or so of this year.
I tested the example code on the official 18c release binaries for
Linux (with AMD K6-2 CTX), and I don't see any problems. And it
works with the FreeBSD binaries (dated from 2001.09.24) installed on
the cons.org machine.
However the original 18c binaries for FreeBSD do give me the problems
that Gareth describes. So this seems 18c+FreeBSD specific, and should
be fixed in current binaries, it seems.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre Mai wrote:
[I mentioned a compiler bug in CMU CL 18c on FreeBSD]
> I tested the example code on the official 18c release binaries for
> Linux (with AMD K6-2 CTX), and I don't see any problems. And it
> works with the FreeBSD binaries (dated from 2001.09.24) installed on
> the cons.org machine.
>
> However the original 18c binaries for FreeBSD do give me the problems
> that Gareth describes. So this seems 18c+FreeBSD specific, and should
> be fixed in current binaries, it seems.
Excellent!
--
Gareth McCaughan ················@pobox.com
.sig under construc