From: Thiago A. <thi...@gm...> - 2005-06-01 04:02:48
|
My name is Thiago Arrais and I am willing to contribute to the eclipsefp project. I have done myself some (little) eclipse development and I am studing it for some time now. I have some functional language implementation background also and I am very interested in eclipsefp project. If anyone could give me some starting directions, I would be thankful. Should I get the source code from CVS and start digging into it? Is there any project documentantion? How do you do version and configuration control? What are the project needs right now? I am specially interested in debugging. Are you planning to have haskell debug support? Thanks, Thiago Arrais thi...@gm... |
From: Leif F. <hi...@le...> - 2005-06-06 23:06:25
|
Hi Thiago, > My name is Thiago Arrais and I am willing to contribute to the > eclipsefp project. Great :-) I'm sorry to answer back that late. I was not in reach of any email for two weeks and am just working through my inbox ... > I have done myself some (little) eclipse development and I am studing > it for some time now. I have some functional language implementation > background also and I am very interested in eclipsefp project. > > If anyone could give me some starting directions, I would be thankful. > Should I get the source code from CVS and start digging into it? Is > there any project documentantion? How do you do version and > configuration control? What are the project needs right now? There are at the moment two subprojects (one for Haskell, which is done mainly by me, and one for OCaml, which is done by Andrei Formiga) together with a (small) set of common plugins. Only the latter are in the CVS on sf. The sources are included in all releases, so the best starting point is to install the latest version with the Update Manager and import all plugins starting with de.leiffrenzel.fp and net.eclipsefp.* into the workspace (Import > External Plugins). I have thought recently about setting up a darcs repository for version control, but had not yet the time to make an experimental go with that. The two main topics on my todo list are currently 1) the language model support (basically an object model that represents the Haskell source code in the workspace, similar to the JDTs model), which involves parsing, monitoring file changes, and making the information from the model useful in different places, like in the outline view, or for the compiler; and 2) the integration of interactive tools (i.e. ghci and hugs) which is very shaky and inconvenient at the moment. You will also find some more suggestions in the list archive (e.g. Cabal integration). Apart from that, there is a list (in the included Help) of items that I would like to include in the plugin. > I am specially interested in debugging. Are you planning to have > haskell debug support? I would be very, very interested indeed, but I have no idea at all how to do it. There is a framework for debugging in Eclipse that is intended to be a basis for debuggers for different languages, but it obviously supports primarily the line-by-line-stepping approach. (I believe there is an article about that framework at http://eclipse.org/articles). So if you are interested to have a look at that and see what can be done with it, that would be surely a good start. I would be glad if we could have a bit of a brainstorming here on the list. The main question here is, of course, whether we can integrate with any existing tools. The only debugger for Haskell that I know of that supports a similar paradigm is HsDebug, and what I read about it was a paper that stated that it was more or less experimental, as far as I can remember. Thanks && ciao, Leif > > Thanks, > Thiago Arrais > thi...@gm... > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr_______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > > |
From: Thiago A. <thi...@gm...> - 2005-06-07 00:29:07
|
Hello Leif, > Great :-) I'm sorry to answer back that late. I was not in reach of any > email for two weeks and am just working through my inbox ... Good to hear from you! > There are at the moment two subprojects (one for Haskell, which is done > mainly by me, and one for OCaml, which is done by Andrei Formiga) > together with a (small) set of common plugins. Only the latter are in > the CVS on sf. The sources are included in all releases, so the best > starting point is to install the latest version with the Update Manager > and import all plugins starting with de.leiffrenzel.fp and > net.eclipsefp.* into the workspace (Import > External Plugins). I have not yet looked on these sources, but I'll certainly look for them. > I have thought recently about setting up a darcs repository for version > control, but had not yet the time to make an experimental go with that. Version control is always welcome. What do you think of using SF's CVS? It is accessible from inside eclipse and I think is a very good acquisition for any project. > The two main topics on my todo list are currently 1) the language model > support (basically an object model that represents the Haskell source > code in the workspace, similar to the JDTs model), which involves > parsing, monitoring file changes, and making the information from the > model useful in different places, like in the outline view, or for the > compiler; and 2) the integration of interactive tools (i.e. ghci and > hugs) which is very shaky and inconvenient at the moment. Lots of things here. All of them very interesting and useful to the end use= r.=20 1) language model support: I have browsed through the mailing list archives and found that (at least the initial work of) a parser is already done. This will be a vital component for the debugger regardless of the approach we choose. I will take a look at the code to get the general idea behind your parser. 2) integration of interactive tools: this is very closely related to the debugger, on the matter that it to will be a interactive tool. > You will also find some more suggestions in the list archive (e.g. Cabal > integration). >=20 > Apart from that, there is a list (in the included Help) of items that I > would like to include in the plugin. >=20 > I would be very, very interested indeed, but I have no idea at all how > to do it. There is a framework for debugging in Eclipse that is intended > to be a basis for debuggers for different languages, but it obviously > supports primarily the line-by-line-stepping approach. (I believe there > is an article about that framework at http://eclipse.org/articles). I have already done some brainstorming and initial researching on functional (and declarative in general) language debuggin but I didn't study the eclipse debugging framework. My general idea for the debugger is to allow the user to see graph reduction taking place and it would be a evaluation-stepping approach. This is an initial idea although. I don't know which level of support the eclipse debug framework will give us, but I think (and this is just a hunch) it is more suitable for side-effect-ful languages as Java and C++. Well, it shouldn't be thrown away at all as it should give us at least some support. =20 > So if you are interested to have a look at that and see what can be done > with it, that would be surely a good start. I would be glad if we could > have a bit of a brainstorming here on the list. >=20 > The main question here is, of course, whether we can integrate with any > existing tools. The only debugger for Haskell that I know of that > supports a similar paradigm is HsDebug, and what I read about it was a What paradigm are you referring to? Line-stepping? > paper that stated that it was more or less experimental, as far as I can > remember. I would add to you question: Can we integrate any existing tools with eclipse nicely? I have heard of another debugger called HAT, but I don't know what is it based upon. Thanks, Thiago Arrais thi...@gm... |
From: Leif F. <lfr...@in...> - 2005-06-08 17:22:25
|
Hi Thiago, > Version control is always welcome. What do you think of using SF's > CVS? It is accessible from inside eclipse and I think is a very good > acquisition for any project. I must confess I'm very much in a hate-love relationship with CVS. Just the well-known quarrels: renaming, deleting, moving directories, which is a pain especially with Java packages when you are as fond as I am for continuous refactoring; deleting a file and later create on with the same name; the problems with platform linebreaks in the CVS/Entries file everytime you are working on a copy on shared filesystems; and the pain whenever a commit breaks mid-way, especially when you have slow connections at times (which I have :-( Although the support in Eclipse is quite good, I still find myself looking for alternatives permanently. The mentioned problems are supposed to go away with svn, but then the svn support in Eclipse is not yet very far advanced (or rather was so when I looked at it a while ago). And it's not yet available on sf. I have been playing around with Darcs a while now and it seems a good solution, for me at least. I'm working regulary on three different machines, and the distributed repos are exactly what I need for that style of work. Also, I can be offline most of the time. And besides, it is a way of supporting Haskell on that front too :-) The drawback is of course the lack of integration in Eclipse. I've started a plugin project for Darcs, but that will take some time until it's usable. But I agree that we should set up a version control for the whole of the code. Would you (and anybody else on the list) agree to give Darcs a try? Or would you prefer to stick to CVS? >1) language model support: I have browsed through the mailing list >archives and found that (at least the initial work of) a parser is >already done. This will be a vital component for the debugger >regardless of the approach we choose. I will take a look at the code >to get the general idea behind your parser. It's the parser from haskell-src. What exactly I'm doing is this: I mashal the content of the Haskell source file to the Haskell side, let the parser run over this and get a stable pointer to the parse result, which I marshal back to the Java side and keep it as int there. I then send that pointer back to the Haskell side in order to retrieve the list of imports, list of top-decls etc. These information is then used to build the object model. When it's ready, the stable pointer is disposed. It's not the most beautiful approach, since it involves lots of bridging code in both c and Haskell, but it works. It should be possible to beautify it somewhat, but there will be a rest of ugliness still, because of the JNI requirements. And there are some worse problems: - It works on Windows where the Haskell code is linked into a dll; but for Linux we'll have to wait until the PIC (position-independent code) support is ready. So we're Windows-only with everything that requires the parser. - The approach I have taken is enough to get the names and positions of the main language elements (top-level decls, imports, module declaration - basically everything that is presented on the Outline View), but we can't marshal the entire AST that way, especially because of nested declarations. - Source code positions are in terms of line and column in the source, whereas the Eclipse text framework does everything in terms of offset in the document and length of the language element. The latter we don't get from the parser, the former requires some conversion, and one is not always in a good position to do it (it is easy when the file is open in an editor, in that case you can get the offset for a line/column pair from the editor's document model; but if the file is not in an editor, there is no easy way to do the conversion). I have a bit of a workaround for this, but that workaround is not universal ... The main advantage of the current approach is that it is fast and, as far as it goes, easy to implement and to update to newer versions of the haskell-src package (if any). But we will probably need a separate approach for cases where we want access to the entire AST. >2) integration of interactive tools: this is very closely related to >the debugger, on the matter that it to will be a interactive tool. Yupp, although I was more thinking in terms of the UI for, say, loading a specific source file in the editor into ghci etc. That is not very well handled in the plugin at the moment. >I don't know which level of support the eclipse debug framework will >give us, but I think (and this is just a hunch) it is more suitable >for side-effect-ful languages as Java and C++. Well, it shouldn't be >thrown away at all as it should give us at least some support. Afaik the Eclipse debugger framework is really more a debugger UI framework. You have to implement a set of interfaces so that the UI can connect to the actual debugger that runs in the background. One good reason for sticking to that framework is that users get something they already know from JDT (or perhaps CDT) when they do Java (or C/C++) debugging. Apart from that, we have to do less UI coding, of course ;-) Ciao, Leif |
From: Thiago A. <thi...@gm...> - 2005-06-09 13:39:15
|
Leif, > I must confess I'm very much in a hate-love relationship with CVS. Just t= he > well-known quarrels: renaming, deleting, moving directories, which is a p= ain > especially with Java packages when you are as fond as I am for continuou= s > refactoring; deleting a file and later create on with the same name; the ---cut--- We'll get along very well then. I just can't go without refactoring. =20 > I have been playing around with Darcs a while now and it seems a good > solution, for me at least. I'm working regulary on three different > machines, and the distributed repos are exactly what I need for that styl= e > of work. Also, I can be offline most of the time. And besides, it is a > way of supporting Haskell on that front too :-) The drawback is of course > the lack of integration in Eclipse. I've started a plugin project > for Darcs, but that will take some time until it's usable. Maybe I can join your project for the darcs plugin later on, if I like the experience. Why not? =20 > But I agree that we should set up a version control for the whole of the > code. Would you (and anybody else on the list) agree to give Darcs a try?= Or > would you prefer to stick to CVS? Sure I will give it a try. Do you have an operant on-line server that we can have access? Would you show the its and bits of using darcs? (Client configurarion, server address, etc.) --- cut --- > - It works on Windows where the Haskell code is linked into a dll; but fo= r > Linux we'll have to wait until the PIC (position-independent code) suppor= t > is ready. So we're Windows-only with everything that requires the parser. Didn't get what do you meant with position-independent code... I think Windows dependency is the worst issue. Platform independence should be one of our main concerns here if we want to get a large number of users. What are the alternatives we have for it? I have thought of at least three and I list them here with the main disadvantages: 1. To take the same approach with other platforms (to port the library): this doesn't achieve all that platform independece, but can be pratical depending on our target public. 2. To re-implement the parser in Java: maybe this is much work to do. But we can always take a incremental approach and there is the haskell-src for us to use as a starting base. This would be almost a translation process. 3. To implement a haskell to Java bytecode compiler, so that we can run the same haskell-src parser inside the Java Virtual Machine: much more work than in the number 2 alternative, but yields a much useful result. There is an issue here although: functional language to 'object-oriented' machines is very unstable at the moment and this would be more like a research project. Any other ideas? > - The approach I have taken is enough to get the names and positions of t= he > main language elements (top-level decls, imports, module declaration - > basically everything that is presented on the Outline View), but we can't > marshal the entire AST that way, especially because of nested declaration= s. I didn't understand your point here. Doesn't the haskell-src parser have the full AST? Why can't we get the full AST? Or is it an implementation specific issue because of the middle C bridge? I am just wondering here now, but I think we we'll need the full AST for some of the functions we plan to have like full code assist. Won't we? > - Source code positions are in terms of line and column in the source, > whereas the Eclipse text framework does everything in terms of offset in = the > document and length of the language element. The latter we don't get from > the parser, the former requires some conversion, and one is not always in= a > good position to do it (it is easy when the file is open in an editor, in > that case you can get the offset for a line/column pair from the editor's > document model; but if the file is not in an editor, there is no easy way= to > do the conversion). I have a bit of a workaround for this, but that > workaround is not universal ... That is what I what was talking about when I said that we'd need some AST decoration ['Debugging - Brainstorm' thread]. The pure AST without that sort of info just isn't enough for full IDE power. How can we adapt a solution for that? =20 > The main advantage of the current approach is that it is fast and, as far= as > it > goes, easy to implement and to update to newer versions of the haskell-sr= c > package (if any). But we will probably need a separate approach for cases > where we want access to the entire AST. Are newer versions a real issue? I think Haskell is mostly stable. But I am not the best person to answer that, although. =20 > >2) integration of interactive tools: this is very closely related to > >the debugger, on the matter that it to will be a interactive tool. > Yupp, although I was more thinking in terms of the UI for, say, loading a > specific source file in the editor into ghci etc. That is not very well > handled in the plugin at the moment. Here I have thought of using the eclipse launch capabilities to integrate the tools more tightly with the workbench. But I am not very comfortable on that subject since I haven't done my homework (current haskell plugin exploration) on that area. =20 > >I don't know which level of support the eclipse debug framework will > >give us, but I think (and this is just a hunch) it is more suitable > >for side-effect-ful languages as Java and C++. Well, it shouldn't be > >thrown away at all as it should give us at least some support. > Afaik the Eclipse debugger framework is really more a debugger UI framewo= rk. > You have to implement a set of interfaces so that the UI can connect to t= he > actual debugger that runs in the background. Nice. But isn't the UI more suitable for side-effect-ful languages? Or is it independent on that aspect? I need to do some researching on that yet. > One good reason for sticking to that framework is that users get somethin= g > they already know from JDT (or perhaps CDT) when they do Java (or C/C++) > debugging. Apart from that, we have to do less UI coding, of course ;-) That's the main idea. I think the HDT (standing for the Haskell JDT counterpart) should be as similar to the JDT as possible. Both in UI and architecture design terms. Should we study the JDT architecture for the common problems and ideas for solutions (mainly getting some design patterns)? Their solutions are undoubtly working very well. What is your level of knowledge on that matter? Do you know the JDT architecture? I think a survey with haskell users and developers for most used debuggers and platforms would be a good shot. That way we could have the directions for issues like the best parser approach and the debugger interface. I mean, if people really like declarational debuggers like buddha and it is really more useful for functional developers, why bother making a full blown user controlled graph reducer? Would the comp.lang.functional newsgroup be a good source for that survey? We are doing a lot of brainstorming here, mainly for me to get into the project. Unquestionably, I have posed many questions here. If you'd like, for the sake of organization, you can answer them in separate threads. Thanks, Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-06-09 20:38:46
|
>>- The approach I have taken is enough to get the names and positions of the >>main language elements (top-level decls, imports, module declaration - >>basically everything that is presented on the Outline View), but we can't >>marshal the entire AST that way, especially because of nested declarations. > > > I didn't understand your point here. Doesn't the haskell-src parser > have the full AST? Why can't we get the full AST? Or is it an > implementation specific issue because of the middle C bridge? The haskell-src parser has the full AST; what I mean is that it is not feasible to marshal it the way I did. (You'll understand when you see the code ...) What I do basically is to hold a pointer to the root of the tree, and then I must navigate the tree down to the element I want. E.g. a parse result has a list of import statements, each of which has a module name. So I use the pointer to the parse result to first get the length of the import list, then I create as many objects on the Java side and then for every one of them I call a method that looks from the Java side like (in pseudo-code) native String getImportName( int stablePtrToParseResult, int indexOfImportInImportList ); and the same for the line and column of the import. These information I feed into the objects that represent the import statements on the Java side. But suppose I go for a data declaration and collect the constructor names. Then I need already three params: the stable pointer to the root, the index of the data decl in the declarations list, and the index of the constructor in the constructors list. That works still, but can't be extended very much more. It won't work of course once we have arbitrarily nested declarations, which could be there for a complete AST. A different approach could have been to get stable pointers to the elements (like HsImport, HsDecl) etc. But afaics that would have involved even more coding. (Remember that I did no actual parser coding, all the code that I wrote is only bridging stuff, and it is already smelling like over-redundant.) > I am just wondering here now, but I think we we'll need the full AST > for some of the functions we plan to have like full code assist. Won't > we? Definitely. For instance for code assist within local declarations, or for indexing calls to a given function in the code. I have already thought that a parser that gives us a homogeneous AST would be easier to handle. We would have just nodes, each of which has a type, a value, and a list of child nodes. The bridging code would reduce to a few functions, and we would have a much more simple model on the Java side. For the language model (i.e. the one that is presented in the Outline view and used in other places), this would be not so good, since there it is an advantage to parse quickly and hava a convenient and type-safe object model to represent the code. But where we want to access the entire AST, it would probably do. It would make using the AST more coding-intensive on the Java side, of course. I'd suggest we keep both approaches: the language model for things like the Outline View, the AST for other things. Both JDT and CDT use different parsers for this division of labour. >>- Source code positions are in terms of line and column in the source, >>whereas the Eclipse text framework does everything in terms of offset in the >>document and length of the language element. The latter we don't get from >>the parser, the former requires some conversion, and one is not always in a >>good position to do it (it is easy when the file is open in an editor, in >>that case you can get the offset for a line/column pair from the editor's >>document model; but if the file is not in an editor, there is no easy way to >>do the conversion). I have a bit of a workaround for this, but that >>workaround is not universal ... > > > That is what I what was talking about when I said that we'd need some > AST decoration ['Debugging - Brainstorm' thread]. The pure AST without > that sort of info just isn't enough for full IDE power. How can we > adapt a solution for that? We'll probably need a different parser that gives us that sort of information. So maybe we should have a look at the existing Haskell parsers again. (The reason I used haskell-src was mainly for simplicity.) >>The main advantage of the current approach is that it is fast and, as far as >>it >>goes, easy to implement and to update to newer versions of the haskell-src >>package (if any). But we will probably need a separate approach for cases >>where we want access to the entire AST. > > > Are newer versions a real issue? I think Haskell is mostly stable. But > I am not the best person to answer that, although. My though here was more about language extensions. >>>2) integration of interactive tools: this is very closely related to >>>the debugger, on the matter that it to will be a interactive tool. >> >>Yupp, although I was more thinking in terms of the UI for, say, loading a >>specific source file in the editor into ghci etc. That is not very well >>handled in the plugin at the moment. > > > Here I have thought of using the eclipse launch capabilities to > integrate the tools more tightly with the workbench. But I am not very > comfortable on that subject since I haven't done my homework (current > haskell plugin exploration) on that area. Yes, that's how it works currently. But the code needs re-working, partly because Eclipse 3.1 has quite a few new features (in the Console View), partly also because I underestimated how many people actually work more intensively with the interpreters than I do. When I started with the interpreter support, I was not aware of that. But a significant part of the feedback was about the interpreter support. >>>I don't know which level of support the eclipse debug framework will >>>give us, but I think (and this is just a hunch) it is more suitable >>>for side-effect-ful languages as Java and C++. Well, it shouldn't be >>>thrown away at all as it should give us at least some support. >> >>Afaik the Eclipse debugger framework is really more a debugger UI framework. >>You have to implement a set of interfaces so that the UI can connect to the >>actual debugger that runs in the background. > > > Nice. But isn't the UI more suitable for side-effect-ful languages? Or > is it independent on that aspect? I need to do some researching on > that yet. I think it is built around the notion of a call stack, there is much UI to inspect the values on the current frame etc. It is clearly designed with jdb/gdb-style debuggers in mind. > > >>One good reason for sticking to that framework is that users get something >>they already know from JDT (or perhaps CDT) when they do Java (or C/C++) >>debugging. Apart from that, we have to do less UI coding, of course ;-) > > > That's the main idea. I think the HDT (standing for the Haskell JDT > counterpart) should be as similar to the JDT as possible. Both in UI > and architecture design terms. Should we study the JDT architecture > for the common problems and ideas for solutions (mainly getting some > design patterns)? Their solutions are undoubtly working very well. > What is your level of knowledge on that matter? Do you know the JDT > architecture? Jupp, I'd say so. I'm an Eclipse specialist in my daytime job (doing consulting and coaching for Eclipse-based software projects, and leading the development of an Eclipse distribution), and I know most of the Platform/RCP and much of JDT and PDE very well from the inside. I've also looked closely into CDT and some other language-supporting plugins. It's definitely a very good idea to look into JDT, but there is an overwhelming lot of code there. A very good introduction to the patterns in the Eclipse architecture is the third part of Gamma/Beck, "Contribution to Eclipse". I completely agree about the similarity to JDT. There is what Erich Gamma called at a recent conference the 'feature matrix'. It shows which features JDT has and it calls for every other project (CDT, WebTools, whatever) to implement the same set. I'll see whether I can put it to the website somewhere. Some of the ideas from that matrix are also already specified in the Eclipse UI Guidelines (at http://eclipse.org/articles). Especially with regard to debugging, looking into CDT may help, too. I have never used the debugging facilities in CDT, so I know neither how good it is nor what exactly it does. I presume it's mainly about driving gdb. Another interesting thing could be the Ant debugger that was introduced in one of the last milestones of 3.1. That sits probably on top of the JDT debugger, but it could be used as an example for things like managing breakpoints etc. From my experience, looking into more peripheral parts of Eclipse like the Ant support helps a lot, because it is not so much code, but it still implements most of the interesting features. > I think a survey with haskell users and developers for most used > debuggers and platforms would be a good shot. That way we could have > the directions for issues like the best parser approach and the > debugger interface. I mean, if people really like declarational > debuggers like buddha and it is really more useful for functional > developers, why bother making a full blown user controlled graph > reducer? Would the comp.lang.functional newsgroup be a good source for > that survey? I'd rather suggest the Haskell-Cafe list. I remember I read a survey in that vein some time ago, I'll dig the archives tomorrow, maybe I can find something there. > We are doing a lot of brainstorming here, mainly for me to get into > the project. Unquestionably, I have posed many questions here. If > you'd like, for the sake of organization, you can answer them in > separate threads. Did so, as you noted :-) Thanks for all your input && ciao, Leif |
From: Leif F. <hi...@le...> - 2005-06-09 20:45:01
|
>>- It works on Windows where the Haskell code is linked into a dll; but for >>Linux we'll have to wait until the PIC (position-independent code) support >>is ready. So we're Windows-only with everything that requires the parser. > > > Didn't get what do you meant with position-independent code... Linking the Haskell and c code into a .so library, i.e. the equivalent to a dll on windows. I had a little experience with dlls, but none with such libs on Linux, maybe I missed something. But as far as I understood, we would have to use the -fPIC flag in GHC, which does not work for Linux yet. But if anybody knew a way to do it for Linux, that would be great of course. You could have a look at how I did the linking for Windows (had to do a bit of googling until I found out how it works). The Haskell and c code is in net.sf.eclipsefp.haskell.core.parser.win32/src/, and the lines I used to build the dll in net.sf.eclipsefp.haskell.core.parser.win32/INTERNAL/conf/build.bat. I run the .bat as an external tool builder in Eclipse. I'm very much for platform independence. I think we should at least aim to have support for Windows, Linux and Mac. For this I just decided to hope that that feature in ghc would soon be available. > I think Windows dependency is the worst issue. Platform independence > should be one of our main concerns here if we want to get a large > number of users. What are the alternatives we have for it? I have > thought of at least three and I list them here with the main > disadvantages: > > 1. To take the same approach with other platforms (to port the > library): this doesn't achieve all that platform independece, but can > be pratical depending on our target public. > > 2. To re-implement the parser in Java: maybe this is much work to do. > But we can always take a incremental approach and there is the > haskell-src for us to use as a starting base. This would be almost a > translation process. > > 3. To implement a haskell to Java bytecode compiler, so that we can > run the same haskell-src parser inside the Java Virtual Machine: much > more work than in the number 2 alternative, but yields a much useful > result. There is an issue here although: functional language to > 'object-oriented' machines is very unstable at the moment and this > would be more like a research project. > > Any other ideas? We had a bit of brainstorming about that issue on this list a while ago (almost exactly a year ago, actually). Since then we had a small parser written in Java (written by Andrei) and more recently the bridge to haskell-src. Since I tried my hand on the latter, I think it is ok to handle native libs, provided they are portable. By this I mean that the Haskell and c code is one and the same and is just compiled and linked into different libs at build time. I can live well with that approach. (Under the condition that we get Linux libs in the near future.) So I'm leaning to alternative 1). One obvious advantage is that we can code some of the interesting bits in Haskell, while leveraging the Eclipse platform for UI and language-independent things (i.e. everything that comes for free like CVS support, Help system etc.). The latter is my main speciality, so I'm of course very glad if someone takes interest in other areas, like you do with debugging (where it is my turn to do some more homework still ;-). Ciao, Leif |
From: Leif F. <hi...@le...> - 2005-06-09 18:28:39
|
Hi Thiago, > We'll get along very well then. I just can't go without refactoring. Very good :-) >>But I agree that we should set up a version control for the whole of the >>code. Would you (and anybody else on the list) agree to give Darcs a try? Or >>would you prefer to stick to CVS? > > > Sure I will give it a try. Do you have an operant on-line server that > we can have access? Would you show the its and bits of using darcs? > (Client configurarion, server address, etc.) We can use the sf webspace for that. It would host the repo, where everybody can pull from (= checkout/update) into a local repo. Developers can push (=checkin) changes to the repo directly, since they have access permissions on sf. It is also possible to use Darcs to create a patch into a text file and send it to a developer, who can have a look at it and then push it. The manual for Darcs is here: http://darcs.net/manual/ Then there's the wiki: http://darcs.net/DarcsWiki That section got me started: http://darcs.net/manual/node4.html Using darcs is very simple. I think I'll just create a repo this weekend on the sf server and we can try it out. When it is up and running, I'll send a summary of the basic steps needed for you to get the sources from it. [cutting the rest of the mail, I'll answer the other topics separately] Ciao, Leif |
From: Thiago A. <thi...@gm...> - 2005-06-11 17:23:07
|
> Very good :-) >=20 > We can use the sf webspace for that. It would host the repo, where > everybody can pull from (=3D checkout/update) into a local repo. > Developers can push (=3Dcheckin) changes to the repo directly, since they > have access permissions on sf. It is also possible to use Darcs to > create a patch into a text file and send it to a developer, who can have > a look at it and then push it. >=20 > The manual for Darcs is here: http://darcs.net/manual/ > Then there's the wiki: http://darcs.net/DarcsWiki > That section got me started: http://darcs.net/manual/node4.html Very good introduction that one. Can't wait to try Darcs out. > Using darcs is very simple. I think I'll just create a repo this weekend > on the sf server and we can try it out. When it is up and running, I'll > send a summary of the basic steps needed for you to get the sources from = it. Just waiting to get my hands on these... Thiago Arrais thi...@gm... |
From: Andrei de A. F. <arc...@ya...> - 2005-06-26 15:06:19
|
--- Thiago Arrais <thi...@gm...> wrote: > My name is Thiago Arrais and I am willing to > contribute to the > eclipsefp project. Hi Thiago, I just noticed your email. Do you have interest in the OCaml subproject ? Right now I'm unfortunately in no condition to carry on with its development. There are a lot of people interested in an IDE for OCaml (I was contacted by some research groups interested in it, for example), there's a book on OCaml coming out from APress, so I believe the language is starting to be visible from the mainstream. Most people don't want to use emacs for their programming, and currently there is no OCaml IDE for these people. I believe it's an important project. If you are interested you can take over the development of the OCaml plugins. I would be able to help, I'm just not able to commit large amounts of time to it now. OT, but are you brazilian ? --- []s, Andrei Formiga ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com |
From: Thiago A. <thi...@gm...> - 2005-06-26 22:20:32
|
Hi Andrei, > Hi Thiago, I just noticed your email. Do you have > interest in the OCaml subproject ? [...] For now, I am mostly interested on the haskell subproject. But I don't discard working on the OCaml subproject on the future. > OT, but are you brazilian ? Yes, I am. I am from Recife. --- Thiago Arrais |