#95: URL Pathnames
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: enhancement | Status: new
Priority: major | Milestone: 0.20
Component: other | Version:
Keywords: |
-------------------------+--------------------------------------------------
Goals
-----
1. Use Common Lisp pathnames to refer to representations referenced
by a URL.
2. The URL schemes supported shall include at least "http", and those
enabled by the URLStreamHandler extension mechanism.
3. Use URL schemes that are understood by the java.net.URL object.
A file specified by URL
#p"http://example.org/org/armedbear/systems/pgp.asd"
4. MERGE-PATHNAMES
(merge-pathnames "url.asd"
"http://example/org/armedbear/systems/pgp.asd")
==> "http://example/org/armedbear/systems/url.asd"
5. PROBE-FILE returning the state of URL accesibility.
6. TRUENAME "aliased" to PROBE-FILE signalling an error if the URL is
not accessible (see "Non-goal 1").
7. DIRECTORY for non-wildcards
8. URL pathname work as a valid argument for OPEN with :DIRECTION :INPUT.
9. Enable the loading of ASDF2 systems referenced by a URL pathname.
10. The reserved URL characters (`~`, `/`, `?`, etc.) shall be
encoded in the proper manner on construction of the Pathname.
11. The "file" scheme will continue to be represented by an
"ordinary" Pathname.
12. The "jar" scheme will continue to be represented by a jar
Pathname.
Non-goals
---------
1. We will not implement canonicalization of URL schemas (such as
following
"http" redirects).
2. DIRECTORY working for URL pathnames containing wildcards.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/95>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#89: compiler stack inconsistency
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version: 0.20
Keywords: |
----------------------+-----------------------------------------------------
In checking out the latest ASDF, I was able to factor out the following
case of the compiler generating stack inconsistency:
{{{
(defun get-uid (stream uid-string)
(with-input-from-string (stream uid-string)
(read-line stream)
(handler-case (parse-integer (read-line stream))
(error () (error "Unable to find out user ID")))))
}}}
Loading the generated code causes a java.lang.VerifyError to be thrown.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#92: Characters created with invalid code points
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: 0.20
Component: CLOS | Version:
Keywords: |
------------------------+---------------------------------------------------
ABCL will happily create characters in the range #xD800 to #xDFFF and
above #x10FFFF. These refer to invalid unicode code points and should not
be allowed.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/92>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#86: No restarts available on error in thread
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: 0.19
Component: libraries | Version:
Keywords: |
------------------------+---------------------------------------------------
Evaluating the following
(threads:make-thread #'(lambda () (error "foof")) :name "foof")
will get you into the debugger. But there's not restart available.
As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an
error occuring in a thread, I think there should be a TERMINATE-THREAD
restart instead.
And the debugger should probably print the thread's name the error
occured in.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/86>
armedbear <http://common-lisp.net/project/armedbear>
armedbear