2018-01-16

Build failures with ASDF 3.3.1

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.

16 comments:

  1. 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
  2. Are the errors not in red "gentle failures" ? Thanks.

    ReplyDelete
    Replies
    1. The non-red errors are old. Red failures are new since the last dist release.

      It'd be great to correct all errors...

      Delete
  3. If I patch the ASDF bundled with SBCL, will you keep these projects?

    ReplyDelete
    Replies
    1. If projects work with SBCL, they will be included. I don't know if that helps other implementations any though.

      Delete
  4. I've noticed some projects are not careful with *readtable*, and cause global changes to it that can escape to break other systems.

    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.)

    ReplyDelete
    Replies
    1. Do you have an example in mind?

      Delete
    2. cl-ana appears to dangerous call set-dispatch-macro-character in several files.

      cl-m4 in test/m4.lsp

      I'm sure there are others.

      Delete
    3. cl-parallel-20130312-git/src/future.lisp

      cl-string-match-20171227-hg/src/pre.lisp

      evol-20101006-git/src/heredoc.lisp

      fixed-20170124-git/test/test.lisp (calls install-q-reader, which modifies *readtable* object.)

      folio-20130128-git/collections/map-syntax.lisp
      folio-20130128-git/collections/sequence-syntax.lisp
      folio-20130128-git/collections/set-syntax.lisp

      folio2-20170403-git/src/as-syntax.lisp
      folio2-20170403-git/src/maps-syntax.lisp
      folio2-20170403-git/src/sequences-syntax.lisp

      graylex-20110522-git/examples/graylex-m4-example.lisp

      There may be more.

      Delete
    4. Thanks. I'm not interested in using Quicklisp to enforce this kind of state safety.

      Delete
    5. do you mean such changes should be done in ASDF side?

      Delete
    6. 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
    7. Changes *are* being done on the ASDF side.

      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.

      Delete
    8. Xach, the option to *intentionally* modify the global state remains and will remain forever.

      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.

      Delete
  5. 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):

    https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86
    https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md

    ReplyDelete
  6. Thanks. I'll look at that. I'm glad others are well ahead of me on this issue.

    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.

    ReplyDelete