armedbear-devel July 2009

armedbear-devel@common-lisp.net

20 participants
46 discussions

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] incorporating java stack frames into backtrace
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

When evaluating (ext:make-thread #'(lambda ())) you get an error "The value NIL is not of type STRING." -- this is a bug in ABCL itself, by the way, but that's not the matter of this mail. The concern of this mail is the backtrace that'd you get: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 2: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 3: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) ... The only thing the backtrace reveales is that the error was signalled somewhere in MAKE-THREAD. With the patch of this mail, the backtrace will also contain the relevant Java stack frames for errors that were signalled from within ABCL's Java runtime: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.getStringValue(LispObject.java:1061) 4: org.armedbear.lisp.LispThread.<init>(LispThread.java:111) 5: org.armedbear.lisp.LispThread.<init>(LispThread.java:39) 6: org.armedbear.lisp.LispThread$3.execute(LispThread.java:909) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:108) 8: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 9: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 10: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) Another example: (LENGTH 12) Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {814AF5}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.length(LispObject.java:403) 4: org.armedbear.lisp.LispObject.LENGTH(LispObject.java:410) 5: org.armedbear.lisp.Primitives$24.execute(Primitives.java:427) 6: (LENGTH 12) 7: (SYSTEM::%EVAL (LENGTH 12)) 8: (EVAL (LENGTH 12)) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

4 18

[armedbear-devel] Integration of CL and Java
by Tobias C. Rittweiler 31 Jul '09

31 Jul '09

To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac. Short term: * make Java objects inspectable. * make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods. * fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around. Medium term: * make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc. * add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method"). * add iteration macro, HOFs, for Java Collections. * Figure out how to get arglist information from Java methods. * Documentation * Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though. Long term: * Add an extensible sequence protocol, and make Java Collection abide it. * integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask. * Make it possible to extend Java classes from Lisp. * Make it possible to implement Java interfaces from Lisp. People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it. Also people who have opinions how they'd like it to look like. -T.

4 3

[armedbear-devel] [REVISED 2] Java stack frame in Java
by Mark Evenson 31 Jul '09

31 Jul '09

Attached is another revision of the Java/Lisp stack frame patch. This one has a problem with SLIME that I'm not entirely sure whats going on, but Tobias asked for the latest revision, so I'm providing as a check point. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

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

30 Jul '09

Hi all, Here is my third iteration. It no longer represents fields as a Lisp lists, which was a premature optimization and as such the root of all evil (*) - i.e. it had the same problem discussed with Tobias, caching too much, because the value of a field was calculated once and never updated, unless one reinspected the root object. Now a FieldRef class is used instead. When inspected, a FieldRef shows the full string representation of the field - e.g. private static java.lang.Object foo - and of course allows to inspect the field's value, which is always coherent to the value the field has when the FieldRef is inspected. If there are no objections, tomorrow I'll commit the patch. Cheers, Alessio (*) as a side note, today I got my copy of Knuth's The Art of Computer Programming!

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel July 2009