Prev: Is LISP divine?
Next: keywords & macros
From: joswig on 16 Apr 2010 10:56
On 16 Apr., 16:02, "o.jas...(a)gmail.com" <o.jas...(a)gmail.com> wrote:
> I somehow got the impression that you were saying that load/compile
> weren't possible that way.
>
> > it[asdf] gets it right as for the goal, but probably not for the means) not
> > to execute things immediately, but to produce a "plan", a
> > topologically sorted lists of actions.
>
> It does seem silly to first gather a list of things to do and then do
> them when you can just do it off/hand like this.

Plans have several useful purposes:

* one can generate the plan and look at it while constructing/refining
a system description.
Is the sequence of operations the one I want? Are all necessary
files in the plan?
Are all systems/files that are mentioned in the plan available?

This also helps debugging a DEFSYSTEM implementation. It helps
to see what the DEFSYSTEM will do, without the need to execute the
actions.

* the plan is a more compact representation of what will be done -
than looking at
various system descriptions

* when porting software, I sometimes generate a compile plan and then
walk manually through
the files, fixing obvious problems and execute the plan steps by
hand for each file.

* sometimes during development I want to get rid of one or more steps
of a plan.
In LispWorks I can deselect these unwanted steps in the user
interface.

* if a plan is aborted for some reason, one might be able to execute
the
remaining steps later.

Much of that is for more advanced usage. Many users might just want to
start over and restart the Lisp compiler. It's fast nowadays. In an
IDE with lots of state, restarting is more costly and I want to avoid
that.

<...>
From: His kennyness on 16 Apr 2010 11:34
RPG wrote:
> On Apr 15, 3:06 pm, Nathan Froyd <froy...(a)gmail.com> wrote:
>> On Apr 13, 6:29 pm, Juanjo <juanjose.garciarip...(a)googlemail.com>
>> wrote:
>>
>
>>> * Restrict the set of operations that ASDF supports to a few: compile,
>>> load & test
>> Please don't do this. There are very good reasons to support more
>> than
>> three operations on a system; I've written at least two custom
>> operations
>> for my own personal use (building tar files and autogenerating
>> documentation);
>> I'm sure you can think of more.
>
> I would like to second this. More and more I find that I write
> systems that
> combine Lisp with other tools. It is common for me to write new
> operations in my ASDF files.

I smell "make"!

>
> It might be reasonable to think harder about what the BUILDING BLOCKS
> for
> such new operations and components should be --- I think ASDF got a
> number of things wrong here --- but not take this ability away.

The way past this is to stop talking in the abstract and Get On With
It(tm), with the benefit of everyone's experience at hand to guide
decisions.

So one guy does not want these make-ish side-effects firing and one guy
wants make-ish behavior -- sounds like a global build option is born,
and those of you who think defsystem is make need to accept that these
other deals will have to be done within a structure, not by slapping
arbitrary code in a def.

As long as the process is public and keeps in mind the edge cases on
hand in 2010 after fifty years of Lisp, we should do OK.

kt

>
> ...
>
>>> * Replace the routine that drives ASDF, TRAVERSE, with something
>>> everybody understands.
>> Method combination would be a good start here. TRAVERSE was written
>> the way it was because of poor CLOS support from some implementations.
>
> Method combination, with all due respect, is a red herring here.
> What
> is needed is not a new software tool, or even a refactoring, but a
> specification. The component that generates the build/load/operate
> plan
> (TRAVERSE) should be specified clearly and (I can almost hear the
> howling)
> formally using the tools of theoretical computer science, especially
> graph
> theory. If we can say what TRAVERSE /should do/, which I believe has
> everything
> to do with computing a topological ordering on a particular graph, it
> will
> be a lot easier to do it, and to check its correctness when it's
> done.
>
> If someone wants to make a successor for ASDF, let's have a RFP for
> what
> its successor /should/ do, first, instead of just banging together
> more
> code.
>
>
>
From: Tim X on 16 Apr 2010 12:59
Faré <fahree(a)gmail.com> writes:

>>>>: Juanjo
>>>: Jochen Schmidt
>>: Tim X
>
>> Yes, I like this approach. Part of where I feel things have fallen down
>> as been due to trying to do too much all at once. I like the idea of
>> building up from a good base and that the most fundamental part of that
>> base is some way of expressing/representing dependencies. Once we crack
>> that nut, I think we can build more complex functionality. The hard part
>> is identifying/defining how to best do this and doing so in such a way
>> that the simple case is still simple and the complex case is no more
>> complex than it needs to be.
>>
> I'm most open to suggestions on how I could rewrite XCVB in a better
> way.
> Please explain.
>

Note that I made no reference to xcb, only on identifying the best way
to represent dependencies that would allow us to build more advanced
functionality. This could well be xcb or some other build system. My
point was that we have various different approaches and no consensus on
how to address the problem and have fragmented how we do things.

I don't think this should be a battle over how one way does x better
than another way. This should be about identifying exactly what is
expected/required and then taking the best ideas and seeing if we can
create something that is even better. The fact we have more than one
system indicates a lack of consensus. We probably need more consensus
before we start debating the merits and weaknesses of any specific
approach.

Tim

--
tcross (at) rapttech dot com dot au
From: Juanjo on 16 Apr 2010 16:43
On Apr 16, 8:39 am, Faré <fah...(a)gmail.com> wrote:
>
> You want simple? Look at XCVB-Master. As simple as can be.

Fare, this is cheating: xcvb-master does nothing, it just calls a
program that does the actual job, compiling and returning the list of
files to be loaded. It is like factoring all of ASDF in a separate
program and then writing a four lines driver of a complex C++ program
that processes the dependencies and does the job.
From: Faré on 16 Apr 2010 17:27
On Apr 16, 4:43 pm, Juanjo <juanjose.garciarip...(a)googlemail.com>
wrote:
> On Apr 16, 8:39 am, Faré <fah...(a)gmail.com> wrote:
>
> > You want simple? Look at XCVB-Master. As simple as can be.
>
> Fare, this is cheating: xcvb-master does nothing, it just calls a
> program that does the actual job, compiling and returning the list of
> files to be loaded. It is like factoring all of ASDF in a separate
> program and then writing a four lines driver of a complex C++ program
> that processes the dependencies and does the job.
>
But THAT'S THE POINT!

Users of CL software shouldn't have to share their image with the
build system, and then either have big in-image versioning
incompatibility problems, or dirt poor build system feature-set
because their build system can't afford to use libraries.

In the future, I'd like to add a distributed system to XCVB,
cryptography, using rich efficient data-structure libraries, etc. Just
can't do that with ASDF.

It's not "cheating". It's "freeing yourself from the self-inflicted
pains of a needless constraint".

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org
]
What one person receives without working for, another person must work
for
without receiving. — Adrian Rogers
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Is LISP divine?
Next: keywords & macros