I used Lisp in my university studies and for the first 3 or 4 years of my
career. At one point I had dedicated use of a brand new Symbolics 3600
(I think that was the model number, it was a long time ago now). I'm only
realising in hindsight how lucky I was. I moved out of technical work, and
hence away from Lisp, about 15 years ago now. I never really lost my passion
for Artificial Intelligence and decided recently to start exploring the
subject
again, hence my return to Lisp. I have a few questions that I hope some
folks here can help me with (I have read the FAQs and done Deja searches
I promise!). Maybe first I'll share my thoughts and experiences to date, in
case there are others with similar requirements to me. My questions are in
the
numbered list at the end of this post.
Sorry if this blows my credibility with many of you, but I use MS Windows
perfectly happily for everything I do with my computer up to now, so I've
been looking (ideally) for an implementation on Windows 98. I downloaded
LispWorks Personal Edition, Allegro CL 6.0 and Corman Lisp 1.4.1. My
favorite is LispWorks. The limitation on heapsize is a big drawback, but
if I find over the next few months that I am spending enough time on my
tinkering to justify it then I may be prepared to pay for the Professional
Edition
which would remove this limitation (but I have a question on that below).
All the implementations have things to commend them, but one thing I was
surprised at after returning to Lisp after 15 years was how far behind other
languages (e.g. C++/Java) it has fallen as far as the graphical IDE is
concerned.
Please don't get me wrong, I'm not looking to start a flame-war here, and I
am
firmly on the side of Lisp (with a true passion, it was an integral part of
my first
contact with AI and still my first-love). This observation is offered as an
outsider
who really does care about the future of Lisp. The trace, break and step
functions
in all these implementations are (as far as I could tell) not really
integrated with
the IDEs to any extent (i.e. the ability to visually see in the editor where
you have
breakpoints set, to drop in and out of the stepper easily, to see where you
are in
stepping through the code with reference to the souce code in an editor
buffer,
and the ability to set watchpoints on variables). I appreciate that the
nature of Lisp
facilitates the testing of individual functions easily without the hassle of
writing
test harnesses and so by better validating individual components there
should
be fewer errors, but we all know that sometimes all else fails and one finds
oneself in the depths or detailed debugging. At this stage it is good to
have the
best possible tools. At the time I left Lisp there were a number of factors
cited as to why it was a good language for complex AI problems. The
characteristics of the language itself remain, but the equally oft-cited
benefit at
the time was that the major Lisp environments offered state of the art IDEs
that other languages at the time couldn't match. Sadly I feel this is no
longer true
and that Lisp has been left behind here (but it wouldn't be that hard to
catch up).
Go, go, go!!
As for my impressions of the implementations I downloaded, I found the IDEs
in ACL and LispWorks are much richer than Corman Lisp, but then these
products are a lot more expensive if you want to pay money to get an
un-restricted
version (well, I know LispWorks is. I haven't checked prices for ACL 6.0 but
a
few posts on this newsgroup seemed to imply that it was more expensive than
LispWorks). I'd be interested in the ACL price for personal use if anyone
wants to
share it. Between ACL and LispWorks, I found the graphical debugging tools
just
slightly better in ACL 6.0 (there are some nice features around trace that
LispWorks
doesn't have) but I thought that the integration of LispWorks with the MS
Windows
environment was nicer; I just prefer the feel of it. It's the little things
like being able
to "Control-X Control-F" from the editor or listener to edit a file and the
fact that
the individual windows within a LispWorks session each appear on the Windows
taskbar instead of them running under a single (optionally) hidden
background
window as they do for ACL 6.0. It just makes the computer feel to me a bit
more
like a built-for-purpose Lisp machine rather than a Windows PC running a
Lisp
development environment. It's a very personal and subjective thing I know,
but
enough to swing me towards LispWorks.
Now to my questions. I realise most of them should be directed to Xanalys
but I thought the answers might be of interest to people here so I thought
I'd
give Xanalys (and others) the opportunity to post responses.
1) I downloaded mostly Windows implementations, but did also download
CMU CL just to see if it's IDE was significantly better than the Windows
ones. Although I don't want to go the Linux route (it's just the
hassle of having to dual boot my machine) I may consider it if a Linux
implementation was significantly better than the Windows ones wrt to
IDE issues I mentioned above. Is this the case? If so, what is the best
implementation on Linux as far as graphical debug facilities are
concerned?
2) What is the heap limit with LispWorks Professional Edition? Is it 32 bit
pointer addressing (i.e. 4GB)? Are type bits kept in the least
significant
bits of the data items (as in Corman Lisp) so that the address range is
maintained at a full 32 bits? Is it fully virtual-memory capable on
Windows?
3) When the heap size limit on Personal Edition is reached, does LispWorks
exit without warning? I seem to remember reading this somewhere but
can't seem to find it again. I have certainly experienced a sudden and
silent exit from the system in the middle of trying to compile and load
a
large system (SNePS). Has anyone run this successfully on LispWorks
Professional Edition? I realise it's a lot to ask from Personal Edition
to
run this.
4) Here's a tricky one. Has anyone been able to persuade a vendor to sell
them the commercial product at educational price on the basis that it is
purely for home/hobby use? This doesn't seem unreasonable to me, but
I realise how difficult this would be for the vendors to police. It's
easy
to prove an order comes from an educational establishment but pretty
much impossible to prove it is for home/hobby use. Still, it's worth
asking
I suppose. If anyone from Xanalys is listening, I'd be very happy to not
have the application delivery tools in return for paying a reduced
price. I
realise that the Personal Edition is supposed to be the home
learning/hobby
system, but the heapsize limitations are a problem. I can see a market
for a version that did cost money but was targetted at home users not
commercial developers, and sat somewhere in-between the Personal
and Professional Editions in terms of functionality and price, but maybe
I'm talking about a market of one (me) here. I'd be interested in other
people's comments. Are there many others on this newsgroup who aren't
using Lisp professionally or as part of their studies, but in a hobby
capacity?
5) What is the support policy for LispWorks Professional Edition? Is there
a seperate maintenance contract? Does this entitle the customer to new
releases during the term of the contract? Does this include
functionality
releases (e.g. 4.1.19 to 5.0 as an extreme and I assume ficticious
example) as well as just maintenance releases? What is the cost of
maintenance?
6) As far as I can tell, a user of Personal Edition can't get access to any
patches. The pre-patched 4.1.19 image is for Professional Edition so it
asks for a registration number on startup (and it doesn't take all 0s or
all
9s ;). Also (load-all-patches) isn't available in Personal Edition so
downloading the individual patches seems pointless. Am I missing
something?
Finally, I did voice my concerns to Xanalys (ex Harlequin) support regarding
graphical debugging features. As a free-loader using their un-supported
Personal Edition I felt a bit guilty about raising a support ticket, but I
got a
pretty reasonable response back. The issue has been raised by others (no big
surprise there, but I'm glad to hear it none the less). The support person
also
made reference to the next LispWorks release so I guess this should be of
some encouragement to those people I saw posting concerns about the future
development of LispWorks a while back. I'm sure it's always a case of "never
enough" in terms of new feature releases, but there do seem to be things
happening. Is anyone at Xanalys ready to share any info on the next release
yet
(new features & release date)?
Julian.
[ Remove numbers to form valid email reply address. ]
"Julian" <······@123lomberg456.net> writes:
> I used Lisp in my university studies and for the first 3 or 4 years of my
> career. At one point I had dedicated use of a brand new Symbolics 3600
> (I think that was the model number, it was a long time ago now). I'm only
> realising in hindsight how lucky I was. I moved out of technical work, and
> hence away from Lisp, about 15 years ago now. I never really lost my passion
> for Artificial Intelligence and decided recently to start exploring the
> subject
> again, hence my return to Lisp. I have a few questions that I hope some
> folks here can help me with (I have read the FAQs and done Deja searches
> I promise!). Maybe first I'll share my thoughts and experiences to date, in
> case there are others with similar requirements to me. My questions are in
> the
> numbered list at the end of this post.
Wow a very long post ;-) I guess I'm not able to answer all the
questions. So maybe jus some remarks.
>
> Sorry if this blows my credibility with many of you, but I use MS Windows
> perfectly happily for everything I do with my computer up to now, so I've
> been looking (ideally) for an implementation on Windows 98.
If you like and are happy with Windows who am I to critizise you on
that?
>
> All the implementations have things to commend them, but one thing I was
> surprised at after returning to Lisp after 15 years was how far behind other
> languages (e.g. C++/Java) it has fallen as far as the graphical IDE is
> concerned.
Now I guess my "background" is a bit different. I'm using LispWors
Professional on Linux and IMHO the IDE of it is much better than
anything else I encountered (besides the fact that I can use (X)Emacs
;-)
What points are you missing?
A drawback I encountered recently is that I do not find a way to use
the services of the Editor elsewhere. I do not find out how to
communicate with the Editor. Therefor a Lisp/Emacs combinations seems
more useful.
> Please don't get me wrong, I'm not looking to start a flame-war here, and I
> am
> firmly on the side of Lisp (with a true passion, it was an integral part of
> my first
> contact with AI and still my first-love). This observation is offered as an
> outsider
> who really does care about the future of Lisp. The trace, break and step
> functions
> in all these implementations are (as far as I could tell) not really
> integrated with
> the IDEs to any extent (i.e. the ability to visually see in the editor where
> you have
> breakpoints set, to drop in and out of the stepper easily, to see where you
> are in
> stepping through the code with reference to the souce code in an editor
> buffer,
> and the ability to set watchpoints on variables).
I can't confirm that. There is usually a way doing it. So you may
point out what your problems are.
>I appreciate that the
> nature of Lisp
> facilitates the testing of individual functions easily without the hassle of
> writing
> test harnesses and so by better validating individual components there
> should
> be fewer errors, but we all know that sometimes all else fails and one finds
> oneself in the depths or detailed debugging. At this stage it is good to
> have the
> best possible tools.
The opinions about the usefulness of the debugger seem not to be so
clear cut. If I look into The Practice of Programming than I can see
an opinion of an hacker saying. Think about it and add some "print"
statements. Now that is one opinion there are others, again you should
probaly point out when you needed the Debugger and what you we're
missing.
>At the time I left Lisp there were a number of factors
> cited as to why it was a good language for complex AI problems. The
> characteristics of the language itself remain, but the equally oft-cited
> benefit at
> the time was that the major Lisp environments offered state of the art IDEs
> that other languages at the time couldn't match. Sadly I feel this is no
> longer true
> and that Lisp has been left behind here (but it wouldn't be that hard to
> catch up).
My experience is different. Lisp itself is very useful and does not
come in you way. You don't have any problems to add a format form
anywhere. Which does not work e.g in Haskell, if you are considering
Lisp bad in this area don't try Haskelle (or put it the other way: Try
Haskell and you'll see how nice Lisp is ;-)
>
> Now to my questions. I realise most of them should be directed to Xanalys
> but I thought the answers might be of interest to people here so I thought
> I'd
> give Xanalys (and others) the opportunity to post responses.
>
> 1) I downloaded mostly Windows implementations, but did also download
> CMU CL just to see if it's IDE was significantly better than the Windows
> ones. Although I don't want to go the Linux route (it's just the
> hassle of having to dual boot my machine) I may consider it if a Linux
> implementation was significantly better than the Windows ones wrt to
> IDE issues I mentioned above. Is this the case? If so, what is the best
> implementation on Linux as far as graphical debug facilities are
> concerned?
Now I'm quite happy with LispWorks. I'm sure I would be as happy with
ACL but the price just for trying is (at least for me) to
redicoulous. I bouth LispWorks Professional after they dropped the
price significantly. Anyway a lot of people consider around $750 to be
too high. I obviously disagree.
>
> 2) What is the heap limit with LispWorks Professional Edition? Is it 32 bit
> pointer addressing (i.e. 4GB)? Are type bits kept in the least
> significant
> bits of the data items (as in Corman Lisp) so that the address range is
> maintained at a full 32 bits? Is it fully virtual-memory capable on
> Windows?
If found another build in Limit which was not pointed out the Stack
Size is limited and you have yourself with using some "other
facilities"
>
> 4) Here's a tricky one. Has anyone been able to persuade a vendor to sell
> them the commercial product at educational price on the basis that it is
> purely for home/hobby use? This doesn't seem unreasonable to me, but
> I realise how difficult this would be for the vendors to police. It's
> easy
> to prove an order comes from an educational establishment but pretty
> much impossible to prove it is for home/hobby use.
This is a real problem IMHO. I asked the same question 2 years or so
ago and to that time the anser was unsatisfying. So I did not buy
the software to that time. I can accept the price tag from LispWorks
and am quite a happy usef of LispWorks
>Still, it's worth
> asking
> I suppose. If anyone from Xanalys is listening, I'd be very happy to not
> have the application delivery tools in return for paying a reduced
> price. I
> realise that the Personal Edition is supposed to be the home
> learning/hobby
> system, but the heapsize limitations are a problem.
Why?
>I can see a market
> for a version that did cost money but was targetted at home users not
> commercial developers, and sat somewhere in-between the Personal
> and Professional Editions in terms of functionality and price, but maybe
> I'm talking about a market of one (me) here. I'd be interested in other
> people's comments. Are there many others on this newsgroup who aren't
> using Lisp professionally or as part of their studies, but in a hobby
> capacity?
Good points, I agree. I would like to see such a thing but again
where's the limit?
>
> 5) What is the support policy for LispWorks Professional Edition? Is there
> a seperate maintenance contract? Does this entitle the customer to new
> releases during the term of the contract? Does this include
> functionality
> releases (e.g. 4.1.19 to 5.0 as an extreme and I assume ficticious
> example) as well as just maintenance releases? What is the cost of
> maintenance?
I think you better ask Xanalys directly. Till now my mails to the
support were answered and I could apply the last patches but that seem
to be a "minor" update. I can't tell what a "major" update means.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> A drawback I encountered recently is that I do not find a way to use
> the services of the Editor elsewhere. I do not find out how to
> communicate with the Editor. Therefor a Lisp/Emacs combinations seems
> more useful.
Definitely one of the things Xanalys could do to make their already
excellent product better would be either including the source of the
editor with their Professional version, or documenting better how to
extend it. Their are some weird inconsistencies there that get
annoying. For instance, if you INSPECT a listener object, you see that
it uses an editor widget object but stuff like (editor:bind-key
"Indent New Line" #\control-\j) doesn't work on the listener.
> The opinions about the usefulness of the debugger seem not to be so
> clear cut. If I look into The Practice of Programming than I can see
> an opinion of an hacker saying. Think about it and add some "print"
> statements. Now that is one opinion there are others, again you should
> probaly point out when you needed the Debugger and what you we're
> missing.
Especially in CL there are usually better ways of doing things than
Unix/C like debuggers. If you suspect a certain function to disobey
its contract an ADVISE :around it that checks relations between
arguments and results if usually easier than line for line tracing.
> Now I'm quite happy with LispWorks. I'm sure I would be as happy with
> ACL but the price just for trying is (at least for me) to
> redicoulous. I bouth LispWorks Professional after they dropped the
> price significantly. Anyway a lot of people consider around $750 to be
> too high. I obviously disagree.
I find it a reasonable price for the product, even to use at home for
personal projects only. Add in their royalty free binary distribution
and I can even write stuff to use at work.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@village.uunet.be> wrote in message
···················@localhost.localdomain...
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> <SNIP>
> > The opinions about the usefulness of the debugger seem not to be so
> > clear cut. If I look into The Practice of Programming than I can see
> > an opinion of an hacker saying. Think about it and add some "print"
> > statements. Now that is one opinion there are others, again you should
> > probaly point out when you needed the Debugger and what you we're
> > missing.
>
> Especially in CL there are usually better ways of doing things than
> Unix/C like debuggers. If you suspect a certain function to disobey
> its contract an ADVISE :around it that checks relations between
> arguments and results if usually easier than line for line tracing.
>
OK, but it's always nice to have a range of tools in ones toolbox. You
do say "usually easier"; there are always those unusual times :).
Having said that, I'll aquaint myself with ADVISE. Thanks for the pointer,
Julian.
On Wed, 17 Jan 2001 00:41:14 -0000, "Julian" <······@123lomberg456.net>
wrote:
> Lieven Marchand <···@village.uunet.be> wrote in message
> ···················@localhost.localdomain...
> > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> >
> > <SNIP>
> > > The opinions about the usefulness of the debugger seem not to be so
> > > clear cut. If I look into The Practice of Programming than I can see
> > > an opinion of an hacker saying. Think about it and add some "print"
> > > statements. Now that is one opinion there are others, again you should
> > > probaly point out when you needed the Debugger and what you we're
> > > missing.
> >
> > Especially in CL there are usually better ways of doing things than
> > Unix/C like debuggers. If you suspect a certain function to disobey
> > its contract an ADVISE :around it that checks relations between
> > arguments and results if usually easier than line for line tracing.
> >
>
> OK, but it's always nice to have a range of tools in ones toolbox. You
> do say "usually easier"; there are always those unusual times :).
> Having said that, I'll aquaint myself with ADVISE. Thanks for the pointer,
DEFADVICE is a general means of modifying the behaviour of existing code.
TRACE is a more specially debugging-oriented interface to similar
underlying call insertion mechanisms.
__Jason
Lieven Marchand <···@village.uunet.be> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > A drawback I encountered recently is that I do not find a way to use
> > the services of the Editor elsewhere. I do not find out how to
> > communicate with the Editor. Therefor a Lisp/Emacs combinations seems
> > more useful.
>
> Definitely one of the things Xanalys could do to make their already
> excellent product better would be either including the source of the
> editor with their Professional version, or documenting better how to
> extend it. Their are some weird inconsistencies there that get
> annoying. For instance, if you INSPECT a listener object, you see that
> it uses an editor widget object but stuff like (editor:bind-key
> "Indent New Line" #\control-\j) doesn't work on the listener.
Please check the documentaton (very very carefully ;-) See this:
To make use of an existing command, the command name should be
hyphenated with a command suffix added. For example, the editor command Forward Character is referred to by
forward-character-command. The syntax of a call to an existing command is the same as a call to a standard Lisp function. The first argument
of all command definitions is the prefix argument, and this must therefore be included in any calls made to commands from defcommand, even when
prefix arguments are ignored by the command. Some commands have additional optional arguments and details of these are provided in the command
descriptions throughout this manual.
It was so hidden that I just found it after reading it three times ;-)
Anyway what I did not found it how to use the features of the Editor
elsewhere in a way that I say I want to search for a regular
expression and a string search that string for the regexp and give me
a result. I bet it's possible, anyway I did not found it (yet?)
Regards
Friedrich
From: Pekka P. Pirinen
Subject: Re: LispWorks - comments & questions (long-ish)
Date:
Message-ID: <ixd7dmngo8.fsf@harlequin.co.uk>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Lieven Marchand <···@village.uunet.be> writes:
> > if you INSPECT a listener object, you see that
> > it uses an editor widget object but stuff like (editor:bind-key
> > "Indent New Line" #\control-\j) doesn't work on the listener.
>
> Please check the documentaton (very very carefully ;-) See this: To
> make use of an existing command, the command name should be
> hyphenated with a command suffix added. For example, the editor
> command Forward Character is referred to by
> forward-character-command.
Yes, but that applies to writing your own commands, to invoke other
commands you call them as Lisp functions with such names. BIND-KEY
does take a command name.
The problem with #\control-\j in listeners is that there's a minor
mode binding (Execute mode) on it that shadows the global binding.
You need to override that as well, like this:
(bind-key "Indent New Line" #\control-\j :mode "Execute")
I think the key bindings are distributed with LW. Look for a file
called key-binds.lisp and study it carefully.
--
Pekka P. Pirinen
On Usenet everyone is an expert. - Todd Michel McComb
·····@harlequin.co.uk (Pekka P. Pirinen) writes:
> The problem with #\control-\j in listeners is that there's a minor
> mode binding (Execute mode) on it that shadows the global binding.
> You need to override that as well, like this:
>
> (bind-key "Indent New Line" #\control-\j :mode "Execute")
>
> I think the key bindings are distributed with LW. Look for a file
> called key-binds.lisp and study it carefully.
Thanks for the help. I knew about the key-binds.lisp file but the
Execute mode isn't used in it.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Please check the documentaton (very very carefully ;-) See this:
> To make use of an existing command, the command name should be
> hyphenated with a command suffix added. For example, the editor command Forward Character is referred to by
> forward-character-command. The syntax of a call to an existing command is the same as a call to a standard Lisp function. The first argument
> of all command definitions is the prefix argument, and this must therefore be included in any calls made to commands from defcommand, even when
> prefix arguments are ignored by the command. Some commands have additional optional arguments and details of these are provided in the command
> descriptions throughout this manual.
>
> It was so hidden that I just found it after reading it three times ;-)
>
> Anyway what I did not found it how to use the features of the Editor
> elsewhere in a way that I say I want to search for a regular
> expression and a string search that string for the regexp and give me
> a result. I bet it's possible, anyway I did not found it (yet?)
I had seen that but that just gives you commands. If you look at the
EDITOR package there are a lot of other goodies in there. Ideally, I'd
like to have something like the Elisp manual so that you can write
real extensions for the editor.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Julian wrote:
>
> All the implementations have things to commend them, but one thing I was
> surprised at after returning to Lisp after 15 years was how far behind other
> languages (e.g. C++/Java) it has fallen as far as the graphical IDE is
Program execution tracing is a problem. Part of it is that Common Lisp
is not really a source-file-line-oriented language. Pretty much every
way of getting at the CL evaluator (interpreted or compiled) starts by
calling (READ), which by default eats any file line information, making
it harder to map place-in-code to line-in-file. For errors during
COMPILE-FILE, most compilers just punt and tell you the character offset
in the file where they think the error is, and that's usually only
accurate to the top-level form.
The real problem, though, is macros. A lot of code in most CL systems
never existed in a source file, even in template form, leaving no useful
thing for an IDE to show you as execution proceeds.
Execution tracing is just one part of IDE-ness, though. I will put
(say) Franz's Composer up against any other IDE in terms of viewing data
structures, space and time profiling, or execution stack display and
manipulation. Does any Java IDE reliably let you go down a few stack
frames, modify data, and restart the computation from there? Or let you
change a class definition in mid-flight, with all old objects updated?
Or let you specify arbitrarily complex trace and break code?
IMHO, Lisp systems could regain some of the high ground in IDEs by
taking more advantage of their truly integrated environment and allowing
more user programmable access to IDE display and control. Interlisp-D
allowed users to extend the Inspector, specifying on a per-data-type
basis exactly how objects were to be displayed - modern Lisp IDEs should
allow more stuff like this.
--
Remove obvious stuff to e-mail me.
Bob Bane
Thanks for the comments Bob. My replies below...
Bob Bane <····@removeme.gst.com> wrote in message
······················@removeme.gst.com...
> Julian wrote:
> >
> > All the implementations have things to commend them, but one thing I was
> > surprised at after returning to Lisp after 15 years was how far behind
other
> > languages (e.g. C++/Java) it has fallen as far as the graphical IDE is
>
> Program execution tracing is a problem. Part of it is that Common Lisp
> is not really a source-file-line-oriented language. Pretty much every
> way of getting at the CL evaluator (interpreted or compiled) starts by
> calling (READ), which by default eats any file line information, making
> it harder to map place-in-code to line-in-file. For errors during
> COMPILE-FILE, most compilers just punt and tell you the character offset
> in the file where they think the error is, and that's usually only
> accurate to the top-level form.
True, but a language like C++ or Java suffers from the same problem. A
call to a function that is fairly deeply indented (i.e. the programmer is
running too close to the right margin on the page) will often have its
arguments written across a few lines with the open bracket and first
argument on the same line as the function name and the remaining args
one per line until the close bracket, so a function call can span a few
physical lines in the source code. This is explicitly acknowledged by the
following quote from the helpfile of Borland C++Builder where it talks
about single stepping with reference to the source code: " The debugger
treats a single statement that spans several lines of text as a single line
of
code." It also, incidentally, "treats multiple program statements on one
line
as a single line of code". All perfectly reasonable.
I think the bigger problem may not be at the Lisp source code level, but
at the binary code level. When a C++ compiler generates a binary file it
is a sequential stream of code with the compiled code for the various
functions, methods etc concatenated one after the other in a fixed order.
This means that the compiler can create debug info that gives an offset
into the binary image for the start of the generated code corresponding
to each "line" (using the Borland definition of line as above) of the
source. This means that when a user sets a breakpoint on a "line" of the
source code in an editor it is quite straightforward for the debugger to
look up the start of the binary code corresponding to the start of that
"line" and overwrite the first few bytes (being careful to save the original
code) with a software trap to enter the debugger. As I understand it, the
compiled code for a Lisp program is (maybe until it is run through a
stand-alone application delivery tool) only guaranteed to be sequential
in memory on a per function basis. Just because "foo" immediately preceeds
"bar" in the source code doesn't guarantee contiguous memory allocation
of the binary code. Also, will any (or all?) garbage collection algorithms
make things even worse by moving compiled code around during runtime?
Having said all the above, there are clever people in Franz, Xanalys etc and
all these problems are fixable. Even if garbage collection moves compiled
code around (does it? I'd be interested to know the answer), clearly there
are
mechanisms to always find the entry point to a function otherwise function
calls would start breaking, so the simple offsets used by a C++ debugger
only need to be slightly modified to reference the function name and then a
relative code offset within the compiled code for that function to identify
the start of each souce code "line" comprising the function definition.
>
> The real problem, though, is macros. A lot of code in most CL systems
> never existed in a source file, even in template form, leaving no useful
> thing for an IDE to show you as execution proceeds.
Yes, although a multi-line #define would cause problems of a similar
nature for a C++ system (and they have overcome these issues).
A macro can be treated by a debugger as an atomic function call and
step-over (as opposed to step-into) semantics are easy since the
compiler should be able to generate an offset to the start of the code
for the expression immediately following the call to the macro so if one
is single-stepping then, on saying "step the next expression" (which
happens to be a macro), the stepper just moves the software trap
forward to the start of the code for the expression that is immediately
after the call to the macro in the source code file. This automatically
places
the software trap after all the code generated by the macro expansion.
I'd have to think a bit longer about implementing step-into semantics for
a macro expansion, but I'm sure it's possible. Maybe others can add
detail here.
>
> Execution tracing is just one part of IDE-ness, though. I will put
> (say) Franz's Composer up against any other IDE in terms of viewing data
> structures, space and time profiling, or execution stack display and
> manipulation. Does any Java IDE reliably let you go down a few stack
> frames, modify data, and restart the computation from there? Or let you
> change a class definition in mid-flight, with all old objects updated?
> Or let you specify arbitrarily complex trace and break code?
True. Good points.
>
> IMHO, Lisp systems could regain some of the high ground in IDEs by
> taking more advantage of their truly integrated environment and allowing
> more user programmable access to IDE display and control. Interlisp-D
> allowed users to extend the Inspector, specifying on a per-data-type
> basis exactly how objects were to be displayed - modern Lisp IDEs should
> allow more stuff like this.
Yup. At the end of the day Lisp has so many strengths that more than offset
the
weaknesses I raise. Those weaknesses perplex and frustrate me though, not
because they have a pervasive effect on the usefulness of Lisp, but because
they
seem to me to be so easy to fix that I don't understand why more hasn't been
done by the major Lisp vendors.
By the way, Interlisp-D was also at the back of my mind when I wrote my
original post.
Julian.
In article <············@news8.svr.pol.co.uk>, "Julian"
<······@123lomberg456.net> wrote:
> Yup. At the end of the day Lisp has so many strengths that more than offset
> the
> weaknesses I raise. Those weaknesses perplex and frustrate me though, not
> because they have a pervasive effect on the usefulness of Lisp, but because
> they
> seem to me to be so easy to fix that I don't understand why more hasn't been
> done by the major Lisp vendors.
"Source Locators" in Genera:
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/source-oriented-debugging.html
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <············@news8.svr.pol.co.uk>, "Julian"
> <······@123lomberg456.net> wrote:
>
> > Yup. At the end of the day Lisp has so many strengths that more than offset
> > the
> > weaknesses I raise. Those weaknesses perplex and frustrate me though, not
> > because they have a pervasive effect on the usefulness of Lisp, but because
> > they
> > seem to me to be so easy to fix that I don't understand why more hasn't been
> > done by the major Lisp vendors.
>
> "Source Locators" in Genera:
>
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/source-oriented-debugging.html
CMU CL also goes to some lengths to locate the source code in its
debugger:
* (test 0)
Arithmetic error DIVISION-BY-ZERO signalled.
Operation was KERNEL::DIVISION, operands (8 0).
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL::INTEGER-/-INTEGER 8 0)
Source:
; File: target:code/numbers.lisp
(TRUNCATE X Y)
0] BACKTRACE
0: (KERNEL::INTEGER-/-INTEGER 8 0)
1: (TEST 0)
2: (INTERACTIVE-EVAL (TEST 0))
3: (COMMON-LISP::%TOP-LEVEL)
4: (COMMON-LISP::RESTART-LISP)
0] D
(TEST 0)
1] VSOURCE 4
; File: /home/dent/src/lang/lisp/debug.cl
(DEFUN TEST (X)
(LET ((Y (/ X 9)))
(PRINT Y)
(PRINT (#:***HERE*** (/ 8 Y)))))
1]
Of course this is a fairly simple example, since it involves no
macros. Here's something more complex:
(defmacro divide-it (y)
`(/ 8 ,y))
(defun test2 (x)
(let ((y (/ x 9)))
(print y)
(print (divide-it y))))
* (test2 0)
Arithmetic error DIVISION-BY-ZERO signalled.
Operation was KERNEL::DIVISION, operands (8 0).
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL::INTEGER-/-INTEGER 8 0)
Source:
; File: target:code/numbers.lisp
(TRUNCATE X Y)
0] BACKTRACE
0: (KERNEL::INTEGER-/-INTEGER 8 0)
1: (TEST2 0)
2: (INTERACTIVE-EVAL (TEST2 0))
3: (COMMON-LISP::%TOP-LEVEL)
4: (COMMON-LISP::RESTART-LISP)
0] D
(TEST2 0)
1] VSOURCE 4
; File: /home/dent/src/lang/lisp/debug.cl
(DEFUN TEST2 (X)
(LET ((Y (/ X 9)))
(PRINT Y)
(PRINT (#:***HERE*** (DIVIDE-IT Y)))))
1]
So in some ways the information needed to highlight the original
source in some Editor buffer is there. And IIRC there was at some
point some support for Emacs to take advantage of that information,
though I can't remember the details (maybe part of one of the portable
lisp debugger packages?).
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
From: Pekka P. Pirinen
Subject: Re: LispWorks - comments & questions (long-ish)
Date:
Message-ID: <ixae8qneov.fsf@harlequin.co.uk>
"Pierre R. Mai" <····@acm.org> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
> > In article <············@news8.svr.pol.co.uk>, "Julian"
> > <······@123lomberg456.net> wrote:
> > > Those weaknesses perplex and frustrate me though, not because
> > > they have a pervasive effect on the usefulness of Lisp, but
> > > because they seem to me to be so easy to fix that I don't
> > > understand why more hasn't been done by the major Lisp vendors.
> >
> > "Source Locators" in Genera:
> >
> > http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/source-oriented-debugging.html
>
> CMU CL also goes to some lengths to locate the source code in its
> debugger:
And LW does the same thing, except, having a GUI, it opens the file in
the editor and puts the cursor in the beginning the expression where
the error occurred (and the mark at the end). You have to compile the
code and turn source-level debugging on before compiling:
(SETF COMPILER:*SOURCE-LEVEL-DEBUGGING* T)
Macros do not confuse the debugger, and if the user wants to see
inside the macro expansion, they can press m-sh-M.
The stepper prints the current expression, so it's not too bad. LW
doesn't step compiled code (which implementations do?), and the source
location stuff didn't all work in interpreted code, so integrating
those two hasn't come up yet.
--
Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited
Technology is powerful magic, so we all need to become powerful magicians.
- Christopher M. Stahnke <cstahnke_worldbank.org>
·····@harlequin.co.uk (Pekka P. Pirinen) writes:
> The stepper prints the current expression, so it's not too bad. LW
> doesn't step compiled code (which implementations do?), and the source
> location stuff didn't all work in interpreted code, so integrating
> those two hasn't come up yet.
CMU CL allows stepping compiled code in the debugger, e.g.
* (compile-file "debug.cl" :load T)
Python version 1.0, VM version Intel x86 on 17 JAN 01 10:27:30 pm.
Compiling: /home/dent/src/lang/lisp/debug.cl 17 JAN 01 11:42:45 am
Converted TEST.
Compiling DEFUN TEST:
Converted DIVIDE-IT.
Compiling DEFMACRO DIVIDE-IT:
Converted TEST2.
Compiling DEFUN TEST2:
Byte Compiling Top-Level Form:
debug.x86f written.
Compilation finished in 0:00:00.
; Loading #p"/home/dent/src/lang/lisp/debug.x86f".
#p"/home/dent/src/lang/lisp/debug.x86f"
NIL
NIL
* (trace test2 :break t)
(TEST2)
* (test2 5)
0: (TEST2 5)
Breaking before traced call to TEST2:
Restarts:
0: [CONTINUE] Return from BREAK.
1: [ABORT ] Return to Top-Level.
Debug (type H for help)
(TEST2 5)
Source:
; File: /home/dent/src/lang/lisp/debug.cl
(DEFUN TEST2 (X)
(LET (#)
(PRINT Y)
(PRINT #)))
0] STEP
*Step*
(TEST2 5)
Source: (/ X 9)
6] STEP
*Step*
(TEST2 5)
Source: (PRINT Y)
6] STEP
*Step*
(TEST2 5)
Source: (DIVIDE-IT Y)
6] STEP
5/9
72/5
0: TEST2 returned 72/5
72/5
* (untrace TEST2)
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
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> wrote:
> ·····@harlequin.co.uk (Pekka P. Pirinen) writes:
>
> > The stepper prints the current expression, so it's not too bad. LW
> > doesn't step compiled code (which implementations do?), and the source
> > location stuff didn't all work in interpreted code, so integrating
> > those two hasn't come up yet.
>
> CMU CL allows stepping compiled code in the debugger, e.g.
Thanks for the information.
So CMUCL, LispWorks and Genera do support some form of source
level debugging for Common Lisp.
CMUCL supports stepping of compiled functions.
The MCL documentation says:
The step macro can be used on compiled functions only if their
uncompiled definitions have been retained.
Well, fair enough. ;-)
Sent via Deja.com
http://www.deja.com/
Julian wrote:
>
> I'd have to think a bit longer about implementing step-into semantics for
> a macro expansion, but I'm sure it's possible. Maybe others can add
> detail here.
>
I don't know about "possible" here, but I can easily see "arbitrarily
hard". When I wrote my disseration system in the early 80's, one
preferred style was massive heaps of macros, where
(defparttype pipe ((end1 . pneumatic) (end2 . pneumatic))
;; Functions
(("pressure constraint"
(== (pressure end1) (pressure end2))
("flow constraint"
(== (flow end1) (- (flow end2))
...
))
would be unrolled by stuff like:
(defmacro defparttype (name connection-list function-list)
`(progn
(defclass ,name (part)
((constraints :accessor constraints :initform nil)
,@(mapcar #'(lambda (conn-spec)
`(,(car conn-spec)
:accessor ,(car conn-spec)
:type ,(cdr conn-spec)
:initform (make-instance ',(cdr conn-spec)))
connection-list)))
(defmethod initialize-instance ((part ,name) &key)
(setf (constraints part)
(list ,@(mapcar #'build-constraint function-list))))
...
))
It would be very hard for an IDE to keep track of source-to-executable
correspondence - you run into questions like:
* when you have multiple levels of macros, which one should the IDE show
you?
* how can the IDE keep track of code like the function-list above?
* how do you handle backquoted code templates?
--
Remove obvious stuff to e-mail me.
Bob Bane
Bob Bane wrote:
> <snip>
> It would be very hard for an IDE to keep track of source-to-executable
> correspondence - you run into questions like:
>
> * when you have multiple levels of macros, which one should the IDE show
> you?
> * how can the IDE keep track of code like the function-list above?
> * how do you handle backquoted code templates?
> Bob Bane
I also worked with several layers of macros, and I found that once the
macros were debugged, the right answer to question one is the trivial
one - point to the defparttype macro invocation which caused the error.
The truly hard part is coming up with meaningful error messages from the
macroexpansion that really offer a clue as to what syntax error the
invocation committed. Run time errors were much easier to provide
debugging info for.
Of course the IDE has to be clued into the fact that defparttype is now
a definition of equal importance to defun, defmacro, etc. Emacs has
such a facility (and no, sadly I don't recall what the function names
are).
>>>>"J" == Julian schrieb am Tue, 16 Jan 2001 23:23:53 -0000:
>> Part of it is that Common Lisp is not really a
>> source-file-line-oriented language. Pretty much every way of
>> getting at the CL evaluator (interpreted or compiled) starts by
>> calling (READ), which by default eats any file line information,
>> making it harder to map place-in-code to line-in-file.
J> True, but a language like C++ or Java suffers from the same
J> problem.
Not true. More often than not, I'm not even loading files. I just
"evaluate" the functions from Emacs, that is Emacs communicates with
Allegro or whatever and tells it which function to invoke. This does
not mean that this is a fundamental problem, Emacs could just as well
communicate the file and line-number which in turn could be used from
Ilisp. However, what do you do when you modified a function only at
the Top-Level? The answer is of course just what the link shows that
was provided by Rainer. But then again, you don't need the file and
line information anymore.
>> The real problem, though, is macros. A lot of code in most CL
>> systems never existed in a source file, even in template form,
>> leaving no useful thing for an IDE to show you as execution
>> proceeds.
J> Yes, although a multi-line #define would cause problems of a
J> similar nature for a C++ system (and they have overcome these
J> issues).
Given the limited power of the macro-system in C and its descendants,
I would think that the problems caused by defmacro are not really
comparable at all.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Brauche einen Kaffee um einen Grund zu haben,
den Mund wieder zu schliessen."
-- Tom Woelfel in de.comp.os.linux.misc
Hello Julian,
I used the free/personal version for LispWorks
for a while, then updated to the professional version.
I love it.
Even though you indicate that you have no interest at this time
in producing standalone executables, this is one of the great
features of the professional version. Years ago at SAIC,
I used to use a Xerox 1108 for rapid prototyping, etc. If
we could have bought LispWorks back then, all of our runtime
problems would have been solved (cheaply!). I think that
the free runtime license is a great feature.
Since I like emacs, I find the emacs-like LispWorks IDE to
be pleasant to use. I also like LispWork's support for
"multi processing" (the 'mp' package), good socket support, etc.
The interface builder tool is slick, but I don't usually do GUIs in
Lisp. The interface tool, I think, only generates CAPI code,
and not CLIM code. CAPI is lighter weight than CLIM, but
CAPI is only available for LispWorks.
I have tried ACL also (trial version). That is also an excellant
product, but the price precludes purchase by an individual (also,
they have runtime license fees). For large corporations, the
price of ACL is reasonable, given a need for good support, etc.
(But, of course, I have found the Xanalys support staff to be helpful
also.)
If I were Xanalys, I might consider selling a "standard" edition
that did not have the ability to generate standalone executables
or CLIM support, and price it a little lower than the professional version.
-Mark
Mark Watson <·····@markwatson.com> wrote in message
························@newsread2.prod.itd.earthlink.net...
> Hello Julian,
>
> <SNIP>
>
> If I were Xanalys, I might consider selling a "standard" edition
> that did not have the ability to generate standalone executables
> or CLIM support, and price it a little lower than the professional
version.
>
For me I'd hate to not have CLIM support. That would be another
reason for me to upgrade from Personal Edition. There's some stuff I've been
looking at that needs CLIM.
On Wed, 17 Jan 2001 00:20:01 -0000, "Julian" <······@123lomberg456.net>
wrote:
> For me I'd hate to not have CLIM support. That would be another
There is work under way to produce a free implementation of CLIM:
source code:
http://www.mikemac.com/mikemac/McCLIM/index.html
mailing list:
http://www2.cons.org:8000/mailman/listinfo/free-clim
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
On Mon, 15 Jan 2001 22:42:43 -0000, "Julian" <······@123lomberg456.net>
wrote:
> hence away from Lisp, about 15 years ago now. I never really lost my passion
> for Artificial Intelligence and decided recently to start exploring the
> subject
> again, hence my return to Lisp. I have a few questions that I hope some
You may be interested in LISA:
http://sourceforge.net/projects/lisa
> 1) I downloaded mostly Windows implementations, but did also download
> CMU CL just to see if it's IDE was significantly better than the Windows
> ones. Although I don't want to go the Linux route (it's just the
CMU CL does not provide a full IDE. It comes with the ZMACS-like,
integrated editor Hemlock and a Motif-based GUI to some debugging tools
such as the inspector. CMU CL is generally used with (X)Emacs and
environments such as ILISP.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> wrote in message
·································@4ax.com...
> On Mon, 15 Jan 2001 22:42:43 -0000, "Julian" <······@123lomberg456.net>
> wrote:
>
> > hence away from Lisp, about 15 years ago now. I never really lost my
passion
> > for Artificial Intelligence and decided recently to start exploring the
> > subject
> > again, hence my return to Lisp. I have a few questions that I hope some
>
> You may be interested in LISA:
>
> http://sourceforge.net/projects/lisa
Thanks. I'll check it out,
Julian.
I have also tried the personal edition of LispWorks and
liked it much, but the price tag for the professional
edition is indeed a bit high for hobbyits use.
It is costs almost the same as "Professional" products
of MS and others so its quite ok for professionals,
but for pure private purpose, especially if you take the
high $ compared to the Euro into consideration, its a bit much.
If there were a "standard" edition for, lets say about
$100-$200, I would surely had placed an order already.
Unless there is such an offering, I am probably going
to do, what others in this thread did, that is try to
collect money until I could buy a full version :) (Though
that may take some time, since it costs a months salary
at the moment)
Being on the topic: the only thing I miss in the built-in
editor is syntax higlighting and auto-indenting of new
lines when pressing enter, is there a way to configure
the editor to gain this ?
Peter
--
Peter Herth
Dawn of the Ages http://dawn.netcologne.de
Peter Herth <·······@uni-koeln.de> writes:
>
> Unless there is such an offering, I am probably going
> to do, what others in this thread did, that is try to
> collect money until I could buy a full version :) (Though
> that may take some time, since it costs a months salary
> at the moment)
What is your work. Xanalys costs around 770 Euro or the like which I
hardly can believe is a months salary.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> What is your work. Xanalys costs around 770 Euro or the like which I
> hardly can believe is a months salary.
>
Well unfortunately its quite close :(. I am working at my PhD thesis
and the monthly payment at german universities are about 900 Euro (BaT2a/2
for those who know...), if you are lucky to get any payment at all...
Peter
--
Dawn of the Ages http://dawn.netcologne.de
Peter Herth <·······@uni-koeln.de> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> >
> > What is your work. Xanalys costs around 770 Euro or the like which I
> > hardly can believe is a months salary.
> >
>
> Well unfortunately its quite close :(. I am working at my PhD thesis
> and the monthly payment at german universities are about 900 Euro (BaT2a/2
> for those who know...), if you are lucky to get any payment at all...
I can confirm this. Research positions at German universities for
someone who has not yet finished a doctoral thesis are typically
'half time' positions. Anything else is unusual these days. The
pay is %50. The number of hours work listed in the contract is
%50. Since it is not feasible to only do half of a research project
and be considered to have been successful, the actual working
hours are normally %100 (or actually more). Those working in the
states which belonged to the GDR a bit more than ten years ago earn
less, namely %86.5 of %50.
People in these positions really should qualify for student pricing
(if it is available for a particular product). Their contracts
often require, however, that they not be matriculated in any
university, meaning that they often do not have student status.
-George
George Smith <······@rz.uni-potsdam.de> writes:
> Peter Herth <·······@uni-koeln.de> writes:
>
> > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> >
> > >
> > > What is your work. Xanalys costs around 770 Euro or the like which I
> > > hardly can believe is a months salary.
> > >
> >
> > Well unfortunately its quite close :(. I am working at my PhD thesis
> > and the monthly payment at german universities are about 900 Euro (BaT2a/2
> > for those who know...), if you are lucky to get any payment at all...
>
> I can confirm this. Research positions at German universities for
> someone who has not yet finished a doctoral thesis are typically
> 'half time' positions. Anything else is unusual these days. The
> pay is %50.
Oh I'm quite aware of this (anyway this definitly off-topic). I was in
those shoes a year (not the most pleasant I can recall, and not quite
because it was a full paid BAT 2A job - not paid by the university of
course ;-)
>
> People in these positions really should qualify for student pricing
> (if it is available for a particular product). Their contracts
> often require, however, that they not be matriculated in any
> university, meaning that they often do not have student status.
I see this a bit differently. If it's for you PhD than there is no
reason not to spend the money on it. And I do think that a PhDs
professor will happily send the vendors a mail that this person is
really writing a PhD.
If you "play" with it, now there
are the free personal versions.
If you want more you have to pay for it...
If it's for the University (besides the PhD)-> university prices
should hold.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> I see this a bit differently. If it's for you PhD than there is no
> reason not to spend the money on it. And I do think that a PhDs
> professor will happily send the vendors a mail that this person is
> really writing a PhD.
>
> If you "play" with it, now there
> are the free personal versions.
>
> If you want more you have to pay for it...
>
Unfortunately I wont be able to talk my professor in trying
Lisp, so for the time being its only for private entertainment
so to speak. I did not wanted to start a long thread, just
to give a sign as the first poster: here is a potential
customer for a "standard" version. Since I like doing
some heap intensive things (follow url below), the
personal version's heap limit stroke me already badly.
(It would help if at the students version pricing Xanalysis
would follow the MS way, but thats truly the only thing
they should copy from that company :))
Peter
--
Dawn of the Ages http://dawn.netcologne.de
Peter Herth <·······@uni-koeln.de> writes:
>
> Unfortunately I wont be able to talk my professor in trying
> Lisp, so for the time being its only for private entertainment
> so to speak. I did not wanted to start a long thread, just
> to give a sign as the first poster: here is a potential
> customer for a "standard" version. Since I like doing
> some heap intensive things (follow url below), the
> personal version's heap limit stroke me already badly.
> (It would help if at the students version pricing Xanalysis
> would follow the MS way, but thats truly the only thing
> they should copy from that company :))
Then I sugget looking into Corman Lisp it's around $200 IIRC
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Then I sugget looking into Corman Lisp it's around $200 IIRC
>
Yes thats a really nice lisp, but has one big disadvantage:
it dos not run under Linux :). So at the moment I will stick
to CMUCL.
Peter
--
Dawn of the Ages http://dawn.netcologne.de
Peter Herth <·······@uni-koeln.de> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Then I sugget looking into Corman Lisp it's around $200 IIRC
> >
>
> Yes thats a really nice lisp, but has one big disadvantage:
> it dos not run under Linux :). So at the moment I will stick
> to CMUCL.
Oh that's fine for me. I was just mentioning a Lisp in a moderate
price league, and sorry although I'm a big fan of Linux I would use
whatever OS is there if the software I want to use can be found
there.
Regards
Friedrich
Thanks to everyone for lots of very useful and interesting responses (please
don't
stop!). You've given me a lot of good pointers and background on the issues,
and
a few very practical tips (pointed out with some kindness, since a number of
them
would have been obvious to me if I'd read some of the documentation a bit
more
thoroughly). I still believe that there is scope for some better visual
tools to wrap
around the existing command-line functionality, but I do accept that there
are some
non-trivial issues in some areas (e.g. macros when stepping code),
Julian.