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

[armedbear-devel] Lisp (0.12.0) crashes with (dotimes (x 35) (print #x
by Phil Berry 30 Jul '09

30 Jul '09

Guys, FYI, I assume this shouldn't crash it: [pb@redhat-linux ~]$ lisp Armed Bear Common Lisp 0.12.0 Java 1.6.0 IBM Corporation IBM J9 VM Low-level initialization completed in 0.768 seconds. Startup completed in 2.637 seconds. Type ":help" for a list of available commands. CL-USER(1): *(dotimes (x 35) (print #x* java.lang.StringIndexOutOfBoundsException at java.lang.String.charAt(String.java:418) at org.armedbear.lisp.Stream.readRadix(Stream.java:1487) at org.armedbear.lisp.LispReader$18.execute(LispReader.java:370) at org.armedbear.lisp.Stream.readDispatchChar(Stream.java:785) at org.armedbear.lisp.LispReader$6.execute(LispReader.java:159) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readList(Stream.java:722) at org.armedbear.lisp.LispReader$3.execute(LispReader.java:121) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readList(Stream.java:722) at org.armedbear.lisp.LispReader$3.execute(LispReader.java:121) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:448) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:459) at org.armedbear.lisp.Stream.read(Stream.java:399) at org.armedbear.lisp.Stream$14.execute(Stream.java:2720) at org.armedbear.lisp.Symbol.execute(Symbol.java:733) at org.armedbear.lisp.LispThread.execute(LispThread.java:659) at org.armedbear.lisp.top_level_42.execute(top-level.lisp:765) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.top_level_43.execute(top-level.lisp:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:659) at org.armedbear.lisp.top_level_44.execute(top-level.lisp:830) at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:63) at org.armedbear.lisp.Symbol.execute(Symbol.java:708) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.top_level_45.execute(top-level.lisp:849) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.Interpreter.run(Interpreter.java:373) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:735) [pb@redhat-linux ~]$

1 0

[armedbear-devel] Maxima profiling results
by Erik Huelsmann 30 Jul '09

30 Jul '09

Today I changed the profiler in ABCL to determine hot spots in our code, by looking only at the 8 stack frames at the head of the stack. The outcome of running the test suite with that changed profiler is this: 10.0 271135 TMS 10.2 275152 TIMESIN 10.7 289952 SIMPTIMES 11.1 300877 GREAT 12.3 332154 KINDP 13.7 371011 MEVAL1 14.1 382393 DMARK 15.8 427010 MEVAL 26.1 706542 SIMPLIFYA 74.3 2009777 DLSF 80.5 2177991 DLS 92.2 2493681 DGRF 100.0 2705263 DGR Where DGR is the hottest spot and the others are percentages of that. So, it looks like it that DGR is in the 8 most recent stack frames the most often of all functions used. Note this is based on sampling at a rate of 1ms intervals, not exact measurement. Robert, I'm hoping together we can explain the outcomes? Bye, Erik.

1 0

[armedbear-devel] ABCL in FreeBSD
by Erik Huelsmann 29 Jul '09

29 Jul '09

Hi Frank, Peter Graves pointed out to me that FreeBSD has a package for ABCL in its ports repository. Upon inspection, it turned out to have your name on it as the maintainer. It's great news! Thanks! There's one thing I'd like to ask you though: we started releasing regular releases of ABCL (bi-monthly intervals) and we're now working toward a release of ABCL 0.16. We noticed FreeBSD has a very old copy: 0.0.10.3. This was a bit of a downside to great news. Are you still the maintainer of that package? If not, do you know who is? If so, could you include more recent versions of ABCL? If you need help in order to be able to get more recent ABCL versions in your packages, maybe we can provide it? If so, what would we be able to do to support your package maintenance? Bye, Erik on behalf of the ABCL community.

1 0

[armedbear-devel] Proposed patch for ticket #58 (inspection of Java objects)
by Alessio Stalla 29 Jul '09

29 Jul '09

I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected. Here's an example interaction: CL-USER(1): (setq obj (jnew (jconstructor "java.util.ArrayList"))) #<JAVA-OBJECT java.util.ArrayList {98062F}> CL-USER(2): (inspect obj) #<JAVA-OBJECT java.util.ArrayList {98062F}> is an object of type JAVA-OBJECT. The wrapped Java object is an instance of java.util.ArrayList: "[]" 0 java-class -------> #<JAVA-OBJECT java.lang.Class {1FB7CBB}> 1 fields -----------> (("serialVersionUID" 8683452581122892189 ...) ("elementData" # ...) ...) [1i] CL-USER(3): :istep 1 A proper list with 4 elements at #x385715 0-> ("serialVersionUID" 8683452581122892189 ...) 1-> ("elementData" #(NIL NIL ...) ...) 2-> ("size" 0 ...) 3-> ("modCount" 0 ...) [1i] CL-USER(4): :istep 1 A proper list with 3 elements at #xDD23CF 0-> "elementData" 1-> #(NIL NIL ...) 2-> #<JAVA-OBJECT java.lang.reflect.Field {5A25F3}> [1i] CL-USER(5): As you can see, fields are triplets: the field name, the value, and the Field metaobject. I chose to represent them as simple lists to avoid having a class just for that purpose. NB: since the field values are read when the object is first inspected, and then translated to Lisp objects, the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact. Next I'd like to show methods as well, and maybe even allow one to easily call them interactively (e.g. by making a method be a shown as triplet as well - the signature as a string, the java.lang.reflect.Method metaobject, and a closure which, when invoked, calls the method on the inspected object with the given parameters). I'm also working on a graphical inspector, but that's a bit more in the works ;) Thoughts? Ale

5 11

[armedbear-devel] Patch for LispThread.java, do not copy arrays in StackFrame
by Ville Voutilainen 29 Jul '09

29 Jul '09

Here's a very simple patch that should make function calls faster. I have only anecdotal tests with the raytracing shootout test and the compiled ansi-tests, but the numbers seem to support this patch. If nobody objects, I'll commit this.

2 1

[armedbear-devel] A clos patch for review
by Ville Voutilainen 28 Jul '09

28 Jul '09

Here's a stab at checking initargs for make-instance and others. With this patch, I get rid of the following errors: -CHANGE-CLASS.1.11 -MAKE-INSTANCE.ERROR.3 -MAKE-INSTANCE.ERROR.4 Feel free to comment.

2 7

[armedbear-devel] false-positive ansi tests
by Peter Tsenter 28 Jul '09

28 Jul '09

It seems abcl generates correct result on some ANSI tests, but in actuality abcl fails. The way tests are written, it's hidden from the user. Example: disassemble.4 If one executes (disassemble-it (eval '(function (lambda (x y) (cons x y))))) as it's written then everything looks ok, but (disassemble (eval '(function (lambda (x y) (cons x y))))) returns the following ; 'jad' is not recognized as an internal or external command, ; operable program or batch file. NIL _________________________________________________________________ Windows Live™ Hotmail®: Search, add, and share the web’s latest sports videos. Check it out. http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_…

2 2

Re: [armedbear-devel] [j-devel] bug - interaction between unwind-protect, function call, multiple values
by Erik Huelsmann 28 Jul '09

28 Jul '09

Hi Alan, On Mon, Jul 27, 2009 at 2:08 AM, Alan Ruttenberg<alanruttenberg(a)gmail.com> wrote: > (defun bar () (values 1 2)) > (bar) => > 1 > 2 > (defun foo () (unwind-protect (return-from foo (bar)) 2)) > (foo) => > 1 > (defun foo () (unwind-protect (return-from foo (values 1 2) 2))) > (foo) => > 1 > 2 > > I noticed this in an early version of abcl, but just downloaded and > built from subversion and it's still there. > Doesn't seem to matter whether it is interpreted or evaluated. It didn't matter whether interpreter or compiled, because both had the same issue. Anyway, thanks for the report! It's fixed now. Bye, Erik.

2 1

Re: [armedbear-devel] [j-devel] bug - interaction between unwind-protect, function call, multiple values
by Erik Huelsmann 27 Jul '09

27 Jul '09

Hi Alan! On Mon, Jul 27, 2009 at 2:08 AM, Alan Ruttenberg<alanruttenberg(a)gmail.com> wrote: > (defun bar () (values 1 2)) > (bar) => > 1 > 2 > (defun foo () (unwind-protect (return-from foo (bar)) 2)) > (foo) => > 1 > (defun foo () (unwind-protect (return-from foo (values 1 2) 2))) > (foo) => > 1 > 2 > > I noticed this in an early version of abcl, but just downloaded and > built from subversion and it's still there. > Doesn't seem to matter whether it is interpreted or evaluated. I can see the error in the compiler; it's in p2-unwind-proctect: the exception handler doesn't save the values register of the thread. Maybe it's the same in the interpreter. I'll have a look later today, if I have time. Thanks for the report! Bye, Erik.

1 0

[armedbear-devel] progress on Maxima + ABCL -- light at the end of the tunnel!
by Robert Dodier 27 Jul '09

27 Jul '09

Hi, I've compiled Maxima (from CVS) with ABCL (from svn) and run_testsuite() shows just a few errors due to different floating point results. Hurray! The key change to Maxima seems to have been changing EQ to EQUAL in a pattern-matching function ... In ABCL it appears that numbers are not necessarily EQ so a lot of patterns failed. Since the pattern-matching stuff is widely used in Maxima (especially integrals) there were a lot of failed tests. Just that one change seems to have fixed dozens of test failures! I found it necessary to run the autoconf machinery (sh bootstrap && ./configure at least; I ran make as well, although I don't know if that's actually necessary, and then I ran configure.lisp as described in INSTALL.lisp) before compiling with ABCL via: (require 'asdf) (asdf:operate 'asdf:load-op :maxima) Without the autoconf stuff, src/autoconf-variables.lisp has incorrect values, it seems. Maxima + ABCL is extremely slow -- something like 7 times slower than Maxima + Clisp, which is the slowest of the established Lisp implementations I've tried (GCL, ECL, SBCL, CMUCL, and Clisp). I'm working on Linux, maybe it helps to run on Windows -- I'm thinking the Java implementation might be faster. Just a guess. I'm pretty excited about the possibilities here. A long-term project is to organize Maxima into modules in hopes of making it possible to load different modules a la carte -- I think that might make it attractive for bolting it onto different projects. Thanks to the ABCL developers for all their work. best Robert Dodier Maxima developer

1 0