armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

[armedbear-devel] [PATCH] Problems with new JavaObject.javaInstance(Class c) and JSS
by Mark Evenson 05 Aug '09

05 Aug '09

Unfortunately Alessio's (and Tobias?) work on [adding richness to inspection of Java objects][1] contains a bug that manifests itself in stopping [JSS][2] from working. The attached patch gets JSS to run again, but I am not sure the right way to fix the problem in the trunk, mainly as I don't understand all of our conversion rules, and how they interact with Java's autoboxing. The problem with JSS occurs when JavaObject.javaInstance(Class c) is invoked with a Class from a primitive boolean on an JavaObject that wraps a java.lang.Boolean. The call to java.lang.Class.isAssignableFrom() has an oddly (to me) specific contract that "[i]if [the] Class object represents a primitive type, this method returns true if the specified Class parameter is exactly this Class object; otherwise it returns false." This makes JavaObject<java.lang.Boolean>.javaInstance(boolean) fail, when everything seems to work fine if we simply return the wrapped object. What I don't understand mainly is if boolean/java.lang.Boolean objects are somehow special in our treatment of them, or should we do this for all of the other primitive types? [1]: http://trac.common-lisp.net/armedbear/changeset/12081 [2]: http://mumble.net:8080/svn/lsw/trunk/jss/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[armedbear-devel] test, please ignore
by Anton Vodonosov 02 Aug '09

02 Aug '09

1 0

[armedbear-devel] [PATCH] 20090731b Java stack frames
by Mark Evenson 01 Aug '09

01 Aug '09

Last night I sent out an older version of my work; attached is the correct current version. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

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

01 Aug '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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel