From: Kenny
Subject: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <48a25072$0$29513$607ed4bc@cv.net>
Can't we do better? It's a bit of an embarrassment, the first thing 
professionals encounter when they come to Lisp.

kt

ps. yes, I just found a new bug. k

-- 

$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/

From: Rob Warnock
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <_dSdnfTv5uAoDD_VnZ2dnUVZ_sednZ2d@speakeasy.net>
Kenny  <·········@gmail.com> wrote:
+---------------
| Can't we do better? It's a bit of an embarrassment, the
| first thing professionals encounter when they come to Lisp.
+---------------

MK:DEFSYSTEM occupied the weird-license niche[1] for a long time;
ASDF now occupies the "really-open MIT-style" license niche,
and is "mostly good enough".[2]  Niche captured; game over.

Refs:
[1] http://en.wikipedia.org/wiki/Niche_market
[2] http://www.dreamsongs.com/WorseIsBetter.html

+---------------
| ps. yes, I just found a new bug. k
+---------------

LOL. We cn haz details plz?


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Kenny
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <48a298c8$0$20937$607ed4bc@cv.net>
Rob Warnock wrote:
> Kenny  <·········@gmail.com> wrote:
> +---------------
> | Can't we do better? It's a bit of an embarrassment, the
> | first thing professionals encounter when they come to Lisp.
> +---------------
> 
> MK:DEFSYSTEM occupied the weird-license niche[1] for a long time;
> ASDF now occupies the "really-open MIT-style" license niche,
> and is "mostly good enough".[2]  Niche captured; game over.

Damn. So I have to go back to COBOL?

> LOL. We cn haz details plz?

My scarce resources are available for the demolition team.

:)

kt

-- 

$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
From: Dan Weinreb
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <5dcbb827-c455-4dfb-b401-8bff982e36a6@m44g2000hsc.googlegroups.com>
On Aug 12, 11:09 pm, Kenny <·········@gmail.com> wrote:
> Can't we do better? It's a bit of an embarrassment, the first thing
> professionals encounter when they come to Lisp.
>
> kt
>
> ps. yes, I just found a new bug. k
>
> --
>
> $$$$$:http://www.theoryyalgebra.com/
> Cells:http://common-lisp.net/project/cells/
> BSlog:http://smuglispweeny.blogspot.com/

It turns out to be really very hard to write a good tool that does the
kind of thing that ASDF does.  You'd think it would be pretty easy,
but back at Symbolics we went through several generations of this, and
even the last one that was done in Genera was very frustrating.

I now regret that I did not write down what its drawbacks were.
Perhaps I can poll some Symbolics alumni and see if anyone remembers.
Probably not; it's been a long time.

Francois-Rene Rideau, known as Fare (accent on the last e), at ITA
Software, it working on a new one, called ACVB.  (Put your fingers on
the ASDF keys on the Qwerty keyboard and move them down and right.)As
you can imagine, at ITA we have this issue in spades since our system
(the "core" part of the airline reservation system") is quite huge and
has many modules.

It's designed to meet several new goals, including allowing builds to
be done in parallel (understanding the dependency issues).  I have not
looked at it yet, but I'd better, because he's about to install it and
I'll be using it!  If this turns out to be good, we will definitely
consider open-sourcing and releasing it.  But first we need a chance
to get more experience and work out the bugs and such.

I have no idea whether it will turn out to be a viable alternative to
ASDF, and so much software exists with ASDF system definitions that
I'm sure ASDF will be with us for a long time.  We do use it now, for
everything.
From: Pascal Costanza
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <6gijd5Ffql8mU1@mid.individual.net>
Dan Weinreb wrote:
> On Aug 12, 11:09 pm, Kenny <·········@gmail.com> wrote:
>> Can't we do better? It's a bit of an embarrassment, the first thing
>> professionals encounter when they come to Lisp.
>>
>> kt
>>
>> ps. yes, I just found a new bug. k
>>
>> --
>>
>> $$$$$:http://www.theoryyalgebra.com/
>> Cells:http://common-lisp.net/project/cells/
>> BSlog:http://smuglispweeny.blogspot.com/
> 
> It turns out to be really very hard to write a good tool that does the
> kind of thing that ASDF does.  You'd think it would be pretty easy,
> but back at Symbolics we went through several generations of this, and
> even the last one that was done in Genera was very frustrating.

It is my impression that ASDF was a pretty important piece of the puzzle 
for getting Lisp popular again in recent years. It made it easier to use 
libraries, and provided its capabilities across several CL 
implementations, which is a very important factor these days. [1]

ASDF is a pretty good example of the "worse is better" principle: It may 
not be the ideal solution for the problem it solves, but it gets its job 
done, and people know how to work around its limitations. I think this 
was more important than waiting for the ideal solution that would have 
never seen the light of day. (As Dan suggested, the problem is 
inherently complex, so an "ideal" solution has to be a pretty complex 
beast almost by definition.)


Pascal


[1] This is just an observation. Whether this is good or bad is a 
different discussion.

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Rob Warnock
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <s5SdnXxa45_x4zjVnZ2dnUVZ_sWdnZ2d@speakeasy.net>
Dan Weinreb  <···@alum.mit.edu> wrote:
+---------------
| Francois-Rene Rideau, known as Fare (accent on the last e), at ITA
| Software, it working on a new one, called ACVB.  (Put your fingers on
| the ASDF keys on the Qwerty keyboard and move them down and right.)
+---------------

ACVB? Did you really mean XCVB?  [Though that's
down-one/right-two. Down-one/right-one would be ZXCV.]

Myself, I kinda like SDFG, which backronyms nicely to
"Source Definition Facility (Generalized)".


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Kaz Kylheku
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <20080813224436.954@kkylheku.gmail.com>
On 2008-08-13, Kenny <·········@gmail.com> wrote:
> Can't we do better? It's a bit of an embarrassment, the first thing 
> professionals encounter when they come to Lisp.

Have you run into the sad bullshit of ASDF's handling of symbolic links?

I maintain a private version of ASDF in which I fix all that.

If some ``foo.asd'' is actually a symbolic link somewhere, ASDF gets cute and
thinks that the project lives in the directory where the target of that link
lives. It resolves the link, strips the resolved path to a directory, and then
resolves the paths in the .asd file relative to /that/ directory.

People rely on this assinine behavior, by populating some directory with
farm of .asd symlinks which point to projects elsewhere.

But I say that, like, if I wanted a directory symlink, I would have sorta used
one.  The correct way to do design this would be to model an ASDF project
structure as a directory which contains a well-known file. You know, like
``Makefile'' or ``index.html'', etc. Doh!  Then  can relocate the whole thing
using a directory symlink, which can be totally transparent to the application
layer. A farm of directory symlinks serves as your project repository.

Then there is the problem that ASDF does even more symlink resolving. Suppose
your .lisp files are actually a symlink farm to real files elsewhere. Well,
guess what, ASDF wants to put the .fasl files next to the target files! Again,
it resolves symlinks, computes the target directory, and then uses that to
compute the target file name.

Many GNU Autoconf projects happily configure in a separate directory, away from
the source directory, and build there. The build system refers back to the
source directory, but builds derived files in the build directory.

Projects which don't support this at all, or whose support for this is broken,
can be coaxed into doing it by the trick of building a link farm using the X11
utility ``lndir''.

With ``lndir'', you can clone the entire Linux kernel and build it separately.
I build the same kernel source tree for two architectures this way.

Unpatched ASDF takes the prize for being the first thing I came across which
breaks the lndir hack, and sticks your object files back into the source tree.
And I speak as the implementor and maintainer of a from-scratch Linux distro.
From: Marco Antoniotti
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <f22e0fb0-43e2-4868-b28d-96915902b796@a70g2000hsh.googlegroups.com>
On Aug 14, 2:01 am, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-08-13, Kenny <·········@gmail.com> wrote:
>
> > Can't we do better? It's a bit of an embarrassment, the first thing
> > professionals encounter when they come to Lisp.
>
> Have you run into the sad bullshit of ASDF's handling of symbolic links?
>
> I maintain a private version of ASDF in which I fix all that.
>
> If some ``foo.asd'' is actually a symbolic link somewhere, ASDF gets cute and
> thinks that the project lives in the directory where the target of that link
> lives. It resolves the link, strips the resolved path to a directory, and then
> resolves the paths in the .asd file relative to /that/ directory.
>
> People rely on this assinine behavior, by populating some directory with
> farm of .asd symlinks which point to projects elsewhere.
>
> But I say that, like, if I wanted a directory symlink, I would have sorta used
> one.  The correct way to do design this would be to model an ASDF project
> structure as a directory which contains a well-known file. You know, like
> ``Makefile'' or ``index.html'', etc. Doh!  Then  can relocate the whole thing
> using a directory symlink, which can be totally transparent to the application
> layer. A farm of directory symlinks serves as your project repository.

Which is what MK:DEFSYSTEM does.  YMMV, but that is the way it works
now.  The .system file acts as the Makefile and you just need to have
the parent directory added with  MK:ADD-REGISTRY-LOCATION (or the
directory itself).  Not only that.  There is code to deal with
"recursive" .system files.


> Then there is the problem that ASDF does even more symlink resolving. Suppose
> your .lisp files are actually a symlink farm to real files elsewhere. Well,
> guess what, ASDF wants to put the .fasl files next to the target files! Again,
> it resolves symlinks, computes the target directory, and then uses that to
> compute the target file name.

The real problem is that symlinks should not be handled in CL.  They
are a UNIX concept (useful as they are) which does not port well to
Windows or even the Mac OSX finder.  As usual the problem is the
"implementation dependent" bits of the Pathname specs, but we have
been there before.

> Many GNU Autoconf projects happily configure in a separate directory, away from
> the source directory, and build there. The build system refers back to the
> source directory, but builds derived files in the build directory.

You can do that in ASFD and MK:DEFSYSTEM as well.

> Projects which don't support this at all, or whose support for this is broken,
> can be coaxed into doing it by the trick of building a link farm using the X11
> utility ``lndir''.
>
> With ``lndir'', you can clone the entire Linux kernel and build it separately.
> I build the same kernel source tree for two architectures this way.

Does not work on Windows AFAIK.

Apart from that, building a good system definition tool is very very
hard.  I have dabbled with it for a long time now, and I never got it
all together.  There are several interplaying bits and pieces that
have to go together and getting all of them even almost right is quite
a challenge.

Personally I think that the right way of looking at the problem is
what Drew McDermott did with his YTools suite.

Cheers
--
Marco
From: Petter Gustad
Subject: Re: ASDF...pwuahhahahahhahahahahah
Date: 
Message-ID: <87ljz0hxev.fsf@pangea.home.gustad.com>
Kaz Kylheku <········@gmail.com> writes:

> and sticks your object files back into the source tree.

Have you considered using asdf-binary-locations?

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?