armedbear-ticket

armedbear-ticket@common-lisp.net

633 discussions

[armedbear-ticket] [armedbear] #103: DOCUMENTATION doesn't seem to autoload properly
by armedbear 28 Aug '10

28 Aug '10

#103: DOCUMENTATION doesn't seem to autoload properly --------------------------+------------------------------------------------- Reporter: vvoutilainen | Owner: nobody Type: defect | Status: new Priority: minor | Milestone: 0.22 Component: libraries | Version: 0.21 Keywords: autoload | --------------------------+------------------------------------------------- Here's a transcript from my repl session: CL-USER(1): (documentation 'append 'function) #<THREAD "interpreter" {9260EE}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function DOCUMENTATION is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to DOCUMENTATION. 3: TOP-LEVEL Return to top level. [1] CL-USER(2): (documentation 'append 'function) NIL DOCUMENTATION seems to load after the initial error, but if it's the first function invoked in the REPL, it doesn't seem to quite work. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/103> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #101: lambda list checking optimizes away dispatch macros which return nil
by armedbear 25 Jun '10

25 Jun '10

#101: lambda list checking optimizes away dispatch macros which return nil -----------------------------------------+---------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: lambda list, dispatch macro | -----------------------------------------+---------------------------------- After [r12693][1], dispatch macros which return nil are stripped from processing in lambda lists. For example {{{ CL-USER> (defun foo (&key (this :that)) this) CL-USER> (foo :this (#+:nil :other)) Odd number of keyword arguments. [Condition of type PROGRAM-ERROR] }}} Among other things, this causes [usocket][2] to fail to load, erroring with the slightly mysterious "Unrecognized keyword argument :NAME" as reported by Kevin Raison. [1]: http://trac.common-lisp.net/armedbear/changeset/12693 [2]: http://common-lisp.net/project/usocket/ -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/101> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

Re: [armedbear-ticket] [armedbear] #16: Re-evaluation of DEFPACKAGE form is ignored
by armedbear 19 May '10

19 May '10

#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

1 0

Re: [armedbear-ticket] [armedbear] #16: Re-evaluation of DEFPACKAGE form is ignored
by armedbear 19 May '10

19 May '10

1 0

[armedbear-ticket] [armedbear] #38: CLOS :metaclass support
by armedbear 07 May '10

07 May '10

#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

1 10

[armedbear-ticket] [armedbear] #79: Identically named gensymed coalesced into same object in fasl file
by armedbear 02 May '10

02 May '10

#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

1 4

[armedbear-ticket] [armedbear] #93: reader does not respect (values) from reader macros
by armedbear 01 May '10

01 May '10

#93: reader does not respect (values) from reader macros -----------------------+---------------------------------------------------- Reporter: janderson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: 0.19 Keywords: | -----------------------+---------------------------------------------------- the hyperspec includes an example which illustrates the effect of (values) for a reader macro(1) as of 0.19.1 the reader treats (values) as nil. [1] CL-USER(3): (set-macro-character #\! #'(lambda (stream char) (declare (ignore char)) (read stream) (values))) T [1] CL-USER(4): (list 1 !qwer 2) (1 NIL 2) [1] CL-USER(5): (lisp-implementation-version) "0.19.1" [1] CL-USER(6): asdf@ip-10-251-122-82:/development/source/metadata/net /common-lisp/bordeaux-threads$ ccl Welcome to Clozure Common Lisp Version 1.4-r13119 (LinuxX8632)! ? (set-macro-character #\! #'(lambda (stream char) (declare (ignore char)) (read stream) (values))) T ? (list 1 !qwer 2) (1 2) ? --- (1) http://www.lispworks.com/documentation/HyperSpec/Body/f_set_ma.htm -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/93> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #95: URL Pathnames
by armedbear 01 May '10

01 May '10

#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

1 7

[armedbear-ticket] [armedbear] #94: Incorporate ASDF2
by armedbear 01 May '10

01 May '10

#94: Incorporate ASDF2 -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 0.20 Component: libraries | Version: Keywords: | -----------------------+---------------------------------------------------- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/94> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #89: compiler stack inconsistency
by armedbear 29 Apr '10

29 Apr '10

#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

2 9

← Newer
1
...
54
55
56
57
58
59
60
...
64
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket