Re: [eclipsefp-develop] GSoC, scion, EclipseFP

[Thomas S. <nom...@go...>]

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.