armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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] changes to autoloading affecting PermGen space?
by Alan Ruttenberg 05 Sep '12

05 Sep '12

I've recently been getting ; Evaluation aborted on #<JAVA-EXCEPTION java.lang.OutOfMemoryError: PermGen space {2D9FD5EA}>. I'm wondering whether it is possible that the recent changes to autoloading are filling more of this space, leading to my (and presumably others at some point) errors. -Alan

3 5

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel