1- While the trivial convenience function bundle-system was removed, the underlying functionality still exists. The function was ill-named legacy of dubious value. Do ABCL users actually use this function as such?
2- On the other hand, its removal is a bit brutal. It might have been better to use the gradual removal strategy we were thinking of in branch obsolete-function-warnings. Maybe there's a case for reversing this removal before next release, and instead completing and merging that branch and using it. I however do not volunteer for the job at this point.
3- I merged part of this pull request into 3.1.7.13.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
On Sun, Sep 11, 2016 at 8:32 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
On Sun, Sep 11, 2016 at 8:12 AM, Daniel Kochmański daniel@turtleware.eu wrote:
Hey,
now all MKCL tests pass as expected. I've also disabled load-bundle-op as a default option (seems like a MKCL bug):
I'll have to look deeper into that load-bundle-op question...
The issue with the system modules is caused by a muss in the systems definitions of MKCL. Namely asd files are bogus – for instance there is (repeated) cmp.asd definition in contrib/ directory pointing and cmp.a file, but the latter isn't present there. `locate-system' takes the cmp.asd from the contrib/ directory and can't inject proper module. I've disabled for mkcl find-system check, but mkcl will fail, if any asd system has "cmp" in `:depends-on' (and this is not a regression, it was like this before and is a problem with mkcl asd files).
Yep, that's a bug. I had not noticed that bogus cmp.asd before now, that's bad.
Long story short – everything is as fine as was before this "wave of change".
Thanks, I'll give the test suite one more spin as soon as I get an opportunity, just to confirm.