best environment for learning Lisp?
ccc31807
programmer would be familiar with. This would include Eclipse, Visual
Studio, and (perhaps most commonly) a plain text editor combined with
gcc, g++, javac, etc.
I have given SLIME a good try, but it's too unlike the tools I use
most often for me to feel comfortable with it. I have tried LispWorks
and CLISP in a command interpreter (shell), but these still feel
awkward. I'm not particularly looking for a GUI based environment,
e.g. VS, but I'm finding that fighting with the environment is getting
in the way of using Lisp.
Thanks, CC.
Pillsy
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
If you have LispWorks already, why not try the IDE it comes with?
Allegro CL also comes with an IDE on Windows, and has a gratis trial
edition like LispWorks.
Cheers,
Pillsy
Robert Uhl
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it.
I think most folks would suggest that you use SLIME. Yes, emacs is very
unlike Visual Studio or Eclipse, but there are good reasons for most of
the differences and historical reasons for most the the rest.
As an example, the keys for manipulating text are not the common Ctrl-C,
Ctrl-V that you may be used to; this seems annoying. There's an
historical reason: emacs was developed before the Ctrl-C/Ctrl-V
convention existed. But there's a good reason to learn the emacs way:
it affords a much more convenient way to manipulate text. E.g. there's
C-a, which goes the the beginning of the current line (I think the
mnemonic is 'a is the beginning of the alphabet'); C-e goes to the end
of the current line; in SLIME mode C-b goes back one sexp and C-f goes
forward one sexp. The emacs equivalent to copy/paste is kill/yank, but
it's more flexible than copy/paste in that there is a killring which
saves previous selections.
Or as another example, Ctrl-S is commonly used to save; in emacs C-s is
instead used to search and saving is C-x C-s. This seems annoying, but
C-s is instead bound to an interactive forward-search, while C-r is
bound to an interactive reverse-search, and C-M-s is bound to an
interactive forward regexp search and C-M-r is bound to an interactive
reverse regexp search.
What I'm getting at is this: yes, emacs is different. But once you
learn it, it's _better_. You'll want to read your email and newsgroups
in emacs; you'll want to browse the web in emacs; you'll want to manage
your time in emacs. It really is that nice.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I admit that X is the second worst windowing system in the world,
but all the others I've used are tied for first. --Paul Tomblin
Pascal J. Bourguignon
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
What would be the best way to go to the moon with the environment an
experienced carpenter would be familiar with. This would include
wood, scisors, saws, planes, and (perhaps most commonly) a plain
hammers combined with nails, glue, etc.
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
I have tried iron works, but it's too unlike the tools I use most
often for me to feel comforntable with it. I have tried tools to deal
with aluminium and tungstein, but these still feel awkward. I'm not
particularly looking for a woodworking shop based environment, but I'm
finding that fighting with the environent is getting in the way of
going to the Moon.
ccc31807, perhaps you could try this:
http://pagesperso-orange.fr/macareux-oiseaux/Icare/icareB.jpg
Just add wings to the legs, and of course, take of during the night:
you have to learn from the errors of your elders!
--
__Pascal Bourguignon__
ccc31807
> I think most folks would suggest that you use SLIME. Yes, emacs is very
> unlike Visual Studio or Eclipse, but there are good reasons for most of
> the differences and historical reasons for most the the rest.
I'm in the IT department of a large public university, working as a
database manager. I frequently write little scripts that munge data. I
have written in Java, C, C++, but mostly I use Perl -- in fact I find
myself writing Perl perhaps two hours a day on a light day and eight
hours on a heavy day. As an editor, I use vi, and over the years have
become quite proficient in vi.
I have made several attempts to learn EMACS, without too much success.
I'm now working through the 3rd edition of Winston and Horn using
SLIME, and continue to be frustrated by the environment. Maybe it will
take a lot of time getting used to it, and maybe in time I'll become
proficient with it, but I still resent the fact that learning my LOTY
(CL) means fighting with the implementation.
> What I'm getting at is this: yes, emacs is different. But once you
> learn it, it's _better_. You'll want to read your email and newsgroups
> in emacs; you'll want to browse the web in emacs; you'll want to manage
> your time in emacs. It really is that nice.
I'm an older guy, and like the older technologies. I still drop into
the DOS prompt, much to the dismay of my younger colleagues who can't
understand that giving a command is a lot quicker and simpler than
pointing and clicking through multiple layers of UI -- or writing,
compiling, and running a Java program using vi, javac, and java.
emacs certainly qualifies as a retrograde technology, but for me it's
brand new. I'll continue to soldier onward with SLIME, but I'll
continue to yearn for Mr. Right, speaking environmentally.
CC
Tim Bradshaw
> I'm in the IT department of a large public university, working as a
> database manager. I frequently write little scripts that munge data. I
> have written in Java, C, C++, but mostly I use Perl -- in fact I find
> myself writing Perl perhaps two hours a day on a light day and eight
> hours on a heavy day. As an editor, I use vi, and over the years have
> become quite proficient in vi.
I suspect (but am not sure) that one of the emacs vi-modes should work
OK with SLIME. I don't know which of them is preferred, really (I use
vi a lot at work but I've managed to avoid learning it properly, which
is a dumb decision, I know).
--tim
Alberto Riva
>
> I have made several attempts to learn EMACS, without too much success.
> I'm now working through the 3rd edition of Winston and Horn using
> SLIME,
Well, that may be part of the problem, that book is 20 years old. It's
still a pretty good book, but you may want to try something more modern
like this:
http://www.gigamonkeys.com/book/
that also includes an introduction to Slime (see Chapter 2).
> and continue to be frustrated by the environment.
What exactly is it that frustrates you?
> Maybe it will
> take a lot of time getting used to it, and maybe in time I'll become
> proficient with it, but I still resent the fact that learning my LOTY
> (CL) means fighting with the implementation.
You should be careful to distinguish the 'implementation' from the
'environment'. By implementation we usually mean a realization of the CL
standard, and there are several to choose from, both free and commercial
(CLISP, CMUCL, SBCL, Allegro, Lispworks... which one are you using,
BTW?). The development environment is the set of tools provided by your
implementation (or by an independent package like Slime) to facilitate
writing programs. Each implementation provides one, ranging from a basic
REPL to Emacs-based interfaces to complete graphical IDEs. Every CL
implementation gives you a REPL, most of them are supported by Slime,
and then there are the proprietary solutions. So you have a lot to
choose from... but it seems that your problem is simply to get used to
the Emacs way of doing things (that is only incidentally related with CL).
> I'm an older guy, and like the older technologies. I still drop into
> the DOS prompt, much to the dismay of my younger colleagues who can't
> understand that giving a command is a lot quicker and simpler than
> pointing and clicking through multiple layers of UI -- or writing,
> compiling, and running a Java program using vi, javac, and java.
Which is exactly the same thing you do when you use Emacs+Slime+CL,
except that the editor, compiler, runtime environment, debugger,
profiler, etc are all integrated...
> emacs certainly qualifies as a retrograde technology
Would you care to explain this statement?
Alberto
Robert Uhl
> On Jun 29, 11:13 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>> I think most folks would suggest that you use SLIME. Yes, emacs is very
>> unlike Visual Studio or Eclipse, but there are good reasons for most of
>> the differences and historical reasons for most the the rest.
>
> I'm in the IT department of a large public university, working as a
> database manager. I frequently write little scripts that munge data. I
> have written in Java, C, C++, but mostly I use Perl -- in fact I find
> myself writing Perl perhaps two hours a day on a light day and eight
> hours on a heavy day. As an editor, I use vi, and over the years have
> become quite proficient in vi.
Ah, I misunderstood where you're coming from--I thought that you must be
someone who's used to the IDE model.
> I have made several attempts to learn EMACS, without too much success.
I was there once too. Part of the problem is that the tutorial really
wasn't useful to me, e.g. it covered C-p/C-n which I never used but
didn't mention the arrow keys which I use all the time.
How did I finally switch? Too long ago now to remember exactly; I think
I just forced myself too and then discovered that it was working pretty
well for me.
> Maybe it will take a lot of time getting used to it, and maybe in time
> I'll become proficient with it, but I still resent the fact that
> learning my LOTY (CL) means fighting with the implementation.
Not too different from learning Java and having to fight with Eclipse,
though--right?
> emacs certainly qualifies as a retrograde technology, but for me it's
> brand new. I'll continue to soldier onward with SLIME, but I'll
> continue to yearn for Mr. Right, speaking environmentally.
An approach that might work for you is to try to learn one new feature
or keystroke per day, and use it as much as you can. E.g. if you're not
used to C-b/C-f or C-M-a/C-M-e, use them constantly today.
Or install emacs-w3m and hyperspec.el and use C-c C-d h to look up Lisp
documentation within emacs...that's awfully handy.
Also, for learning Lisp you might wish to check out Practical Common
Lisp--it's excellent.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...I've seen Sun monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these things will be
lost in time, like the root partition last week. Time to die... --Peter Gutmann
Kenneth Tilton
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with.
I feel a naggum coming on.
> This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
If those are what you call best, we need to work on your idea of best.
Let's lose that troublemaker of a word and change the subject to "Lisp
environment most like what us MS-possessed drones are used to"... oh,
look!...
AllegroCL IDE, available on Windows and I think Linux. Not sure of the
actual nature of the second, I use the first. Linux has a sub-par but
powerful IDE that runs cross-platform.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it.
Do I tell you my problems? If the Lisp experience makes you
uncomfortable Lisp either sucks or really is as different as you have
heard. Suggest you stop whining and start memorizing those keychords.
> I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
We do that to keep out the riff-raff. Suck it up for a week and you'll
be fine.
hth, kt
ps. Yes, Emacs+Slime is a joke of an IDE. kt
ccc31807
> > and continue to be frustrated by the environment.
>
> What exactly is it that frustrates you?
The basic stuff, like,
- how do you write a file?
- how do you save a file?
- how do you compile a file?
- how do you run a script?
- how do you recover from an errir?
I still don't know how to write and save a file in SLIME, although I
have figured out how to compile, load, and run a script in SLIME.
However, when my script hangs, all I know how to do is kill the
process and start a new one, which takes time and frustrates the heck
out of me.
> > emacs certainly qualifies as a retrograde technology
>
> Would you care to explain this statement?
I meant it as a complement rather than a criticism. C, Perl, sh and
bash, vi, all are retrograde but all are unsurpassed in their
competencies. Indeed, Lisp itself is going on 60 years old, which
makes it a retrograde technology.
CC
Jimmy Miller
> On Jun 29, 12:19 pm, Alberto Riva <a...@nospam.ufl.edu> wrote:
>
> > > and continue to be frustrated by the environment.
>
> > What exactly is it that frustrates you?
>
> The basic stuff, like,
> - how do you write a file?
> - how do you save a file?
> - how do you compile a file?
> - how do you run a script?
> - how do you recover from an errir?
1.) Go to File -> New.
2.) Go to File -> Save.
3.) Look up the COMPILE-FILE function in the hyperspec. If you
instead want to generate a standalone executable, that's
implementation-dependent, so you can refer to the CLISP/SBCL/whatever
docs.
4.) (load "/path/to/my/script.lisp")
5.) Normally, you just press q (make sure the focus is on the buffer
with the error message) and you'll be back at the SLIME REPL.
Emacs is pretty much like any other editor; you don't have to learn
Emacs commands if you don't want to.
Alberto Riva
> On Jun 29, 12:19 pm, Alberto Riva <a...@nospam.ufl.edu> wrote:
>>> and continue to be frustrated by the environment.
>> What exactly is it that frustrates you?
>
> The basic stuff, like,
> - how do you write a file?
I assume you mean 'how do you create a new file'... C-x C-f, then type
the name of the file you want to create.
> - how do you save a file?
C-x C-s
Note that the two above are Emacs commands, they have nothing to do with
Lisp. They're usually items #1 and #2 in any Emacs tutorial. Try C-h t.
> - how do you compile a file?
The Lisp way: (compile-file "/path/to/source-file"), usually followed by
(load "/path/to/compiled-file")
The Slime way: ,cl followed by enter followed by the name of the source
file (note the comma before the 'cl').
> - how do you run a script?
See below.
> - how do you recover from an error?
In general when an error occurs the screen will split in two, and you'll
find yourself in the Slime debugger. From there, you should almost
always be able to type 'a' to abort and go back to the Lisp prompt.
There are many other wonderful things you can do with the debugger, but
let's leave them for later... :)
> I still don't know how to write and save a file in SLIME, although I
> have figured out how to compile, load, and run a script in SLIME.
Here I am a bit confused... what do you mean by 'script'? There are no
'scripts' in Lisp, there are programs that you write in a source file
and then compile, load and execute (see above), or functions you type
directly at the REPL, but that's usually only done for quick tests and
experiments. How can you be able to load a script and not be able to
write a file? Where are you loading your script from?
> However, when my script hangs, all I know how to do is kill the
> process and start a new one, which takes time and frustrates the heck
> out of me.
See above.
>>> emacs certainly qualifies as a retrograde technology
>> Would you care to explain this statement?
>
> I meant it as a complement rather than a criticism. C, Perl, sh and
> bash, vi, all are retrograde but all are unsurpassed in their
> competencies. Indeed, Lisp itself is going on 60 years old, which
> makes it a retrograde technology.
Ok, then I would use a different adjective... according to the American
Heritage Dictionary:
ret·ro·grade (rĕt'rə-grād')
adj.
1. Moving or tending backward.
2. Opposite to the usual order; inverted or reversed.
3. Reverting to an earlier or inferior condition.
Alberto
Robert Uhl
>
>> > and continue to be frustrated by the environment.
>>
>> What exactly is it that frustrates you?
>
> The basic stuff, like,
> - how do you write a file?
> - how do you save a file?
'Writing' and 'saving' a file normally mean the same thing...do you mean
'how do you open a new file' and 'how do you save a file'?
To open a new file: C-x C-f (hold down control, type xf); you'll be
prompted for a filename, with tab-completion of directories and existing
files. You can type a new file name to create a new file.
To save a file: C-x C-s (hold down control, type xs).
> - how do you compile a file?
C-c M-k
But that's probably not what you really want to do: you _probably_ want
to compile the file and then immediately load it; that's C-c C-k.
> - how do you run a script?
sbcl --load foo.lisp
Or, from the REPL:
(load "foo")
> - how do you recover from an errir?
Normally a number of restarts are presented; you can choose one of them.
cl-user> (/ 1 0)
arithmetic error division-by-zero signalled
Operation was sb-kernel::division, operands (1 0).
[Condition of type division-by-zero]
Restarts:
0: [retry] Retry SLIME REPL evaluation request.
1: [abort] Return to SLIME's top level.
2: [terminate-thread] Terminate this thread (#<thread "repl-thread" running {B2DBF89}>)
Backtrace:
0: (sb-kernel::integer-/-integer 1 0)
1: (/ 1)[:external]
2: (sb-int:simple-eval-in-lexenv (/ 1 0) #<NULL-LEXENV>)
--more--
Typing 0 would retry '(/ 1 0)'; 1 would abort and return to the
toplevel; 2 would kill the current thread; q would do the same as 1.
> I still don't know how to write and save a file in SLIME, although I
> have figured out how to compile, load, and run a script in SLIME.
Ah, it sounds to me like you're working at the REPL and want to work
with files. Just use C-x C-f to open a new or existing file; you can
then save it with C-x C-s as usual. While you're in that file, C-x C-e
will evaluate the sexp before the point ('point' is what emacs calls the
cursor), so you could, for example, evaluate a function or variable
definition.
> However, when my script hangs, all I know how to do is kill the
> process and start a new one, which takes time and frustrates the heck
> out of me.
That must be extremely frustrating! C-c C-c will interrupt the
currently-running thread.
--
Robert Uhl <http://public.xdi.org/=ruhl>
At this rate it'll not be so much a case of Four Horsemen as
Death, War, and all their friends in the Cavalry Charge of the
Apocalypse. --Dan Holdsworth
André Thieme
You were speaking in general about Lisp, so I don't know if you wish to
learn Scheme, Common Lisp or Dylan, or one of the newer dialects, such
as Clojure.
If that is the case then you could use NetBeans + Enclojure. That would
be a modern IDE and sounds like what you are looking for (GUI based
environment).
http://www.enclojure.org/
If an editor is enough then you can use Lisp also via SLIME and also
via vimclojure: http://kotka.de/projects/clojure/vimclojure.html
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Rainer Joswig
> On Jun 29, 12:19 pm, Alberto Riva <a...@nospam.ufl.edu> wrote:
>
> > > and continue to be frustrated by the environment.
>
> > What exactly is it that frustrates you?
>
> The basic stuff, like,
> - how do you write a file?
> - how do you save a file?
> - how do you compile a file?
> - how do you run a script?
> - how do you recover from an errir?
>
> I still don't know how to write and save a file in SLIME, although I
> have figured out how to compile, load, and run a script in SLIME.
> However, when my script hangs, all I know how to do is kill the
> process and start a new one, which takes time and frustrates the heck
> out of me.
Typically it does not take long to learn to use Lisp, unless you have
been programming before then it takes longer - some even don't get it
at all.
A basic 'reorientation' is necessary. The typical assumption is that
Lisp is just another language, but with fancy parentheses. But that is
wrong.
Lisp has been designed for incremental, interactive and evolutionary
programming. It has been designed for computing with symbols, with s-
expressions and with Lisp code.
You can use Lisp like you would use Java or C, but that's not what it
is designed for and how it's best used.
The ideal is: you interact with a Lisp environment and evaluate
statements. The interface for that is the so-called REPL, the Read
Eval Print Loop. You type something and Lisp does something. Whenever
you move away from this ideal (you start thinking of compiling files,
linking object files, etc.) you will miss something from the strength
of interactive programming. The program evolves while you talk to the
Lisp system. No reloading, no full compiles, no linking, no
application restarts. To deal with errors, Lisp has a sophisticated
error handling system that allows the user to recover from many errors
at development time, without leaving the program under development.
The following video might give you an impression how this development
style works. I tried to use simple interaction techniques. You can see
that I type code to an editor (here using LispWorks) and immediately
try the code in the Listener (the REPL window). The basic development
cycle might use one or both, the editor and the listener. Much of the
work can be done this way. When you get the functionality going, it is
'packaged' up, saved in a file and one tries to edit it so that it can
be loaded into Lisp via LOAD.
http://lispm.dyndns.org/news?ID=NEWS-2005-07-08-1
See the video link at the end of above page. It is not SLIME, but
LispWorks. But it will give you an idea why things work a little bit
different than you might be used to. ;-)
If you have the feeling that the multitude of windows, gadgets, dialog
items, control buttons, menus are somehow missing - that's because
those tend to get into the way during interactive development. Reduce
the visual clutter, work from the code. That's the Lisp way.
Jimmy Miller
> The ideal is: you interact with a Lisp environment and evaluate
> statements. The interface for that is the so-called REPL, the Read
> Eval Print Loop. You type something and Lisp does something. Whenever
> you move away from this ideal (you start thinking of compiling files,
> linking object files, etc.) you will miss something from the strength
> of interactive programming. The program evolves while you talk to the
> Lisp system. No reloading, no full compiles, no linking, no
> application restarts.
Of course, this is the ideal, but you will have to deal with files at
some point if you want to save all of the code that you've been typing
at the REPL for future use (and have it still be readable and editable
by humans). I think the optimal solution would be to have the Lisp
system keep track of the "permanent" bits of code you enter, like
calls to defun and defmacro, and then you can save your REPL session
in a typical binary image. Later on, when you reload this image, you
just enter a form like (get-code 'my-foo-fuction) and Lisp will show
you the code you typed in for that function.
This would allow you to spend all of your time at the REPL, without
having to deal with separate text files just so you can suspend and
resume your work.
ccc31807
> > However, when my script hangs, all I know how to do is kill the
> > process and start a new one, which takes time and frustrates the heck
> > out of me.
>
> That must be extremely frustrating! C-c C-c will interrupt the
> currently-running thread.
Thank you, all -- especially including Jimmy, Alberto, and Robert.
I wasn't entirely forthcoming, since I had discovered some of these
tricks, but I wasn't being dishonest either, since the process of
discovery was tedious and not at all obvious. And I'm still in the
process of discovery, since some things I take for granted still seem
hidden in working through the books.
For example, when I write a little script in Java, or C, or Perl, I
follow a three step process:
1. Invoke a text editor (usually vi) and write the code.
2. (with C and Java) Compile with gcc or javac.
3. Run the script with perl or java (for Perl and Java) or directly
with a C executable.
When I compile a .lisp script in SLIME, I get a .fas file and a .lib
file. Neither of these seem to be a binary file, but they each have
parts that look like a dump (using od).
What are the Lisp equivalents to:
javac? (compiles source to bytecode)
java? (runs bytecode)
gcc? (compiles source to executable)
perl? (interprets and runs source directly)
Thanks, CC.
Jimmy Miller
> What are the Lisp equivalents to:
> javac? (compiles source to bytecode)
> java? (runs bytecode)
> gcc? (compiles source to executable)
> perl? (interprets and runs source directly)
>
> Thanks, CC.
This depends on your Lisp implementation. The commercial CLs, like
LispWorks and Allegro, have menu options for generating an executable
(although this feature isn't available in the trial version of
LispWorks). In CLISP, you can just distribute the CLISP runtime
executable along with your .fas file; see
http://clisp.cons.org/impnotes/quickstart.html#quickstart-desktop. In
SBCL, you have the ability to generate a complete standalone
executable, see http://www.sbcl.org/manual/Saving-a-Core-Image.html.
Ron Garret
<d259d6db-26fb-4d34...@l2g2000vba.googlegroups.com>,
Jimmy Miller <captain...@gmail.com> wrote:
I have always thought that saving Lisp code in files is a mistake.
Files are good for saving text, but Lisp code isn't text, it's
S-expressions. S-expressions can be serialized as text, but they are
not themselves text, and rendering them non-volatile by storing their
serializations in a file seems like a Horrible Hack.
rg
Ron Garret
<520f7e9c-878e-45fa...@k8g2000yqn.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
If you have access to a Macintosh I'd recommend looking at Clozure
Common Lisp. It's free, and it has an IDE. (You can also run it on
Linux and Windows but without the IDE.) It's pretty new and still has a
few rough edges, but a lot of those have been smoothed out recently.
rg
Tim Bradshaw
> Of course, this is the ideal, but you will have to deal with files at
> some point if you want to save all of the code that you've been typing
> at the REPL for future use (and have it still be readable and editable
> by humans). I think the optimal solution would be to have the Lisp
> system keep track of the "permanent" bits of code you enter, like
> calls to defun and defmacro, and then you can save your REPL session
> in a typical binary image. Later on, when you reload this image, you
> just enter a form like (get-code 'my-foo-fuction) and Lisp will show
> you the code you typed in for that function.
That's pretty much how the environment on the Xerox d-machines worked.
You just used ED to edit definitions, at least if you were using it
from the CL environment, which I pretty much always did. You could
(and did) save "files" but these were not like the files you know.
These machines seem to have faded into history almost completely now
(though of course they were closely related to things like the Alto,
which is probably still well-remembered).
--tim
Tim Bradshaw
> If you have access to a Macintosh I'd recommend looking at Clozure
> Common Lisp. It's free, and it has an IDE. (You can also run it on
> Linux and Windows but without the IDE.) It's pretty new and still has a
> few rough edges, but a lot of those have been smoothed out recently.
I second that. When Ron says "pretty new" he actually means "pretty
old" in some ways - it's fairly directly descended from Macintosh
Common Lisp which I think is of some considerable vintage. I think the
IDE may be much newer though.
--tim
André Thieme
This happens all dynamically in Lisp.
You have the compile function, and for example clisp compiles then lists
(they contain your source code) to bytecode. Many other compilers of
other Lisp implementations compile directly to native machine code.
Calling a function of compiled code is what you do by calling Java on a
.class file. That classes main method gets called. In Lisp you just call
that function (and it does not necessarily need to be called main).
You can also just call uncompiled code - many Lisps will eval (interpret)
it then (some like SBCL will most likely under the hood compile the code
for you first).
ccc31807
> I have always thought that saving Lisp code in files is a mistake.
> Files are good for saving text, but Lisp code isn't text, it's
> S-expressions. S-expressions can be serialized as text, but they are
> not themselves text, and rendering them non-volatile by storing their
> serializations in a file seems like a Horrible Hack.
How then would you save the code that you write, other than in a file?
A file is everything, a document, a glob of binary data (like a
picture, a sound file, or a binary), directory, device, printer,
modem, network node -- there is nothing that it is not a file.
Surely you don't mean that you type the code into memory every time
you want to run an application, do you?
If so, this is just too, too weird.
CC
Thomas A. Russ
> For example, when I write a little script in Java, or C, or Perl, I
> follow a three step process:
> 1. Invoke a text editor (usually vi) and write the code.
> 2. (with C and Java) Compile with gcc or javac.
> 3. Run the script with perl or java (for Perl and Java) or directly
> with a C executable.
Well, you CAN follow that same method in lisp if you want to. In the
really old days we had to do that as well, but something like an early
predecessor of SLIME was developed fairly early on.
Anyway, you can certainly do
1. Write your program in a text editor. vi will work, but I'm not sure
if it really has much support for lisp. At a minimum you want to
get parentheses matching, and ideally, auto-indenting. Emacs lisp
mode provides both.
1.5. Start your lisp execution environment. You would generally only
need to do this once. The steps 2 and 3 occur in your lisp
environment.
2. (compile-file "myprogram.lisp")
3. (load-file "myprogam") ;; Note: No file type given!
(some-functon-in-myprogram)
In general, you would do steps 2 and 3 together in the same
environment. You can even do this repeatedly after making changes to
your code.
But except for small projects, you usually are only changing a small
part (or single function) at a time, so the SLIME-like environment where
you can compile single functions turns out to be more convenient.
> When I compile a .lisp script in SLIME, I get a .fas file and a .lib
> file. Neither of these seem to be a binary file, but they each have
> parts that look like a dump (using od).
Not sure about the internal details. This sounds like it might be
CLISP. Each implementation is allowed to set up its own structures and
file extensions for compiled files.
> What are the Lisp equivalents to:
> javac? (compiles source to bytecode)
> java? (runs bytecode)
> gcc? (compiles source to executable)
> perl? (interprets and runs source directly)
Well it's a bit tough because there isn't necessarily a direct
correspondence. For example, not all lisp implementations even use
bytecode. So there might not be anything that works with bytecodes.
So, perhaps the best approach would be to look at what lisp functions
are available to you. To use any of these, you first start your lisp
environment:
LOAD: Loads a source or compiled file into lisp.
(load "myprogram") ; loads the most recent of source or
; compiled versions.
(load "myprogram.lisp") ; Forces source version
COMPILE-FILE: Compiles a source files and writes it out
in compiled form for later loading.
(compile-file "myprogram.lisp")
Executing your code after loading it is done by invoking one of the
functions that exist in your code. Unlike C or Java, there is no
distinguished name for a function that is run automatically. You have
to tell the lisp environment which one to run.
The choice between running intepreted or compiled code depends on
whether you have loaded compiled or source forms of the program. [Note
that not all lisp systems have a true interpreter. Some of them will
compile on the fly. -- but that shouldn't matter to you.]
--
Thomas A. Russ, USC/Information Sciences Institute
Rainer Joswig
In some Lisps you have a working DRIBBLE function which writes the
interaction to a file.
Some Lisps have/had a listener that is more like an editor. There were
also variants where input and output were in different panes.
CL:FUNCTION-LAMBDA-EXPRESSION gets you the source for a function
in a Lisp that supports it.
Usually I type definitions into an editor window and evaluate from
there.
The MCL model is nice, where evaluations are enqueued into the
top-most Listener. I try to avoid loading/saving files. Even
if I work with a file in an editor I evaluate from there.
There are also editor commands to insert evaluation results
into the editor window.
There are also cases where I write something that takes care
of the code. For example I could have a data structure
for a bunch of rules. There is a function ADD-RULE.
It will add the rule s-expression to the rules data
and it will do the necessary compilation. If I want
to see my rules, I can do SHOW-RULE :all or some
individual rule name. That way I write some code that
tracks the current active rules - both in source and compiled.
I don't have to use the editor to find it. I have
a separate rule storage, which may be a file, but I
don't edit it with the text editor.
If you look at earlier systems that were written in a more
symbolic style, like Frame systems - those would
give names (symbols) for everything. Every object has
a name. Every method, every class, every instance has a name.
The name points to a data structure that has all the necessary
information. With a single command you could dump all
these definitions into a file and transfer them to another Lisp.
If you had described for example a motor block and its functionality,
you could dump it and load the thing into another Lisp.
The interaction, the editing is then not based on files,
but you edit the in-image data structures - files were only
there to save the state of work or to transfer the data to
some other place. The Lisp image contains the 'knowledge base'
and you can dump and load it. If you want to add a subclass
you would point to the thing and use the add subclass menu.
It would ask for the necessary information and create the subclass.
Unfortunately we have been going a way from this symbol style a bit.
A CLOS class is relatively primitive by default: it has no
demons, no slot facets, no multiple slot values, no name, it
can't be dumped etc. - by default. The earlier systems offered quite a
bit
more comfort. So there is definitely some space for development
environments to provide different CLOS metaclasses which are
easier to use and which have more support by the development
environment than simple introspection.
For me as an CL user, a developer, I may need to reconstruct
some of this power. In a way it is a version of Greenspun:
In any larger Lisp application there tends to be a Frame system
(or it would be useful to have one). For example to have
names for every object can be very useful in interactive development.
For example you see in some data structure two graph nodes
NODE1456 and NODE167. Now you could just call (connect 'node1456
'node167)
and get these nodes connected. No need to try to retrieve them
using long accessors (side note presentations can be used in a similar
way).
If I work with Lisp as an interactive system, my first question is
not how I could organize my software in files. My first question
is how I organize my software as Lisp objects and how I can
get the maximum of interactivity. If you move conceptually to far away
from this, you should ask yourself if Lisp is really the
best tool for the task.
This may be frightening for a Lisp beginner who is used to, say,
Java and Eclipse. You can start slowly but at some point you should
ask yourself which advantages Lisp has and how you can maximize
these for your development. THE advantage Lisp has is interactive
development with symbolic expressions. Try to find out how to
leverage that for your development. In Java you can only
manipulate code with refactoring tools. In Lisp you can
manipulate code with the full power of the language - and live!
It is a programmable programming language with a relatively
simple model.
At some point you need to make use of code is data is code is data.
Think about the consequences of this!
Slobodan Blazeski
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> I have given SLIME a good try, but it's too unlike the tools I use
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
corporation to develop the IDE and in days like today after 14
restarts of the Visual Studio I think that's an advantage rather then
a deficit..
BTW lispworks has an windows mode if you're used to win shortcuts
rather then emacs ones but you're doing yourself a bad favor. I never
liked emacs but I've learned to tolerate it. If you don't plan to buy
lw or acl I suggest to spent some time learning basic emacs and or
even better use the slime.
Slobodan
>
> Thanks, CC.
Ron Garret
Tim Bradshaw <t...@tfeb.org> wrote:
Here's the full history (and I know this because I've personally used
every product in the chain):
What is now Clozure Common Lisp started in 1986 as Coral Common Lisp
(not coincidentally also CCL). CCL 1.0 was released in 1987. It ran on
a Macintosh Plus with 1 MB of RAM. I wrote the code for my master's
thesis on this system. (NB: The power of that system relative to the
hardware it ran on has IMO never been surpassed. It was a full Common
Lisp IDE running on hardware that had a tiny fraction of the computing
power of an iPhone.)
CCL was briefly renamed Macintosh Allegro Common Lisp in a short-lived
joint venture with Franz, Inc. It was then acquired by Apple and
renamed Macintosh Common Lisp (MCL) in 1989. MCL was spun off to an
independent company called Digitool in 1994.
In 1997 or so, I hired Gary Byers, author of the MCL compiler among
other things, to work for me at JPL to port MCL to run under the vxWorks
operating system as part of an effort to get Lisp to run on a
spacecraft. (That effort was ultimately successful, but the Lisp that
flew was Harlequin, not MCL. To this day I believe that decision was a
mistake. But that's another story.) Along the way he also ported MCL
to run under Linux and Solaris. Gary is truly one of the great unsung
heros of the Lisp world.
Gary left JPL around 1999, and shortly thereafter managed to convince
Digitool to open-source his ports. Those ports included the core Lisp,
but not the IDE, which depended heavily on the peculiar architecture of
Mac OS (classic/carbon, not OS X). That fork was named OpenMCL, despite
the fact that it ran on just about everything *except* a Macintosh.
The current Clozure Common Lisp is the result of extensive develoment on
the OpenMCL fork. It has come full-circle by running under OS X, with a
new Cocoa-based IDE based on the Hemlock editor. I've been noodling
around with it for several months, and it kicks major ass. It has a
solid FFI, including an objective-C bridge that give you direct access
to Cocoa. It also has native threads. The base Lisp runs on Linux and
Windows, so you can use it to write server code. CCL has prompted me to
switch my primary development back to Lisp after wandering for many
years in the Python wilderness.
FWIW, I've spent more time programming in Lisp than any other language.
But I've never used Slime. So it can be done, and done productively.
(I do use emacs, but I'm far from what you'd call a power user.)
rg
P.S. The latest MCL was recently open-sourced and ported to run under
Rosetta, so the original MCL environment is now universally accessible
on OS X as well. (Before, you needed a PPC Mac to run it. CCL has a
native Intel compiler for both 32 and 64 bit environments, but that
compiler has never been back-ported to MCL. Because MCL is based on the
now-obsolete carbon environment its useful days are numbered.)
Paul Donnelly
Ron Garret
<434340d0-8a34-4909...@37g2000yqp.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
> On Jun 29, 3:00�pm, Ron Garret <rNOSPA...@flownet.com> wrote:
> > I have always thought that saving Lisp code in files is a mistake. �
> > Files are good for saving text, but Lisp code isn't text, it's
> > S-expressions. �S-expressions can be serialized as text, but they are
> > not themselves text, and rendering them non-volatile by storing their
> > serializations in a file seems like a Horrible Hack.
>
> How then would you save the code that you write, other than in a file?
I'd put it in a database.
> A file is everything, a document, a glob of binary data (like a
> picture, a sound file, or a binary), directory, device, printer,
> modem, network node -- there is nothing that it is not a file.
If that were true there would be no need for databases.
A file is an unstructured sequence of bytes rendered to non-volatile
storage. There are many things that are not sequences of bytes,
including nearly all data structures, and particularly including
S-expressions. This is one of the key differences in mindset that
separates Lisp from all other programming languages. There is a
*fundamental* difference between the string "(foo baz bar)" and the
S-expression (foo baz bar). The former is a vector of 13 characters.
The latter is not a vector at all. It's a completely different animal.
> Surely you don't mean that you type the code into memory every time
> you want to run an application, do you?
No, of course not.
> If so, this is just too, too weird.
We're not masochists here. Lisp is weird, but it's not that weird.
rg
Thomas A. Russ
> On Jun 29, 3:00��pm, Ron Garret <rNOSPA...@flownet.com> wrote:
> > I have always thought that saving Lisp code in files is a mistake. ��
> > Files are good for saving text, but Lisp code isn't text, it's
> > S-expressions. ��S-expressions can be serialized as text, but they are
> > not themselves text, and rendering them non-volatile by storing their
> > serializations in a file seems like a Horrible Hack.
>
> How then would you save the code that you write, other than in a file?
There actually have been system that work somewhat like what Ron
suggests. Instead of manipulating the text, they would directly
manipulate the s-expressions, which would be stored in something more
like a database.
Your experience is much more database-like rather than file-based. Just
like you don't generally worry about file structure when trying to write
new values into a database table, with an s-expression store, you
wouldn't worry about the file-like interface.
Ron Garret
Ron Garret <rNOS...@flownet.com> wrote:
> In article
> <434340d0-8a34-4909...@37g2000yqp.googlegroups.com>,
> ccc31807 <cart...@gmail.com> wrote:
>
> > On Jun 29, 3:00�pm, Ron Garret <rNOSPA...@flownet.com> wrote:
> > > I have always thought that saving Lisp code in files is a mistake. �
> > > Files are good for saving text, but Lisp code isn't text, it's
> > > S-expressions. �S-expressions can be serialized as text, but they are
> > > not themselves text, and rendering them non-volatile by storing their
> > > serializations in a file seems like a Horrible Hack.
> >
> > How then would you save the code that you write, other than in a file?
>
> I'd put it in a database.
I should add that this is speculative. No Lisp environment actually
does this. But it wouldn't be very hard to do, at least not technically.
rg
Paul Donnelly
> On Jun 29, 3:00 pm, Ron Garret <rNOSPA...@flownet.com> wrote:
>> I have always thought that saving Lisp code in files is a mistake.
>> Files are good for saving text, but Lisp code isn't text, it's
>> S-expressions. S-expressions can be serialized as text, but they are
>> not themselves text, and rendering them non-volatile by storing their
>> serializations in a file seems like a Horrible Hack.
>
> How then would you save the code that you write, other than in a file?
>
> A file is everything, a document, a glob of binary data (like a
> picture, a sound file, or a binary), directory, device, printer,
> modem, network node -- there is nothing that it is not a file.
I think he refers to saving code in plain text source files.
> Surely you don't mean that you type the code into memory every time
> you want to run an application, do you?
More likely a Smalltalk-style system where code is developed in a
running Lisp image (more or less like usual), but where care is taken to
retain enough information about your code that you can go back and edit
it (unlike many Lisps, which retain only information they require
internally, since it's assumed your code is stored in source
files). You'd save your image instead of saving source files. Check out
Squeak Smalltalk if you'd like to see a system that works in this way.
I think there was a Lisp dialect that did this, but I'm not old enough
to know anything about it. InterLisp, perhaps?
Jimmy Miller
> In article <rNOSPAMon-574CB9.14524329062...@news.albasani.net>,
> Ron Garret <rNOSPA...@flownet.com> wrote:
>
> > In article
> > <434340d0-8a34-4909-a256-6492df25f...@37g2000yqp.googlegroups.com>,
> > ccc31807 <carte...@gmail.com> wrote:
>
> > > On Jun 29, 3:00 pm, Ron Garret <rNOSPA...@flownet.com> wrote:
> > > > I have always thought that saving Lisp code in files is a mistake.
> > > > Files are good for saving text, but Lisp code isn't text, it's
> > > > S-expressions. S-expressions can be serialized as text, but they are
> > > > not themselves text, and rendering them non-volatile by storing their
> > > > serializations in a file seems like a Horrible Hack.
>
> > > How then would you save the code that you write, other than in a file?
>
> > I'd put it in a database.
>
> I should add that this is speculative. No Lisp environment actually
> does this. But it wouldn't be very hard to do, at least not technically.
>
> rg
It's a very interesting concept. I think I'd like to try this style
of development for my next project, where I write a small db for
storing s-expressions and then solely interact with it through the
REPL. It might make one structure code more carefully, so that it is
more amenable to being manipulated algorithmically; and if all your
code is so easy to manipulate, who knows how much of the development
process you could automate...
Speculative, but interesting.
Rob Warnock
+---------------
| Tim Bradshaw <t...@tfeb.org> writes:
| > I suspect (but am not sure) that one of the emacs vi-modes should work
|
| Viper-mode seems solid to me.
The last time I tried to learn Emacs, Vi mode was a *major* mode
[not a minor mode], and thus cannot be used while in Lisp mode.
Has that changed?!?
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul Donnelly
> Paul Donnelly <paul-d...@sbcglobal.net> wrote:
> +---------------
> | Tim Bradshaw <t...@tfeb.org> writes:
> | > I suspect (but am not sure) that one of the emacs vi-modes should work
> | > OK with SLIME. ...
> |
> | Viper-mode seems solid to me.
> +---------------
>
> The last time I tried to learn Emacs, Vi mode was a *major* mode
> [not a minor mode], and thus cannot be used while in Lisp mode.
> Has that changed?!?
Well, let's see... I don't actually use it myself, but cursory testing
indicates it works passably well, at least. I can hjkl around, compile
sexps with C-c C-k, toggle into insert mode, and see parameter lists in
the minibuffer as usual.
Keep in mind, this is viper-mode and not vi-mode, which also exists but
is different. Viper-mode uses some black magic to become omnipresent in
every new buffer, and you have to use the special viper-go-away command
to escape, although you can toggle it per-buffer with toggle-viper-mode.
It manages to leave Emacs functions generally unclobbered, except for
the things necessary for a vi to have.
Don Geddis
> On Jun 29, 3:00�pm, Ron Garret <rNOSPA...@flownet.com> wrote:
>> I have always thought that saving Lisp code in files is a mistake. �
>> Files are good for saving text, but Lisp code isn't text, it's
>> S-expressions. �S-expressions can be serialized as text, but they are
>> not themselves text, and rendering them non-volatile by storing their
>> serializations in a file seems like a Horrible Hack.
>
> How then would you save the code that you write, other than in a file?
Object-Oriented Database, for example.
> A file is everything, a document, a glob of binary data (like a picture, a
> sound file, or a binary), directory, device, printer, modem, network node
> -- there is nothing that it is not a file.
It is possible to map a lot of different concepts into a single structure,
"the file system". But that is not the only way, for every concept, nor is
it the best way, for some concepts.
Would it help you if Ron had talked about writing a payroll system, and
instead said that "I have always thought that saving payroll data in files
is a mistake. [...]" Would you have similarly responded, "How then would
you save the data, other than in a file?"
If someone invented the idea of a database, and then later the uniform
SQL interface to querying it, would have any idea how to evaluate that
suggestion, compared to "saving the data in a file"?
> Surely you don't mean that you type the code into memory every time
> you want to run an application, do you?
You seem to have skipped a bunch of content that Ron wrote above. For
example, he said
Files are good for saving text, but Lisp code isn't text
Does that statement mean anything to you? In what way is Lisp code
different from text? What is lost, when going from Lisp code, to text
in a file, and then back to Lisp code again?
In any case, the answer to your final question here is: OF COURSE Ron
doesn't want to type the code in every time; he wants to save it to some
"non-volatile" form ... but using a method OTHER than (and presumably
better than) "storing their serializations in a file".
Is it really the case, that you can think of no other possible way of saving
code? For you, it's either storing it in a text file, or typing it in again
from scratch each time?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Outside of a dog, a book is a man's best friend.
Inside of a dog, it's too dark to read.
-- Groucho Marx, 1890-1977
Rob Warnock
| > The last time I tried to learn Emacs, Vi mode was a *major* mode
| > [not a minor mode], and thus cannot be used while in Lisp mode.
| > Has that changed?!?
|
| Well, let's see... I don't actually use it myself, but cursory testing
| indicates it works passably well, at least. I can hjkl around, compile
| sexps with C-c C-k, toggle into insert mode, and see parameter lists in
| the minibuffer as usual.
|
| Keep in mind, this is viper-mode and not vi-mode, which also exists but
| is different. Viper-mode uses some black magic to become omnipresent in
| every new buffer, and you have to use the special viper-go-away command
| to escape, although you can toggle it per-buffer with toggle-viper-mode.
| It manages to leave Emacs functions generally unclobbered, except for
| the things necessary for a vi to have.
Good to know, thanks!!
[Time for another go at Emacs, it seems...]
Vassil Nikolov
On Mon, 29 Jun 2009 17:08:27 -0500, Paul Donnelly <paul-d...@sbcglobal.net> said:
> ...
> I think there was a Lisp dialect that did this, but I'm not old enough
> to know anything about it. InterLisp, perhaps?
What did they call the condition of coming up with a non-recreatable
(or hard-to-recreate) image, i.e. the condition of having lost the
ability to bootstrap oneself to the current state of the world?
---Vassil.
P.S. Speaking of "retrograde": Algol, which was born in the same
year as Lisp, was famously said to be an improvement on many of its
successors... Caveant linguarum auctores.
--
Vassil Nikolov <vnik...@pobox.com>
(1) M(Gauss);
(2) M(a) if M(b) and declared(b, M(a)),
where M(x) := "x is a mathematician".
Thomas M. Hermann
> On Jun 29, 11:13 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>> I think most folks would suggest that you use SLIME. Yes, emacs is very
>> unlike Visual Studio or Eclipse, but there are good reasons for most of
>> the differences and historical reasons for most the the rest.
>
> I'm in the IT department of a large public university, working as a
> database manager. I frequently write little scripts that munge data. I
> have written in Java, C, C++, but mostly I use Perl -- in fact I find
> myself writing Perl perhaps two hours a day on a light day and eight
> hours on a heavy day. As an editor, I use vi, and over the years have
> become quite proficient in vi.
>
> I'm now working through the 3rd edition of Winston and Horn using
> SLIME, and continue to be frustrated by the environment. Maybe it will
> take a lot of time getting used to it, and maybe in time I'll become
> proficient with it, but I still resent the fact that learning my LOTY
> (CL) means fighting with the implementation.
Before learning lisp, I was exclusively a VI user, so I can sympathize.
When I started to study lisp, it quickly became clear that in the open
source world, there really is no substitute for EMACS+SLIME. I don't
have a lot of experience with commercial lisps, although I am in the
process of trying to learn enough LispWorks to take advantage of CAPI
and be able to deliver commercial applications. Regardless, my primary
development environment is EMACS+SLIME.
Since then, I have seen some attempts to better integrate lisp with VIM.
Having become entirely accustomed to EMACS, I've not tried any of them.
I think the best one is called LIMP.
http://www.vim.org/scripts/script.php?script_id=2219
I wasn't able to review that page because it seems the MySQL backend to
the VIM website is puking chunks. Anyway, I recommend using EMACS+SLIME,
it's worth the effort. But, if you really must use VI, the LIMP
extension to VIM may be your best bet.
Good luck,
Tom
[ Rest of message snipped ]
Paul Donnelly
> On Mon, 29 Jun 2009 17:08:27 -0500, Paul Donnelly
> <paul-d...@sbcglobal.net> said:
>> ...
>> I think there was a Lisp dialect that did this, but I'm not old enough
>> to know anything about it. InterLisp, perhaps?
>
> What did they call the condition of coming up with a non-recreatable
> (or hard-to-recreate) image, i.e. the condition of having lost the
> ability to bootstrap oneself to the current state of the world?
“Embarrasing”?
It's not obvious to me how this would be a big issue. For your own
purposes there's no reason to recreate the image, because you've already
got it. For distribution, you'd serialize the code from an up-to-date
image, which would be loaded by the client. That's how Squeak operates;
it can spit out your object and method definitions as moderately
readable plain text, but the only purpose for this feature is to
distribute code. Actually defining things is done from the GUI.
I suppose it's possible to program yourself into a corner. I'd hope
you've got backups, integrated version control, and tools for inspecting
unbootable images to get you out of that mess.
Vassil Nikolov
On Mon, 29 Jun 2009 21:16:30 -0500, Paul Donnelly <paul-d...@sbcglobal.net> said:
> Vassil Nikolov <vnik...@pobox.com> writes:
>> On Mon, 29 Jun 2009 17:08:27 -0500, Paul Donnelly
>> <paul-d...@sbcglobal.net> said:
>>> ...
>>> I think there was a Lisp dialect that did this, but I'm not old enough
>>> to know anything about it. InterLisp, perhaps?
>>
>> What did they call the condition of coming up with a non-recreatable
>> (or hard-to-recreate) image, i.e. the condition of having lost the
>> ability to bootstrap oneself to the current state of the world?
> “Embarrasing”?
> It's not obvious to me how this would be a big issue. For your own
> purposes there's no reason to recreate the image, because you've already
> got it.
There may well be better examples, but what if my lisp
process---under my wise leadership---went from state S0 to state S1,
there being no saved image newer than S0, and S1 is messed up (no
point in saving it), so I actually want S1', somewhat different from
S1, but I cannot get from S1 to S1' and I don't know (any more) how
to get from S0 to S1'? I _think_ things like that did happen with
Interlisp, and I think there was a name for this condition, but I
forget where I read about it or how to search for that source now.
Perhaps someone who knows will chime in.
---Vassil.
Vassil Nikolov
On Mon, 29 Jun 2009 08:43:50 -0700 (PDT), ccc31807 <cart...@gmail.com> said:
> ... still drop into the DOS prompt
Use S/360?! No, that cannot be...
Paul Donnelly
> On Mon, 29 Jun 2009 21:16:30 -0500, Paul Donnelly <paul-d...@sbcglobal.net> said:
>
>> Vassil Nikolov <vnik...@pobox.com> writes:
>>> On Mon, 29 Jun 2009 17:08:27 -0500, Paul Donnelly
>>> <paul-d...@sbcglobal.net> said:
>>>> ...
>>>> I think there was a Lisp dialect that did this, but I'm not old enough
>>>> to know anything about it. InterLisp, perhaps?
>>>
>>> What did they call the condition of coming up with a non-recreatable
>>> (or hard-to-recreate) image, i.e. the condition of having lost the
>>> ability to bootstrap oneself to the current state of the world?
>
>> “Embarrasing”?
>
>> It's not obvious to me how this would be a big issue. For your own
>> purposes there's no reason to recreate the image, because you've already
>> got it.
>
> There may well be better examples, but what if my lisp
> process---under my wise leadership---went from state S0 to state S1,
> there being no saved image newer than S0, and S1 is messed up (no
> point in saving it), so I actually want S1', somewhat different from
> S1, but I cannot get from S1 to S1' and I don't know (any more) how
> to get from S0 to S1'?
I see. I thought you were talking about having a desirable, hopefully
bootable, image that you couldn't recreate elsewhere or recover if you
borked it in some way (without making a big change to its state).
I'm sure what you describe can happen easily, but I don't see how it's
any different from having a set of source files, editing and saving them
for a while, then realizing your last backup is from two days ago and
you've wrecked your intermediate work. Just another argument for a VCS,
in my book.
I'd be interested in knowing what the word for that condition was as
well.
Robert Uhl
>
> | > The last time I tried to learn Emacs, Vi mode was a *major* mode
> | > [not a minor mode], and thus cannot be used while in Lisp mode.
> | > Has that changed?!?
> |
> | Well, let's see... I don't actually use it myself, but cursory
> | testing indicates it works passably well, at least. I can hjkl
> | around, compile sexps with C-c C-k, toggle into insert mode, and see
> | parameter lists in the minibuffer as usual.
> |
> | Keep in mind, this is viper-mode and not vi-mode, which also exists
> | but is different. Viper-mode uses some black magic to become
> | omnipresent in every new buffer, and you have to use the special
> | viper-go-away command to escape, although you can toggle it
> | per-buffer with toggle-viper-mode. It manages to leave Emacs
> | functions generally unclobbered, except for the things necessary for
> | a vi to have.
>
>
> [Time for another go at Emacs, it seems...]
Well, I like emacs a _lot_, but loathe as I am to turn away a potential
convert I don't know that it's likely to meet your needs if you want to
use it as a better-vi-than-vi--frankly, I doubt it can be that. What I
mean is that while it's certainly _possible_ to use emacs as a kind of
vi, I don't think it's very good at that task.
IMHO viper-mode is best looked at as a kind of training wheels to help
convert over to doing things the emacs way, not as a long-term solution.
Best of luck though! I think you'll find that emacs has a lot to like,
although of course it's pretty different at first.
--
Robert Uhl
Pascal J. Bourguignon
Yes of course, that would be the ideal.
The problem you see is that you have been brainwashed into thinking
that it's normal for a computer to loose its memory for any reason,
because of another program error, or because of a power loss.
But it doesn't have to be that way. An error in a lisp program
doesn't lead to memory corruption. And customers could expect
computers not losing their memory on power loss (well, there are
optional UPS, but this could be built into the CPU).
So indeed, you just type the code into the memory. And when your lisp
VM has the unfortune of being run over a lesser VM such as unix (or
MS-Windows, which is not better), then we can save the lisp VM memory
image into a unix file, since that's all that unix can persist.
Next time you get some power, you can relaunch the lisp VM with some
saved lisp image, so you get back to the point you where before the
power loss.
Type: #+clisp (describe 'ext:saveinitmem)
--
__Pascal Bourguignon__
Pascal J. Bourguignon
The problem is (FUNCTION-LAMBDA-EXPRESSION ...) -> NIL.
But if you correct this bug, image based programming is no problem.
--
__Pascal Bourguignon__
Rob Warnock
| > | but is different. Viper-mode uses some black magic to become
...
| > Good to know, thanks!!
| > [Time for another go at Emacs, it seems...]
|
| Well, I like emacs a _lot_, but loathe as I am to turn away a potential
| convert I don't know that it's likely to meet your needs if you want to
| use it as a better-vi-than-vi--frankly, I doubt it can be that. What I
| mean is that while it's certainly _possible_ to use emacs as a kind of
| vi, I don't think it's very good at that task.
|
| IMHO viper-mode is best looked at as a kind of training wheels to help
| convert over to doing things the emacs way, not as a long-term solution.
Hmmm... Thanks for your frankness. In fact, I am *not* looking for
"training wheels to help convert"; I'm looking for a natural way
(if one exists) to use SLIME while continuing to use a "moded" editor.
I've been using moded editors [that is, ones with an "insert mode"
and a "command mode"] since forever: first TECO (on multiple platforms),
then Bravo (Xerox Alto), then Vi (on everything else). I *like* having
separate insert & command modes, so that most editing commands are
single un-shifted characters [and those that aren't are single-shifted
with the other hand]. Conversely, Emacs's "chords" hurt my fingers.
[Literally.]
I was hoping that Emacs + Viper-mode would be usable long-term as a
near-identical replacement for Vi [at least for the typing/editing
functions]. If not, oh, well, I'll stick with what I have. Which isn't
that bad, actually. It's actually quite easy to edit Lisp in Vi, if
one sets one's options correctly -- ":set ai sw=1 sm matchtime=2 icl"
is a good start.
+---------------
| Best of luck though! I think you'll find that emacs has a lot
| to like, although of course it's pretty different at first.
+---------------
The other possibility is gluing a SWANK backend onto Vi, or maybe
using one of the backends available for Vim. Or something... ;-}
ACL
> On Mon, 29 Jun 2009 21:16:30 -0500, Paul Donnelly <paul-donne...@sbcglobal.net> said:
>
> > Vassil Nikolov <vniko...@pobox.com> writes:
> >> On Mon, 29 Jun 2009 17:08:27 -0500, Paul Donnelly
> >> <paul-donne...@sbcglobal.net> said:
> >>> ...
> >>> I think there was a Lisp dialect that did this, but I'm not old enough
> >>> to know anything about it. InterLisp, perhaps?
>
> >> What did they call the condition of coming up with a non-recreatable
> >> (or hard-to-recreate) image, i.e. the condition of having lost the
> >> ability to bootstrap oneself to the current state of the world?
> > “Embarrasing”?
> > It's not obvious to me how this would be a big issue. For your own
> > purposes there's no reason to recreate the image, because you've already
> > got it.
>
> There may well be better examples, but what if my lisp
> process---under my wise leadership---went from state S0 to state S1,
> there being no saved image newer than S0, and S1 is messed up (no
> point in saving it), so I actually want S1', somewhat different from
> S1, but I cannot get from S1 to S1' and I don't know (any more) how
> to get from S0 to S1'? I _think_ things like that did happen with
> Interlisp, and I think there was a name for this condition, but I
> forget where I read about it or how to search for that source now.
> Perhaps someone who knows will chime in.
>
> ---Vassil.
>
> --
>
> (1) M(Gauss);
> (2) M(a) if M(b) and declared(b, M(a)),
> where M(x) := "x is a mathematician".
I believe the technical term is f*cked.
Although I would guess that if you were dribbling your repl to a file
and had a previous image you would just be able to re-execute the
dribble up until the point at which you f*cked yourself.
It would be sort of like using a transactional database instead of a
commit based system.
ACL
> 'Best' defined as an environment most like one that an experienced
> programmer would be familiar with. This would include Eclipse, Visual
> Studio, and (perhaps most commonly) a plain text editor combined with
> gcc, g++, javac, etc.
>
> most often for me to feel comfortable with it. I have tried LispWorks
> and CLISP in a command interpreter (shell), but these still feel
> awkward. I'm not particularly looking for a GUI based environment,
> e.g. VS, but I'm finding that fighting with the environment is getting
> in the way of using Lisp.
>
I dunno if anyone posted this yet, but there is Limp,
which is a slime-like extension for vim. (link follows)
http://www.vim.org/scripts/script.php?script_id=2219
I've never used it as I just went ahead and learned key-chords and
emacsen-fu,
but might give it a look if you are really that much of an old dog...
Thomas F. Burdick
> Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> +---------------
I don't see why it Viper wouldn't fit what you're looking for. As a vi
replacement for programmers, it should be fine, and I disagree
completely with Robert Uhl. For sysadmins, it would suffer from the
usual Emacs issue of being big and slow to start up.
Raffael Cavallaro
> http://lispm.dyndns.org/news?ID=NEWS-2005-07-08-1
>
> See the video link at the end of above page. It is not SLIME, but
> LispWorks. But it will give you an idea why things work a little bit
> different than you might be used to. ;-)
fwiw, I highly recommend this video for anyone interested in lisp
metaprogramming in a very practical, hands-on example.
--
Raffael Cavallaro
Michael Livshin
> I don't see why it Viper wouldn't fit what you're looking for. As a vi
> replacement for programmers, it should be fine, and I disagree
> completely with Robert Uhl. For sysadmins, it would suffer from the
> usual Emacs issue of being big and slow to start up.
and since the usual Vi these days is actually Vim, the above usual issue
is not actually an issue any more.
Stelian Ionescu
> I don't see why it Viper wouldn't fit what you're looking for. As a vi
> replacement for programmers, it should be fine, and I disagree
> completely with Robert Uhl. For sysadmins, it would suffer from the
> usual Emacs issue of being big and slow to start up.
Lies, nothing but lies ! With the new daemon mode(emacs --daemon) and
emacsclient -t(tty mode), emacs spawns a new (terminal) frame faster than
vim(haven't tried vi).
Furthermore, to ease typing I have in .bashrc alias ed="emacsclient -t".
Vi(m) can eat my shorts :P
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
Robert Uhl
Wow--you're right. On my machine, I can run emacs --no-init then C-x
C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
Of course, emacs with my normal .emacs takes 2.853 seconds...
--
Robert Uhl <http://public.xdi.org/=ruhl>
If something's expensive to develop, and somebody's not going to get
paid, it won't get developed. So you decide: Do you want software to be
written, or not? --Bill Gates doesn't foresee the FSF or Linux, 1980
Russell McManus
Vassil Nikolov <vnik...@pobox.com> writes:
> There may well be better examples, but what if my lisp
> process---under my wise leadership---went from state S0 to state S1,
> there being no saved image newer than S0, and S1 is messed up (no
> point in saving it), so I actually want S1', somewhat different from
> S1, but I cannot get from S1 to S1' and I don't know (any more) how
> to get from S0 to S1'? I _think_ things like that did happen with
> Interlisp, and I think there was a name for this condition, but I
> forget where I read about it or how to search for that source now.
> Perhaps someone who knows will chime in.
Things like this also happen when using files, although perhaps the
problems one enounters are less serious than the one you describe.
For example it's relatively easy to edit away using slime for a while,
and end up with a bunch of files that can't be compiled and loaded in
any order. The only way to find these problems is to compile and load
into a fresh image occasionally.
-russ
Giorgos Keramidas
> On Jun 29, 12:19�pm, Alberto Riva <a...@nospam.ufl.edu> wrote:
>> > and continue to be frustrated by the environment.
>>
>
> The basic stuff, like,
> - how do you write a file?
Start with:
(describe 'with-open-file)
The ``Practical Common Lisp'' book includes a very good section about
opening files for reading and writing, including such handy details
like:
* How to read a single byte.
* How to loop reading bytes until end-of-file.
* How to read many bytes in one operation, storing the data you read
in a vector of bytes.
* How to write one or multiple bytes.
> - how do you save a file?
There are two levels of `file saving' when you are working in an
environment like SLIME or an IDE:
* How to save the file I am editing now in the IDE.
* How to write code that opens a file for writing, send some data to
the output file, and close it.
> - how do you compile a file?
That's easy. Just type in your Lisp prompt:
(compile-file "~/lisp/filename")
This produces a "fast load" file (fasl) that you can load later, and
returns the pathname of the fasl bytecode file:
bash$ cat foo.lisp
(defun hello-world ()
(princ "Hello world"))
bash$ sbcl
* (compile-file "foo.lisp")
; compiling file "/home/keramida/foo.lisp" (written 30 JUN 2009 08:31:57
PM):
; compiling (DEFUN HELLO-WORLD ...)
; /home/keramida/foo.fasl written
; compilation finished in 0:00:00.121
#P"/home/keramida/foo.fasl"
NIL
NIL
You can load the "foo.fasl" file then:
* (load "foo.fasl")
T
* (hello-world)
Hello world
"Hello world"
*
You can also combine both steps with:
* (load (compile-file "foo.lisp"))
; compiling file "/home/keramida/foo.lisp" (written 30 JUN 2009 08:31:57
PM):
; compiling (DEFUN HELLO-WORLD ...)
; /home/keramida/foo.fasl written
; compilation finished in 0:00:00.039
T
> - how do you run a script?
> - how do you recover from an errir?
Lisp includes an extensive system of conditions, errors, handlers and
restarts. It is far more elaborate than any other system I have seen,
but it also takes a bit of reading to get used to the way it works.
The ``Practical Common Lisp'' book describes a *lot* of the mechanisms
you can use to handle errors, or other sorts of exceptional conditions.
It will help a lot if you read the relevant bits from the book :)
> I still don't know how to write and save a file in SLIME, although I
> have figured out how to compile, load, and run a script in SLIME.
> However, when my script hangs, all I know how to do is kill the
> process and start a new one, which takes time and frustrates the heck
> out of me.
Most of the scripting languages in wide use today favor a sort of
programming that is a bit un-Lispy, using a repetitive cycle of edit,
save, run script, stare at debugging output, repeat. Lisp supports that
sort of programming too, as you have found out, but you are missing out
a *lot* of its power if you have to restart every time something odd
happens.
Most of the power of having a full Lisp at your user-interaction prompt
comes from a different sort of programming: an incremental way of ``REPL
sessions''. Instead of saving a short script and running Lisp with the
script as input, you directly enter forms at the REPL prompt and watch
for ``interesting'' things that happen as you define, redefine, extend
and experiment with the code already loaded in your Lisp image.
This is a departure from the usual cycle of edit, save, compile, run,
look at debugging output, repeat. It may seem a bit ``alien'' at first,
but it's worth trying. It may seem quite useful after a while :)
Rob Warnock
+---------------
| >> For sysadmins, it would suffer from the
| >> usual Emacs issue of being big and slow to start up.
| >
| > and since the usual Vi these days is actually Vim, the above usual
| > issue is not actually an issue any more.
|
| Wow--you're right. On my machine, I can run emacs --no-init then C-x
| C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
| Of course, emacs with my normal .emacs takes 2.853 seconds...
Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
On my laptop, Vi (nvi-1.79) takes 0.83 s to
start up & exit the first time; only 7 ms thereafter!!
Rob Warnock
+---------------
| ccc31807 <cart...@gmail.com> wrote:
| > ... I have figured out how to compile, load, and run a script in SLIME.
| > However, when my script hangs, all I know how to do is kill the
| > process and start a new one, which takes time and frustrates the heck
| > out of me.
|
| Most of the scripting languages in wide use today favor a sort of
| programming that is a bit un-Lispy, using a repetitive cycle of edit,
| save, run script, stare at debugging output, repeat. Lisp supports that
| sort of programming too, as you have found out, but you are missing out
| a *lot* of its power if you have to restart every time something odd
| happens.
|
| Most of the power of having a full Lisp at your user-interaction prompt
| comes from a different sort of programming: an incremental way of ``REPL
| sessions''. Instead of saving a short script and running Lisp with the
| script as input, you directly enter forms at the REPL prompt and watch
| for ``interesting'' things that happen as you define, redefine, extend
| and experiment with the code already loaded in your Lisp image.
It is possible to combine these modes to one's benefit, provided that
you write your "scripts" in a way that cooperates with your development
environment. Simply find *something* that is different when the script is
run standalone versus when you're debugging and LOAD the script into your
Lisp (either a raw REPL or via SLIME or some IDE, etc.). For example, in
my personal environment it's whether or not the keyword :REPL is present
in the list in the global variable EXTENSIONS:*SCRIPT-EXIT-HOOKS*.[1]
So I conventionally write all my scripts to *not* do anything in
top-level forms that is likely to be dangerous or have problems,
but rather just define functions, ending with a (DEFUN MAIN () ...).
Then at the very end of each script, there's this snippet:
(unless (find :repl ext:*script-exit-hooks*) ; Debugging?
(main)) ; No, just run & exit.
So if one LOADs the script, it does nothing but define variables
[with "safe", idempotent values] and functions. You can then examine
or modify the variables and call the functions and so forth until
the script is thoroughly debugged. It should then execute correctly
when run standalone.
[The environment in your Lisp will require a different test,
but the general principle should apply, mutatis mutandis...]
-Rob
[1] My scripts use the hack I added to CMUCL:
http://rpw3.org/hacks/lisp/site-switch-script.lisp
which allows you to run scripts that start like this:
#!/usr/local/bin/cmucl -script
The "site-switch-script" code defines a *SCRIPT-EXIT-HOOKS*
variable that says what to do when the script finishes loading.
For scripts that simply exit when done, this will be NIL. For
scripts that want a normal CMUCL REPL to start up after they're
loaded, *SCRIPT-EXIT-HOOKS* will be a list containing the keyword
:REPL in it somewhere. My normal REPL-based debug environment
will have this set [since it's such a script itself!].
Vassil Nikolov
On Tue, 30 Jun 2009 18:32:47 -0500, rp...@rpw3.org (Rob Warnock) said:
> ...
> On my laptop, Vi (nvi-1.79) takes 0.83 s to
> start up & exit the first time; only 7 ms thereafter!!
Is that faster than `ed'?
---Vassil,
who couldn't resist...
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Vassil Nikolov
On Tue, 30 Jun 2009 15:45:10 -0500, Russell McManus <russell...@yahoo.com> said:
> ...
> Things like this also happen when using files, although perhaps the
> problems one enounters are less serious than the one you describe.
> For example it's relatively easy to edit away using slime for a while,
> and end up with a bunch of files that can't be compiled and loaded in
> any order. The only way to find these problems is to compile and load
> into a fresh image occasionally.
Needless for me to say, this is a good point. And yes, it seems to
me that it is easier to fall into such traps when using images than
when using files, but that might be an illusion.
Anyway, what I hoped to find out by following up to this thread was
just the word (or phrase) for that condition, as I believe I have
read it somewhere, but I cannot remember it (I'm sure it wasn't a
past participle, though).
---Vassil.
Rob Warnock
| > On my laptop, Vi (nvi-1.79) takes 0.83 s to
| > start up & exit the first time; only 7 ms thereafter!!
|
| Is that faster than `ed'?
Not even close! The "ed" program takes only ~1 ms to start up & exit
[mode of 500 runs]. Though note that when I run Vi [as "ex"] 500 times
in a row, it takes only ~5 ms, so "ed" is really "only" 5x faster at
startup.
But seriously, any startup time less than ~100ms is negligible to
a human, so who cares? ;-}
Thomas F. Burdick
wrote:
> On Tue, 30 Jun 2009 05:20:51 -0700, Thomas F. Burdick wrote:
> > I don't see why it Viper wouldn't fit what you're looking for. As a vi
> > replacement for programmers, it should be fine, and I disagree
> > completely with Robert Uhl. For sysadmins, it would suffer from the
> > usual Emacs issue of being big and slow to start up.
>
> Lies, nothing but lies ! With the new daemon mode(emacs --daemon) and
> emacsclient -t(tty mode), emacs spawns a new (terminal) frame faster than
> vim(haven't tried vi).
> Furthermore, to ease typing I have in .bashrc alias ed="emacsclient -t".
> Vi(m) can eat my shorts :P
Two things: first, unless I'm terribly mistaken, none of the server/
client setups for emacs preserve the properties of the shell that
invoked the editor (uid, gid, umask, etc). That makes them nonstarters
for sysadmin work. Second, vim is not vi. Vi and nvi are small, simple
tools for unix sysadmins. Vim wishes it was emacs (and has the startup
time to match).
Thomas F. Burdick
> Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> +---------------
> | Michael Livshin <use...@cmm.kakpryg.net> writes:
> | >> For sysadmins, it would suffer from the
> | >> usual Emacs issue of being big and slow to start up.
> | >
> | > and since the usual Vi these days is actually Vim, the above usual
> | > issue is not actually an issue any more.
> |
> | Wow--you're right. On my machine, I can run emacs --no-init then C-x
> | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
> | Of course, emacs with my normal .emacs takes 2.853 seconds...
> +---------------
>
> Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
> On my laptop, Vi (nvi-1.79) takes 0.83 s to
> start up & exit the first time; only 7 ms thereafter!!
Not to argue against the venerable usenet tradition of discussions
that go flying off on a random tangent ... but weren't we talking
about whether Emacs+Slime+Viper could serve as a modal IDE? For this
purpose, you would *not* want to be constantly starting and shutting
down your editor: you want it to stay connected to the Lisp :-)
Rob Warnock
+---------------...
| > | Wow--you're right. �On my machine, I can run emacs --no-init then C-x
| > | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
| > | Of course, emacs with my normal .emacs takes 2.853 seconds...
| > +---------------
| >
| > Which is why I use real Vi, and *NOT* Vim!! �;-} �;-}
| > On my laptop, Vi (nvi-1.79) takes 0.83 s to
| > start up & exit the first time; only 7 ms thereafter!!
|
| Not to argue against the venerable usenet tradition of discussions
| that go flying off on a random tangent ... but weren't we talking
| about whether Emacs+Slime+Viper could serve as a modal IDE? For this
| purpose, you would *not* want to be constantly starting and shutting
| down your editor: you want it to stay connected to the Lisp :-)
Yes, of course, thanks for dragging us back on-topic. [I'm afraid
I let myself get dragged down the "startup time" rathole... (*sigh*)]
And it wasn't quite "whether Emacs+Slime+Viper could serve as a
modal IDE", but "whether Emacs+Slime+Viper could serve as a Lisp IDE
with a modal editor even when editing Lisp". I know the difference
may sound subtle, but it's important. I have no problems using Emacs
chords -- or, better, M-x long-commands -- for the IDE functions.
I just want navigation/insertion/editing to work like Vi (modal editing).
Giorgos Keramidas
> Giorgos Keramidas <kera...@ceid.upatras.gr> wrote:
> | Most of the scripting languages in wide use today favor a sort of
> | programming that is a bit un-Lispy, using a repetitive cycle of edit,
> | save, run script, stare at debugging output, repeat. Lisp supports that
> | sort of programming too, as you have found out, but you are missing out
> | a *lot* of its power if you have to restart every time something odd
> | happens.
> |
> | Most of the power of having a full Lisp at your user-interaction prompt
> | comes from a different sort of programming: an incremental way of ``REPL
> | sessions''. Instead of saving a short script and running Lisp with the
> | script as input, you directly enter forms at the REPL prompt and watch
> | for ``interesting'' things that happen as you define, redefine, extend
> | and experiment with the code already loaded in your Lisp image.
>
> you write your "scripts" in a way that cooperates with your development
> environment. Simply find *something* that is different when the script is
> run standalone versus when you're debugging and LOAD the script into your
> Lisp (either a raw REPL or via SLIME or some IDE, etc.). For example, in
> my personal environment it's whether or not the keyword :REPL is present
> in the list in the global variable EXTENSIONS:*SCRIPT-EXIT-HOOKS*.[1]
>
> So I conventionally write all my scripts to *not* do anything in
> top-level forms that is likely to be dangerous or have problems,
> but rather just define functions, ending with a (DEFUN MAIN () ...).
> Then at the very end of each script, there's this snippet:
>
> (unless (find :repl ext:*script-exit-hooks*) ; Debugging?
> (main)) ; No, just run & exit.
Heh! Very neat, thanks :)
ccc31807
Your post illustrates the source of many of my frustrations with the
Lisp environment (as opposed to Lisp itself, which is a separate
issue).
I'm not a total beginner, I have a couple of degrees in CS and a
decade in practical work experience. I've used a number of IDEs for
both work and pleasure, and have played with about a dozen different
languages.
Please see below for my interlined comments.
On Jun 30, 1:43 pm, Giorgos Keramidas <keram...@ceid.upatras.gr>
wrote:
> > - how do you write a file?
>
> Start with:
>
> (describe 'with-open-file)
>
> The ``Practical Common Lisp'' book includes a very good section about
> opening files for reading and writing, including such handy details
> like:
Yes, I purchased the dead tree version of PCL, have skimmed through it
a couple of times, and have worked through the first six or so
chapters. I agree that it contains a very good explanation about
writing and running Lisp. However, I write scripts for a living for
users to use to do useful things, and so far I haven't found anything
that would allow me to write a Lisp script that I can give to a user
to run -- NOTING WITH THANKS several posts earlier in this thread some
information about saving a Lisp image, which I haven't yet had time to
explore in detail.
> There are two levels of `file saving' when you are working in an
> environment like SLIME or an IDE:
>
> * How to save the file I am editing now in the IDE.
>
> * How to write code that opens a file for writing, send some data to
> the output file, and close it.
The second is straight forward. The first depends on the environment,
and wasn't too bad with SLIME, but it's not obvious to an experienced
programmer at first. Almost every step generated a WTF: ^X-^F to open
a file? ^X-2 to create a write window? ^X-O to move from one window to
another? Sometimes Q to exit from a debug window, other times a digit?
Come on guys, give me a break!
> > - how do you compile a file?
>
> That's easy. Just type in your Lisp prompt:
>
> (compile-file "~/lisp/filename")
^C-^K? WTF.
Okay, this is the first time I have seen anything like this, and it
look like generating and running a program in C or Perl or Java. I can
deal with this. I'm wondering now why this kind of information seems
so hard to find. Is it because we assume that anybody with half a wit
already knows it? I have six Lisp books so far (Wilensky, Winston &
Horn, Sieibel, Graham, Lamkins, Friedman & Felliesen) and somehow this
little bit of info hasn't been covered in a direct and to-the-point
manner.
> The ``Practical Common Lisp'' book describes a *lot* of the mechanisms
> you can use to handle errors, or other sorts of exceptional conditions.
> It will help a lot if you read the relevant bits from the book :)
I agree. What it doesn't cover is how I can create JAR file (for
example) and give it to a user than he can use. The fact that it's
written in Java or Lisp or C should not concern the user at all. The
user should be able just to invoke the program (or at worst as for
Perl to invoke a browser to run a CGI-like script.)
> Most of the scripting languages in wide use today favor a sort of
> programming that is a bit un-Lispy, using a repetitive cycle of edit,
> save, run script, stare at debugging output, repeat. Lisp supports that
> sort of programming too, as you have found out, but you are missing out
> a *lot* of its power if you have to restart every time something odd
> happens.
>
> Most of the power of having a full Lisp at your user-interaction prompt
> comes from a different sort of programming: an incremental way of ``REPL
> sessions''. Instead of saving a short script and running Lisp with the
> script as input, you directly enter forms at the REPL prompt and watch
> for ``interesting'' things that happen as you define, redefine, extend
> and experiment with the code already loaded in your Lisp image.
Earlier this year, I worked through Joe Armstrong's 'Programming
Erlang' and saw this in action. I agree with you, to the point that I
posted on another ng that I frequent a question as to why Perl (my
most used language) doesn't have an interactive listener. To those
guys, my question didn't make any sense. Most had no idea what the
term 'interactive listener' meant.
> This is a departure from the usual cycle of edit, save, compile, run,
> look at debugging output, repeat. It may seem a bit ``alien'' at first,
> but it's worth trying. It may seem quite useful after a while :)
I agree. Different languages have their own unique form of idiomatic
development. When I write in Java, I naturally write a test class
BEFORE I write the object classes, so I will have a way to test the
object classes. When I write Perl, I usually follow a comment
translation style of development. I'm beginning to develop an Erlang/
Lisp style that makes heavy use of the REPL.
Still and all, my criticism of the Lisp community as an outsider who
has spent some effort in learning Lisp, is that the community appears
to want to erect barriers to keep people like me on the outside.
Unlike the Perl community, where generally they want to bring people
in as quickly as possible.
Thanks for your post, and the others that have taken the time to post
to this thread.
CC
Rainer Joswig
<1ac1a758-2aaa-4d2f...@l31g2000yqb.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
> > � * (load (compile-file "foo.lisp"))
> >
> > � � ; compiling file "/home/keramida/foo.lisp" (written 30 JUN 2009 08:31:57
> > � � � PM):
> > � � ; compiling (DEFUN HELLO-WORLD ...)
> >
> > � � ; /home/keramida/foo.fasl written
> > � � ; compilation finished in 0:00:00.039
> > � � T
>
> Okay, this is the first time I have seen anything like this, and it
> look like generating and running a program in C or Perl or Java. I can
> deal with this. I'm wondering now why this kind of information seems
> so hard to find. Is it because we assume that anybody with half a wit
> already knows it? I have six Lisp books so far (Wilensky, Winston &
> Horn, Sieibel, Graham, Lamkins, Friedman & Felliesen) and somehow this
> little bit of info hasn't been covered in a direct and to-the-point
> manner.
The 'System Construction Dictionary' of the HyperSpec
gives an overview of the standard functionality:
http://www.lispworks.com/documentation/HyperSpec/Body/c_system.htm
Important are LOAD and COMPILE-FILE.
It is also good to read the manual of the Lisp implementation
you are using, since most have more extensive features
to save images, create executables, create shared libraries,
etc. But this is really covered in the manuals, since
the capabilities are very different from implementation
to implementation. The reason for this is that the implementations
differ widely in their approach: ECL compiles via a C compiler,
SBCL has its own native code compiler, ABCL runs on top
of the JVM, and more.
You can also query your Lisp for information about defined functionality:
To find all symbols with COMPILE in the package CL use:
Command: (apropos "COMPILE" "CL")
Searching the package CL (really FUTURE-COMMON-LISP), including inherited symbols, for symbols containing the substring "COMPILE".
CL:*COMPILE-VERBOSE* - Bound
CL:*COMPILE-FILE-TRUENAME* - Bound
CL:COMPILED-FUNCTION
CL:COMPILE-FILE - Function (INPUT-FILE &key :OUTPUT-FILE (:VERBOSE *COMPILE-VERBOSE*) (:PRINT *COMPILE-PRINT*) (:EXTERNAL-FORMAT :DEFAULT))
CL:COMPILE-FILE-PATHNAME - Function (INPUT-FILE &key :OUTPUT-FILE &allow-other-keys)
LISP:COMPILE - Function (FUNCTION-SPEC &optional LAMBDA-EXP)
CL:COMPILER-MACRO-FUNCTION - Function (NAME &optional ENV)
CL:COMPILER-MACRO
CL:*COMPILE-FILE-PATHNAME* - Bound
CL:COMPILED-FUNCTION-P - Function (X)
CL:DEFINE-COMPILER-MACRO - Function (NAME LAMBDA-LIST &body BODY)
CL:*COMPILE-PRINT* - Bound
'Practical Common Lisp' mentions load and compile-file in chapter 2 in the section 'Saving Your Work':
http://gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html
It is there.
Björn Lindberg
> I agree. What it doesn't cover is how I can create JAR file (for
> example) and give it to a user than he can use. The fact that it's
> written in Java or Lisp or C should not concern the user at all. The
> user should be able just to invoke the program (or at worst as for
> Perl to invoke a browser to run a CGI-like script.)
Here are your options:
1) Deliver shebang scripts. Not all implementations can do this, but I
believe that it is possible with e.g. Clisp. Rob Warnock has a way
of doing this with CMUCL, and it is possible to accomplish with
SBCL too. This requires that the Lisp is present in the system of
course, just like Perl must be present for a Perl script to run.
2) Create stand-alone executables. Again, not all implementations are
capable of this, but several are.
3) Deliver your program as a shell script which in turn invokes the
lisp with either a saved image file, or loading a set of FASL files
or source.
In most cases, if you start by writing the program, come delivery time
you will figure out how to get it to your users.
Bj�rn Lindberg
Robert Uhl
> client setups for emacs preserve the properties of the shell that
> invoked the editor (uid, gid, umask, etc).
I believe that you are correct.
> That makes them nonstarters for sysadmin work.
That's actually immaterial; as with so many other things, using emacs as
a sysadmin requires a different mode of work than does vi.
With vi, one lives in a shell, navigating around--sometimes becoming
other users (normally root)--annd one fires up vi frequently. Fast
startup time is really important here.
With emacs, one lives in emacs, probably with at least one shell session
opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
access files as other users, and to run shells as those other users.
Fast startup time is not so important here, because the emacs session is
persistent.
As a matter of fact, I use both very often. They each have their strong
points. Vi is great for simple line-oriented text editing; it's
particularly good when performing the same actual a limited number of
times (I often wish that emacs had an equivalent to vi's . command).
Emacs is great for structured text editing; it's particularly good at
doing new things, or automating large tedious tasks. Now that more and
more Unix vendors are doing IMHO silly things like using XML instead of
line-oriented formats for config files I anticipate that my usage of
emacs will increase yet more.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Power corrupts. Touching the wrong capacitor corrupts absolutely.
--Anthony de Boer
Pascal J. Bourguignon
>> You can also combine both steps with:
>>
>> � * (load (compile-file "foo.lisp"))
>>
>> � � ; compiling file "/home/keramida/foo.lisp" (written 30 JUN 2009 08:31:57
>> � � � PM):
>> � � ; compiling (DEFUN HELLO-WORLD ...)
>>
>> � � ; /home/keramida/foo.fasl written
>> � � ; compilation finished in 0:00:00.039
>> � � T
>
> Okay, this is the first time I have seen anything like this, and it
> look like generating and running a program in C or Perl or Java. I can
> deal with this. I'm wondering now why this kind of information seems
> so hard to find. Is it because we assume that anybody with half a wit
> already knows it? I have six Lisp books so far (Wilensky, Winston &
> Horn, Sieibel, Graham, Lamkins, Friedman & Felliesen) and somehow this
> little bit of info hasn't been covered in a direct and to-the-point
> manner.
All of these books will introduce you to the REPL, and let you type
code directly at the REPL, which is the appropriate thing to do to
teach you the language and let you try out how it works.
In most implementations you don't really need to explicitely require
compilation, since the REPL compiles what you give it automatically.
Loading a lisp source file is needed only later, when you know enough
of the language to be able to start thinking writing more or less
standalone a program. At that time, you should be proficient enough
with the language to be able to find these operators yourself in the
reference.
>> The ``Practical Common Lisp'' book describes a *lot* of the mechanisms
>> you can use to handle errors, or other sorts of exceptional conditions.
>> It will help a lot if you read the relevant bits from the book :)
>
> I agree. What it doesn't cover is how I can create JAR file (for
> example) and give it to a user than he can use. The fact that it's
> written in Java or Lisp or C should not concern the user at all. The
> user should be able just to invoke the program (or at worst as for
> Perl to invoke a browser to run a CGI-like script.)
The big difference is that:
Perl language Java language Common Lisp language
/usr/bin/perl-5 /usr/bin/java /usr/bin/cmucl
/usr/bin/kaffe /usr/bin/sbcl
/usr/bin/clisp
/usr/bin/gcl
/usr/bin/ecl
/usr/bin/alisp
/usr/bin/abcl
/usr/bin/kcl
/usr/bin/bbncl
...
We couldn't tell you how to generate a .fasl or an executable, because
it depends on the implementation you use. In the case of java or
perl, there's only one way to do anything because these languages are
so poor and uninteresting that there are basically only one
implementation. On the contrary with lisp, there are tens of
implementations, and there are differences of environment and a lot of
additionnal features that are not specified by the standard.
So you have to tell us first what implementation you use, so we can
direct you to the implementation specific user manual or, if you're
nice, tell you directly how to do things in your implementation.
> Still and all, my criticism of the Lisp community as an outsider who
> has spent some effort in learning Lisp, is that the community appears
> to want to erect barriers to keep people like me on the outside.
Be very careful so you don't erect these barriers yourself to your
follower newbies. Take note of everything that bother you, and when
you become proficient with lisp, develop the needed tools and
documentation to help the future newbies circumvents these barriers.
Unfortunately, it's probable that like us, you won't have enough time
to do anything significant...
--
__Pascal Bourguignon__
Robert Uhl
>
> Yes, I purchased the dead tree version of PCL, have skimmed through it
> a couple of times, and have worked through the first six or so
> chapters.
Glad to hear that! PCL is IMHO the best introductory Lisp book out
there; while most other books seem _way_ too beginner-oriented and/or
compare Lisp to Pascal or C, PCL explains things to someone who already
knows what a computer is, and explains why Lisp still has aadvantages
today.
> However, I write scripts for a living for users to use to do useful
> things, and so far I haven't found anything that would allow me to
> write a Lisp script that I can give to a user to run -- NOTING WITH
> THANKS several posts earlier in this thread some information about
> saving a Lisp image, which I haven't yet had time to explore in
> detail.
This page <http://www.xhbml.com/archives/42> has instructions about how
you do it with SBCL. If you have control over the end user's system,
the easiest thing to do is to add those .sbclrc lines to /etc/sbcl.rc.
I found it by Googling 'shell scripts with sbcl,' for whatever that's
worth.
> Almost every step generated a WTF: ^X-^F to open a file? ^X-2 to
> create a write window? ^X-O to move from one window to another?
> Sometimes Q to exit from a debug window, other times a digit? Come on
> guys, give me a break!
C-x is an extended chord which introduces a lot of commands. Remember,
emacs existed before the Macintosh's very limited chord set; it requires
an entirely different suite of chords to do its job. As an example, on
a Macintosh or Windows host one can't go to the beginning or end of a
line, or move forward by s-expression, or incrementally search forward
and backward, with the option of using a regexp.
The end result is that while a Mac might use C-o to open an existing
file and C-n to open a new file, in emacs both functions are the same,
bound to C-x C-f; meanwhile C-o opens a new line and C-n moves to the
next line.
>> > - how do you compile a file?
>>
>> That's easy. Just type in your Lisp prompt:
>>
>> (compile-file "~/lisp/filename")
>
> ^C-^K? WTF.
C-c is an extended chord which introduces a lot of mode-specific
commands--it's appropriate to use it to introduce file compilation in
SLIME.
Emacs is not Eclipse. Those who take the time to learn emacs typically
prefer it, believe it or not: it is different, but more powerful.
[snip load/compilation of files]
> Okay, this is the first time I have seen anything like this, and it
> look like generating and running a program in C or Perl or Java. I can
> deal with this. I'm wondering now why this kind of information seems
> so hard to find. Is it because we assume that anybody with half a wit
> already knows it? I have six Lisp books so far (Wilensky, Winston &
> Horn, Sieibel, Graham, Lamkins, Friedman & Felliesen) and somehow this
> little bit of info hasn't been covered in a direct and to-the-point
> manner.
Read PCL, chapter 2. Under 'Saving Your Work' there are the
instructions for using C-x C-f, and using LOAD, and using COMPILE-FILE
with LOAD, and using C-c C-c and C-c C-k.
It's toward the end of the chapter, but it's all there.
You can see it online at:
<http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html>
> I agree. What it doesn't cover is how I can create JAR file (for
> example) and give it to a user than he can use. The fact that it's
> written in Java or Lisp or C should not concern the user at all. The
> user should be able just to invoke the program (or at worst as for
> Perl to invoke a browser to run a CGI-like script.)
For delivery you have a number of options: you could deliver the source
Lisp files, generally as a tarball; you could compile an executable,
e.g. with SBCL's SAVE-LISP-AND-DIE; you could set up a website, similar
to using CGI; or you could choose to deliver only the FASLs (I think
that works on most/all implementations).
> Still and all, my criticism of the Lisp community as an outsider who
> has spent some effort in learning Lisp, is that the community appears
> to want to erect barriers to keep people like me on the outside.
It used to; I think it's better now. And some of those barriers aren't
barriers at all, but stairways--emacs is an example. It does seem alien
at first, because it _is_ alien. But it turns out that it's actually a
much better way to program than what most folks are used to.
Pascal J. Bourguignon
> It used to; I think it's better now. And some of those barriers aren't
> barriers at all, but stairways--emacs is an example. It does seem alien
> at first, because it _is_ alien. But it turns out that it's actually a
> much better way to program than what most folks are used to.
No, emacs is not alien. It was there first.
The alien UIs are Apple and Microsoft UIs.
--
__Pascal Bourguignon__
Kaz Kylheku
> Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
> +---------------
>| Michael Livshin <use...@cmm.kakpryg.net> writes:
>| >> For sysadmins, it would suffer from the
>| >> usual Emacs issue of being big and slow to start up.
>| >
>| > and since the usual Vi these days is actually Vim, the above usual
>| > issue is not actually an issue any more.
>|
>| Wow--you're right. On my machine, I can run emacs --no-init then C-x
>| C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
>| Of course, emacs with my normal .emacs takes 2.853 seconds...
> +---------------
>
> Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
Good thing you put in those smileys.
nvi real?
nvi is an offshoot of Steve Kirkendall's Elvis, which was first released in
1990. The 1.79 version that is still in wide use, and shipping in OpenBSD and
others dates back to 1997.
This program has nothing to do with any code written by Bill Joy,
which would be the prime requirement for calling anything ``real vi''.
Moolenaar's Vim existed in an unreleased 1.0 form in 1988; but its first public
release was in 1991. It wasn't from scratch, but rather some bugfixes and
enhancements to Stevie, a vi-like editor by Tim Thompson, which was
posted to Usenet in 1987.
So Vim has a more ancient lineage than nvi.
nvi's saving grace is a high degree of compatibility with Unix (TM) vi,
thanks to hacking by Keith Bostic. As far as actual features and ueseability
are concerned, nvi badly sucks compared to later versions of Elvis, and
compared to 1997 vintage Vim.
ccc31807
wrote:
> The big difference is that:
>
> Perl language Java language Common Lisp language
>
> /usr/bin/perl-5 /usr/bin/java /usr/bin/cmucl
> /usr/bin/kaffe /usr/bin/sbcl
> /usr/bin/clisp
> /usr/bin/gcl
> /usr/bin/ecl
> /usr/bin/alisp
> /usr/bin/abcl
> /usr/bin/kcl
> /usr/bin/bbncl
> ...
Point made ... and I'm certainly not going to freak out over the Lisp
landscape.
> In the case of java or
> perl, there's only one way to do anything because these languages are
> so poor and uninteresting that there are basically only one
> implementation.
Whoa, boy! As to poor, we have Java classes coming out of our ears,
and CPAN is an extraordinarily rich resource. I've looked at the free,
available Lisp libraries, and they don't come anywhere near. As to
uninteresting, I agree that Java isn't very interesting, but that's
the point of Java -- to make an uninteresting language, which is
exactly why it has topped the charts for the past decade. As for Perl,
the title of a recent NG thread was this:
'$#{$h{$_}}, $#{@{$h{$_}}}, $#@{$h{$_}}'
Don't tell me that this is uninteresting. (And yes, I could read these
variables generally, the idiom isn't typical but the syntax certainly
is good Perl.)
> So you have to tell us first what implementation you use, so we can
> direct you to the implementation specific user manual or, if you're
> nice, tell you directly how to do things in your implementation.
I'm using whatever came with Lisp in a Box, CLISP. I have played with
it on the CLI, and have learned enough to explore some alternatives. I
have CMUCL on a FreeBSD machine that I have played with as well. I've
downloaded Corman and LispWorks, but am focused on learning the
language and haven't explored these.
You are right about learning the language as a path toward general
competency with the various implementations. I will say that this bit
isn't explained to newbies, and it's probably just as well, as it
would scare the heck out of us.
> Be very careful so you don't erect these barriers yourself to your
> follower newbies.
Very good advice.
> Take note of everything that bother you, and when
> you become proficient with lisp, develop the needed tools and
> documentation to help the future newbies circumvents these barriers.
My first Lisp book was Graham's ANSI CL. To be honest, I found it
opaque, so much so that I put in on my shelf four years ago and
haven't touched it since. Languages flourish in a culture, even COBOL
which is taught in two or the three colleges that I am connected with.
Unfortunately, I am the only Lisp learner and potential user that I
know, and it's real hard to become proficient in a language if you are
by yourself. Perlists? Pythonistas? Rubyites? I know several
personally and can pick up the telephone and call them by name.
Lispers? I don't know a single one.
IMO, the biggest single barrier is the absence of a Lisp culture where
the young can be cultivated and the mature can grow. This isn't a
complaint, or a slam, or a troll, simply an observation based on
personal experience.
Thanks for your help, CC.
Giorgos Keramidas
> On Jun 30, 1:43�pm, Giorgos Keramidas <keram...@ceid.upatras.gr> wrote:
>> The ``Practical Common Lisp'' book includes a very good section about
>> opening files for reading and writing, including such handy details
>> like:
>
> Yes, I purchased the dead tree version of PCL, have skimmed through it
> a couple of times, and have worked through the first six or so
> chapters. I agree that it contains a very good explanation about
> writing and running Lisp. However, I write scripts for a living for
> users to use to do useful things, and so far I haven't found anything
> that would allow me to write a Lisp script that I can give to a user
> to run -- NOTING WITH THANKS several posts earlier in this thread some
> information about saving a Lisp image, which I haven't yet had time to
> explore in detail.
How to write shebang-style scripts is a bit implementation dependent.
So this is why nobody has told you so far.
I use SBCL on FreeBSD for most of my Lisp work, so here's an
SBCL-specific way of doing this:
* In my ~/.sbclrc file I have copied the following code (from an older
post of comp.lang.lisp, of course):
;;;; -*- mode: Lisp; coding: utf-8; -*-
;;;; Commentary:
;;;
;;; This file is the startup script that is loaded automatically by SBCL.
;;;; Code:
;;; Support for she-bang scripts:
;; If the first user-processable command-line argument is a filename,
;; disable the debugger, load the file handling shebang-line and quit.
(let ((script (and (second *posix-argv*)
(probe-file (second *posix-argv*)))))
(when script
;; Handle shebang-line
(set-dispatch-macro-character #\# #\!
(lambda (stream char arg)
(declare (ignore char arg))
(read-line stream)))
;; Disable debugger
(setf *invoke-debugger-hook*
(lambda (condition hook)
(declare (ignore hook))
;; Comment-out to disable backtraces on errors.
(sb-debug:backtrace 20)
(format *error-output* "Error: ~A~%" condition)
(quit)))
(load script)
(quit)))
* With this code in place, I can write SBCL 'scripts' by adding a
first line of the form:
#!/usr/local/bin/sbcl --noinform
A small script that shows very basic stuff is:
$ cat -n foo.lisp
1 #!/usr/local/bin/sbcl --script
2
3 (format t "Script ~S running~&" (first *posix-argv*))
4 (format t "Arguments:~&")
5 (loop for arg in (rest *posix-argv*)
6 do (format t " ~S~&" arg))
$ chmod 0755 foo.lisp
$ ./foo.lisp
Script "/usr/local/bin/sbcl" running
Arguments:
$ ./foo.lisp some arguments here
Script "/usr/local/bin/sbcl" running
Arguments:
"some"
"arguments"
"here"
$ ./foo.lisp "first shell-quoted argument" "second argument"
Script "/usr/local/bin/sbcl" running
Arguments:
"first shell-quoted argument"
"second argument"
This is enough to start using SBCL in a 'Perly' way, by hacking at
short, throw-away files until they have the right shape and smell.
When you start using more complex stuff, like modules, it will be a good
idea to read the links by Rainer for 'constructing a system'. What Lisp
calls a 'system' is, basically, "a set of modules and other code loaded
in the same running (Lisp) image".
There are quite a few tools for building 'Lisp systems'. Two of them
that I find useful quite often are: ASDF and MUDBALL. The following
links will get you started with these two:
* ASDF-INSTALL Tutorial
http://common-lisp.net/project/asdf-install/tutorial/index.html
* Mudballs: a System Management Tool for Common Lisp
http://mudballs.com/
Pascal J. Bourguignon
> My first Lisp book was Graham's ANSI CL. To be honest, I found it
> opaque, so much so that I put in on my shelf four years ago and
> haven't touched it since. Languages flourish in a culture, even COBOL
> which is taught in two or the three colleges that I am connected with.
> Unfortunately, I am the only Lisp learner and potential user that I
> know, and it's real hard to become proficient in a language if you are
> by yourself. Perlists? Pythonistas? Rubyites? I know several
> personally and can pick up the telephone and call them by name.
> Lispers? I don't know a single one.
>
> IMO, the biggest single barrier is the absence of a Lisp culture where
> the young can be cultivated and the mature can grow. This isn't a
> complaint, or a slam, or a troll, simply an observation based on
> personal experience.
Well, there's news:comp.lang.lisp, and irc://irc.freenode.org/#lisp
and you may notice that several lisp symposia and conferences are
organized all over the world every year, for the oral culture
transmission ;-)
--
__Pascal Bourguignon__
Pascal J. Bourguignon
> I'm new to slime and emacs, but I am worried about security concerns.
> Slime use swank and I don't know how exposed is my computer to the
> outer world. As lisp jobs are not so plentiful, i remember some Lisp
> hacker saying that he was desesperate or something similar. So using
> asdf, mudball, git, svn, tar, make and friends, i don't know if my
> computer is a net for trojans and worms.
>
> I remember one time i installed maxima (lisp based) in my computer
> and zonealarm detected that the program was connecting with someone in
> Holland, i used whois to find who was trying to get in my computer.
> Maxima for windows opened a socket ...
>
> I don't have much sensible information in my computer, but i don't
> want to have a key logger or trojans in my ubuntu computer.
>
> So i can summarize this with: Is secure to use Lisp for a newbye?
You should repost this article in its own thread with a meaningful
Subject: line.
--
__Pascal Bourguignon__
ccc31807
> This is enough to start using SBCL in a 'Perly' way, by hacking at
> short, throw-away files until they have the right shape and smell.
>
> When you start using more complex stuff, like modules, it will be a good
> idea to read the links by Rainer for 'constructing a system'. What Lisp
> calls a 'system' is, basically, "a set of modules and other code loaded
> in the same running (Lisp) image".
>
> There are quite a few tools for building 'Lisp systems'. Two of them
> that I find useful quite often are: ASDF and MUDBALL. The following
> links will get you started with these two:
>
> * ASDF-INSTALL Tutorial
> http://common-lisp.net/project/asdf-install/tutorial/index.html
>
> * Mudballs: a System Management Tool for Common Lisp
> http://mudballs.com/
Okay. I feel like I'm drinking from a fire hose. Way too much
information for my present stage of development. This reminds me of
struggling with make the first few times -- the complexity is hard to
handle, and I'm frankly not in a position to comprehend all that's
being delivered.
Give me a month (or a year, maybe) and I'll revisit.
Anyway, my original question has long since been answered. I'm using
SLIME for the time being, the Lisp in a Box version.
CC.
Stelian Ionescu
> With vi, one lives in a shell, navigating around--sometimes becoming
> other users (normally root)--annd one fires up vi frequently. Fast
> startup time is really important here.
>
> With emacs, one lives in emacs, probably with at least one shell session
> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
> access files as other users, and to run shells as those other users.
> Fast startup time is not so important here, because the emacs session is
> persistent.
Again, wrong! I use a daemonized emacs and pop up frames with emacsclient
whenever I need. I can be done, people
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
Thomas F. Burdick
> "Thomas F. Burdick" <tburd...@gmail.com> writes:
>
>
>
> > Two things: first, unless I'm terribly mistaken, none of the server/
> > client setups for emacs preserve the properties of the shell that
> > invoked the editor (uid, gid, umask, etc).
>
> I believe that you are correct.
>
> > That makes them nonstarters for sysadmin work.
>
> That's actually immaterial; as with so many other things, using emacs as
> a sysadmin requires a different mode of work than does vi.
Context, Robert :-)
That makes them nonstarters for sysadmin work *as vi replacements*. Of
course you can invert things and try to do all your permission
changing from within Emacs ... although honestly, I'd rather just wait
for Emacs to start up than to mess with TRAMP. And besides ... did I
mention umask? Emacs is a great programming editor, but I've never
found a happy use model for sysadmin work with it.
> With vi, one lives in a shell, navigating around--sometimes becoming
> other users (normally root)--annd one fires up vi frequently. Fast
> startup time is really important here.
Also changing gid, umask, and all number of other fiddly little
things.
> With emacs, one lives in emacs, probably with at least one shell session
> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
> access files as other users, and to run shells as those other users.
> Fast startup time is not so important here, because the emacs session is
> persistent.
This I never found especially usable. I end out with one Emacs session
for a given host/user/permission set. If I have a number of things to
do in that state, this is fine. If I just want to edit a config
file ... well, this is why I still know how to use vi.
> As a matter of fact, I use both very often. They each have their strong
> points. Vi is great for simple line-oriented text editing; it's
> particularly good when performing the same actual a limited number of
> times (I often wish that emacs had an equivalent to vi's . command).
I used to have a vi-dot command in my Emacs. I should track down that
package again.
> Emacs is great for structured text editing; it's particularly good at
> doing new things, or automating large tedious tasks. Now that more and
> more Unix vendors are doing IMHO silly things like using XML instead of
> line-oriented formats for config files I anticipate that my usage of
> emacs will increase yet more.
Not that Emacs is especially great with XML, but yeah, I'd rather use
it than vi for that purpose.
Thomas F. Burdick
> Thomas F. Burdick <tburd...@gmail.com> wrote:
> +---------------
> | r...@rpw3.org (Rob Warnock) wrote:
> | > Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> ...
> | > | Wow--you're right. On my machine, I can run emacs --no-init then C-x
> | > | C-c in 1.154 seconds while vi starts and then quits in 1.249 seconds.
> | > | Of course, emacs with my normal .emacs takes 2.853 seconds...
> | > +---------------
> | >
> | > Which is why I use real Vi, and *NOT* Vim!! ;-} ;-}
> | > On my laptop, Vi (nvi-1.79) takes 0.83 s to
> | > start up & exit the first time; only 7 ms thereafter!!
> |
> | Not to argue against the venerable usenet tradition of discussions
> | that go flying off on a random tangent ... but weren't we talking
> | about whether Emacs+Slime+Viper could serve as a modal IDE? For this
> | purpose, you would *not* want to be constantly starting and shutting
> | down your editor: you want it to stay connected to the Lisp :-)
> +---------------
>
> Yes, of course, thanks for dragging us back on-topic. [I'm afraid
> I let myself get dragged down the "startup time" rathole... (*sigh*)]
>
> And it wasn't quite "whether Emacs+Slime+Viper could serve as a
> modal IDE", but "whether Emacs+Slime+Viper could serve as a Lisp IDE
> with a modal editor even when editing Lisp". I know the difference
> may sound subtle, but it's important.
Yeah, actually that's what I meant. I didn't mean to imply that you'd
have a navigation mode, editing mode, evaluation mode, debugging mode,
etc.
> I have no problems using Emacs
> chords -- or, better, M-x long-commands -- for the IDE functions.
> I just want navigation/insertion/editing to work like Vi (modal editing).
That's not a problem. My group at work has an Emacs-based IDE for the
(Cadence proprietary) Skill dialect of Lisp, and I make a point of
ensuring that it works with Viper as well. The few issues that have
come up over time weren't due to Lisp-Mode, and were nothing more than
minor annoyances.
Robert Uhl
> On Wed, 01 Jul 2009 08:24:46 -0600, Robert Uhl wrote:
>> With vi, one lives in a shell, navigating around--sometimes becoming
>> other users (normally root)--annd one fires up vi frequently. Fast
>> startup time is really important here.
>>
>> With emacs, one lives in emacs, probably with at least one shell session
>> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
>> access files as other users, and to run shells as those other users.
>> Fast startup time is not so important here, because the emacs session is
>> persistent.
>
> Again, wrong! I use a daemonized emacs and pop up frames with
> emacsclient whenever I need. I can be done, people
Not if you need your uid, gid & umask to be those of another user,
e.g. if one is a sysadmin...which is what Mr. Burdick referred to.
--
Every time I read up about the next XML "solution" it feels like someone just
missed the point of the Lisp syntax, S expressions, and tried to achieve the
same results by sticking a salad fork in their brain, swirling for a while,
then recording the results. --Daniel Pittman
Robert Uhl
>
>> > Two things: first, unless I'm terribly mistaken, none of the
>> > server/ client setups for emacs preserve the properties of the
>> > shell that invoked the editor (uid, gid, umask, etc).
>>
>> I believe that you are correct.
>>
>> > That makes them nonstarters for sysadmin work.
>>
>> That's actually immaterial; as with so many other things, using emacs as
>> a sysadmin requires a different mode of work than does vi.
>
> Context, Robert :-)
>
> That makes them nonstarters for sysadmin work *as vi replacements*. Of
> course you can invert things and try to do all your permission
> changing from within Emacs ... although honestly, I'd rather just wait
> for Emacs to start up than to mess with TRAMP.
C-x C-f /sudo::/etc/passwd
Or as a user other than root:
C-x C-f /sudo:user@:/home/user/foo
TRAMP really is that easy.
> And besides ... did I mention umask?
You get it for free with sudo.
> Emacs is a great programming editor, but I've never found a happy use
> model for sysadmin work with it.
I use emacs and vi both for sysadminry.
>> With vi, one lives in a shell, navigating around--sometimes becoming
>> other users (normally root)--annd one fires up vi frequently. Fast
>> startup time is really important here.
>
> Also changing gid, umask, and all number of other fiddly little
> things.
By 'changing,' do you mean chown? Because M-! works pretty well for
that. If you mean 'edit a file as another user' then TRAMP handles
that.
>> With emacs, one lives in emacs, probably with at least one shell session
>> opened up inside it. One uses TRAMP on top of sudo, ssh & friends to
>> access files as other users, and to run shells as those other users.
>> Fast startup time is not so important here, because the emacs session is
>> persistent.
>
> This I never found especially usable. I end out with one Emacs session
> for a given host/user/permission set.
C-x C-f /multi:ssh:user@host:sudo:otheruser@:/home/otheruser/
It even works with tab completion!
> I used to have a vi-dot command in my Emacs. I should track down that
> package again.
I would _love_ to have that.
>> Emacs is great for structured text editing; it's particularly good at
>> doing new things, or automating large tedious tasks. Now that more and
>> more Unix vendors are doing IMHO silly things like using XML instead of
>> line-oriented formats for config files I anticipate that my usage of
>> emacs will increase yet more.
>
> Not that Emacs is especially great with XML, but yeah, I'd rather use
> it than vi for that purpose.
At least emacs can be made better at editing XML...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Curmudgeon: Someone so down on the world that he won't donate old
clothes because one day he might be mugged by someone wearing one of his
old shirts. --Unknown
Robert Uhl
> As for Perl, the title of a recent NG thread was this: '$#{$h{$_}},
> $#{@{$h{$_}}}, $#@{$h{$_}}'
Do you kiss your mother with that mouth? *grin*
> I'm using whatever came with Lisp in a Box, CLISP.
A quick Googling yields:
http://clisp.wiki.sourceforge.net/shell+scripting
Apparently you can put '#!/usr/bin/clisp -C' at the top of the Lisp file
and CLISP will treat it as a shell script.
CLISP is a very capable Lisp implementation; you should be able to get
some good work done with it.
I myself am a big fan of SBCL, which compiles to very fast machine code.
> IMO, the biggest single barrier is the absence of a Lisp culture where
> the young can be cultivated and the mature can grow.
I would agree. I'd also agree that Graham's Lisp book--while
well-done--isn't really a good introduction to Lisp. It's more of an
introduction to programming.
--
Robert Uhl <http://public.xdi.org/=ruhl>
They say `the early bird gets the worm.' What they often fail to
consider, however, is the early cat.
ccc31807
> They say `the early bird gets the worm.' What they often fail to
> consider, however, is the early cat.
The early worm gets the bird.
;-)
CC
Paul Donnelly
> On Jun 30, 1:43 pm, Giorgos Keramidas <keram...@ceid.upatras.gr>
> wrote:
>> You can also combine both steps with:
>>
>> * (load (compile-file "foo.lisp"))
>>
>> ; compiling file "/home/keramida/foo.lisp" (written 30 JUN 2009 08:31:57
>> PM):
>> ; compiling (DEFUN HELLO-WORLD ...)
>>
>> ; /home/keramida/foo.fasl written
>> ; compilation finished in 0:00:00.039
>> T
>
> Okay, this is the first time I have seen anything like this, and it
> look like generating and running a program in C or Perl or Java.
But it isn't. In Lisp you're not generating a program you can
run. You're just compiling the functions that comprise it to make them
faster. You could equally well compile only the functions that actually
need to be compiled. A runnable Lisp program is something that exists
inside a running Lisp. It's not a file on disk.
> I can deal with this. I'm wondering now why this kind of information
> seems so hard to find.
It's because a Lisper who's just written some code in a file and wants
to compile the whole thing generally wouldn't do it like that. They
would use their environment's “compile this file” command (e.g. C-x C-k
in SLIME), instead of typing all that garbage into the REPL. Those lines
would be more useful if you were writing a system loading facility that
needed to programmatically compile and load files.
> Is it because we assume that anybody with half a wit already knows it?
> I have six Lisp books so far (Wilensky, Winston & Horn, Sieibel,
> Graham, Lamkins, Friedman & Felliesen) and somehow this little bit of
> info hasn't been covered in a direct and to-the-point manner.
It's also partly because it's beside the point. In Lisp, producing a
compiled version of your program is largely incidental. The important
thing is that a function be defined in your running Lisp. Sometimes it's
also desirable that a particular function run as fast as possible, in
which case it's helpful to compile it. These days, I think most people
just compile almost everything as a matter of course.
>> The ``Practical Common Lisp'' book describes a *lot* of the mechanisms
>> you can use to handle errors, or other sorts of exceptional conditions.
>> It will help a lot if you read the relevant bits from the book :)
>
> I agree. What it doesn't cover is how I can create JAR file (for
> example) and give it to a user than he can use. The fact that it's
> written in Java or Lisp or C should not concern the user at all. The
> user should be able just to invoke the program (or at worst as for
> Perl to invoke a browser to run a CGI-like script.)
That's implementation-specific. You need to consult your
implementation's documentation to see if it has a way to produce
stand-alone executables, and if so, how it might be done. Or you could
ship the source, a Lisp, and a shell script/batch file to get the whole
thing going.
> Still and all, my criticism of the Lisp community as an outsider who
> has spent some effort in learning Lisp, is that the community appears
> to want to erect barriers to keep people like me on the outside.
I think you're mistaking old cultural differences for intentional
barriers. For how many decades have Lispers been working this way? For
how many decades have many of them been using Emacs or its relatives to
edit Lisp code? They don't do it just to be difficult. Newcomers to Lisp
often get hung up on recreating their old habits and have a lot of
trouble coming to grips with the fact that we don't do things that way
here.
There's probably a place for an FAQ or something that deals with these
questions, but who's to guarantee that anyone would see it?
Raffael Cavallaro
> As an example, on
> a Macintosh or Windows host one can't go to the beginning or end of a
> line, or move forward by s-expression, or incrementally search forward
> and backward, with the option of using a regexp.
Just to pick a nit, on the Mac OS you've been able to move to the
start/end of a line with Cmd-leftarrow/Cmd-rightarrow for the better
part of two decades (maybe even since 1984 - I don't remember anymore);
forward/back a word with opt-rightarrow/opt-leftarrow; similarly with
selection and extending selections (e.g., opt-shift-rightarrow =
select/extend-selection to end of word; Cmd-shift-leftarrow =
select/extend-selection to beginning of line). Searching with regexps
is a job for a programmer's editor, and BBEdit has done this for what,
almost 2 decades?
Moreover, for a decade Mac OS X cocoa applications have had some actual
emacs keybindings in addition to the above (ctl-a beginning of line,
ctl-e, ctl-p, ctl-n, etc.)
--
Raffael Cavallaro
Pascal J. Bourguignon
Indeed, and this features, which comes from NeXTstep (two decades),
has been instrumental in my conversion from vi to emacs.
So let's advice TextEdit.app and Control commands to all vi users! :-)
--
__Pascal Bourguignon__
ccc31807
> I think you're mistaking old cultural differences for intentional
> barriers. For how many decades have Lispers been working this way? For
> how many decades have many of them been using Emacs or its relatives to
> edit Lisp code? They don't do it just to be difficult. Newcomers to Lisp
> often get hung up on recreating their old habits and have a lot of
> trouble coming to grips with the fact that we don't do things that way
> here.
Okay, I can buy this. Let me address two points:
One. I understand what you say when you make the point that the
central application is a running Lisp image, and that the 'program' is
just something that exists in the image and runs in it. Looking at it
from the standpoint of one who writes software for a living, I'm still
having a hard time seeing how you can distribute a script or app to a
lay user ad have him or her execute it. If I tell them that they must
have a running Lisp image, it will terrify them!
Two. I also understand that there are workarounds, like writing a
shell script or batch file, or running it from the command line.
However, PC users typically have a .NET and a JVM framework installed,
and I'm wondering as a practical matter how I can get a multitude of
users to install a Lisp.
The point is that I want to write working software, something that
Java and the .NET framework make easy. Maybe I should look at Clojure
or one of the Lisps that runs on Java (I forget which one, ABCL?)
CC
Pascal Costanza
Have you ever tried to install a .NET application on a Mac?
There are alternatives:
+ Distribute a self-contained .exe/.app.
+ Use one of the web frameworks to 'distribute' a web application.
+ Create an installer that installs a CL runtime along with your
scripts/programs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal J. Bourguignon
ccc31807 <cart...@gmail.com> writes:
> On Jul 1, 5:44�pm, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>> I think you're mistaking old cultural differences for intentional
>> barriers. For how many decades have Lispers been working this way? For
>> how many decades have many of them been using Emacs or its relatives to
>> edit Lisp code? They don't do it just to be difficult. Newcomers to Lisp
>> often get hung up on recreating their old habits and have a lot of
>> trouble coming to grips with the fact that we don't do things that way
>> here.
>
> Okay, I can buy this. Let me address two points:
>
> One. I understand what you say when you make the point that the
> central application is a running Lisp image, and that the 'program' is
> just something that exists in the image and runs in it. Looking at it
> from the standpoint of one who writes software for a living, I'm still
> having a hard time seeing how you can distribute a script or app to a
> lay user ad have him or her execute it. If I tell them that they must
> have a running Lisp image, it will terrify them!
You are confounding developer's stuff with user's point of view.
As a developer, you launch a virgin lisp image:
[pjb@simias :0.0 ~]$ clisp -norc
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.47 (2008-10-23) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2008
Type :h and hit Enter for context help.
Then you develop your application in that image:
[1]> (defun main () (format t "~%Hello World!~%"))
MAIN
Test and debug it:
[2]> (main)
Hello World!
NIL
Well this one doesn't need debugging.
Then you read some documentation:
[3]> (describe 'ext:saveinitmem)
SAVEINITMEM is the symbol SAVEINITMEM, lies in #<PACKAGE EXT>, is accessible
in 7 packages COMMON-LISP-USER, EXT, FFI, POSIX, READLINE, SCREEN, SYSTEM,
names a function, has 1 property SYSTEM::DOC
;; connecting to "http://clisp.cons.org/impnotes/id-href.map"...connected...HTTP/1.1 200 OK...71,405 bytes
;; SYSTEM::GET-STRING-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER clisp.cons.org:80>)...1,926 IDs
;; SYSTEM::ENSURE-IMPNOTES-MAP(#P"/usr/local/lib64/clisp-2.47/data/Symbol-Table.text")...640 IDs
.
CLISP Documentation is at
"http://clisp.cons.org/impnotes/image.html"
For more information, evaluate (SYMBOL-PLIST 'SAVEINITMEM).
#<PACKAGE EXT> is the package named EXT.
It imports the external symbols of 7 packages POSIX, SOCKET, GSTREAM, GRAY,
I18N, COMMON-LISP, CUSTOM and exports 768 symbols to 7 packages READLINE,
POSIX, FFI, CS-COMMON-LISP-USER, SCREEN, COMMON-LISP-USER, SYSTEM.
#<COMPILED-FUNCTION SAVEINITMEM> is a compiled function.
Argument list:
(&OPTIONAL #:ARG0 &KEY :QUIET :INIT-FUNCTION :VERBOSE :NORC :DOCUMENTATION
:SCRIPT :KEEP-GLOBAL-HANDLERS :START-PACKAGE :LOCKED-PACKAGES :EXECUTABLE)
For more information, evaluate (DISASSEMBLE #'SAVEINITMEM).
Documentation:
SYSTEM::IMPNOTES:
"image.html"
SYSTEM::FILE:
((SYSTEM::DEFUN/DEFMACRO #P"/usr/local/src/clisp-2.47/src/savemem.fas" 31 88))
And save the lisp image:
[4]> (ext:saveinitmem "hw" :quiet t :init-function (lambda () (main) (ext:quit)) :verbose t :norc t :documentation "This is a Common Lisp 'hello world' sample." :executable t)
;; Wrote the memory image into hw (11,558,239 bytes)
Bytes permanently allocated: 163,632
Bytes currently in use: 3,694,528
Bytes available until next GC: 920,782
3694528 ;
920782 ;
163632 ;
2 ;
1133120 ;
16666
If you're done creating applications, you leave:
[5]> (ext:quit)
Bye.
And you can deliver the executable to your user:
[pjb@simias :0.0 ~]$ ./hw
Hello World!
[pjb@simias :0.0 ~]$ ./hw -help-image
All positional arguments are put into *ARGS*
This is a Common Lisp 'hello world' sample.
[pjb@simias :0.0 ~]$
> Two. I also understand that there are workarounds, like writing a
> shell script or batch file, or running it from the command line.
> However, PC users typically have a .NET and a JVM framework installed,
> and I'm wondering as a practical matter how I can get a multitude of
> users to install a Lisp.
Why do you wonder? Sun and Microsoft didn't wonder as a practical
matter how the could get a multitude of users to install a JVM or
.NET. The users do as they're told to do. You tell them: double
click on the installer icon, and they'll do it.
>> There's probably a place for an FAQ or something that deals with these
>> questions, but who's to guarantee that anyone would see it?
I find a good solution is to have the FAQ posted twice a month on the
newsgroup. It wouldn't be any overhead amongst the spam or trollwars.
--
__Pascal Bourguignon__
ccc31807
wrote:
Okay, Pascal, I tried it. I cut and pasted your commands directly at
the prompt to make sure I didn't make a mistake.
This is what happened when I tried to run hw:
This application failed to start because libinit-8.dll was not found.
Reinstalling the application may fix the problem.
I'm not asking for help with dlls. I just wanted you to know that the
commands did create a hw.exe file in the directory, so at least at
this point I'm satisfied.
Question: the HelloWorld.exe with clisp was almost 5MB, while the C
HelloWorld.exe (compiled with gcc) was only 15850 bytes. As a
practical matter, does the large file size present any problems, other
than the obvious one?
Thanks, CC.
Pillsy
[...]
> Question: the HelloWorld.exe with clisp was almost 5MB, while the C
> HelloWorld.exe (compiled with gcc) was only 15850 bytes.
The CLISP HelloWorld.exe is an image that not only contains the "Hello
World" program itself, but also a complete Common Lisp implementation,
with an interpreter, compiler and debugger. The relative size of the
overhead is obviously going to be pretty big for programs that
basically don't do anything, like "Hello World".
Some Lisp implementations provide "tree shakers", which allow you
deliver executables without the extra parts (like the compiler) that
your users may not need. I'm pretty sure it's limited to commercial
implementations at the moment. OTOH, for some applications, delivering
the debugger, compiler and interpreter along with it has real
advantages.
Cheers,
Pillsy
Pascal J. Bourguignon
> On Jul 2, 8:31�am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> Okay, Pascal, I tried it. I cut and pasted your commands directly at
> the prompt to make sure I didn't make a mistake.
>
> This is what happened when I tried to run hw:
> This application failed to start because libinit-8.dll was not found.
> Reinstalling the application may fix the problem.
>
> I'm not asking for help with dlls. I just wanted you to know that the
> commands did create a hw.exe file in the directory, so at least at
> this point I'm satisfied.
Sorry, I don't know anything about MS-Windows. You should ask on
mailto:clisp...@lists.sourceforge.net
> Question: the HelloWorld.exe with clisp was almost 5MB, while the C
> HelloWorld.exe (compiled with gcc) was only 15850 bytes. As a
> practical matter, does the large file size present any problems, other
> than the obvious one?
Notice that the C executable depends on more shared libraries. In
Linux at least when you compare the size of the excutable plus the
shared libraries in both case, the sizes are on the same order.
The difference is in the fact that the lisp hw actually includes the
whole lisp system:
[pjb@simias :0.0 ~]$ ./hw -x '(loop (print (multiple-value-list
(ignore-errors (multiple-value-list (eval (progn (terpri) (princ "> ")
(finish-output) (read *terminal-io*))))))))'
> (function-lambda-expression (function main))
(((LAMBDA NIL (DECLARE (SYSTEM::IN-DEFUN MAIN))
(BLOCK MAIN (FORMAT T "~%Hello World!~%")))
#(NIL NIL NIL NIL ((DECLARATION OPTIMIZE DECLARATION))) MAIN))
> (defun main () (FORMAT T "~%----====#### Hello World ####====----!~%"))
((MAIN))
> (compile 'main)
((MAIN NIL NIL))
> (ext:saveinitmem "hw2" :quiet t :init-function (lambda () (main) (ext:quit))
:verbose t :norc t
:documentation "This is a second version of the Common Lisp 'hello world' sample."
:executable t)
;; Wrote the memory image into hw2 (11,562,551 bytes)
Bytes permanently allocated: 163,632
Bytes currently in use: 3,699,744
Bytes available until next GC: 920,956
((3699744 920956 163632 1 129816 13332))
> (ext:quit)
[pjb@simias :0.0 ~]$ ./hw2
----====#### Hello World ####====----!
[pjb@simias :0.0 ~]$
However, even if you don't use the compiler at run-time, with
applications of the size of current applications, there's not much
difference between 5 byte or 5 Mbyte of overhead.
For smaller scripts, just distribute them as such:
[pjb@simias :0.0 ~]$ cat hw3
#!/usr/bin/clisp -norc
(format t "~%Hello World~2%")
(finish-output)
(ext:quit)
[pjb@simias :0.0 ~]$ chmod 755 hw3
[pjb@simias :0.0 ~]$ ./hw3
Hello World
[pjb@simias :0.0 ~]$
See also: http://clisp.cons.org/impnotes/quickstart.html
--
__Pascal Bourguignon__
fortunatus
fortunatus
> I'm not asking for help with dlls. I just wanted you to know that the
> commands did create a hw.exe file in the directory, so at least at
> this point I'm satisfied.
I deploy apps with CLISP on MSWin around my company like this all the
time. They are generally fairly straight forward script type apps
using standard i/o, TCP networking, etc, nothing with fancy foreign
function interface or GUI, etc. Here's the DLLs I need to distribute
alongside the *.exe (in the same directory is fine):
libiconv-2.dll
libintl-8.dll
readline5.dll
These come out of "C:\Program Files\clisp-2.45\base" on my system.
Paul Donnelly
> One. I understand what you say when you make the point that the
> central application is a running Lisp image, and that the 'program' is
> just something that exists in the image and runs in it. Looking at it
> from the standpoint of one who writes software for a living, I'm still
> having a hard time seeing how you can distribute a script or app to a
> lay user ad have him or her execute it. If I tell them that they must
> have a running Lisp image, it will terrify them!
Don't tell them. ;)
> Two. I also understand that there are workarounds, like writing a
> shell script or batch file, or running it from the command line.
> However, PC users typically have a .NET and a JVM framework installed,
> and I'm wondering as a practical matter how I can get a multitude of
> users to install a Lisp.
Just pick a workaround and do it if you aren't using a Lisp that can
produce executables for your target system. Unless you can come up with
a way to have Common Lisp installed on most computers before your
program even gets delivered, it's just something you have to do. It
doesn't have to be perfectly elegant, it just has to be reliable and not
scary. I'm not trying to say the solution couldn't be more intuitive,
but it's not the obstacle it's sometimes made out to be.
> The point is that I want to write working software, something that
> Java and the .NET framework make easy. Maybe I should look at Clojure
> or one of the Lisps that runs on Java (I forget which one, ABCL?)
That's one option. Since you're distributing files to begin with, I
don't see what the big advantage of running on the JVM is, but if that's
how you like to do it, do it like that.
Alessio Stalla
> > The point is that I want to write working software, something that
> > Java and the .NET framework make easy. Maybe I should look at Clojure
> > or one of the Lisps that runs on Java (I forget which one, ABCL?)
>
> That's one option. Since you're distributing files to begin with, I
> don't see what the big advantage of running on the JVM is, but if that's
> how you like to do it, do it like that.
I am a fan of ABCL, but in this aspect Paul is completely right: using
abcl will not improve much your ease of deployment. Sure, you could
package everything (abcl + your code + libraries) in a bunch of jar
files with a little work, but in the end the user would still be
needed to
- check she has a suitable JVM version installed
- ensure all the jars are in the classpath
- launch the main class from one of the jars.
nothing dramatic, but nothing harder than what other Lisp
implementations offer - the majority of dummy users will need an
installer anyway.
The only point in favor of abcl is that you can use Java Web Start,
but then it has its own drawbacks too - you'll still need your users
to have a JVM installed (best if Sun's), you'll need to sign all the
jars and have the user click on a scary "really run this?" dialog, or
pay a third-party CA to provide you with a trusted certificate.
Just my €.02
Alessio