Re: `Standalone Executables'

From: Alan Crowe (alan_at_cawtech.freeserve.co.uk)
Date: 02/04/04 

Date: 04 Feb 2004 13:19:30 +0000

Joe Marshall wrote:

   let me instead rephrase the question:

     How do I deliver a Lisp application with the minimum
     amount of burden on the recipient?

   We wish to deliver to the user a package that he can
   easily unpack, install, and run without having to know
   the details of compiling, loading, and running Lisp.

I have difficulties understanding what is being asked here.
Suppose I attempt to deploy my application, super-frob, as a
lisp source file. The instructions on my web page are
carefully worded and the substance of them is:

  from the shell prompt, make a directory to keep super-frob
  in

  bash$ mkdir sf

  Go to that directory

  bash$ cd sf

  Use your browser or download tool to fetch super-frob.lisp
  For example

  bash$ netscape http://www.super-frob.org/downloads.html

  Quit from your download tool and check that super-frob has
  arrived by using the ls command from the shell prompt

  bash$ ls

  Your computer should respond with a single line

  super-frob.lisp

  From the shell prompt, fire up your Lisp system

  bash$ lisp

  From the lisp prompt, compile the file

  lisp* (compile-file "super-frob")

  Your computer should response with a message such as

    Converted FROB.
    Compiling DEFUN FROB:
    Byte Compiling Top-Level Form:

    #p"/home/alan/tempdir/super-frob.x86f"
    NIL
    NIL

  You can now run super-frob from the Lisp prompt

  lisp* (load "super-frob")

  The compilation step is only needed the first time you run
  super-frob. Now that you have compiled super-frob you can
  run it, either from Lisp, or from the shell prompt

  bash$ lisp -eval '(load "super-frob")'

Does this meet the requirement of the the user not having
to know the /details/ of compiling, loading, and running Lisp?
I can argue both yes and no

NO, the user is having to run Lisp and use both
compile-file, and load

YES, the user is not required to know anything, let alone
details. He does not even have to type accurately. The
instructions on the webpage are literal instructions. He
can cut and paste them from the webpage, without filling in
any variables by putting finger to keyboard.

Is there a point to my quibbling? I hope so. In particular,
my experience is that the major burden I encounter as a
recipient of software is when the instructions don't work.

By "work" I mean that the instructions are keystroke
perfect. If they don't work it is because I have not
followed them accurately, and I can make them work by
starting again, and being careful and literal minded, doing
exactly what is asked, not a keystroke more or less.

So instructions that "work" require neither common sense nor
system administration skills. No error messages, requiring
the obvious corrective answer. No wizards asking me
questions I did not expect, and do not feel competent to
answer.

>From this perspective, it doesn't matter very much whether
the instructions are simple or complicated. Complicated that
"works" beats simple that doesn't "work". Complicated/works
beats simple/broken every time, and by a large margin.

Joe's question contrasts unpacking and installing with
compiling, loading, and running. This seems to be orthogonal
to my concerns. I just want the instructions to work. If the
installation script that is supposed to make it easy for me
by hiding the ordeal of compiling, loading, and running from
me happens to break, that is a much bigger burden than
cutting and pasting a few opaque commands from a webpage.

So I see the question

   How do I deliver a Lisp application with the minimum
   amount of burden on the recipient?

and that takes me off in the direction wanting the most
reliable means of deployment. What decisions will allow me
to write instructions that will work for everybody, every
time? Are there problems with distributing source code that
might catch me by surprise?

Alan Crowe
Edinburgh
Scotland

Relevant Pages

  • Re: `Standalone Executables
    ... > the details of compiling, loading, and running Lisp. ... > You can now run super-frob from the Lisp prompt ... I just want the instructions to work. ...
    (comp.lang.lisp)
  • Re: best environment for learning Lisp?
    ... Just type in your Lisp prompt: ... ; compiling ... have figured out how to compile, load, and run a script in SLIME. ... sort of programming too, as you have found out, but you are missing out ...
    (comp.lang.lisp)
  • Re: undefined (asdf:system-license on clisp+cywgin
    ... Franz's case-sensitive lisp when the string designators are symbols, ...  This means that when the compiling ... names into strings, so that even if a source file has random symbols ... whatever readtable-case translation you might have in effect, ...
    (comp.lang.lisp)
  • Re: undefined (asdf:system-license on clisp+cywgin
    ... Sometime I shout strings and sometimes ... Franz's case-sensitive lisp when the string designators are symbols, ...  This means that when the compiling ... whatever readtable-case translation you might have in effect, ...
    (comp.lang.lisp)
  • Re: {Historical} Lisp manually compiled to assembly
    ... The core Lisp functions only had to ... [Both instructions and data ... minimum of utility routines in bare machine code -- output a string, ...
    (comp.lang.lisp)