#16: Re-evaluation of DEFPACKAGE form is ignored
--------------------------+-------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone: unscheduled
Component: other | Version: 1.0
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment(by mevenson):
As far as I understand a quick analysis of SBCL which is also a multi-
threaded Lisp, to implement this we would have to:
1. create a global mutex WITH-PACKAGES for FIND-PACKAGE, MAKE-PACKAGE,
RENAME-PACKAGE, DELETE-PACKAGE, LIST-ALL-PACKAGES, INTERN, UNINTERN,
EXPORT, UNEXPORT, IMPORT, SHADOWING-IMPORT, SHADOW, USE-PACKAGE, UNUSE-
PACKAGE, and FIND-ALL-SYMBOLS.
2. Check that nicknames are not being used as the redefined name (??)
3. Warn about various changes (like unusing previously used packages)
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/16#comment:2>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#16: Re-evaluation of DEFPACKAGE form is ignored
--------------------------+-------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: enhancement | Status: new
Priority: minor | Milestone: unscheduled
Component: other | Version: 1.0
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment(by mevenson):
At a minimum in the near term we should warn the user of this behavior.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/16#comment:1>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#38: CLOS :metaclass support
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: |
------------------------+---------------------------------------------------
Blake McBride reports:
Running the code:
(defclass meta-class1 (standard-class)
(cv1 cv2 cv3)
(:metaclass standard-class))
(defclass class1 (standard-object)
(iv1 iv2 iv3)
(:metaclass meta-class1))
The second object returns:
#<STANDARD-CLASS CLASS1 {F673CC}>
It should be:
#<META-CLASS1 CLASS1 {F673CC}>
Not only is it reporting the wrong class of class1 but it doesn't work
either. I suppose ABCL doesn't support the :metaclass option. It just
ignores it. The problem is that without that option ABCL's CLOS is
severely limited. Any plans to fix this?
Thanks.
Blake McBride
--
Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/38>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#79: Identically named gensymed coalesced into same object in fasl file
-------------------------+--------------------------------------------------
Reporter: trittweiler | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: CLOS | Version:
Keywords: |
-------------------------+--------------------------------------------------
From: Erik Huelsmann
Date: Mon, Jan 11, 2010 at 11:40 PM
Subject: Re: [armedbear-devel] [Bug] Identically named gensymed
coalesced into same object in fasl file
To: "Tobias C. Rittweiler"
Hi Tobias,
Thanks for your report. This issue has long been in ABCL and it's not
fixed yet.
I have known about this problem for a while, but was kind of hoping it
wouldn't show up in practice. I guess it did.
This is what happens: when reading, the fasl loader creates an
anonymous package in which it interns uninterned symbols. It "has" to
do that, because ABCL doesn't store references to the actual unique
objects everywhere; instead it stores the textual representation in
some places. These symbols get coalesced by use of the anonymous
package.
So, generally the system of coalescing is something inherent to this
idea. The idea is wrong enough for you to run into and get bitten by
it.
We'll have to come up with a better idea. Can you add the mail message
below to our issue tracker?
BTW: Did you happen to find this issue by accident? How did you find it?
Bye,
Erik.
On Mon, Jan 11, 2010 at 10:35 PM, Tobias C. Rittweiler wrote:
>
> I'm currently running an old checkout ("0.17.0-dev"), so the issue may
> have been fixed meanwhile.
>
> ### /tmp/foo.lisp
> (eval-when (:load-toplevel :execute)
> (let ((a '#:foo)
> (b '#:foo))
> (setf (fdefinition 'foo) (lambda () (values a b)))))
>
> (eval-when (:load-toplevel :execute)
> (format t "~&(multiple-value-call #'eq (foo)) => ~S~%"
> (multiple-value-call #'eq (foo))))
> ###
>
> CL-USER> (compile-file "/tmp/foo.lisp")
> ; Compiling /tmp/foo.lisp ...
> ; (LET (# #) ...)
> ; (FORMAT T ...)
>
> ; Compilation unit finished
> ; The following functions were used but not defined:
> ; FOO
>
> ; Wrote /tmp/foo.abcl (0.034 seconds)
> #P"/tmp/foo.abcl"
> NIL
> NIL
>
> That warning is bogus. There some work in this area so this bit may be
> fixed already.
>
> The actual issue of my mail is this one, though:
>
> CL-USER> (load *)
> (multiple-value-call #'eq (foo)) => T
> T
>
> As you can see, ABCL coalesces the two identical named gensyms into the
> same object in the fasl file.
>
> While 3.2.4.2.2 does specify that
>
> Two apparently uninterned symbols S and C are similar if their names
> are similar.
>
> ABCL's behavior is still wrong because 3.2.4.1 says
>
> If two literal objects appearing in the source code for a single file
> processed with the file compiler are the [sic] identical, the
> corresponding objects in the compiled code must also be the
> identical. __With the exception of symbols and packages__, any two
> literal objects in code being processed by the file compiler may be
> coalesced if and only if they are similar; __if they are either both
> symbols or both packages, they may only be coalesced if and only if
> they are identical__.
>
> -T.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/79>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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