Re: lispworks 7.0
On Fri, Apr 10, 2015 at 6:24 AM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
> As for ASDF per-se, it has indeed the same problem as a lot of OO-based
> systems, in that it is easily extensible, but only if you know well the
> object model it uses, along with all its methods, so that you're able to
> extend it by writing just the right method for the right subclass.
>
The object model was originally broken; it was only fixed with ASDF3.
If you want to understand the ASDF object model, beside the source code,
and its documentation, the best source of information is my wrap up
of my involvement as ASDF maintainer, at:
https://github.com/fare/asdf3-2013
> On the other hand, the "better" replacement should be xcvb, which IS
> written by people working at ITA now Google. The question could be
> indeed, when will xcvb ready for production, and whether quicklisp would
> be able to use xcvb?
>
I fear that XCVB is mostly dead. When I became ASDF maintainer,
I stopped adding new features to XCVB. Now it lags behind in many ways,
though in other ways, it's still ahead. Yet, in these other ways,
it cannot remotely rival with bazel, Google's newly opensource build system.
Bazel implements all the things I dreamed for XCVB to implement,
except for it being an unportable java memory hog instead of
a lean portable Lisp solution. I suppose there's still an opportunity
to hack on XCVB, if someone feels like a challenge.
On the other hand, for a lean portable Lisp solution, ASDF3 is probably
a better place to start than XCVB, especially since the transition from
ASDF2 to ASDF3 was heavily informed by my experience with XCVB:
ASDF3 adopted quite a few design patterns from XCVB, not to speak about
a lot of actual code that became the start of its UIOP.
And it avoided some some dead ends that I went into during my XCVB days.
That said, more ideas from XCVB could usefully make it to ASDF, and
the asdf/TODO file describes what an ASDF4 could look like that way,
now that ASDF3 did the hard thing of fixing the ASDF object model.
> I would note that if you write simple system definitions, (apart from
> the fact that we usually qualify the symbol asdf:defsystem), you can
> write .asd files with nothing in it really depending on asdf: it's just
> a defsystem form, which _declares_ some dependencies. How you process
> this sexps is entirely up to you.
>
> You could very well write a 20-line function to compile and load systems
> using these defsystem forms, and live and be happy for ever. (hint: use
> com.informatimago.common-lisp.cesarum.file:sexp-file-contents
> and com.informatimago.common-lisp.cesarum.utility:topological-sort)
>
For a radically simpler design that isn't backward compatible, see how
faslpath and quick-build did it. Quick-build wasn't portable, but it
was only 184 lines,
one quarter of Dan Barlow's initial hack, and 64 times less than the
current ASDF.
That said, the current ASDF contains a robust portable implementation
of the same idea, and I recommend it to all users for new developments.
See the ASDF documentation for package-inferred-system.
> For the implementation maintainers, the only thing is that asdf defines
> and require some common POSIX features. The problem here is that vendor
> have not yet defined a de-facto standard (a portability library
> eventually implemented by every implementation) for POSIX operation.
>
UIOP implements a good enough portability library for ASDF.
For more complete access to the OS, I recommend IOlib.
> Anyways, the point is that this workload ASDF requires on the part of
> implementation vendors or contributors for it's integration has to be
> executed in any case, be it in the other portability libraries or in the
> applications. It is a good thing for lisp developers to be able to
> rely on asdf (uiop) as a portability library for those features, thanks
> to ASDF ubiquity.
>
Yes, being able to portably (require "asdf") is great.
LispWorks 6.1 does it, but only has an antique ASDF 2 by now.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Law is always law of the strongest. The only question is what feedback
mechanism selects this strongest and controls his behavior.
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html