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

ASDF-newbie: How to determine whether ASDF is *already* installed on my ISP?

220 views
Skip to first unread message

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 10, 2009, 12:52:38 PM1/10/09
to
My personal ISP account has very limited disk space not already
used. I would like to know whether my ISP already has ASDF
installed on some public system directory (freeBSD Unix shell)
before I go ahead and download and install yet another copy of it
within my personal account. It's partly a matter of not wanting to
waste space with a private copy if it's already installed by the
ISP, and partly to avoid possible conflicts if there are two
different copies in different directories at the same time.

I looked several times at each of these:
<http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/README>
<http://constantly.at/lisp/asdf/> but neither of them tells me
anything about checking if ASDF already is installed. Each seems to
assume you already know it's not previously installed and you need
to start from scratch installing it.

I asked this same question a couple times previously in different
threads, but nobody told me how to get the info I need. I'm hoping
blatantly announcing "ASDF-newbie" in the Subject field will
finally attract somebody who knows the answer. Does anybody know
how to get that ASDF-already-installed-or-not info???

Later: If I can ever find out whether ASDF is already installed on
my ISP, and if it turns out that it's in fact not yet installed and
I need to download and install it myself on my personal account,
I'll need to know how to get it and how to install it. For example:
<http://www.cliki.net/asdf>
says:
you can find it in the Sourceforge cCLan CVS repository:
* http://cclan.cvs.sourceforge.net/cclan/asdf/
but when I click on that link it says:
ViewVC Exception
An Exception Has Occurred
The root "cclan" is unknown. If you believe the value is correct, then
please double-check your configuration.
HTTP Response Status
404 Repository not found
_________________________________________________________________

<http://constantly.at/lisp/asdf/Using-asdf-to-load-systems.html#Using%20asdf%20to%20load%20systems>
says:
The single file asdf.lisp is all you need to use asdf normally. Once
you load it in a running Lisp, you're ready to use asdf.
Is that really correct??

<http://www.cliki.net/asdf> also says:
The source code of ASDF is here.
URL: <http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/asdf.lisp>
Is that the aforementionned "single file" that I need to load into
a running CMUCL before using ASDF? So, assuming it's not already on
some system directory and I need to download my own private copy, I
just download the contents of that Web page to my private account,
start up CMUCL, load that in, and then I can immediately start
using ASDF?

The cclan version of asdf apparently doesn't have the necessary code
to hook REQUIRE into CMUCL. So here is a small bit of code to make it
so. You need at least cmucl 19a with patch 0 for this to work.

When I start up CMUCL here, it says:
CMU Common Lisp 18b, running on shell.rawbw.com
So does anybody know whether if I go to the trouble of downloading
and installing ASDF here, it'll even be possible for it to work
here?? Does anybody know how to make ASDF work here? Or should I
just dismiss ASDF as something that can't possibly work here and
is not worth any further bother on my part?

Pascal J. Bourguignon

unread,
Jan 10, 2009, 1:10:31 PM1/10/09
to
seeWeb...@teh.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
writes:

> My personal ISP account has very limited disk space not already
> used. I would like to know whether my ISP already has ASDF
> installed on some public system directory (freeBSD Unix shell)
> before I go ahead and download and install yet another copy of it

> within my personal account. [...]

man locate
man find

If the administrator has configured his system to updated periodically
the locate database, you can use it to locate a file by (part of) name
(or with some versions of localte by regular expression).

locate asdf.lisp

Otherwise, in the last resort, you can use find (it's slower since it
scans all the directory hierarchy):

find / -name asdf.lisp -print


That said, asdf.lisp is about 40 KB, I wouldn't hesitate to keep my own
copy in case of version differential or whatever.

> I looked several times at each of these:
> <http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/README>
> <http://constantly.at/lisp/asdf/> but neither of them tells me
> anything about checking if ASDF already is installed. Each seems to
> assume you already know it's not previously installed and you need
> to start from scratch installing it.

There's nothing to do to install asdf. Just load the asdf.lisp file.

> The single file asdf.lisp is all you need to use asdf normally. Once
> you load it in a running Lisp, you're ready to use asdf.
> Is that really correct??

How many times do we need to tell?


> <http://www.cliki.net/asdf> also says:
> The source code of ASDF is here.
> URL: <http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/asdf.lisp>
> Is that the aforementionned "single file" that I need to load into
> a running CMUCL before using ASDF? So, assuming it's not already on
> some system directory and I need to download my own private copy, I
> just download the contents of that Web page to my private account,
> start up CMUCL, load that in, and then I can immediately start
> using ASDF?

That's what it says, yes.


> The cclan version of asdf apparently doesn't have the necessary code
> to hook REQUIRE into CMUCL. So here is a small bit of code to make it
> so. You need at least cmucl 19a with patch 0 for this to work.
>
> When I start up CMUCL here, it says:
> CMU Common Lisp 18b, running on shell.rawbw.com
> So does anybody know whether if I go to the trouble of downloading
> and installing ASDF here, it'll even be possible for it to work
> here?? Does anybody know how to make ASDF work here? Or should I
> just dismiss ASDF as something that can't possibly work here and
> is not worth any further bother on my part?

You don't care about REQUIRE. It's a deprecated feature. It behavior
with one argument is implementation dependant, and its behavior with two
argument is about the same as LOAD, only with one more useless
argument. JUST USE LOAD!

--
__Pascal Bourguignon__

D Herring

unread,
Jan 10, 2009, 1:51:36 PM1/10/09
to
Robert Maas, http://tinyurl.com/uh3t wrote:
> My personal ISP account has very limited disk space not already
> used. I would like to know whether my ISP already has ASDF
> installed on some public system directory (freeBSD Unix shell)
> before I go ahead and download and install yet another copy of it
> within my personal account. It's partly a matter of not wanting to
> waste space with a private copy if it's already installed by the
> ISP, and partly to avoid possible conflicts if there are two
> different copies in different directories at the same time.

In lisp,
- Does asdf:*central-registry* have a value?
If yes, ASDF is already loaded.
- Does (require :asdf) succeed?
If yes, ASDF is already available in a known location.
- Otherwise, upload ASDF.lisp to your server. Then
(load "/path/to/asdf.lisp")
(push #P"/path/to/*.asd" asdf:*central-registry*)
...

For some lisps, it is better to
(compile-file #P"/path/to/asdf.lisp") ; do this once
and then load the compiled version of ASDF.
(load #P"/path/to/asdf.fas") ; or whatever extension your lisp uses

For most (all?) lisps, this can be simplified as
(compile-file "/path/to/asdf") ; compile-file guesses the extension
(load "/path/to/asdf") ; load tries compiled version first

HTH,
Daniel

budden

unread,
Jan 10, 2009, 6:24:25 PM1/10/09
to
> - Does asdf:*central-registry* have a value?
In this case, it is better to try
(find-package :asdf) first. If it returns true value then asdf is
loaded.

Rob Warnock

unread,
Jan 10, 2009, 9:57:20 PM1/10/09
to
Pascal J. Bourguignon <p...@informatimago.com> wrote:
+---------------

| You don't care about REQUIRE. It's a deprecated feature. It behavior
| with one argument is implementation dependant, and its behavior with two
| argument is about the same as LOAD, only with one more useless
| argument. JUST USE LOAD!
+---------------

Well, while well-intended, I feel that's a bit too strong.
REQUIRE does have one useful feature that one would want to
duplicate when "just using LOAD", namely, that it won't LOAD
the file again if LOADing it the first time resulted in the
addition of the module name to *MODULES*. This makes it easy
for small utility modules to simply REQUIRE the other modules
they depend on without having to have an ASDF file for every
possible combination of modules one might use!

Yes, one can easily create a REQUIRE replacement that performs
an equivalent "once-only" action, and perhaps that's a better
solution for programs intended to be very portable. Something
like this perhaps [only lightly tested]:

(defvar *my-required-files* nil)

(defun my-require (&rest files)
(dolist (file files)
(let ((path (truename file)))
(unless (find path *my-required-files* :test #'equal)
(load path)
(push path *my-require-files*)))))

But for local hacking about, I find CMUCL's REQUIRE adequate... ;-}


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Kaz Kylheku

unread,
Jan 11, 2009, 12:47:34 AM1/11/09
to
On 2009-01-10, D Herring <dher...@at.tentpost.dot.com> wrote:
> In lisp,
> - Does asdf:*central-registry* have a value?
> If yes, ASDF is already loaded.

You mean, does the syntax ASDF:*CENTRAL-REGISTRY* intern a symbol, rather than
signaling an error about a nonexistent package?

If so, ASDF is already loaded.

:)

Mark Wooding

unread,
Jan 11, 2009, 8:54:06 AM1/11/09
to
Kaz Kylheku <kkyl...@gmail.com> wrote:

> You mean, does the syntax ASDF:*CENTRAL-REGISTRY* intern a symbol,
> rather than signaling an error about a nonexistent package?

It's unlikely to intern a symbol. If the symbol isn't interned already,
but package exists, you'll get an error saying that the symbol isn't
exported -- because it can't very well be if it isn't interned.

> If so, ASDF is already loaded.

I'd probably just check (MEMBER :ASDF *FEATURES*) to see if it's loaded.

-- [mdw]

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 11, 2009, 7:13:24 PM1/11/09
to
> > My personal ISP account has very limited disk space not already
> > used. I would like to know whether my ISP already has ASDF
> > installed on some public system directory (freeBSD Unix shell)
> > before I go ahead and download and install yet another copy of it
> > within my personal account. [...]
> From: p...@informatimago.com (Pascal J. Bourguignon)
> man locate

Thanks, looks reasonable to try.

On my current (very cramped) shell account:
shell.rawbw.com% locate -S
Database: /var/db/locate.database
Compression: Front: 17.35%, Bigram: 63.12%, Total: 12.68%
Filenames: 181580, Characters: 11116300, Database size: 1409385
Bigram characters: 519782, Integers: 3810, 8-Bit characters: 3
shell.rawbw.com% ls -l /var/db/locate.database
1392 -r--r--r-- 1 nobody wheel 1409385 Jan 10 04:15 /var/db/locate.database

On the machine we'll be miagrating to eventually:
> locate -S
Database: /var/db/locate.database
Compression: Front: 16.13%, Bigram: 64.18%, Total: 11.88%
Filenames: 528282, Characters: 32084063, Database size: 3811449
Bigram characters: 1365297, Integers: 19481, 8-Bit characters: 0
> ls -l /var/db/locate.database
3845 -r--r--r-- 1 nobody wheel 3811449 Jan 10 04:18 /var/db/locate.database

On the machine in the UK where I have a guest account:
rem@teh:~$ locate -S
Database /var/cache/locate/locatedb is in the LOCATE02 format.
Locate database size: 11087253 bytes
Filenames: 644372 with a cumulative length of 47764669 bytes
of which 1459 contain whitespace,
2 contain newline characters,
and 100 contain characters with the high bit set.
Compression ratio 76.79%
rem@teh:~$ ls -l /var/cache/locate/locatedb
-rw-r--r-- 1 root root 11087253 Jan 11 06:26 /var/cache/locate/locatedb

So it looks like the database is kept up to date on all three machines.

> man find

Too messy, confusing, nevermind probably too slow and unnecessary.

> locate asdf.lisp

Trying that on all three machines:

shell.rawbw.com% locate asdf.lisp
(no output before next shell prompt, hence no such file found)

> locate asdf.lisp
/usr/ports/devel/cl-asdf/files/patch-asdf.lisp
Um, what is that???
> more /usr/ports/devel/cl-asdf/files/patch-asdf.lisp
--- asdf.lisp.orig Thu Mar 20 13:58:09 2003
+++ asdf.lisp Thu Mar 20 13:58:49 2003
@@ -322,8 +322,7 @@
(defvar *central-registry*
'(*default-pathname-defaults*
- #+nil "/home/dan/src/sourceforge/cclan/asdf/systems/"
- #+nil "telent:asdf;systems;"))
+ "%%PREFIX%%/lib/common-lisp/system-registry/"))
(defun sysdef-central-registry-search (system)
(let ((name (coerce-name system)))
Why is that file present if the primary asdf.lisp isn't anywhere there??

rem@teh:~$ locate asdf.lisp
/home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp
/usr/share/common-lisp/source/arnesi/src/asdf.lisp
/usr/share/common-lisp/source/asdf/asdf.lisp
/usr/share/sbcl-common/contrib/asdf/asdf.lisp
Four different versions, comparing sizes:

rem@teh:~$ ls -l /home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp
-rw-r--r-- 1 jpw jpw 44714 Aug 31 2005 /home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp
rem@teh:~$ ls -l /usr/share/common-lisp/source/arnesi/src/asdf.lisp
-rw-r--r-- 1 root root 2376 Oct 12 2005 /usr/share/common-lisp/source/arnesi/src/asdf.lisp
rem@teh:~$ ls -l /usr/share/common-lisp/source/asdf/asdf.lisp
-rw-r--r-- 1 root root 39639 Sep 26 2005 /usr/share/common-lisp/source/asdf/asdf.lisp
rem@teh:~$ ls -l /usr/share/sbcl-common/contrib/asdf/asdf.lisp
-rw-r--r-- 1 root root 44714 Mar 27 2006 /usr/share/sbcl-common/contrib/asdf/asdf.lisp
First and last are same size, so comparing them:
rem@teh:~$ diff /home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp /usr/share/sbcl-common/contrib/asdf/asdf.lisp | more
(no output before next shell prompt, hence files are identical)

Comparing slightly short with full-length versions:
rem@teh:~$ diff /usr/share/common-lisp/source/asdf/asdf.lisp /usr/share/sbcl-common/contrib/asdf/asdf.lisp | more
< ;;; This is asdf: Another System Definition Facility. $Revision: 1.88 $
---
> ;;; This is asdf: Another System Definition Facility. 1.87
Curious that the shorter version, of which there's only one copy,
is actually the older version.
Also the dates written to local disk aren't consistent with the
sequence of version numbers.
If I use ASDF on that system, would it be prudent to explicitly
specify the FULL PATH in the LOAD command to get the same (latest)
version every time?
..
< (defvar *asdf-revision* (let* ((v "$Revision: 1.88 $")
< (colon (or (position #\: v) -1))
< (dot (position #\. v)))
---
> (defvar *asdf-revision* (let* ((v "1.87")
> (colon (or (position #\: v) -1))
> (dot (position #\. v)))
Hmm, it looks like 1.87 is correctly prettyprinted, but 1.88 is trashed.
Or maybe 1.88 used TAB optimization, which breaks indented output from 'diff'?
Is there any utility on Ubuntu Linux that is like 'diff' but ignores
the difference in white space?

Finally, looking at that short file:
rem@teh:~$ more /usr/share/common-lisp/source/arnesi/src/asdf.lisp
;; -*- lisp -*-
(in-package :it.bese.arnesi)
;;;; * A clean-op for ASDF
(defclass clean-op (asdf:operation)
((for-op :accessor for-op :initarg :for-op :initform 'asdf:compile-op))
(:documentation "Removes any files generated by an asdf component."))
(defmethod asdf:perform ((op clean-op) (c asdf:component))
"Delete all the output files generated by the component C."
(dolist (f (asdf:output-files (make-instance (for-op op)) c))
(when (probe-file f)
(delete-file f))))
..
Is that something I would need *after* 1.88, or something already
incorporated into it hence no longer needed?

> Otherwise, in the last resort, you can use find (it's slower since it
> scans all the directory hierarchy):
> find / -name asdf.lisp -print

Skipping that idea since 'locate' seems to work fine with up-to-date database.

> That said, asdf.lisp is about 40 KB, I wouldn't hesitate to keep
> my own copy in case of version differential or whatever.

On both FreeBSD systems, asdf apparently isn't on system disk, so
I'll need to have my own private copy. On Ubuntu, please advise
which of the various versions I should use, and why that short file
is present.

> There's nothing to do to install asdf. Just load the asdf.lisp file.

Don't I also need to somehow set up a table of which directories
should be in my ASDF search path? Or does the regular Unix/Linux
search path suffice? SInce the regular Unix/Linux search path is
for executables (binaries), not for ASDF libraries, I would think
I'd need a separate table of directories that might have ASDF
libraries to search.

> > The single file asdf.lisp is all you need to use asdf normally. Once
> > you load it in a running Lisp, you're ready to use asdf.
> > Is that really correct??
> How many times do we need to tell?

See my question above about setting up where to search for ASDF libraries.

> > <http://www.cliki.net/asdf> also says:
> > The source code of ASDF is here.
> > URL: <http://cclan.cvs.sourceforge.net/*checkout*/cclan/asdf/asdf.lisp>
> > Is that the aforementionned "single file" that I need to load into
> > a running CMUCL before using ASDF? So, assuming it's not already on
> > some system directory and I need to download my own private copy, I
> > just download the contents of that Web page to my private account,
> > start up CMUCL, load that in, and then I can immediately start
> > using ASDF?
> That's what it says, yes.

See my question above about setting up where to search for ASDF libraries.

> > The cclan version of asdf apparently doesn't have the necessary code
> > to hook REQUIRE into CMUCL. So here is a small bit of code to make it
> > so. You need at least cmucl 19a with patch 0 for this to work.
> > When I start up CMUCL here, it says:
> > CMU Common Lisp 18b, running on shell.rawbw.com
> > So does anybody know whether if I go to the trouble of downloading
> > and installing ASDF here, it'll even be possible for it to work
> > here?? Does anybody know how to make ASDF work here? Or should I
> > just dismiss ASDF as something that can't possibly work here and
> > is not worth any further bother on my part?

> You don't care about REQUIRE. It's a deprecated feature. ...

OK. Somebody later contradicted you, but for beginner use I think
I'll go with your easy way of using ASDF without using REQUIRE.

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 11, 2009, 7:40:12 PM1/11/09
to
> From: D Herring <dherr...@at.tentpost.dot.com>

> In lisp,
> - Does asdf:*central-registry* have a value?
> If yes, ASDF is already loaded.

On my current FreeBSD Unix account:
shell.rawbw.com% lisp


CMU Common Lisp 18b, running on shell.rawbw.com

..
* asdf:*central-registry*
Reader error at 65793 on #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*S
TDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>:
Package "ASDF" not found.
Restarts:
0: [ABORT] Return to Top-Level.
That's not a very clean way to get the info!
Maybe instead first something like this:
* (find-package "ASDF")
NIL
At that point I know there's no such package in the Lisp
environment so there can't possibly be a symbol by the name you
specified above.

> - Does (require :asdf) succeed?
> If yes, ASDF is already available in a known location.

* (require :asdf)
(long pause, appx. 20 seconds)
"modules:asdf" does not exist.

Switching over to the Ubuntu Linux system in the UK:
rem@teh:~$ lisp
-bash: lisp: command not found
rem@teh:~$ cmucl
-bash: cmucl: command not found
rem@teh:~$ sbcl
This is SBCL 0.9.8.8, an implementation of ANSI Common Lisp.
..
* (find-package "ASDF")
NIL
* asdf:*central-registry*
debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
READER-ERROR on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100015D091}>:
package "ASDF" not found
* (require :asdf)
appx. 3 second pause
("ASDF")
so does that mean it loaded it from one of those three files I
found earlier via the 'locate asdf.lisp' command?

> - Otherwise, upload ASDF.lisp to your server.

UPLOAD??? From what, my VT100 emulator? Do you perhaps mean DOWNLOAD??
To what server???? Why do I need to run a server before I can use ASDF??
Do you perhaps mean download TO SOMEWHERE WITHIN MY PERSONAL
DIRECTORY TREE ON MY SHELL ACCOUNT?

> Then
> (load "/path/to/asdf.lisp")
> (push #P"/path/to/*.asd" asdf:*central-registry*)

I'll wait until I get confirmation that you mis-wrote that above
about up/down load and where to.

> For some lisps, it is better to
> (compile-file #P"/path/to/asdf.lisp") ; do this once

If it's on a system directory, where I don't have write access,
such as on the Ubuntu system, this can't succeed, right?

> and then load the compiled version of ASDF.
> (load #P"/path/to/asdf.fas") ; or whatever extension your lisp uses
> For most (all?) lisps, this can be simplified as
> (compile-file "/path/to/asdf") ; compile-file guesses the extension
> (load "/path/to/asdf") ; load tries compiled version first

I'll set that advice aside until the earlier advice is clarified.

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 11, 2009, 7:57:54 PM1/11/09
to
> From: budden <budden-l...@mail.ru>

On my current FreeBSD Unix account (CMUCL):
* (find-package :asdf)
NIL

On the Ubuntu Linux machine in the UK (SBCL):
* (find-package :asdf)
NIL

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 11, 2009, 8:14:36 PM1/11/09
to
> > In lisp,
> > - Does asdf:*central-registry* have a value?
> > If yes, ASDF is already loaded.
> From: Kaz Kylheku <kkylh...@gmail.com>

> You mean, does the syntax ASDF:*CENTRAL-REGISTRY* intern a
> symbol, rather than signaling an error about a nonexistent package?
> If so, ASDF is already loaded.

I'm confused. It's my understanding that with only a single colon
between package name and symbol name, a symbol by that name must be
*already* interned in that package, and furthermore must be
exported from there so that I can see it from outside that package
with only single-colon qualifier. If there is such a package, but
no such symbol in it, then double colon ASDF::*CENTRAL-REGISTRY*
would intern it there, right?

* (make-package "FOOQ")
#<The FOOQ package, 0/9 internal, 0/9 external>

* fooq:bar
Reader error at 74579 on #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*S


TDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>:

Symbol "BAR" not found in the FOOQ package.

* fooq::bar
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable FOOQ::BAR is unbound.
i.e. it created the symbol bar in package fooq, then found it not
to have any variable binding.

Robert Maas, http://tinyurl.com/uh3t

unread,
Jan 11, 2009, 9:59:33 PM1/11/09
to
> From: Mark Wooding <m...@distorted.org.uk>

> I'd probably just check (MEMBER :ASDF *FEATURES*) to see if it's loaded.

On my current FreeBSD Unix account (CMUCL):
* (MEMBER :ASDF *FEATURES*)
NIL
* (require :asdf)


"modules:asdf" does not exist.

On the Ubuntu Linux system in the UK (SBCL):
* (MEMBER :ASDF *FEATURES*)
NIL
* (require :asdf)
("ASDF")
* (MEMBER :ASDF *FEATURES*)
(:ASDF :ANSI-CL
:COMMON-LISP
:SBCL
:UNIX
:SB-DOC
:SB-TEST
:SB-PACKAGE-LOCKS
:SB-UNICODE
:SB-SOURCE-LOCATIONS
:IEEE-FLOATING-POINT
:X86-64
:ELF
:LINUX
:GENCGC
:STACK-GROWS-DOWNWARD-NOT-UPWARD
:C-STACK-IS-CONTROL-STACK
:LINKAGE-TABLE
:STACK-ALLOCATABLE-CLOSURES
:OS-PROVIDES-DLOPEN
:OS-PROVIDES-DLADDR
:OS-PROVIDES-PUTWC)
IMO using POSITION instead of MEMBER is better, to avoid the
verbose printout of the tail of the list from the found-element to
the end of the list of features.

Several people (thanks to all) have responded to my question,
posting various parts of a complete answer. I'll now create a Web
page that summarizes the best info/advice I've seen ... done:
<http://www.rawbw.com/~rem/HowTo/ASDF/1-avail.html>
comments/corrections welcome. After I finish part 1, part 2 will
tell how to do a quick preliminary test with some arbitrary
asdf-loadable module to make sure it really works. No time for any
of that at the moment. After part 2, the standard online ASDF
documentation ought to suffice, unless I discover some "gotchas".
If things go smoothly from this point on, I might start actually
trying some of the modules, which will probably result in my
starting work on critiques of various asdf-loadable modules and a
classification of them per both intentional datatype(s) and ease of
use.

Alberto Riva

unread,
Jan 11, 2009, 10:40:00 PM1/11/09
to
Robert Maas, http://tinyurl.com/uh3t wrote on 01/11/2009 07:40 PM:
>> For some lisps, it is better to
>> (compile-file #P"/path/to/asdf.lisp") ; do this once
>
> If it's on a system directory, where I don't have write access,
> such as on the Ubuntu system, this can't succeed, right?

Yes, it can. See the :OUTPUT-FILE keyword argument to COMPILE-FILE.

And I would say that it is *always* better to compile asdf.lisp.

Alberto

D Herring

unread,
Jan 12, 2009, 12:39:04 AM1/12/09
to
Robert Maas, http://tinyurl.com/uh3t wrote:
...
(find-package :asdf)
BSD server - nil
linux home - nil

=> ASDF isn't preloaded (e.g. by an init file) on either system...


>> - Does (require :asdf) succeed?
>> If yes, ASDF is already available in a known location.
>
> * (require :asdf)
> (long pause, appx. 20 seconds)
> "modules:asdf" does not exist.
>
> Switching over to the Ubuntu Linux system in the UK:
> rem@teh:~$ lisp
> -bash: lisp: command not found
> rem@teh:~$ cmucl
> -bash: cmucl: command not found
> rem@teh:~$ sbcl
> This is SBCL 0.9.8.8, an implementation of ANSI Common Lisp.
> ..
> * (find-package "ASDF")
> NIL
> * asdf:*central-registry*
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
> READER-ERROR on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100015D091}>:
> package "ASDF" not found
> * (require :asdf)
> appx. 3 second pause
> ("ASDF")
> so does that mean it loaded it from one of those three files I
> found earlier via the 'locate asdf.lisp' command?

Yes, ASDF is available on your desktop, but apparently not on the server.


>> - Otherwise, upload ASDF.lisp to your server.
>
> UPLOAD??? From what, my VT100 emulator? Do you perhaps mean DOWNLOAD??
> To what server???? Why do I need to run a server before I can use ASDF??
> Do you perhaps mean download TO SOMEWHERE WITHIN MY PERSONAL
> DIRECTORY TREE ON MY SHELL ACCOUNT?

Somehow I though you were running lisp on a webserver and had
asdf.lisp on your personal desktop. Upload = "from local to
remote"... But now I see that you're doing this on two boxes to
confuse me.

Anyway, you need to get a copy of asdf.lisp on the BSD server. If
that requires netcat, then more power to you.


>> Then
>> (load "/path/to/asdf.lisp")
>> (push #P"/path/to/*.asd" asdf:*central-registry*)
>
> I'll wait until I get confirmation that you mis-wrote that above
> about up/down load and where to.

Since (require :asdf) works on your desktop, there's no reason to use
an explicit load unless you intend on compiling ASDF (see below) or
need a newer version.

The server will need to use either
(load #P"/path/to/asdf.lisp")
or
(require :asdf #P"/path/to/asdf.lisp")

I think REQUIRE, while "deprecated", is preferable to LOAD in this
case; it can no-op when the file is already loaded.


>> For some lisps, it is better to
>> (compile-file #P"/path/to/asdf.lisp") ; do this once
>
> If it's on a system directory, where I don't have write access,
> such as on the Ubuntu system, this can't succeed, right?
>
>> and then load the compiled version of ASDF.
>> (load #P"/path/to/asdf.fas") ; or whatever extension your lisp uses
>> For most (all?) lisps, this can be simplified as
>> (compile-file "/path/to/asdf") ; compile-file guesses the extension
>> (load "/path/to/asdf") ; load tries compiled version first
>
> I'll set that advice aside until the earlier advice is clarified.

On my system, it takes ~1.25s for sbcl to (load "asdf.lisp") and
~0.08s for sbcl to (load "asdf.fasl"). In normal use, that's not
enough for me to care; but on a webserver, it may be a different story.

Since you don't have write access to the directory containing
asdf.lisp on the server, compile it with something like

(compile-file #P"/path/to/asdf.lisp"
:output-file #P"/path/to/asdf.fasl")

Then load the compiled version using
(load #P"/path/to/asdf.fasl")

and tell ASDF where to find files using


(push #P"/path/to/*.asd" asdf:*central-registry*)

where #P"/path/to/*.asd" is a directory of symlinks named *.asd
pointing to the asd files in actual packages.

-----

On your webserver, is SBCL a persistent process, or is it started each
time a CGI script runs? If the latter, there are two tricks you might
consider:
- Use save-lisp-and-die to save everything into a single image
- Switch to clisp

On my system,
# time sbcl --eval '(quit)'
real 0m0.352s
# time clisp -x '(quit)'
real 0m0.020s
> time clisp -x '(require :asdf "./asdf.fas") (quit)'
real 0m0.114s

So the slower implementation is sometimes faster.

- Daniel

Pascal J. Bourguignon

unread,
Jan 12, 2009, 1:52:35 AM1/12/09
to

> rem@teh:~$ locate asdf.lisp


> /home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp
> /usr/share/common-lisp/source/arnesi/src/asdf.lisp
> /usr/share/common-lisp/source/asdf/asdf.lisp
> /usr/share/sbcl-common/contrib/asdf/asdf.lisp
> Four different versions, comparing sizes:

So you can see that this jpw user has his own copy, and SBCL too, beside
the original source /usr/share/common-lisp/source/asdf/asdf.lisp


> Curious that the shorter version, of which there's only one copy,
> is actually the older version.

Not at all. Usually code grows. It's rare a programmer who can add
features or remove bug by removing code.


> Is there any utility on Ubuntu Linux that is like 'diff' but ignores
> the difference in white space?

man diff

Look, it's not difficult. On unix, before using ANY command, you should
just type: man THE_COMAND and read carefully the page mage of the
command.

> Finally, looking at that short file:
> rem@teh:~$ more /usr/share/common-lisp/source/arnesi/src/asdf.lisp
> ;; -*- lisp -*-
> (in-package :it.bese.arnesi)
> ;;;; * A clean-op for ASDF
> (defclass clean-op (asdf:operation)
> ((for-op :accessor for-op :initarg :for-op :initform 'asdf:compile-op))
> (:documentation "Removes any files generated by an asdf component."))
> (defmethod asdf:perform ((op clean-op) (c asdf:component))
> "Delete all the output files generated by the component C."
> (dolist (f (asdf:output-files (make-instance (for-op op)) c))
> (when (probe-file f)
> (delete-file f))))
> ..
> Is that something I would need *after* 1.88, or something already
> incorporated into it hence no longer needed?

If you need a clean-op, possibly. In lisp, code = data = code = data.

With make, arnesi would have written something like:

clean:
for file in $(OUTPUT_FILES) ; do \
if [ -r $$file ] ; then \
rm $$file ;\
fi ;\
done

in some makefile. That is, they would have provided data to make.
But since in lisp, code = data = code = data, instead of providing data
in some strange format to lisp tools, you just provide code. This is
easier and more powerful, and can be done without a question raised
since asdf is to be used by _programmers_. Are you a programmer?

>> That said, asdf.lisp is about 40 KB, I wouldn't hesitate to keep
>> my own copy in case of version differential or whatever.
>
> On both FreeBSD systems, asdf apparently isn't on system disk, so
> I'll need to have my own private copy. On Ubuntu, please advise
> which of the various versions I should use, and why that short file
> is present.

Why would you do differently on ubuntu than on FreeBSD. Since you will
have to provide your own version anyways, it will work the same on
ubuntu. Why make a special case? Are you a user or what?


>> There's nothing to do to install asdf. Just load the asdf.lisp file.
>
> Don't I also need to somehow set up a table of which directories
> should be in my ASDF search path? Or does the regular Unix/Linux
> search path suffice? SInce the regular Unix/Linux search path is
> for executables (binaries), not for ASDF libraries, I would think
> I'd need a separate table of directories that might have ASDF
> libraries to search.

Ah, but this is not installation anymore, it's configuration. Shall we
answer a configuration question in a thead about installation?

>> > The single file asdf.lisp is all you need to use asdf normally. Once
>> > you load it in a running Lisp, you're ready to use asdf.
>> > Is that really correct??
>> How many times do we need to tell?
>
> See my question above about setting up where to search for ASDF libraries.

There is a default setting of the variable asdf:*central-registry*.

For example, if you have an asdf system such as:

/home/rem/src/split-sequence/split-sequence.asd

you can write:

(pushnew #P"/home/rem/src/split-sequence/" asdf:*central-registry*
:test (function equal))

to be able to do:

(asdf:oos 'asdf:load-op :split-sequence)

Or you can use a little function such as:

http://paste.lisp.org/display/49261

to fill asdf:*central-registry* with all the directories in a subtree
where .asd files lie.

(There's another way, using so called "symbolic links", but I cannot
find this notion in CLHS...)

--
__Pascal Bourguignon__

Raymond Toy

unread,
Jan 12, 2009, 9:27:15 AM1/12/09
to
>>>>> "Robert" == Robert Maas <seeWeb...@teh.intarweb.org> writes:

Robert> The cclan version of asdf apparently doesn't have the necessary code
Robert> to hook REQUIRE into CMUCL. So here is a small bit of code to make it
Robert> so. You need at least cmucl 19a with patch 0 for this to work.

Robert> When I start up CMUCL here, it says:
Robert> CMU Common Lisp 18b, running on shell.rawbw.com
Robert> So does anybody know whether if I go to the trouble of downloading
Robert> and installing ASDF here, it'll even be possible for it to work
Robert> here?? Does anybody know how to make ASDF work here? Or should I
Robert> just dismiss ASDF as something that can't possibly work here and
Robert> is not worth any further bother on my part?


If you want to have asdf hook into REQUIRE with CMUCL, I can provide
the nessary changes. You need the bit of code from cliki.net, and you
need the changes from 19a to run with 18b. I'm pretty sure the
changes are quite simple and should run on 18b.

Ray

Thomas A. Russ

unread,
Jan 13, 2009, 6:27:13 PM1/13/09
to

FIND would be better still. It returns the element you are looking for
rather than its position.

--
Thomas A. Russ, USC/Information Sciences Institute

budden

unread,
Jan 14, 2009, 3:01:39 PM1/14/09
to
Hi all!
Two more questions, in case someone knows:
i) how do I tell asdf that I do not want to compile one particular
file in system?
ii) most interesting applications are not mere libraries. User usually
wants loads them (if sources have changed) and then runs. Think of
"Run" command in any modern developer's IDE (Visual Studio,
Delphi, ...).
Is there a way to define some "run-op" which will invoke build and
then some predefined startup (even if build was not required).

I'm sure both questions have multiple answers. I'm looking for the
elegant ones.

budden

unread,
Jan 14, 2009, 3:06:46 PM1/14/09
to
ooops,

> i) how do I tell asdf that I do not want to compile one particular
> file in system?
I mean I do not want to compile it - I just want to load source. No
compilation.
For this particular file. And compile all the rest prior to load.

budden

unread,
Jan 14, 2009, 3:27:54 PM1/14/09
to
And one more question:
How do I define a method on component? I've grepped on my clbuild dir
and found only

(defmethod perform ((o asdf:test-op) (c (eql (find-
system :weblocks))))

and

(defmethod perform ((o load-op) (c elephant-c-source))

No definition of methods on separate components is found. Is there a
way to create one?

Robert Maas, http://tinyurl.com/uh3t

unread,
Mar 7, 2009, 1:47:57 PM3/7/09
to
Before I reply point-by-point, I'll condense what I said before:
/usr/share/common-lisp/source/asdf/asdf.lisp = 39639
/usr/share/sbcl-common/contrib/asdf/asdf.lisp = 44714
/home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp = 44714

diff /usr/share/common-lisp/source/asdf/asdf.lisp
/usr/share/sbcl-common/contrib/asdf/asdf.lisp | more
< ;;; This is asdf: Another System Definition Facility. $Revision: 1.88 $
---
> ;;; This is asdf: Another System Definition Facility. 1.87
Condensing further:
/usr/share/common-lisp/source/asdf/asdf.lisp = 39639 = 1.88
/usr/share/sbcl-common/contrib/asdf/asdf.lisp = 44714 = 1.87
Now citing my typo:

Curious that the shorter version, of which there's only one copy,
is actually the older version.
xxxxx
Should read "newer", sorry for the typo and resultant confusion.


Now on to my point-by-point reply/followup:

> From: p...@informatimago.com (Pascal J. Bourguignon)

seeWebInst...@teh.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
writes:

> rem@teh:~$ locate asdf.lisp
> /home/jpw/old-src/sbcl/contrib/asdf/asdf.lisp
> /usr/share/common-lisp/source/arnesi/src/asdf.lisp
> /usr/share/common-lisp/source/asdf/asdf.lisp
> /usr/share/sbcl-common/contrib/asdf/asdf.lisp
> Four different versions, comparing sizes:

So you can see that this jpw user has his own copy, and SBCL too, beside
the original source /usr/share/common-lisp/source/asdf/asdf.lisp


> > Curious that the shorter version, of which there's only one copy,

> > is actually the <del>older</del>
> > <em>newer</em> version.


> Not at all. Usually code grows. It's rare a programmer who can add
> features or remove bug by removing code.

But in this case the newer version is shorter, which is the point I
was trying to remark about, modulo my typo, which you didn't catch,
sorry for leading your astray.

> > Is there any utility on Ubuntu Linux that is like 'diff' but ignores
> > the difference in white space?
> man diff
> Look, it's not difficult. On unix, before using ANY command, you
> should just type: man THE_COMAND and read carefully the page mage
> of the command.

I already did read those fucking-extraverbose man pages several
times, each time spending a half hour or hour or even two hours
scrolling past thousands of useless (to me) options, to the point
where I forgot what I was looking for in the first place. I learned
from experience that most of the time if I've been using a
particular command thousands of times over more than fifteen years,
it doesn't really pay to read those fucking-extraverbose man pages
yet one more time if I don't remember seeing what I need any
previous time I spend hours scrolling them and becoming too
exhausted to go on living. Documentation ought to make it easy to
find the essential stuff and see the bulk of rarely-useful stuff
organized nicely enough to get an overview of it to where you know
where to look if and when you ever need one of those arcane modes.
Much of the time half of those hundreds of options are only for
compatibility with some really obsolete version of the program that
existed at UCB more than thirty years ago, needed *only* for
automated scripts written more than twenty years ago that relied on
those obsolete modes scripts that are so arcane in their syntax
that nobody is capable of fixing them to *not* use the arcane
obsolete mode they depend on.

So as long as you're jumping down my throat for my failure to wade
my way through those illegible 'man' pages for 'diff' once again,
starting more than three hours past my bedtime, at 1:43, I'll give
it a royal try...

-E --ignore-tab-expansion
Ignore changes due to tab expansion.
(doesn't ignore *all* white space, but might do what I need in this
special case where tab expansion might be why the newer version is
smaller)

-b --ignore-space-change
Ignore changes in the amount of white space.
(might be what I asked for)

-w --ignore-all-space
Ignore all white space.
(might be over-kill, but might be needed, not sure)

-B --ignore-blank-lines
Ignore changes whose lines are all blank.
(I might want this too, not sure)

-t --expand-tabs
Expand tabs to spaces in output.
(I probably need this to avoid problem of host and recipient
counting tabs as different sizes.)

-d --minimal
Try hard to find a smaller set of changes.
(I might need this too)

--speed-large-files
Assume large files and many scattered small changes.
(I don't know whether to use this or not)

The full documentation for diff is maintained as a Texinfo manual. If
the info and diff programs are properly installed at your site, the
command
info diff
should give you access to the complete manual.
(It's now 1:52. Should I 'info diff' or not??)

Ok, now it's sitting at:
Manual page diff(1) line 195/219 (END)
and when I press space to continue off the end it just beeps at me.
Do I need to press control-C to abort the 'man' program on Ubuntu
Linux, or is there some clean way to exit it? I think I need to
control-Z to suspend 'man diff' and now do 'man man' to get
instructions how to gracefully exit the program when it reaches the
end of the document. It's now 1:55...
OK, I've scrolled all the way to the end of 'man man', and I don't
see any mention whatsoever of the commands used to navigate
scrolling, such as space to see another window or return to see
just one more line. At 2:01, I'm sitting at:
Manual page man(1) line 527/551 (END)
and have no idea how to gracefully get out of either 'man diff' or
'man man'. Let me see if the 'h' command gives me help about
scrolling commands, as it does when running 'more'...

SUMMARY OF LESS COMMANDS
Commands marked with * may be preceded by a number, N.
Notes in parentheses indicate the behavior if N is given.
h H Display this help.
q :q Q :Q ZZ Exit.
ESC-SPACE * Forward one window, but don't stop at end-of-file.
HELP -- Press RETURN for more, or q when done
LINE EDITING
These keys can be used to edit text being entered
on the "command line" at the bottom of the screen.
Now at 2:06 I'm sitting at:
HELP -- END -- Press g to see it again, or q when done
I pressed 'q', now sitting at:
Manual page man(1) line 527/551 (END)
I pressed 'q' again, now sitting at:
rem@teh:~$
I typed 'fg', now sitting at:
Manual page diff(1) line 195/219 (END)
I pressed 'q' again, now sitting at:
rem@teh:~$

rem@teh:~$ diff -b /usr/share/common-lisp/source/asdf/asdf.lisp /usr/share/sbcl-common/contrib/asdf/asdf.lisp | more
1c1


< ;;; This is asdf: Another System Definition Facility. $Revision: 1.88 $
---
> ;;; This is asdf: Another System Definition Facility. 1.87

112c112


< (defvar *asdf-revision* (let* ((v "$Revision: 1.88 $")

---
> (defvar *asdf-revision* (let* ((v "1.87")

977c977
< (let ((name-hash (make-hash-table :test #'equal)))
---
> (let ((name-hash (make-hash-table :test #'equalp)))
rem@teh:~$

Hmm, they went to all the trouble of issuing a new minor version
number, just to fix the pretty-print indentation on that (let ...,
and change equal to equalp (I almost missed that because the two
lines didn't "line up" because of change in indentation, so the
change didn't pop out at me when eyeballing the two lines in
parallel), and in the process they made massive changes in white
space due to tab optimization?? I'll need to look at the two files
separately (in emacs) to see whether they fixed the indentation
that had been wrong before, or *broke* it in the process of
manually adding the letter "p" to "equal"...

rem@teh:~$ emacs /usr/share/common-lisp/source/asdf/asdf.lisp /usr/share/sbcl-common/contrib/asdf/asdf.lisp
C-U 976 C-N
takes me to a line (same in each file), that says:
(let ((*serial-depends-on* nil))
How come the line-number given by 'diff' isn't the same as one more
than the number of C-N commands needed to get there? Is it because
the stupid version of EMACS on Ubuntu counts wrapped lines as MORE
THAN ONE LINE, where C-N goes into position-plus-80 in the SAME
LINE instead of moving to next line? I'll have to go back to the
top and try incremental-search instead, hoping that there aren't a
lot of lines that look the same in different parts of the file...
There's only one line (same in each file) like that:
;; check for duplicate names
(let ((name-hash (make-hash-table :test #'equal)))
Both are indented the same, so 'diff' is lying when it shows
different indentation. Or the prefix at the left of the line
added by 'diff' is screwing tab alignment, Let me try again:

rem@teh:~$ diff -b -t /usr/share/common-lisp/source/asdf/asdf.lisp /usr/share/sbcl-common/contrib/asdf/asdf.lisp | more
1c1


< ;;; This is asdf: Another System Definition Facility. $Revision: 1.88 $
---
> ;;; This is asdf: Another System Definition Facility. 1.87

112c112


< (defvar *asdf-revision* (let* ((v "$Revision: 1.88 $")

---
> (defvar *asdf-revision* (let* ((v "1.87")

977c977
< (let ((name-hash (make-hash-table :test #'equal)))
---
> (let ((name-hash (make-hash-table :test #'equalp)))
rem@teh:~$

Aha, no change in indentation, just the < or > added by 'diff'
caused tab to end up 8 from very left margin instead of 8 from
start of line from file. But -t makes it generate 8 spaces, so it
shows as 8 from start of line from file. So they didn't fix any
indentation, merely converted it to tabs instead of spaces, so that
diff without the -t option would give a misleading report.
It's now 2:27, and I really should go to bed now, before finishing
the rest of this followup.

It's now 9:48, and I'm awake and resuming my reply now:

[snip discussion of makefile vs. lisp]


> This is easier and more powerful, and can be done without a
> question raised since asdf is to be used by _programmers_. Are
> you a programmer?

I'm a multi-facited human being, not a one-trick pony. I conceive
new tools that would help people, then figure out a way to get them
built, then build them, then use them. "programmer" is a tiny part
of that "build them" step in the sequence. At the moment I have so
many conceptions for new tools but so little time/energy to get
them all done that I really could use a team of at least ten others
to do most of the work as I manage the group, but I have no money
to pay any of those helpers, but maybe with so many good people
unemployed they'd be willing to join my new "cooperative" (barter)
economy. <tinyurl.com/neweco>

> >> That said, asdf.lisp is about 40 KB, I wouldn't hesitate to keep
> >> my own copy in case of version differential or whatever.
> > On both FreeBSD systems, asdf apparently isn't on system disk, so
> > I'll need to have my own private copy. On Ubuntu, please advise
> > which of the various versions I should use, and why that short file
> > is present.
> Why would you do differently on ubuntu than on FreeBSD. Since
> you will have to provide your own version anyways, it will work the
> same on ubuntu. Why make a special case? Are you a user or what?

I don't understand why, on Ubuntu where asdf already is on system
disk, I need to provide my own version in addition. Why can't I
just use the system-supplied version?

> >> There's nothing to do to install asdf. Just load the asdf.lisp file.
> > Don't I also need to somehow set up a table of which directories
> > should be in my ASDF search path? Or does the regular Unix/Linux

> > search path suffice? Since the regular Unix/Linux search path is


> > for executables (binaries), not for ASDF libraries, I would think
> > I'd need a separate table of directories that might have ASDF
> > libraries to search.
> Ah, but this is not installation anymore, it's configuration.
> Shall we answer a configuration question in a thead about installation?

Oh, OK, so you're a one-trick pony that can only answer questions
about installation, and to get you to answer any question about
configuration I need to knock on another door to find you in
another room wearing a different hat and being a different person?

> >> > The single file asdf.lisp is all you need to use asdf normally. Once
> >> > you load it in a running Lisp, you're ready to use asdf.
> >> > Is that really correct??
> >> How many times do we need to tell?
> > See my question above about setting up where to search for ASDF libraries.
> There is a default setting of the variable asdf:*central-registry*.
> For example, if you have an asdf system such as:
> /home/rem/src/split-sequence/split-sequence.asd
> you can write:
> (pushnew #P"/home/rem/src/split-sequence/" asdf:*central-registry*
> :test (function equal))

Oh, so asdf:*central-registry* is just a list of filesystem-directories
where individul asdf systems might be found, OK.

> to be able to do:
> (asdf:oos 'asdf:load-op :split-sequence)

Doing a Google search for asdf:oos to see if I can find its formal
definition so that I can understand what I'd be doing by that line
of code. I'm guessing asdf:oos means Object-Oriented Services, but
so-far the Google search isn't turning up the definition of the
abbreviation. Instead I've found:
<http://smuglispweeny.blogspot.com/2008/12/beginners-guide-to-asdf-ha.html>
Pascal Bourguignon said...
The syntax is "insane" because it shows the entrails of ASDF.
ASDF is like C6PO when he met R2D2 the first time.
The problem is not with ASDF, it's with the users. There are so
many of them, it's impossible to make friend with all of them.
So every user has to define his own userfriendly interface to
ASDF (and ASDF-INSTALL).
For me, it's two functions, ASDF-INSTALL and ASDF-LOAD. For
somebody else, it could be some button in a slime buffer, or a
CAPI window. Who knows?
In a way it's no different from Java's java.lang.System.out.println("Hello world");
which exposes the following facts:
- Essentially-supplied Java includes the core-language package.
- The core-language package contains a Class called 'System'.
- The 'System' class contains a pre-defined (static) object called 'out'.
- The 'out' object can be used with the 'System' instance method 'print'.
- The System 'print' instance-method can take a string as a parameter.
Since the "java.lang" is already included by default, you can just say
System.out.println("Hello world");
which hides the first two facts, replacing them by the more generic fact:
- Essentially-supplied Java somehow contains a Class called 'System'.

So here's what I'm guessing that
(asdf:oos 'asdf:load-op :split-sequence) reveals?
- ASDF, when installed, contains a general-purpose utility called 'oos'.
- The 'oos' utility can take a command symbol followed by a keyword.
-- The command can be 'load-op', which apparently means "load
operator", which really means "load function" in this case, or
maybe "load macro" in other cases, which is why it's given the
generic name "load operator" instead more specifically "load
function", to avoid being a misnomer in the case of loading a
macro, or even worse requring the user to know whether
something is a function or a macro a priori and use a different
command in the two cases.
-- In such case, the keyword is the name of the function (or macro)
to load, where a keyword is used to avoid pre-judging what
package it might actually be in.
Did I do a good job of breaking down the knowledge into smaller
units, each explicitly stated? <SOT>Many years ago there were job
openings for people to do this kind of work, for the purpose of
developing a huge database of "world knowledge" for use by a
computer system that understood the deep meaning of natural
language. I thought I'd be good at that kind of work, so I applied
for the job, but I never even got a reply much less an interview. I
have no idea why I didn't get the job, because I do believe I'd be
good at that kind of (top-down) *analysis* (factoring) of
knowledge, both for that world-knowledge project, and for tutoring
beginners at 'deep' topics such as computer programming.</SOT>

Robert said...
I have to respectfully disagree with Pascal here. I have never
understood why it has been such an issue of faith that it is up
to the users to define their own friendly interface on top of
ASDF:OOS. Who would it hurt if we were to simply add
ASDF:LOAD-SYSTEM, ASDF:COMPILE-SYSTEM, and ASDF:TEST-SYSTEM?
How would the existence of ASDF:LOAD-SYSTEM interfere with your
use of, or preference for ASDF-LOAD? How would it keep the
SLIME folks from introducing a button? Offering a facility
doesn't seem to me to preclude someone else offering the same
facility?
It's all about lowering the barrier to the first use of ASDF.
I didn't write that! I'm sure, because it isn't my wording.
Clicking on the link to see the blogger profile, I see "On Blogger
Since July 2002", then clicking on the XML link at the top, I see
only a dummy <email>nor...@blogger.com</email>. I wonder why that
other "Robert" wants to be so anonymous? <humor>Maybe he's the
leader of Zimbabwe and doesn't want to tarnish his "bad boy"
reputation?</humor>

<VOT>IMO s-expressions are optimal for specifying strictly-nested
structures, whereas SGML is optimal for turning orthogonal modes on
and off in a non-nested way, the old "tag soup" methodology.
For example: <b>I <color "green">say:</b> Hello</color> world!
The first word is bold but default color, second is bold-green,
third is green but not bold, and fourth is normal in all aspects.
To get that effect with strictly nested SGML tags would be painful,
either duplicating bold both inside and outside the toplevel color-green:
<b>I</b> <color "green"><b>say:</b> Hello</color> world!
or duplicating color-green both inside and outside the toplevel bold:
<b>I <color "green">say:</color></b> <color "green">Hello</color> world!
I wonder how MicroSoft Word handles it if you overlap regions of
orthogonal text properties in a non-nested way?</VOT>

Kenny Tilton said...
... ":serial t" is no option
because it forces everything after a file changed to be
recompiled. ...
Hmm, it occurs to me that there are *different* kinds of dependencies:
-1- Module A must be loaded into the compiler environment, to
define macros used by the source for module B, before module B
will compile correctly.
-2- Module A must be loaded into the runtime environment, to define
constants and parameters used by DEFPARAMETERs within module
B, before those DEFPARAMETERs within module B can be executed
correclty during loading of module B.
-3- Functions within module B call functions within module A, thus
module A must be loaded before those particular functions in
module B will run correctly, but it's fine to load module A
after loading module B if neither of the earlier types of
dependencies are also in fact.
-*- With CLOS there may be other kinds of dependencies related
to class hierarchy or methods defined etc.
Note that if module A is changed, module B needs to be recompiled
only if dependency type -1- is present, and in fact only if one of
the specific macros defined in A and needed for compiling parts of
B was redefined to generate new code-to-compile. Otherwise, even if
a macro was re-defined to be more efficient at generating exactly
the *same* code-to-compile, module B needn't be re-compiled. How
subtly can ASDF distinguish these various reasons for needing to
recompile and thereby avoid needless recompilations? Semi-ideally
ASDF should contain a source-code-walker utility that at least
checks which specific macros within one module are used to generate
code to compile within another module, and also source-code control
to detect precisely which macros got re-defined during a series of
edits, thus determine whether an edit of module A really did change
a macro needed by B hence possibly requiring module B to be
recompiled "just in case" the newly-edited macro might generate new
code-to-compile compared to before the edit. (Actually analyzing
old and new macro definitions to determine whether new
code-to-compile might be generated in any case ever, even moreso
determining whether the specific call to the macro within module B
would result in functionally different code being compiled, is
probably NP hard or even Turing non-halting.) But at the very least
I'd expect ASDF to distinguish the three (or more) generic types of
source dependencies, to avoid re-compiling B just because A changed
when all B ever does is call *functions* (not macros) within A.

So I ask some ASDF expert now: Where does ASDF fall along my
spectrum of more-or-less-carefully distinguishing when module B
does or does not need recompiling after module A was changed?

<http://xach.livejournal.com/191187.html>
... below is a file I've been loading from
my init files to get consistent, concise ASDF loading across
implementations. It also adds a crude registry maintenance system and
a way to reload a system without using :FORCE. :FORCE has the downside
of recompiling and reloading all other dependencies, which is never
what I want.
It's a work in progress, but so far I've been pretty happy using
(asdf:load* 'mysystem) and (asdf:reload 'mysystem). YMMV.
Question to experienced ASDF users: Is this something I might
eventually want to use, to assure consistency between CMUCL on
FreeBSD Unix and CLISP on Ubuntu Linux?

Continuing to look at Google search results, nothing worth reading
in rest of first ten results, nothing at all in second ten, one
curious item in third ten:
<http://boinkor.net/archives/2007/01/explaining_some_features_of_as.html>
(defsystem foo
:components ((:file "a")))
(defsystem bar
:depends-on (:foo)
:components ((:file "b")))
Suppose that file "a" in system FOO changes; if you load system BAR,
file "a" will be recompiled; but file "b" will not! If file "b" uses a
macro from file "a", you will load the old version of that macro from
FASLs, and things will break. Ow.
Does this mean ASDF is really crappy in this respect?

XREF is a mechanism provided by many CL implementations which allows
queries like who-calls and who-macroexpands. who-macroexpands would
cover a good part of compile-time dependencies,
Aha, this is the -1- type of dependencies I discussed earlier.
but there are many more types of compile-time dependencies! For example:
* Definition of a method that uses a class defined in another file
* Definition of a package that uses another package
* Use of a symbol interned in a package defined in another file
* Calling (at compile or load time) a function defined in another
file
* many more...
And this gets into the -*- types of dependencies I was evading earlier.
Since 99.99% of the time in my own work I don't use either macros
or CLOS, this kind of problem is just a curiosity for me at this
time, except for symbols defined in another module (A) and exported
from it and then either fully-qualified at each call or imported
into the current module (B). Maybe the workaround, given that I use
long names for functions, is when exporting a symbol from a
particular module, to always import it into lisp-user, so then no
special treatment is needed. Of course this somewhat defeats the
whole idea of packages in CL, but if I do this *only* for toplevel
API functions defined in each module, and keep all inner functions
"secret", that would be a reasonable compromise?

Question to all expert users of ASDF: Is use of exported symbol a
major problem when auto-rebuilding dependencies based on what
changed? Is there any other major problem in the general field of
dependencies?

Nothing at all worth reading in 4th group of ten Google search
results, maybe time to give up and try reading source for ASDF to
see if it gives a clue what OOS means. But first I need to suspend
this task, at 14:16, to work on something more urgent.

Ouch! I got really busy with other tasks, and several days went by
before I found time to finish replying here. Sorry!!

(Splitting long reply here.)

Robert Maas, http://tinyurl.com/uh3t

unread,
Mar 7, 2009, 1:56:35 PM3/7/09
to
(Part 2 of too-long article after split:)

> Or you can use a little function such as:
> http://paste.lisp.org/display/49261

OK, I looked at that just now, and while the function names are
somewhat self-explanatory, there's no accompanying inline
documentation, neither ;;comments at the top nor before each
function, nor docstrings in the DEFUNs, so I have no idea what is
required before calling these functions, why I would want to call
them, or what precisely they do. No, telling me to read the code to
see what they do is totally unacceptable.


The code I write is fully inline-documented, for example, here's
what's at the top of my 2005-7-mbbt.lisp:

;Moderately-Balanced Binary Tree: The total number of nodes in the two
; branches, at each level, is never allowed to get worse than 3:1 or 2:0
;This is not as strict as an AVL tree, so it gets somewhat more unbalanced,
; but performs major rebalancing much less often. This implements a sorted
; TreeMap. To implement a sorted set, use NIL as val in all cases. It wastes
; some storage for every node to contain one dunzell standard-pair,
; but it saves writing a lot of almost duplicate software.
;<EmptyPair> = (:PAIR . NIL) ;[sic] not really a pair yet
;<GoodPair> = (:PAIR key . val) ;Key field is immutable, value mutable
;<Tree> = (:MBBT 0 . <EmptyPair>) = (:MBBT 0 :PAIR) ;empty/null/dummy
; | (:MBBT 1 . <GoodPair>) ;leaf
; | (:MBBT <Total> <GoodPair> <Tree> <Tree>) ;fork
;Note: Per the BNF above, NIL would be a valid key. A GoodPair with NIL
; as the key is distinguished from an EmptyPair because NIL is car of stdpair
; which isn't present for EmptyPair. However in the code below the key must
; always be integer and sorting predicate is always #'< and equality predicate
; is always #'=, whereby NIL wouldn't be allowed as a key. A variation of
; this module might use different sorting/equality predicates whereby NIL
; could be a valid key, sharing whatever code below doesn't involve those
; operators.
;Note that during the transition between: leaf <-> fork,
; both the count and the basic structure must be changed,
; hence at the halfway point the two are inconsistent.
;At such times, it's the structure, not the count, which determines access means.
;The structure is changed first, then the count is recomputed and updatedInPlace.
;Hence mbbt-tree-is-leaf and mbbt-tree-is-fork test the structure, not the count.

;If you are going to be adding large consecutive blocks that share all
; the same value (or for a TreeSet where there's no value associated with
; a key), this is not appropriate because it takes a long time to add all the
; individual nodes one by one, and it wastes space to have so many nodes.
; Instead, use a derived type that stores intervals of keys instead of
; individual keys per node.

;Major change 2007.May.08-10: Node-update function no longer fixed, now
; parameterized via fluid variable, so that other node-update policies
; can be used for derived classes such as MBBT-interval+length (mbbtil).


In the same file, a few samples of inline documentation before
individual functions:

;This makes an empty tree or sub-tree.
; This is to avoid having to wait until the first element is available
; before building the framework for the tree, so you can save the
; toplevel handle which will never change for any given tree, so copies
; of the original handle will always be valid. Note: It's a bad idea to
; make copies of handles of sub-trees then attempt to modify those sub-trees,
; because if you do that, the total-count-of-subtree won't propagate into
; totals at higher levels in main tree.
(defun mbbt-new ()
(list :MBBT 0 :PAIR)) ;I.e. (:MBBT 0 . <EmptyNode>) = (:MBBT 0 :PAIR)

;Are we looking at the very top level of a MBBT object here?
(defun mbbt-is-tree (mbbt)
(eql :MBBT (car mbbt)))
;MBBT must be a leaf node, and we want to delete the only key present,
; which will convert this to an empty (null) tree.
;As usual, we return values: deletedKey deletedVal
(defun mbbt-leaf-delete-only (mbbt)
...)

;Find node with key exactly = the probe.
;If such exists, return entire <GoodPair> object, i.e. (:PAIR key . value)
;Otherwise return NIL.
(defun mbbt-find-exact= (mbbt probe)
...)

;Find node with nearest key leq the probe.
;If such exists, return entire <GoodPair> object, i.e. (:PAIR key . value)
;If probe is leftward of leftmost node in tree, return :LEFTWARD
(defun mbbt-find-nearest-leq (mbbt probe)
...)


> to fill asdf:*central-registry* with all the directories in a
> subtree where .asd files lie.

IMO This comment should be included in the online repository, and
it should be fleshed out better, to say what set-up is required
before you can do this, and fully explain any consequences it may
have. For example, does it destructively modify some existing
structure in the Lisp environment, or does it build a complete copy
then SETQ the result at the last moment, or does it
non-destructively build a new structure sharing parts with the old
structure, or what? No, each person considering using this code
shouldn't have to read the code and figure this all out
him/herself. The person who wrote and posted the code should have
had this in mind from the start and posted it up front with the
code, or somebody else "adopting" the code should do this once,
before the code can be considered "ready for prime time".

If I were already intimately familiar with ASDF, I might undertake
the task of "adopting" this code. But as an absolute beginner who
has never used ASDF even once, I'm very likely to miss most of the
consequences of the code if I try to read the code to figure out
what it really does. I wouldn't want my very first use of ASDF to
include downloading a piece of code I don't understand and which
isn't fully documented as to what I should expect to happen when I
use it. Thanks for showing me the link, but I'll pass on using it.

Thomas Stenhaug

unread,
Mar 7, 2009, 5:52:39 PM3/7/09
to

[Pascal J. Bourguignon]

| [...] man THE_COMAND and read carefully the page mage
| of the command.

[Robert Maas]

| I already did read those fucking-extraverbose man pages several times,

| each time spending a half hour or hour or even two hours [...]

You might be better off reading them less carefully. I'm often helped
by cheap-and-cheerful approaches, like

$ diff --version | head -n 1
diff (GNU diffutils) 2.8.1

$ diff --help | grep white


-b --ignore-space-change Ignore changes in the amount of white space.

-w --ignore-all-space Ignore all white space.

at least for the first pass.

I think it's reasonable to think of `find' as the general Unix user
interface for operating on the filesystem-graph, and as such worth
spending a little time learning.

find --help

yields a dense overview, at least with a recent GNU findutils. Also,
the top 4 Google results for "find tutorial" are tutorials for `find'.

You'll find that most commands yield useful output when you pass --help.

| Ok, now it's sitting at:
| Manual page diff(1) line 195/219 (END)
| and when I press space to continue off the end it just beeps at me.
| Do I need to press control-C to abort the 'man' program on Ubuntu

Nowadays it's reasonable to assume that the default pager is `less'
(instead of `more'). `man' takes care of rendering the page, and punts
to `less' for paging. Press `q' to quit, press `h' to see a help-page,
press `/' to search forward for a regex-match, press `g' to jump to the
first line. Piping long output to `less' for paging long outputs from
grep, locate etc. is useful.

There's a recent-Linux-distribution survival-kit for you; --help,
option, grep, find, locate, man and less.

| How come the line-number given by 'diff' isn't the same as one more
| than the number of C-N commands needed to get there? Is it because
| the stupid version of EMACS on Ubuntu counts wrapped lines as MORE

| THAN ONE LINE [...]

That sounds highly unlikely. Besides, you can probably get the
display behaviour you want by putting "(setq selective-display-ellipses
t)" in your .emacs.

Since you're already in Emacs, it's convenient to do `M-x diff RET'
insteading of dropping to a shell. Other useful commands to avoid
dropping to a shell in Emacs are `dired', `locate', `grep', `find',
`find-grep' and `man'. They invoke the corresponpinding Linux commands
for you, and provides helpful behaviour for operating on the output.
For example, `RET' on a line in a diff-buffer will take you to the
corresponding line in the source file, `RET' on a line in a grep buffer
will take you to the corresponding location in the source file etc.

| I don't understand why, on Ubuntu where asdf already is on system
| disk, I need to provide my own version in addition. Why can't I
| just use the system-supplied version?

Why can't you? (load "/path/to/asdf.lisp") ?

| I'm guessing asdf:oos means Object-Oriented Services, but
| so-far the Google search isn't turning up the definition of the
| abbreviation.

CL-USER> (load #p"/home/thomas/lib/cl/asdf.lisp")
T
CL-USER> (documentation 'asdf:oos 'function)
"Short for _operate on system_ and an alias for the `operate` function.
Operate does three things:

1. It creates an instance of `operation-class` using any keyword parameters
as initargs.
2. It finds the asdf-system specified by `system` (possibly loading
it from disk).
3. It then calls `traverse` with the operation and system as arguments

The traverse operation is wrapped in `with-compilation-unit` and error
handling code. If a `version` argument is supplied, then operate also
ensures that the system found satisfies it using the `version-satisfies`
method."

An alternative to ASDF is Sean Ross' Mudballs <http://mudballs.com/>

| Many years ago there were job openings for people to do this kind of
| work, for the purpose of developing a huge database of "world
| knowledge" for use by a computer system that understood the deep
| meaning of natural language.

Today the "semantic web" is all the rage. Or, maybe it was last week.
<http://en.wikipedia.org/wiki/Semantic_Web>

| IMO s-expressions are optimal for specifying strictly-nested
| structures, whereas SGML is optimal for turning orthogonal modes on
| and off in a non-nested way, the old "tag soup" methodology.

Related topic at <http://www.cliki.net/HTML-from-sexpr>. Marking up
with sexprs offers paren-matching instead of tag-balancing, structural
editing with familiar Emacs commands, less verbosity, easy manipulation
by means of CL, easy to spit out whatever-format from.

| I wonder how MicroSoft Word fhandles it [...]

It's "Microsoft", I believe.

| [about ASDF dependency-detection/resolving]

<http://www.cliki.net/asdf-dependency-grovel> is useful, and
<http://common-lisp.net/project/xcvb/> is in the works.

ASDF/ASDF-INSTALL works just fine for downloading, installing, compiling
and loading an extensive set of libraries, though.

| Suppose that file "a" in system FOO changes; if you load system BAR,
| file "a" will be recompiled; but file "b" will not! If file "b" uses a
| macro from file "a", you will load the old version of that macro from
| FASLs, and things will break. Ow.

| Does this mean ASDF is really crappy in this respect?

This has bitten me often enough that I have written tools for clearing
relevant fasls. On the other hand, I've become better at getting my
macros right quickly. :)

--
Thomas

Robert Maas, http://tinyurl.com/uh3t

unread,
Mar 12, 2009, 3:16:31 AM3/12/09
to
> From: D Herring <dherr...@at.tentpost.dot.com>

> (find-package :asdf)
> BSD server - nil
> linux home - nil
> => ASDF isn't preloaded (e.g. by an init file) on either system...

OK, except that on Ubuntu Linux it returns #<PACKAGE ASDF>

FreeBSD:


> > * (require :asdf)
> > (long pause, appx. 20 seconds)
> > "modules:asdf" does not exist.

Ubuntu Linux:


> > rem@teh:~$ sbcl
> > This is SBCL 0.9.8.8, an implementation of ANSI Common Lisp.

> > ...


> > * (find-package "ASDF")
> > NIL

;Note the difference between using a string and a keyword.
;Is this important to study?

> > * (require :asdf)
> > appx. 3 second pause
> > ("ASDF")
> > so does that mean it loaded it from one of those three files I
> > found earlier via the 'locate asdf.lisp' command?
> Yes, ASDF is available on your desktop, but apparently not on the server.

That makes no sense to me. This is a Linux shell account.
There's neither a desktop nor server involved AFAIK, except for the
SSH server that I use to connect into my login/shell account.

> >> - Otherwise, upload ASDF.lisp to your server.
> > UPLOAD??? From what, my VT100 emulator? Do you perhaps mean DOWNLOAD??
> > To what server???? Why do I need to run a server before I can use ASDF??
> > Do you perhaps mean download TO SOMEWHERE WITHIN MY PERSONAL
> > DIRECTORY TREE ON MY SHELL ACCOUNT?
> Somehow I though you were running lisp on a webserver

Do you mean like running a CGI application, where the files are on
my Unix or Linux account, fully accessible from my shell account,
only executable from the Web via CGI? Or are you talking about
something entirely different that I can't even guess?

At this stage, I am nowhere near packaging an application to run
under CGI. All these manual tests of CMUCL and SBCL are directly
from interactive shell.

> and had asdf.lisp on your personal desktop.

That makes no sense to me. I am about 30 miles away from the
FreeBSD computer, and about 6000 miles (California to UK) from the
Ubuntu Linux computer. It's physically impossible for me to have a
desktop on either computer.

> Upload = "from local to remote"... But now I see that you're
> doing this on two boxes to confuse me.

I'm not doing anything to confuse you. I'm sitting on a chair, with
keyboard on my lap, and mouse to the right on the TV table to the
side, facing a Macintosh Performa computer. The Macintosh connects
through a modem and phone line and another modem to a dialup server
which connects through a TELNET link to the new FreeBSD computer
(because the dialup to the old/current FreeBSD computer stopped
working a few weeks ago), logged in there, connected via SSH to the
old FreeBSD computer, logged in there, running 'screen', and inside
it running SSH to connect to Ubuntu Linux system in the UK, where
I'm logged in and running SBCL.

> Anyway, you need to get a copy of asdf.lisp on the BSD server.

Do you mean BSD *shell* machine?

> If that requires netcat, then more power to you.

I have no idea what "netcat" means. I'll try to find it on Google ...
<http://netcat.sourceforge.net/>
Netcat is a featured networking utility which reads and writes data
across network connections, using the TCP/IP protocol.
How is this different from using sockets directly from CMUCL? For
most connections between components in my proposed distributed
system for NewEco, I'll use HTTP somehow.
(On server end I'll use PHP or CGI/Lisp.
On client side, I'm not sure which method will be easiest to use.
Some really old CMUCL software ran lynx as a sub-process with PTY
link for controlling it, for connections that maintained sustained
sessions that required cookies. For tasks that didn't require any
sort of sustained session, I just invoked lynx with the -source
option with output diverted to file. I think PHP has something
built-in.)
For single-character-exchange protocols, such as per-character
exact-exchange, I'll open direct TELNET/TCP streams.

> >> Then
> >> (load "/path/to/asdf.lisp")
> >> (push #P"/path/to/*.asd" asdf:*central-registry*)
> > I'll wait until I get confirmation that you mis-wrote that above
> > about up/down load and where to.
> Since (require :asdf) works on your desktop,

I think you mean "shell", not "desktop", right?

> there's no reason to use an explicit load unless you intend on
> compiling ASDF (see below) or need a newer version.

Somebody said ASDF should *always* be compiled. I'm not sure whom to believe.

> The server will need to use either
> (load #P"/path/to/asdf.lisp")
> or
> (require :asdf #P"/path/to/asdf.lisp")
> I think REQUIRE, while "deprecated", is preferable to LOAD in
> this case; it can no-op when the file is already loaded.

What I've been doing with my own auto-load methodology is to check
whether a particular function is already defined, if not then load
the file and check to make sure the function did indeed get defined
by that load. From 2007-2-mayload.lisp:

;Given name (symbol) of needed function, and directory-shorthand + fn1
; where that function is defined:
;If function already defined, do nothing, else load source or compiled,
; whichever is latest, then make sure the function really got defined.
(defun funct+shortdir+fn1-mayload (funct shortdir fn1)
(prog (lastfile)
(when (fboundp funct) (return :ALREADY))
(setq lastfile (shortdir+fn1-which-more-recent shortdir fn1))
(load lastfile)
(when (fboundp funct) (return :LOADED))
(error "After loading ~S,~%function ~S still not defined" lastfile funct)
))

> On my system, it takes ~1.25s for sbcl to (load "asdf.lisp") and
> ~0.08s for sbcl to (load "asdf.fasl"). In normal use, that's not
> enough for me to care; but on a webserver, it may be a different story.

Yeah, since this will ultimately be running a major Web
application, where I bill users per number of seconds of
computer-realtime they consume, it would be totally wrong for me to
charge them a whole second just to load ASDF. So eventually I will
surely want ASDF compiled.

> Since you don't have write access to the directory containing
> asdf.lisp on the server, compile it with something like
> (compile-file #P"/path/to/asdf.lisp"
> :output-file #P"/path/to/asdf.fasl")
> Then load the compiled version using
> (load #P"/path/to/asdf.fasl")

Yeah, that makes sense. With my own personal code, I never needed
to compile to a different directory so I never checked if such a
capability existed. So thanks for the clue.

> On your webserver, is SBCL a persistent process, or is it started
> each time a CGI script runs?

All my current CGI/CL software is on the old shell account (circa
Belmont) that runs FreeBSD Unix, where I have CMUCL not SBCL. Any
CGI applications on the Ubuntu system are sometime in the future.
I'm not sure, but I believe both CMUCL and (future) SBCL would run
as ordinary CGI i.e. re-start on each server request. But since
executable files are memory-mapped when started, a rapid sequence
of successive CGI requests takes hardly any time to start each
because most/all of the pages are still in fast memory.

> If the latter, there are two tricks you might consider:
> - Use save-lisp-and-die to save everything into a single image

I'll have to check if that is available from CMUCL. If I do that,
it'll require version control so that whenever I change the source
and want the changed version to start up quickly I'll re-build the
executable. During development, to reduce the need for rebuilds,
I'll probably have to deal with patch files, where the old stable
version is insta-started then the patch file is loaded.

If and when I run CGI/SBCL code on Ubuntu Linux, then I should be
able to use the code you quoted.

> - Switch to clisp

That might not be available here.

Robert Maas, http://tinyurl.com/uh3t

unread,
Mar 12, 2009, 3:22:12 AM3/12/09
to
> From: Raymond Toy <raymond....@ericsson.com>

> If you want to have asdf hook into REQUIRE with CMUCL, I can provide
> the nessary changes. You need the bit of code from cliki.net, and you
> need the changes from 19a to run with 18b. I'm pretty sure the
> changes are quite simple and should run on 18b.

Thanks for the offer. I'll try to remember it when I get to the
point where I will need it.

Robert Maas, http://tinyurl.com/uh3t

unread,
Mar 12, 2009, 4:18:00 AM3/12/09
to
> >> For some lisps, it is better to
> >> (compile-file #P"/path/to/asdf.lisp") ; do this once
> > If it's on a system directory, where I don't have write access,
> > such as on the Ubuntu system, this can't succeed, right?
> From: Alberto Riva <ar...@nospam.ufl.edu>

> Yes, it can. See the :OUTPUT-FILE keyword argument to COMPILE-FILE.

But if each person compiles his/her own copy from the master source
on system directory, that would be a bit inefficient. What I meant
is that I can't compile a master version to be used by everyone
because I don't have root/admin priviledges.

On the other hand, better is the enemy of good enough, so maybe
each user compiling a private copy would be good enough as a start.
If the admin ever does an audit to discover tens of copies of
identical compiled-ASDF files, one per user who is using ASDF, then
the admin might decide it's time to make a single copy on the
system directory and link all the private versions to it to save
disk space and also to save page-map thrashing if several different
users all run CGI applications using *different* FASL files.
But for now, maybe it's not worth worrying about.

> And I would say that it is *always* better to compile asdf.lisp.

Should I trust that as good advice?

In general, anything super-stable ought to be compiled.
I guess ASDF falls into that category.
Is that what you meant?

Robert Maas, http://tinyurl.com/uh3t

unread,
Apr 30, 2009, 4:03:40 AM4/30/09
to
> From: Thomas Stenhaug <thomas.stenh...@gmail.com>

> [Pascal J. Bourguignon]
> | [...] man THE_COMAND and read carefully the page mage
> | of the command.

> [Robert Maas]
> | I already did read those fucking-extraverbose man pages several times,
> | each time spending a half hour or hour or even two hours [...]

> You might be better off reading them less carefully.

Perhaps. But when reading a new 'man' page for the first time, it's
hard to know which parts to skip and which to read, so I pretty
much need to at least browse *everything* in the entire 'man' page
to get a "feeling" for how the 'man' page is organized and how the
command structure is organized (such as major action commands
separate from minor mode commands separated from expert-only
commands separated from debug commands/modes), before *any* of the
listed commands make enough contextual sense to be safe to try
using the first time.


> I'm often helped by cheap-and-cheerful approaches, like
> $ diff --version | head -n 1
> diff (GNU diffutils) 2.8.1

How would somebody who has used the 'diff' program for many years
and has not the slightest idea it has an ignore-white-space
command, think of using that 'head' command piped from version
output?? I don't even know what the 'head' command does, and would
have to spend another half hour learning how to use it, even if
somebody told me the name "head" as something I might want to learn
about. Even then, why would I guess that piping diff to head would
do anything useful at all??

% man head
head [-n count | -c bytes] [file ...]
This filter displays the first count lines or bytes of each of the speci-
fied files, or of the standard input if no files are specified. If count
is omitted it defaults to 10.
IMO that isn't worth the trouble, except on printing terminal where
you want to avoid wasting paper and print-time. I just pipe through
more and the copy+paste the part I want from the top of the first
screen. Showing a whole screen instead of just one line gives me
useful feedback as to whether I am doing it right or not.

> $ diff --help | grep white
> -b --ignore-space-change Ignore changes in the amount of white space.
> -w --ignore-all-space Ignore all white space.

I didn't even know 'diff' had a --help option that would show some
kind of documentation. let me pipe it through 'more' instead of
'grep' to get a feeling for what the --help option really does: Oh,
that just prints out the "usage" error message, the same thing you
get from many Unix programs if you just type the program name
without any parameters, for programs where at least one parameter
is *required* for correct operation. But how would I even know
about --help option unless I first looked at the entire 'man diff'
page and happened to notice it somewhere there. But if I already
did that, carefully, spending a half hour I would already know how
to ignore white space, after which I had my answer and would quit
'man' and never see the --help option anyway.

> I think it's reasonable to think of `find' as the general Unix
> user interface for operating on the filesystem-graph, and as such
> worth spending a little time learning.

Hmm, let me see if it's mentionned in the book my boss gave me to
allow me to learn about Unix when we were porting or CAI-Calculus
program to IBM/Unix workstations ... it's by McGraw-Hill, called
"Introducing the Unix system", by Henry McGilton and Rachel Morgan,
ISBN 0-07-045001-3 ... page 549 (index), alphabetically consecutive
entries for "filters" (page 94), and then "finger command" (page
500), unless I'm getting my alphabetical order wrong, or that index
is missing an entry, 'find' isn't in that book, hence isn't a valid
Unix command that everybody should learn about, it's only some
advanced special-purpose command that nobody except experts should
ever learn about, and only if somebody happens to tell them such a
command even exists, or if they're some sort of extreme nerd who
insists on learning *every* file in the entire FreeBSD
distribution.

> You'll find that most commands yield useful output when you pass --help.

I never heard of any such thing. Where is that alleged fact stated
in that book I cited above?

> There's a recent-Linux-distribution survival-kit for you; --help,
> option, grep, find, locate, man and less.

Unfortunately I don't currently have access to any Linux shell, so
I'll have to put your suggestion on the "back burner".

> Since you're already in Emacs, it's convenient to do `M-x diff
> RET' insteading of dropping to a shell.

Hmm, let me get into GNU Emacs on FreeBSD Unix to see what the
documetantion for that command says ...

ESC x runs the command execute-extended-command
which is an interactive built-in function.
Read function name, then read its arguments and call it.
(execute-extended-command PREFIXARG)

diff is an interactive autoloaded Lisp function in `diff'.
Find and display the differences between OLD and NEW files.
Interactively the current buffer's file name is the default for NEW
and a backup file for NEW is the default for OLD.
With prefix arg, prompt for diff switches.

OK, we have a problem: I don't know how to override the defaults
when calling an emacs-lisp function that has defaults, like how
does it know whether I'm done and want defaults or not done and
will be entering explicit file names? I think ctrl-Z to shell,
reducing the problem to one I already know how to solve, is easier
then going through the complications of passing args to M-x diff.

> Other useful commands to avoid dropping to a shell in Emacs are
> `dired',

I never use that. Instead I start up 'lynx', because it makes
browsing the directory tree very easy, and it doesn't accidently
delete hundreds of files just because I pressed a keystroke I got
wrong. By the way, I never use the 'rm' command from a regular
directory, to protect myself against accidently expunging some
file, or lots of files, I don't want to lose. Instead, I 'mv' the
unwanted file(s) to ~/Trash/ which is a holding place for unwanted
files. Later I can empty that "trash can" after I've looked over
the contents several times to be extra sure I really haven't
accidently trashed a file I want to keep. DIRED would seem to
suffer the same problem as 'rm', but moreso, where a single
mistaken keystroke can delete a file.

Is there a way to configure dired so that whatever keystroke
deletes a file or multiple files will instead move to ~/Trash/ ?

> `locate',

I never heard of that program. Let me check the book again ...
nope, that's not in the book either, so it's not anything I should
know. By the way, 'dired' isn't in that book either. I know it only
as an EMACS mode, or as a shortcut to start up EMACS and go into
DIRED mode.

> `grep',

I use that on a regular basis, one of my most commonly used
non-trivial programs/commands. But I hate regular expressions!!!
(You don't want to get me started on all the things I hate about them!)

> `find',

I seem to recall us seeing that a few minutes ago already.
Are we in the Collosal Cave and we're back there again?
Or is this the Who's on First skit? :-)

> `find-grep'

I never heard of that. Neither 'find' nor 'find-grep' is in the
book, so there's no reason I should know either.

> and `man'.

That *is* in the book, the only one so-far that you've mentionned.
But that gets back to the top of this message, when I use 'man' and
spent a half hour trying to find anything useful toward solving the
current crisis.

> `RET' on a line in a diff-buffer will take you to the
> corresponding line in the source file,

That seems a minor shortcut compared to what I do normally:
- I see the offending text in the diff | more output.
- I copy that text from my VT100 emulator and paste into McSink edit.
- I go into EMACS and issue c-s (incremental search) command, and
paste in the text, and there I am.
As a bonus of this method, my local Macintosh text edit file has a
copy of the offending text already, so later I can look at my notes
to see where I got stuck, and I can the copy+paste that text into a
newsgroup article to ask for further help to get unstuck.

> | I don't understand why, on Ubuntu where asdf already is on system
> | disk, I need to provide my own version in addition. Why can't I
> | just use the system-supplied version?
> Why can't you? (load "/path/to/asdf.lisp") ?

If the Ubuntu Linux system is ever working again, I'll have to give
that a try. Right now, becuse Ubuntu Linux has been down, and
FreeBSD Unix doesn't have any extra disk space in my account, I've
gotten an account on a free PHP/MySQL hosting site and I'm
implementing my NewEco there instead of on either shell account.
If you're curious to see what I have so far (a couple days work) on
PHP/MySQL, see <tinyurl.com/Portl1>.

> | I'm guessing asdf:oos means Object-Oriented Services, but
> | so-far the Google search isn't turning up the definition of the
> | abbreviation.
> CL-USER> (load #p"/home/thomas/lib/cl/asdf.lisp")
> T
> CL-USER> (documentation 'asdf:oos 'function)
> "Short for _operate on system_ and an alias for the `operate` function.
> Operate does three things:
> 1. It creates an instance of `operation-class` using any keyword parameters
> as initargs.
> 2. It finds the asdf-system specified by `system` (possibly loading
> it from disk).
> 3. It then calls `traverse` with the operation and system as arguments

I know generally about OOP, including reading random discussions
about CLOS (which I've never used yet because I've never had a need
for it), but I don't know anything about those specific classes
you're talking about, so I understand the general idea of what you
wrote there, including the general concept of initargs, but have no
idea what you're really talking about. Since I don't have any shell
account available where I could practice/test/explore anything
related to asdf, I'm skipping much of the rest of your fine
message.

> Today the "semantic web" is all the rage. Or, maybe it was last week.
> <http://en.wikipedia.org/wiki/Semantic_Web>

A few weeks ago I created my meta-TinyURL portal
<tinyurl.com/UrlGo> which I planned to expand to include something
like a semantic link, where instead of typing the last part of a
TinyURL into the blank space, there'd be another blank space where
you'd type a keyword or phrase and it'd perform an information
retrieval action to try to discocver which of my Web pages you were
seeking or which FAQ item within a database of FAQ items you might
want, and then you could browse the search results and click on the
link that looked most like what you were seeking. But with Ubuntu
Linux inaccessible, I can't edit my meta-TinyURL portal to add that
functionality, so I'd need to copy the whole thing to some hosting
site and the expand it there, which at the moment is less urgent
than finishing implementation of my MakeNewAccount/LogIn portal at
<tinyurl.com/Portl1>. By the way, my Turing-protected menu is
already there, a neat idea I thought of a few days ago and then
implemented. It ensures that you understand any menu option you
select, because you need to understand it well enough to key in the
missing text in the menu entree, rather than just blindly click at
a random link. Please try that portal and tell me if you like my
new idea. Note: It's formatted for cell-phones with one-inch
screens, including micro-navigation to avoid having to press the
down key on your cellphone eight times in a row just to scroll all
the way to the next screen after the one you're currently looking
at. So please try it on your *cell*phone*, not your lap/desk-top.

> | IMO s-expressions are optimal for specifying strictly-nested
> | structures, whereas SGML is optimal for turning orthogonal modes on
> | and off in a non-nested way, the old "tag soup" methodology.

Looked at it, crufty.

> Marking up with sexprs offers paren-matching instead of
> tag-balancing, structural editing with familiar Emacs commands,
> less verbosity, easy manipulation by means of CL, easy to spit out
> whatever-format from.

Yes, but as I pointed out above, it works *only* with properly
nested tags, not with orthogonal on/off mode-change commands.
Although SGML is supposed to be properly nested, the raw syntax
says the opposite, that tag soup should be the norm rather than a
violation of the standard that is only *tolerated* without
signalling an error/exception/warning because of Postel's stupid
rule for communication protocols.

> <http://www.cliki.net/asdf-dependency-grovel> is useful,

OK, looked at it briefly.

Pascal J. Bourguignon

unread,
Apr 30, 2009, 9:46:55 AM4/30/09
to

>> From: Thomas Stenhaug <thomas.stenh...@gmail.com>
>
>> [Pascal J. Bourguignon]
>> | [...] man THE_COMAND and read carefully the page mage
>> | of the command.
>
>> [Robert Maas]
>> | I already did read those fucking-extraverbose man pages several times,
>> | each time spending a half hour or hour or even two hours [...]
>
>> You might be better off reading them less carefully.
>

> [...ragnagnagna...]


>
>> You'll find that most commands yield useful output when you pass --help.
>
> I never heard of any such thing. Where is that alleged fact stated
> in that book I cited above?

You should _REALLY_ read this paper:
http://www-formal.stanford.edu/jmc/applications.html
and try to integrate its algorithms to your thinking processes.

--
__Pascal Bourguignon__

0 new messages