From: Thiago A. <thi...@gm...> - 2005-09-26 18:20:52
|
EclipseFP team, I am currently interesting on understanding our parser approach, and I mean deep understanding. My interest is mainly because of my desire to use the eclipsefp plugins under linux. I am currently working to run eclipsefp under Linux, and I have concluded that this is one of the factors that are holding the Linux port. So that's where I will throw my efforts (I really don't know if there is such an idiom in english, but I am trying). As part of my efforts, I am writing a technical article with my findings. The most up-to-date draft is available at http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.htm= l and the darcs repo for the article is under http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/ Anyone interested in co-authoring and/or reviewing the article? Leif? Regards, Thiago Arrais |
From: Leif F. <lfr...@in...> - 2005-09-28 06:57:22
|
Hi Thiago, first of all, thanks for your effort :-) I have been silent for a while, partly because of some heavy workload, and partly because I have shifted priorities in the last weeks towards the Darcs plugin (which I need at work too, and I have to convince a few people there :-). Partly it is also because I am somewhat frustrated with the progress (or better: lack of progress) that is made inside the Eclipse organization in supporting languages other than Java. I heard a lot of people talking about this at both EclipseCon conferences so far, and subsequently never anything happened :-( There seemed to be an effort going on at the start of this year, to create a new Eclipse subproject for generic language development tools (the LDT project), but this has been quietly cancelled a few months ago. There will be another meeting about that topic in October, which I am going to attend, so we'll see if there is any progress then ... Having said that, I am still committed to the eclipsefp project, whenever time permits :-) This is not much at the moment, so I am mainly restricted to a few posts and simple fixes. I hope this will get better soon, but probably not very much so before the end of the year :-( >I am currently interesting on understanding our parser approach, and I >mean deep understanding. My interest is mainly because of my desire to >use the eclipsefp plugins under linux. I am currently working to run >eclipsefp under Linux, and I have concluded that this is one of the >factors that are holding the Linux port. So that's where I will throw >my efforts (I really don't know if there is such an idiom in english, >but I am trying). > > > Yes, you are right, that is the one major difference. I am interested in getting this to work on Linux, too. >As part of my efforts, I am writing a technical article with my >findings. The most up-to-date draft is available at > >http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.html > >and the darcs repo for the article is under > >http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/ > >Anyone interested in co-authoring and/or reviewing the article? Leif? > > I've read the draft and it looks like a very good description of the situation to me. (Since I started to write this, the article seems to have been updated, but only on the website, not yet in the repo. So I can't create a patch right now and just send my suggestions in here :-) I'd like to add a few remarks: - The whole procedure of parsing is in one single run, i.e. we let the native parser run over the file, then use the different methods to query the information, and then release the pointer to the parse result. This approach doesn't scale very well. At the moment, the object model that represents the parse result in the Java world is cached and thrown away when the file changes (we get file change notifications from Eclipse). But that can obviously only done for some number of files that are not too big. Plus, for something like 'search references to a given function', we would need a different approach that builds an index that holds all the workspace sources (and information about libraries); we would also need to parse the entire AST for that. JDT (Eclipse's Java Development Tools) use a split approach: the have a parser that, like our current parser, reads an object model for presenting it in the Outline etc., and they have a full parser, the results of which are indexed in a searchable model of the entire workspace. - I would suggest to put the paragraph that starts with " When a file is parsed" more to the start, because it describes what actually is the entry point in the code, too. - A very minor point: in the second paragraph of the "Internal workings" section, "no longer need the parser any For instance" was probably meant to be ""no longer need the parser any more. For instance". Thanks a lot && ciao, Leif >Regards, > >Thiago Arrais > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >eclipsefp-develop mailing list >ecl...@li... >https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > > |
From: Jake L. <ef...@10...> - 2005-09-28 08:21:14
|
Leif: Thanks for the earlier download tip. The current haskell console for ghci sessions doesn't appear to support command history - ghc here is compiled with readline and works properly in a shell. Is this limited by eclipse's console capability or something that needs to be implemented?jake |
From: Leif F. <hi...@le...> - 2005-09-28 08:33:38
|
Hi Jake, > Leif: Thanks for the earlier download tip. The current haskell console > for ghci sessions doesn't appear to support command history - ghc here > is compiled with readline and works properly in a shell. Is this limited > by eclipse's console capability or something that needs to be > implemented?jake When I implemented the ghci support, there was no easy way to support command history in the Eclipse console. But that was in Eclipse 3.0, Milestone 4, I believe, so there may be now. The trouble is that the console uses a text control where the cursor keys have the navigation as predefined meaning, so it is probably a matter of catching some SWT key events and send the appropriate characters to the process stream. This would be nasty if we had to do it ourselves, but possibly there is more support for this in Eclipse 3.1/3.2 now. If you'd like to try your hand on this, I would happily accept any contribution. It could help to search the Eclipse newsgroups archives or Bugzilla entries for posts where someone wanted to do something similar. Thanks && ciao, Leif > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > |
From: Thiago A. <thi...@gm...> - 2005-09-28 13:57:34
|
Leif, 2005/9/28, Leif Frenzel <lfr...@in...>: > Hi Thiago, > > first of all, thanks for your effort :-) Thank you for the reply, you are undoubtedly one of the best suited ones to help me in this little adventure. [...] > I've read the draft and it looks like a very good description of the > situation to me. (Since I started to write this, the article seems to > have been updated, but only on the website, not yet in the repo. So I > can't create a patch right now and just send my suggestions in here :-) Not any more. I have struggled a little with darcs and ant and now the repo is synchronized with the work on my local machine. Everybody can start sending their patches now. :-) > I'd like to add a few remarks: I am right now reading them and integrating the suggestions to the article. Take a look. Thanks for the attention, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-09-29 09:01:01
|
>>I've read the draft and it looks like a very good description of the >>situation to me. (Since I started to write this, the article seems to >>have been updated, but only on the website, not yet in the repo. So I >>can't create a patch right now and just send my suggestions in here :-) > > > Not any more. I have struggled a little with darcs and ant and now the > repo is synchronized with the work on my local machine. Everybody can > start sending their patches now. :-) Cool :-) I'll pull it at once. Ciao, Leif > > >>I'd like to add a few remarks: > > > I am right now reading them and integrating the suggestions to the > article. Take a look. > > Thanks for the attention, > > Thiago Arrais > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > |
From: Thiago A. <thi...@gm...> - 2005-10-03 18:26:53
|
EclipseFP Team, I have published another version of the parser article. This one is almost final, I am just waiting for comments. If you want to make any modification to the article, you just need to darcs get the repo and then darcs send your patches to me. All comments are welcome. The URLs again... The published article is on: http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.htm= l The darcs repo for the source code is on: http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/ Leif, can we publish this on the EcliseFP site? Thanks, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-10-04 10:11:18
|
Hi Thiago, >I have published another version of the parser article. This one is >almost final, I am just waiting for comments. If you want to make any >modification to the article, you just need to darcs get the repo and >then darcs send your patches to me. All comments are welcome. > > Great :-) I'll try to have a look at it (still somewhat busy, so it always takes a bit time, sorry :-( >The URLs again... > >The published article is on: > >http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.html > >The darcs repo for the source code is on: > >http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/ > >Leif, can we publish this on the EcliseFP site? > > Certainly. I'll link it in :-) Thanks a lot && ciao, Leif >Thanks, > >Thiago Arrais > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions, >and more. http://solutions.newsforge.com/ibmarch.tmpl >_______________________________________________ >eclipsefp-develop mailing list >ecl...@li... >https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > > |
From: Leif F. <hi...@le...> - 2005-10-09 13:08:03
|
Thiago Arrais wrote: > EclipseFP Team, > > I have published another version of the parser article. This one is > almost final, I am just waiting for comments. If you want to make any > modification to the article, you just need to darcs get the repo and > then darcs send your patches to me. All comments are welcome. Just reading it at the moment (as you see, I'm lagging behind as usual :-( I'll send a few suggestions later. Just when I read the bit about Linux support I remembered I have read something on a mailing list just a few days ago that it would be possible to make shared libs (.so) for Linux with hs-plugins. So maybe that's what we need to get the parser working under Linux too. Is there by any chance someone on the list with experiences with hs-plugins? > The URLs again... > > The published article is on: > > http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.html > > The darcs repo for the source code is on: > > http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/ > > Leif, can we publish this on the EcliseFP site? Done :-) Perhaps a bit of re-structuring would be in order on the homepage, it's already a bit much of information on one page there ... Ciao, Leif > > Thanks, > > Thiago Arrais > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > |
From: Jake <ef...@10...> - 2005-10-09 14:33:58
|
> Just when I read the bit about Linux support I remembered I have read > something on a mailing list just a few days ago that it would be possible to > make shared libs (.so) for Linux with hs-plugins. So maybe that's what we > need to get the parser working under Linux too. Is there by any chance Maybe I am still missing something because I am running eclipsefp perfectly well on both Gentoo X86 and Debian X86 Linux daily with Eclipse 3.1 jake |
From: Thiago A. <thi...@gm...> - 2005-10-10 02:56:56
|
> Just reading it at the moment (as you see, I'm lagging behind as usual > :-( I'll send a few suggestions later. I am looking forward to it. > Just when I read the bit about Linux support I remembered I have read > something on a mailing list just a few days ago that it would be > possible to make shared libs (.so) for Linux with hs-plugins. So maybe > that's what we need to get the parser working under Linux too. Is there > by any chance someone on the list with experiences with hs-plugins? Not me. Sorry. But I surely can learn it, can you give me some initial pointers? And I have to say that I think we should start to build a pure Java parser. We will need it sooner or later. I am currently a little busy with UI enhancements and GHC support, but maybe I can start it as soon as I find some material on parsing Haskell. I have tried to play with lexers and parsers for Haskell without much success. I am used to parsing curly-brace languages like C and Java, but I am somehow lost on parsing Haskell. Maybe someone with some experience on Haskell parsing could give me some initial pointers. If I could just manage to understand the .y files... > Done :-) Perhaps a bit of re-structuring would be in order on the > homepage, it's already a bit much of information on one page there ... I have been thinking of re-structuring the EclipseFP site for some time now. Maybe we can write a 'One minute tutorial' and split the site in user and developer areas. I have some ideas, we can discuss them as needed. Best regards, Thiago Arrais |
From: Jake <ef...@10...> - 2005-10-10 04:35:13
|
> And I have to say that I think we should start to build a pure Java > parser. We will need it sooner or later. I am currently a little busy > with UI enhancements and GHC support, but maybe I can start it as soon > as I find some material on parsing Haskell. I have tried to play with > lexers and parsers for Haskell without much success. I am used to > parsing curly-brace languages like C and Java, but I am somehow lost on > parsing Haskell. Maybe someone with some experience on Haskell parsing > could give me some initial pointers. If I could just manage to > understand the .y files... Thiago, that's something that maybe I can help. I have been working with parsec recently, and it is just plain elegant. I take that over lex/yacc any day. Why not utilizing ghc's internal Language.Haskell.* libraries? I started looking at the eclipsefp darcs repo recently, the major inpediment here is understanding how does the existing plugin fits in the eclipse framework. Maybe we can collaborate on this. jake checkout http://www.cs.uu.nl/~daan/parsec.html |
From: Thiago A. <thi...@gm...> - 2005-10-10 12:00:07
|
2005/10/10, Jake <ef...@10...>: > Thiago, that's something that maybe I can help. I have been working with > parsec recently, and it is just plain elegant. I take that over lex/yacc > any day. Why not utilizing ghc's internal Language.Haskell.* libraries? > > I started looking at the eclipsefp darcs repo recently, the major > inpediment here is understanding how does the existing plugin fits in the > eclipse framework. Maybe we can collaborate on this. jake Maybe my article on the parser can help you understand our parser structure. I have been messing with the parser for some time now (although I didn't write it), I can help you understand it as needed. Take a look at: http://www.cin.ufpe.br/~tbas/eclipsefp-parser.techarticle/build/article.htm= l I am a little busy right now, but will comment on the GHC library thing later. Anyway, reading the article may enlighten you a bit. And, if it doesn't, the article is always a work on progress and we can always augment it. Cheers, Thiago Arrais |
From: Thiago A. <thi...@gm...> - 2005-10-10 17:58:43
|
Jake, 2005/10/10, Jake <ef...@10...>: [...] > Thiago, that's something that maybe I can help. I have been working with > parsec recently, and it is just plain elegant. I take that over lex/yacc > any day. Why not utilizing ghc's internal Language.Haskell.* libraries? This is exactly the approach we have been taking so far, more details on the article. The problem with doing the parsing in Haskell is that it holds us back a little, because with our current structure we need lots of bridging code (both in Haskell and in C) if we want to access the AST. Having a pure Java parser would free us from that and let us move a little faster, but it is work that has to be started "from the ground". We can have access to the full AST with our current structure, but the code that will be written to translate the tree from the Haskell world back to Java will look just like plain parser code, in the sense that it has to know about the language structure and query the Haskell code accordingly. I have thought of starting with a partial parser, one that would initially recognize only the main language elements and delegate the rest of the parsing process to the underlying native parser. That way we could convert the parser from Haskell to Java as needed and end with a full Haskell parser running in Java. We would also have the parser available to all supported platforms with no native code needed, that means having to take care of a smaller code base. This is one idea, but is it feasible? Maybe we can cooperate on this... > I started looking at the eclipsefp darcs repo recently, the major > inpediment here is understanding how does the existing plugin fits in the > eclipse framework. Maybe we can collaborate on this. jake Maybe someone can explain this better than me, but I will give it a try. If anyone sees me making any mistakes, please correct me. ;-) The whole Haskell extension is made of a lot of plugins. In Eclipse, a plugin needs to fit into one or more existing extension points and can declare other extension points. The parser is one of those plugins, and it fits into an extension point declared by the haskell.core plugin (another of our plugins). When the Haskell core plugin needs to do some parsing, it asks the Eclipse platform if there is any plugin registered that can do it. The platform finds the parser plugin and they start talking. If the platform cannot find a suitable parser, the core plugin rolls back the functionality that needs the parser, that's why, for example, it won't populate the Outline view accordingly on non-win32 systems. Actually, I don't know if it is this that really happens, or if the plugin actually exists on non-win32 but it can't answer because it lacks the apropriate native parser. Take a look at the code. If there is something you don't understand, I don't really know all the details but we can help each other to learn. There is also lots of docs on the eclipse site. Cheers, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-10-10 20:01:30
|
Hi all, > Maybe someone can explain this better than me, but I will give it a > try. If anyone sees me making any mistakes, please correct me. ;-) I couldn't have explained it better :-) > When the Haskell core plugin needs to do some parsing, it asks the > Eclipse platform if there is any plugin registered that can do it. The > platform finds the parser plugin and they start talking. If the > platform cannot find a suitable parser, the core plugin rolls back the > functionality that needs the parser, that's why, for example, it won't > populate the Outline view accordingly on non-win32 systems. Actually, > I don't know if it is this that really happens, or if the plugin > actually exists on non-win32 but it can't answer because it lacks the > apropriate native parser. The plugin for the parser consists of several platform-specific 'fragments'. If you have a plugin, you can have a number of fragments that declare the plugin as their host. Each fragment specifies for which platform it is responsible. So we have for the native parser the plugin (net.sf.eclipsefp.haskell.core.parser) plus a win32 fragment (net.sf.eclipsefp.haskell.core.parser.win32). When the Eclipse runtime starts, it loads all fragments that fit the platform into the plugin, so that it appears, from the plugin's perspective, as if the fragment content (jars, resources, extensions to extension points) are actually in the plugin. If the win32-fragment is there on a Linux-platform, it is just ignored by the runtime. If it is not there, it won't be missed ;-). On win32, the fragment is loaded and it's contents are available to all other plugins, including haskell.core, as if they came from net.sf.eclipsefp.haskell.core.parser. If we would have a Linux implementation, it would go into a fragment net.sf.eclipsefp.haskell.core.parser.linux-gtk, which should contain a .so library. If a parser is asked for on a platform where there is no native parser available, it happens exactly like you described. The plugin is there but can't find a native parser. Ciao, Leif > > Take a look at the code. If there is something you don't understand, I > don't really know all the details but we can help each other to learn. > There is also lots of docs on the eclipse site. > > Cheers, > > Thiago Arrais > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
From: Leif F. <hi...@le...> - 2005-10-09 16:37:15
|
Jake wrote: > >> Just when I read the bit about Linux support I remembered I have read >> something on a mailing list just a few days ago that it would be >> possible to make shared libs (.so) for Linux with hs-plugins. So maybe >> that's what we need to get the parser working under Linux too. Is >> there by any chance > > > Maybe I am still missing something because I am running eclipsefp > perfectly well on both Gentoo X86 and Debian X86 Linux daily with > Eclipse 3.1 jake It falls back to the functionality that doesn't need a parser. On windows, there is in addition an outline view showing top-level declarations and code folding. These are just not there under Linux, but we'd like to have them ;-) Most interesting things like 'Go to declaration', 'Search for references', refactoring, better build support etc. will also need the parser. Ciao, Leif |
From: Jake <ef...@10...> - 2005-10-09 20:24:01
|
> It falls back to the functionality that doesn't need a parser. On > windows, there is in addition an outline view showing top-level > declarations and code folding. These are just not there under Linux, but > we'd like to have them ;-) Most interesting things like 'Go to > declaration', 'Search for references', refactoring, better build support > etc. will also need the parser. Ahhh, I only used eclipsefp on Mac OS X and Linux, and assumed that was the state of the art. I guess, I should give windows a try. Thanks for the tip. jake |