November 2011 - 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] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] BUG: invalid treatment of UNSIGNED-BYTE type specifiers
by Eric Marsden 18 Nov '11

18 Nov '11

Hi, The following code seems to be miscompiled (works fine with an INTEGER type declaration). CL-USER(23): (lisp-implementation-version) "1.1.0-dev-svn-13695M" CL-USER(24): (compile nil (lambda (a) (declare (type unsigned-byte a)) (max 28105919 a 1016934843))) #<FUNCTION (LAMBDA (A)) {2D53EAFD}> NIL NIL CL-USER(25): (funcall * 10545160975) 1955226383 (From ansi-test/random suite) -- Eric

2 1

Re: [armedbear-devel] [fset-devel] FSet on ABCL
by Alessio Stalla 08 Nov '11

08 Nov '11

Hi, to follow up on the topic of running FSet on ABCL, I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine. However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization? Bye, Alessio On Thu, Oct 27, 2011 at 1:19 AM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott(a)sympoiesis.com> wrote: >> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla >> <alessiostalla(a)gmail.com> wrote: >>> Greetings, >>> >>> as part of my nth plan to conquer the world (which of course I won't >>> unveil right now), I tried FSet on ABCL. I managed to make it run, but >>> I had to patch it; you can find the patch attached (it's taken against >>> the version in Quicklisp, but I believe it's the latest version). >> >> Thanks for the patch! >> >> Did you run the test suite? Were any non-default JVM settings >> required, e.g. stack size? >> >> Do you have any performance comparisons (of FSet operations in >> particular) vis-a-vis, say, SBCL? > > I haven't run the test suite yet, nor made any performance > comparisons. Regarding JVM settings, in order to compile and load FSet > (under SLIME) I had to increase the maximum heap size from the (iirc) > 64M default. I set it at 256M but it may well be that a lower value is > sufficient. In the next few days I'll do a few tests and benchmarks > and I'll keep you informed on the results. > >> >>> Besides some minor #+abcl porting stuff, the one thing that stuck out >>> was the DEFLEX macro for defining global lexical variables, which >>> conflicts with ABCL's implementation of symbol macros. >>> (deflex var) expands basically into (define-symbol-macro var >>> (symbol-value 'var)). The problem: ABCL stores symbol macros in the >>> value cell of symbols, so you can't have a symbol which is both a >>> variable and a symbol macro. >>> Now, I believe deflex as written is non portable CL. This is because >>> accessing the symbol-value of an unbound variable is, to my >>> interpretation, unspecified [*]; and if you use defvar/defparameter >>> with var, then you cannot use it as a symbol macro. Thus, I patched it >>> (taking inspiration from Rob Warnock's version of deflex/defglobal). >> >> Heh -- I had seen Rob's implementation and wondered why he created a >> second symbol. Now I know :-) > > I don't particularly like the second interned symbol solution... I > tried initially with a gensym, but it's hard to get right the > interplay between compile-time, load time, and the file compiler > possibly losing gensym identity, so I guess Rob's approach is the most > practical. > >> >>> I don't think a symbol for which there is no special declaration in >>> scope can be considered to name a dynamic variable, and thus to have a >>> value cell at all. >> >> On a strict reading, you're probably correct. But I had never seen an >> implementation for which this was not the case. > > Yes, me neither, and I'd like to get ABCL fixed in that regard. You > might keep your implementation of deflex as-is; in the meantime I will > use my patched version, until ABCL is fixed. > > Thanks, > Alessio >

1 0

[armedbear-devel] stack overflow for worst-case vector sort
by James M. Lawrence 08 Nov '11

08 Nov '11

ABCL-1.0.0 (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) => Stack overflow. [Condition of type STORAGE-CONDITION] 0: (#<FUNCTION {7F535BDF}> #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 1: (APPLY #<FUNCTION {7F535BDF}> (#<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {74A2B3B8}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:374) 5: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1315) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 8: org.armedbear.lisp.swank_469.execute(swank.lisp:2116) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:683) 10: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) 11: (JAVA:JRUN-EXCEPTION-PROTECTED #<FUNCTION {39B4CEC7}>) It looks like the quick-sort function (attributed to ECL) pivots off the first element. I would suggest using a midpoint instead. ABCL's sort also seems a little slow. The psort benchmarks show too much speedup for only 2 cores (http://lparallel.com/download) size 1000 | op < | SORT 11 size 1000 | op < | SORT 11 size 1000 | op < | SORT 12 size 1000 | op < | SORT 12 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 50000 | op < | SORT 1014 size 50000 | op < | SORT 1011 size 50000 | op < | SORT 1012 size 50000 | op < | SORT 1013 size 50000 | op < | PSORT 413 size 50000 | op < | PSORT 417 size 50000 | op < | PSORT 415 size 50000 | op < | PSORT 416 size 200000 | op < | SORT 4703 size 200000 | op < | SORT 4701 size 200000 | op < | SORT 4715 size 200000 | op < | SORT 4712 size 200000 | op < | PSORT 1977 size 200000 | op < | PSORT 1975 size 200000 | op < | PSORT 1979 size 200000 | op < | PSORT 1994 psort is based upon the following (posted to usenet by Roger Corman; free license). (defun quicksort (vec lo hi comp-func) (if (> hi lo) (let* ((mid (round (+ lo hi) 2)) (i lo) (j (+ hi 1)) (p (elt vec mid))) (rotatef (elt vec mid) (elt vec lo)) ;; swap mid element to first (loop (loop do (incf i) until (or (> i hi) (funcall comp-func p (elt vec i)))) (loop do (decf j) until (or (<= j lo) (funcall comp-func (elt vec j) p))) (if (< j i) (return)) (rotatef (elt vec i)(elt vec j))) (rotatef (elt vec lo) (elt vec j)) ;;put partition element in place (quicksort vec lo (- j 1) comp-func) (quicksort vec i hi comp-func))) vec) (defun qsort (sequence comp-func) (quicksort sequence 0 (- (length sequence) 1) comp-func))

2 1

[armedbear-devel] Patch: sequence implementations can be structures
by Alessio Stalla 08 Nov '11

08 Nov '11

Hello, again musing with FSet on ABCL, thinking about integrating it with the CL sequence API (where it makes sense). FSet collections are structures, so I wrote the attached hack^H^H^H^Hpatch to create a special structure class that extends cl:sequence. This can be used to make user-defined structures obey the sequence protocol without wrappers, though I haven't used it with FSet yet. What do you think about it? Bye, Alessio

1 1

[armedbear-devel] Patch to dynamically load jna.jar for CFFI
by Mark Evenson 06 Nov '11

06 Nov '11

If you have the the [contrib mechanism working correctly, post abcl-1.0.0][1], one can get ABCL to dynamically load the required shared objects to enable [via the following code in your ~/.abclrc][2]: #+abcl (eval-when (:load-toplevel) (require 'abcl-contrib) (require 'abcl-asdf) (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.sun.jna" "jna" "3.0.9"))) ASDF shouldn't really be patched in [this way][1], but it involves debugging the Pathname internals (yet again) which is a task I am postponing until I can string together a bunch of consecutive hours. [1]: http://trac.common-lisp.net/armedbear/changeset/13692 [2]: http://bit.ly/v6OQFf

1 0

[armedbear-devel] adjust-array bug
by Helmut Eller 06 Nov '11

06 Nov '11

Evaluating this form (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) prints a longish stacktrace that doesn't seem right: Armed Bear Common Lisp 1.1.0-dev-svn-13692M Java 1.6.0_18 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 0.771 seconds. Startup completed in 2.209 seconds. Type ":help" for a list of available commands. CL-USER(1): (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:291) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:40) at org.armedbear.lisp.adjust_array.execute(adjust_array.java:95) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.Autoload.execute(Autoload.java:258) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.arrays_2.execute(arrays.lisp:46) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:541) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:496) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:277) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) 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.top_level_51.execute(top-level.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.Interpreter.run(Interpreter.java:360) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:636) #<THREAD "interpreter" {3DC13D}>: Debugger invoked on condition of type ERROR Caught java.lang.ArrayStoreException. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): Helmut

2 1

[armedbear-devel] Symbol-macro patch
by Alessio Stalla 02 Nov '11

02 Nov '11

Greetings, following up from my earlier mail about FSet and ABCL, I propose a patch (attached) to fix ABCL's symbol-macro implementation not to use the symbol's global value slot. Local symbol macros still use the same storage location as variables, since it's not possible to use symbol-value on local variables and it is forbidden to both declare a variable special and associate a symbol macro to its name. I also simplified some code that did not make use of this assumption, and specially handled cases where a symbol was both naming a special variable and a symbol macro. An inconsistency remains: (defvar foo) (define-symbol-macro foo nil) signals an error, while (define-symbol-macro foo nil) (defvar foo) does not. This behaviour is present in stock ABCL as well, and apparently it's allowed by the ANSI standard, although at least SBCL consistently signals an error in both cases. I believe we should do so, too. But I think it pertains to another patch. Please test the patch with your own code; I ran the ANSI test suite and got no regressions, but I'm not very confident about it - apparently it doesn't cover symbol macros very well or at all, since at one time I ran it with define-symbol-macro effectively unimplemented and it happily reported the same 19-20 failures it did before. Cheers, Alessio

2 2