1. 29 Oct, 2011 2 commits
  2. 24 Oct, 2011 1 commit
  3. 23 Oct, 2011 2 commits
  4. 22 Oct, 2011 1 commit
  5. 20 Oct, 2011 1 commit
  6. 18 Oct, 2011 3 commits
  7. 17 Oct, 2011 1 commit
  8. 13 Oct, 2011 6 commits
  9. 12 Oct, 2011 1 commit
  10. 10 Oct, 2011 1 commit
  11. 09 Oct, 2011 1 commit
  12. 07 Oct, 2011 1 commit
  13. 06 Oct, 2011 2 commits
  14. 25 Sep, 2011 1 commit
  15. 14 Sep, 2011 1 commit
  16. 12 Sep, 2011 4 commits
  17. 02 Sep, 2011 4 commits
    • Robert P. Goldman's avatar
      Bumping the version. · 8f5e2d90
      Robert P. Goldman authored
    • Robert P. Goldman's avatar
      New fix for reuse of COMPONENTS based on REINITIALIZE-INSTANCE mehtods. · 97c5462a
      Robert P. Goldman authored
      Thanks to Christophe Rhodes for suggestions.  We use
      REINITIALIZE-INSTANCE to clear out-of-date information out of the slots
      of COMPONENT objects while they are reused.
      Two complications presented themselves:
      1.  Previously, I believe for orthogonality, we would either get an old
      (reused) COMPONENT or make a new one, but in either case, the handling
      of initargs was done by REINITIALIZE-INSTANCE.  This made it impossible
      for the REINITIALIZE-INSTANCE methods to "know" that they were in a real
      sense RE-initializing.  At the expense of some code duplication, I broke
      this sharing, so that now REINITIALIZE-INSTANCE should only be called
      when we are reusing a COMPONENT, with an exception below...
      2.  We always need to have a SYSTEM object active for the defsystem we
      are currently processing.  Accordingly,  SYSTEM objects will *ALWAYS*
      be RE-initialized.  So the REINITIALIZE-INSTANCE method required a
      little care (in particular, the SOURCE-FILE slot needed delicate
    • Robert P. Goldman's avatar
    • Robert P. Goldman's avatar
      Partial solution to Xach's bug from reused system COMPONENT OBJECTS. · ef7dfd39
      Robert P. Goldman authored
      Unfortunately, this doesn't work in general because of other problems with
      the reuse of  pre-existing SYSTEM COMPONENT objects.
  18. 26 Jul, 2011 1 commit
  19. 16 Jun, 2011 1 commit
  20. 12 Jun, 2011 1 commit
    • Francois-Rene Rideau's avatar
      2.016.2: Enhancements for MCL pathname and logical-pathname users. · 86b7de25
      Francois-Rene Rideau authored
      Major change for RMCL: location strings are now POSIX namestrings.
      Major change for logical pathnames: they are now preserved by source-registry;
      the price is that only logical pathnames for which merging the name and type
      commutes with truename will be found by directory-files and subdirectories.
      Minor change for GCL: dropped kluges for 2.6, which never was working.
      Simplifications in internals of (implementation-identifier).
      Removed *system-cache* and get-uid, which never were working right
      (bad attempts at allowing common-lisp-controller compatibility,
      but it only ever was but a giant gaping security hole in the waiting).
      Simplified resolve-relative-location-component
      (ugly because it was written before MERGE-PATHNAMES*).
      Updated documentation about the file location DSL.
  21. 09 Jun, 2011 1 commit
    • Francois-Rene Rideau's avatar
      2.016.1: Fixes for ABCL, GCL; tweaks for LispWorks and CCL. · 9ece06df
      Francois-Rene Rideau authored
      Use probe-file for probe-file* in LispWorks.
      Make ABCL's jar translation happier with
      the recent compile-file-pathname* change for Stelian by redoing cfp myself.
      Make truenamize work when the merged pathname is relative.
      Makes it happier when e.g. the *default-pathname-defaults* is #p"",
      which is the case notably on CCL.
      Try and fail to support GCL 2.6 and have 2.7 fail less;
      too many bugs, in CONDITIONs, PATHNAMEs, and more,
      plus compiler bug that breaks coerce-pathname.
  22. 07 Jun, 2011 2 commits
  23. 06 Jun, 2011 1 commit
    • Francois-Rene Rideau's avatar
      2.015.11: naming tweaks for CLISP. · d8b24967
      Francois-Rene Rideau authored
      Magically recognize x64 as architecture on CLISP (yuck).
      Document (require "asdf") as the portable way to load ASDF,
      since the CLISP maintainers insist that they won't recognize
      the otherwise universally accepted (require :asdf). Sigh.