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 ? > > > > * 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. > > > > > > 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. > > > > ==> 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 -~----------~----~----~----~------~----~------~--~---
