From: goose
Subject: ASDF help
Date: 
Message-ID: <1148391870.105439.4430@j73g2000cwa.googlegroups.com>
Hello all

I'd like some help about asdf, specifically, where
can I find it as the only download page for it as
returned by google is down (sourceforge).

I am shocked that the are no mirrors, is there no
one in the lisp community who mirrors things like asdf?

<rant>
On a related note, while I am falling ever more in love
with lisp as I learn more, I am rapidly losing patience
with the lisp "community", where everyone who writes
the tiniest little thing assumes that your entire
system is setup to exactly their specifications.

1. I downloaded sbcl, but it refuses to run as my
   kernel is too old (linux 2.4)? Eh? Everything else
   runs fine; why not just disable those features that
   require 2.6, as I (and I'm not alone in this) got
   fed up with the forever unstable 2.6 series and went
   back to 2.4.

2. I downloaded cmucl, which works as advertised.

3. I tried using clsql with it, but apparently it needs
   asdf-installer.

4. I downloaded the asdf-installer, but I *still* need
   asdf itself (I'm a newbie, and I wasn't aware that
   they come seperately, as none of the literature that
   comes with stuff that uses asdf actually makes a point
   of telling me what asdf actually is, they all assume
   that I already know what asdf is).

5. I now try to download asdf itself, but there is only
   a single site that has it for download (as serached by
   google).

Whats the story here? Why make everything so convoluted?
Whats wrong a make-ish process for building? If asdf is
so damn nice, why don't all the lisps ship with it? If
it is actually that good, then why the hell don't the
people who distribute their stuff (like clsql) distribute
asdf as well? I looked through the .asd files, and it
seems that asdf is simply a brain-damaged replacement
for make (which, admittedly, is even more brain-damaged).

For building a lisp program (say, shipping a core file),
I'd have expected something thats make-like in use to be
better than something like asdf, which seems to have
set as a design goal Perls brain-damaged design/quasi-distro
methods.

</rant>

Now that I've let of a little steam (hey, I spend
hours just spinning wheels with lisp because I
*still* want to learn it), I can think of better ways
of source distribution that don't assume that your
target has *two* programs needed for build which are
distributed by *two* different sources. This current
method means that my target user has got to install:
1. my fav. lisp system (cos they are not easily interchangeable).
2. asdf (unattainable atm because only one source exists).
3. asdf-installer.
4. finally, they get to install my software.

Most users are going to give up long before #4. I suppose the
best thing to do (which no open-source lisp program that I know off
currently does) is to package #2, #3 and #4 up together, optionally
with #1 if the user wants. Why don't any lisp developers do this?
(Thats not rhetorical, btw; I'd really rather like to know).

goose

From: Ken Tilton
Subject: Re: ASDF help
Date: 
Message-ID: <CUGcg.24$mN3.23@fe09.lga>
goose wrote:
  On a related note, while I am falling ever more in love
> with lisp as I learn more, I am rapidly losing patience
> with the lisp "community", where everyone who writes
> the tiniest little thing assumes that your entire
> system is setup to exactly their specifications.

Well, it is not the community so much as the simple reality arising I 
think mostly from the history of Lisp. The standardization process did 
not happen to include things like a make utility, so everyone just rolls 
their own. And their is no one Lisp implementation as with other 
languages, so do not look for The One True Implementation to have a 
preferred build solution.

AllegroCL happens to have a killer project manager, but that is the only 
one I know of.

The other problem is that, if the learning curve does not kill you, you 
will have your own system up and humming (including some ad hoc Lisp 
build code) and you will never look back. Or stop to write something 
better than ASDF.

otoh... it sounds like you are using Linux. I thought you would have a 
high tolerance for pain by now.

:)

kenny
From: goose
Subject: Re: ASDF help
Date: 
Message-ID: <1148418444.148551.103970@38g2000cwa.googlegroups.com>
>> with lisp as I learn more, I am rapidly losing patience
>> with the lisp "community", where everyone who writes
>> the tiniest little thing assumes that your entire
>> system is setup to exactly their specifications.
>
>Well, it is not the community so much as the simple reality arising I
>think mostly from the history of Lisp. The standardization process did
>not happen to include things like a make utility, so everyone just rolls
>their own.

Respectfully, I feel obliged to point out that *no* other
(standardised) language comes with a build utility, and very
few single-reference-implementation languages come with
any sort of build utility either; they just seem to be
designed for an external, user-supplied build utility
and provide comprehensive hooks for external build utilities
(ala c/line flags).

The difference is that Lisp implementations seem
to all abhor non-Lisp programs, hence the build
utility has to *speak* Lisp. With C, C++, etc ad nauseum
they don't expect the build utility to understand
C (or C++, etc) and so they are fairly easier to build.

(If the reader thinks that I'm being hypocritical by
a) bitching about convoluted build processes on Lisp systems
     *while*
b) saying that other languages don't even have a build
   process for the particular language

then yes, I guess I am. The other languages tend to
build fine using the default build program on the
machine i.e. make.

Lisp implementations cannot make use of make, but
instead supply a poor substitute. However, even with
my newbieness glowing off my scalp like polished
dandruff, I can see that make itself is not adequate
for most lisp programs).

>And their is no one Lisp implementation as with other
>languages, so do not look for The One True Implementation to have a
>preferred build solution.

I try not to use languages which are One-True-Reference-
Implementation-Defined. There are uses for them, but not
for longetivity(sp?). For example, look at the wreckage
of php4 to php5 (php5 fixed a number of dubious practices
of php4) conversions. Or look at the uptake of Perl6 amongst
perl5 users. Language standards, IMHO, are much better.

>
>AllegroCL happens to have a killer project manager, but that is the only
>one I know of.
>

Not really familiar with that yet :-(. I have a limited amount
of time after getting married recently, and going back to
university, and holding down one full-time job and one
part-time job, as well as trying to actually *fix* the fixer
upper house I bought.

>The other problem is that, if the learning curve does not kill you, you
>will have your own system up and humming (including some ad hoc Lisp
>      build code) and you will never look back.

I've got a nicely done system which uses clisp, the build process
automagically stuffs the documentation strings for everything
into a seperate text file while building, etc.

>Or stop to write something
>better than ASDF.
>
>otoh... it sounds like you are using Linux. I thought you would have a
>high tolerance for pain by now.
>

Hehe... I actually *don't* have a high tolerance for pain,
which is I am back at kernel 2.4. I get by just fine with
slackware as it requires the least amount of babysitting,
not to mention that the scripts I wrote to ease my life
back in '95 on slackware 2.something still work. Other
operating systems and distros are just too much work for
me, having to learn the gui, etc means that what I already
know is irrelevant; I stick with c/line administration as
then I simply automate everything when possible.
From: Tim X
Subject: Re: ASDF help
Date: 
Message-ID: <878xoromnk.fsf@tiger.rapttech.com.au>
"goose" <····@webmail.co.za> writes:

>
> Hehe... I actually *don't* have a high tolerance for pain,
> which is I am back at kernel 2.4. I get by just fine with
> slackware as it requires the least amount of babysitting,
> not to mention that the scripts I wrote to ease my life
> back in '95 on slackware 2.something still work. Other
> operating systems and distros are just too much work for
> me, having to learn the gui, etc means that what I already
> know is irrelevant; I stick with c/line administration as
> then I simply automate everything when possible.
>

Just a couple of comments which may or may not be relevant to your
approach. 

After starting with Slackware way back in 94/93?, then moving to Red
Hat as slackware's package management back then was pretty much
o\non-existent and then moving to Debian because I got frustrated with
Red Hat's tendency to move more and more towards GUI based admin, I
can very much recommend Debian for lisp work. There is a learning
curve, but I don't think you would have any problems with it. Debian
still seems to favor command line stuff (the gui tools are there if
you want them, but you don't need them). 

However, Debian has a very nice lisp environment which uses ASDF and
the lisp controller, which makes it trivial to run multiple lisp
implementations. You can switch from CMUCL to SBCL to CLISP to GCL at
will with hardly any fuss and then move back. There is also quite a
good selection of popular CL packages you can use (cl-sql, cl-ppcre,
mod_lisp, etc). Emacs is also well supported with lots of useful
add-on packages ready to go including Slime. The only advice I'd give
is to run Debian Testing, which I've found to be quite stable and
reasonably up-to-date - certainly adequate for most situations. I run
it at home and at work and have not lost any of my productivity at
work because of instability with my system. The Debian package manager
is the best I've used on Linux so far and a *lot* better than RPM IMO.
I also find Debian to be one of the better distros wrt standards.

The other point I wanted to make was that the 2.6.15 kernel package
from Debian seems pretty stable to me. We are running it at work on a
number of different architectures (Intel, AMD, 32bit and 64bit) and
have no issues with it apart from some problems we had with fibre
channel drivers which have since been resolved. 

I realise switching distros is not necessarily trivial, but going from
what you have said, I suspect you would quite like Debian as a
distribution and you will get far better lisp and emacs support than
under Slackware. 

Tim

-- 
tcross (at) rapttech dot com dot au
From: Holger Schauer
Subject: Re: ASDF help
Date: 
Message-ID: <yxzzmh7smuc.fsf@gmx.de>
On 4648 September 1993, Tim X. wrote:
> However, Debian has a very nice lisp environment [...]

As of stable (sarge), I can't support that statement. Getting ucw to
run on sarge, for instance, requires a compiling a new sbcl, as the
version shipped is a queen of the stone-age. I also had trouble with
the old version of cl-sql shipping with sarge. Slime is only available
in testing and unstable. Probably etc.

> The only advice I'd give is to run Debian Testing, which I've found
> to be quite stable and reasonably up-to-date - certainly adequate
> for most situations.

There is no security support for testing. That makes it a no-no for
production systems if the system in question has connection to the
internet. It's also a moving target which might break when you last
expect it.

Holger

-- 
---          http://www.coling.uni-freiburg.de/~schauer/            ---
"I don't do drugs or windows."
"You need the one to do the other :-)"
                  -- Steve Baur and Adrian Aichner on xemacs-beta
From: Christophe Rhodes
Subject: Debian Testing security (was: Re: ASDF help)
Date: 
Message-ID: <sqbqtn64y4.fsf_-_@cam.ac.uk>
[ not really c.l.l. material: note f'ups ]

Holger Schauer <··············@gmx.de> writes:

> On 4648 September 1993, Tim X. wrote:
>> The only advice I'd give is to run Debian Testing, which I've found
>> to be quite stable and reasonably up-to-date - certainly adequate
>> for most situations.
>
> There is no security support for testing.

This is not entirely true: security support for Debian testing has
been provided since August 2005, and as of this month is integrated
with the main Debian infrastructure: see
<http://lists.alioth.debian.org/pipermail/secure-testing-announce/2006-May/000029.html>.

Christophe
From: Stefan Nobis
Subject: Re: ASDF help
Date: 
Message-ID: <87mzd73ast.fsf@snobis.de>
Holger Schauer <··············@gmx.de> writes:

[Debian]
> There is no security support for testing.

Not quite up to date:

http://secure-testing-master.debian.net/

deb http://security.debian.org/debian-security etch/updates main contrib non-free

> It's also a moving target which might break when you last expect it.

However that's still true.

-- 
Stefan.
From: Tim X
Subject: Re: ASDF help
Date: 
Message-ID: <87r72imptr.fsf@tiger.rapttech.com.au>
Stefan Nobis <······@gmx.de> writes:

> Holger Schauer <··············@gmx.de> writes:
>
> [Debian]
>> There is no security support for testing.
>
> Not quite up to date:
>
> http://secure-testing-master.debian.net/
>
> deb http://security.debian.org/debian-security etch/updates main contrib non-free
>
>> It's also a moving target which might break when you last expect it.
>
> However that's still true.
>
> -- 
> Stefan.

I don't disagree, but would point out that I did also say it was good
enough for "learning", which implies a non-production role and it was
in response to the OP's original post in which he was expressing som
frustration regarding getting a good linux based environment for
learning lisp. 

I think stating that a "testing" distribution is not suitable for a
production environment is stating the bleeding obvious, but I have no
issue if others feel it is necessary. It would be a shame though if
the OP is convinced Debian testing is no good because of misdirection created
through references to production environments. Still, if someone can
recommend a Linux distro which has the level of CL support Debian
testing has "out of the box", is more current and rated stable enough
for a production environment, then speak up as I'd be interested in
looking at it. 

Tim

-- 
tcross (at) rapttech dot com dot au