From: Thomas t. C. <tte...@gm...> - 2009-03-25 02:59:06
|
Hello all, I'm trying to pull a Google Summer of Code project together in which I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the level of Visual Haskell, the Haskell plugin for Visual Studio. Currently, EclipseFP is usable, but not usable enough, and it does not offer all functionality that it could. This e-mail goes to Thomas Schilling, the dev of the IDE lib scion; to folks who seem to have been active in EclipseFP; to the eclipsefp-develop mailing list; and to everyone who signed up as prospective mentors on the Haskell wiki and have their e-mail address listed. There are several things I'm trying to work out. 1. It seems that scion is in usable shape, since an emacs frontend already exists. It also seems that interfacing with other languages is no problem because it uses some kind of client/server model. Am I right so far? 2. Would I need to send my proposal to the Eclipse project, or to the Haskell project? In other words, from which project would my mentor come? Most of my code would probably be Java code to interface with Eclipse; on the other hand, the Eclipse community is large, the plugin API is well documented, and what I'm doing on the Eclipse side should be fairly straightforward, but I am not an expert on Haskell, so a Haskell mentor would probably be of more use to me. 3. If we decide that I should send my proposal to the Haskell project, who from the Haskell project is willing and able be my mentor? 4. If we decide that I should send my proposal to the Eclipse project, who from the Eclipse project is willing and able to be my mentor? I couldn't find a list of Eclipse mentors, so I asked on #eclipse-soc. No response yet, but I wanted to get this e-mail out ASAP. This is why no Eclipse prospective mentors are receiving this e-mail (yet). Hope to get this ball rolling! Thanks, Thomas ten Cate (thomastc on freenode) |
From: Leif F. <hi...@le...> - 2009-03-25 10:06:19
|
Hi Thomas, > I'm trying to pull a Google Summer of Code project together in which > I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the > level of Visual Haskell, the Haskell plugin for Visual Studio. thanks for your mail and for the initiative. It's good to see that the interest in Haskell IDEs keeps growing :-) On EclipseFP, there hasn't been active work for a while (around a year), and as far as I know, there is currently no active development on the 'experimental' stream, i.e. the 1.10x builds, which was an attempt to support Eclipse plugins written partly in Haskell. > 2. Would I need to send my proposal to the Eclipse project, or to the > Haskell project? What you reflect in your questions is an old headache of mine too: writing a full Haskell IDE purely in Java is too much work and there are not enough people who'd want to do that (we would rather code in Haskell, of course ;-), but on the other hand, there is neither infrastructure nor really a great interest in the Eclipse community to support other languages (especially those which don't compile to Java bytecode) as implementation languages for Eclipse plugins. So the best way to go is in my experience to integrate as much functionality as possible that comes from existing Haskell tools. With these considerations in mind, and from my own experiences, you'll probably get more support from the Haskell community, including of course from the maintainers of the tools you'll want to integrate. So if you can find a mentor from haskell.org, that would probably be more beneficial for you and the project. > 4. If we decide that I should send my proposal to the Eclipse project, > who from the Eclipse project is willing and able to be my mentor? I > couldn't find a list of Eclipse mentors, so I asked on #eclipse-soc. > No response yet, but I wanted to get this e-mail out ASAP. This is why > no Eclipse prospective mentors are receiving this e-mail (yet). On the Eclipse side, you could try the SoC mailing list: https://dev.eclipse.org/mailman/listinfo/soc-dev One thing to consider though is that just exactly this week EclipseCon is taking place, so there might be a shortage of attention until next week. Hope this helps Thanks && ciao, Leif -- Leif Frenzel http://leiffrenzel.de http://cohatoe.blogspot.com |
From: Thomas t. C. <tte...@gm...> - 2009-03-25 15:20:40
|
Thanks Leif! Hello people on the Eclipse soc-dev list! Hello two new mentors who just appeared on the Haskell GSoC wiki! As explained below, I'm trying to pull together a GSoC project to work on EclipseFP, the Haskell plugin for Eclipse, which is what this e-mail thread is all about. Right now I'm wondering who would be my mentor, and whether he/she would be from Haskell or from Eclipse. If the choice is up to me, I think I'd prefer a Haskell mentor, because a) the coding on the Eclipse side should be straightforward, and the API is well documented, b) I know much more about Java than about Haskell, and c) the interest from the Haskell community in this project is probably larger than from the Eclipse community. On Wed, Mar 25, 2009 at 05:47, Leif Frenzel <hi...@le...> wrote: > Hi Thomas, > >> I'm trying to pull a Google Summer of Code project together in which >> I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the >> level of Visual Haskell, the Haskell plugin for Visual Studio. > thanks for your mail and for the initiative. It's good to see that the > interest in Haskell IDEs keeps growing :-) > > On EclipseFP, there hasn't been active work for a while (around a year), > and as far as I know, there is currently no active development on the > 'experimental' stream, i.e. the 1.10x builds, which was an attempt to > support Eclipse plugins written partly in Haskell. I figured. Could you tell me more about the reasoning behind this? Of course Haskell devs rather code in Haskell; but it seems like such a poor fit for Eclipse plugin development. >> 2. Would I need to send my proposal to the Eclipse project, or to the >> Haskell project? > [snip] So the best way to go is in my experience to > integrate as much functionality as possible that comes from existing > Haskell tools. [snip] Which is why I'd like to use scion for this. Hope that nominolo will chime in soon! The way it looks now, I'll send my proposal to the Haskell project, for the aforementioned reasons. Still, it would be great if somebody from Eclipse could also say clever things about all this! Thanks, Thomas |
From: Thomas t. C. <tte...@gm...> - 2009-03-25 16:58:30
|
On Wed, Mar 25, 2009 at 11:20, Thomas ten Cate <tte...@gm...> wrote: > The way it looks now, I'll send my proposal to the Haskell project, > for the aforementioned reasons. Still, it would be great if somebody > from Eclipse could also say clever things about all this! I have just put up a first draft of my project proposal at http://socghop.appspot.com/student_proposal/show/google/gsoc2009/thomastc/t123799996710 Any feedback will be greatly appreciated! Thanks, Thomas |
From: Leif F. <hi...@le...> - 2009-03-26 00:09:07
|
Hi Thomas, >> On EclipseFP, there hasn't been active work for a while (around a year), >> and as far as I know, there is currently no active development on the >> 'experimental' stream, i.e. the 1.10x builds, which was an attempt to >> support Eclipse plugins written partly in Haskell. > > I figured. Could you tell me more about the reasoning behind this? Of > course Haskell devs rather code in Haskell; but it seems like such a > poor fit for Eclipse plugin development. I've written a longish blog post some time ago about that: http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html The most 'interesting' functionality in an IDE such as JDT is for Java is the functionality that 'knows' about the language, i.e. things like Mark Occurrences, search for references, refactorings etc. These things go beyond language-neutral platform functionality and require analysis and/or manipulation of the source code. But such functionality is already implemented in Haskell for many purposes (HaRe, GHC API, ...). Re-implementing all this in Java (even if possible) would be quixotic, so it's an integration task. There are several options for this, which we all tried. (You can find more detail here, if you are interested: http://leiffrenzel.de/papers/icfp085-frenzel.pdf) Thanks && ciao, Leif > >>> 2. Would I need to send my proposal to the Eclipse project, or to the >>> Haskell project? >> [snip] So the best way to go is in my experience to >> integrate as much functionality as possible that comes from existing >> Haskell tools. [snip] > > Which is why I'd like to use scion for this. Hope that nominolo will > chime in soon! > > The way it looks now, I'll send my proposal to the Haskell project, > for the aforementioned reasons. Still, it would be great if somebody > from Eclipse could also say clever things about all this! > > Thanks, > > Thomas > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > -- Leif Frenzel http://leiffrenzel.eu http://cohatoe.blogspot.com |
From: Thomas t. C. <tte...@gm...> - 2009-03-26 23:55:29
|
Philippe, thanks for joining the discussion! On Thu, Mar 26, 2009 at 19:08, Philippe Ombredanne <pom...@ne...> wrote: > Co-mentoring can work nicely "behind the scenes" but you would need to pick > one org or the other as the official mentor. You can post your app to both > orgs though, ann you will pick one if you get accepted in both (please make > a note of that double post clearly in your application) > If you pick Haskell as an org and get accepted we will help you as if you > were an eclipse student for sure. Once my proposal is finalized, I'll port it to the Eclipse template as well, and send it to both projects like you suggested. > Also, one thing to consider is the DLTK project ( http://eclipse.org/dltk ) > which *could* be a nice base for Haskell, iff the EclipseFP code base is a > tad old and un-maintained. Someone could be interested to mentor you there. EclipseFP has only been standing still for a year or so, so I don't think it'll be much outdated. At least it seems to work with current Eclipse releases. Working from the current EclipseFP source will probably be much more efficient than starting pretty much from scratch. > Another possibility is in the context of E4, though the focus might be more > about using Haskell to *code* eclipse rather than coding Haskell in eclipse > there, and I reckon that some expereimentation hass been done already in > some branch. Yes, this is what Leif's Cohatoe ("COntributing HAskell TO Eclipse") project is all about. > Finally a good goal for such a project and beyond could be to bring > EclipseFP as an *official* Eclipse project after the Soc ... If that could be made to happen, it would be really great. Would also increase visibility for the project, attract developers and users alike. But let's see about that after I'm done hacking ;) nominolo: Usability is indeed important. This is part of the reason why I chose Eclipse in the first place. Concerning refactoring, if I get round to it (maybe after GSoC), here is an article that might be of help: http://www.eclipse.org/articles/Article-LTK/ltk.html Guess who wrote it :) The LTK could serve as a guide in deciding what functionality must be exposed by scion to make the refactoring happen. But let's not get ahead of ourselves. To my knowledge there is no haskell-soc mailing list. Since you offered to mentor me, I have removed the other potential mentors from the CC; so far I have not received a reply from them anyway. Thomas |
From: Johannes W. <wal...@im...> - 2009-03-27 08:40:24
Attachments:
signature.asc
|
Dear all, it's good to see some activity towards Eclipse/Haskell integration. I would love to use this for my own projects, and for teaching. (I have a huge pile of refactorings on my todo list that I don't dare to start because even conceptually simple things like renaming identifiers and moving them between modules are a nightmare with current (i.e., missing) tool support.) It is the Right Thing (TM) to aggressively re-use existing software (Cohatoe, GHC API, Scion, HaRe (later)). In particular, I want to emphasize Leif's statement that the goal is to do all the semantics processing with tools written in Haskell (not Java). Because these tools will be written by Haskell programmers that maybe don't even know (or want to learn) Java. From past attempts at EclipseFP hacking I recall these questions: how deep is the notion of "Haskell module = file" built into GHC/API (and the tools based on it)? Because with Eclipse, the concept is, or should be, "edit buffer contents". What is the "state" model? As I recall, Cohatoe design is for stateless plugins. GHC API is stateful, or at least it has state objects (handles). These must be passed around and managed somehow. I think that's where you decide about single/multi-threadedness. (Ultimately, this session state should be attached to an eclipse project view, that is, switchable by the user?) Best regards, Johannes. |
From: Philippe O. <pom...@ne...> - 2009-03-27 15:37:30
|
Thomas ten Cate wrote: > To my knowledge there is no haskell-soc mailing list. Since you > offered to mentor me, I have removed the other potential mentors from > the CC; so far I have not received a reply from them anyway. So far I am *not* offering to mentor you, though that *could* be a possibility, just to set the record straight and keep your expectations in line. I am the co-admin for the program so that is my role and duty to reply to you and help you in any way I can... I am also an aspiring mentor for the program, though in all fairness I would not recognize-an-Haskell-in-full-day-light-if-it-was-in-my-face :D despite I love functional languages. Please continue your quest for mentors especially since you may be looking for a two different orgs. One post in reply to your email offers a potential mentor with DLTK. That is worth considering regardless of the state of the code base. -- Cordially Philippe philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com nexB - Open by Design (tm) - http://www.nexb.com http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com |
From: Thomas t. C. <tte...@gm...> - 2009-03-27 15:38:44
|
On Fri, Mar 27, 2009 at 11:20, Philippe Ombredanne <pom...@ne...> wrote: > Thomas ten Cate wrote: > > To my knowledge there is no haskell-soc mailing list. Since you >> >> offered to mentor me, I have removed the other potential mentors from >> the CC; so far I have not received a reply from them anyway. > > So far I am *not* offering to mentor you, though that *could* be a > possibility, just to set the record straight and keep your expectations in > line. > > I am the co-admin for the program so that is my role and duty to reply to > you and help you in any way I can... > I am also an aspiring mentor for the program, though in all fairness I would > not recognize-an-Haskell-in-full-day-light-if-it-was-in-my-face :D despite I > love functional languages. > > Please continue your quest for mentors especially since you may be looking > for a two different orgs. > > One post in reply to your email offers a potential mentor with DLTK. > That is worth considering regardless of the state of the code base. My "you" was aimed at nominolo, not at you, Philippe. I see now that the "nominolo:" prefix three paragraphs above that one was quite insufficient to make that clear. Sorry about the confusion. Could you (Philippe) shed some more light on the relevance of the DLTK project? Haskell is very much not a dynamic language, and although the stuff about languages in general still applies, I don't currently see how EclipseFP would fit into that project. Thanks, Thomas |
From: Thomas t. C. <tte...@gm...> - 2009-05-13 22:11:59
|
Thomas ten Cate <tte...@gm...> wrote: >>> I'm trying to pull a Google Summer of Code project together in which >>> I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the >>> level of Visual Haskell, the Haskell plugin for Visual Studio. Hi all, Well, apparently I have been accepted to work on this project for haskell.org! This does not necessarily mean that you are rid of me, though, since my project is as much Eclipse-related as it is Haskell-related. My shiny new blog contains more information and can be found at http://eclipsefp.wordpress.com/ I will post regular updates here about the project's progress. Cheers, Thomas |
From: Thomas S. <nom...@go...> - 2009-03-26 01:17:32
Attachments:
PGP.sig
|
Hi Thomas, I would be available as a mentor if you decided to do this project. I try to keep as much as possible on the Haskell side, since this (a) more comfortable to implement and (b) more reusable across different front ends. At the moment Scion does not much; it pretty much only implements GHCi's :load and :reload functionality and can load meta data from a .cabal file. Apart from that there's some pragma, flag and (external) module completion possible, but those are one-liners on the Haskell side. Since we compile to byte code anyway, I plan to also add some very basic GHCi-like support. A debugger UI would be nice at some point, type-of-thing at point is in the works. It'll be a bit more work to have working refactoring support. When working on Scion I noticed that much of my time was spent understanding or modifying GHC, though. I don't think this will change anytime soon. I've also been changing abstractions around; there's still a lot of design work to be done. Another front end would of course help to understand the requirements better. We also have the problem that the GHC API is practically single-threaded at the moment. That is, loading multiple projects at the same time, or even the same project in different configurations, cannot currently be done in the same process. Scion's model for Emacs and Vim (being worked on by Marc Weber) is to communicate through a socket or (coming soon) using stdin/stdout. Since writing parsers in Haskell is easier than in most other languages, we also try to use a serialisation that is easy to read by the client. I'm working on a scheme to have the protocol be independent of the serialisation method, so that a new client merely needs to define its wire protocol and the rest should Just Work (tm). (E.g., even JSON or XML for web clients should be doable.) I certainly think it's a very useful project to work on, especially if you decide to work on Scion, as it will then not only profit Eclipse users. I also believe that the project is quite well-defined and we can always find some more work if need be :) Thanks, On 25 Mar 2009, at 15:20, Thomas ten Cate wrote: > Thanks Leif! > > Hello people on the Eclipse soc-dev list! Hello two new mentors who > just appeared on the Haskell GSoC wiki! As explained below, I'm trying > to pull together a GSoC project to work on EclipseFP, the Haskell > plugin for Eclipse, which is what this e-mail thread is all about. > > Right now I'm wondering who would be my mentor, and whether he/she > would be from Haskell or from Eclipse. If the choice is up to me, I > think I'd prefer a Haskell mentor, because a) the coding on the > Eclipse side should be straightforward, and the API is well > documented, b) I know much more about Java than about Haskell, and c) > the interest from the Haskell community in this project is probably > larger than from the Eclipse community. > > On Wed, Mar 25, 2009 at 05:47, Leif Frenzel <hi...@le...> > wrote: >> Hi Thomas, >> >>> I'm trying to pull a Google Summer of Code project together in which >>> I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to >>> the >>> level of Visual Haskell, the Haskell plugin for Visual Studio. >> thanks for your mail and for the initiative. It's good to see that >> the >> interest in Haskell IDEs keeps growing :-) >> >> On EclipseFP, there hasn't been active work for a while (around a >> year), >> and as far as I know, there is currently no active development on the >> 'experimental' stream, i.e. the 1.10x builds, which was an attempt to >> support Eclipse plugins written partly in Haskell. > > I figured. Could you tell me more about the reasoning behind this? Of > course Haskell devs rather code in Haskell; but it seems like such a > poor fit for Eclipse plugin development. > >>> 2. Would I need to send my proposal to the Eclipse project, or to >>> the >>> Haskell project? >> [snip] So the best way to go is in my experience to >> integrate as much functionality as possible that comes from existing >> Haskell tools. [snip] > > Which is why I'd like to use scion for this. Hope that nominolo will > chime in soon! > > The way it looks now, I'll send my proposal to the Haskell project, > for the aforementioned reasons. Still, it would be great if somebody > from Eclipse could also say clever things about all this! > > Thanks, > > Thomas / Thomas -- Push the envelope. Watch it bend. |
From: Thomas t. C. <tte...@gm...> - 2009-03-26 15:02:50
|
Thank you, Leif, for the links. I had seen another PDF about this topic, possibly also written by you, but I can't find it anymore. This one has in Section 2 a nice list of things that should be considered for implementation in EclipseFP; since I won't be able to do them all, it will be a matter of prioritizing. I also had a look at the German PDF you linked to from your blog post. Does it say anything that the other one does not say? I can read German, but only slowly, and I cannot skim it. And thank you, thank you, thank you Thomas, for offering to be my mentor! I would definitely not mind to work on scion too, if that turns out to be necessary. In particular, I think a deserializer for the scion stream format, written in Java, should go into the scion project and not into EclipseFP, so that other Java-based projects can directly benefit from it. I just realized that you may not be able to read my project proposal on the GSoC site. So I put it up here: http://docs.google.com/Doc?id=dfmvb7sr_13fzdg5qhr It's just a draft, and I am especially unsure about the road map and milestones, because I do not yet have a good grasp of all the difficulties I'll encounter along the way. (For example, since scion groks Cabal, maybe I should add Cabal support first?) Could you maybe have a look at my roadmap and tell me whether it seems realistic? I get more excited about this project every day! It would be great if we can get it to work! Thanks! thomastc (I will use that name from now on to avoid confusion :)) On Wed, Mar 25, 2009 at 21:17, Thomas Schilling <nom...@go...> wrote: > Hi Thomas, > I would be available as a mentor if you decided to do this project. I try > to keep as much as possible on the Haskell side, since this (a) more > comfortable to implement and (b) more reusable across different front ends. > At the moment Scion does not much; it pretty much only implements GHCi's > :load and :reload functionality and can load meta data from a .cabal file. > Apart from that there's some pragma, flag and (external) module completion > possible, but those are one-liners on the Haskell side. > Since we compile to byte code anyway, I plan to also add some very basic > GHCi-like support. A debugger UI would be nice at some point, type-of-thing > at point is in the works. It'll be a bit more work to have working > refactoring support. > When working on Scion I noticed that much of my time was spent understanding > or modifying GHC, though. I don't think this will change anytime soon. > I've also been changing abstractions around; there's still a lot of design > work to be done. Another front end would of course help to understand the > requirements better. We also have the problem that the GHC API is > practically single-threaded at the moment. That is, loading multiple > projects at the same time, or even the same project in different > configurations, cannot currently be done in the same process. > Scion's model for Emacs and Vim (being worked on by Marc Weber) is to > communicate through a socket or (coming soon) using stdin/stdout. Since > writing parsers in Haskell is easier than in most other languages, we also > try to use a serialisation that is easy to read by the client. I'm working > on a scheme to have the protocol be independent of the serialisation method, > so that a new client merely needs to define its wire protocol and the rest > should Just Work (tm). (E.g., even JSON or XML for web clients should be > doable.) > I certainly think it's a very useful project to work on, especially if you > decide to work on Scion, as it will then not only profit Eclipse users. I > also believe that the project is quite well-defined and we can always find > some more work if need be :) > Thanks, > On 25 Mar 2009, at 15:20, Thomas ten Cate wrote: > > Thanks Leif! > > Hello people on the Eclipse soc-dev list! Hello two new mentors who > just appeared on the Haskell GSoC wiki! As explained below, I'm trying > to pull together a GSoC project to work on EclipseFP, the Haskell > plugin for Eclipse, which is what this e-mail thread is all about. > > Right now I'm wondering who would be my mentor, and whether he/she > would be from Haskell or from Eclipse. If the choice is up to me, I > think I'd prefer a Haskell mentor, because a) the coding on the > Eclipse side should be straightforward, and the API is well > documented, b) I know much more about Java than about Haskell, and c) > the interest from the Haskell community in this project is probably > larger than from the Eclipse community. > > On Wed, Mar 25, 2009 at 05:47, Leif Frenzel <hi...@le...> wrote: > > Hi Thomas, > > I'm trying to pull a Google Summer of Code project together in which > > I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the > > level of Visual Haskell, the Haskell plugin for Visual Studio. > > thanks for your mail and for the initiative. It's good to see that the > > interest in Haskell IDEs keeps growing :-) > > On EclipseFP, there hasn't been active work for a while (around a year), > > and as far as I know, there is currently no active development on the > > 'experimental' stream, i.e. the 1.10x builds, which was an attempt to > > support Eclipse plugins written partly in Haskell. > > I figured. Could you tell me more about the reasoning behind this? Of > course Haskell devs rather code in Haskell; but it seems like such a > poor fit for Eclipse plugin development. > > 2. Would I need to send my proposal to the Eclipse project, or to the > > Haskell project? > > [snip] So the best way to go is in my experience to > > integrate as much functionality as possible that comes from existing > > Haskell tools. [snip] > > Which is why I'd like to use scion for this. Hope that nominolo will > chime in soon! > > The way it looks now, I'll send my proposal to the Haskell project, > for the aforementioned reasons. Still, it would be great if somebody > from Eclipse could also say clever things about all this! > > Thanks, > > Thomas > > / Thomas > -- > Push the envelope. Watch it bend. > > > |
From: Thomas S. <nom...@go...> - 2009-03-26 19:23:44
Attachments:
PGP.sig
|
You can call me "nominolo", I chose it to be Google-unique (for better or worse.) The overall proposal looks good. The timeline looks reasonable as well--it's impossible to come up with something accurate at this point. I assume you are an Eclipse user and will remain so. That is needed in order to avoid bitrot. Having a working Eclipse plugin is also very important to reduce the entry barrier for newcomers. In fact, I would suggest that you concentrate on usability rather than features. E.g., it is more important that things are easy to install and reliable than having lots of fancy features. At least for now. Refactoring support is nice to have, but most likely well beyond the project. FWIW, there is an ongoing effort to interface Eclipse with the Erlang refactorer Wrangler which we might be able to reuse (at least partly). BTW, is there a haskell-gsoc2009 mailing list for students, so that we can cut down the CC list? On 26 Mar 2009, at 15:02, Thomas ten Cate wrote: > Thank you, Leif, for the links. I had seen another PDF about this > topic, possibly also written by you, but I can't find it anymore. This > one has in Section 2 a nice list of things that should be considered > for implementation in EclipseFP; since I won't be able to do them all, > it will be a matter of prioritizing. > > I also had a look at the German PDF you linked to from your blog post. > Does it say anything that the other one does not say? I can read > German, but only slowly, and I cannot skim it. > > And thank you, thank you, thank you Thomas, for offering to be my > mentor! I would definitely not mind to work on scion too, if that > turns out to be necessary. In particular, I think a deserializer for > the scion stream format, written in Java, should go into the scion > project and not into EclipseFP, so that other Java-based projects can > directly benefit from it. > > I just realized that you may not be able to read my project proposal > on the GSoC site. So I put it up here: > http://docs.google.com/Doc?id=dfmvb7sr_13fzdg5qhr > It's just a draft, and I am especially unsure about the road map and > milestones, because I do not yet have a good grasp of all the > difficulties I'll encounter along the way. (For example, since scion > groks Cabal, maybe I should add Cabal support first?) Could you maybe > have a look at my roadmap and tell me whether it seems realistic? > > I get more excited about this project every day! It would be great if > we can get it to work! > > Thanks! > > thomastc (I will use that name from now on to avoid confusion :)) > > On Wed, Mar 25, 2009 at 21:17, Thomas Schilling <nom...@go... > > wrote: >> Hi Thomas, >> I would be available as a mentor if you decided to do this >> project. I try >> to keep as much as possible on the Haskell side, since this (a) more >> comfortable to implement and (b) more reusable across different >> front ends. >> At the moment Scion does not much; it pretty much only implements >> GHCi's >> :load and :reload functionality and can load meta data from >> a .cabal file. >> Apart from that there's some pragma, flag and (external) module >> completion >> possible, but those are one-liners on the Haskell side. >> Since we compile to byte code anyway, I plan to also add some very >> basic >> GHCi-like support. A debugger UI would be nice at some point, type- >> of-thing >> at point is in the works. It'll be a bit more work to have working >> refactoring support. >> When working on Scion I noticed that much of my time was spent >> understanding >> or modifying GHC, though. I don't think this will change anytime >> soon. >> I've also been changing abstractions around; there's still a lot >> of design >> work to be done. Another front end would of course help to >> understand the >> requirements better. We also have the problem that the GHC API is >> practically single-threaded at the moment. That is, loading multiple >> projects at the same time, or even the same project in different >> configurations, cannot currently be done in the same process. >> Scion's model for Emacs and Vim (being worked on by Marc Weber) is to >> communicate through a socket or (coming soon) using stdin/stdout. >> Since >> writing parsers in Haskell is easier than in most other languages, >> we also >> try to use a serialisation that is easy to read by the client. I'm >> working >> on a scheme to have the protocol be independent of the >> serialisation method, >> so that a new client merely needs to define its wire protocol and >> the rest >> should Just Work (tm). (E.g., even JSON or XML for web clients >> should be >> doable.) >> I certainly think it's a very useful project to work on, especially >> if you >> decide to work on Scion, as it will then not only profit Eclipse >> users. I >> also believe that the project is quite well-defined and we can >> always find >> some more work if need be :) >> Thanks, >> On 25 Mar 2009, at 15:20, Thomas ten Cate wrote: >> >> Thanks Leif! >> >> Hello people on the Eclipse soc-dev list! Hello two new mentors who >> just appeared on the Haskell GSoC wiki! As explained below, I'm >> trying >> to pull together a GSoC project to work on EclipseFP, the Haskell >> plugin for Eclipse, which is what this e-mail thread is all about. >> >> Right now I'm wondering who would be my mentor, and whether he/she >> would be from Haskell or from Eclipse. If the choice is up to me, I >> think I'd prefer a Haskell mentor, because a) the coding on the >> Eclipse side should be straightforward, and the API is well >> documented, b) I know much more about Java than about Haskell, and c) >> the interest from the Haskell community in this project is probably >> larger than from the Eclipse community. >> >> On Wed, Mar 25, 2009 at 05:47, Leif Frenzel >> <hi...@le...> wrote: >> >> Hi Thomas, >> >> I'm trying to pull a Google Summer of Code project together in which >> >> I'm hoping to bring EclipseFP, the Haskell plugin for Eclipse, to the >> >> level of Visual Haskell, the Haskell plugin for Visual Studio. >> >> thanks for your mail and for the initiative. It's good to see that >> the >> >> interest in Haskell IDEs keeps growing :-) >> >> On EclipseFP, there hasn't been active work for a while (around a >> year), >> >> and as far as I know, there is currently no active development on the >> >> 'experimental' stream, i.e. the 1.10x builds, which was an attempt to >> >> support Eclipse plugins written partly in Haskell. >> >> I figured. Could you tell me more about the reasoning behind this? Of >> course Haskell devs rather code in Haskell; but it seems like such a >> poor fit for Eclipse plugin development. >> >> 2. Would I need to send my proposal to the Eclipse project, or to the >> >> Haskell project? >> >> [snip] So the best way to go is in my experience to >> >> integrate as much functionality as possible that comes from existing >> >> Haskell tools. [snip] >> >> Which is why I'd like to use scion for this. Hope that nominolo will >> chime in soon! >> >> The way it looks now, I'll send my proposal to the Haskell project, >> for the aforementioned reasons. Still, it would be great if somebody >> from Eclipse could also say clever things about all this! >> >> Thanks, >> >> Thomas >> >> / Thomas >> -- >> Push the envelope. Watch it bend. >> >> >> / Thomas -- Push the envelope. Watch it bend. |