Spake Andrei Zernoveanu:
> What holds me up right now is understanding how to set up my
> environment correctly. ... So, any resources for somebody that sees
> Lisp for the first time would be greatly appreciated
Orthogonal to this, has anyone written up a thorough description of
their (personal, Lisp) development workflow? Along the lines of
1. I start (Carbon GUI) Emacs from the OSX Dock.
2. I do M-x slime to start slime.
3. I use C-x C-f to open the code directory.
...
4. I have added slime-mode to the lisp-mode entry hook.
...
5. I use M-( and M-) to do structured editing.
...
6. After writing a function, I do fooble warp thud to test and
debug it.
...and so on. Almost like an HCI-esque observational study of your
typical coding session. Maybe even including non-coding tasks, such as
how you design the program architecture or do change management.
As a young hacker, I'm starting to experience problems with the
minimalist techniques I've been using so far; they're OK for class
assignments, but they don't scale well. How do old hands do it?
--
Trent Buck, Student Errant
You start off with a typical message, let's say a 2.5MB Word document
containing three lines of text and a macro virus... -- Peter Gutmann
Trent Buck <·········@tznvy.pbz> writes:
> Spake Andrei Zernoveanu:
> > What holds me up right now is understanding how to set up my
> > environment correctly. ... So, any resources for somebody that sees
> > Lisp for the first time would be greatly appreciated
>
> Orthogonal to this, has anyone written up a thorough description of
> their (personal, Lisp) development workflow? Along the lines of
>
> 1. I start (Carbon GUI) Emacs from the OSX Dock.
> 2. I do M-x slime to start slime.
> 3. I use C-x C-f to open the code directory.
[snip]
> 6. After writing a function, I do fooble warp thud to test and
> debug it.
>
> ...and so on. Almost like an HCI-esque observational study of your
> typical coding session. Maybe even including non-coding tasks, such as
> how you design the program architecture or do change management.
>
> As a young hacker, I'm starting to experience problems with the
> minimalist techniques I've been using so far; they're OK for class
> assignments, but they don't scale well. How do old hands do it?
Not to this level of detail yet. I have been working on something
like that though. On my website I describe my Lisp configuration on
OS X (which currently has nice google karma on the search "lisp os
x"). And although I am far from being an old hand, I have just
recently created a page that is intended to be a sort of process
overview. I published a link in the other thread, but I'll repeat it
here for your convenience:
http://www.david-steuber.com/Lisp/Development/
I've been a bit under the weather the past week or so and I haven't
been doing any coding as a consequence :-(
However the Carbon application I am working on (which is a throw-away
learning exercises) is actually a pretty good candidate for keeping
track of my actual workflow for documenting. It is atypical though.
In extreme brief:
1. Launch Carbon Emacs from dock
2. Launch Carbon App from finder
3. Use M-x slime-connect to attach to running application
4. Use C-x C-f to open files for editing
5. Use C-c C-c to compile definitions
6. Sometimes use C-c C-k to compiile and load whole file
7. Poke the GUI for testing
8. Use Console.app to see debug logging output
And so on.
Other things include using ASDF to keep my project organized. I also
have a shell script to rebuild my Lisp image as a batch process.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Spake David Steuber:
>> Orthogonal to this, has anyone written up a thorough description of
>> their (personal, Lisp) development workflow? Almost like an
>> observational study of your typical coding session. Maybe even
>> including non-coding tasks, such as how you design the program
>> architecture or do change management.
>
> Not to this level of detail yet. I have just recently created a page
> that is intended to be a sort of process overview.
>
> http://www.david-steuber.com/Lisp/Development/
Cool. Another way of thinking about this is a chronologically-sorted
collection of neat tricks from the Lisp community as a whole.
I can go through documentation like Cliki, Emacs-wiki or the Slime
manual and say `hey, neat', but if everything was collected in
workflow-order I think it'd be easier to internalize. Links could to
those other resources could provide an in-depth discussion of each neat
thing.
Some neat things I know are:
- Using w3m-el to browse the hyperspec.
- Using a local copy of the hyperspec.
- Creating an init file in $HOME.
- Saving (and later reloading) the core image.
- Displaying lambda as the greek letter.
- Using a string as the first expression in a function for
literate programming.
- Using RCS from within emacs (via vc-mode).
- Using emacsclient or gnuserv to attach to a running emacs.
- Using and configuring screen.
Some other neat things:
- Using and building ASDF packages.
- Using and building common-lisp-controller / debian packages.
- How to deploy Windows and OSX applications.
I'll try to get something useful together at
http://twb.ath.cx/wiki/LispDevelopment.xhtml
--
Trent Buck, Student Errant
Computers? And here I've been reading my CDs with a laser pointer!
Trent Buck <·········@gmail.com> writes:
> Some neat things I know are:
> [...]
> - Using RCS from within emacs (via vc-mode).
CVS.
> [...]
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Spake Pascal Bourguignon:
>> - Using RCS from within emacs (via vc-mode).
>
> CVS.
Well, TLA (Arch) RSN. From OP: "minimalist techniques not working".
--
Trent Buck, Student Errant
Confidence is that feeling experienced prior to comprehension.
Trent Buck <·········@tznvy.pbz> writes:
> Orthogonal to this, has anyone written up a thorough description of
> their (personal, Lisp) development workflow? Along the lines of
I use CMUCL with GNU Emacs and SLIME under Linux with KDE. The Lisp
applications I create are currently not complex, e.g. I don't do web
development.
> 1. I start (Carbon GUI) Emacs from the OSX Dock.
> 2. I do M-x slime to start slime.
I usually start Emacs from the shell, then issue `M-x slime' (I also
have a `slime' shell script that does this). If I need McCLIM, I
start SLIME with `C-u M-x slime clim', where `clim' is a script that
starts CMUCL with a McCLIM image.
> 3. I use C-x C-f to open the code directory.
I do `M-x cd' to move to the code directory and `,load-system' to load
the application I'm working on via ASDF. Then I `C-x 5 f' to open the
files I need to edit in different Emacs frames, which I put in as many
KDE virtual desktops as required (usually no more than a couple).
So, I keep an Emacs frame with a SLIME REPL, and a number of frames
with Lisp source code buffers. Each frame is maximized in its
desktop, and I use the 10x20 font on a 17" LCD screen at 1280x1024 (my
eyesight is no longer so good...). I prefer to keep Firefox open in
yet another desktop for accessing a local copy of the HyperSpec via
SLIME.
It's easy and quick to jump to a different desktop, but others prefer
to do the same entirely within Emacs and its buffer switch commands.
> 6. After writing a function, I do fooble warp thud to test and
> debug it.
I usually compile new functions with `C-c C-c', and switch to the REPL
for evaluating test forms and experiment with the system I'm working
on. I use the SLIME inspector and debugger backtrace a lot.
Perennial kudos to the SLIME developers.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> If I need McCLIM, I start SLIME with `C-u M-x slime clim', where
> `clim' is a script that starts CMUCL with a McCLIM image.
I didn't realize that the `slime' function accepts interactive
arguments. Can you share this "clim" script as an example? Is this an
ELisp function, or maybe some CL file that gets loaded by swank? Is
`slime-register-lisp-implementation' involved?
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> If I need McCLIM, I start SLIME with `C-u M-x slime clim', where
>> `clim' is a script that starts CMUCL with a McCLIM image.
>
> I didn't realize that the `slime' function accepts interactive
> arguments. Can you share this "clim" script as an example? Is this an
Sure. Here is `clim', which is just a shell script:
#!/bin/sh
DIR=~/src/mcclim
exec cmucl -core $DIR/clim.core
When I update my working copy of the McCLIM CVS sources in
~/src/mcclim, I dump an image in ~/src/mcclim/clim.core. My CMUCL
executable is called `cmucl', not `lisp', because all Lisps want to be
`lisp' :)
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
I use the following script, which I put in /usr/local/bin. Then I
soft-link it as follows:
lisp -> lisp-wrapper
clim -> lisp-wrapper
garnet -> lisp-wrapper
Then the script looks for a file named "<foo>.image" (where foo is the
name it is linked to) in /usr/local/lib/cmucl/lib (actually in
$CMUCLLIB). I prefer using <foo>.image as a naming convention to
avoid conflict with FreeBSD's default habit of calling its core files
<foo>.core. I only had my lisp.core file wiped out once, but that was
enough.
It also handles the "executable" stuff I was doing in the past.
#!/bin/sh
#
NAME=`basename $0`
# Configure this.
CMUTOP=/usr/local/lib/cmucl
# Set up CMUCLLIB environment variable to point to run-time files.
CMUCLLIB=$CMUTOP/lib
export CMUCLLIB
USERCORE=FALSE
EXECUTABLE=FALSE
# Point to lisp startup binary.
if [ -e $CMUTOP/lib/$NAME -a -x $CMUTOP/lib/$NAME ] ; then
# There's a lisp executable in CMUCLLIB with the name we want.
CMUBIN=$CMUTOP/lib/$NAME
EXECUTABLE=TRUE
else
# Just use the normal lisp loader.
CMUBIN=$CMUTOP/bin/lisp
# Set up lisp image file according to name of script.
CMUCORE=$CMUCLLIB/$NAME.image
# See if user specified an image file. If so, override default
# image file.
for arg in ·@
do
case "$arg"
in
-core) USERCORE=TRUE;;
esac
done
fi
# Don't let lisp dump core.
ulimit -c 0
# Run Lisp
if [ "$EXECUTABLE" = TRUE ]
then
exec $CMUBIN ··@"
else
if [ "$USERCORE" = TRUE ]
then
exec $CMUBIN ··@"
else
exec $CMUBIN -core $CMUCORE ··@"
fi
fi
--
Fred Gilham ······@csl.sri.com
The spam folder --- you will never find a more wretched hive of scum
and villainy. We must be cautious.
Paolo Amoroso <·······@mclink.it> writes:
> "Steven E. Harris" <···@panix.com> writes:
>
>> Paolo Amoroso <·······@mclink.it> writes:
>>
>>> If I need McCLIM, I start SLIME with `C-u M-x slime clim', where
>>> `clim' is a script that starts CMUCL with a McCLIM image.
>>
>> I didn't realize that the `slime' function accepts interactive
>> arguments. Can you share this "clim" script as an example? Is this an
>
> Sure. Here is `clim', which is just a shell script:
>
> #!/bin/sh
> DIR=~/src/mcclim
> exec cmucl -core $DIR/clim.core
Note that as of a week or so ago, in the CVS HEAD version of SLIME you
can replace that shell script with something like the following elisp:
(slime-register-lisp-implementation
"clim"
(format "cmucl -core %s" (expand-file-name "~/src/mcclim/clim.core")))
This makes "clim" a symbolic name for the command to invoke cmucl with
the appropriate core file and which can be passed to C-u M-x slime.
The name of the SLIME repl will be taken from the symbolic name so
you'll get a repl buffer named *slime-repl clim*.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Trent Buck <·········@tznvy.pbz> writes:
> Spake Andrei Zernoveanu:
>> What holds me up right now is understanding how to set up my
>> environment correctly. ... So, any resources for somebody that sees
>> Lisp for the first time would be greatly appreciated
>
> Orthogonal to this, has anyone written up a thorough description of
> their (personal, Lisp) development workflow?
i work with web apps, this influences my development workflow quite a
bit.
1) I startup emacs. i'm using a recent CVS build of emacs on macos x
10.3. [i generally restart emacs a couple times a week].
2) I open up a terminal and decide what lisp image i need to mess
with.
I generally work locally so i just go the directory containing the
development branch of whatever application i'm interested in and
load its startup script. This script loads whatever systems (using
ASDF), performs any db initialization and, finally, creates a
slime-server.
A couple times a week (though this varies a lot) i need to
patch/debug the production images. In this case everything is
already setup so all i need to do is setup the ssh tunnel which
will allow me to connect to the remote slime server.
3) from within emacs: M-x slime-connect RET RET
4) If i'm patching a running image i'll generally have created a file
somewhere containg whatever update code i need. this will generally
be class/method definitions and some code to update the existing db
or objects. some times it's easier to just re-load and re-compile
everything so i'll simply perform whatever shutdown is needed and
quit the image (and then go back to step 2).
If i'm debugging a running image most of my time will be spent
jumping back and forth between the inspector (C-c I or M-x
slime-inspect), a browser window and various sldb buffers. I use
the slime-inspector a LOT and i've recently started using
slime-edit-value (C-c E) quite a bit. I've hacked my local slime to
allow me to edit things from within the inspector and I've hacked
slime-edit-value to allow me to put unreadable objects in it.
Once i've figured out what the problem is i may fix it immeditaly
(if its a trivial change) or i'll disconnect from the remote server
and attempt to reproduce and fix the bug locally.
If, as is normally the case, i'm performing active development I'll
just open up whatever files i'm interested in and start
editing. The first things i usually do are:
, RET !d RET <wherever>
since i usually start the lisp a directory which isn't the source
code directory. Then i use:
, RET !p RET <package>
to switch into the system's package.
I don't like writing code directly in the repl, so i always keep a
slime-scratch buffer open (M-x slime-scratch) and perform my test
there. I've patched my slime to save slime-scratch buffers, this is
as much due to my habit to hit C-x C-s as it is to a real need to
save scratch buffers.
5) I've gotten into the habit of using "structured editing," i've put
up my comments at: (this has been edited/improved by some many
people that's it's hardly "my" guide anymore)
http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs
6) I use a modified version of osx-itunes to control itunes. If my dog
hadn't eaten them i'd be wearing a nice pair of sennheiser
headphones.
7) I live and die with slime-complete-symbol. i use it so much that
i've setup emacs so that hiting the \ twice runs
slime-complete-symbol and C-c TAB runs slime-complete-form (which i
don't use very often).
8) I tend to create lots of small files and use M-. and M-, to move
through them. I use C-x r SPC (point-to-register) and C-x r j
(jump-to-register) occasianly.
9) I contemplate exiting, so I've no particular advice to give.
I'm sure i do lots of other things, but i can't think of any at the
moment.
hth.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen