August 2012 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Issue finding methods in JSS
by Jonathan P. Bona 09 Nov '12

09 Nov '12

Hello, We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method: ;;;---------------- (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com")))) ; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers))))) ;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName") ; Java exception 'java.lang.NoSuchMethodException: No applicable method named size found in java.lang.Object or java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) ;;;---------------- I chased this into org.armedbear.lisp.Java, where findMethod is returning null. - Jonathan Bona

4 7

[armedbear-devel] Unbound initargs slot in slot-definitions
by Stas Boukarev 30 Sep '12

30 Sep '12

Having two classes: (defclass slot-d-1 (mop:standard-direct-slot-definition) ()) (defclass slot-d-2 (mop:standard-direct-slot-definition) (a)) (slot-boundp (make-instance 'slot-d-2) 'sys::initargs) => T (slot-boundp (make-instance 'slot-d-2) 'sys::initargs) => NIL So, having a slot makes initargs unbound. Below is the actual code which suffers from it: (defpackage test (:use :cl :mop)) (in-package test) (defclass storable-class (standard-class) ()) (defmethod validate-superclass ((class standard-class) (superclass storable-class)) t) (defmethod validate-superclass ((class storable-class) (superclass standard-class)) t) (defclass storable-direct-slot-definition (standard-direct-slot-definition) ((storep :initarg :storep :initform t :reader store-slot-p))) (defmethod direct-slot-definition-class ((class storable-class) &key) (find-class 'storable-direct-slot-definition)) ;;; (defclass identifiable () ((id :accessor id :initform nil :storep nil)) (:metaclass storable-class)) The last form receives an error: The slot INITARGS is unbound in the object #<STORABLE-DIRECT-SLOT-DEFINITION {34C1EFE7}>. -- With best regards, Stas.

2 6

[armedbear-devel] Closer-mop support for ABCL
by Rudi Schlatte 19 Sep '12

19 Sep '12

Greetings, ABCL 1.1, expected in 2-3 months from now, will have a mop implementation that passes the mop test suite without missing features. The work is finished in svn and can be checked out at http://svn.common-lisp.net/armedbear/trunk/abcl/. It would be great if we had closer-mop support by release time; attached is a naive patch (which assumes that abcl needs nothing in closer-mop-shared). I also re-send the abcl patch for mop-feature-tests. The closer-mop patch is written to give an error if :mop isn't on *features*, this feature is present in the mop-supporting svn version of abcl and will be in the released version as well, so if you decide to merge the patch, users of the old release will get a sensible error message. Cheers, Rudi

3 17

[armedbear-devel] Ansi tests fail to execute
by Rudolf Schlatte 05 Sep '12

05 Sep '12

Hi, Currently the ansi test suite crashes with this error: Error loading /Users/rudi/Source/ansi-tests/load-arrays.lsp at line 3 (offset 55) #<THREAD "interpreter" {712A95C7}>: Debugger invoked on condition of type TYPE-ERROR The value CL-TEST::OPTIONS is not of type LIST. Restarts: 0: TOP-LEVEL Return to top level. According to git bisect, the offending commit is r14130 (Replace a Java primitive LAMBDA-LIST-NAMES with a lisp function) although I haven't investigated further yet. Rudi

2 2

[armedbear-devel] CLOS / D-M-C tests failure DMC-TEST-MC.1 help requested
by Erik Huelsmann 31 Aug '12

31 Aug '12

Hi all, In an attempt to solve ticket 201 and everything related (now that I'm into it anyway), I've been staring at the failure of one of ABCL's own tests and can't seem to understand what's going on. So, DMC-TEST-MC.1 is failing because it uses a non-standard METHOD-QUALIFIER. STD-COMPUTE-EFFECTIVE-METHOD throws an error when matching the qualifiers of the defined methods with the method groups and finds that the method combination isn't one of type long-form. However, the problem is: it really *is* of type long form. However, this seems to happen *only* in the compiled case....s So, I inserted a trace: (eval-when (:compile-toplevel) (trace mop::STD-COMPUTE-EFFECTIVE-METHOD)) and extracted the test form from outside the test case, in order to be able to see the error triggered (RT just prints #<simple-error >): (dmc-test-mc.1 :k 1) The result is this backtrace: [java] 0: (MOP::STD-COMPUTE-EFFECTIVE-METHOD #<STANDARD-GENERIC-FUNCTION DMC-TEST-MC.1 {10D3D99}> #<METHOD-COMBINATION {69B861}> (#<STANDARD-METHOD {C821EF}>)) which clearly shows the method combination is of type METHOD-COMBINATION and not of type LONG-METHOD-COMBINATION. I do understand that this is the error, but I can't for the life of me figure out how we get into the situation that the method combination being instantiated is of the resulting type METHOD-COMBINATION... Any help on debugging or additional insights would be extremely appreciated! Bye, Erik.

3 12

[armedbear-devel] asdf 2.24 released
by Faré 26 Aug '12

26 Aug '12

I am pleased to announce the release of ASDF 2.24. Since previous release 2.23, the changes are as follow: Portability: * ACL: handle SMP vs non-SMP builds in Allegro 9.0 * MKCL: add support for ManKai Common Lisp * ECL: merge improvements from ECL git. Refactor ECL support somewhat. * Remove broken-fasl-support: first, cormanlisp is supposed to have fixed it; second, cormanlisp is dead; third, one can now (setf *load-system-operation* 'load-source-op) instead. Internals: * renaming ends-with to string-suffix-p to avoid conflict with alexandria. * Refactor load-system to use *load-system-operation*, and change require-system and module-provide-asdf to use that. Also note: * We recommend you use asdf-utils to access the utilities in asdf. Some time next year, we may stop exporting the utilities from asdf itself. * To avoid conflicts between alexandria, fare-utils, xcvb-driver, asdf-utils, etc., you can use xcvb-utils that solves the conflicts. Or you can use fare-utils:define-package-mix that will help you automatically resolve them. These changes are few and subtle, but nonetheless significant to those who'd use these features. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Obscenity is the crutch of inarticulate motherfuckers.

1 0

[armedbear-devel] Recommended ABCL development setup
by Jonathan P. Bona 24 Aug '12

24 Aug '12

Greetings, As a user of ABCL, I've found it useful to browse the Java source, make slight modifications, run it in a debugger, and so on. I'm doing this rather inelegantly right now by linking to the source folder in an Eclipse project, and it's not working very well. Is there a recommended IDE setup that ABCL developers use? Regards, Jonathan Bona

2 1

Re: [armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Mark 22 Aug '12

22 Aug '12

The point of the current procedure is that abcl-contrib.jar is not on the classpath at all, so it should be less configuration. That being said, I'm always open to easier ways for deployment as long as it doesn't break existing usages. I'm "on the road" camping right now so I really won't be able to work on this until perhaps September. A thought might be that the user can extend the CL:REQUIRE mechanism by pushing closures into a special variable whose name is something like *module-provider-hooks*, perhaps in a local system.lisp. This path may allow some experimentation before we merge those semantics with those of ABCL-CONTRIB.

1 0

[armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Eric Marsden 22 Aug '12

22 Aug '12

Hi, I am trying to use the new abcl-contrib JSS functionality, which looks very useful; thanks. I have the ABCL classes (and in fact the ABCL-CONTRIB classes) embedded into a jar file containing other code, and both the FIND-SYSTEM-JAR and FIND-CONTRIB logic are failing. Would it be possible perhaps to search for abcl-contrib.jar on the classpath, instead of assuming that it is installed next to abcl-XXX.jar? Thanks, -- Eric Marsden

1 1

[armedbear-devel] BUG: ClassCastException in MAKE-PATHNAME
by Eric Marsden 22 Aug '12

22 Aug '12

Hi, The following behaviour is not ideal. ,---- | Armed Bear Common Lisp 1.1.0-dev-svn-14131M | Java 1.7.0_03 Oracle Corporation | OpenJDK 64-Bit Server VM | Low-level initialization completed in 0.3 seconds. | Startup completed in 1.456 seconds. | Loading /home/emarsden/.abclrc completed in 0.66 seconds. | Type ":help" for a list of available commands. | CL-USER(1): (make-pathname :device (list "foo")) | java.lang.ClassCastException: org.armedbear.lisp.SimpleString cannot be cast to org.armedbear.lisp.Pathname | at org.armedbear.lisp.Pathname.getNamestring(Pathname.java:657) | at org.armedbear.lisp.Pathname.printObject(Pathname.java:909) | at org.armedbear.lisp.Primitives$pf__output_object.execute(Primitives.java:907) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_8.execute(print.lisp:127) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_14.execute(print.lisp:281) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) `---- -- Eric Marsden

1 0

[armedbear-devel] Problem with defstruct accessor functions and included structures in combination with conc-names
by Ralf Moeller 18 Aug '12

18 Aug '12

The following file causes a problem in ABCL (1.1.0-dev-svn-14041) when compiled (!) and loaded. (in-package cl-user) (defstruct a (s1 nil)) (defstruct (b (:include a) (:conc-name foo-)) (s2 nil)) (defstruct (c (:include a) (:conc-name foo-)) (s3 nil)) (defun test () (let ((x (make-b :s1 1 :s2 2))) (foo-s1 x))) CL-USER(4): (test) #<THREAD "interpreter" {2EF7D41F}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<B {564434F7}> is not of type C. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(6): (lisp-implementation-version) "1.1.0-dev-svn-14041" [1] CL-USER(7): The problem is that the defstruct declaration for c "overwrites" the accessor foo-s1 generated by defstruct b. If foo-s1 is called for a b instance, the type assertions introduced by define-reader (and define-writer, see the ABCL implementation for defstruct) cause the error described above. The code above runs fine in ACL, Lispworks, SBCL, and other Lisps. I had to remove the generation of type assertions in define-reader and define-accessor (see below) to make the code work in ABCL. Note, however, that there is no type checking pursued with the code below. Thus, a better solution might be developed. Regards, Ralf Moeler http://www.sts.tu-harburg.de/~r.f.moeller/ (defun define-reader (slot) (let ((accessor-name (dsd-reader slot)) (index (dsd-index slot)) (type (dsd-type slot))) (cond ((eq *dd-type* 'list) `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-list-reader ,index)))) ((or (eq *dd-type* 'vector) (and (consp *dd-type*) (eq (car *dd-type*) 'vector))) `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-vector-reader ,index)) (define-source-transform ,accessor-name (instance) `(aref ,instance ,,index)))) (t `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-structure-reader ,index ',*dd-name*)) (define-source-transform ,accessor-name (instance) ,(if (eq type 't) ``(structure-ref ,instance ,,index) ``(the ,',type (structure-ref ,instance ,,index))))))))) (defun define-writer (slot) (let ((accessor-name (dsd-reader slot)) (index (dsd-index slot))) (cond ((eq *dd-type* 'list) `((setf (get ',accessor-name 'setf-function) (make-list-writer ,index)))) ((or (eq *dd-type* 'vector) (and (consp *dd-type*) (eq (car *dd-type*) 'vector))) `((setf (get ',accessor-name 'setf-function) (make-vector-writer ,index)) (define-source-transform (setf ,accessor-name) (value instance) `(aset ,instance ,,index ,value)))) (t `((setf (get ',accessor-name 'setf-function) (make-structure-writer ,index ',*dd-name*)) (define-source-transform (setf ,accessor-name) (value instance) `(structure-set ,instance ,,index ,value)))))))

3 5

[armedbear-devel] ABCL development surprises
by Erik Huelsmann 18 Aug '12

18 Aug '12

Every time I create a new feature or new behaviour for ABCL, the system surprises me: with all the automatic detection of autoloaders, one would say that the system should have slowed down. Nothing of that sort happened. In fact, build time for ABCL seems to have gone down from over 6 minutes (can't remember: 6'15 or 6'30) to roughly 5'30! Unfortunately, start up times have gone up to 4s. Bye, Erik.

1 0

[armedbear-devel] Autoloaders: status report and a question
by Erik Huelsmann 18 Aug '12

18 Aug '12

Hi all, Sorry for the bumpy ride while I reorganized the auto loader system. Thanks for taking the time to respond to my earlier questions on auto loaders. This is the time to explain what I did with your answers (and what I did in general). To reiterate what this is all about: the autoloader is an important part of the start up efficiency and internal file dependency resolution of ABCL: it establishes function and macro bindings on symbols without loading the actual code to bind to. Instead, loading the FASL is being delayed until some part of the system (or a user) needs it. There are two variants of autoloaders: Java class autoloaders and lisp (fasl) autoloaders. Their purpose is the same and they operate roughly the same way, but one operates by forcing a class to be loaded while the other causes a FASL to be loaded. Most parts of the system don't know about autoloaders and simply evaluate code. The autoloaders take special action when evaluated: their purpose is not to execute the intended action, but instead, they load the fasl in which the actual code is located. Then, when the actual code is loaded, the function (or macro) call is forwarded to the loaded code. The FASL loader process replaces the content of the function symbol slot with the true function so the autoloader gets garbage collected after replacement. This entire system works pretty well, that is: *if* you know which symbols you have to install an autoloader on. Before my changes, we didn't know which symbols we had to install autoloaders on. Instead, we maintained a list of symbols by hand through trial and error. When a change caused total havoc, you'd look for the cause and - hopefully - debugged the problem to a missing autoloader. That's when you would add an autoloader to autoloads.lisp. That works as long as our only purpose is to build ABCL. However, we actually intend for ABCL to be used by our users. Users may not be aware of what autoloaders do for them and choose to start calling some random function in the AMOP definition. Since we hand-maintain a list of functions to be decorated with autoloaders, that probably doesn't work. So, in order to provide more stability for our users we need to decorate all functions with autoloaders. What's more: having all functions decorated with autoloaders -if done well- should also help ABCL development quite a bit: the chances of a change causing havoc because a non-decorated function is being used have been reduced to next-to-none. What then did I do? The change involves a few steps: 1. Extraction of symbols to be decorated ============================= The file compiler now generates (when compiling our own system, that is) two extra output files: basename.funcs and basename.macs. These files contain a single s-exp with all the symbols which have been DEFUNed or DEFMACROed respectively. With this information, we can generate decoration information. Analysis of the extracted symbols leads to the conclusion we can't assign an autoloader to each and every extracted symbol for 2 reasons: a. There is a built-in function associated with the symbol to help bootstrapping b. There are multiple DEFUNs or DEFGENERIC/DEFMETHODs 2. Determination of what to decorate symbols with ==================================== Autoloaders - at this time - can only be used to load a single FASL. So, when a symbol is in multiple files, we need to choose which file it load the FASL for (and hence not the others). Most symbols which occur in multiple files are DEFMETHODs which is perfectly fine. Most symbols with double locations stem from the EXTENSIBLE-SEQUENCES implementation. We want to exclude those FASLs, which reduces the number of multi-homed symbols to only a few. All single-homed symbols excluding those which have bootstrap functions attached can be decorated with autoloaders. 3. Generate code to install the autoloaders =============================== We just used to have autoloads.lisp (and Autoload.java). But that file will contain only the manual bits which can't be auto-generated. So there's now a second file autoload-gen.lisp. This file is being generated during the build and populated with all symbols which need an autoloader. Today's autoload.lisp has been stripped to the bare minimum of AUTOLOAD and AUTOLOAD-MACRO forms. With the stripped autoload.lisp and the fact that the autoloaders are bootstrapping helpers, I had to take additional measures to help us bootstrap again. The result is autoloads-gen.lisp in the source directory. It is loaded at build time to help bootstrapping. It's an unmodified version I took from the build directory: build/classes/org/armedbear/lisp/autoloads-gen.lisp - the one which is generated on each build. 4. Exporting the right symbols ====================== Not a problem related to autoloading per se, but definitely related to the fact that we don't load all fasls at boot time: autoload.lisp - as the canonical location being loaded at startup - had grown to be a listing of EXPORT forms. Having EXPORT forms and actual code widely apart is counter-intuitive: to the occasional developer it's inexplicable how some symbols become exported and some don't. (We had files with additional EXPORT forms.) So, when the above was "solved", I created another facility which collects all the symbols in the second argument of EXPORT throughout our source tree. Those symbols are added to the autoload-gen file and the EXPORT forms executed at start up as well. Even though the developer still doesn't know what's going on, the system should be working transparently. All of the above has happened over the last week(s) - last week, mostly. Then there is the question: As it turns out, the macroexpansion for DEFSTRUCT happens in a way such that the file compiler can't detect the slot accessors as being defined as functions. The advantage is that we're *not* seeing a whole slew of symbols to be attached to autoloaders and hence limiting the number of autoloaders (the contructor function *is* detected). Now: what do others think: should we depend on the constructor being called before any of the accessors to make sure the autoloaders have been run? Or should we attach an autoloader to each accessor function just to be sure? (This requires small changes to the file compiler and defstruct macro expansion.) Bye, Erik.

1 0

[armedbear-devel] SLIME && ABCL autoloaders
by Erik Huelsmann 18 Aug '12

18 Aug '12

Hi Mark, While working on the autoloaders, I found a very interesting thing: SLIME doesn't know about ABCL's autoloaders. To maximize the benefit of SLIME for ABCL (yea, I even started using it to debug ABCL itself, after you pointed out to me that these tools generally help productivity), I think it would be beneficial to teach it about autoloaders. The case I'm talking about is this: When using M-. SLIME looks up the source code location for the source associated with the symbol. However, when you do that to a symbol which hasn't been autoloaded yet, that source code location information isn't available. SLIME could easily resolve that by evaluating the form (SYS::RESOLVE <symbol>) and look for the info after that. SLIME could do the same when looking up function lambda list information to present in the minibuffer for auto-completion. How about that? Bye, Erik.

2 1

[armedbear-devel] SLIME broken on current svn because export statement is in autoloaded file
by Rudolf Schlatte 18 Aug '12

18 Aug '12

Hi, Subject says most of it, I guess. Currently, threads.lisp line 36ff. contains the export form that exports make-thread-lock from the threads package ... which will be evaluated as soon as one of the autoloaded functions is called. This first function call must use notation for unexported symbols to avoid a reader error. Cheers, Rudi

2 1

[armedbear-devel] Forward referenced classes woes
by Stas Boukarev 15 Aug '12

15 Aug '12

Consider the following code: (defclass whitespace-normalizer (sax-proxy)) (defclass sax-proxy (broadcast-handler) ()) (defclass broadcast-handler () ((handlers :initform nil :initarg :handlers :accessor broadcast-handler-handlers))) Doing the followoing results in errors: (setf (broadcast-handler-handlers (make-instance 'whitespace-normalizer)) 10) There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION (SETF BROADCAST-HANDLER-HANDLERS) {6621477C}> when called with arguments (10 #<WHITESPACE-NORMALIZER {14BAAEA8}>). (setf (broadcast-handler-handlers (make-instance 'sax-proxy)) 10) The slot HANDLERS is missing from the class #<STANDARD-CLASS SAX-PROXY {1700FFDB}>. The problem is that whitespace-normalizer and sax-proxy are finalized too early. Finalization happens in std-after-initialization-for-classes http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/… by calling maybe-finalize-class-subtree, which in its turn finalizes the class and its subclasses in case the class has all its superclasses finalized. When (defclass whitespace-normalizer (sax-proxy)) is executed it creates a forward-referenced-class for sax-proxy, and when sax-proxy is defined it calls a method for ensure-class-using-class http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/… for forward-referenced-classes. Before calling reinitialize-instance it does (change-class class metaclass) to change from forward-referenced to normal class. change-class in its turn calls shared-initialize method, which calls the aforementioned std-after-initialization-for-classes, but it doesn't supply any direct-superclass arguments. So, when maybe-finalize-class-subtree is called it thinks that sax-proxy's sole superclass is standard-object, so it goes ahead finalizing sax-proxy and whitespace-normalizer at the wrong time with wrong information. And ensure-class-using-class later call with the right direct-superclass information doesn't matter anymore, since the classes were already badly finalized -- With best regards, Stas.

2 2

[armedbear-devel] [patch] compile slightly broken for compiled functions
by Vladimir Sedach 14 Aug '12

14 Aug '12

Hi, (compile nil (compile nil (lambda ()))) => NIL (compile '+) => + The first result is obviously wrong, and the second one is actually as well (according to the HyperSpec, compile should return the function definition of +). The fix is rather trivial: Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 14055) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -7483,7 +7483,7 @@ (resolve name) ;; Make sure the symbol has been resolved by the autoloader (setf definition (fdefinition name))) (when (compiled-function-p definition) - (return-from jvm-compile (values name nil nil))) + (return-from jvm-compile (values definition nil nil))) (let ((catch-errors *catch-errors*) (warnings-p nil) (failure-p nil) Index: test/lisp/abcl/compiler-tests.lisp =================================================================== --- test/lisp/abcl/compiler-tests.lisp (revision 14055) +++ test/lisp/abcl/compiler-tests.lisp (working copy) @@ -472,11 +472,10 @@ (not (null result)))) t) +(deftest compile-named + (compile '+) + (symbol-function '+)) - - - - - - - \ No newline at end of file +(deftest compile-compile + (compiled-function-p (compile nil (compile nil (lambda ())))) + t) Happy hacking, Vladimir

2 3

[armedbear-devel] Wrongly initialized generic function method combination
by Stas Boukarev 13 Aug '12

13 Aug '12

When compile a file with (defgeneric test (a b) (:method-combination progn :most-specific-last)) (defmethod test progn (a b) (list a b)) TEST receives a wrong method-combination (mop:generic-function-method-combination #'test) => #<METHOD-COMBINATION STANDARD {6E99175D}> When defgeneric is called, the generic function TEST is already created by the defmethod macro at macroexpansion time, but not completely initialized, so defgeneric ends up calling reinitialize-instance with :method-combination, but the slot for method-combination is called %METHOD-COMBINATION and its initarg is :%METHOD-COMBINATION, so nothing gets initialized. This was changed in the following commit: http://trac.common-lisp.net/armedbear/changeset?new=13947%40trunk%2Fabcl%2F… -- With best regards, Stas.

2 1

[armedbear-devel] [Patch]: Make listen work on gray-streams.
by Stas Boukarev 13 Aug '12

13 Aug '12

gray-listen functions weren't plugged into cl:listen for some reason. -- With best regards, Stas.

2 1

[armedbear-devel] LISTEN doesn't work on non-character streams
by Stas Boukarev 13 Aug '12

13 Aug '12

(with-open-file (stream "/dev/zero" :element-type '(unsigned-byte 8)) (listen stream)) #<FILE-STREAM {5CF9DE08}> is not a character input stream. -- With best regards, Stas.

1 0

[armedbear-devel] Stack overflow when compiler macro with fallback is triggered
by James M. Lawrence 12 Aug '12

12 Aug '12

(eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99) (define-compiler-macro foo () `(locally (declare (notinline foo)) (foo)))) (defun call-foo () (foo)) Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that." Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.jvm_746.execute(jvm.lisp:572) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) [...]

5 5

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] compile doesn't return correct values for warnings-p and failure-p
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile nil '(lambda () (char=))) ; Caught WARNING: ; Wrong number of arguments for CHAR=. ; Compilation unit finished ; Caught 1 WARNING condition #<FUNCTION (LAMBDA ()) {456E3EB3}> NIL NIL while it should be T, T. jvm-compile, which handles this doesn't succeed because the underlying with-compilation-unit eats all the warnings and errors so that jvm-compile's handler-bind doesn't get a piece of them. Binding *resignal-compiler-warnings* to T inside jvm-compile resolves this. -- With best regards, Stas.

1 0

[armedbear-devel] char= compilation warning
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile (defun test (a b c) (if (char= a b c) t))) ; Caught WARNING: ; Wrong number of arguments for CHAR= (expected 2, but received 3). The error is caused by p2-test-char= in compiler-pass2.lisp:2667 calling (check-arg-count form 2). -- With best regards, Stas.

1 1