Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Common Lisp Cookbook - proposal and request for comments

482 views
Skip to first unread message

Dr. Edmund Weitz

unread,
Jan 24, 2002, 4:52:13 AM1/24/02
to
I think most of you will agree that once you're hooked on Common Lisp
you realize that you've found a language which has things to offer
that no competitor has, so I won't discuss this any
further. Nevertheless, CL is also a language that is somewhat hard for
newcomers, especially for those who've used other, more widespread
languages before: I come from the Perl/C/Java camp (and this is how I
pay my rent) and there are myriads of _simple_ tasks that I could
implement in these languages without thinking while I would have to
work hard to get them done in CL. This is what this posting is about:

I now that many c.l.l regulars despise Perl, but I hope you'll agree
that the Perl community has a couple of things that we can learn
from. The one thing that I'm going to talk about here is the famous
(?) Perl Cookbook (see <http://www.oreilly.com/catalog/cookbook/>), a
nice little book that provides concise, elegant and instructive
answers to seemingly simple questions like "You need to find the
number of days between two dates or times" or "You want to get a list
of filenames similar to MS-DOS's *.* and Unix's *.h", or "You want to
access or modify just a portion of a string, not the whole thing". If
you've been using Lisp since the day you were born this might seem
trivial to you, but judging from my experience - and from many
questions I've read in this newsgroup - many of these simple tasks
seem to be harder than they should be in CL (and they are usually not
dealt with in the standard literature, i.e. Graham, Norvig,
Winston/Horn, and so on).

This posting is a proposal for a community effort to provide a "Common
Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
for Java, Python and other languages). It'll provide 'recipes' that'll
help you in implementing mundane stuff and thus enabling you to get
more comfortable with the language as well as giving you more time to
think about the stuff that's really hard (and would probably be a pain
to do in other languages).

I hereby volunteer to organize/maintain this project if enough people
are willing to help. I will also be able to host the project (see
below) if this will be the agreed-upon way to do it. Following are a
couple of thoughts about the Cookbook project. I hope many people will
have something to say about it - additions, corrections, improvements,
suggestions, comments are welcome (and should be directed to the
newsgroup and not to my email address).

[Disclaimers: 1. I'm rather new to CL. I'm lightyears away from being
the Tom Christiansen of Common Lisp, so I will need the help of as
many people as possible. (A newbie might be able to ask the right
questions but somebody has to answer them...) 2. I have a family to
feed, so I can't guarantee to keep any terms.]

Having said that, here comes the main stuff:

0. What it is and what it isn't.

- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
AutoLisp, or whatever.

- The target audience are people who are new to (Common) Lisp - people
who have just discovered the language and are willing to learn it.

- The Cookbook will provide small code snippets as answers to
frequently asked questions usually beginning with "How do I..." (see
above for examples). The code should ideally be accompanied with a
discussion of how it works and what has to be paid attention to plus
pointers to relevant chapters in books, online articles or the
CLHS. (The standard article in the Perl Cookbook has four parts:
"Problem", "Solution", "Discussion", "See also". An example can be
found at
<http://www.oreilly.com/catalog/cookbook/chapter/ch08.html>.)

- The project does not aim to supplant introductory books or the
HyperSpec. People who use the Cookbook are expected to know the
language basics and to consult the CLHS if necessary.

- The Cookbook should be agnostic to operating systems and
implementations if possible. It will surely be necessary to provide
information that is specific to a certain OS or vendor (especially
if we're talking about non-ANSI stuff) but it would be nice if
readers had a choice between different versions.

- Contributions to the Cookbook aren't expected to be exhaustive or
worthy a Pulitzer Price. On the contrary - I am convinced that at
least thirty percent of the typical newbie questions can be answered
by pointing them to a specific function entry in the CLHS (or - even
better - by providing a one-line solution).

- Due to the nature of this there will be some intersection with the
c.l.l FAQ (recently revived by Christophe Rhodes at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
these projects are different enough to warrant two distinct
documents.

- This'll be an ongoing collaborative effort and it will be perfectly
OK to just post a good question. Let someone else take care of the
answer.

1. Content

Here's a quick sketch of the content in very rough form. It's
assembled from the O'Reilly Books, the CLHS, and from postings to this
newsgroup.

- Basics: Installation, Loading and Compiling
- Numbers: BIGNUMS, rationals, complex numbers
- Strings / Regular Expressions
- Dates and Times
- Arrays
- Hash Tables
- Lists/Conses
- Structures
- CLOS
- Other data structures: Btrees, Queues, Linked Lists
- Iteration: LOOP, SERIES, MAP functions
- Searching and Sorting
- Input and Output, Streams, FORMAT, the Lisp Reader
- Conditions, Error Handling
- File Access, File Contents, Directories
- Packages
- Defsystem
- Debugging, Profiling, Advice
- Database Access
- Sockets
- Internet Protocols, Web Serving
- Multi-Processing, Multi-Threading
- FFI, Extending and Embedding CL
- Communicating with other processes
- GUI
- I18N
- XML
- MOP

This is of course open to discussion. I'm sure I've missed
something. Also, I'm not sure about the correct order and I'm aware of
the fact that I've mixed rather basic stuff with advanced topics.

Let me repeat that I think the basic stuff is important and this'll be
what the Cookbook is about. Many Lisp newcomers have an idea how to
implement something in their preferred programming language but they
tend to feel lost if they're to choose from the wealth of built-in
functions and data types that CL has to offer.

2. Infrastructure / How to do it

2.1. The first thing that comes to mind (and has been mentioned here
already) is CLiki. The good thing about it is that it's already
there and we can simply start hacking in questions and
answers. But I think it might be better if we had some means to
organize the whole project - providing for ways to easily
re-structure the whole document and for automatic generation of
different formats like HTML, TeX, PDF...

2.2. That's why I think a custom-tailored database-backed website
would be the best solution. As with CLiki, everybody should be
able to add content or change what's there already (maybe after
registering once with his name and email address). I would
volunteer to set up such a thing (although I'd currently write it
in mod_perl/DBI - shame on me - rather than in CL/USQL) and
provide a server to host it.

[This could be somewhat similar to the Python Cookbook at
<http://aspn.activestate.com/ASPN/Cookbook/Python>. I haven't
looked at every detail but it seems to be OK.]

2.3. As an alternative one could start a Sourceforge project to host a
couple of Texinfo files. Contributors would have to use CVS.

3. License

This will be a collaborative effort, so we'll have to find a license
that seems fair to everyone who contributes code and advice. I'm not
familiar with Open Source Documentation Licenses. What do you think
would be the best one and why?

4. "Prior Art"

I'm pretty sure that most of the stuff that would go into this
Cookbook has already been posted to c.l.l at least once by very
knowledgeable people, it's just a matter of finding and organizing
it. Would you think it'll be OK to take a code snippet from
groups.google.com, put it into the Cookbook and add a reference like
"posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
<news:m3y9mze...@disney.com>" or do you see any legal
restrictions?

OK, I hope this is enough to start a discussion and to solicit more
input. I'm really willing to do this - not only because I'm a good guy
(ahem) but mainly because I think it'll be a very good way to improve
my own knowledge of Common Lisp. It'd be great if many others would
join this project for whatever reasons they might have.

Thanks for your time,
Edi.

Dr. Edmund Weitz

unread,
Jan 24, 2002, 8:09:26 AM1/24/02
to
e...@agharta.de (Dr. Edmund Weitz) writes:

> 3. License
>
> This will be a collaborative effort, so we'll have to find a license
> that seems fair to everyone who contributes code and advice. I'm not
> familiar with Open Source Documentation Licenses. What do you think
> would be the best one and why?

Sorry for answering to myself but this might be interesting:

<http://slashdot.org/article.pl?sid=02/01/23/2022235&mode=thread&threshold=1>

Edi.

Marc Battyani

unread,
Jan 24, 2002, 8:55:42 AM1/24/02
to

"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3it9so...@bird.agharta.de...
[snip...]

> Having said that, here comes the main stuff:
>
> 0. What it is and what it isn't.
>
> - This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.
>
> - The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.

Don't forget those who learned Lisp in some recent (or distant) past but are
coming back to it.

[snip...]

> - Due to the nature of this there will be some intersection with the
> c.l.l FAQ (recently revived by Christophe Rhodes at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> these projects are different enough to warrant two distinct
> documents.

If they end up having too much intersection it will be possible to merge
them anyway.

[snip...]

> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...

sexpr ?

> 2.2. That's why I think a custom-tailored database-backed website
> would be the best solution. As with CLiki, everybody should be
> able to add content or change what's there already (maybe after
> registering once with his name and email address). I would
> volunteer to set up such a thing (although I'd currently write it
> in mod_perl/DBI - shame on me - rather than in CL/USQL) and
> provide a server to host it.

Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)

Marc


Dr. Edmund Weitz

unread,
Jan 24, 2002, 9:26:08 AM1/24/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)

One of my servers has mod_lisp installed and I'm experimenting with
CMUCL there. However, if I would write the application with mod_lisp
and CL I'd need _much_ more time for it (while mod_perl is my
bread-and-butter currently). Installing UncommonSQL alone might take
me a couple of hours... :(

[This is a FreeBSD machine, no CCLAN and apt-get install available.]

Once the Cookbook is finished all this will be much easier of
course. Version 2.0 will be hosted by a CL web server... :)

Cheers,
Edi.

Marc Battyani

unread,
Jan 24, 2002, 10:10:25 AM1/24/02
to

"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3d6zza...@dyn138.dbdmedia.de...

> "Marc Battyani" <Marc.B...@fractalconcept.com> writes:
>
> > Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)
>
> One of my servers has mod_lisp installed and I'm experimenting with
> CMUCL there. However, if I would write the application with mod_lisp
> and CL I'd need _much_ more time for it (while mod_perl is my
> bread-and-butter currently). Installing UncommonSQL alone might take
> me a couple of hours... :(

Why do you want a SQL database ? For now you have 0 article so you don't
need an SQL database. Even when you have lots of articles, you won't need an
SQL database.
As I wrote in the previous post, you can use sexprs to store the data. Or
some CLOS objects in a hash table or in a list. There are lots of quick
start solutions.

To start you just need a server, apache, mod_lisp and an HTML generation
macro and that's it.
Start with an in memory database saved as an ascii file (remember Lisp has a
nice reader). It's better to have a working solution in a few days and then
to refine it when it is a huge success.

Then you can put in it the first article : How to write a successful web
application in Lisp in 3 days...

Marc


Pierre R. Mai

unread,
Jan 24, 2002, 10:27:11 AM1/24/02
to
e...@agharta.de (Dr. Edmund Weitz) writes:

> This posting is a proposal for a community effort to provide a "Common
> Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
> for Java, Python and other languages). It'll provide 'recipes' that'll
> help you in implementing mundane stuff and thus enabling you to get
> more comfortable with the language as well as giving you more time to
> think about the stuff that's really hard (and would probably be a pain
> to do in other languages).

I think this is a very good proposal indeed, and highly refreshing,
after all the constant whining that has been posted here during the
last couple of weeks. I'll add a couple of comments below:

> - The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.

I think it wouldn't hurt to let the focus expand as needed, to include
not quite so new people, who are still willing to learn common idioms,
etc. There are quite a number of known idioms for slightly
advanced/specialized stuff, which would profit from being presented in
a cookbook/recipe like style, like MOP-stuff, etc.

> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...

It might be useful to start off with CLiki (possibly on a separate
site), and expand the mark-up stuff, and reorganization facilities...

> 4. "Prior Art"
>
> I'm pretty sure that most of the stuff that would go into this
> Cookbook has already been posted to c.l.l at least once by very
> knowledgeable people, it's just a matter of finding and organizing
> it. Would you think it'll be OK to take a code snippet from
> groups.google.com, put it into the Cookbook and add a reference like
> "posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
> <news:m3y9mze...@disney.com>" or do you see any legal
> restrictions?

Legally, the stuff posted to newsgroups is covered by copyright laws,
although the application of copyright law to Usenet is probably not
very well understood. I.e. one would presume that certain rights are
implicitly granted by posting, like e.g. the right to redistribute
and copy for the purposes of dissemination on Usenet servers. There
are also the obvious rights granted under fair-use, but one of the
problems with this is that the relation of quoted and unquoted amounts
are taken into consideration, and it is easy to fall afoul of this
requirement with Usenet postings, which are already quite small.

On the whole I'd advise that you get the permission of the poster
(either for an individual posting, or for all postings on c.l.l by the
given poster) prior to inclusion, since this is the best way to cover
yourself, and it might also lead to further interesting input from the
poster, e.g. by pointing out better, or more relevant code in another
posting/source, or by informing the poster of the existence of your
project, which might lead to the poster participating more directly,
or giving you pointers to other interesting articles in the past or
the future.

You might want to contact Paolo Amoroso, who has been doing excellent
work as the editor/creator of the EncyCMUCLopedia, and who will
probably be able to give you more advice on this, and related matters.

Including pointers to the original article is also very important from
the POV of the user, since it gives him the ability to read relevant
parts of the whole thread that give him more context and background on
the why of that particular solution. This prevents the cookbook
approach from degenerating into a simple clipboard to copy from
without understanding, but as a valuable starting point for a journey
that results in deeper insight into the language, and the problem and
solution spaces surrounding a particular question.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein

Marc Spitzer

unread,
Jan 24, 2002, 11:28:14 AM1/24/02
to
In article <0135468F4F467E47.8DC05578...@lp.airnews.net>

, Marc Battyani wrote:
>
> "Dr. Edmund Weitz" <e...@agharta.de> wrote in message
> news:m3d6zza...@dyn138.dbdmedia.de...
>> "Marc Battyani" <Marc.B...@fractalconcept.com> writes:
>>
>> > Argh! mod_perl.... Please use mod_lisp or any CL web server ;-)
>>
>> One of my servers has mod_lisp installed and I'm experimenting with
>> CMUCL there. However, if I would write the application with mod_lisp
>> and CL I'd need _much_ more time for it (while mod_perl is my
>> bread-and-butter currently). Installing UncommonSQL alone might take
>> me a couple of hours... :(
>

If you are looking for a caned app type of solution, take a look
at openacs.org. It looks like what you want in the first draft of
the site is already there:
sql back end(postgres and oracle)
message boards
administrative interface, create/modify/delete message boards ...
full text search

I have installed it a few times to play with and have gotten it running
on freebsd. I would be willing to help install/manage it.

A couple of possible issues:
it uses aolserver not apache
tcl is the scripting language

marc

Christophe Rhodes

unread,
Jan 24, 2002, 11:37:32 AM1/24/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> > - Due to the nature of this there will be some intersection with the
> > c.l.l FAQ (recently revived by Christophe Rhodes at
> > <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> > these projects are different enough to warrant two distinct
> > documents.
>
> If they end up having too much intersection it will be possible to merge
> them anyway.

Absolutely -- I'd welcome contributors over here too; time is
limited... :)

I do want to get the FAQ up to postable state, but, alas, the real
world is intervening at the moment.

Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

Paolo Amoroso

unread,
Jan 24, 2002, 12:06:16 PM1/24/02
to
On 24 Jan 2002 16:27:11 +0100, "Pierre R. Mai" <pm...@acm.org> wrote:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > This posting is a proposal for a community effort to provide a "Common
> > Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources

[...]


> > it. Would you think it'll be OK to take a code snippet from
> > groups.google.com, put it into the Cookbook and add a reference like
> > "posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
> > <news:m3y9mze...@disney.com>" or do you see any legal
> > restrictions?

[...]


> You might want to contact Paolo Amoroso, who has been doing excellent
> work as the editor/creator of the EncyCMUCLopedia, and who will
> probably be able to give you more advice on this, and related matters.

Quite simple. For each batch of newsgroup or mailing list postings from a
same author that I plan to include in a version of the EncyCMUCLopedia, I
contact the author asking for permission, and including all material for
his reference and convenience. Then I include in the EncyCMUCLopedia
distribution a copy of each posting with full headers as received by my
mail/newsreader, adding a blurb such as "included with permission" in each
index entry.

As Pierre suggests, I have found that contacting authors provides valuable
additional feedback on the material I am interested in.

As for useful tools with which to maintain the Cookbook, I suggest Edmund
to have a look at the SBCL Internals Documentation project, which has
similar technical requirements and is based on CLiki technology:

http://ww.telent.net/sbcl-internals/index


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

novice106

unread,
Jan 24, 2002, 1:50:05 PM1/24/02
to
"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m3it9so...@bird.agharta.de...

[...]

> OK, I hope this is enough to start a discussion and to solicit more
> input. I'm really willing to do this - not only because I'm a good guy
> (ahem) but mainly because I think it'll be a very good way to improve
> my own knowledge of Common Lisp. It'd be great if many others would
> join this project for whatever reasons they might have.

This will be extremely useful for people like me who know something of the
Lisp language but have little experience using it for daily work. I
currently use CMUCL for experimenting with ideas in an Emacs/ILISP buffer,
but I'd like to go beyond that.

I think one of the first hurdles is understanding the package system and
installing new 'modules' (for want of correct terminology). People quite
often complain that the free Lisp implementations lack GUI toolkit support,
database access and so on. It's obviously not true. The packages are out
there, but the installation instructions, if present, often assume prior
knowledge of how Lisp packages work, how they're loaded, how they're used,
etc.

I confess with some embarrassment that I don't know anything about this, and
have not found any idiot-proof instructions. Whilst I could probably install
any package through trial and error, I do think that Common Lisp's way of
handling packages and installing/loading of extensions is sufficiently
different from other languages to merit some basic explanation. Even simple
concepts like "saving an image", which experienced Lisp users naturally take
for granted, are alien to most people who come to Lisp from other languages.
In my opinion, this would be a good place to start.

If we had a page with detailed step-by-step instructions on how to set up,
say, Clisp or CMUCL with a commonly requested configuration, eg. complete
with bindings to GTK+ and MaiSQL, it would give the user the background s/he
needs to install other packages when the time comes.

I think your project is an excellent idea.
I will certainly be willing to contribute when I can.

Christophe Rhodes

unread,
Jan 24, 2002, 1:23:56 PM1/24/02
to
"novice106" <novi...@yahoo.com.au> writes:

> "Dr. Edmund Weitz" <e...@agharta.de> wrote in message
> news:m3it9so...@bird.agharta.de...
>
> [...]
>
> > OK, I hope this is enough to start a discussion and to solicit more
> > input. I'm really willing to do this - not only because I'm a good guy
> > (ahem) but mainly because I think it'll be a very good way to improve
> > my own knowledge of Common Lisp. It'd be great if many others would
> > join this project for whatever reasons they might have.
>

> If we had a page with detailed step-by-step instructions on how to set up,
> say, Clisp or CMUCL with a commonly requested configuration, eg. complete
> with bindings to GTK+ and MaiSQL, it would give the user the background s/he
> needs to install other packages when the time comes.

Well, we sort of do, but currently it starts with
"1. Install Debian..."
because that is the only "Operating Environment" that
common-lisp-controller, or any equivalent to my knowledge, runs
on. Counterexamples are welcome :)

Thaddeus L Olczyk

unread,
Jan 24, 2002, 6:45:22 PM1/24/02
to
On 24 Jan 2002 10:52:13 +0100, e...@agharta.de (Dr. Edmund Weitz)
wrote:

Stuff about the language written by Larry "Should Be Lined Up Against
A " Wall cut, allthough I'm tempted.

>This posting is a proposal for a community effort to provide a "Common
>Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
>for Java, Python and other languages). It'll provide 'recipes' that'll
>help you in implementing mundane stuff and thus enabling you to get
>more comfortable with the language as well as giving you more time to
>think about the stuff that's really hard (and would probably be a pain
>to do in other languages).
>

While I think it should be vast enough so that people can open to a
page and find a solution close to a problem they have, I don't think
the focus should just be a "recipe" thing.

Rather the focus should be on getting people "thinking in lisp" well
enough so that they can answer similar questions on their own.

>I hereby volunteer to organize/maintain this project if enough people
>are willing to help. I will also be able to host the project (see
>below) if this will be the agreed-upon way to do it. Following are a
>couple of thoughts about the Cookbook project. I hope many people will
>have something to say about it - additions, corrections, improvements,
>suggestions, comments are welcome (and should be directed to the
>newsgroup and not to my email address).
>

>


>Having said that, here comes the main stuff:
>
>0. What it is and what it isn't.
>
>- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.
>

I believe the lions share of jobs ( and I do believe getting a "lisp
job" is the goal of many of the newer people ) are in the "embedded
language" business where Lisp is used as an embedded scripting
language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
on ACL is the best thing.

Instead I think you should say that ACL solutions are prefered over
Scheme solutions or Emacs Lisp solutions. But in the end the best
solutions are ones that can be used by as many possible
implementations as is possible. ( You might hafve to tweak them
though. )

>- The target audience are people who are new to (Common) Lisp - people
> who have just discovered the language and are willing to learn it.
>

Maybe also people who use lisp but rarely, say once a month. So some
things fade.
I also think the focus should be on people with some coding exerience
( at least a year in another language ) rather then someone whose
first language is lisp.

>- The Cookbook will provide small code snippets as answers to
> frequently asked questions usually beginning with "How do I..." (see
> above for examples). The code should ideally be accompanied with a
> discussion of how it works and what has to be paid attention to plus
> pointers to relevant chapters in books, online articles or the
> CLHS. (The standard article in the Perl Cookbook has four parts:
> "Problem", "Solution", "Discussion", "See also". An example can be
> found at
> <http://www.oreilly.com/catalog/cookbook/chapter/ch08.html>.)
>

I think that many problems may involve multiple solutions.
For example: quick hacks versus more complicated solutions which run
more efficiently.
Another might be to a question like:
How do I find the extension of a file?
Solution 1: use pathname-type.
Solution2: Describe how to parse the filename.

The reason is that people seeing this question might be wondering
howto get the extension, but others might be thinking:
" I need to parse this string in a way similar to the way that you
parse a filename to get the extension. The answer to that question
might be give me the answer to my question."

>- The project does not aim to supplant introductory books or the
> HyperSpec. People who use the Cookbook are expected to know the
> language basics and to consult the CLHS if necessary.
>

Here I would disagree. The CLHS is a standard. Standards are mean for
language implementors, not for users. Therefore they are often
unreadable. An answer to the question:
"How do I write a while loop?"
might be to look up the "loop" command in the CLHS.
At that point I expect the reader to give up on Lisp and take up VB.
At the very least ClTl2 should be considered a supplimental manual.

I think this is all very wrong. It reads like the table of contents of
a lisp book, and will therefore reflect many lisp books ( and their
problems ).
A very partial version might be something like:

1) Non Lisp problems.
a) Looping.
i) How do I write a "For Loop"?
ii) How do I write a "while Loop"?
iii) How do I write a "repeat-until Loop"?
iv) Write an inifinite loop?
v) Return from the infinte loop in iV.
b) Files and Directories
i) How do I get a list of files in a directory?
ii) How do I get a list of directories in a directory?
iii) How do I read in a file?
Iv) How do I write to a file?
2) Lisp problems
1) List manipulation
i) How do I add something to a list?
a) At the biginnning.
b) At the end.
c) In the middle.
ii) How do I find an element in a list"
iii) How do I remove an element for a list?
2) What is the equivalent of an
associated array/hash table/dictionary/map?
i) How do I look up an association?
ii) How do I look up a reverse association?
iii) How do I create an association?

>2. Infrastructure / How to do it
>
>2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...
>

While I hate to promote Smalltalk. You might want to check out
swiki. It seems to be thew best wiki server around, and includes
the ability to lock pages ( as well as very advanced Administration ).
The one weakness is that it doesn't have a startup/shutdown script
needed by UNIX systems.

You might also want to check out ThoughtWeaver. This is a Wiki variant

Jim Coplien used to to collect a set of patterns on the organisational
structure of a development group. One thing Thought Weaver did was
collect the web pages into a pdf file for people to download the
latest snapshot.

Wiki's would be OK, but please keep away from
TheStupidWikiWayOfNamingThings.
At first it's cute but gets annoying after a while.
There are several free wiki's which don't use that format.

>
>3. License
>
>This will be a collaborative effort, so we'll have to find a license
>that seems fair to everyone who contributes code and advice. I'm not
>familiar with Open Source Documentation Licenses. What do you think
>would be the best one and why?
>

There is exactly one postgress book out there. When it first came out
it was downloadable from the guys web site. He was distributing it
under some open source license. The Hunt and Thomas Book "Practical
Ruby" has a freely downloadable version too. ( In fact it comes in
many formats. )

>4. "Prior Art"
>
>I'm pretty sure that most of the stuff that would go into this
>Cookbook has already been posted to c.l.l at least once by very
>knowledgeable people, it's just a matter of finding and organizing
>it. Would you think it'll be OK to take a code snippet from
>groups.google.com, put it into the Cookbook and add a reference like
>"posted to comp.lang.lisp by Donald Duck at Dec 12, 1996 as
><news:m3y9mze...@disney.com>" or do you see any legal
>restrictions?
>

This may sound sleasy, but if you only take the snippet then I don't
believe there will ber any problem. If you have doubts change the
variable and function names.

As an example, an answer to the question "How do you read a file a
line at a time?" might read:

(with-open-file (stream file)
(do ((line ( read-line stream) (read-line stream nil 'eof))
((eq line ' eof) return-value)))
(process-line line)))

Do you think anyone should get credit for that?
After all about a dozen people might have posted something similar.

BTW if you use something like a wiki then pages should have phases.
The initial phase would be a general discussion of different
approaches to solve a proble. The consolidation phase should be
when people stop discussion and start consolidating the page into a
clear answer. The final phase is when the solution is done and that
page is locked.

Thaddeus L Olczyk

unread,
Jan 24, 2002, 6:58:23 PM1/24/02
to
On Fri, 25 Jan 2002 05:50:05 +1100, "novice106"
<novi...@yahoo.com.au> wrote:

>I think one of the first hurdles is understanding the package system and
>installing new 'modules' (for want of correct terminology). People quite
>often complain that the free Lisp implementations lack GUI toolkit support,
>database access and so on. It's obviously not true. The packages are out
>there, but the installation instructions, if present, often assume prior
>knowledge of how Lisp packages work, how they're loaded, how they're used,
>etc.

Last weekend I tried to install lispdebug for CLisp.
Apparently the maintainer of lispdebug stopped maintaining the
CLisp version ( this is a guess ) and the package system changed so
that CLisp no longer installs.
I've gone over to the CLisp mail-list and been trying to get some
help, but things have started to get testy over there. ( I'm try to
not let the tone get to hot. )

dj special ed

unread,
Jan 24, 2002, 11:53:10 PM1/24/02
to
Excellent! I these are all topics that we would love to see addressed
from the "pragmatic" programmer's perspective--especially those topics
that are never formally addressed.

-dj

> - Basics: Installation, Loading and Compiling

> - Strings / Regular Expressions
> - Dates and Times

> - File Access, File Contents, Directories

> - Other data structures: Btrees, Queues, Linked Lists

> - CLOS


> - Iteration: LOOP, SERIES, MAP functions

> - Input and Output, Streams, FORMAT, the Lisp Reader
> - Conditions, Error Handling

> - Packages
> - Defsystem
> - Debugging, Profiling, Advice
> - Database Access
> - Sockets
> - Internet Protocols, Web Serving
> - Multi-Processing, Multi-Threading
> - FFI, Extending and Embedding CL
> - Communicating with other processes
> - GUI

> - XML

> - Lists/Conses
> - Searching and Sorting
> - Hash Tables
> - Structures
> - Arrays

> - MOP
> - I18N

Alberto Riva

unread,
Jan 25, 2002, 1:08:35 AM1/25/02
to
Dr. Edmund Weitz wrote:
>
> This posting is a proposal for a community effort to provide a "Common
> Lisp Cookbook" that will mimick the Perl Cookbook (or similar sources
> for Java, Python and other languages). It'll provide 'recipes' that'll
> help you in implementing mundane stuff and thus enabling you to get
> more comfortable with the language as well as giving you more time to
> think about the stuff that's really hard (and would probably be a pain
> to do in other languages).

I too think that this is a great project, and I'll be glad to
contribute if (as I hope) it gets off the ground. Just a few comments:

> - This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> AutoLisp, or whatever.

Agreed.

> - Due to the nature of this there will be some intersection with the
> c.l.l FAQ (recently revived by Christophe Rhodes at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>), but I think
> these projects are different enough to warrant two distinct
> documents.

It's good to see that the FAQ is being revived, first of all. I agree
on the "two documents" strategy, but I also think that the two projects
should be coordinated. The FAQ could act as an "entry level" document,
pointing to the relevant sections of the Cookbook when necessary for
people who want more detail. The Cookbook would in turn point to the
CLHS, newsgroup messages, online resources, etc. for even more detailed
info. I also think the FAQ could benefit from a little restructuring:
for example, the first entry in section 4 (Programming Questions) is
about how to write a 'Hello World' program, and the second one deals
with FLET. Quite a big conceptual gap, I'd say...

> 2. Infrastructure / How to do it
>
> 2.1. The first thing that comes to mind (and has been mentioned here
> already) is CLiki. The good thing about it is that it's already
> there and we can simply start hacking in questions and
> answers. But I think it might be better if we had some means to
> organize the whole project - providing for ways to easily
> re-structure the whole document and for automatic generation of
> different formats like HTML, TeX, PDF...
>
> 2.2. That's why I think a custom-tailored database-backed website
> would be the best solution. As with CLiki, everybody should be
> able to add content or change what's there already (maybe after
> registering once with his name and email address). I would
> volunteer to set up such a thing (although I'd currently write it
> in mod_perl/DBI - shame on me - rather than in CL/USQL) and
> provide a server to host it.
>

> 2.3. As an alternative one could start a Sourceforge project to host a
> couple of Texinfo files. Contributors would have to use CVS.

Being one of the many people who use Lisp for database-backed web
applications, I like solutions 1 and 2, but I'm concerned that the time
to design and set up such an environment might be too long, causing the
project to lose momentum. I'd rather see it start in a simple way
(solution 3, or HTML, or even plain text files) than not start at all.

Anyway, thanks for doing this, and let us know when and how we can start
contributing!

--
Alberto Riva
Children's Hospital
Informatics Program

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:18:07 AM1/25/02
to
"Pierre R. Mai" <pm...@acm.org> writes:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > - The target audience are people who are new to (Common) Lisp -
> > people who have just discovered the language and are willing to
> > learn it.
>
> I think it wouldn't hurt to let the focus expand as needed, to
> include not quite so new people, who are still willing to learn
> common idioms, etc. There are quite a number of known idioms for
> slightly advanced/specialized stuff, which would profit from being
> presented in a cookbook/recipe like style, like MOP-stuff, etc.

Sure. My idea of target audience was obviously too narrow. The Perl
Cookbook and similar documents also appeal to people not so new to the
language.

> It might be useful to start off with CLiki (possibly on a separate
> site), and expand the mark-up stuff, and reorganization
> facilities...

I'll take a closer look at CLiki and how it works this weekend.

Thanks for your comments about the legal side of quoting Usenet
postings. I think I'll try to contact the original posters in any
case.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:19:21 AM1/25/02
to
ma...@oscar.eng.cv.net (Marc Spitzer) writes:

> If you are looking for a caned app type of solution, take a look
> at openacs.org. It looks like what you want in the first draft of
> the site is already there:
> sql back end(postgres and oracle)
> message boards
> administrative interface, create/modify/delete message boards ...
> full text search
>
> I have installed it a few times to play with and have gotten it running
> on freebsd. I would be willing to help install/manage it.
>
> A couple of possible issues:
> it uses aolserver not apache
> tcl is the scripting language

Thanks for the hint. I've played around with ACS a while ago. It's
nice but maybe a bit over-done for the Cookbook. Also, the server that
I'm probably going to provide space on is used for other tasks,
including running test applications for clients of mine. It has Apache
with mod_perl and PostgreSQL already running and has to stay that way.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:20:54 AM1/25/02
to
Paolo Amoroso <amo...@mclink.it> writes:

> Quite simple. For each batch of newsgroup or mailing list postings
> from a same author that I plan to include in a version of the
> EncyCMUCLopedia, I contact the author asking for permission, and
> including all material for his reference and convenience. Then I
> include in the EncyCMUCLopedia distribution a copy of each posting
> with full headers as received by my mail/newsreader, adding a blurb
> such as "included with permission" in each index entry.

Thanks. I think this is the way to go. What do you do if you can't
reach the original author anymore?

> As for useful tools with which to maintain the Cookbook, I suggest
> Edmund to have a look at the SBCL Internals Documentation project,
> which has similar technical requirements and is based on CLiki
> technology:
>
> http://ww.telent.net/sbcl-internals/index

I'll take a closer look at it this weekend.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:27:05 AM1/25/02
to
"Marc Battyani" <Marc.B...@fractalconcept.com> writes:

> Why do you want a SQL database ?

I didn't say that I _needed_ it. It's just that it's already there and
I'm working with it every day. It would be a piece of cake to do a
little app in mod_perl/DBI because I'm used to it - that's all.

> For now you have 0 article so you don't
> need an SQL database.

Yeah. But for 0 articles I don't need mod_lisp either... :)

I hope we'll have a couple of articles soon.

> Even when you have lots of articles, you won't need an SQL database.
> As I wrote in the previous post, you can use sexprs to store the
> data. Or some CLOS objects in a hash table or in a list. There are
> lots of quick start solutions.
>
> To start you just need a server, apache, mod_lisp and an HTML
> generation macro and that's it. Start with an in memory database
> saved as an ascii file (remember Lisp has a nice reader). It's
> better to have a working solution in a few days and then to refine
> it when it is a huge success.
>
> Then you can put in it the first article : How to write a successful
> web application in Lisp in 3 days...

Sounds interesting and I haven't thought about this yet. I usually
tend to use SQL databases because they free me from thinking about
things like concurrent access and stuff. Not that I think we'll soon
have dozens of authors committing articles at the same time... :)

Cheers,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:33:20 AM1/25/02
to
"novice106" <novi...@yahoo.com.au> writes:

> I think one of the first hurdles is understanding the package system
> and installing new 'modules' (for want of correct
> terminology). People quite often complain that the free Lisp
> implementations lack GUI toolkit support, database access and so
> on. It's obviously not true. The packages are out there, but the
> installation instructions, if present, often assume prior knowledge
> of how Lisp packages work, how they're loaded, how they're used,
> etc.
>
> I confess with some embarrassment that I don't know anything about
> this, and have not found any idiot-proof instructions. Whilst I
> could probably install any package through trial and error, I do
> think that Common Lisp's way of handling packages and
> installing/loading of extensions is sufficiently different from
> other languages to merit some basic explanation. Even simple
> concepts like "saving an image", which experienced Lisp users
> naturally take for granted, are alien to most people who come to
> Lisp from other languages. In my opinion, this would be a good
> place to start.

Well said. I have the same problems and I would be glad if I could
find a tutorial that not only explains _what_ to do but also _why_ it
is done and what's happening in the background.

Maybe someone with enough knowledge will add this to the Cookbook once
it's started.

Thanks,
Edi.

Dr. Edmund Weitz

unread,
Jan 25, 2002, 8:38:53 AM1/25/02
to
Christophe Rhodes <cs...@cam.ac.uk> writes:

> "novice106" <novi...@yahoo.com.au> writes:
>
> > If we had a page with detailed step-by-step instructions on how to
> > set up, say, Clisp or CMUCL with a commonly requested
> > configuration, eg. complete with bindings to GTK+ and MaiSQL, it
> > would give the user the background s/he needs to install other
> > packages when the time comes.
>
> Well, we sort of do, but currently it starts with "1. Install
> Debian..." because that is the only "Operating Environment" that
> common-lisp-controller, or any equivalent to my knowledge, runs
> on. Counterexamples are welcome :)

I think that providing this stuff for Debian is not enough. And by
that I don't mean someone should also build RPMs for Red Hat,
Mandrake, oder SuSE. I think it would be better if the tools needed
for the installation of Lisp extensions and the usual way of using
them would be explained somewhere rather than telling people they'll
just have to type 'apt-get install'.

With most of the GNU stuff it's just './configure && make && make
install' and it usually works. But if it doesn't work, there's enough
tutorial material out there to help you in understanding why it broke
and how to fix it. I think we should work on providing the same level
of documentation for CL.

Thanks,
Edi.

Thom Goodsell

unread,
Jan 25, 2002, 9:25:03 AM1/25/02
to
olc...@interaccess.com (Thaddeus L Olczyk) writes:
>
> While I think it should be vast enough so that people can open to a
> page and find a solution close to a problem they have, I don't think
> the focus should just be a "recipe" thing.
>
> Rather the focus should be on getting people "thinking in lisp" well
> enough so that they can answer similar questions on their own.

Agreed, sort of. I think that providing recipes is fine (or rather,
good), so long as the "Discussion" section points out the Lisp-think
involved. After all, this is supposed to be a collection of easy
solutions to common problems. It should be used in conjunction with,
e.g., Graham's ANSI Common Lisp or PAIP, which will provide plenty of
Lisp-think information.



> >
> >- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
> > AutoLisp, or whatever.
> >
> I believe the lions share of jobs ( and I do believe getting a "lisp
> job" is the goal of many of the newer people ) are in the "embedded
> language" business where Lisp is used as an embedded scripting
> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> on ACL is the best thing.

Can't agree with this one. If we try to cover every Lisp dialect and
Lisp-like dialect this will end up being an unintelligible
nightmare. As it is, much of the stuff in this cookbook will rely on
something like CLOCC to cover implementation-dependent stuff. Trying
to then include intirely new dialect is just way too much, IMHO.



> Instead I think you should say that ACL solutions are prefered over
> Scheme solutions or Emacs Lisp solutions. But in the end the best
> solutions are ones that can be used by as many possible
> implementations as is possible. ( You might hafve to tweak them
> though. )

The point is that one target audience of this book is people who
wouldn't have the foggiest idea of what to tweak.



> >- The project does not aim to supplant introductory books or the
> > HyperSpec. People who use the Cookbook are expected to know the
> > language basics and to consult the CLHS if necessary.
> >
> Here I would disagree. The CLHS is a standard. Standards are mean for
> language implementors, not for users. Therefore they are often
> unreadable.

While I certainly don't think that the CLHS should be the only
reference, I definitely think that it should be referenced. Unlike a
lot of other languages, we have a standard that *is* readable by
users, whatever its intended audience. I think we should show off that
fact. Besides, the CLHS is as close as you can get to a final
authority without buying the actual spec from ANSI.

Thom

--
(map 'string #'(lambda (char) (let ((char-code (char-code char)))
(code-char (if (< 64 char-code 123) (+ (mod (+ 13 char-code) 52) 65)
char-code)))) "Z...@IXG.IUS")

Tim Bradshaw

unread,
Jan 25, 2002, 10:00:42 AM1/25/02
to
> Why do you want a SQL database ? For now you have 0 article so you don't
> need an SQL database. Even when you have lots of articles, you won't need an
> SQL database.

Well said. The only thing you get is transactions and that's hardly
an issue here.

--tim

Bijan Parsia

unread,
Jan 25, 2002, 10:29:23 AM1/25/02
to
On Fri, 25 Jan 2002, novice106 wrote:

[snip]


> I think one of the first hurdles is understanding the package system and
> installing new 'modules' (for want of correct terminology).

Goodness yes! I started my first Common Lisp program using LispWorks. I
wanted to play around with the recent update to CL-XML. Sometimes I get
things to work, and sometimes I done ;) I've made a little bit of progress
on understanding packages (with a little help from the HyperSpec, a little
help from the manuals, and a little help form Norvig, and a whole lot of
pounding my face on the keyboard :)).

The CAPI user manual is a great example of how to hurt a guy like me :) I
went there to try to do a little GUI work. Let me first say that CAPI is
*great*. It's very easy to use overall, and has some nice widgets. I'm
thus far really happy with it.

It would be *perfect* for playing around with Lisp *if* the examples in
the manual didn't bite you hard. For example:

http://www.xanalys.com/software_tools/reference/lwl41/capiuser/CUG_15.HTM
------------
All symbols in this manual are exported from either theCAPI
orCOMMON-LISPpackages unless explicitly stated otherwise. You should use
theCAPI package in your code to access them:

(defpackage "MY-PACKAGE"
(:add-use-defaults t)
(:use "CAPI")
)


This creates and loads a package containing all theCAPI commands required
to try out the examples in this guide
------------

Then on
http://www.xanalys.com/software_tools/reference/lwl41/capiuser/CUG_16.HTM#HEADING16-0

This section shows how easy it is to create a simple window, and how to
include CAPI elements, such as panes, in your window.

1. Type the following in a listener
(make-instance 'interface
:title "My Interface")

(display *)
-----------

Well, there are a bunch of situtions where that code one run. Adding the
CAPI: prefix to the right bits helps. As does an in-package. But, it took
me a while to figure these things out :)

Now, I'm sure even a slightly more experienced person would have had no
trouble (maybe not!). But would those more experienced people have needed
the defpackage snippet in the first place? Why that and not the bit more?

This would be a *terrific* introduction to common lisp. The GUI examples
are *very* satifactory to play with, and they are high reward.

[snip]

> I confess with some embarrassment that I don't know anything about this, and
> have not found any idiot-proof instructions.

Yep. If there is one out there, someone let me know!

> Whilst I could probably install
> any package through trial and error, I do think that Common Lisp's way of
> handling packages and installing/loading of extensions is sufficiently
> different from other languages to merit some basic explanation.

Yep.

> Even simple
> concepts like "saving an image", which experienced Lisp users naturally take
> for granted, are alien to most people who come to Lisp from other languages.
> In my opinion, this would be a good place to start.

That's *not* alien to me (being a Smalltalker) and various things were
non-obvious to me :)

The installation instructions on http://www.cl-xml.org are an example of
something that actually didn't help me a lot (and they're a bit hard to
find). If I get enough control over it, I will certainly submit some.

(No strike on James Anderson! CL-XML looks great, it's just not set up for
XMLers who know little to know CL :))

> I think your project is an excellent idea.
> I will certainly be willing to contribute when I can.

Indeed. If Xanalys is willing, it would be fun to adapt their CAPI guide
to focus more on "learning CL through GUI code" (rather than documenting
CAPI per se).

Cheers,
Bijan Parsia.

Holger Schauer

unread,
Jan 25, 2002, 9:52:06 AM1/25/02
to
On Thu, 24 Jan 2002, Thaddeus L. Olczyk wrote:
> On 24 Jan 2002 10:52:13 +0100, e...@agharta.de (Dr. Edmund Weitz)
> wrote:

A very nice proposal.

> While I think it should be vast enough so that people can open to a
> page and find a solution close to a problem they have, I don't think
> the focus should just be a "recipe" thing.
> Rather the focus should be on getting people "thinking in lisp" well
> enough so that they can answer similar questions on their own.

I guess that it will be hard to keep any focus, given the multiple
author approach, or even worse the idea of using Usenet postings. The
major problem with the latter is arguably the lack of context (when
copying _one_ posting).

>>- This'll be about ANSI Common Lisp, not about Scheme, Emacs Lisp,
>> AutoLisp, or whatever.
>>
> I believe the lions share of jobs ( and I do believe getting a "lisp
> job" is the goal of many of the newer people ) are in the "embedded
> language" business where Lisp is used as an embedded scripting
> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> on ACL is the best thing.
> Instead I think you should say that ACL solutions are prefered over
> Scheme solutions or Emacs Lisp solutions. But in the end the best
> solutions are ones that can be used by as many possible
> implementations as is possible. ( You might hafve to tweak them
> though. )

You must be joking or very ignorant of the differences between Common
Lisp, Scheme and Emacs Lisp. Many one-line solutions for Common Lisp
would need a lot of code in either Scheme or ELisp.

>>- The project does not aim to supplant introductory books or the
>> HyperSpec. People who use the Cookbook are expected to know the
>> language basics and to consult the CLHS if necessary.

ACK

> Here I would disagree. The CLHS is a standard. Standards are mean
> for language implementors, not for users. Therefore they are often
> unreadable.

I -- as a user -- find the CLHS to be extremely useful. In fact, it is
by far my major resource when solving problems. And yes, I mostly find
it very readable and its examples very helpful.

> An answer to the question: "How do I write a while
> loop?" might be to look up the "loop" command in the CLHS. At that
> point I expect the reader to give up on Lisp and take up VB.

I am really not sure whether I would include such a question in a
/Cookbook/. But anyway: yes, I would definitely include a reference to
the CLHS. But that doesn't prevent one from giving a small example as
well.

Holger

--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Ja, wir sind die, die vor lauter Baeumen auch noch einen Wald sehen
koennen. Da stehen wir mitten drin und rufen gaaaanz laut zurueck. Das
hat man davon, wenn man laut in den Wald ruft."
-- Friedbert Widmann in de.comp.text.tex

Marco Antoniotti

unread,
Jan 25, 2002, 10:52:00 AM1/25/02
to

e...@agharta.de (Dr. Edmund Weitz) writes:

..

> With most of the GNU stuff it's just './configure && make && make
> install' and it usually works.

With CL.CONFIGURATION is

(load "package.conf")
(conf:setup "PACKAGE")
(mk:compile-system "PACKAGE")
(mk:load-system "PACKAGE")

All in your favourite CL. No operating system dependencies (if there
are, they are bugs).

If you want to change some parameter you do

(conf:setup "PACKAGE" :source-location "/where/the/hell/is/the/code/")

(CL.CONFIGURATION has, untested, provisions to accomodate other
DEFSYSTEM utilities).

> But if it doesn't work, there's enough
> tutorial material out there to help you in understanding why it broke
> and how to fix it. I think we should work on providing the same level
> of documentation for CL.

On this I agree.

Ciao

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Thaddeus L Olczyk

unread,
Jan 25, 2002, 11:15:16 AM1/25/02
to
On 25 Jan 2002 09:25:03 -0500, Thom Goodsell
<tgoo...@DESPAM.cra.com> wrote:

>> I believe the lions share of jobs ( and I do believe getting a "lisp
>> job" is the goal of many of the newer people ) are in the "embedded
>> language" business where Lisp is used as an embedded scripting
>> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
>> on ACL is the best thing.
>
>Can't agree with this one. If we try to cover every Lisp dialect and
>Lisp-like dialect this will end up being an unintelligible
>nightmare. As it is, much of the stuff in this cookbook will rely on
>something like CLOCC to cover implementation-dependent stuff. Trying
>to then include intirely new dialect is just way too much, IMHO.
>

I'm not saying that the solutions should be applicable to all
implementations.
What I am saying is that given one solution that works under many
different dialects ( I'll admit Scheme is a stretch. ) and another
that only works in ACL that the solution that works under many be
preffered.

Imagine for example that you have two solutions to a problem.
One relies on the "scoping scheme" of the dialect, and the other
does not. Choose the second. In fact try as much as possible to
write solutions of the second type.

Now there may be a solution that relies on scoping that is far
superior. That solution should be chosen.


>> Instead I think you should say that ACL solutions are prefered over
>> Scheme solutions or Emacs Lisp solutions. But in the end the best
>> solutions are ones that can be used by as many possible
>> implementations as is possible. ( You might hafve to tweak them
>> though. )
>
>The point is that one target audience of this book is people who
>wouldn't have the foggiest idea of what to tweak.
>

No the point is to teach the people "what to tweak".

Marco Antoniotti

unread,
Jan 25, 2002, 11:42:45 AM1/25/02
to

olc...@interaccess.com (Thaddeus L Olczyk) writes:

> On 25 Jan 2002 09:25:03 -0500, Thom Goodsell
> <tgoo...@DESPAM.cra.com> wrote:
>
> >> I believe the lions share of jobs ( and I do believe getting a "lisp
> >> job" is the goal of many of the newer people ) are in the "embedded
> >> language" business where Lisp is used as an embedded scripting
> >> language ( ala Emacs Lisp, or AutoLisp ). So I don't think focusing
> >> on ACL is the best thing.
> >
> >Can't agree with this one. If we try to cover every Lisp dialect and
> >Lisp-like dialect this will end up being an unintelligible
> >nightmare. As it is, much of the stuff in this cookbook will rely on
> >something like CLOCC to cover implementation-dependent stuff. Trying
> >to then include intirely new dialect is just way too much, IMHO.
> >
> I'm not saying that the solutions should be applicable to all
> implementations.
> What I am saying is that given one solution that works under many
> different dialects ( I'll admit Scheme is a stretch. ) and another
> that only works in ACL that the solution that works under many be
> preffered.

Most little problems cannot be solved in Scheme, given the main design
goal of the language. Including the variants for the godzillion Scheme
implementations is not pragmatical.

As for ELisp, stick

(require 'cl)

in your .emacs (despite RMS' opinion) and you have solved the problem
of providing most of the portability.

Ciao

PS. Using the term ACL to refer to ANSI Common Lisp is confusing, as
ACL is usually used to refer to Allegro Common Lisp, the main
Franz Inc. product. Just saying CL implies the ANSI standard.

Erann Gat

unread,
Jan 25, 2002, 11:01:02 AM1/25/02
to

I used to believe this too until my recent foray into the real world. Not
only are transactions not the only thing that an SQL database buys you,
they aren't even the main thing. In fact, not all SQL databses even
support transactions.

The main thing an SQL database buys you (or any database for that matter)
is flexible, non-volatile indexing, making it easy e.g. to efficiently
find all the articles written by a particular person at a particular time
on a particular topic, even when the number of articles is very, very
large.

Erann

Marc Battyani

unread,
Jan 25, 2002, 12:40:20 PM1/25/02
to

"Erann Gat" <g...@jpl.nasa.gov> wrote

Sure but we were saying that the number of articles was very, very small ;-)

Marc


Tim Bradshaw

unread,
Jan 25, 2002, 1:11:04 PM1/25/02
to
* Erann Gat wrote:

> I used to believe this too until my recent foray into the real world. Not
> only are transactions not the only thing that an SQL database buys you,
> they aren't even the main thing. In fact, not all SQL databses even
> support transactions.

I think they are the main thing. My guess is that a lot more people
care a lot more about knowing that the system that handles all their
financial transactions works correctly than care about indexing. And
those people run investment banks and so on, so they have a lot of
money to spend on database systems.

Of course, indexing is an important thing but it definitely is not the
thing that pushes commercial database development. You have only to
look at the kind of benchmarks they compete on...

In fact, I'd always assumed that people who have really serious
indexing requirements use custom or semi-custom indexing systems.
Maybe not.

--tim

Erann Gat

unread,
Jan 25, 2002, 2:12:18 PM1/25/02
to
Tim Bradshaw <t...@cley.com> wrote:

> The only thing you get is transactions and that's hardly
> an issue here.

...


> I think they are the main thing. My guess is that a lot more people
> care a lot more about knowing that the system that handles all their
> financial transactions works correctly than care about indexing.

Maybe so, but we're not talking about a financial system here, we're
talking about a bulletin board. In that context transactions are neither
the main thing nor the only thing.

"Marc Battyani" <Marc.B...@fractalconcept.com> wrote:

> Sure but we were saying that the number of articles was very, very small ;-)

At the moment. Presumably the number of articles won't be small forever.

E.

Paolo Amoroso

unread,
Jan 25, 2002, 2:50:33 PM1/25/02
to
On 25 Jan 2002 14:20:54 +0100, e...@agharta.de (Dr. Edmund Weitz) wrote:

> Thanks. I think this is the way to go. What do you do if you can't
> reach the original author anymore?

I don't know, this has not happaned yet. If it does, I will probably not
include the material.

Dorai Sitaram

unread,
Jan 25, 2002, 3:11:41 PM1/25/02
to
In article <y6cu1ta...@octagon.mrl.nyu.edu>,

Cookbooks are appropriate for something that you have
to do everyday but are still in need of modest
variation (either to be useful or so you don't get
bored). Making everyday meals, everyday scripts...,
you get the picture. The Perl Cookbook is therefore
very apt. CL isn't used like that, so I don't see what
problem a Common Lisp cookbook can possibly solve.
Something to think about before committing
resources.

--d

Nils Goesche

unread,
Jan 25, 2002, 3:22:04 PM1/25/02
to
In article <a2se5t$l1c$1...@news.gte.com>, Dorai Sitaram wrote:

> Cookbooks are appropriate for something that you have to do everyday
> but are still in need of modest variation (either to be useful or so
> you don't get bored). Making everyday meals, everyday scripts..., you
> get the picture. The Perl Cookbook is therefore very apt. CL isn't
> used like that, so I don't see what problem a Common Lisp cookbook can
> possibly solve. Something to think about before committing resources.

The point was that it would be useful for beginners and for people
who haven't used CL for practical things yet. All existing books
address mainly advanced and/or theoretical issues. The great
``On Lisp'' teaches what you can do in CL what you can't do in other
languages; but there is no book I know of that teaches how you can do
in CL what you can do in other languages...

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

Bijan Parsia

unread,
Jan 25, 2002, 6:01:53 PM1/25/02
to
On Thu, 24 Jan 2002, Thaddeus L Olczyk wrote:

[snip]


> While I hate to promote Smalltalk.

What? Instead of promoting *Perl*? ;)

Cheers,
Bijan Parsia.

Michael Naunton

unread,
Jan 25, 2002, 10:37:07 PM1/25/02
to
On 24 Jan 2002 10:52:13 +0100, Dr. Edmund Weitz <e...@agharta.de> wrote:

>- Basics: Installation, Loading and Compiling

>- Numbers: BIGNUMS, rationals, complex numbers

>- Strings / Regular Expressions
>- Dates and Times

>- Arrays
>- Hash Tables
>- Lists/Conses
>- Structures
>- CLOS

>- Other data structures: Btrees, Queues, Linked Lists

>- Iteration: LOOP, SERIES, MAP functions

>- Searching and Sorting


>- Input and Output, Streams, FORMAT, the Lisp Reader
>- Conditions, Error Handling

>- File Access, File Contents, Directories

>- Packages
>- Defsystem
>- Debugging, Profiling, Advice
>- Database Access
>- Sockets
>- Internet Protocols, Web Serving
>- Multi-Processing, Multi-Threading
>- FFI, Extending and Embedding CL
>- Communicating with other processes
>- GUI

>- I18N
>- XML
>- MOP

I think Sun got it right with their concept of "Trails" for Java. It's
hard to teach LISP in a linear fashion: if a user wants to know how to
read in a file, she's at chapter 15, and it makes no sense at all: e.g.
what's this "(foobar &list :opt fun-arg :rest a-list)" advice?

Trail 1 should be "Getting Started." That is installation and running
LISP. Final example is printing "hello world" and maybe (+ 2 2).
Compiling/profiling should be its own trail.

Don't try to explain Numbers: most people are happy that (/ 10 2) is 5.
Offer an advanced trail on using huge numbers and rationals.

The initial trails must solve common problems: how to read files,
ask the user for input, etc. Most users will give up if they can't
do the basics they need for their little test application.

I hate to say this, but the first data structures to be explained should
be the array and hash-table! Give the novices something they understand
and can build on. Introducing map and apply and lists on page 1 just
confuses the new user (consider a COBOL programmer learning PROLOG: yes,
it computes, but how can he use it?)

The trick is to introduce the powerful features of LISP (anonymous functions,
mapping, closures, macros, etc) in such a way that the expressiveness
offsets the perceived syntactic clunkiness. People don't want generality
when they are just trying to read a dictionary file... they just want the
file to get read!

Example: I wrote my first real LISP program in ten years last week: it
did the add-a-gram thingie: 60 lines total (C++ would have been 300+,)
and I spent almost all of my time trying to find trivial things: how to
read a file, convert a list to a sequence of chars, copy an array, etc.
The actual implementation of algorithm was trivial (maybe 10% of the total
time.)

Regards,
MMN

Thaddeus L Olczyk

unread,
Jan 25, 2002, 11:39:54 PM1/25/02
to

I do not promote the abomination called a language that was
written by Larry "Should Be Lined Up Against A" Wall.

synthespian

unread,
Jan 26, 2002, 12:50:56 AM1/26/02
to
In article <m3it9so...@bird.agharta.de>, e...@agharta.de (Dr. Edmund Weitz) wrote:
> I think most of you will agree that once you're hooked on Common Lisp
> you realize that you've found a language which has things to offer
> that no competitor has, so I won't discuss this any
> further. Nevertheless, CL is also a language that is somewhat hard for
> newcomers, especially for those who've used other, more widespread
> languages before: I come from the Perl/C/Java camp (and this is how I
> pay my rent) and there are myriads of _simple_ tasks that I could
> implement in these languages without thinking while I would have to
> work hard to get them done in CL. This is what this posting is about:
>
> I now that many c.l.l regulars despise Perl, but I hope you'll agree
> that the Perl community has a couple of things that we can learn
> from. The one thing that I'm going to talk about here is the famous
> (?) Perl Cookbook (see <http://www.oreilly.com/catalog/cookbook/>), a
> nice little book that provides concise, elegant and instructive
>

Hi -

I think yours is, in broad terms, a Good Idea. I mean, I'm a Lisp newbie, and
already I'm scared with this talk about how difficult it is to do trivial things...
Although I'm not able to contribute anything right now (except my opinion), I
feel I that I joint effort to index those issues in a web page would be far better
than having to buy yet another cookbook. Web sites are more dynamic, and don't cost
$50,00-plus dollars for you to update the information.
So, my vote goes for a web page (Cliki, maybe?).
I guess the bottom-line is that lispers have to make a coordinated effort to ease things
for the LIsp newbies.
These are all important questions which are bound to pop-up again and again unless
wide - preferably free - documentation is made avaliable.

Regs,

HL

Dr. Edmund Weitz

unread,
Jan 26, 2002, 2:21:00 AM1/26/02
to
synthespian <synth...@uol.com.br> writes:

> Although I'm not able to contribute anything right now (except
> my opinion), I feel I that I joint effort to index those issues in a
> web page would be far better than having to buy yet another
> cookbook. Web sites are more dynamic, and don't cost $50,00-plus
> dollars for you to update the information.

Yep. Maybe the term 'cookbook' is kinda misleading. I was talking
about making it available ob the Web all the time.

Edi.

Dr. Edmund Weitz

unread,
Jan 26, 2002, 2:23:12 AM1/26/02
to
olc...@interaccess.com (Thaddeus L Olczyk) writes:

> I do not promote the abomination called a language that was written
> by Larry "Should Be Lined Up Against A" Wall.

Wishing someone death just because he inventend a language that you
don't like? Hmmm - you're feeling better now?

Software Scavenger

unread,
Jan 26, 2002, 5:26:16 AM1/26/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<a2se5t$l1c$1...@news.gte.com>...

> Cookbooks are appropriate for something that you have
> to do everyday but are still in need of modest

I disagree. Cookbook recipes are more useful for things you do less
often, not things you do every day. If you do something every day,
you don't need a book to remind you how to do it. Cookbook recipes
are most useful the very first time you try something. For a
programming language, a cookbook is most useful the very first time
you try something in that language which you have done in other
languages.

Software Scavenger

unread,
Jan 26, 2002, 5:34:39 AM1/26/02
to
Yes, what a cookbook for novice users of Common Lisp should tell is
how to do something in Common Lisp which the user has done in other
languages. It should cover everything commonly done in other
languages, so no users will get stuck on such things, and they can
instead spend their time learning how to take full advantage of the
power of Common Lisp to do things that aren't done in other languages.

What the cookbook needs is a vast collection of example programs,
covering all the most common things done in other languages, and a
vast and powerful index, such that a programmer who knows how to do
something in a particular language can use that index to quickly find
out how to do the same thing in Common Lisp.

We don't have to explain each example program, as long as we clarify
what it does and what it's for. Having the example to play with is
enough for even the greenest novice to learn from.

A typical example program would compute the number of days between two
dates or the total number of bytes in all the files of a directory
tree. The index entries would have to be verbose to cover everything
anyone would use as search keys. For dates, the keywords would
include date, time, days, months, years, elapsed, duration, etc. The
index is as important as the content.

For this cookbook to be the best it can be, it has to be many
megabytes of useful information. The effort should be organized in
such a way that people can easily contribute large numbers of
miscellaneous example programs to it without making a mess of it and
without having to understand any complicated details of how to index
each entry. Maybe the entries should include a few extra lines of
comments containing index keywords, and other contributors could add
more index keywords to those. Maybe the actual indexing should just
use all the words found anywhere in the example. It might also be a
good idea for each entry to be reviewable by other contributors, who
can then add their comments to it, perhaps adding a better version of
the same program, etc.

Siegfried Gonzi

unread,
Jan 26, 2002, 6:27:06 AM1/26/02
to
synthespian wrote:

> Hi -
>
> I think yours is, in broad terms, a Good Idea. I mean, I'm a Lisp newbie, and
> already I'm scared with this talk about how difficult it is to do trivial things...

I favor of Lisp: the other languaes are not necessarilly better in this respect. I once red "Teach
C++ in 21days" (I had a time --concerning my career-- where I didn't know that industry is only
searching for slaves). Albeit grasping C++ in 21days is a joke, the book also didn't go much into
deatail concerning lets say reading files or therelike.

Last year I wrote a program for a colleague (it was a 1000 LOC C and C++ mixture). Only by hazard
have I found something on the net how to read-in values in C++ from a file. The version works now,
but I do not know why and how.


S. Gonzi

Dr. Edmund Weitz

unread,
Jan 26, 2002, 9:45:28 AM1/26/02
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > With most of the GNU stuff it's just './configure && make && make
> > install' and it usually works.
>
> With CL.CONFIGURATION is
>
> (load "package.conf")
> (conf:setup "PACKAGE")
> (mk:compile-system "PACKAGE")
> (mk:load-system "PACKAGE")
>
> All in your favourite CL. No operating system dependencies (if
> there are, they are bugs).

Thanks for the hint. I hadn't heard about CL.CONFIGURATION before, so
I wanted to give it a try. What happened makes a good story (or case
study if you prefer), so I'll write it down here.


Disclaimers:

1. This is _not_ meant to critize anyone involved in providing Free,
Open Source (Lisp) software. I'm thankful for what you're doing and
I'm definitely not in a position to ask for anything. I myself have
only contributed some small code snippets to Open Source projects
and I never really had to deal with making sure that large systems
will install on every possible combination of OS, installed
libraries and language implementation. See my conclusions below.

2. This is _not_ meant to solicit help for the particular task of
installing CL.CONFIGURATION. I actually _want_ to figure it out
myself so I can learn something from it.

3. Maybe it's just me and I'm just plain stupid. If that's the case, I
hope you'll have a good laugh while reading this.

4. This is a looooooong one, so bear with me.


OK, here we go:

A. Google told my that CL.CONFIGURATION was part of the CLOCC project,
so I said, "Hey, you have CLOCC already. You even managed to get it
(partly) installed, so this should be easy." I found
CL.CONFIGURATION but had to realize that there were no compiled
files in that directory so I had to build first. I re-read the
CLOCC installation instructions and found this paragraph:

You should be able to compile any package in CLOCC now by typing
"make system" in the appropriate directory.
E.g., if you want to compile "PORT" (the cross-implementation
portability system), you do
$ cd src/port
$ make system

OK, fine, CL.CONFIGURATION is in the port directory, so I did 'cd
src/port' and 'make system'. CMUCL started to work, everyting went
smoothly, and after it had finished I found a couple of new '.x86f'
files in there. Unfortunately, the CL.CONFIGURATION stuff wasn't
amongst them...

B. OK, no prob. I did 'cd configuration' and 'make system':

edi@bird:/usr/local/clocc/src/port/configuration> make system
make: *** No rule to make target `system'. Stop.

C. Ah, I see. Looks like I have to read the INSTALLATION file. [...]
I'm lucky - I have CMUCL, so I can use DEFSYSTEM and follow the
easy installation path. [Remark: The CMUCL binaries that I
downloaded some months ago didn't come with DEFSYSTEM, but I
managed to find it when I first needed it. Unfortunately, I had to
find out that there seem to be mutual incompatible DEFSYSTEMs out
there - but that's another story.]

D. I followed the instructions and did the following:

* (load "defconf.system")
T
* (mk:compile-system 'cl.ext.configuration)
Error in function "Top-Level Form":
CL.EXT.CONFIGURATION requires the CL.ENVIRONMENT package.

Damn! Where's that one? Ah, yes, it's in the neighbor
directory. Let's go there...

E. Some seconds later I succeeded in building CL.ENVIRONMENT which
actually worked as advertised in the INSTALLATION file. Now I
wondered how I would make sure that the package is there the next
time I start CMUCL. As I had had to fiddle with DEFSYSTEM before I
though that something like this should work...

* (load "env.system")
* (mk:oos 'cl.environment :load)

...and it did. However, it of course only worked in the same
directory. When I went back into the CL.CONFIGURATION directory, I
got:

* (load "env.system")
File-error in function COMMON-LISP::INTERNAL-LOAD: "env.system" does not exist.

F. Yeah, sure - sorry. Of course it's...

* (load "../environment/env.system")
T
* (mk:oos 'cl.environment :load)
Error in format: Unknown format directive.
Source file ~A ~
~:[and binary file ~A ~;~]not found, not loading.
^

G. Oops - my bad: I didn't read the manual carefully and forgot to
configure the 'env.system' file. No problem, I added the correct
lines to this file and re-built CL.ENVIRONMENT. Now I tried to
build CL.CONFIGURATION again and ended up with:

Compiling DEFMETHOD PARSE-CONF-CLAUSE ((EQL :REQUIRED-MODULE) T):
Error in KERNEL:%COERCE-TO-FUNCTION: the function REQUIRED-MODULE-CLAUSE-NAME is undefined.
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL:%COERCE-TO-FUNCTION REQUIRED-MODULE-CLAUSE-NAME)
Source:
; File: target:code/fdefinition.lisp
(ERROR 'UNDEFINED-FUNCTION :NAME NAME)

0] (quit)
Error in KERNEL:%COERCE-TO-FUNCTION: the function QUIT is undefined.
Error flushed ...

Hmmmm.....

H. Now let's suppose I will be able to build CL.CONFIGURATION. If I
understand Marco Antoniotti's posting correctly it'll need some
kind of '.conf' file to build a system, but there are no '.conf'
files in CLOCC or in the packages from onShore that I downloaded
the other day. Would CL.CONFIGURATION help me in these cases?

I. And what's the relation between CL.CONFIGURATION,
COMMON-LISP-CONTROLLER and DEFSYSTEM? Do they depend on each other?
Are they intended to replace each other? Or are they orthogonal?

J. Now, the usual answer might be: 'Install Debian and you're done.'
Unfortunately, this is currently not an option for me. I have two
machines - one of them is a server running FreeBSD which didn't let
me down for three years in a row. I wouldn't install another OS
there even if you gave me money for it. (Well, on second thought,
it depends on the amount...) The other machine is one of those
fancy new IBM Thinkpad laptops and I was too dumb to install Debian
on it while SuSE 7.3 was up and running (supporting all of the
hardware) in less than an hour (even faster than Win2k). I need
this puppy for my daily work and I don't want to learn more about
its internals, so Debian is out for the moment.

OK, so far for the rant. What is my conclusion? As I said before, I
don't want to accuse anyone. I just wanted to make clear that we're in
need of more and better documentation for the CL community. It is
unlikely that O'Reilly will provide us with a pile of books, and the
core developers have enough work already, so we (the Newbies) have to
do it (with a little help from the experts if time permits). That's
why I want to start the Cookbook project.

Thanks for listening,
Edi.

Bijan Parsia

unread,
Jan 26, 2002, 9:59:31 AM1/26/02
to
On 25 Jan 2002, Tim Bradshaw wrote:
[snip]

> Of course, indexing is an important thing but it definitely is not the
> thing that pushes commercial database development. You have only to
> look at the kind of benchmarks they compete on...
>
> In fact, I'd always assumed that people who have really serious
> indexing requirements use custom or semi-custom indexing systems.
> Maybe not.

I'd have thought that a fulltext inverted index sort of thing would be
preferable (a la Lucene, or Ht/Dig). May this is what folks *really* want,
but don't get, perhaps because they don't know they want it :).

Actually, I think "organization" or "structuring" is what database driven
web building is most common motivated by. Instead of putting your author
bios in on directory, the article under each topic in their own
directors, and having to cross link by hand and symlink and *yeccch*, you
can express organization pages (by topic, by author, etc.) as queries,
with a more pleasing and rational and maintainable structure at the
semiphysical level.

Perhaps this is what Erann meant rather than arbitrary user searches.

Cheers,
Bijan Parsia.

Paolo Amoroso

unread,
Jan 26, 2002, 2:02:32 PM1/26/02
to
On 26 Jan 2002 15:45:28 +0100, e...@agharta.de (Dr. Edmund Weitz) wrote:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
[...]
> > With CL.CONFIGURATION is
[...]


> Thanks for the hint. I hadn't heard about CL.CONFIGURATION before, so
> I wanted to give it a try. What happened makes a good story (or case

[...]


> actually worked as advertised in the INSTALLATION file. Now I
> wondered how I would make sure that the package is there the next
> time I start CMUCL. As I had had to fiddle with DEFSYSTEM before I

[...]


> * (load "env.system")
> File-error in function COMMON-LISP::INTERNAL-LOAD: "env.system" does not exist.

See note [*] below.


> Compiling DEFMETHOD PARSE-CONF-CLAUSE ((EQL :REQUIRED-MODULE) T):
> Error in KERNEL:%COERCE-TO-FUNCTION: the function REQUIRED-MODULE-CLAUSE-NAME is undefined.
> Restarts:
> 0: [ABORT] Return to Top-Level.
> Debug (type H for help)
> (KERNEL:%COERCE-TO-FUNCTION REQUIRED-MODULE-CLAUSE-NAME)
> Source:
> ; File: target:code/fdefinition.lisp
> (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
>
> 0] (quit)
> Error in KERNEL:%COERCE-TO-FUNCTION: the function QUIT is undefined.
> Error flushed ...

CL.CONFIGURATION is still in an early stage of development, and the latest
officially released version is 0.1. Marco has been soliciting feedback on
it for a long time. If you report this problem to the CLOCC mailing list,
he will be able to fix it.


> H. Now let's suppose I will be able to build CL.CONFIGURATION. If I
> understand Marco Antoniotti's posting correctly it'll need some
> kind of '.conf' file to build a system, but there are no '.conf'

CL.CONFIGURATION is a tool for processing `.conf' configuration description
files. If you develop an application that uses CL.CONFIGURATION, you have
to supply that file. See note [+] below.

In the CL.CONFIGURATION source tree you should be able to find a paper with
some more information and a sample `.conf' file. Note that the paper is
written in LaTeX2e, and in order to process it you have to get a style
package included with a LaTeX to HTML translator (Marco: which one? What
about a note with a link to that tool?).


> I. And what's the relation between CL.CONFIGURATION,
> COMMON-LISP-CONTROLLER and DEFSYSTEM? Do they depend on each other?
> Are they intended to replace each other? Or are they orthogonal?

If you are familiar with C development tools under Unix, you may think of
DEFSYSTEM as `make', and of CL.CONFIGURATION as `autoconf'. So, the `.conf'
file mentioned above[+] is something analogous to the scripts that you
supply to `autoconf'.

As for the Common Lisp Controller, it's a way of making sure that a package
"is there" the next time you start your Lisp, without having to keep track
of where libraries are in the file system. Its goal is to make it possible
to just type a form like:

(require :cool-library)

each time you need a particular library in your running Lisp image.


> don't want to accuse anyone. I just wanted to make clear that we're in
> need of more and better documentation for the CL community. It is

Agreed.

I hope the information I provided is accurate enough. If not, users more
familiar with CL.CONFIGURATION and Common Lisp Controller are welcome to
correct me.

synthespian

unread,
Jan 26, 2002, 3:10:53 PM1/26/02
to
Software Scavenger wrote:

> Yes, what a cookbook for novice users of Common Lisp should tell is
> how to do something in Common Lisp which the user has done in other
> languages. It should cover everything commonly done in other
> languages, so no users will get stuck on such things, and they can
> instead spend their time learning how to take full advantage of the
> power of Common Lisp to do things that aren't done in other languages.
>
> What the cookbook needs is a vast collection of example programs,
> covering all the most common things done in other languages,

I totally agree. While I'm learning Lisp from books and
tutorials, I'm in that phase where nothing "practical" is getting
done (except for some Math - better documented, BTW by a great French
Scheme PostScript).
While Dr. Edmund Weitz's list is probably borne out of his experience
and frustration, it is maybe to "general." "God is in the details", a
saying goes.
So what I'm saying is that I would like to see a list of the common
_problems_ newbies face, in doing, as it reads above, "everything
commonly done in other languages." If we get such a list up somewhere on
the web, than for sure the community will help to elaborate the solution
to those worldly problems very quickly.
Wouldn't it be better if we moved this "project" to Cliki?
Dr. Weitz, since you're the front man, what do you think? A Wiki Web is
a very good tool for collective knowledge-building, IMHO.

And for the heck of it, I just want to say I'm happy I found comp.lang.lisp!

Best regards,
S

P.C.

unread,
Jan 26, 2002, 3:37:26 PM1/26/02
to
Hi

"Michael Naunton" <m...@mmn.bellatlantic.net> skrev i en meddelelse

> I hate to say this, but the first data structures to be explained should
> be the array and hash-table! Give the novices something they understand
> and can build on. Introducing map and apply and lists on page 1 just
> confuses the new user (consider a COBOL programmer learning PROLOG: yes,
> it computes, but how can he use it?)

You are quite right ; it proberly be the same, hello world, in a little
different notasion, then how to make somthing realy new by starting in exactly
the same way, when understanding a more practic problem ,lead to se how things
work anyway. I allways thought some of the simple examples to be quite boring.
Now this is maby quite off topic, but I allways thought there must be better
way's. ------- why not boxes with the code printet on and accible so a user can
pile the right boxes together and get the thing working. Isn't high level
programing that way allready, and why "stop" with a new Lisp when the concept
could just aswell include Lisp as common batching ,worked well before ;))
Now I think Win. are allready a graphic workspace, with a number of standard
functions working amongst the applications, ---- Then why do I need to write
wierd lib. names in a program, if I could build with Windows standard functions
;)) -------- Are we talking about 95 or 98 pct of computer users or what.
Also it's true that it's the same problems that occour all the time "how do I" ,
seem to cover all the same issues. Anyway to get even more off topic, I
wouldn't mind somthing that is only partly an edditor ; I rather start my
computer, ----- any computer, ----- expecting that with this blank screen I just
need to point at the middle of the screen to be asked my password and then Im'e
quite sure, that even more graphics would be able to teach a completely
newcommer more, by a limitet set of choices, or a more flexible workspace, in
Lisp please, if that is possible, In 3D would be nice, and If I want to build
house ; vopti here are a way to create section cuts in CAD, make your own villa
; still then you Romans use to say no, that's when the money can come. When
money realy can be made, then it don't matter anyway. Lisp would be exelent as
a batch thing btw ; a dialect where you try boost the mem. with highly effective
means , what I mean is, that representing five primitives, to say it all ,that's
quite neat, then shaping the world make sense -------- don't show me an Autolisp
file I wrote 4 years ago ; a new program often will be easyer to make, with my
kind of programming, still I have 40 K things, loaded with recursies ,no
resetting var's in those, when job done you simply don't save the drawing ;))
What I would like, would instantly seing the results when turning blocks In say
Not or And mode, this allways been my point btw. you Romans shuld use the
technology better. Anyway I bet that having a 3D workspace, make a more 3D mind.
Still what if all this kind of making computers intiligent, suddenly one day
could be the result of to much Lisp working together. My son complains ,that at
tech. school they again need to learn Windows "introduction To" Windows , while
they all rather learn a highlevel. some drop to Assembler but no highlevel, as
that is not required doing electronics mechanic doings, after others been doing
their part. For me this make no sense, as a wider aproach shuldn't
hurt, -------- but _they_ will be Win specialists, people who could put Linux on
Mac's ;))
Why not have Lisp, up right corner, unfolding a number of standard blocks at
screen , implermenting it shuld be easy with Windows , wouldn't it ; please Im'e
not going to talk for reinventing the double reversed lack of sense, ----------
( no I don't mean Ms. ) , still Im'e glad about the proposal of a common Lisp
made more modern than standard compiler window textscreen , Reinventing the
round thing shuldn't be nessery it's allway's nice with some Viking mentality
;))

>
> The trick is to introduce the powerful features of LISP (anonymous functions,
> mapping, closures, macros, etc) in such a way that the expressiveness
> offsets the perceived syntactic clunkiness. People don't want generality
> when they are just trying to read a dictionary file... they just want the
> file to get read!

> Regards,
> MMN

Don't know what people programming want to do, if you make a standard, it better
be good.

Have a nice day.
P.C.
When you can just press a button, and have these produced ;
http://makeashorterlink.com/?B5574244
Then technology make sense to me ;))


novice106

unread,
Jan 26, 2002, 6:44:10 PM1/26/02
to

"Dr. Edmund Weitz" <e...@agharta.de> wrote in message
news:m34rl9tb...@bird.agharta.de...

> [...] I hadn't heard about CL.CONFIGURATION before, so


> I wanted to give it a try. What happened makes a good story (or case
> study if you prefer), so I'll write it down here.

[ ... A long, familiar, and perversely funny story ...]

This is exactly the kind of experience that prompted my 'confession'.

One of the great attractions of Lisp is that it allows me to focus on
solving a problem without paying much attention to housekeeping details.
I've tended to assume this extends to the Lisp environment as well as the
Lisp language.

When I think of all the stuff a beginning C programmer has to learn (eg.
compiling, linking, include paths, library paths, makefiles, etc), it's
quite a lot to swallow in one sitting. I didn't expect it to be so easy in
C, so why did I expect it to be simple in Lisp? Dunno, but I did. Perhaps
Python spoiled me.

Just about every C book contains a chapter on how to use the basic tools in
a generic Unix environment. The only two Lisp books I own (Norvig,
Winston/Horn) both (for good reasons) soar high above such trivia. I hope we
can fill in these gaps.

Leaving aside tools like CL.CONFIGURATION and other utilities for a moment,
I'd like to get a better understanding of what these tools are trying to
automate. I'm talking about very naive questions like: what actually happens
when I fire up my Lisp? What does it load by default? How do I tell it to
load something else? Are all these things implementation specific, or is
there some commonality? How do I call functions in different packages?
What's the proper method for using "require", "load", "in-package",
"use-package", and how are they related? When I use "use-package" I
sometimes get name clashes; what can I do about this? Should I always use
fully-qualified names, ie. prefaced by package name? Should I always put my
own code in a separate package? How should my packages be defined and named
(strings, keywords, ordinary symbols)? When I'm building a software system
in Lisp, should I 'include' files as I would in C, and if so how and where
do I specify how they're loaded? Or should I load them all and dump a
complete image? If I want to distribute an application in source form,
assuming somebody else has a Lisp runtime, how can I make it painless for
them to load and run my application?

If anybody can point me to documents that cover any of these topics (CMUCL
specific, if it matters), it would be very helpful. I suspect the documents
are out there, but perhaps scattered across several sites. If I can get a
handle on these topics, I'll distil the info and write up a summary for
review.

Oh, one specific (minor) issue. I've installed CLG with CMUCL. I have
cl-gtk.x86f in my extensions directory. "(require 'cl-gtk)" allows me to
load it and run GTK+ apps in the listener. Is there any way I can save and
distribute an image with the GTK bindings? Alternatively, how can I tell
CMUCL to load this package at startup?

Another quickie: I tried to install McCLIM with CMUCL(18c, Linux x86
glibc2.2), but it failed to compile "presentation.lisp". Somebody else must
have had this problem. Is there a quick fix without delving into CVS for
McCLIM?

Alexey Dejneka

unread,
Jan 27, 2002, 1:41:03 AM1/27/02
to
Hello,

"novice106" <novi...@yahoo.com.au> writes:

> what actually happens
> when I fire up my Lisp? What does it load by default?

It is implementation specific. E.g., sbcl loads /etc/sbclrc and
~/.sbclrc. Read a manual for your compiler (for CMUCL it is in the
section FILES in 'man lisp').

> How do I tell it to
> load something else?

If you want your CL to do smth at startup, put the correspondent
commands into your initialization file.

> Are all these things implementation specific, or is
> there some commonality?

If you use lisp packages from CCLAN, then at startup it will load
DEFSYSTEM and C-L-C, so you can do (REQUIRE :package) to load a package.

> How do I call functions in different packages?

(EXT:QUIT) -- function QUIT from EXT package.

> What's the proper method for using "require", "load", "in-package",
> "use-package", and how are they related?

These functions are divided into 2 unrelated groups.

1. REQUIRE and LOAD are for loading code into your lisp system. LOAD
unconditionally loads a specified file. REQUIRE is for loading
"modules". It can check whether a specified module is already
loaded, and if not, tries to load it. It has two forms:
(REQUIRE module-name) and (REQUIRE module-name pathname). In the
second form it load a file with a name PATHNAME if the module is
not loaded. The meaning of the first form is implementation
specific. With C-L-C it loads
"/path-to-repositiry/systems/module-name.system" and do (MK:OOS
MODULE-NAME :LOAD).

2. IN-PACKAGE and USE-PACKAGE. They deal with namespaces. Let your
current package be A. After (IN-PACKAGE B) the current package will
be B. After (USE-PACKAGE B) the current package will still be A,
but you can use unqualified names for symbols from B.

Read CLHS for more info.

> When I use "use-package" I
> sometimes get name clashes; what can I do about this?

Don't do it in such situation. Or use SHADOW, SHADOWING-IMPORT.

> Should I always put my
> own code in a separate package?

If you want to share your code with others -- yes. If it is a
use-once script -- no.

> How should my packages be defined

DEFPACKAGE?

> and named
> (strings, keywords, ordinary symbols)?

In your own code -- as you like (except for (DEFPACKAGE APACK ...) --
it can make a conflict later, use (DEFPACKAGE #:APACK) instead).

> When I'm building a software system
> in Lisp, should I 'include' files as I would in C,

You must provide a functionality before you can use it. E.g. if your
code uses a macro, this macro must be defined before compilation of
the code. So you must load its definition first.

> and if so how and where
> do I specify how they're loaded?

In a defsystem file.

> Or should I load them all and dump a
> complete image?

You can do it (not always) for an application, but not for a library
-- lisp cannot use two images simultaneously.

> If anybody can point me to documents that cover any of these topics (CMUCL
> specific, if it matters), it would be very helpful.

First get Common Lisp HyperSpec and read about Lisp language.

> Oh, one specific (minor) issue. I've installed CLG with CMUCL. I have
> cl-gtk.x86f in my extensions directory. "(require 'cl-gtk)" allows me to
> load it and run GTK+ apps in the listener. Is there any way I can save and
> distribute an image with the GTK bindings?
>
> Alternatively, how can I tell
> CMUCL to load this package at startup?

echo "(require :cl-gtk)" >>~/.cmucl-init.lisp

> Another quickie: I tried to install McCLIM with CMUCL(18c, Linux x86
> glibc2.2), but it failed to compile "presentation.lisp".

Did you do full load-compile-load cycle instead of just compile-load
(as it must be)? And you shold ask it in free-clim mailing list.

> Is there a quick fix without delving into CVS for
> McCLIM?

It dependes on what do you want from CLIM. Maybe you could just delete
references to "presentation.lisp" and "Examples/presentation-test"
from system.lisp.

--
Regards,
Alexey Dejneka

Tim Moore

unread,
Jan 27, 2002, 2:50:17 AM1/27/02
to
On 27 Jan 2002 09:41:03 +0300, Alexey Dejneka <adej...@comail.ru> wrote:
>Hello,

>
>"novice106" <novi...@yahoo.com.au> writes:
>
>> Another quickie: I tried to install McCLIM with CMUCL(18c, Linux x86
>> glibc2.2), but it failed to compile "presentation.lisp".
>
>Did you do full load-compile-load cycle instead of just compile-load
>(as it must be)? And you shold ask it in free-clim mailing list.
>
>> Is there a quick fix without delving into CVS for
>> McCLIM?

As always, specific error messages and output are most helpful.

Tim

Dr. Edmund Weitz

unread,
Jan 27, 2002, 7:18:36 AM1/27/02
to
Paolo Amoroso <amo...@mclink.it> writes:

> > * (load "env.system")
> > File-error in function COMMON-LISP::INTERNAL-LOAD: "env.system" does not exist.
>
> See note [*] below.

Where is it?

> > Compiling DEFMETHOD PARSE-CONF-CLAUSE ((EQL :REQUIRED-MODULE) T):
> > Error in KERNEL:%COERCE-TO-FUNCTION: the function REQUIRED-MODULE-CLAUSE-NAME is undefined.
> > Restarts:
> > 0: [ABORT] Return to Top-Level.
> > Debug (type H for help)
> > (KERNEL:%COERCE-TO-FUNCTION REQUIRED-MODULE-CLAUSE-NAME)
> > Source:
> > ; File: target:code/fdefinition.lisp
> > (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
> >
> > 0] (quit)
> > Error in KERNEL:%COERCE-TO-FUNCTION: the function QUIT is undefined.
> > Error flushed ...
>
> CL.CONFIGURATION is still in an early stage of development, and the latest
> officially released version is 0.1. Marco has been soliciting feedback on
> it for a long time. If you report this problem to the CLOCC mailing list,
> he will be able to fix it.

I will.

Thanks,
Edi.

Paolo Amoroso

unread,
Jan 27, 2002, 8:40:41 AM1/27/02
to
On Sun, 27 Jan 2002 10:44:10 +1100, "novice106" <novi...@yahoo.com.au>
wrote:

> If anybody can point me to documents that cover any of these topics (CMUCL
> specific, if it matters), it would be very helpful. I suspect the documents

You may have a look at the EncyCMUCLopedia--see my signature below--even if
it does not answer most of your questions.


> Another quickie: I tried to install McCLIM with CMUCL(18c, Linux x86
> glibc2.2), but it failed to compile "presentation.lisp". Somebody else must
> have had this problem. Is there a quick fix without delving into CVS for
> McCLIM?

Yes: report the problem to the McCLIM maintainers via the mailing list,
including all the information you have (version numbers, sequence of
operations that trigger the problem, error messages stack traces, etc.).
They need feedback from users in order to fix problems, and all the ones I
reported have been fixed.

Paolo Amoroso

unread,
Jan 27, 2002, 8:40:44 AM1/27/02
to
On Sat, 26 Jan 2002 20:02:32 +0100, Paolo Amoroso <amo...@mclink.it>
wrote:

> CL.CONFIGURATION is a tool for processing `.conf' configuration description
> files. If you develop an application that uses CL.CONFIGURATION, you have
> to supply that file. See note [+] below.

[...]


> If you are familiar with C development tools under Unix, you may think of
> DEFSYSTEM as `make', and of CL.CONFIGURATION as `autoconf'. So, the `.conf'
> file mentioned above[+] is something analogous to the scripts that you
> supply to `autoconf'.

Here is a--hopefully correct--minimal CL.CONFIGURATION example. Suppose you
are developing an application, `COOL-APP', intended to run under Unix,
Windows and MacOS. Its `cool-app.conf' configuration file may look like
(recall that it's a minimal example):

(con:defconfiguration "COOL-APP" ()
(:library-location "/usr/src/lisp/cool-app/" :os-type :unix)
(:library-location "C:\\LISP\\COOL-APP\\" :os-type :ms-windows)
(:library-location "Disk:src:lisp:COOL-APP:" :os-type :mac-os))

where each :LIBRARY-LOCATION clause specifies the source code location for
a particular operating system. You can then configure the COOL-APP system
by loading the `cool-app.conf' file in a running Lisp image (containing
CL.CONFIGURATION, of course) and evaluating the form:

(conf:setup "COOL-APP")

This performs all operating system and Lisp system dependent configurations
specified in the `.conf' file, and is analogous to running `./configure' in
the case of a C program under Unix. In the above example, CONF:SETUP sets
up the logical pathname COOL-APP. Now you can use DEFSYSTEM to compile and
load COOL-APP (operations roughly analogous to `make' and `./cool-app' in
the C case):

(mk:compile-system :cool-app)
(mk:load-system :cool-app)

Corrections and clarifications are greatly appreciated. Did I mention that
this is a minimal example? :)

Kenny Tilton

unread,
Jan 27, 2002, 9:07:28 AM1/27/02
to

I was wondering how one would even "line up" just one thing. :)

--

kenny tilton
clinisys, inc
----------------------------------
"Catch a wave."
- Brian Wilson

Pierre R. Mai

unread,
Jan 27, 2002, 8:58:21 AM1/27/02
to
g...@jpl.nasa.gov (Erann Gat) writes:

> Tim Bradshaw <t...@cley.com> wrote:
>
> > The only thing you get is transactions and that's hardly
> > an issue here.
> ...
> > I think they are the main thing. My guess is that a lot more people
> > care a lot more about knowing that the system that handles all their
> > financial transactions works correctly than care about indexing.
>
> Maybe so, but we're not talking about a financial system here, we're
> talking about a bulletin board. In that context transactions are neither
> the main thing nor the only thing.

But I'd still claim that transaction processing (and probably all the
meta-data management issues, as well) is one of the few things that
run-of-the-mill RDBMSes are exceedingly good at. It is e.g. very easy
to beat Oracle when it comes to read-only access to rigidly structured
databases, with clearly predictable access patterns.

> "Marc Battyani" <Marc.B...@fractalconcept.com> wrote:
>
> > Sure but we were saying that the number of articles was very, very small ;-)
>
> At the moment. Presumably the number of articles won't be small forever.

Well, let's be realistic about that: Even if the cookbook approach
took of really fantastically well, it would take a couple of years
before the number of articles surpasses, let's say 10000 articles.
Before it crosses that threshold, any non-random indexing strategy is
going to be sufficiently fast, and sufficiently simple to implement.
Once it crosses that threshold, you will have lots of other
performance and management problems already, so you will likely
reconsider quite a number of implementation decisions, and reimplement
anyway.

But this whole point is IMHO moot, since Google has already solved all
the text indexing needs you'll ever need (just make sure you play
along nicely with the Google bots, and handle all your searching needs
via Google's services).

One thing I've learned to appreciate in my more-or-less continuous
stay in "the real world" is that you can achieve more with less if you
look at realistic requirements projections, and plan accordingly.
There are quite a few corners you can _safely, and profitably_ cut,
when you don't need overgeneralized solutions.

That said, I'd still consider using a smallish RDBMS like PostgreSQL
for the transaction handling requirements, since a collaborative
editing site will need some form of transaction handling anyway,
botching it is going to be painful, so why not use a stable one that's
already there...

And that's the second thing I learned: It sometimes (but by no means
all the time) pays to use a "non-optimal" existent solution, instead
of badly reinventing it yourself.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein

Paolo Amoroso

unread,
Jan 27, 2002, 10:26:45 AM1/27/02
to
On 27 Jan 2002 13:18:36 +0100, e...@agharta.de (Dr. Edmund Weitz) wrote:

> Paolo Amoroso <amo...@mclink.it> writes:
>
> > > * (load "env.system")
> > > File-error in function COMMON-LISP::INTERNAL-LOAD: "env.system" does not exist.
> >
> > See note [*] below.
>
> Where is it?

Ooops... I forgot to add the [*] marker before the following paragraph:

As for the Common Lisp Controller, it's a way of making sure that a
package "is there" the next time you start your Lisp, without having to
keep track of where libraries are in the file system. Its goal is to make
it possible to just type a form like:

(require :cool-library)

each time you need a particular library in your running Lisp image.

Apologies,

Dr. Edmund Weitz

unread,
Jan 27, 2002, 10:34:42 AM1/27/02
to
"Pierre R. Mai" <pm...@acm.org> writes:

[ a couple of thoughtful paragraphs about RDMSs and "real world"
applications that I mostly agree with ]

> And that's the second thing I learned: It sometimes (but by no means
> all the time) pays to use a "non-optimal" existent solution, instead
> of badly reinventing it yourself.

Which comes back to the point that I made initially: The server I'm
talking about (which is used as a testbed for various customers)
already has some apps that run atop mod_perl/DBI/PostgreSQL. This is
definitely not "optimal" and by no means CL-related, but it's there
and I could apply the existing code to the Cookbook in a couple of
hours. (After all, Slashdot uses the same combination of tools -
replace PostgreSQL with MySQL - and it seems to work well. Should we
ever be able to reach only ten percent of Slashdot's traffic, I'd be
glad to change to whatever solution might be considered "optimal" at
that time.)

Cheers,
Edi.

Thaddeus L Olczyk

unread,
Jan 27, 2002, 12:38:08 PM1/27/02
to
On 27 Jan 2002 14:58:21 +0100, "Pierre R. Mai" <pm...@acm.org> wrote:

>But this whole point is IMHO moot, since Google has already solved all
>the text indexing needs you'll ever need (just make sure you play
>along nicely with the Google bots, and handle all your searching needs
>via Google's services).
>

>That said, I'd still consider using a smallish RDBMS like PostgreSQL
>for the transaction handling requirements, since a collaborative
>editing site will need some form of transaction handling anyway,
>botching it is going to be painful, so why not use a stable one that's
>already there...

There is nothing smallish about postgreSQL. In fact it is the db used
by Google which you so readily praise above.

Pierre R. Mai

unread,
Jan 27, 2002, 1:49:50 PM1/27/02
to
olc...@interaccess.com (Thaddeus L Olczyk) writes:

I'm sorry, but I've been using PostgreSQL (in its various names and
guises) now for over half a decade, and PostgreSQL is a smallish
RDBMS, when compared to "standard" RDBMS like Oracle, DB/2, etc. (which
among themselves already vary in complexity), both in the good and bad
implications of that word. For the application at hand, PostgreSQL's
small size, installation and administration overhead are quite
advantageous.

When did you last install or administer an Oracle DB?

Tim Bradshaw

unread,
Jan 28, 2002, 4:29:15 AM1/28/02
to
* Bijan Parsia wrote:

> I'd have thought that a fulltext inverted index sort of thing would be
> preferable (a la Lucene, or Ht/Dig). May this is what folks *really* want,
> but don't get, perhaps because they don't know they want it :).

Well, yes.

> Actually, I think "organization" or "structuring" is what database driven
> web building is most common motivated by. Instead of putting your author
> bios in on directory, the article under each topic in their own
> directors, and having to cross link by hand and symlink and *yeccch*, you
> can express organization pages (by topic, by author, etc.) as queries,
> with a more pleasing and rational and maintainable structure at the
> semiphysical level.

Yes, of course. But the choice isn't between and RDBMS and symlinking
by hand, of course, even though the SQLoids would like you to think it
is.

--tim

Brian P Templeton

unread,
Feb 1, 2002, 9:13:51 PM2/1/02
to
m...@mmn.bellatlantic.net (Michael Naunton) writes:

> On 24 Jan 2002 10:52:13 +0100, Dr. Edmund Weitz <e...@agharta.de> wrote:
>
[list of topics elided]
> I think Sun got it right with their concept of "Trails" for Java. It's
> hard to teach LISP in a linear fashion: if a user wants to know how to
> read in a file, she's at chapter 15, and it makes no sense at all: e.g.
> what's this "(foobar &list :opt fun-arg :rest a-list)" advice?
>
From the name and your description (I'm fortunately unfamiliar with
Java), I think the credit ought to go to Vannevar Bush :).

[...]


--
BPT <b...@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards

Marco Antoniotti

unread,
Feb 4, 2002, 1:03:26 PM2/4/02
to

e...@agharta.de (Dr. Edmund Weitz) writes:

> Disclaimers:
>
No problema compadre.


>
>
> OK, here we go:
>
> A. Google told my that CL.CONFIGURATION was part of the CLOCC project,
> so I said, "Hey, you have CLOCC already. You even managed to get it
> (partly) installed, so this should be easy." I found
> CL.CONFIGURATION but had to realize that there were no compiled
> files in that directory so I had to build first. I re-read the
> CLOCC installation instructions and found this paragraph:
>
> You should be able to compile any package in CLOCC now by typing
> "make system" in the appropriate directory.
> E.g., if you want to compile "PORT" (the cross-implementation
> portability system), you do
> $ cd src/port
> $ make system
>
> OK, fine, CL.CONFIGURATION is in the port directory, so I did 'cd
> src/port' and 'make system'. CMUCL started to work, everyting went
> smoothly, and after it had finished I found a couple of new '.x86f'
> files in there. Unfortunately, the CL.CONFIGURATION stuff wasn't
> amongst them...

You are right. Essentially CL.ENVIRONMENT, CL.CONFIGURATION and
MK:DEFSYSTEM 3.2x are independent of the CLOCC. They are in the CLOCC
as a convenient and well known place where to keep them.

I can add the Makefiles for the CLOCC distribution. It will not be a
problem.

> B. OK, no prob. I did 'cd configuration' and 'make system':
>
> edi@bird:/usr/local/clocc/src/port/configuration> make system
> make: *** No rule to make target `system'. Stop.
>
> C. Ah, I see. Looks like I have to read the INSTALLATION file. [...]
> I'm lucky - I have CMUCL, so I can use DEFSYSTEM and follow the
> easy installation path. [Remark: The CMUCL binaries that I
> downloaded some months ago didn't come with DEFSYSTEM, but I
> managed to find it when I first needed it. Unfortunately, I had to
> find out that there seem to be mutual incompatible DEFSYSTEMs out
> there - but that's another story.]

CL.CONFIGURATION and CL.ENVIRONMENT do not require MK:DEFSYSTEM. The
.system files are there just as a conveninece.

>
> D. I followed the instructions and did the following:
>
> * (load "defconf.system")
> T
> * (mk:compile-system 'cl.ext.configuration)
> Error in function "Top-Level Form":
> CL.EXT.CONFIGURATION requires the CL.ENVIRONMENT package.

Ok. I need better error messages for this.

> Damn! Where's that one? Ah, yes, it's in the neighbor
> directory. Let's go there...
>
> E. Some seconds later I succeeded in building CL.ENVIRONMENT which
> actually worked as advertised in the INSTALLATION file. Now I
> wondered how I would make sure that the package is there the next
> time I start CMUCL. As I had had to fiddle with DEFSYSTEM before I
> though that something like this should work...
>
> * (load "env.system")
> * (mk:oos 'cl.environment :load)
>
> ...and it did. However, it of course only worked in the same
> directory.

Exactly. This is a feature. CL.ENVIRONMENT and CL.CONFIGURATION have
not been designed to fit in any "framework". They are "raw" packages
that must be carefully loaded into a working Lisp image. I suppose
that this should be emphasized. If you use the 'load-' scripts, they
will work better.

> When I went back into the CL.CONFIGURATION directory, I
> got:
>
> * (load "env.system")
> File-error in function COMMON-LISP::INTERNAL-LOAD: "env.system" does not exist.
>
> F. Yeah, sure - sorry. Of course it's...
>
> * (load "../environment/env.system")
> T
> * (mk:oos 'cl.environment :load)
> Error in format: Unknown format directive.
> Source file ~A ~
> ~:[and binary file ~A ~;~]not found, not loading.
> ^

Ok, this is a bug.

> G. Oops - my bad: I didn't read the manual carefully and forgot to
> configure the 'env.system' file. No problem, I added the correct
> lines to this file and re-built CL.ENVIRONMENT. Now I tried to
> build CL.CONFIGURATION again and ended up with:
>
> Compiling DEFMETHOD PARSE-CONF-CLAUSE ((EQL :REQUIRED-MODULE) T):
> Error in KERNEL:%COERCE-TO-FUNCTION: the function REQUIRED-MODULE-CLAUSE-NAME is undefined.
> Restarts:
> 0: [ABORT] Return to Top-Level.
> Debug (type H for help)
> (KERNEL:%COERCE-TO-FUNCTION REQUIRED-MODULE-CLAUSE-NAME)
> Source:
> ; File: target:code/fdefinition.lisp
> (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
>
> 0] (quit)
> Error in KERNEL:%COERCE-TO-FUNCTION: the function QUIT is undefined.
> Error flushed ...
>
> Hmmmm.....

This is another bug.

> H. Now let's suppose I will be able to build CL.CONFIGURATION. If I
> understand Marco Antoniotti's posting correctly it'll need some
> kind of '.conf' file to build a system, but there are no '.conf'
> files in CLOCC or in the packages from onShore that I downloaded
> the other day. Would CL.CONFIGURATION help me in these cases?

The documentation is still embryonal. There is an example in the paper.

> I. And what's the relation between CL.CONFIGURATION,
> COMMON-LISP-CONTROLLER and DEFSYSTEM? Do they depend on each other?
> Are they intended to replace each other? Or are they orthogonal?

CL.CONFIGURATION and C-L-C are independent as they have been developed
separatedly. They solve similar but non completely overlapping
problems. CL.CONFIGURATION is independent of MK:DEFSYSTEM. Any
(def)system using CL.CONFIGURATION can be sure to have - at a minimum
- a set of logical pathnames correctly set up. CL.CONFIGURATION can
also use the environment created by C-L-C.

One thing that CL.CONFIGURATION does (modulo bugs) is to be portable
across CL implementations and operating systems.

> J. Now, the usual answer might be: 'Install Debian and you're done.'

CL.CONFIGURATION does not require you anything like this. See above.

> OK, so far for the rant. What is my conclusion? As I said before, I
> don't want to accuse anyone. I just wanted to make clear that we're in
> need of more and better documentation for the CL community. It is
> unlikely that O'Reilly will provide us with a pile of books, and the
> core developers have enough work already, so we (the Newbies) have to
> do it (with a little help from the experts if time permits). That's
> why I want to start the Cookbook project.
>
> Thanks for listening,

Your rant is well accepted. I will do what you think is necessary to
make CL.CONFIGURATION more useful and usable. Just remember to read
my signature :)

Ciao

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

0 new messages