Hi,
I've just recently started looking at LISP and need a little bit of
direction. The main languages I'm used to programming in are C++ and
Java, with the emphasis on C++ using g++ and GNU make. How similar is
the development environment people tend to use with LISP to what is used
with C++? Is there an equivalent to GNU make? Can make be used with LISP?
I program on Linux and I have CMUCL installed. Are applications written
in LISP typically run similarly to java, by typing something like "lisp
file" or is there a way of making the translator transparent? Also,
I've noticed that when things go bad the lisp interpreter drops you into
a debugger. Is there a way to disable that? Or a way to generate the
equivalent of a stack trace instead? I guess I'm still used to the
debug/release version theory that other languages have. Does LISP have
the same sort of thing? Can you compile LISP without debugging info?
Sorry for all the questions. I don't have a local LISP guru to turn to,
so I don't really have any other starting point to start getting a LISP
programming environment set up.
Thanks.
Nobody Famous <·······@hotmail.com> writes:
> Hi,
>
> I've just recently started looking at LISP and need a little bit of
> direction. The main languages I'm used to programming in are C++ and
> Java, with the emphasis on C++ using g++ and GNU make. How similar is
> the development environment people tend to use with LISP to what is used
> with C++?
It's very different. You start up an Emacs, and have that run a lisp
system as an inferior process. You then edit your lisp files, and
send expressions over to the running lisp image be evaluated, as
needed. Occasionally you go to the lisp toplevel and do things like
load an entire file, or type some forms to test parts of your system.
Essentially, you load up a lisp image, and modify it until it contains
your application.
> Is there an equivalent to GNU make?
Sort of. There's defsystem, which is pretty much the make analogue in
the Lisp world. It tracks dependencies, and can recreate your
application for you from a fresh image.
> Can make be used with LISP?
Not without sacrificing a bunch of the advantages of the lisp
environment. Rather than think of the shell as the system top-level,
think of the lisp shell as the system top-level. You run and debug
your application from there.
> I program on Linux and I have CMUCL installed. Are applications written
> in LISP typically run similarly to java, by typing something like "lisp
> file" or is there a way of making the translator transparent?
What do you mean by "run" :)? If you're running you application while
developing it, run it from the lisp top-level. Don't shut down and
start up your lisp system -- keep it running, and load code into it,
and run it from it. If you're asking how your users will run it,
there are several possibilities, but you shouldn't bother yourself
with that yet.
> Also, I've noticed that when things go bad the lisp interpreter
> drops you into a debugger. Is there a way to disable that? Or a
> way to generate the equivalent of a stack trace instead?
Now why on earth would you want to get rid of the debugger? You can
type Q to get back to the toplevel, or backtrace to get a list of
pending stack frames, among other things. I'd highly reccomend
perusing the CMUCL manual on this topic. Otherwise you'll probably
find yourself doing things approximately as foolish as a C++
programmer who only knows about printf, but not gdb.
> I guess I'm still used to the debug/release version theory that
> other languages have. Does LISP have the same sort of thing?
Edit -> Compile -> Debug -> (repeat n times) -> Release
is not the lisp way of doing things. Interactive development and
incremental compilation are. Once you've got your application to a
releasable point, you'll take a fresh image (maybe the small one for
cmucl), load your application into it, save that image, and distribute
that. Probably.
> Can you compile LISP without debugging info?
You *can* (optimize (debug 0)), but *I* wouldn't (except in inner loops).
> Sorry for all the questions. I don't have a local LISP guru to turn to,
> so I don't really have any other starting point to start getting a LISP
> programming environment set up.
Be sure to use an Emacs, and to get the ILISP package (for Emacs).
You'll be a *lot* happier, as that's essentially the sane, normal lisp
development environment. If you're a vi user, try checking out ViPER,
the vi emulation mode in Emacs.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thanks for the info.
> It's very different. You start up an Emacs, and have that run a lisp
> system as an inferior process. You then edit your lisp files, and
> send expressions over to the running lisp image be evaluated, as
> needed. Occasionally you go to the lisp toplevel and do things like
> load an entire file, or type some forms to test parts of your system.
> Essentially, you load up a lisp image, and modify it until it contains
> your application.
>
I'm running XEmacs (I've been using XEmacs for years, but never did much
with the lisp other than edit my .emacs file) and I've installed ilisp.
When I have it evaluate something in my lisp file, it opens a separate
window to display the output. Is there a way to have that go to a
separate buffer instead of another window?
> Sort of. There's defsystem, which is pretty much the make analogue in
> the Lisp world. It tracks dependencies, and can recreate your
> application for you from a fresh image.
>
I finally tracked defsystem down but haven't had a chance to do much
with it, yet.
> Now why on earth would you want to get rid of the debugger? You can
> type Q to get back to the toplevel, or backtrace to get a list of
> pending stack frames, among other things. I'd highly reccomend
> perusing the CMUCL manual on this topic. Otherwise you'll probably
> find yourself doing things approximately as foolish as a C++
> programmer who only knows about printf, but not gdb.
>
If I get to the point where someone other than myself is using my
program, I don't want it to drop them into the debugger if something
goes wrong.
Thanks.
Nobody Famous <·······@hotmail.com> writes:
> > Now why on earth would you want to get rid of the debugger? You can
> > type Q to get back to the toplevel, or backtrace to get a list of
> > pending stack frames, among other things. I'd highly reccomend
> > perusing the CMUCL manual on this topic. Otherwise you'll probably
> > find yourself doing things approximately as foolish as a C++
> > programmer who only knows about printf, but not gdb.
> >
>
> If I get to the point where someone other than myself is using my
> program, I don't want it to drop them into the debugger if something
> goes wrong.
You can always wrap a handler-bind around your whole program, and
thereby simulate standard C behaviour:
(defun c-like-quitter (condition)
(format *error-output* "~&~A~%I'm calling it quits...~%" condition)
(finish-output *error-output*)
(ext:quit))
(defun my-initial-function ()
(handler-bind ((error #'c-like-quitter))
(run-my-application)))
Of course, as a recent thread has pointed out, this doesn't quite
simulate standard C behaviour, because it fairly often provides a
meaningful error message, runs all applicable cleanups, doesn't dump a
corefile filling up your mail-spool, etc. But given enough effort on
your part, you can come pretty close <g>.
Dumping a backtrace can be achieved in this way:
(defun c-like-quitter (condition)
(format *error-output* "~&~A~2%Backtrace:~%" condition)
(debug:backtrace 100 *error-output*) ; Print upto 100 frames
(format *error-output* "~2&I'm calling it quits...~%")
(finish-output *error-output*)
(ext:quit))
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
* Nobody Famous wrote:
> If I get to the point where someone other than myself is using my
> program, I don't want it to drop them into the debugger if something
> goes wrong.
But not doing that is not the same as not having the debug info
there. You use the condition system to make sure you handle any
uncaught nasties. Ultimately something like:
(handler-case
(run-my-big-program ...)
(error (e)
;; Ooops.
(format *error-output* "~&Whoops, caught an unexpected bogon at top-level: ~A~%"
e)
(clean-up-and-exit :abort t)))
is what you want.
--tim
Nobody Famous <·······@hotmail.com> writes:
| I'm running XEmacs (I've been using XEmacs for years, but never did
| much with the lisp other than edit my .emacs file) and I've installed
| ilisp. When I have it evaluate something in my lisp file, it opens a
| separate window to display the output. Is there a way to have that go
| to a separate buffer instead of another window?
You can make the output go to the Lisp listener buffer by setting
lisp-no-popper variable to t. But I'm not quite sure if that's
what you are asking, because by default it should open a separate
frame and not window, I think. Do you perhaps mean that it opens a
separate frame now and you want it to open a separate window
instead of a frame? If that's the case, try setting
ilisp-*use-frame-for-output* variable to nil.
--
Hannu
Nobody Famous <·······@hotmail.com> writes:
> Hi,
>
> I've just recently started looking at LISP and need a little bit of
> direction. The main languages I'm used to programming in are C++ and
> Java, with the emphasis on C++ using g++ and GNU make. How similar is
> the development environment people tend to use with LISP to what is
> used with C++?
Depends on what Lisp you're using. CMUCL like CLISP seem to fit the
"Unix" way of doing things more than other Lisps. I would state that
Lisps DE are very different from the unix way of doing things. I
suggest you have a look at the LispWorks and see yourself what I mean
with it.
>Is there an equivalent to GNU make?
Yes, it's usually called defsystem ... Every Lisp comes with it's
version and there is too a GPLd version called mk:defsystem
available. It's the defsystem which is shipped with CMUCL but it steel
seems to work for any Common Lisp.
>Can make be used
> with LISP?
Yes. Clisp does this quite intensivly IIRC.
>
>
> I program on Linux and I have CMUCL installed. Are applications
> written in LISP typically run similarly to java, by typing something
> like "lisp file" or is there a way of making the translator
> transparent?
Eric Naggum posted what you can do to make Lisp programs run
transparently on Linux some weeks ago.
> Also, I've noticed that when things go bad the lisp
> interpreter drops you into a debugger. Is there a way to disable
> that? Or a way to generate the equivalent of a stack trace instead?
should be doable.
> I guess I'm still used to the debug/release version theory that other
> languages have. Does LISP have the same sort of thing?
Well you can do it that way, but as I learned this is not the Common
Lisp way. You develop a function and than you can immediatly test if
it runs properly. There is not edit-compile-debug circly necessary. If
you find a problem you fix it and often can simple restart the
program. Well it's IMHO a fantastic way of doing programming...
>Can you
> compile LISP without debugging info?
Yes check out the the Hyperspec and the manual for you Lisp.
>
>
> Sorry for all the questions. I don't have a local LISP guru to turn
> to, so I don't really have any other starting point to start getting a
> LISP programming environment set up.
If you're using Emacses for editin I strongly suggest to look at
Ilisp. If you want to see an "integrated development" environment in
action check out e.g LispWorks and/or AllegroCL. I do think the
LispWorks IDE is a nice one and I usually use it for my work.
AllegroCL on Linux is "Emacs based" so it's different, but IMHO nice
too.
Regards
Friedrich
* Nobody Famous wrote:
> Can make be used
> with LISP?
Not easily. Lisp's typical compilation model is rather different than
C/C++, in a way that looks worse but in fact turns out to be an
enormous win.
In typical C/C++ environments you run lots of little invocations of
the compiler, each of which has to discover enough information to
compile the file it's been pointed at.
In typical Lisp environments you run one Lisp, and successively
compile and load (whose nearest C/C++ equivalent is link) code into
the image.
This looks terrible: for a start expressing the dependencies between
things-to-be-compiled is harder in Lisp because there are all sorts of
possible ways that they can happen: something can depend on something
else either being loaded, being compiled by the same image (since
compilation can side-effect the running system) or both. And of
course loading (and in fact compiling) something can effectively alter
the Lisp language itself, which causes even more excitement. If you
are not careful it's possible to get into a state where you either
don't know how to recompile a system into a `clean' image, or you do
know but the knowledge is horribly procedural.
Lisp has tools, usually called `defsystem' to deal with this, and they
are similar to make, but different in important ways because of the
above differences in compilation model. They are generally *simpler*
than make, despite the above, because they don't have to deal with so
much grotty syntax, and don't impose so much of their own. There is
no one standard defsystem unfortunately.
Why do I say that the Lisp model turns out to be a win? Well the
answer is incrementality: because a Lisp system incrementally compiles
and loads code, each successive compilation happens in an environment
where the information needed to compile is already available to the
compiler. In C/C++ this information has to be discovered, usually by
reading many header files, used, and then forgotten just in time for
the next invocation of the compiler. One resulting difference is
that large Lisp systems can be compiled from scratch in an hour, while
large C++ systems take days (seriously: where I'm working now they
don't do overnight builds, because they can't get a build done
overnight). Another resulting difference is that when developing code
you can recompile incrementally and have a new version of the system
in seconds (well, it used to be seconds, it's usually tens of
milliseconds now).
> Also, I've noticed that when things go bad the lisp
> interpreter drops you into a debugger. Is there a way to disable
> that? Or a way to generate the equivalent of a stack trace instead?
> I guess I'm still used to the debug/release version theory that other
> languages have. Does LISP have the same sort of thing? Can you
> compile LISP without debugging info?
You almost certainly do not want to do that: even many C/C++ people
are beginning to ship code with debugging information left in (again,
the place I'm working now are moving to this) because debugging info
is so useful for, well, debugging. If you don't want the end-user
application to end up in the debugger, you should use the condition
system to catch errors and deal with them appropriately - if nothing
better print some information about the error and terminate.
--tim
Nobody Famous <·······@hotmail.com> writes:
> Hi,
>
> I've just recently started looking at LISP and need a little bit of
> direction. The main languages I'm used to programming in are C++ and
> Java, with the emphasis on C++ using g++ and GNU make. How similar is
> the development environment people tend to use with LISP to what is used
> with C++?
It is the same. It is called (X)Emacs. :)
> Is there an equivalent to GNU make?
Check out MK:DEFSYSTEM in the CLOCC (http://sourceforge.net/projects/clocc).
> Can make be used with LISP?
Yes it can, but it does not necessarily work in the same way you'd expect.
> I program on Linux and I have CMUCL installed. Are applications written
> in LISP typically run similarly to java, by typing something like "lisp
> file" or is there a way of making the translator transparent?
Yes you can, but it is implementation dependent. In CMUCL first you
save an "image" with the function EXT:SAVE-LISP and then you can
invoke the saved image with
prompt> lisp -core your-saved-image.core
Other implementations have similar but different conventions.
> Also,
> I've noticed that when things go bad the lisp interpreter drops you into
> a debugger. Is there a way to disable that? Or a way to generate the
> equivalent of a stack trace instead? I guess I'm still used to the
> debug/release version theory that other languages have.
You can get the stack trace by typing :backtrace (or something similar
at the debugger).
> Does LISP have the same sort of thing?
Again it is implementation dependent.
> Can you compile LISP without debugging info?
Ditto. But you really do something different. Some implementations
give you a "Tree Shaker" that "removes" unwanted code from the saved
"image".
> Sorry for all the questions. I don't have a local LISP guru to turn to,
> so I don't really have any other starting point to start getting a LISP
> programming environment set up.
>
> Thanks.
>
You are velcome.
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'.