How would you feel...

[Robert P. Goldman]

Faré wrote:

>> But seriously, waiting until the first bugfixes show up doesn't work
>> well unless *somebody* runs the initial release and tests it in actual
>> day-to-day use.
>>
> I always use the latest asdf, but the range of things I use day to day
> is limited. At least, the basic functionality,
> package-inferred-system, run-program and image dumping are kept in
> working order (plus cffi extensions, that I rely on).

I don't use the latest ASDF day in and day out, because it's important
that I not break things for my co-workers by using features that are
only available in the bleeding edge.

Also, no one at our site (including me!) uses any of the configuration
DSLs. We all use old established code that manipulates
ASDF:*CENTRAL-REGISTRY*.  TBH, I don't know how to debug failures with
the registry DSL, so I have stayed away.  I know the DSL scales better,
but don't have anything ITA-scale where that matters.

We don't use image dumping, either.
> 
>> It would be nice to figure out a way that ASDF could work nicely with
>> the implementations so that implementors have an easy option to use the
>> latest ASDF patch version day-to-day and see how well it plays with the
>> latest version of the CL implementation.
>>
> As long as implementations offer ASDF 3, it's trivial to install asdf
> in your source-registry and let it upgrade itself. And now, all
> implementations do, at least all those that are maintained except gcl.
> All but clisp (and maybe allegro express) provide 3.1, so your
> source-registry now automatically includes ~/common-lisp/ so that's
> all even easier. If you want to test a recent asdf, just unpack the
> source (and/or git clone it) into ~/common-lisp/asdf/ — and if you're
> using clisp or are stuck with and old unupdatable allegro-express,
> then use asdf/tools/install-asdf.lisp to override your
> implementation's old asdf with a newer one.

That's true, but I don't get any sense that any of the implementor's are
actually running pre-release versions before shipping.

And I think that a lot of the implementation-specific code in UIOP could
be done better by the implementors than us guessing how the
implementations work.

Best,
r