1. 19 Aug, 2018 1 commit
  2. 17 Aug, 2018 8 commits
  3. 13 Aug, 2018 1 commit
  4. 05 Aug, 2018 2 commits
    • Francois-Rene Rideau's avatar
      Fix and tweak the .asd files · c09b3664
      Francois-Rene Rideau authored
      Include definition for call-without-redefinition-warnings in asdf.asd
      since we don't depend on loading uiop.asd anymore.
      
      Also tweak the #+asdf3 and #+asdf3.1 options in the main defsystem
      so there is only a couple conditional markers per version,
      making the file more readable.
      
      Revise some comments.
      c09b3664
    • Robert P. Goldman's avatar
      Bump version to 3.3.2.5 · 8ffa6386
      Robert P. Goldman authored
      8ffa6386
  5. 03 Aug, 2018 3 commits
  6. 02 Aug, 2018 1 commit
  7. 31 Jul, 2018 2 commits
  8. 29 Jul, 2018 1 commit
  9. 05 Jun, 2018 1 commit
  10. 02 Jun, 2018 2 commits
  11. 04 May, 2018 1 commit
  12. 07 Mar, 2018 2 commits
  13. 01 Mar, 2018 1 commit
  14. 20 Feb, 2018 1 commit
  15. 19 Feb, 2018 1 commit
  16. 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.
      21e3a85b
    • 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.
      ed0f4d5e
  17. 16 Jan, 2018 1 commit
  18. 18 Dec, 2017 1 commit
  19. 17 Dec, 2017 1 commit
  20. 12 Dec, 2017 1 commit
  21. 14 Nov, 2017 1 commit
  22. 26 Oct, 2017 2 commits
  23. 20 Oct, 2017 1 commit
    • 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.
      c6654583
  24. 12 Oct, 2017 1 commit
  25. 06 Oct, 2017 1 commit