Java / lisp
Unable to parse email body. Email id is 5178
Unable to parse email body. Email id is 5178
I haven't toyed with it yet, but http://foil.sourceforge.net/ seems extremely promising in that department. As far as I understand how it works, they set-up a Java server process you connect to from Lisp using sockets. Once on the server, your requests have access to 100% of the java stuff, be it Swing or otherwise. -- JFB On 10 Jan 2006, at 18:03, Nick Levine wrote: > > Can anyone give me an expected pain estimate for either of the > following: > > 1) LispWorks invokes functionality writen in Java > > 2) LispWorks integrates with a Java GUI > > Thanks, > > - nick > -- Jean-François Brouillet verec@mac.com
On Tue, 10 Jan 2006 18:03:51 GMT, Nick Levine <ndl@ravenbrook.com> wrote: > Can anyone give me an expected pain estimate for either of the > following: > > 1) LispWorks invokes functionality writen in Java > > 2) LispWorks integrates with a Java GUI Part 1 should be painless, part 2 less so, I think. I played around with JFLI <http://jfli.sourceforge.net/> some time ago and found it to be pretty easy to set up - it just worked. (It probably helps that JFLI was developed on LispWorks.) Although JFLI seems to be working and complete the focus of the developers has shifted towards FOIL which is supposed to replace JFLI: <http://foil.sourceforge.net/> I haven't used this one but as an example here's Francis Leboutte's "Dialogue" which deploys FOIL to create SWT dialogs: <http://www.algo.be/cl/dialogue/> I haven't done any GUI programming with Java/Lisp. I think the main pain will be to figure out how to do the stuff in Java because even though you're in a Lisp IDE you effectively let Java do the grunt work and there's no CAPI-like layer atop it. (Unless the Java GUI is already there and you just want to call back and forth between it and Lisp. That might be easy and fun if you're lucky.) HTH, Edi.
On Jan 10, 2006, at 1:26 PM, Edi Weitz wrote: > > On Tue, 10 Jan 2006 18:03:51 GMT, Nick Levine <ndl@ravenbrook.com> > wrote: > >> Can anyone give me an expected pain estimate for either of the >> following: >> >> 1) LispWorks invokes functionality writen in Java >> >> 2) LispWorks integrates with a Java GUI > > Part 1 should be painless, part 2 less so, I think. > > I played around with JFLI > > <http://jfli.sourceforge.net/> > > some time ago and found it to be pretty easy to set up - it just > worked. (It probably helps that JFLI was developed on LispWorks.) > > Although JFLI seems to be working and complete the focus of the > developers has shifted towards FOIL which is supposed to replace JFLI: > > <http://foil.sourceforge.net/> I am the author of jFli and Foil. Both are viable, and Foil represents less a replacement for jFli than a different set of tradeoffs. jFli runs a JVM in-proc and accesses it via JNI. It is a fast and easy way to do #1. However, being in-proc presents several challenges, especially for GUIs. Thus, Foil, which runs the JVM in a separate proc and communicates with it via sockets. This makes it easier to do #2, and multi-threaded programming in general, although some knowledge of Java is required if you want to create a custom JVM 'host' with particular threading/socket characteristics. There are samples doing GUI with SWT - see the screenshots. Both jFli and Foil offer similar, but not identical, high-level wrappers for Java classes/methods etc, transparent conversions and memory management. Both were authored in LispWorks, and are open source - feel free to fix/enhance... I'll let some non-author speak to the relative 'pain' of using jFli or Foil. Rich
For me, under LWL 4.3.7, using Jfli caused segmentation violations as the image size grew. I never could pin down the exact size problems would begin. Perhaps they began during a gc, for example. My final image was around 50Mb, unoptimized and unshaken, but the problems began before I reached that size. I finally had to abandon Jfli. I wrote an out-of-process socket-based interface between Java and Lisp, using Java reflection to generate stubs in Lisp, creating Java object instances and returning their handles to Lisp, calling methods via RPC calls using the handles, and "freeing" references to those instances when they are no longer needed. As I was finishing that software, Rich released Foil ... go figure :) I never tested Jfli under LWW with the same image size so I don't know if the same problems happen there. If I needed the same functionality again today, I'd start by looking at Foil. Jeff Caldwell --- Rich Hickey <rich@richhickey.com> wrote: .... > Both jFli and Foil offer similar, but not identical, high-level > wrappers for Java classes/methods etc, transparent conversions and > memory management. Both were authored in LispWorks, and are open > source - feel free to fix/enhance... > > I'll let some non-author speak to the relative 'pain' of using jFli > or Foil. > > Rich > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
At 11/01/2006 06:09, Jeff Caldwell wrote: >For me, under LWL 4.3.7, using Jfli caused segmentation violations as the >image size grew. I never could pin down the exact size problems would begin. >Perhaps they began during a gc, for example. My final image was around 50Mb, >unoptimized and unshaken, but the problems began before I reached that size. At some moment, my image (Foil/SWT app) suddenly grews from 30 Mb to about 60 Mb. I filtered some of the uneeded classes in the Java packages I use and the size went back to a more decent 30Mb (still completely unoptimized). >I finally had to abandon Jfli. I wrote an out-of-process socket-based >interface between Java and Lisp, using Java reflection to generate stubs in >Lisp, creating Java object instances and returning their handles to Lisp, >calling methods via RPC calls using the handles, and "freeing" references to >those instances when they are no longer needed. As I was finishing that >software, Rich released Foil ... go figure :) I'm impressed! Francis >I never tested Jfli under LWW with the same image size so I don't know if the >same problems happen there. If I needed the same functionality again today, >I'd start by looking at Foil. > >Jeff Caldwell > > >--- Rich Hickey <rich@richhickey.com> wrote: > >... > > Both jFli and Foil offer similar, but not identical, high-level > > wrappers for Java classes/methods etc, transparent conversions and > > memory management. Both were authored in LispWorks, and are open > > source - feel free to fix/enhance... > > > > I'll let some non-author speak to the relative 'pain' of using jFli > > or Foil. > > > > Rich > > > > > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com
At 10/01/2006 20:07, Rich Hickey wrote: >On Jan 10, 2006, at 1:26 PM, Edi Weitz wrote: > >> >>On Tue, 10 Jan 2006 18:03:51 GMT, Nick Levine <ndl@ravenbrook.com> >>wrote: >> >>>Can anyone give me an expected pain estimate for either of the >>>following: >>> >>>1) LispWorks invokes functionality writen in Java >>> >>>2) LispWorks integrates with a Java GUI >> >>Part 1 should be painless, part 2 less so, I think. >> >>I played around with JFLI >> >> <http://jfli.sourceforge.net/> >> >>some time ago and found it to be pretty easy to set up - it just >>worked. (It probably helps that JFLI was developed on LispWorks.) >> >>Although JFLI seems to be working and complete the focus of the >>developers has shifted towards FOIL which is supposed to replace JFLI: >> >> <http://foil.sourceforge.net/> > >I am the author of jFli and Foil. Both are viable, and Foil >represents less a replacement for jFli than a different set of >tradeoffs. > >jFli runs a JVM in-proc and accesses it via JNI. It is a fast and >easy way to do #1. However, being in-proc presents several >challenges, especially for GUIs. Thus, Foil, which runs the JVM in a >separate proc and communicates with it via sockets. This makes it >easier to do #2, and multi-threaded programming in general, although >some knowledge of Java is required if you want to create a custom JVM >'host' with particular threading/socket characteristics. There are >samples doing GUI with SWT - see the screenshots. > >Both jFli and Foil offer similar, but not identical, high-level >wrappers for Java classes/methods etc, transparent conversions and >memory management. Both were authored in LispWorks, and are open >source - feel free to fix/enhance... > >I'll let some non-author speak to the relative 'pain' of using jFli >or Foil. I'll try to answer this question as soon possible, au plus tard ce WE, en détail et en anglais! Sorry for the delay and the French words, I'm in a hurry now. Best regards to all, Francis >Rich > >
At 10/01/2006 19:03, Nick Levine wrote: >Can anyone give me an expected pain estimate for either of the >following: > >1) LispWorks invokes functionality writen in Java > >2) LispWorks integrates with a Java GUI I'have been using Foil for a few months to make Java GUIs with SWT (and LWw). See: http://www.eclipse.org/swt/ http://www.algo.be/cl/dialogue/index.htm http://www.algo.be/ref-projects.htm#kmed In this area I have some experience with CG (Common Graphics, ACL) and CLIM. I have found programming Foil/SWT quite similar to CG, SWT is a nice and mature package, still light comparing to Swing (maybe someone here has experience with both CAPI and CG and can tell how they compare in programming style). Comparing to CG (2002), SWT has more features, for example I have found SashForm widget to be easy and convenient (an SashForm has draggable splitters, to divide a pane). For example, there are 4 four nested SashForm widgets in this GUI (KMed application). http://algo.be/cl/labage/KMed/images/working-with-situations.jpg Adding 3 more SashForms into the main existing one and made them dynamic was a snap (its an optional view the user can choose). I didn't use CAPI to develop KMed because KMed is peripheral to an application where a requirement was a solid grapher library (JGo, http://www.nwoods.com/go/jgo.htm ) On the downside: Of course Foil/SWT is more difficult to install and start to work with than to use CAPI. You have to start the JVM, the Java Foil server, the Lisp Foil VM and extract the API from Java packages. However: o Once done, forget it. o I'm biased because I did not have any Java programming experience. BTW, my Java competence is still superficial, that's maybe a good point, you don't have to be a Java hacker to use Foil and SWT. My main complain is about debugging and maybe robustness. I have found the debugger almost useless in the context of Foil/SWT programming. The condition displayed is often unrelated to the real error. I don't spend time anymore in looking at the backtrace. I'm becoming a champion of the trace utility and the print statement! Finally, I have found a "mode de vie" thanks to a with-error macro which I tend to use everywhere: it handles errors, displays a dialog showing the condition and allows me to continue to test the GUI without having to restart everything (JVM, etc.) Finally, I think I can say Foil and SWT are a viable alternative to other solutions. I start to have encouraging feedback from KMed users (2 beta testers in fact). My productivity at GUI development is not that different from the one I had when I was programming with CG, even if some enhancements in Foil should improve it. Regards, Francis >Thanks, > >- nick