SBCL 1.4.3 ships with ASDF 3.3.1, and a number of Quicklisp projects have build problems as a result. Linedit, mgl, micmac, cl-string-match, and others are affected.
Here is a build failure report for yesterday. (You can ignore the gendl failures - it's a special case.) If anyone has ways to fix these projects, please do so as soon as you can - otherwise they will be removed from the January Quicklisp dist update in a few weeks.
Pull requests to make those system work were sent many months ago. The question is whether anyone is willing to fork these systems and maintain them on e.g. sharplispers, since they have been silently abandoned by their authors.ReplyDelete
Are the errors not in red "gentle failures" ? Thanks.ReplyDelete
The non-red errors are old. Red failures are new since the last dist release.Delete
It'd be great to correct all errors...
If I patch the ASDF bundled with SBCL, will you keep these projects?ReplyDelete
If projects work with SBCL, they will be included. I don't know if that helps other implementations any though.Delete
I've noticed some projects are not careful with *readtable*, and cause global changes to it that can escape to break other systems.ReplyDelete
I suggest quicklisp be modified so the call to asdf:load-system is wrapped in (let ((*readtable* (copy-readtable nil))) ...) so this escape cannot occur. This may break projects that were depending on the readtable being modified, but that's a bug that would need to be fixed.
(Note that COMPILE-FILE and LOAD are defined to rebind *readtable* at entry; however, the readtable object itself may still be modified if it isn't explicitly copied.)
Do you have an example in mind?Delete
cl-ana appears to dangerous call set-dispatch-macro-character in several files.Delete
cl-m4 in test/m4.lsp
I'm sure there are others.
fixed-20170124-git/test/test.lisp (calls install-q-reader, which modifies *readtable* object.)
There may be more.
Thanks. I'm not interested in using Quicklisp to enforce this kind of state safety.Delete
do you mean such changes should be done in ASDF side?Delete
I don't think they should be done at all. I don't like accidental changes to global state, but I also don't like the removal of the option to intentionally modify the global state.Delete
Changes *are* being done on the ASDF side.Delete
However, though it isn't clear what the Right Thing™ is, at least in the short run: ideally, all implementations would make their standard readtable read-only, no system would try to side-effect the shared readtable that is current at the beginning of the build, and that read-only standard readtable is what would be used. But we're not there yet. There are lots of libraries to fix. Good luck.
Xach, the option to *intentionally* modify the global state remains and will remain forever.Delete
Actually, the short term plan is to be fully backward compatible, by making the shared readtable (new concept; to be used by all ASDF systems) be the initial readtable (new concept; the one that was current when ASDF itself was loaded).
In the long run, I would have liked the shared readtable by default to be the read-only standard readtable. But I'm not going to be there in the long run anyway, so my preference doesn't matter.
Paul, see the syntax-control branch of ASDF and its syntax-control.md document (in the making since 2014, hopefully merged in the upcoming 3.3.2):ReplyDelete
Thanks. I'll look at that. I'm glad others are well ahead of me on this issue.ReplyDelete
It could be interesting to modify ASDF or Quicklisp to detect changes in global state, without necessarily enforcing a policy, so the extent of the problems, at least in Quicklisp, could be evaluated.