Re: Patch to UIOP/LISP-BUILD:GET-OPTIMIZATION-SETTINGS for SBCL

[Robert P. Goldman]

Douglas Katzman wrote:
 Hi ASDF developers,
 
 I'm changing SB-C::*POLICY* from a list to a struct. (This yields us a
 nice compile-file speedup.)
 Instead of accessing the global policy with (CDR (ASSOC ...)) it should
 be accessed with (SB-C::POLICY-QUALITY) as per the attached diff.
 This function has been present since 2000-12-29 and the interface is
 unchanged, so a new ASDF can work just fine with an older SBCL. The
 reverse is not possible. I'll patch the ASDF that ships with SBCL.
 
 Doug

I will apply this to ASDF and run the tests.  If all goes well, I'll
push it to cl.net this morning.

cheers,
R

Re: New version of ASDF pushed

[Faré]

 Actually, I don't think there's anything new asdf that warrants a feature,
 so I'd add a uiop feature only (and uiop has evolved enough since 2.27
 that a feature could help, especially considering that at least
 quicklisp distributes uiop without asdf). I believe uiop/driver.lisp
 is the correct place for the pushnew.

 OK. Should we at some point define a stable UIOP feature set, and just
 bump to 3.0 as a new stable point?

I suppose whenever you release 3.2 (hopefully this year) is the best time
to decree that whatever is in UIOP is the new stable point, and then to apply
usual deprecation policies to any API change.

Of course, it would be nice if deprecation support functions were made
part of UIOP
before this happens, though not strictly necessary.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
During the Bikini operations, a discussion arose as to what weapons would be
used in the next war–atom bombs, germs, rockets.
“I don’t know what weapons will be used in the next war,” a young Army
lieutenant interrupted, “but in the war after the next one, surer than hell
they’ll be using bows and arrows and spears.” — Joe Laitin in Frontpage, 1946