2009/1/26 Laurent PETIT <laurent.pe...@gmail.com> > 2009/1/26 gaetan <gaetan.mor...@gmail.com> > >> On 26 jan, 13:29, Laurent PETIT <laurent.pe...@gmail.com> wrote: >> > Hello Gaetan, >> > >> > Thanks for the shared code. I think that for a first version in >> clojuredev, >> > I'll too just implement the full builder, and wait for performance >> problems >> > before writing an incremental one (thus saving development time for >> adding >> > other functionalities right now). >> > >> > BUT I think I'll not follow the example in one place. I'd like to hear >> what >> > you think about my arguments, though: >> > >> > I'll not use the clojure environment of the plugin to compile files. For >> at >> > least two reasons : >> > * if there is malicious or problematic code in the compiled files, I >> don't >> > want the eclipse environment to hang, or to crash. >> >> You are right, it may rise some problems as the compiled code is >> loaded in the clojure runtime (I don't think that you have to bother >> about malicious code). It would be nice in that case to be able to >> unload code after compilation, I don't think that the current runtime >> enable that. However it could be very useful to have the code loaded, >> in order to perform syntactic analysis, re-factoring and other >> operations. > > > I have seen functions to remove symbols from a ns (and probably also > functions to remove ns, I presume). > So by making a snapshot of the tree of ns>symbols before and after the > compilation, it should certainly be possible to know what was created, and > remove it at will ? >
Yes that's true. > > > >> >> >> > * to decouple the version of clojure needed by the plugin own needs >> (for >> > the parts of the plugin written in clojure), from the version of clojure >> the >> > user wants to use : I'll use the version of clojure the user wants. >> >> That's true too. As Werner Schuster told me, it seems very difficult >> to run two different versions of the clojure runtime in the same >> process. > > > Yes, currently clojure bootstraps some things in static initializers, thus > somewhat embracing the whole jvm for one instance. > Maybe some specific applications can do something by very quickly (before > the RT class is loaded) segregating things via different classloaders, but > I'm not sure this is possible in an eclipse OSGI managed environment. > I just talk of this problem with a colleague of mines. And he told me that theoretically its feasible in OSGi but that it may be very tricky in the OSGi runtime of Eclipse. > > >> >> > >> > But this will lead to another problem : we can't, for performance reason >> I >> > fear, start a new JVM each time we want to compile a new file ! So there >> > will be the need to share an instance at the project level, and be sure >> this >> > instance is still alive (and in good conditions ...) >> >> Maybe it is the best solution : using a specific JVM for a set of >> project that work together and have a repl plug on it. However it may >> rise a problem in the interaction with JDT. >> Indeed, if you compile your code with gen-class to use it directly in >> java, JDT needs the generated *.class file, otherwise the project >> won't compile corectly. > > > I'done some tests for this : I already have managed to enable compilation > for end users of clojuredev. And this involves to be able to make the > compiled classes available to the other java classes the user made. > > The solution I came with is to create a specific folder in the user > project. I name it "classes" to remain standard with the defaults for > Clojure compilation. It is added as a class folder to the classpath of the > user project (via Java build path > Libraries > New class folder). > And then it works just fine (just had to remember to refresh the "classes" > folder after compilation, and the end user has his compiled clojure classes > visible from his java classes). > => Not yet commited in svn, though. > It seems to be a good solution. The last thing is to manage project dependencies if needed. > > > >> > >> > ==> Do you know how the JDT does for incremental compilation of java >> files >> > (sensible when eclipse is running with JDK 6, but the project depends on >> > e.g. JDK 1.4.2) ? >> >> In fact JDT does not use the JDK to compile code : it embeds its own >> compiler. So, I assume it can compile code for all Java versions >> regardless the JDK on which it runs. > > > Ah, OK. > > >> >> >> > >> > Regards, >> > >> > -- >> > Laurent >> > >> > 2009/1/26 gaetan <gaetan.mor...@gmail.com> >> > >> > >> > >> > > On 23 jan, 20:57, Laurent PETIT <laurent.pe...@gmail.com> wrote: >> > > > OK, I understand better now, I think. >> > >> > > > Did you experience the problems you have exposed ? Or is it an >> > > anticipation >> > > > of problems ? >> > >> > > Yes I directly experience the problem when I first implement a Clojure >> > > REPL inside Eclipse and do not have access to some resources of other >> > > plugins. >> > >> > > The best way to reproduce the problem is to implement the use case I >> > > described : two plugins with dependencies. >> > >> > > > If so, can you expose the tests data, so that one can also >> experiment >> > > with >> > > > them ? >> > >> > > I can provide a simple example with a hello world action. >> > >> > > > 2009/1/23 Gaetan Morice <gaetan.mor...@gmail.com> >> > >> > > > > Hello Laurent, >> > > > > thank you for your interest. >> > >> > > > > 2009/1/23 Laurent PETIT <laurent.pe...@gmail.com> >> > >> > > > >> Hello Gaetan, >> > >> > > > >> I'm one of the core developers of clojuredev, an open source >> project >> > > whose >> > > > >> goal is to provide clojure support for the Eclipse IDE. >> > > > >> What you say below is interesting, please see what I have noted >> inline >> > > --> >> > >> > > > >> 2009/1/23 gaetan <gaetan.mor...@gmail.com> >> > >> > > > >>> Hi everybody, >> > >> > > > >>> I am working in a software company specialized in Eclipse based >> > > > >>> product development (and member of the Eclipse Fundation). We >> are >> > > very >> > > > >>> interesting in clojure features and we plan to use it in some of >> our >> > > > >>> products. I am currently working on clojure integration in OSGi >> > > > >>> Bundles in order to embed code in Eclipse plugins. As mentioned >> in >> > > > >>> some posts the biggest problems is class loading. Indeed in OSGi >> each >> > > > >>> bundle has its own class loader and class loading is not based >> on the >> > > > >>> application classpath or on the current thread class loader. >> > > > >>> Consequently, it is very difficult to make clojure work with >> java >> > > code >> > > > >>> and to use OSGi visibility and dependencies system inside >> clojure. >> > >> > > > >> For mere mortals like me, could you explain the problem via an >> example >> > > ? >> > > > >> (I understand there is a problem, I don't exactly understand what >> it >> > > > >> really is) >> > >> > > > >> Concerning clojuredev, we provide clojure as a separate plugin, >> which >> > > > >> exposes everything to plugins that depend on it. >> > > > >> Currently, clojuredev plugin is successful in calling clojure >> core >> > > > >> functions defined in clojure plugin, as well as loading new >> functions >> > > and >> > > > >> namespaces from clojuredev plugin. >> > >> > > > > I will try to give an example (I hope it will be understandable). >> > > > > First has you may now in OSGi (and therefor in Eclipse) each >> bundle >> > > declare >> > > > > its dependencies toward others in the MANIFEST.MF file. If you >> > > > > are developing a bundle "a" that needs a class in a bundle "b" you >> have >> > > to >> > > > > update the MANIFEST.MF file of "a" to said that it depends on "b" >> and >> > > "b" >> > > > > has to export the package that contains the class (this >> information is >> > > in >> > > > > the MANIFEST.MF file of b). Under the hood, each bundle has its >> own >> > > class >> > > > > loader that is fully aware of the dependencies and export of the >> > > plugin. So >> > > > > in the example above, at runtime the class loader of "a" will be >> able >> > > to use >> > > > > the class loader of "b" (thanks to the dependency declaration) and >> this >> > > one >> > > > > will be able to load the class for an external bundle (thanks to >> the >> > > export >> > > > > declaration). Now if you want to use clojure code in your OSGi >> instead >> > > of >> > > > > java. First you will embed clojure core in a specific bundle >> called >> > > "c". You >> > > > > write a clojure lib in "a" that use another clojure lib in "b". >> What >> > > > > will happen? To load code of "b" the lib in "a" will use the "use" >> (or >> > > > > "require") function of clojure core. This function use a specific >> class >> > > > > loader (called DynamicClassLoader) that use the class path of >> > > > > the bootstrapping thread. However this class path is not aware of >> the >> > > > > bundles inside the application and so the clojure class loader >> will not >> > > be >> > > > > able to find the lib in "b". Another case is if you want to use >> clojure >> > > code >> > > > > in "a" that use java code in "b". In this case clojure code use >> the >> > > "import" >> > > > > function of clojure core. This function use the Class#forName >> method >> > > that is >> > > > > based on the caller class loader. In this case the caller is >> clojure >> > > core >> > > > > and so its class loader is the class loader of "c". As this class >> > > loader as >> > > > > no dependencies toward "b", it will not be able to load the java >> class. >> > > > > As you can see the problem is a little tricky :-). That's why I >> think >> > > the >> > > > > best way to use clojure in OSGi bundles is to enable clojure to >> use >> > > bundles' >> > > > > class loader, it is flawless and understandable as it mimics java >> > > behavior. >> > > > > To do this I use clojure namespaces. In the example above the >> clojure >> > > lib in >> > > > > "a" must have a namespace that start with "a" so the clojure class >> > > loader >> > > > > can find and use the class loader of bundle "a" to load its >> > > dependencies. >> > >> > > > Thanks, I now see what you mean. >> > >> > > > >>> I >> > > > >>> think the best solution is to use bundles class loader inside >> clojure >> > > > >>> class loading system. I developed a proof of concept that uses a >> new >> > > > >>> class loader that extends clojure.lang.DynamicClassLoader with >> > > bundle >> > > > >>> class loading capability. To know which bundle use to load >> classes or >> > > > >>> script file the class loader uses the current namespace which >> has to >> > > > >>> reflect the bundle name (this is the java convention for >> bundles). In >> > > > >>> order to use this new class loader I had to modified >> > > > >>> clojure.lang.RT#baseLoader and makeClassLoader and >> > > > >>> clojure.lang.core#import. Moreover to test this I made a >> experimental >> > > > >>> Eclipse Builder that enable AOT compilation of mixed clojure and >> java >> > > > >>> plugin. So far it seems to work well: clojure and java interact >> > > > >>> seamlessly and it is very fun to interact dynamically with an >> Eclipse >> > > > >>> instance! >> > >> > > > >>> I had some questions to the clojure community: >> > > > >>> * Whether it is possible to overload clojure class loading >> without >> > > > >>> introducing dependencies in clojure's core? >> > > > >>> * If their are some people interested in this application of >> > > clojure? >> > > > >>> (I can made my sources available) >> > >> > > > >> We currently don't have made the AOT version of the eclipse >> builder, >> > > so if >> > > > >> you could publish what you've done so far that would be great, >> because >> > > we >> > > > >> could work on it, or it could give us some hints to make our own. >> > >> > > > >> Is it possible for you to publish it, maybe via the EPL, which >> seems >> > > to be >> > > > >> the 'defacto' Open source license to use when creating code >> around >> > > clojure ? >> > >> > > > > No problem I will release the code under EPL. However you must be >> aware >> > > > > that it is a proof of concept and there is a lot of things to fix >> and >> > > > > re-factor. I just have one question what is the best place to >> share the >> > > code >> > > > > ? >> > >> > > > I don't have the rights to make you a commiter of clojuredev (not >> the >> > > > project owner), so I don't know ... maybe you could just place your >> > > > copyright + EPL on your files, and attach it to issue 3 in >> clojure-dev >> > > > bugtracker ? ( >> http://code.google.com/p/clojure-dev/issues/detail?id=3) >> > >> > > I attach my builder and visitor to the issue 3 of clojure-dev (tp:// >> > > code.google.com/p/clojure-dev/issues/detail?id=3). >> > >> > > > Thanks in advance, >> > >> > > > -- >> > > > Laurent >> > >> > > > >> Regards, >> > >> > > > >> -- >> > > > >> Laurent >> > >> > > > >>> Moreover I will made a post on Eclipse E4 project mailing list >> (work >> > > > >>> on the future of Eclipse) as they are very interested in dynamic >> > > > >>> languages. >> > >> > > > >>> BR, >> > >> > > > >>> Gaetan >> > >> > > > >> Cheers, >> > > > > Gaetan >> > >> > > > -- >> > > > Cordialement, >> > >> > > > Laurent PETIT >> > >> > > Gaetan >> >> > > > -- > Cordialement, > > Laurent PETIT > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
