headers
Alessio Stalla | 1 Aug 2009 01:09
Picon

Re: Integration of CL and Java

On Sat, Aug 1, 2009 at 12:18 AM, Tobias C. Rittweiler<tcr@...> wrote:
>
> 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.

Working on that ;)

>    * 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.

Cool. I never thought about this, it's a great idea. We probably need
a JMethod extends JavaObject class to make this easier.

>    * add reader-macros for convenience. For example, #J'class.method
>      for (jmethod "class" "method").

This would be useful, but I also think we should provide some kind of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 Aug 2009 07:22
Picon
Favicon

[PATCH] 20090731b Java stack frames

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."

--- a/src/org/armedbear/lisp/BuiltInClass.java	Fri Jul 31 00:49:28 2009 +0200
+++ b/src/org/armedbear/lisp/BuiltInClass.java	Sat Aug 01 07:18:46 2009 +0200
 <at>  <at>  -143,6 +143,10  <at>  <at> 
   public static final BuiltInClass TWO_WAY_STREAM       = addClass(Symbol.TWO_WAY_STREAM);
   public static final BuiltInClass VECTOR               = addClass(Symbol.VECTOR);

+  public static final BuiltInClass STACK_FRAME          = addClass(Symbol.STACK_FRAME);
+  public static final BuiltInClass LISP_STACK_FRAME     = addClass(Symbol.LISP_STACK_FRAME);
+  public static final BuiltInClass JAVA_STACK_FRAME     = addClass(Symbol.JAVA_STACK_FRAME);
+
   public static final StructureClass STRUCTURE_OBJECT =
     new StructureClass(Symbol.STRUCTURE_OBJECT, list(CLASS_T));
   static
 <at>  <at>  -275,6 +279,13  <at>  <at> 
     TWO_WAY_STREAM.setCPL(TWO_WAY_STREAM, STREAM, CLASS_T);
     VECTOR.setDirectSuperclasses(list(ARRAY, SEQUENCE));
     VECTOR.setCPL(VECTOR, ARRAY, SEQUENCE, CLASS_T);
+
+    STACK_FRAME.setDirectSuperclasses(CLASS_T);
+    STACK_FRAME.setCPL(STACK_FRAME, CLASS_T);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Reiners | 2 Aug 2009 19:15
Picon
Gravatar

Re: ABCL introductory user documentation

I just finished making the corrections you suggested:


http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html

I also improved the format a lot.

Would there be any interest in moving this over (or a modified version of this over) to the Armed Bear web site as a start on User Documentation?

Paul


On Thu, Jul 30, 2009 at 2:48 AM, Alessio Stalla <alessiostalla-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Good work! It's nice to see introductory documentation for abcl.

Now the (constructive) criticism part :) I found an inaccuracy on
Slide 10, regarding boxing/unboxing of values. Indeed boxing and
unboxing is done automatically by ABCL. In your case, had you wrapped
your ints in Fixnums instead of JavaObjects, you could have used them
directly in Lisp. In general, since the user can't be expected to know
how to map every Java type to Lisp and vice-versa, there are a couple
of nice methods you can use in all cases:

public static LispObject JavaObject.getInstance(Object, boolean)
converts (or wraps) a Java object to a Lisp object, if the boolean is
true (else it just wraps it in a JavaObject).

public Object LispObject.javaInstance()
converts (or unwraps) a Lisp object to Java. You can invoke this on
any Lisp object, if it can't be converted, it will be returned as-is.

_______________________________________________
armedbear-devel mailing list
armedbear-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 7 comments |
headers
Mark Evenson | 3 Aug 2009 15:42
Picon
Favicon

Re: ABCL introductory user documentation

On 8/2/09 7:15 PM, Paul Reiners wrote:
> I just finished making the corrections you suggested:
>
>     http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html
>
> I also improved the format a lot.
>
> Would there be any interest in moving this over (or a modified version
> of this over) to the Armed Bear web site as a start on User Documentation?

I think we would be interested in including your contribution but you'll 
have to be a little patient with us for a more detailed reply.  Erik, 
who has a pretty clear idea of presentation vis a vis the ABCL web 
pages, is on vacation until August 15.

Thanks for the proposed contribution!

Mark

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 6 comments |
headers
Ville Voutilainen | 3 Aug 2009 15:48
Picon

