1. 20 Feb, 2018 3 commits
  2. 19 Feb, 2018 2 commits
  3. 17 Feb, 2018 2 commits
    • Eric Timmons's avatar
      Change apply to funcall in expansion of define-package · 21e3a85b
      Eric Timmons authored
      SBCL has been getting aggresive with checking arguments to functions. For some
      reason (as of SBCL 1.4.1), setting the package source location in define-package
      seems to trigger a source translation for the apply form that ends up producing
      (many) compilation notes that the arguments to ensure-package in the keyword
      positions are not constant, weakening keyword argument checking. We can get
      around that, however, by using a funcall directly.
    • Eric Timmons's avatar
      Evaluate sb-c:source-location after macroexpansion · ed0f4d5e
      Eric Timmons authored
      Tested on SBCL 1.4.4. If sb-c:source-location is evaluated during macro
      expansion, then the source location will always point to asdf.lisp (inside the
      define-package macro). If it is evaluated after macro expansion, it points to
      the right place.
  4. 16 Jan, 2018 2 commits
  5. 03 Jan, 2018 2 commits
    • Francois-Rene Rideau's avatar
      Better handle misnamed secondary systems · 069cd2a6
      Francois-Rene Rideau authored
      Distinguish between "syntactic" primariness ("foo" vs "foo/bar" names) and
      "semantic" primariness (system foo in foo.asd vs system foo in bar.asd),
      and use the right one at all right place: when checking if a system is
      up-to-date, what matters is that the old primary system is at the same
      place as before, and is up-to-date.
      Thinking about it, there is a lingering bug in case a definition-dependency
      are up-to-date, but were modified after the definition was read.
      What is really needed is a prepare-define-op. Sigh.
    • Francois-Rene Rideau's avatar
      Massage test-multiple to check non-reloading · 5397c994
      Francois-Rene Rideau authored
      Test whether ASDF is still confused by misnamed secondary systems:
  6. 18 Dec, 2017 3 commits
  7. 17 Dec, 2017 1 commit
  8. 15 Dec, 2017 2 commits
  9. 12 Dec, 2017 3 commits
  10. 06 Dec, 2017 1 commit
  11. 05 Dec, 2017 3 commits
    • Francois-Rene Rideau's avatar
      Fix upgrade issue with asdf/bundle. · 8e68ac22
      Francois-Rene Rideau authored
      Change implementation strategy for operation metadata methods
      bundle-type, gather-operation and gather-type.
      Upgrading from 3.1.7 or earlier yielded incorrect values for the metadata slots
      of the bundle operation classes, e.g.
      (gather-type (make-operation 'monolithic-lib-op))) was stuck to :STATIC-LIBRARY
      instead of its correct value :OBJECT since 3.2.0.
      The reason was that we were storing the value for this method in the :initform
      for the slot gather-type, which started as clever way of defining it as part of
      the DEFCLASS form for the class itself; however, this usage pattern does not
      work well with hot code upgrade: if the :initform changes during ASDF upgrade,
      the slot is already initialized, so its value isn't updated. That would require
      a method on UPDATE-INSTANCE-FOR-REDEFINED-CLASS, which hopefully should be
      invoked despite the fact that the shape of the class hasn't changed.
      A new slot won't be allocated because (a) we ensure that our operation classes
      are singleton classes using an *operations* cache, so objects are not
      reallocated, and (b) we define our slots with an :allocation :class, anyway.
      Remarkably, at least *some* of our changes in :initform have worked anyway,
      because when we transitioned allocation from :instance (default) to :class,
      that transition did force the computation of the new :initform, so the problem
      was hidden. But we're already out of luck with this upgrade from 3.1.7,
      and we must find a real solution.
      The Right Thing(tm) to do is to use DEFMETHOD to define specialized values.
      This commit does exactly that for the slots defined in bundle.lisp
      (and also used in concatenate-source.lisp). Ideally, we'd also do that
      for the slots defined in action.lisp and used in lisp-action.lisp, bundle.lisp
      and concatenate-source.lisp --- but there might or might not be clients
      in Quicklisp (or beyond Quicklisp) that this change would break.
      We must check backward compatibility, make sufficient announcement, etc. Sigh.
    • Francois-Rene Rideau's avatar
      Add a regression tests for upgrade · c54265da
      Francois-Rene Rideau authored
      Test more versions during upgrade tests.
    • Francois-Rene Rideau's avatar
      Improve test-bundle · 652d1c08
      Francois-Rene Rideau authored
  12. 01 Dec, 2017 2 commits
  13. 14 Nov, 2017 2 commits
  14. 12 Nov, 2017 2 commits
  15. 27 Oct, 2017 2 commits
  16. 26 Oct, 2017 3 commits
  17. 22 Oct, 2017 1 commit
  18. 21 Oct, 2017 1 commit
  19. 20 Oct, 2017 3 commits
    • Francois-Rene Rideau's avatar
      Extend the set of versions from which to test upgrade · bfbefcec
      Francois-Rene Rideau authored
      A recent manual test found a bug upgrading from 3.2.1.
      So include that in the test set.
      New policy: include first and last of the last few ASDF series, not just last.
    • Francois-Rene Rideau's avatar
      Rename stamp to timestamp in uiop/utility · c6654583
      Francois-Rene Rideau authored
      Restore backward compatibility with older versions of ASDF (before 3.3.0)
      by renaming stamp< and its friends to timestamp<, etc.
      Sometime in the lead-up to ASDF 3.3.0, I changed the encoding of infinities
      from NIL is -infinity and T is +infinity to T is -infinity and T is +infinity
      which made the code notably nicer on the ASDF side, because file-write-date
      would return directly the correct result instead of having to constantly switch
      between inverse conventions. However --- big mistake --- I kept the same
      function name, after checking that the functions had no user in Quicklisp,
      no one who had ever discussed them but me, and no documentation before 3.2.0
      except a single comment line for the entire family of functions.
      This doesn't matter as long as ASDF and UIOP are kept in synch, but such is
      not the case with Quicklisp, where Xach both welcomes recent UIOP releases
      but refuses to include updates to ASDF itself. Then, loading a new UIOP
      with reverse conventions totally confuses the old ASDF, and causes spurious
      rebuilds of everything after UIOP is loaded -- multiple times if present
      in multiple phases (that and slower build times is how Xach noticed the bug).
      The solution adopted is to give a new name to the functions with a different
      convention -- timestamp< instead of stamp<, and so on. Therefore,
      the new ASDF 3.3.1 will expect the new convention from UIOP 3.3.1,
      that will no longer overwrite the functions from ASDF 3.2.1 and older with
      backward-incompatible variants. If an old ASDF 3.2.1 or earlier loads
      a newer UIOP 3.3.1 or later, it will keep using the old functions:
      the symbols for these functions will be uninterned, but
      the values for these functions which won't be clobbered anymore.
      Backward compatibility is a strong requirement not to to break lightly,
      not even in a subtle way, not even if "nobody else is using it" ---
      an older version of ASDF is already "somebody else" with respect to UIOP.
    • Francois-Rene Rideau's avatar
      Add upgrade test for UIOP issue that Xach found. · 40020f7d
      Francois-Rene Rideau authored
      UIOP 3.3.0 loaded on top of an earlier ASDF 3 would cause everything to be
      spuriously rebuilt, because of a change of representation of stamp< arguments.
      This test evidences the breakage, and the fix.