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

[armedbear-devel] No JSR-223 code in abcl-src-0.15.tar.gz
by Alessio Stalla 28 Aug '09

28 Aug '09

Greetings all, I have downloaded the 0.15 release of abcl from the official site, to use it in a side-project at work. I found out that the archive does not contain the src/org/armedbear/lisp/scripting directory, where the JSR-223 stuff resides. Worse, the archive does contain the META-INF/services/javax.script.ScriptEngineFactory, so when built the jar actually declares it contains a JSR-223 implementation, but it does not. How is the archive built? I think I saw tasks in the Ant-based build file to zip the source, maybe those don't include the scripting/ directory. If that is the case, I can fix it for build.xml. I don't know how the Lisp based build works, though. Alessio

2 3

[armedbear-devel] Embedding ABCL into IntelliJ IDEA and writing plugins
by Anton Vodonosov 23 Aug '09

23 Aug '09

Hello, I created IntelliJ IDEA plugin that embeds ABCL, allows to connect from SLIME and extend IDEA using Common Lisp. I haven't contrived any useful functionality (that is easy to implement), therefore, for the sake of example, the plugin ads to IDEA commands yank and yank-pop, like in Emacs. Source may be found here: http://github.com/avodonosov/abcl-idea/tree/master Binary distro: http://cloud.github.com/downloads/avodonosov/abcl-idea/abcl-idea.zip There is a readme, check it for more details. Some conclusions from my experience: - it is absolutely possible to create IDEA plugins using ABCL. - Jfli interface to java is currently more convenient than native ABCL's - ABCL's performance of slime fuzzy-completion is still unsatisfying (it is the only little unsatisfying thing for me) - ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like: if (jlisp) { ... close input output streams } else System.exit(status); I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process This is not a big problem, because with having Interpreter source code we may But having source code we can copy/past desirable kill behavior - closing streams. But it would make sense to reactor it a little to be more embedding friendly. If somebody is interested to write IDEA plugins in Lisp, my plugin may be used as a basis for further extension. Best regards, - Anton

3 4

Re: [armedbear-devel] progress on Maxima + ABCL -- light at the end of the tunnel!
by Erik Huelsmann 09 Aug '09

09 Aug '09

On Thu, Jul 30, 2009 at 8:04 PM, Robert Dodier<robert_dodier(a)yahoo.com> wrote: > > --- On Thu, 7/30/09, Erik Huelsmann <ehuels(a)gmail.com> wrote: > >> Another question: I'm running these profiles too, of >> course. On my system rtest_integrate takes forever to run, >> could that be this is the main cause it takes that long? >> Should we start profiling only that test set? > > Yes, that sounds reasonable. The integration code makes > use of the sign-inference code, to which DGR and DLS belong, > so maybe it is actually true that they are doing something > that is taking a long time. Well, I found a reason why ABCL may be taking so extremely long: in SPRDET.lisp, there's a top-level special declaration of the variable name X. In ABCL such declarations are retained after file compilation completes (which is allowed by the spec). Hence, after compilation of sprdet.lisp, any reference to a variable with the name X, or creation of a binding thereof, is a special binding. In ABCL, there's a non-trivial difference between evaluation of a special variable versus a local variable. So, renaming the special variable could be a solution, but that would require a change on part of Maxima; I'm thinking about how to revert the side effect at the end of the file compilation. That's a non-trivial change to ABCL. I haven't figured it out yet. Bye, Erik.

2 5

[armedbear-devel] European Common Lisp Meeting
by Arthur Lemmens 07 Aug '09

07 Aug '09

Hi, We just want to remind you that the registration deadline for this year's ECLM (European Common Lisp Meeting) is August 15. You can still register at http://weitz.de/eclm2009 We hope to see you in Hamburg, Edi Weitz & Arthur Lemmens

1 0

[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