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

[armedbear-devel] [Patch] add classes METAOBJECT, SPECIALIZER
by Rudolf Schlatte 05 Jan '12

05 Jan '12

Hi, These two patches add the metaobject and specializer classes (ref. Table 5.1 in AMOP). They are at the proper place in the class hierarchy as far as possible -- there are some structures that should be classes (eql-specializer, method-combination) and [standard-]generic-function still have the wrong metaclass and superclasses. Regards, Rudi

3 11

[armedbear-devel] invoke.lisp can't find jsint.Invoke
by Peter Olsen 26 Dec '11

26 Dec '11

Ladies and Gentlemen, I've been trying to run ABCL with JSS. I load ABCL then I try to '(load "invoke.lisp")'. I always get an error Peters-MacBook-Pro:bin pcolsen$ java -cp jscheme.jar -jar abcl-1.0.0.jar Armed Bear Common Lisp 1.0.0 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.315 seconds. Startup completed in 1.06 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "invoke.lisp") Error loading /Users/pcolsen/bin/invoke.lisp at line 194 (offset 8509) #<THREAD "interpreter" {1DC2DAD7}>: Debugger invoked on condition of type ERROR Class not found: jsint.Invoke Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): I the past several years I have used Java only to support ABCL, so I may be making some simple mistake that I have not the wit to recognize. Please feel free to tell me to RTFM, but please give me a hint about what part of TFM I should R. Thanks! Peter Peter Olsen pcolsen(a)gmail.com Scientists study the world; engineers change it.

2 1

[armedbear-devel] stack overflow when compiling alexandria-tests
by Anton Vodonosov 20 Dec '11

20 Dec '11

Hello I am running tests of some libraries with ABCL (I decided to setup an test environment for CL libraries). When compiling alexandria tests by (quicklisp:quickload :alexandria-tests) it encounters StackOverflow. I am using the latest quicklisp. I've tried to increase the java stack size by -XX:ThreadStackSize=12048, but it doesn't help. Best regards, - Anton

2 1

[armedbear-devel] Bug in reader case handling
by Blake McBride 12 Dec '11

12 Dec '11

Greetings, Given a file name ff.lisp containing the following: (setf (readtable-case *readtable*) :invert) (defpackage "abc" (:use "COMMON-LISP") (:export "MYFUN")) (in-package "abc") (defun myfun (a b) (+ a b)) ; EOF Then try: (use-package "abc") (myfun 4 5) (abc:myfun 4 5) ; this should not work (ABC:myfun 4 5) ; this should work This works as described in sbcl, cmucl, clisp and ecl but doesn't work in abcl. It seams abcl takes into account the case of the entire "ABCL:myfun" when dealing with case. All the other lisps treat "ABC" and "myfun" separately in terms of string case. Blake McBride

1 0

[armedbear-devel] FORMAT dollarsign with negative numbers
by Marshall Abrams 05 Dec '11

05 Dec '11

It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's handling of negative numbers when it has to round up. (Forgive me if this is a known issue--I didn't find it when I searched the bug list and mailing list archives--or if there's something I'm misunderstanding.) The first group of examples use the F directive for comparison to show that the problem seems to be specific to dollarsign. (I added blank lines between example groups for easy reading.) The second group of examples illustrates a problem using dollarsign with negative numbers. The output is about 10x too large, and doesn't seem to be getting rounded properly. I'm guessing that the out of bounds error is the result of the same issue. The third group of examples shows that the problem doesn't seem to occur with positive numbers, although there's still an extra negative sign preprended. Thank you- Marshall Abrams Armed Bear Common Lisp 1.0.0-svn-13663 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.7 seconds. Startup completed in 2.211 seconds. Type ":help" for a list of available commands. CL-USER(1): (format t "~,vf" 3 -0.1768522) -0.177 NIL CL-USER(2): (format t "~,vf" 2 -0.1768522) -0.18 NIL CL-USER(3): (format t "~,vf" 1 -0.1768522) -0.2 NIL CL-USER(4): (format t "~,vf" 0 -0.1768522) -0. NIL CL-USER(5): (format t "~$" -0.1768522) --1.6 NIL CL-USER(6): (format t "~v$" 3 -0.1768522) --1.75 NIL CL-USER(7): (format t "~v$" 2 -0.1768522) --1.6 NIL CL-USER(8): (format t "~v$" 1 -0.1768522) #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type TYPE-ERROR Array index out of bounds: 2 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(9): 0 CL-USER(10): (format t "~v$" 0 -0.1768522) --0. NIL CL-USER(11): (format t "~$" 0.1768522) 0.18 NIL CL-USER(12): (format t "~v$" 3 0.1768522) 0.177 NIL CL-USER(13): (format t "~v$" 2 0.1768522) 0.18 NIL CL-USER(14): (format t "~v$" 1 0.1768522) 0.2 NIL CL-USER(15): (format t "~v$" 0 0.1768522) 0. NIL

2 1

[armedbear-devel] [Patch] implement mop:extract-specializer-names
by Rudolf Schlatte 05 Dec '11

05 Dec '11

... as specified in AMOP page 189. The internal function extract-specializers did exactly the same, so the attached patch renames and exports it. Cheers, Rudi

2 1

[armedbear-devel] (defpackage :foo (:import-from "COMMON-LISP" "NIL")) fails
by Rudolf Schlatte 01 Dec '11

01 Dec '11

Hi, Subject says it all, I suppose. :) Patch enclosed. Rudi

1 0

[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