Re: ABCL introductory user documentation

2009/8/3 Mark Evenson <evenson@...>:
> On 8/2/09 7:15 PM, Paul Reiners wrote:
>> I just finished making the corrections you suggested:
>>     http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html
>> I also improved the format a lot.
>> Would there be any interest in moving this over (or a modified version
>> of this over) to the Armed Bear web site as a start on User Documentation?
> I think we would be interested in including your contribution but you'll
> have to be a little patient with us for a more detailed reply.  Erik,
> who has a pretty clear idea of presentation vis a vis the ABCL web
> pages, is on vacation until August 15.
> Thanks for the proposed contribution!
> Mark

I have read that doc a couple of times, and I like it. Sure, there's
some duplication
between that and the documentation we have, and cross-referencing the existing
examples would perhaps be nice, but it looks quite good to me. It'll
take a while
before we can integrate it, as Mark said, because of vacations. Anyhow, I think
it looks like a valuable addition to what we have, and also looks like
a nice basis
on top of which to build further documentation.
Permalink | Reply | 5 comments |
headers
Ville Voutilainen | 3 Aug 2009 18:51
Picon

Re: ABCL introductory user documentation

2009/8/3 Paul Reiners <paul.reiners@...>:
> I can do some work on cross-referencing the existing examples.  I'll let you
> know when that's done.  I can certainly get it done before the 15th.

Erik usually puts under-development web pages under a staging area. I'm not
familiar with that process, so I'd rather have him do the updates to the web
pages. Thus there's no hurry. :)
Permalink | Reply | 0 comments |
headers
Paul Reiners | 3 Aug 2009 18:40
Picon
Gravatar

Re: ABCL introductory user documentation

I can do some work on cross-referencing the existing examples.  I'll let you know when that's done.  I can certainly get it done before the 15th.

Paul


On Mon, Aug 3, 2009 at 8:48 AM, Ville Voutilainen <ville.voutilainen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:


between that and the documentation we have, and cross-referencing the existing
examples would perhaps be nice, but it looks quite good to me. It'll


_______________________________________________
armedbear-devel mailing list
armedbear-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 1 comment |
headers
Paul Reiners | 4 Aug 2009 03:27
Picon
Gravatar

Re: ABCL introductory user documentation

I did some more work on the page tonight:

http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html

I did the following:

  • Added some links to already existing code samples
  • Added a "Calling Java from Lisp" section.  This was basically taken from Ville's example code (for which I gave credit and linked to).
  • Added a note at the bottom stating that the code samples in the article are released under the GPL
  • Used the ABCL site style-sheet for the page

I think I should add a navigation bar on the left that links to the sections, but I'm not going to do that tonight.

If anyone has any other ideas for improvement, let me know.

Paul


On Aug 3, 2009, at 8:48 AM, Ville Voutilainen wrote:

I have read that doc a couple of times, and I like it. Sure, there's
some duplication
between that and the documentation we have, and cross-referencing the existing
examples would perhaps be nice, but it looks quite good to me. It'll

_______________________________________________
armedbear-devel mailing list
armedbear-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 2 comments |
headers
Mark Evenson | 5 Aug 2009 17:17
Picon
Favicon

[PATCH] Problems with new JavaObject.javaInstance(Class c) and JSS

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."
Attachment (java-instance-primitive-types.diff): text/x-diff, 1892 bytes
_______________________________________________
armedbear-devel mailing list
armedbear-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply | 5 comments |
headers
Alessio Stalla | 5 Aug 2009 17:33
Picon

Re: [PATCH] Problems with new JavaObject.javaInstance(Class c) and JSS

On Wed, Aug 5, 2009 at 5:17 PM, Mark Evenson<evenson@...> wrote:
> 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.

Right, that's an oversight on my part. Unfortunately Java's reflection
does not know about automatic boxing/unboxing, you have to do it by
yourself.

> 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?

The latter. I believe there's already code written for this somewhere
(in jmethod perhaps?), so maybe we could generalize & reuse that code.

Also, I have a question about your patch: do you have a specific
reason to handle null by always signaling an error? In principle, null
is assignable to any non-primitive type, so the type error ought to be
signaled only for primitive types, imho.

Bye,
Alessio

> [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."
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel@...
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
>
Permalink | Reply | 3 comments |

Gmane