On Mon, Oct 19, 2009 at 2:59 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Mon, Oct 19, 2009 at 2:22 PM, Alex Muscar muscar@gmail.com wrote:
Hi,
I've been messing around with the code. I've managed to load the fasl, but I think we're missing some initializations because I get the following error:
ERROR placeholder called with arguments: #<UNDEFINED-FUNCTION SYSTEM::ENSURE-AVAILABLE-SYMBOLS {E5F46E}>
Here's a full stack trace:
org.armedbear.lisp.ConditionThrowable: java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1459)
OT, but not too much: if we used named classes for primitives we could get more meaningful stack traces (say, JCALL instead of Primitives$XY). I.e. instead of
private static final Primitive xyz = new Primitive(...) { ... };
we could use
private static class JCALL extends Primitive { JCALL(...) { super(...); } ... } private static final Primitive xyz = new JCALL(...);
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-)
Bye,
Erik.
Erik Huelsmann writes:
On Mon, Oct 19, 2009 at 2:59 PM, Alessio Stalla alessiostalla@gmail.com wrote:
private static final Primitive xyz = new Primitive(...) { ... };
we could use
private static class JCALL extends Primitive { JCALL(...) { super(...); } ... } private static final Primitive xyz = new JCALL(...);
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-)
If someone does, it may make sense to also include source location information to make M-. on primitives jump to the Java source. I actually started to work on it, but haven't had any time since.
-T.
On 10/19/09 5:48 PM, Erik Huelsmann wrote: […]
a bit more verbose, but worth the effort imho.
I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-)
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing, but it seems a little neglected since 2007 so it won't easily run in a modern IDE. Interestingly it has an "add overrides" example that would have helped out adding all the override statements.
[1]: http://jackpot.netbeans.org/ [2]: http://hg.netbeans.org/main/contrib/raw-file/tip/jackpot/src/org/netbeans/mo...
There appear to be 768 instances that need transformation, so the task is indeed suitable to use some sort of automatic tool.
I'd give this a whack but I simply don't have extra time until the end of October due to work constraints.
I would make the following suggestions if someone else takes on this task:
1) We should name the functions in all lowercase in analogy to the various "standalone" extensions of Primitive like 'open_stream_p.java', 'make_array.java', etc. This produces a more readable stack trace in my opinion.
2) Don't forget to retain the comments with the '###' string in them: they form the necessary linkage for SYSTEM::GROVEL-JAVA-DEFINITIONS
3) Use a no argument constructor in the primitive that calls the appropriate super with the arguments, e.g.
// ### packagep // packagep object => generalized-boolean private static final Primitive PACKAGEP = new Primitive("packagep", "object") { @Override public LispObject execute(LispObject arg) throws ConditionThrowable { return arg instanceof Package ? T : NIL; } };
becomes
// ### packagep // packagep object => generalized-boolean private static final Primitive PACKAGEP = new packagep();
private static class packagep extends Primitive { packagep() { super("packagep", "object"); } @Override public LispObject execute(LispObject arg) throws ConditionThrowable { return arg instanceof Package ? T : NIL; } };
Mark Evenson writes:
- Don't forget to retain the comments with the '###' string in them:
they form the necessary linkage for SYSTEM::GROVEL-JAVA-DEFINITIONS
You don't need that if you store source-location information inside each Primitive object.
-T.
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST:
http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html
At the moment, that's read-only access, but I wouldn't be surprised if that restriction will be lifted at some point in future. And we all know what this will mean: Java gets macros in disguise. :-)
Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility...
-T.
"Tobias C. Rittweiler" writes:
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST:
http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html
That url linked to the Compiler API, here the direct link to the Compiler Tree Api:
http://java.sun.com/javase/6/docs/jdk/api/javac/tree/index.html
-T.
On Tue, Oct 20, 2009 at 9:02 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
Mark Evenson writes:
It would be better to have a tool that can grok the Abstract Syntax Tree for Java, transforming that. [Jackpot][1] should be the kind of tool that would help with this sort of thing,
By the way, Java6 contains an API to the Java AST:
http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html
At the moment, that's read-only access, but I wouldn't be surprised if that restriction will be lifted at some point in future. And we all know what this will mean: Java gets macros in disguise. :-)
I believe C# sort of has them already now... ;)
Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility...
I haven't yet understood exactly what invokedynamic is; would it be helpful for abcl?
Alessio Stalla writes:
Combined with invokedynamic, Java6 becomes an even more so interesting platform. Perhaps interesting enough to throw out backwards compatibility...
I haven't yet understood exactly what invokedynamic is; would it be helpful for abcl?
My understanding is based on 5 minutes reading about it, so take it with a grain of salt. From my understanding, when using invokedynamic, code is compiled to something like (transliterated to Lisp):
(defun foo (x y) (declare (type t x y)) (check-type x integer) (check-type y integer) (+ x y))
I.e. types are checked at run-time, but the code following the type checks is compiled with the assumption of the type-checks. In the example, the call to + may assume that X and Y are in fact integers, not just any objects.
-T.
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Erik Huelsmann -
Mark Evenson -
Tobias C. Rittweiler