1. 07 Mar, 2013 1 commit
  2. 13 Jan, 2013 1 commit
  3. 11 Oct, 2012 1 commit
    • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      Refactor PATHNAME implementation details to tighten existing semantics. · 094f6d21
      None of this should change the behavior of CL:PATHNAME, but it
      prepares for that in subsequent patches to address problems in merging
      when the defaults points to a JAR-PATHNAME.
      Fix COMPILE-FILE to work with source located in jar archive.
      Moved Utilities.getFile() to instance method of Pathname which makes
      more logical sense.  Moved Utilities.getPathnameDirectory() to static
      instance classes.  These functions no longer merge their argument with
      *DEFAULT-PATHNAME-DEFAULTS*, as this should be done explictly at a
      higher level in the Lisp calling into Java abstraction.
      RENAME-FILE no longer on namestrings, but instead use the result of
      TRUENAME invocation, as namestrings will not always roundtrip
      exactly back to PATHNAMES.
      POPULATE-ZIP-FASL no longer forms its argumentes by merging paths,
      instead using MAKE-PATHNAME with controlled defaults.
      rather than namestrings.
      Compiler now dumps pathname in alternate form that preserves DEVICE
  4. 21 Oct, 2011 1 commit
  5. 20 Sep, 2011 2 commits
  6. 19 Sep, 2011 1 commit
  7. 20 Aug, 2011 1 commit
  8. 08 Jul, 2011 1 commit
    • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      Fasls are no no longer created with *PRINT-READABLY*. · 99417cf1
      This fixes #156 in which the compiler could no longer dump forms into
      the fasls containing arrays of (UNSIGNED-BYTE 32) because in r13274 we
      required that all forms be created with a non-nil *PRINT-READABLY*.
      Presumably, SimpleArray_UnsignedByte32.writeToString() signals an
      error when invoked with a non-NIL *PRINT-READABLY* because the
      resulting read of the form will not necessarily be of the specified
      base type.
      With this change, we restore ABCL's behavior before r13274 to fix
      #147, which is to read a create a less precise type from the fasl.
      The more correct solution would be to dump some aspects of the fasls
      directly into JVM code that would perform the stricter intialization.
      Tests added for both cases to ensure this remains fixed.
  9. 04 May, 2011 1 commit
  10. 19 May, 2010 1 commit
  11. 02 May, 2010 1 commit
  12. 18 Jan, 2009 1 commit
  13. 20 Dec, 2008 1 commit