Andreas Davour wrote:
On Wed, 27 May 2015, Faré wrote:
[snip]
My SBCL is at 3.1.3. I think 3.1.4 is solid enough that it should be updated there.
I've bugged SBCL hackers many time since last october, to no avail.
But remember hwo it looks like from the outside, though.
You are changing the third number, which will look like a patch to a minor revision. They probably wont bother with updating (if it's any amount of work) unless they see 3.2 or 4.0 is my guess. That's how I would think.
Actually, if I was them, I wouldn't bother updating until I saw 3.2.1! ;-)
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.
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.
Cheers, r
You are changing the third number, which will look like a patch to a minor revision. They probably wont bother with updating (if it's any amount of work) unless they see 3.2 or 4.0 is my guess. That's how I would think.
Actually, if I was them, I wouldn't bother updating until I saw 3.2.1! ;-)
Well, our stable releases used to be two-digits versus three-digits for the unstable ones; these days it's three digits for the stable releases vs four-digits for development patches.
The who point of stable releases is that we can tell the world: these versions have received extensive testing and can be vouched for, whereas these don't.
Which makes me feel queasy about some implementations delivering development versions of ASDF (e.g. Allegro delivering 3.0.2.3 or 3.1.4.3, or CLISP being stuck at 3.0.2.26). It's fine if there's a bug that affects their implementation and is fixed at that patch level *and* they promptly upgrade to the next stable release. But making lingering for months or years on such unsupported intermediate version is poor practice.
ccl is always prompt at updating (thanks, rme). cmucl, abcl do it as part of their release cycle. So does lispworks, except it releases only every so many years. sbcl and ecl are lagging a bit (a lot these days), but generally not doing too bad. mkcl is lagging a lot. gcl doesn't reply to my bug reports. mocl, scl, xcl are dead. clasp is newborn.
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).
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Question authority... but raise your hand first.
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
-
Faré -
Robert P. Goldman