From: Andrei de A. F. <arc...@ya...> - 2004-05-31 15:04:07
|
I just started using the eclipsefp plugin in eclipse 3M8. I use eclipse at work and was delighted to see a haskell plugin. It seems very good and polished right now, congratulations. I do java at work and decided to join this mail list to see if I can help with development. Read about the java<->haskell bridges issues in the archives (which go up to may 27th) and maybe I could help there. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Leif F. <hi...@le...> - 2004-06-04 23:39:34
|
Hi Andrei, thanks for your mail and sorry for the long delay in answering :-( I was on a business trip the last four days and could not answer all my mail. Sadly, this will be the same in the week from June 14th, so sorry in advance if I'll be (almost) unreachable in that time again. (But it''s related to Eclipse, so it is at least for a god purpose :-) > I just started using the eclipsefp plugin in > eclipse 3M8. I use eclipse at work and was delighted > to see a haskell plugin. It seems very good and > polished right now, congratulations. Thanks :-) We're just starting, though, many things are still somewhat shaky :-) > I do java at work and decided to join this mail > list to see if I can help with development. Read about > the java<->haskell bridges issues in the archives > (which go up to may 27th) and maybe I could help > there. That would be great. As I said, for me is this at the B-priority level for the moment, but for a start we could proceed as follows: I have (already in 0.2) started to create some of the core functionalities that notify the language model. (You find language-model related stuff in the haskell.core plugin in the 'halamo'-packages.) I will put an extension point for a Haskell parser in the haskell.core plugin, which can be then extended from a new plugin (haskell.core.parser). That new plugin can then contain the parser (native), bridge, and implementation for the extension. I think we should put this in a separate plugin primarily because we will have to divide it up into at least two (win32, linux) fragments with the respective native code in them (that is the usual way the Eclipse project handles platform dependent components). With an extension point, we can later easily add Haskell -> Java bytecode compiled parsers (or possibly an ANTLR-generated parser). It has the additional advantage that we can leave it out of the stable builds if it makes problems (native code - it's bound to do that ;-) Once the extension-point is in place, we should start trying to set up a working bridge. Hope that makes sense, Ciao, Leif > > --- > []s, Andrei de A. Formiga > > > > > __________________________________ > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger. > http://messenger.yahoo.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
From: Andrei de A. F. <arc...@ya...> - 2004-06-06 19:54:46
|
--- Leif Frenzel <hi...@le...> wrote: > I think we should put this in a separate plugin > primarily because we will > have to divide it up into at least two (win32, > linux) fragments with the > respective native code in them (that is the usual > way the Eclipse project > handles platform dependent components). With an > extension point, we can > later easily add Haskell -> Java bytecode compiled > parsers (or possibly an > ANTLR-generated parser). It has the additional > advantage that we can leave > it out of the stable builds if it makes problems > (native code - it's bound > to do that ;-) Yes, I believe separating the parser as a plugin is a good idea. > > Once the extension-point is in place, we should > start trying to set up a > working bridge. > > Hope that makes sense, > Ciao, > Leif I think I got the gist of it. I can't find the sources anywhere, I believe they must be available, the plugin being licensed by the CPL. Is it available somewhere ? Again about the java bridge, I contacted the author of Jaskell, but unfortunately it is not maintained anymore AND the sources are not available. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Leif F. <lfr...@in...> - 2004-06-06 22:29:44
|
> I can't find the sources anywhere, I believe they > must be available, the plugin being licensed by the > CPL. Is it available somewhere ? Yes, the sources are in the downloadable version, but packaged in separate plugins. That is a practice not supported by the export wizards in the PDE (and that has caused me some trouble during deplyoment ...), but it is the way Eclipse itself organizes its sources, and it has the advantage to make it easier to separate bin and source versions (once the package grows). You find the sources in the plugins with 'source' in their names. If you just import the plugins into the workspace, you should be able to browse the code. For changing it, you'll have to import them as 'plugins with source folders'. Eclipse maps the sources automatically (at least did so when I tested it here :-). I'm at the moment struggling with the 3.0RC1 Export wizard and I am also reworking my setup for the eclipsefp development at home. Once I get that sorted out, I will post the sources also to the CVS on sourceforge. Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-07 12:27:55
|
--- Leif Frenzel <lfr...@in...> wrote: > Yes, the sources are in the downloadable version, > but packaged in separate > plugins. That is a practice not supported by the > export wizards in the PDE > (and that has caused me some trouble during > deplyoment ...), but it is the > way Eclipse itself organizes its sources, and it has > the advantage to make > it easier to separate bin and source versions (once > the package grows). You > find the sources in the plugins with 'source' in > their names. Dumb me, didn't look there... > > I'm at the moment struggling with the 3.0RC1 Export > wizard and I am also > reworking my setup for the eclipsefp development at > home. Once I get that > sorted out, I will post the sources also to the CVS > on sourceforge. I use the integrated CVS client in eclipse which imports the whole project as a module, and I can checkout directly as a project in another eclipse instance. Anyway, if you need any help with the plugins, I have limited experience with eclipse plugin development, but I'm willing to help and learn as needed. I'd like very much to have good plugins for Haskell and OCaml... Scheme wouldn't hurt either :) --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Leif F. <lfr...@in...> - 2004-06-07 12:56:49
|
> Anyway, if you need any help with the plugins, I > have limited experience with eclipse plugin > development, but I'm willing to help and learn as > needed. I'd like very much to have good plugins for > Haskell and OCaml... Scheme wouldn't hurt either :) Exactly those three were on my plan from the start :-) But there is no way to get an IDE from scratch for a real language without much effort :-( I have separated the language-neutral parts from the Haskell-specific parts, so it would be in principle possible to build an IDE for othe lanugages on top of the common.* plugins, but it is still much work. But I have decided to concentrate on Haskell for the next time. Maybe later on we can extend :-) My own background in Java ist mostly UI, and I have done Eclipse development for more than a year now in my daytime job. But in the core parts (that is, with the parser, compiler interfacing, dependency computing and so on), I am not that firm. If we can complement each other here, that would be fine. Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-07 13:20:10
|
--- Leif Frenzel <lfr...@in...> wrote: > Exactly those three were on my plan from the start > :-) But there is no way > to get an IDE from scratch for a real language > without much effort :-( I > have separated the language-neutral parts from the > Haskell-specific parts, > so it would be in principle possible to build an IDE > for othe lanugages on > top of the common.* plugins, but it is still much > work. But I have decided > to concentrate on Haskell for the next time. Maybe > later on we can extend > :-) Yes, trying to develop all 3 plugins at once would be crazy :) Having Haskell for now is already very good. > > My own background in Java ist mostly UI, and I have > done Eclipse development > for more than a year now in my daytime job. But in > the core parts (that is, > with the parser, compiler interfacing, dependency > computing and so on), I am > not that firm. If we can complement each other here, > that would be fine. I wouldn't say I have much experience there, either, at least not with haskell tools (being relatively new to haskell, but not to functional programming). But I can concentrate on that and look for help when needed. > > Ciao, > Leif > --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Andrei de A. F. <arc...@ya...> - 2004-06-08 19:49:17
|
So I started looking around. The plugin always compiles with the --make option, which has some problems: 1) it's slow. Most of the time it's compiling just one module. Also, as the module being saved was the only one changed, chasing dependencies from it is mostly wasted time (not with recursive modules, though). 2) with --make, ghc chases dependency from the module, but does nothing about modules that depend on the current module. The most obvious effect is that, when compiling a module that is not Main, the executable is not remade. One must make an artificial change to the Main module so a new executable is generated. I'm sure you are aware of this, and there are some options to correct it. Are there any plans already on how will be this done ? If I can help with something, let me know. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Leif F. <hi...@le...> - 2004-06-08 21:58:19
|
> I'm sure you are aware of this, and there are some > options to correct it. Are there any plans already on > how will be this done ? If I can help with something, > let me know. Yupp. This problem will be solved once we have the language model in place (in a way, almost everything that is only a little bit advanced in Eclipse is in fact dependent on such a model :-) The idea is with an object model that 'knows everything about the modules' in the project, we know of course also which depends on which. We can then on every autobuild collect the information what has to be rebuild and let ghc compile in batch-mode accordingly. But to feed that information into the language model, we need to parse the files and collect the import information. So we're back again. Hm, I'll let you into a little secret: I have already experimented with that import dependency stuff, and you find some of the code in the 0.2 release (although commented out). My problem was the parser. I had some very simple (handwritten) parser that read out import statements. I even created a dependencies view similar to the plugin dependency view in the PDE. But again, that was the part where I got stuck (because I've not managed so far a decent parser integration). So this is indeed a good point to testdrive our native parser via a bridge. It would return, say, the module name and a list of imported modules. We could do then do both things: populate the Dependency View (not so important, but probably helpful for testing) and compute the set of files to re-compile and the compile order. I am just at the moment wrapping up the 0.3 package and I'll upload it at the weekend. It has support for compiler options and works with Eclipse 3.0 M9 /RC1 (and probably with RC2, which is to be released on Friday). I put also in the haskell.core plugin a new extension point 'de.leiffrenzel.fp.haskell.core.haskellParsers' and an interface de.leiffrenzel.fp.haskell.core.parser.IHaskellParser: public interface IHaskellParser { String getModuleName(); String getImportedModules(); } Let's say we add another plugin 'de.leiffrenzel.fp.haskell.core.parser' with platform specific fragments. In the fragment.xml we declare the parser and implement the interface in a class that talks to Haskell via the bridge. Well, that was the easy part; but which bridge? Have you found a usable scheme? To me, Lambada looked not bad, but I didn't actually try it (only read the paper). Ciao, Leif |
From: Leif F. <hi...@le...> - 2004-06-08 22:05:10
|
> public interface IHaskellParser { > String getModuleName(); > String getImportedModules(); > } I meant String[] getImportedModules() of course. Sorry! Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-09 02:02:44
|
--- Leif Frenzel <hi...@le...> wrote: > Well, that was the easy part; but which bridge? Have > you found a usable > scheme? To me, Lambada looked not bad, but I didn't > actually try it (only > read the paper). It seems we're out of luck here. Lambada is mostly a research project, AFAIK, and it makes some sense to be so, its authors being from MS Research. Sigbjorn Finne worked on a .NET-Haskell bridge, actually, some time after the publication of the Lambada paper. And I couldn't find the code anywhere, just the paper and references to it. I found GCJNI (http://www.haskell.org/gcjni/) but it's only for Haskell code calling to Java, not the other way around. I have also found this: http://sourceforge.net/projects/jvm-bridge/ but, again, it's only a way to call Java code from a Java program. Searching google and the communities & activities reports didn't reveal anything else. So, it seems there's nothing out there, and our only choice is to implement the bridge. I will look into this further and see where the difficulties lie. > > Ciao, > Leif --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
From: Leif F. <hi...@le...> - 2004-06-11 08:14:30
|
Andrei, > It seems we're out of luck here. Lambada is mostly > a research project, AFAIK, and it makes some sense to > be so, its authors being from MS Research. Sigbjorn > Finne worked on a .NET-Haskell bridge, actually, some > time after the publication of the Lambada paper. And I > couldn't find the code anywhere, just the paper and > references to it. I did download the lambada code (just have to dig into my backup CDs ;-), so I can email it to you (and to anybody else who is interested). I think it didn't run out of the box, at least not for me. Nonetheless it is probably worth a look or two. Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-11 12:52:09
|
--- Leif Frenzel <hi...@le...> wrote: > Andrei, > I did download the lambada code (just have to dig > into my backup CDs ;-), so > I can email it to you (and to anybody else who is > interested). I think it > didn't run out of the box, at least not for me. > Nonetheless it is probably > worth a look or two. Yes, that would be good. I wonder what's the license that covers this code. > > Ciao, > Leif --- []s, Andrei Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |