From: Andrei de A. F. <arc...@ya...> - 2004-06-18 15:36:07
|
Hello, I have finished a proof-of-concept lightweight Haskell parser written in Java. I'm currently preparing a testing apparatus to complement the simple unit tests. The interface of the parser is similar to core.halamo.parser.Parser/CompilationUnit, and I'd be glad to integrate it (after testing) if I know how. Should I create a new Parser subclass ? How about extending the current interface (more below) ? The lightweight parser extracts information about the module, all imports and all top-level declarations. It takes into account the layout rules if they are used, recognizing explicit punctuation instead if layout is not used. It doesn't know anything about binding declarations (that is, it can't separate between value and function bindings). I believe pattern bindings (using arbitrary patterns in the lhs) are not recognized, but I didn't test that yet. The parser doesn't know about types either; in the general case, the only way we could determine the types of entities in a module would be by having a complete type inference engine. So, this lightweight parser extracts more information than what is exposed by the current parser interfaces in the plugin. Can the current interfaces be changed, or should I stick to what's there ? Leif, I understand you may be away, so in the meantime I'll continue testing and experimenting. I've been reading about ANTLR and there are plans to try and build the fabled bridge. However, the types will be a problem. Maybe ghc can output only the type information... will look after that. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-06-20 11:38:08
|
Hi Andrei, > I have finished a proof-of-concept lightweight > Haskell parser written in Java. I'm currently > preparing a testing apparatus to complement the simple > unit tests. The interface of the parser is similar to > core.halamo.parser.Parser/CompilationUnit, and I'd be > glad to integrate it (after testing) if I know how. > Should I create a new Parser subclass ? How about > extending the current interface (more below) ? Great! > So, this lightweight parser extracts more > information than what is exposed by the current parser > interfaces in the plugin. Can the current interfaces > be changed, or should I stick to what's there ? Yes, we should change them. They were only for experimental purposes, and as long as we are still alpha, we should go and break the APIs ;-) These interfaces are used throughout the UI for code assist, outline view etc., so we should put into them everything we want to see in the UI. I suggest we extend them to everything your parser exposes. The interfaces are part of the Halamo API and will remain in that package (something of the internal stuff like the resource change stuff and the ProjectModelManager should go to 'internal' packages later). Your parser itself should be in the de.leiffrenzel.fp.haskell.core.parser plugin, should implement the interface IHaskellParser (from the core plugin) and then declare itself like this: <extension point="de.leiffrenzel.fp.haskell.core.haskellParsers"> <parser class="de.leiffrenzel.fp.haskell.core.parser.HalamoParser" name="Halamo Lightweight Parser"/> </extension> You will probably need to change the interface of IHaskellParser to fit your parser. That's fine, because this interface is not used anywhere (so far). Since all this breaks no existing code (apart from adding to interfaces), it should be possible to include it into the current development stream without problems. Could you send me the interfaces and the changed IHaskellParser interface? I'll integrate them and we can then set up an additional plugin project for the parser in the CVS. (I'll try to get the current sources into the CVS also, so that not everybody has to wait for the next release to get them. Just a matter of finding some free hour ;-) Thanks && ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-21 14:35:15
|
--- Leif Frenzel <hi...@le...> wrote: > Your parser itself should be in the > de.leiffrenzel.fp.haskell.core.parser > plugin, should implement the interface > IHaskellParser (from the core plugin) > and then declare itself like this: > > <extension > point="de.leiffrenzel.fp.haskell.core.haskellParsers"> > <parser > class="de.leiffrenzel.fp.haskell.core.parser.HalamoParser" > name="Halamo Lightweight Parser"/> > </extension> > > You will probably need to change the interface of > IHaskellParser to fit your > parser. That's fine, because this interface is not > used anywhere (so far). > > Since all this breaks no existing code (apart from > adding to interfaces), it > should be possible to include it into the current > development stream without > problems. Could you send me the interfaces and the > changed IHaskellParser > interface? Will do in the next few days. Testing is already under way, and going fine. One problem, though: the parser doesn't support literate haskell files. I think I can add support at least for bird-scripts quite easily. Another limitation: it only parses a module per file. This is no problem at all, as all current implementations require a 1 on 1 mapping between modules and files. I'll extend the current interfaces to expose the information the parser makes available, but should we think about a forward-looking interface (for when the full-blown parser is ready) or create only what's needed now, changing it later ? For the current parser, I would use the current IModule and IImport interfaces, and add a ITopDecl interface for top-level declarations, possibly creating derived, more specific interfaces like IDataDecl, ITypeDecl, and so on. The current interface has Module, Import and Declaration (TopDecl) only, using a type-safe enum for the declaration type. Any suggestions ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Andrei de A. F. <arc...@ya...> - 2004-06-21 18:08:06
|
I'm using the 0.3 version with eclipse 3.0RC3. Team support has improved with the automatic setting of .hs/.lhs files to ASCII, but there's still one small glitch that remained: when importing a module to CVS, I include bin and out directories in the .cvsignore, a standard practice. So far, so good. But when I check out the module from another workstation, these directories are not created, and ghc complains about them missing. I then go and create them manually. But with Java projects these directories are created automatically, even if they are in .cvsignore. It should be easy to fix that, I believe... --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-06-21 22:44:40
|
> I'm using the 0.3 version with eclipse 3.0RC3. Team > support has improved with the automatic setting of > .hs/.lhs files to ASCII, but there's still one small > glitch that remained: when importing a module to CVS, > I include bin and out directories in the .cvsignore, a > standard practice. So far, so good. But when I check > out the module from another workstation, these > directories are not created, and ghc complains about > them missing. I then go and create them manually. But > with Java projects these directories are created > automatically, even if they are in .cvsignore. It > should be easy to fix that, I believe... Right, I'll fix that. It' not directly in the Team plugins, I think the Java Builder checks these folders before starting (or the Java compiler is just clever enough to create them). I think I'll make the Haskell builder check that. Thanks && ciao, Leif > > --- > []s, Andrei de A. Formiga > > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
From: Andrei de A. F. <arc...@ya...> - 2004-06-22 19:06:15
|
Hi Leif, Can we use interfaces from halamo in the parser interface ? If so, I was thinking of the following interface for IHaskellParser: public interface IHaskellParser { IModule parseModule(InputStream moduleStream); } Then IModule would have all the information. The parser could be a singleton, if so desired. Is that ok, or do you think it's better to have these interfaces separated ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Leif F. <lfr...@in...> - 2004-06-22 22:30:26
|
Hi Andrei, > Can we use interfaces from halamo in the parser > interface ? Yupp, that is perfectly alright. >If so, I was thinking of the following > interface for IHaskellParser: > > public interface IHaskellParser { > IModule parseModule(InputStream moduleStream); > } > > Then IModule would have all the information. The > parser could be a singleton, if so desired. That would be difficult, because the parser has to be declared in the plugin.xml, and Eclipse creates an instance, which means it needs a public, parameterless constructor. I presume the parser has no state, so we can it cache in the resource change mechanism, which makes also sure that there is just one instance. Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-23 00:33:02
|
--- Leif Frenzel <lfr...@in...> wrote: > Hi Andrei, > > > The parser could be a singleton, if so desired. > That would be difficult, because the parser has to > be declared in the > plugin.xml, and Eclipse creates an instance, which > means it needs a public, > parameterless constructor. I presume the parser has > no state, so we can it > cache in the resource change mechanism, which makes > also sure that there is > just one instance. > Ok, no problem. The singleton part was just a thought. The parser doesn't need to keep state, so the cache would work fine. Let's get it working, then we can think about improvements. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-06-21 22:44:38
|
> I'll extend the current interfaces to expose the > information the parser makes available, but should we > think about a forward-looking interface (for when the > full-blown parser is ready) or create only what's > needed now, changing it later ? I think we should just expose what we have only (for the moment). For most things in the UI (code assist, outline) and the compiler (dependency tracking) we won't need the full-blown parser anyway. In JDT, the full-blown parser is invoked only on demand (when it comes to refactorings or structural search) on only some of the files, because it is too expensive in both space and time. (Btw: there is not too much documentation about the ideas behind the Java language model in JDT, but I once read one good summary of what I've come to think is the main point: http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg00653.html ) One question: does your parser collect information about the positions in the file (character offset) where the language elements are? We would need that for instance for the outline view (where you click on an element and the editor shows the corresponding code), probably in terms of document offset, i.e. the count of characters from the document start. >For the current > parser, I would use the current IModule and IImport > interfaces, and add a ITopDecl interface for top-level > declarations, possibly creating derived, more specific > interfaces like IDataDecl, ITypeDecl, and so on. The > current interface has Module, Import and Declaration > (TopDecl) only, using a type-safe enum for the > declaration type. Any suggestions ? Since language elements in the UI (e.g. in the Module Browser, Outline View ...) are usually displayed dependent on their type, that is, with an 'instanceof' check, I would plead for subinterfaces instead of enums. (Also, there is an aesthetical point in having a completely heterogeneous model: one type per language element, instead of a homogeneous/heterogeneous mix: using in some cases an attribute of nodes for what is in effect a subtype :-) Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-22 01:12:40
|
--- Leif Frenzel <hi...@le...> wrote: > I think we should just expose what we have only (for > the moment). For most > things in the UI (code assist, outline) and the > compiler (dependency > tracking) we won't need the full-blown parser > anyway. In JDT, the full-blown > parser is invoked only on demand (when it comes to > refactorings or > structural search) on only some of the files, > because it is too expensive in > both space and time. Yes, I thought so. I was thinking about having typing decorations on the entities in the Outline view, but that would require not only a full-blown parser, but a complete type inferencer as well. So the complete parser would not help much here. Still, it would probably be useful to differentiate between pattern bindings and function bindings, as well as recognizing variables in pattern bindings (the parser doesn't do that yet). I'll think about that later. > > (Btw: there is not too much documentation about the > ideas behind the Java > language model in JDT, but I once read one good > summary of what I've come to > think is the main point: I'll read that. > > One question: does your parser collect information > about the positions in > the file (character offset) where the language > elements are? We would need > that for instance for the outline view (where you > click on an element and > the editor shows the corresponding code), probably > in terms of document > offset, i.e. the count of characters from the > document start. Yes, the parser must maintain the current column for processing of layout, and then an offset count was added because I saw that in the parser interfaces. I suppose tab characters count as one char, right ? > Since language elements in the UI (e.g. in the > Module Browser, Outline View > ....) are usually displayed dependent on their type, > that is, with an > 'instanceof' check, I would plead for subinterfaces > instead of enums. Ok, will do that. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-06-22 22:41:42
|
> Yes, I thought so. I was thinking about having >typing decorations on the entities in the Outline >view, but that would require not only a full-blown >parser, but a complete type inferencer as well. So the >complete parser would not help much here. We could do it at least for explicit type declarations. (That would be also something that can be clicked on and located in the source.) > Yes, the parser must maintain the current column > for processing of layout, and then an offset count was > added because I saw that in the parser interfaces. I > suppose tab characters count as one char, right ? Jupp, one char. Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-23 00:45:16
|
--- Leif Frenzel <hi...@le...> wrote: > > We could do it at least for explicit type > declarations. (That would be also > something that can be clicked on and located in the > source.) > I think it wouldn't be hard to extend the parser to recognize type constructors. The lexer would grow a bit more, though. The lhs situation is more pressing... --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
From: Andrei de A. F. <arc...@ya...> - 2004-06-23 02:02:34
|
These are the proposed interface changes: - de.leiffrenzel.fp.haskell.core.parser public interface IHaskellParser { IModule parseModule(); } - de.leiffrenzel.fp.haskell.core.halamo public interface IModule extends IHaskellLanguageElement { IImport[] getImports(); IDeclaration[] getDeclarations(); ICompilationUnit getCompilationUnit(); } public interface IImport extends IHaskellLanguageElement { IModule getModule(); String getAlias(); } public interface IDeclaration extends IHaskellLanguageElement { IModule getModule(); } ---------------------------------------- Then we'll have (in the parser) concrete classes Import, Module and Declaration that implement the respective interfaces, and classes TypeDeclaration, DataDeclaration, NewTypeDeclaration, ClassDeclaration, InstanceDeclaration, DefaultDeclaration and TypeSignature that are Declaration subclasses. How about that ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-06-28 20:09:43
|
Hi Andrei, > These are the proposed interface changes: > > - de.leiffrenzel.fp.haskell.core.parser > > public interface IHaskellParser { > > IModule parseModule(); > } Should the parser not take an ICompilationUnit (or an IFile) to parse? The parser will be called whenever a file changes, so it will have to get its input from there. > Then we'll have (in the parser) concrete classes > Import, Module and Declaration that implement the > respective interfaces, and classes TypeDeclaration, > DataDeclaration, NewTypeDeclaration, ClassDeclaration, > InstanceDeclaration, DefaultDeclaration and > TypeSignature that are Declaration subclasses. > > How about that ? This looks fine for a start. One thing I don't see at the moment is how information from these subclasses can be accessed. We have only on dependency (from the parser plugin to the core), so we cannot cast in the core (or UI, for that matter) to these subclasses. I think from any of the declarations, we should have at least an identifier in the interface. Once the busy time with the distribution is over (see the news on the project page :-), that is, probably not before the weekend, I'll put your interface definition into the core plugin :-) Thanks && ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-06-29 00:01:57
|
--- Leif Frenzel <hi...@le...> wrote: > > > > - de.leiffrenzel.fp.haskell.core.parser > > > > public interface IHaskellParser { > > > > IModule parseModule(); > > } > Should the parser not take an ICompilationUnit (or > an IFile) to parse? The > parser will be called whenever a file changes, so it > will have to get its > input from there. Oh yes, I overlooked that. Whatever you feel is better, an ICompilationUnit or IFile should go as a parameter. > > How about that ? > This looks fine for a start. One thing I don't see > at the moment is how > information from these subclasses can be accessed. > We have only on > dependency (from the parser plugin to the core), so > we cannot cast in the > core (or UI, for that matter) to these subclasses. I > think from any of the > declarations, we should have at least an identifier > in the interface. Well, all subclasses implement IHaskellLanguageElement, so at least you get the name and offset for each element. As for the other information, I hadn't thought about that... a Visitor pattern, maybe ? > > Once the busy time with the distribution is over > (see the news on the > project page :-), that is, probably not before the > weekend, I'll put your > interface definition into the core plugin :-) The Yoxos bit is very good news :) > Thanks && ciao, > Leif --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-07-05 22:19:44
|
Hi Andrei, I started to intergrate your interfaces in the core plugin. The next step should be to connect to whatever parser is registered via the extension point. That shouldn't be too difficult :-) Did you make use of the classes in core.halamo.parser? I think they should be moved completely to the implementing plugin (that is, the parser plugin). > Well, all subclasses implement > IHaskellLanguageElement, so at least you get the name > and offset for each element. Of course (I really should start to learn reading ;-). >As for the other > information, I hadn't thought about that... a Visitor > pattern, maybe ? The visitor would still have to access the specialized information in some way, and we would need to cast then, which is not possible from any plugin which is not dependent on the parser plugin. Since all interfaces are defined in the core plugin, there should be no dependency whatsoever from any plugin to the parser plugin, but this means all information that is parsed out of the files would have to be in the interfaces. But I think we should postpone extending the interfaces for the moment and concentrate on integrating the parser so that we can at least see the dependencies in the dependency view and use them for calculating the compile order. Could you send me the code of the parser so I can have a look at it? If you want to contribute it to the project, I would like to add you to the developers list on sourceforge. (I think I need your sf username for that.) Presumably we could then exchange files more easily via the server (I must have a look at the facilities on sf for these things.) Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-07-06 00:46:50
|
--- Leif Frenzel <hi...@le...> wrote: > Hi Andrei, > > I started to intergrate your interfaces in the core > plugin. The next step > should be to connect to whatever parser is > registered via the extension > point. That shouldn't be too difficult :-) How will the core choose between parser plugins and guarantee there's at least one ? Just curious, as I said, I have very little previous experience with eclipse development. > > Did you make use of the classes in > core.halamo.parser? I think they should > be moved completely to the implementing plugin (that > is, the parser plugin). I intended to use the interface from haskell.core.parser, but nothing from core.halamo.parser. > The visitor would still have to access the > specialized information in some > way, and we would need to cast then, which is not > possible from any plugin > which is not dependent on the parser plugin. I see. > Since > all interfaces are > defined in the core plugin, there should be no > dependency whatsoever from > any plugin to the parser plugin, but this means all > information that is > parsed out of the files would have to be in the > interfaces. Yes, that would be fixed in the parser plugin interface. > > Could you send me the code of the parser so I can > have a look at it? If you > want to contribute it to the project, I would like > to add you to the > developers list on sourceforge. (I think I need your > sf username for that.) > Presumably we could then exchange files more easily > via the server (I must > have a look at the facilities on sf for these > things.) Well, the code as it is now is not exactly conforming to the interfaces I described, but changing it would be no great trouble. I can do it and send it to you, or we can do this in other ways. My username on sourceforge is ktulu. > > Ciao, > Leif --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Leif F. <lfr...@in...> - 2004-07-06 08:15:23
|
> How will the core choose between parser plugins and > guarantee there's at least one ? Just curious, as I > said, I have very little previous experience with > eclipse development. There is no guarantee that there is a parser, so there will be a fallback variant with a dummy parser that is used if no extension is found. It will do nothing, but it will ensure that no calls (e.g. from the UI) run into NPEs. A similar mechanism is, btw, at work with the Haskell compilers. There is no way to choose automatically between multiple parsers, if more than one is provided. That is, the core plugin, if it finds more than one parser, cannot find which one to use. There are two possible solutions: either let the user choose (via UI, that is on a preference page), which is the way the compiler is selected, or make it configurable. the latter means that we would introduce a further attribute to make one of the parsers 'primary'. The core plugin would then use the first primary parser it can find. That way, the responsibility for choosing the parser would be with the deployment process. I would prefer the latter way, so we could package several parsers into the feature and then can switch the parser without rebuilds (e.g. for testing or as fallback if on some machine the primary parser doesn't work). > I intended to use the interface from > haskell.core.parser, but nothing from > core.halamo.parser. Fine, that means they are history :-) |
From: Leif F. <lfr...@in...> - 2004-07-06 08:22:38
|
> Well, the code as it is now is not exactly > conforming to the interfaces I described, but changing > it would be no great trouble. I can do it and send it > to you, or we can do this in other ways. My username > on sourceforge is ktulu. Yupp, I would prefer to use sf for that, so everybody who does something gets the full credit. (But of course I would like to have a look at the code before including it ;-) Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-07-06 12:25:12
|
--- Leif Frenzel <lfr...@in...> wrote: > Yupp, I would prefer to use sf for that, so > everybody who does something > gets the full credit. (But of course I would like to > have a look at the code > before including it ;-) Sure. Can you send me the new interfaces as they are ? Then I'll change the classes to the right package, integrate the new interfaces, test it, and send it to you. > > Ciao, > Leif > --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Leif F. <lfr...@in...> - 2004-07-07 16:32:14
|
> Sure. Can you send me the new interfaces as they > are ? Then I'll change the classes to the right > package, integrate the new interfaces, test it, and > send it to you. I did just integrate what you proposed (no problem as long as you just add to the interfaces :-). The only different one was this: /** <p>specifies a parser for Haskell source files.</p> * * Note: this is an interim API for experimental purposes. Implementors are * declared via the de.leiffrenzel.fp.haskell.core.haskellParsers extension * point. * * @author Leif Frenzel */ public interface IHaskellParser { IModule parseModule( ICompilationUnit compilationUnit ); } Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-07-08 20:12:30
|
Hi Leif, Here is a zip file with the parser, conforming to the interfaces that were agreed upon: http://ktulu.freezope.org/projetos/lwhp.zip It passed unit testing, which is not very extensive. I'll be doing more tests in the next days, but here you have it to begin integrating. If it chokes with some input, you can send me the offending files and I'll include it in my testing system. Some observations: 1) Error handling: I put only a generic exception handler (that calls printStackTrace) in the parseModule method, because I didn't know how to handle the error. We can change this later. 2) I didn't put the code in a plugin project, didn't create the plugin, declare extension point, etc. 3) There are test classes in the test directory, which are unit tests and a dumper that I use in my test system. I believe they shouldn't be included in the plugin (well, maybe the unit tests). That's it. I hope it works :) --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-07-08 22:21:58
|
Hi Andrei, > Here is a zip file with the parser, conforming to > the interfaces that were agreed upon: > > http://ktulu.freezope.org/projetos/lwhp.zip Great! I'll look into it this weekend and integrate it :-) > 2) I didn't put the code in a plugin project, > didn't create the plugin, declare extension point, > etc. No big deal; I'll do that and make the plugin available for you and others. > 3) There are test classes in the test directory, > which are unit tests and a dumper that I use in my > test system. I believe they shouldn't be included in > the plugin (well, maybe the unit tests). I usually put my unit tests into a separate plugin (so for de.leiffrenzel.fp.haskell.ui there is an additional plugin de.leiffrenzel.fp.haskell.ui.test that is not included in the release, but is developed in the same workspace). The tests are in a plugin because some of them are PDE JUnit tests. PDE JUnit is a special extension of JUnit for Eclipse development that runs the tests inside a Runtime-workbench, so that you have access to the workspace, IFiles etc. In the Eclipse 2.1 aera, PDE JUnit was a separate add-on, but in Eclipse 3.0 it is included in the standard. Unfortunately, since Eclipse 3.0 M6 or so the PDE JUnit tests that I had created did no longer work. That was because of the new feature in Eclipse 3.0 that lets you run builds and other time-consuming stuff in the background. The time behaviour in the new Eclipse is grossly different than that in Eclipse 2.1, and most of my tests could not cope with that. So I could no longer use them, most of them cause exceptions in totally unexpected places. I'll have to fix that at some time in the future, of course ... Ciao, Leif |
From: Andrei de A. F. <arc...@ya...> - 2004-07-10 21:49:43
|
Hi Leif, I will be using linux much more often now, and so I installed eclipse and the plugin. Then ghc complained with the known error (reported in the forums): ghc-6.2.1: can't apply -o to multiple source files Usage: For basic information, try the `--help' option. I tracked down the problem here. In the GhcCompiler.buildCommandLine method, there is this block of code: cmdLine.add( getCompilerExecutable() ); cmdLine.add( "--make" ); cmdLine.add( constructLibPath( haskellProject ) ); but then, constructLibPath returns an empty string. When this empty string is included in the array returned by GhcCompiler.buildCommandLine, ghc thinks there are more than one source file in the command line, and complains. I've commented this line and the error was gone. However, in the linking phase it complained about not being able to find 'ld'. So I looked into AbstractCompiler.createProcess. This is the call to exec at the end of the method: return Runtime.getRuntime().exec( cmdLine, new String[ 0 ], workDir ); which calls ghc with an empty environment, so it was not able to find ld. I changed the second parameter to null (inherit the environment from parent process) and everything worked. So, I guess this solves the problem. Maybe adding a check to see if constructLibPath returns an empty string and then only adding to cmdLine if it's not... well, it's your call :) --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
From: Leif F. <hi...@le...> - 2004-07-12 22:46:44
|
Hi Andrei, yupp, I would say that's exactly it. Thanks for this fix :-) I have integrated it and I'm now halfway through with integrating your parser, too, so I would suggest to envisage a next release in the next few days. Ciao, Leif ----- Original Message ----- From: "Andrei de A. Formiga" <arc...@ya...> To: <ecl...@li...> Sent: Saturday, July 10, 2004 11:49 PM Subject: [eclipsefp-develop] Linux/unix bug > > Hi Leif, > > I will be using linux much more often now, and so I > installed eclipse and the plugin. Then ghc complained > with the known error (reported in the forums): > > ghc-6.2.1: can't apply -o to multiple source files > Usage: For basic information, try the `--help' option. > > I tracked down the problem here. In the > GhcCompiler.buildCommandLine method, there is this > block of code: > > cmdLine.add( getCompilerExecutable() ); > cmdLine.add( "--make" ); > cmdLine.add( constructLibPath( haskellProject ) ); > > but then, constructLibPath returns an empty string. > When this empty string is included in the array > returned by GhcCompiler.buildCommandLine, ghc thinks > there are more than one source file in the command > line, and complains. I've commented this line and the > error was gone. > However, in the linking phase it complained about > not being able to find 'ld'. So I looked into > AbstractCompiler.createProcess. This is the call to > exec at the end of the method: > > return Runtime.getRuntime().exec( cmdLine, new String[ > 0 ], workDir ); > > which calls ghc with an empty environment, so it > was not able to find ld. I changed the second > parameter to null (inherit the environment from parent > process) and everything worked. > > So, I guess this solves the problem. Maybe adding a > check to see if constructLibPath returns an empty > string and then only adding to cmdLine if it's not... > well, it's your call :) > > --- > []s, Andrei de A. Formiga > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail is new and improved - Check it out! > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |