On Jun 29, 12:19 pm, Alberto Riva <····@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.
> > 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
On Jun 29, 12:51 pm, ccc31807 <········@gmail.com> wrote:
> On Jun 29, 12:19 pm, Alberto Riva <····@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.
On 29 Jun., 18:51, ccc31807 <········@gmail.com> wrote:
> On Jun 29, 12:19 pm, Alberto Riva <····@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.
>
> > > 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
On Jun 29, 2:14 pm, Rainer Joswig <······@lisp.de> wrote:
> 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.
In article
<····································@l2g2000vba.googlegroups.com>,
Jimmy Miller <··············@gmail.com> wrote:
> On Jun 29, 2:14�pm, Rainer Joswig <······@lisp.de> wrote:
> > 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.
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
On Jun 29, 3:00 pm, Ron Garret <·········@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.
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
ccc31807 <········@gmail.com> writes:
> On Jun 29, 3:00��pm, Ron Garret <·········@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.
--
Thomas A. Russ, USC/Information Sciences Institute
In article
<····································@37g2000yqp.googlegroups.com>,
ccc31807 <········@gmail.com> wrote:
> On Jun 29, 3:00�pm, Ron Garret <·········@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
In article <·······························@news.albasani.net>,
Ron Garret <·········@flownet.com> wrote:
> In article
> <····································@37g2000yqp.googlegroups.com>,
> ccc31807 <········@gmail.com> wrote:
>
> > On Jun 29, 3:00�pm, Ron Garret <·········@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
On Jun 29, 6:02 pm, Ron Garret <·········@flownet.com> wrote:
> In article <·······························@news.albasani.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > In article
> > <····································@37g2000yqp.googlegroups.com>,
> > ccc31807 <········@gmail.com> wrote:
>
> > > On Jun 29, 3:00 pm, Ron Garret <·········@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.
ccc31807 <········@gmail.com> writes:
> On Jun 29, 3:00 pm, Ron Garret <·········@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?
Vassil Nikolov <········@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
On Tue, 30 Jun 2009 15:45:10 -0500, Russell McManus <···············@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.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On 29 Jun., 20:22, Jimmy Miller <··············@gmail.com> wrote:
> On Jun 29, 2:14 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > 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.
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!
On 2009-06-29 19:22:53 +0100, Jimmy Miller <··············@gmail.com> said:
> 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
ccc31807 <········@gmail.com> writes:
>
>> > 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
On Jun 29, 1:40 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> > 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.
On Jun 29, 2:23 pm, ccc31807 <········@gmail.com> wrote:
> 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.
ccc31807 <········@gmail.com> writes:
> 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
ccc31807 schrieb:
> On Jun 29, 1:40 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>>> 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)
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).
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
ccc31807 wrote:
> On Jun 29, 12:19 pm, Alberto Riva <····@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
From: Giorgos Keramidas
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <87y6r9d3cy.fsf@kobe.laptop>
On Mon, 29 Jun 2009 09:51:05 -0700 (PDT), ccc31807 <········@gmail.com> wrote:
> On Jun 29, 12:19�pm, Alberto Riva <····@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?
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 :)
Giorgos Keramidas <········@ceid.upatras.gr> wrote:
+---------------
| ccc31807 <········@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!].
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Giorgos Keramidas
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <871vp1ql9n.fsf@kobe.laptop>
On Tue, 30 Jun 2009 19:29:40 -0500, ····@rpw3.org (Rob Warnock) wrote:
> Giorgos Keramidas <········@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.
>
> 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.
Heh! Very neat, thanks :)
Hi, Goirgos,
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 <········@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.
> 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
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
ccc31807 <········@gmail.com> writes:
>
> 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.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> 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__
From: Pascal J. Bourguignon
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <87prcknufb.fsf@galatea.local>
camposdeviento <·············@gmail.com> writes:
> 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__
On 2009-07-01 10:57:00 -0400, Robert Uhl <·········@NOSPAMgmail.com> said:
> 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
From: Pascal J. Bourguignon
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <87ljn7ochp.fsf@galatea.local>
Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com> writes:
> On 2009-07-01 10:57:00 -0400, Robert Uhl <·········@NOSPAMgmail.com> said:
>
>> 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.)
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__
In article
<····································@l31g2000yqb.googlegroups.com>,
ccc31807 <········@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.
--
http://lispm.dyndns.org/
ccc31807 <········@gmail.com> writes:
> 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
ccc31807 <········@gmail.com> writes:
>> 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__
On Jul 1, 10:36 am, ····@informatimago.com (Pascal J. Bourguignon)
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.
ccc31807 <········@gmail.com> writes:
> 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.
On Jul 1, 4:47 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> 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
From: Pascal J. Bourguignon
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <87tz1wnuhe.fsf@galatea.local>
ccc31807 <········@gmail.com> writes:
> 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__
ccc31807 <········@gmail.com> writes:
> On Jun 30, 1:43 pm, Giorgos Keramidas <········@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?
On Jul 1, 5:44 pm, Paul Donnelly <·············@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!
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
>
> 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?
ccc31807 <········@gmail.com> writes:
> 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.
On Jul 2, 7:34 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> > 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
ccc31807 wrote:
> On Jul 1, 5:44 pm, Paul Donnelly <·············@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!
>
> 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?)
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/
ccc31807 <········@gmail.com> writes:
> On Jul 1, 5:44�pm, Paul Donnelly <·············@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:
[···@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:
[···@simias :0.0 ~]$ ./hw
Hello World!
[···@simias :0.0 ~]$ ./hw -help-image
All positional arguments are put into *ARGS*
This is a Common Lisp 'hello world' sample.
[···@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__
On Jul 2, 8:31 am, ····@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.
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.
On Jul 2, 9:58 am, ccc31807 <········@gmail.com> wrote:
[...]
> 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
On Jul 2, 10:28 am, Pillsy <·········@gmail.com> wrote:
> On Jul 2, 9:58 am, ccc31807 <········@gmail.com> wrote:
> [...]
>
> > 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
On Jul 2, 9:58 am, ccc31807 <········@gmail.com> wrote:
> On Jul 2, 8:31 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
...
> 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.
ccc31807 <········@gmail.com> writes:
> On Jul 2, 8:31�am, ····@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
·················@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:
[···@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)
[···@simias :0.0 ~]$ ./hw2
----====#### Hello World ####====----!
[···@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:
[···@simias :0.0 ~]$ cat hw3
#!/usr/bin/clisp -norc
(format t "~%Hello World~2%")
(finish-output)
(ext:quit)
[···@simias :0.0 ~]$ chmod 755 hw3
[···@simias :0.0 ~]$ ./hw3
Hello World
[···@simias :0.0 ~]$
See also: http://clisp.cons.org/impnotes/quickstart.html
--
__Pascal Bourguignon__
From: Giorgos Keramidas
Subject: Re: best environment for learning Lisp?
Date:
Message-ID: <87tz1wz5bp.fsf@kobe.laptop>
On Wed, 1 Jul 2009 05:26:46 -0700 (PDT), ccc31807 <········@gmail.com> wrote:
> On Jun 30, 1:43�pm, Giorgos Keramidas <········@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/
On Jul 1, 1:22 pm, Giorgos Keramidas <········@ceid.upatras.gr> wrote:
> 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.