From: Alessio S. <ale...@gm...> - 2008-09-23 18:46:51
|
Hello everyone. I'm doing some experiments on embedding ABCL in a Java application. Depending on the results, I may give a talk about it to a bunch of Java developers :) But I have a simple question. Suppose I need to package some additional Lisp files together with ABCL (for example, to offer a nicer Lisp API to my Java application - I'm not talking of a complete Lisp library here). How is the preferred way of doing it? The Java way would be to store these files in a Jar file, and load them as classpath resources. Indeed by looking at ABCL's source I see that Load.java has the capability to load code from any stream, not just files, but those methods are private (probably for a reason ;-) The Lisp way instead should be to load them into ABCL, dump an image and package ABCL + the image into the application. The problems with this approach are 1) I don't know how to do it ;) 2) from the point of view of a Java developer, depending on a file outside a jar is not nice or at least it's not the common behaviour of Java libraries... Problem 1) is easily solved, and is one of the reasons behind this post; problem 2) might not be a real problem, and an acceptable solution is not hard to find anyway. So, what do you think? Any suggestions? Thanks in advance, Alessio Stalla |
From: Ville V. <vil...@gm...> - 2008-09-23 19:42:09
|
On Tue, Sep 23, 2008 at 9:44 PM, Alessio Stalla <ale...@gm...> wrote: > But I have a simple question. Suppose I need to package some > additional Lisp files together with ABCL (for example, to offer a > nicer Lisp API to my Java application - I'm not talking of a complete > Lisp library here). How is the preferred way of doing it? The Java way > would be to store these files in a Jar file, and load them as > classpath resources. Indeed by looking at ABCL's source I see that Well, immediately two options come to mind: 1) load the files as classpath resources, dump (write) to normal files and let abcl load them as normal files 2) wait until someone adds the ability for abcl to load lisp files from a jar file. This is not far-fetched at all. another option is 3) add the ability mentioned in 2) to abcl yourself, it's free software and contributions are welcome HTH, -VJV- |
From: Alessio S. <ale...@gm...> - 2008-09-23 21:12:28
|
I was investigating option 3), when I found that ABCL more or less already supports this - the LOAD function accepts a stream as its first argument, and behaves as one expects :) The only drawback is that, apparently, you can only load source streams, not fasls - but for my simple needs, that's sufficient. So, ABCL itself needs not to be modified; I just wrote a couple of utility methods to make it easier to access that functionality from Java. I'm sharing those here in case someone else steps into the same "problem", or in case someone who knows ABCL well enough finds them useful and knows a suitable place where they can be put: ------------------------------ public LispObject loadFromClasspath(String classpathResource) throws ConditionThrowable { InputStream istream = getClass().getResourceAsStream(classpathResource); Stream stream = new Stream(istream, Symbol.CHARACTER); return load(stream); } public LispObject load(Stream stream) throws ConditionThrowable { Symbol keyword_verbose = Lisp.internKeyword("VERBOSE"); Symbol keyword_print = Lisp.internKeyword("PRINT"); /* load (filespec &key (verbose *load-verbose*) (print *load-print*) (if-does-not-exist t) (external-format :default) */ return Symbol.LOAD.getSymbolFunction().execute(new LispObject[] { stream, keyword_verbose, Lisp.NIL, keyword_print, Lisp.T, Keyword.IF_DOES_NOT_EXIST, Lisp.T, Keyword.EXTERNAL_FORMAT, Keyword.DEFAULT }); } ------------------------------ If you find something obviously incorrect in this code, please tell me... Cheers, Alessio S. On Tue, Sep 23, 2008 at 9:41 PM, Ville Voutilainen <vil...@gm...> wrote: > On Tue, Sep 23, 2008 at 9:44 PM, Alessio Stalla <ale...@gm...> wrote: >> But I have a simple question. Suppose I need to package some >> additional Lisp files together with ABCL (for example, to offer a >> nicer Lisp API to my Java application - I'm not talking of a complete >> Lisp library here). How is the preferred way of doing it? The Java way >> would be to store these files in a Jar file, and load them as >> classpath resources. Indeed by looking at ABCL's source I see that > > Well, immediately two options come to mind: > > 1) load the files as classpath resources, dump (write) to normal files and let > abcl load them as normal files > > 2) wait until someone adds the ability for abcl to load lisp files > from a jar file. This is not far-fetched > at all. > > another option is > > 3) add the ability mentioned in 2) to abcl yourself, it's free > software and contributions > are welcome > > HTH, > -VJV- > |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-24 07:42:13
|
On Tue, Sep 23, 2008 at 8:44 PM, Alessio Stalla <ale...@gm...> wrote: > Hello everyone. I'm doing some experiments on embedding ABCL in a Java > application. Depending on the results, I may give a talk about it to a > bunch of Java developers :) > > But I have a simple question. Suppose I need to package some > additional Lisp files together with ABCL (for example, to offer a > nicer Lisp API to my Java application - I'm not talking of a complete > Lisp library here). How is the preferred way of doing it? The Java way > would be to store these files in a Jar file, and load them as > classpath resources. Indeed by looking at ABCL's source I see that > Load.java has the capability to load code from any stream, not just > files, but those methods are private (probably for a reason ;-) > The Lisp way instead should be to load them into ABCL, dump an image > and package ABCL + the image into the application. The problems with > this approach are 1) I don't know how to do it ;) 2) from the point of > view of a Java developer, depending on a file outside a jar is not > nice or at least it's not the common behaviour of Java libraries... > Problem 1) is easily solved, and is one of the reasons behind this > post; problem 2) might not be a real problem, and an acceptable > solution is not hard to find anyway. > So, what do you think? Any suggestions? Well, I'm creating an application which I deliver with 15 .jars and 2 .abcl files. I use some 5 lines of code to find out where my jar is and load the .abcl from the same location. I haven't noticed anybody actually noticing they're not all jars... Bye, Erik. |
From: Alessio S. <ale...@gm...> - 2008-09-24 09:50:12
|
Erik, that's good to hear: both that you are actually using ABCL to ship an application, which means that ABCL is mature enough (for you anyway), and that nobody cares if they're not all jars ;) - although my target (imaginary, for now) users are developers, and those kind of people do tend to complain about minor things like that... ;) Anyway as I said, I have solved the problem in a satisfactory way. BTW to get a feel of the Java side of ABCL, and looking forward to using it as a scripting language for my application, I'm working on integrating ABCL with the Java scripting API introduced with Java 6. If that works out, it should make it easier for Java developers to adopt and use ABCL as an extension language... if anyone is interested, when the code is mature enough I'll be happy to publish it on common-lisp.net or sourceforge, whichever fits it better. Bye, Alessio PS Sorry for the multiple postings... On Wed, Sep 24, 2008 at 9:42 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Tue, Sep 23, 2008 at 8:44 PM, Alessio Stalla <ale...@gm...> wrote: >> Hello everyone. I'm doing some experiments on embedding ABCL in a Java >> application. Depending on the results, I may give a talk about it to a >> bunch of Java developers :) >> >> But I have a simple question. Suppose I need to package some >> additional Lisp files together with ABCL (for example, to offer a >> nicer Lisp API to my Java application - I'm not talking of a complete >> Lisp library here). How is the preferred way of doing it? The Java way >> would be to store these files in a Jar file, and load them as >> classpath resources. Indeed by looking at ABCL's source I see that >> Load.java has the capability to load code from any stream, not just >> files, but those methods are private (probably for a reason ;-) >> The Lisp way instead should be to load them into ABCL, dump an image >> and package ABCL + the image into the application. The problems with >> this approach are 1) I don't know how to do it ;) 2) from the point of >> view of a Java developer, depending on a file outside a jar is not >> nice or at least it's not the common behaviour of Java libraries... >> Problem 1) is easily solved, and is one of the reasons behind this >> post; problem 2) might not be a real problem, and an acceptable >> solution is not hard to find anyway. >> So, what do you think? Any suggestions? > > Well, I'm creating an application which I deliver with 15 .jars and 2 > .abcl files. I use some 5 lines of code to find out where my jar is > and load the .abcl from the same location. I haven't noticed anybody > actually noticing they're not all jars... > > Bye, > > Erik. > |
From: Ville V. <vil...@gm...> - 2008-09-24 10:27:50
|
On Wed, Sep 24, 2008 at 12:50 PM, Alessio Stalla <ale...@gm...> wrote: > Anyway as I said, I have solved the problem in a satisfactory way. BTW > to get a feel of the Java side of ABCL, and looking forward to using > it as a scripting language for my application, I'm working on > integrating ABCL with the Java scripting API introduced with Java 6. > If that works out, it should make it easier for Java developers to > adopt and use ABCL as an extension language... if anyone is > interested, when the code is mature enough I'll be happy to publish it > on common-lisp.net or sourceforge, whichever fits it better. Sounds excellent, this has been in my plans for some time. Do you think it's possible to do this without modifying abcl at all, by building the Java Scripting support on top of abcl? I'd really like to see any progress you make with this, as soon as possible. -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-24 12:10:36
|
On Wed, Sep 24, 2008 at 12:27 PM, Ville Voutilainen <vil...@gm...> wrote: > On Wed, Sep 24, 2008 at 12:50 PM, Alessio Stalla > <ale...@gm...> wrote: >> Anyway as I said, I have solved the problem in a satisfactory way. BTW >> to get a feel of the Java side of ABCL, and looking forward to using >> it as a scripting language for my application, I'm working on >> integrating ABCL with the Java scripting API introduced with Java 6. >> If that works out, it should make it easier for Java developers to >> adopt and use ABCL as an extension language... if anyone is >> interested, when the code is mature enough I'll be happy to publish it >> on common-lisp.net or sourceforge, whichever fits it better. Well, as far as I'm concerned, we could make it part of ABCL (if the compilation target is 1.6), if you don't mind making it public under GPL + classpath exception. > Sounds excellent, this has been in my plans for some time. Do you think > it's possible to do this without modifying abcl at all, by building the Java > Scripting support on top of abcl? > > I'd really like to see any progress you make with this, as soon as possible. Maybe the 2 of you could help each other, possibly in the ABCL repository in a separate directory in the source tree? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-09-24 13:49:03
|
On Wed, Sep 24, 2008 at 3:10 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > Maybe the 2 of you could help each other, possibly in the ABCL > repository in a separate directory in the source tree? That sounds suitable for me. As a bonus, we'd have an existing repository for Alessio's work, so there's no need to go through the trouble of creating a repository for this from scratch. |
From: Alessio S. <ale...@gm...> - 2008-09-24 13:02:27
|
I've not studied the problem extensively, but it seems that for the basic scripting API it can be done without modifying ABCL, by just wrapping its Java API. However, I plan to add a little support on the Lisp side to ease things a bit. This needs not to be part of ABCL, but can be provided as a separate module; OTOH, nothing prevents adding it to the ABCL codebase later. However, I have not yet explored the more complicated parts of the API (which are optional, but it would be nice to have them anyway), such as support for compilation of scripts. From my first impression, I think the API is general enough to still allow to get away with just building things on top of ABCL. Of course, this comes with a little performance overhead since ABCL uses its internal data structures, while the API has its own, so a little marshalling/unmarshalling is necessary, but I don't think this is a significant problem. So, as soon as I make some decent progress (I work on this on my free time, and I don't have much of it), I'll promptly tell you. And of course, if someone wants to contribute (s)he's welcome - just drop me an email. It's nice to see there's interest in the subject... Cheers, Alessio On Wed, Sep 24, 2008 at 12:27 PM, Ville Voutilainen <vil...@gm...> wrote: > On Wed, Sep 24, 2008 at 12:50 PM, Alessio Stalla > <ale...@gm...> wrote: >> Anyway as I said, I have solved the problem in a satisfactory way. BTW >> to get a feel of the Java side of ABCL, and looking forward to using >> it as a scripting language for my application, I'm working on >> integrating ABCL with the Java scripting API introduced with Java 6. >> If that works out, it should make it easier for Java developers to >> adopt and use ABCL as an extension language... if anyone is >> interested, when the code is mature enough I'll be happy to publish it >> on common-lisp.net or sourceforge, whichever fits it better. > > Sounds excellent, this has been in my plans for some time. Do you think > it's possible to do this without modifying abcl at all, by building the Java > Scripting support on top of abcl? > > I'd really like to see any progress you make with this, as soon as possible. > > -VJV- > |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-24 13:20:26
|
On Wed, Sep 24, 2008 at 3:02 PM, Alessio Stalla <ale...@gm...> wrote: > I've not studied the problem extensively, but it seems that for the > basic scripting API it can be done without modifying ABCL, by just > wrapping its Java API. However, I plan to add a little support on the > Lisp side to ease things a bit. This needs not to be part of ABCL, but > can be provided as a separate module; OTOH, nothing prevents adding it > to the ABCL codebase later. > However, I have not yet explored the more complicated parts of the API > (which are optional, but it would be nice to have them anyway), such > as support for compilation of scripts. From my first impression, I > think the API is general enough to still allow to get away with just > building things on top of ABCL. Of course, this comes with a little > performance overhead since ABCL uses its internal data structures, > while the API has its own, so a little marshalling/unmarshalling is > necessary, but I don't think this is a significant problem. > > So, as soon as I make some decent progress (I work on this on my free > time, and I don't have much of it), I'll promptly tell you. And of > course, if someone wants to contribute (s)he's welcome - just drop me > an email. It's nice to see there's interest in the subject... In that case, let me shamelessly plug a book of a friend of mine: http://www.producingoss.com/ It's a great description of how OSS communities *can* be run, including hints on how to create one. Bye, Erik. |
From: Alessio S. <ale...@gm...> - 2008-09-24 14:08:40
|
On Wed, Sep 24, 2008 at 2:10 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Wed, Sep 24, 2008 at 12:27 PM, Ville Voutilainen > <vil...@gm...> wrote: >> On Wed, Sep 24, 2008 at 12:50 PM, Alessio Stalla >> <ale...@gm...> wrote: >>> Anyway as I said, I have solved the problem in a satisfactory way. BTW >>> to get a feel of the Java side of ABCL, and looking forward to using >>> it as a scripting language for my application, I'm working on >>> integrating ABCL with the Java scripting API introduced with Java 6. >>> If that works out, it should make it easier for Java developers to >>> adopt and use ABCL as an extension language... if anyone is >>> interested, when the code is mature enough I'll be happy to publish it >>> on common-lisp.net or sourceforge, whichever fits it better. > > Well, as far as I'm concerned, we could make it part of ABCL (if the > compilation target is 1.6), if you don't mind making it public under > GPL + classpath exception. I don't mind at all, it would be great for me if my work became part of ABCL. >> Sounds excellent, this has been in my plans for some time. Do you think >> it's possible to do this without modifying abcl at all, by building the Java >> Scripting support on top of abcl? >> >> I'd really like to see any progress you make with this, as soon as possible. > > Maybe the 2 of you could help each other, possibly in the ABCL > repository in a separate directory in the source tree? > That would be great. As I said earlier, any kind of collaboration is welcome. Bye, Alessio > > Bye, > > Erik. > |
From: Ville V. <vil...@gm...> - 2008-09-24 16:02:51
|
>> Maybe the 2 of you could help each other, possibly in the ABCL >> repository in a separate directory in the source tree? > That would be great. As I said earlier, any kind of collaboration is welcome. So, could we do so that Alessio gives Erik the code written so far, so that Erik can put it into the repository? Do we need a branch in order to control committer privileges? I'd like to keep abcl as solely Erik's turf so that he triages all commits there. Adding Java Scripting on top is not critical to J or abcl so there's probably more leeway. |
From: Alessio S. <ale...@gm...> - 2008-09-25 09:14:31
|
I have a basic working implementation now. If Erik is ok with it, when I return home this evening I can send him the code so he can put it into the repository. I just need to put a summary of the license at the beginning of each file, I'll copy it from ABCL source files. I don't know how svn commit privileges work, but it would be a great thing to have, especially in this early phase when a lot of things are subject to change... Ale On Wed, Sep 24, 2008 at 5:58 PM, Ville Voutilainen <vil...@gm...> wrote: >>> Maybe the 2 of you could help each other, possibly in the ABCL >>> repository in a separate directory in the source tree? >> That would be great. As I said earlier, any kind of collaboration is welcome. > > So, could we do so that Alessio gives Erik the code written so far, so that > Erik can put it into the repository? Do we need a branch in order to control > committer privileges? I'd like to keep abcl as solely Erik's turf so that > he triages all commits there. Adding Java Scripting on top is not > critical to J or abcl so there's probably more leeway. > |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-25 09:52:24
|
On Thu, Sep 25, 2008 at 11:06 AM, Alessio Stalla <ale...@gm...> wrote: > I have a basic working implementation now. If Erik is ok with it, when > I return home this evening I can send him the code so he can put it > into the repository. I just need to put a summary of the license at > the beginning of each file, I'll copy it from ABCL source files. I > don't know how svn commit privileges work, but it would be a great > thing to have, especially in this early phase when a lot of things are > subject to change... Well, in open source it works this way: depending on your role and contributions, the project maintainer(s) may decide to grant you commit access; sometimes to specific parts of the repository. Before you send me the code, I think it would be good to discuss where in the source tree it should be stored. Inside the lisp/ directory might be less handy, because of the fact that it will be harder to exclude the files when making a 1.5 build. This becomes less of an issue if we create a lisp/javascripting directory though. How did you intend to name your package? If you didn't come up with a name yet, how about: org.armedbear.lisp.javascripting ? I quickly considered how to get the code into the repository and get you two working on it. This is my proposed plan: You send me (or the list whichever you prefer) the code tonight, so I can have a look at it. If I have any comments, I'll send them in response. In the mean time, I'll try to get you two set up as committing members of the project on common-lisp.net. This may take a few days. I'd like the two of you to commit directly to the repository, but we'll set up a branch for your work (to be integrated into the trunk when the code is less "in flux"). I'd appreciate it if you didn't commit to the trunk yet without prior notice (partial commitership for the branch). Then, after a while, when we're all settled and in agreement of the quality of code we're trying to deliver, we can agree that you can commit anywhere you like (full committership). How does that sound to you? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-09-25 10:01:26
|
On Thu, Sep 25, 2008 at 12:50 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > If you didn't come up with a name yet, how about: > org.armedbear.lisp.javascripting ? Gets confused with javascript. :) org.armedbear.lisp.jsr223? <blech, I don't like that either..> Maybe org.armedbear.lisp.scripting or org.armedbear.lisp.script > In the mean time, I'll try to get you two set up as committing members > of the project on common-lisp.net. This may take a few days. I'd like > the two of you to commit directly to the repository, but we'll set up > a branch for your work (to be integrated into the trunk when the code > is less "in flux"). I'd appreciate it if you didn't commit to the > trunk yet without prior notice (partial commitership for the branch). > Then, after a while, when we're all settled and in agreement of the > quality of code we're trying to deliver, we can agree that you can > commit anywhere you like (full committership). > How does that sound to you? Sounds perfect to me. |
From: Alessio S. <ale...@gm...> - 2008-09-25 10:06:20
|
On Thu, Sep 25, 2008 at 11:50 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Thu, Sep 25, 2008 at 11:06 AM, Alessio Stalla > <ale...@gm...> wrote: >> I have a basic working implementation now. If Erik is ok with it, when >> I return home this evening I can send him the code so he can put it >> into the repository. I just need to put a summary of the license at >> the beginning of each file, I'll copy it from ABCL source files. I >> don't know how svn commit privileges work, but it would be a great >> thing to have, especially in this early phase when a lot of things are >> subject to change... > > Well, in open source it works this way: depending on your role and > contributions, the project maintainer(s) may decide to grant you > commit access; sometimes to specific parts of the repository. > > Before you send me the code, I think it would be good to discuss where > in the source tree it should be stored. Inside the lisp/ directory > might be less handy, because of the fact that it will be harder to > exclude the files when making a 1.5 build. > > This becomes less of an issue if we create a lisp/javascripting > directory though. How did you intend to name your package? > > If you didn't come up with a name yet, how about: > org.armedbear.lisp.javascripting ? > For now, it is named abcl-script. This would not fit very well in the org.armedbear... package hierarchy, so I think ...scripting as suggested by Ville is better. > > I quickly considered how to get the code into the repository and get > you two working on it. This is my proposed plan: You send me (or the > list whichever you prefer) the code tonight, so I can have a look at > it. If I have any comments, I'll send them in response. > > In the mean time, I'll try to get you two set up as committing members > of the project on common-lisp.net. This may take a few days. I'd like > the two of you to commit directly to the repository, but we'll set up > a branch for your work (to be integrated into the trunk when the code > is less "in flux"). I'd appreciate it if you didn't commit to the > trunk yet without prior notice (partial commitership for the branch). > Then, after a while, when we're all settled and in agreement of the > quality of code we're trying to deliver, we can agree that you can > commit anywhere you like (full committership). > > > How does that sound to you? > Sounds good :) Bye, Ale > > Bye, > > Erik. > |