Starting November 9th, common-lisp.net's Gitlab instance has implemented a more open account policy, allowing anyone with a GitHub or Google account to create an account on our instance.

At the same time, the login policy has started to require 2-factor authentication (2FA).

See https://mailman.common-lisp.net/pipermail/clo-devel/2018-October/001232.html for discussion.

  1. 06 Feb, 2014 1 commit
  2. 09 Oct, 2012 1 commit
  3. 08 Oct, 2012 1 commit
  4. 01 Oct, 2012 1 commit
  5. 30 Sep, 2012 1 commit
  6. 12 Sep, 2012 1 commit
  7. 05 Feb, 2012 1 commit
  8. 19 Oct, 2011 1 commit
  9. 02 Oct, 2011 1 commit
  10. 06 Sep, 2011 1 commit
  11. 02 Aug, 2011 1 commit
  12. 05 Jul, 2011 1 commit
  13. 04 Jul, 2011 3 commits
  14. 21 Jun, 2011 1 commit
    • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      Fix problems with whitespace in JAR-PATHNAME. · 07c45f9e
      For dealing with URI Encoding (also known as [Percent Encoding]() we
      implement the following rules which were implicitly.
      
      [Percent Encoding]: http://en.wikipedia.org/wiki/Percent-encoding
      
      1.  All pathname components are represented "as is" without escaping.
      
      2.  Namestrings are suitably escaped if the Pathname is a URL-PATHNAME
          or a JAR-PATHNAME.
      
      3.  Namestrings should all "round-trip":
      
          (when (typep p 'pathname)
             (equal (namestring p)
                    (namestring (pathname p))))
      
      Users may use EXT:URI-ENCODE and EXT:URI-DECODE to access the escaping
      rules in circumstances where they wish to manipulate PATHNAME
      namestrings more directly.
      
      All tests in JAR-PATHNAMES now pass.
      
      Constructors for PATHNAME now produce ERROR rather than FILE-ERROR as
      CLHS says "The type file-error consists of error conditions that occur
      during an attempt to open or close a file, or during some low-level
      transactions with a file system," which doesn't apply here.
      07c45f9e
  15. 20 Mar, 2011 1 commit
  16. 27 Nov, 2010 1 commit
  17. 15 Apr, 2010 2 commits
  18. 26 Mar, 2010 3 commits
  19. 18 Mar, 2010 1 commit
  20. 15 Mar, 2010 1 commit
  21. 14 Mar, 2010 1 commit
  22. 11 Mar, 2010 1 commit
  23. 22 Feb, 2010 1 commit
  24. 08 Feb, 2010 1 commit
  25. 06 Feb, 2010 1 commit
    • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
      Extensively reworked new implementation for specifiying jar pathnames. · fe838110
      Pathname namestrings that have the form "jar:URL!/ENTRY" now construct
      references to the ENTRY within a jar file that is located by URL.  The
      most common use is the "file:" form of URL
      (e.g. 'jar:file:/home/me/foo.jar!/foo.lisp') although any valid syntax
      accepted by the java.net.URL constructor should work (such as
      'jar:http://abcl-dynamic-install.googlecode.com/files/baz.jar!/a/b/eek.lisp').
      
      The internal structure of a jar pathname has changed.  Previously a
      pathname with a DEVICE that was itself a pathname referenced a jar.
      This convention was not able to simultaneously represent bothjar
      entries that were themselves jar files as occurs with packed FASLs
      within JARs and devices which refer to drive letters under Windows.
      Now, a pathname which refers to a jar has a DEVICE which is a proper
      list of at most two entries.  The first entry always references the
      "outer jar", and the second entry (if it exists) references the "inner
      jar".  Casual users are encouraged not to manipulate the "internal
      structure" of jar pathname by setting its DEVICE directly, but instead
      rely on namestring <--> pathname conversions.
      
      Jar pathnames are only currently valid for use with LOAD, TRUENAME,
      PROBE-FILE and pathname translation related functions (such as
      MERGE-PATHNAMES, TRANSLATE-PATHNAME, etc.)  Passing one to OPEN
      currently signals an error.  Jar pathnames do not currently work
      with DIRECTORY or PROBE-DIRECTORY.
      
      Jar pathnames work for ASDF systems packaged within JARs.  We override
      ASDF:LOAD-OP to load ASDF from JAR Pathnames by bypassing compilation
      if the output location would be in a JAR file.  Interaction with
      ASDF-BINARY-LOCATIONS is currently untested.
      
      Pathname now used as the basis of ABCL's internal routines for loading
      FASLs replacing the use of strings, which simplifies a lot of the
      behavior in looking for things to LOAD.
      
      Fixed nasty shared structure bug on MERGE-PATHNAMES by implementing
      (and using) a copy constructor for Pathname.
      
      Implemented SYS:PATHNAME-JAR-P predicate for jar pathnames.
      
      Removed ZipCache as it is no longer used now that we are using JVM's
      implicit JAR caching.
      
      WRITE-FILE-DATE works for jar pathnames, returning 0 for a
      non-existent entry.
      
      JAR-FILE tests now include loading FASLs from network location, which
      means that these tests will fail if there is no network
      connectivity. The tests initialization rewritten in Lisp, so it works
      under Windows.
      
      Allow of a top directory for creating hierarchially ZIPs with SYS:ZIP.
      There is now a three argument version--PATHNAME PATHNAMES &OPTIONAL
      TOPDIR--whereby all pathnames will be interpolated relative to topdir.
      
      Implementation of SYS:UNZIP to unpack ZIP/JAR files.
      
      JAR files always use '/' to name hierarchial entries. Pathname
      translates '/' --> '\' under isPlatformWindows for all hierarchy
      *except* reference to jar entries.
      
      Pathname URL constructor under Windows to properly parses the
      drive letter.
      
      Ensure that *EXT:LISP-HOME* contains a directory.
      
      
      Removed unused imports.
      
      Converted Primitives to stack-trace friendly form where we touched the
      source extensively anyways.
      fe838110
  26. 31 Jan, 2010 1 commit