From: Thiago A. <thi...@gm...> - 2005-11-19 20:22:20
|
Fellows, I don't know how many of you are following my efforts on the JParser, but I have made available right now a bunch of patches that can be called a developer preview. Although the parser isn't really fully functional (it only parses modules, nothing inside), at least the main pieces are glued together and I would like to get some feedback here (and on future patches). In order to see the code running, you will need Eclipse 3.1 at least (I have tested also with 3.2M2) running on a 1.5 JVM. Once you are sure you have the needed environment, follow these instructions: 1. Get the source code from the repo with 'darcs get http://eclipsefp.sf.net/repos/branches/jparser' (if you already have a previous repository version, you can just darcs pull) 2. Inside Eclipse, import the downloaded projects with File > Import... > Existing Projects into Workspace 3. Close the net.sf.eclipsefp.haskell.core.parser.win32 (this may lead to an annoying error if you are not on win32) 4. Run a full build by sayin' Project > Clean... > Clean all projects 5. On some occasions (I couldn't figure out which ones yet) the net.eclipsefp.haskell.core.jparser plugin doesn't build correctly, refresh the project to workaround this 6. Finally, run a new eclipse application with Run > Run... > Eclipse Application/eclipsefp.haskell-jparser.linux There you go, try creating a new module. You will see that it the outline now shows the module name (even without win32). The current parser isn't able to read the function names inside the module, but will soon. I have tested it on some Linux boxes, but it should work gracefully on every platform, since the code is pure Java. Some sidenotes: - Step number 5 is really annoying, does anyone have some way to get around this? - You will notice that the launch configuration has a .linux suffix. This is due to the fact that there are some linux specific plugins selected on it. If anyone can test if it also works on windows, we can wipe that suffix out. If it doesn't we need to create a windows-specific launch (with a .win32 suffix). Take care, Thiago Arrais |
From: Leif F. <lfr...@in...> - 2005-11-20 14:03:27
|
Hi Thiago, > I don't know how many of you are following my efforts on the JParser, > but I have made available right now a bunch of patches that can be > called a developer preview. Although the parser isn't really fully > functional (it only parses modules, nothing inside), at least the main > pieces are glued together and I would like to get some feedback here > (and on future patches). Cool :-) I have just pulled and built from your descriptions :-) Here's a few suggestions: The classpath of plugin projects should always be managed by PDE alone, i.e. via the plugin dependencies and runtime libs declared in the Manifest.mf. In the net.eclipsefp.antlr plugin, it looks as if the library was not correctly recognized by PDE, so I did right-click project > PDE tools > Update classpath. Patch appended. (Possibly in your repo it was still on the classpath from a former implementation stage :-). > - Step number 5 is really annoying, does anyone have some way to get > around this? This is most probably because antlr creates new resources from outside an Eclipse process. You can force a refresh after the antlr run: right-click project > Properties > Builders > Antlr > Edit > Refresh > Refresh Resources upon completion > The project containing the selected resources (patch appended :-) > > In order to see the code running, you will need Eclipse 3.1 at least > (I have tested also with 3.2M2) running on a 1.5 JVM. Once you are > sure you have the needed environment, follow these instructions: I'm running on Eclipse 3.2M3 and Java 5, and it works fine. Btw, I think we should consider to move to Java 5 in the development stream. I'm not sure for how many users this is an issue, though, so I'd better ask on the mailing list. > - You will notice that the launch configuration has a .linux suffix. > This is due to the fact that there are some linux specific plugins > selected on it. If anyone can test if it also works on windows, we can > wipe that suffix out. If it doesn't we need to create a > windows-specific launch (with a .win32 suffix). It did not work directly for me, because on Eclipse 3.2M3 there are some new plugins, which were initially missing, so I pressed 'Add required plugins' and that did the trick. This was of course not because of windows, but my adding the required plugins will have wiped out all possible differences between Win and Linux, so I don't know :-) Anyway, this looks good to me. I'm looking forward to seeing it handle imports and top-level decls :-) Ironically, this will make us independent from platform-specific compiled Haskell code once again, just at the time when I am devising a means to implement plugin code in Haskell :-) Thanks again && ciao, Leif > > Take care, > > Thiago Arrais > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id845&opÌk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > |
From: Leif F. <lfr...@in...> - 2005-11-20 14:06:39
Attachments:
patchbundle.zip.txt
|
> > I don't know how many of you are following my efforts on the JParser, > > but I have made available right now a bunch of patches that can be > > called a developer preview. Although the parser isn't really fully > > functional (it only parses modules, nothing inside), at least the main > > pieces are glued together and I would like to get some feedback here > > (and on future patches). > Cool :-) I have just pulled and built from your descriptions :-) Here's > a few suggestions: > > The classpath of plugin projects should always be managed by PDE alone, > i.e. via the plugin dependencies and runtime libs declared in the > Manifest.mf. In the net.eclipsefp.antlr plugin, it looks as if the > library was not correctly recognized by PDE, so I did right-click > project > PDE tools > Update classpath. Patch appended. (Possibly in > your repo it was still on the classpath from a former implementation > stage :-). > > > - Step number 5 is really annoying, does anyone have some way to get > > around this? > This is most probably because antlr creates new resources from outside > an Eclipse process. You can force a refresh after the antlr run: > right-click project > Properties > Builders > Antlr > Edit > Refresh > > Refresh Resources upon completion > The project containing the selected > resources (patch appended :-) Hm, I wasn't able to attach the patch, because sf doesn't like things that have .zip as their surname. But afaik there is sometimes a problem with plain text patches from windows machines, which is why I always zip them. So I appended it again, zipped and re-christened to .txt. Please remove the .txt extension and unzip :-) Ciao, Leif |
From: Thiago A. <thi...@gm...> - 2005-11-21 02:16:07
|
Leif, Your suggestions are now merged into the jparser branch. Thanks for providing us a clean build :-) 2005/11/20, Leif Frenzel <lfr...@in...>: > It did not work directly for me, because on Eclipse 3.2M3 there are some > new plugins, which were initially missing, so I pressed 'Add required > plugins' and that did the trick. This was of course not because of > windows, but my adding the required plugins will have wiped out all > possible differences between Win and Linux, so I don't know :-) Well, when adding required plugins to the launch, I noticed that there were some .linux plugins on the list (mostly for swt). If you would like, you could create two win32 launches (one with the native parser and one with the java parser). This wouldn't be extremely necessary but would certainly speed up things a little bit for future win32 developers. By the way, export declarations support is ready (I forgot to mention it on the previous post, but the most curious ones could find out :-). Import and top level declaration support is coming soon. Cheers, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-11-21 10:39:50
|
> If you would like, you could create two win32 launches (one with the > native parser and one with the java parser). This wouldn't be > extremely necessary but would certainly speed up things a little bit > for future win32 developers. Good idea. > By the way, export declarations support is ready (I forgot to mention > it on the previous post, but the most curious ones could find out :-). > Import and top level declaration support is coming soon. Cool. I was asking for imports because that is one particular thing I=20 would like to do something about. At the moment, the compiler=20 integration that we have depends on ghc --make to find out which files=20 to compile. This is not very elegant and it also requires people to=20 artifically modify the main module in order to get the Eclipse builder=20 to rebuild correctly. I'd like to do somethig about this, but I need=20 imports correctly determined first. Actually, the prototype for my coding-plugins-in-Haskell idea is=20 intended to do just this. Ciao, Leif >=20 > Cheers, >=20 > Thiago Arrais >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id=16845&op=CCk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >=20 >=20 >=20 |
From: Thiago A. <thi...@gm...> - 2005-11-21 18:11:57
|
2005/11/21, Leif Frenzel <hi...@le...>: > Cool. I was asking for imports because that is one particular thing I > would like to do something about. At the moment, the compiler > integration that we have depends on ghc --make to find out which files > to compile. This is not very elegant and it also requires people to > artifically modify the main module in order to get the Eclipse builder > to rebuild correctly. I'd like to do somethig about this, but I need > imports correctly determined first. Parsing is the very first step here. After the parsing is done, we will need to write a dependency checker. I assume we will need to build some kind of internal graph for the inter-module dependency structure (a project model), but I don't know which is the standard way to do that with Eclipse. Cheers, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-11-22 09:59:31
|
> Parsing is the very first step here. After the parsing is done, we > will need to write a dependency checker. I assume we will need to > build some kind of internal graph for the inter-module dependency > structure (a project model), but I don't know which is the standard > way to do that with Eclipse. Alas, there is no standard way. (Which was one of the topics in the=20 Language Symposium, but it came to nothing.) I've always thought there=20 should be a generic way to manage dependecies, where one wuld have to=20 implement only a function that tells whether two given files stand in=20 the dependency relation or not. The rest would be managed in the=20 background and would not depend on anything language-specific. But we'll=20 have to do it ourselves. There are already the beginnings of it in the=20 eclipsefp code, in the core plugin. Ciao, Leif >=20 > Cheers, >=20 > Thiago Arrais >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id=16845&op=CCk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >=20 >=20 >=20 |