armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Reworked patch: convert (long|short)-method-combination into CLOS classes
by Rudolf Schlatte 06 Jan '12

06 Jan '12

Hi, After Mark's question about "what are you really trying to do?" I realized that in clos.lisp we have defun and friends available, so the accessor functions for method combinations can be implemented there. Attached is a reworked patch. I believe that the class definitions need to stay inside StandardClass.lisp, since we can't call ensure-class yet. I also attach a patch that gets rid of the ill-fated EqualSpecializerObject.java and replaces it with 3 lines of Lisp code ... (Thanks for tolerating my stumbling-about in your project, guys..) Rudi

1 0

[armedbear-devel] Patch: convert method-combination from structure to class representation
by Rudolf Schlatte 06 Jan '12

06 Jan '12

Hi, Another day, another conversion ... This was the error (apart from some un-exported symbols, which I plan to collect in a separate patch) that brought mop-feature-tests to a halt last time. I'll try to re-run it soon and see how much farther we get now. Any feedback that makes your work easier gladly welcomed, including code style, documentation etc. Rudi

2 2

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel