Re: [eclipsefp-develop] EclipseFP reloaded

[Andrew U. F. <fr...@ge...>]

dear leiff

we are still using eclipse + fp nearly continously (mostly my team...)
and i am pleased to read your intentions. i think in principle the idea
to be able to write in haskell what should help with writing haskell
makes things easier. and perhaps it gets easy enough that i can do the
things i see necessary immediately myself...

an idea in the same veine: we have tried to use darcs with eclipse
(0.3.0) and found that not all is implemented. (a new colleague did
this, so i am not certain how necessary the additional parts are). i
thought it might be useful for the darcs extension of eclipse to use
cohatoe...i guess you must have already thought of this? did you contact
the darcs eclipse team? what are the reactions?

kind regards
and keep up the good work! 
thank you

andrew

On Mon, 2007-11-19 at 22:08 +0100, Leif Frenzel wrote:
> Hi everybody,
> 
> EclipseFP has gone though a somewhat quiet patch lately, at least if
> you look at actual delivery of working features. However, I'm more than
> convinced that we have actually made tremendous progress, and that this
> will be very clearly visible soon. I still think that, as things
> currently stand, a Haskell IDE has to build on an existing framework
> such as Eclipse, and I think we have solved one main issue that such
> an approach necessarily has: we are now able to integrate native
> Haskell code where we like and with the granularity we need. From a
> technical point of view, we are ready to get really going now. From
> here, it's just a matter of doing it (and having fun along the way :-).
> 
> I have thought about what the next steps could look like, and I've
> come up with this list:
> 
> 
> Get things implemented in Haskell
> 
> I have created a new EclipseFP branch as an experimentation area for
> possible ways to adopt Cohatoe, i.e. implement language-specific stuff
> in Haskell. In particular, for the first steps I'm looking for
> 
> - small parts of EclipseFP that could be broken out and (partially) be
>    re-implemented in Haskell,
> - ideas for extensions to the current functionality that are small in
>    size and can easily be hooked in.
> 
> In this branch, I will try to work towards a version of EclipseFP that
> uses Cohatoe to shift as much functionality as possible to the Haskell
> side, without losing re-use options from the Eclipse platform. I am
> currently collecting a list of ideas and will post it soon. Any
> suggestions are very welcome :-)
> 
> Since this is an experimental branch, it is not clear how long it will
> take to make it even usable. So this will definitely not replace the
> current EclipseFP version anytime soon. Moreover, there are some
> features that are likely to work on both a new, Cohatoe-based EclipseFP
> and the current state. (E.g. GHCi debugger integration, which would
> have to be implemented so that it runs GHCi in an external process and
> just connects it to the Eclipse Debugger UI - there is not much need
> for Cohatoe there, as far as I can see at the moment.) So I think it
> makes sense to keep the main branch around; and I definitely think we
> should consider to release the current state as a new milestone, since
> it has a number of fixes that might be helpful to people.
> 
> Here's the branch repo URL:
> 
> http://eclipsefp.sf.net/repos/eclipsefp/branches/eclipsefp2
> 
> (and it is of course recommended to use 'darcs get --partial' :-)
> 
> 
> Versions
> 
> Our EclipseFP development stream has used 0.x versions so far, with the
> goal to reach version 1.0. Taking this into account and
> allowing for a (theoretical) final 1.0 build and possibly 1.0.x and 1.x
> maintenance builds, I suggest to call the experimental branch
> EclipseFP 2 branch and use version numbers from a floor of 1.100, i.e.
> 1.100, 1.101 etc. with the goal of course to reach a 2.0 release at
> some point :-).
> 
> 
> Eat your own dog food
> 
> We should be able to use EclipseFP for working on EclipseFP, so one of
> the first priorities should be to make it dead easy to create and
> modify Eclipse plugins that are partially implemented in Haskell. I've
> already mostly implemented what I think is needed on the Cohatoe SDK
> side (Cohatoe plugin projects, which play the same role as PDE projects
> play for 'normal' plugins); the next steps can now happen on the
> EclipseFP side.
> 
> I also think we should have a hacking guide that describes what stuff
> you need to get started with hacking EclipseFP. That's currently a
> long list, and it's definitely too complicated for potential
> contributors to figure out :-(
> 
> 
> Regular integration builds
> 
> There should be a latest milestone build that you can just download and
> start using for development. It should contain all the latest stuff,
> including experimental features, so it is not for general consumption
> (for this we release more stable release builds). But nobody should
> have to wait long until a fix he needs gets into the development stream.
> 
> For this, I'd like to re-activate the regular builds that Thiago has
> installed and let them run for the experimental branch (in addition to
> the other branches). Things have become more complicated here with
> Eclipse 3.3, and it will probably also become a little more difficult
> when we have to accommodate native Haskell code for different platforms.
> 
> We should also have a very convenient one-stop download for people who
> really just want to get it, unzip it, and use it (and hopefully send
> bug reports). We should make this a high-priority service for our
> users, especially those who are willing to put up with buggy early
> release code for the benefit of having their requests fulfilled. These
> people are giving us a chance, we should give them something back.
> 
> My idea there would be to really pack up everything, including Eclipse
> and all prerequisites (except JRE and GHC). I think that would make it
> considerably easier for people to use it, especially for the SDK packet
> (which would include the Eclipse SDK, Cohatoe SDK, EclipseFP,
> EclipseDarcs, CheckStyle etc.). I'm somewhat uneasy, though, about the
> file sizes (40 MB and 150 MB, resp.). I think this would need to go
> via the sf file releases. (Although that complicates uploading them.)
> 
> I am currently preparing the first set of builds after this manner, and
> I'm curious to hear feedback if that will help to use EclipseFP.
> 
> 
> Tracker
> 
> I have in the past weeks had a look at our trackers, which have a few
> orphaned bug reports and feature requests. Some of them are fixed or
> implemented meanwhile, some of them are still valid.
> 
> For the EclipseFP 2 branch, I have created an extra tracker which I use 
> for structuring my work. Its called 'Backlog', and you will find that it
> makes no difference between work items, features, bugs, and pure 
> placeholder items for some rather foggy ideas :-) You will see from it,
> however, what I have put onto my agenda for the next few versions, and
> you are invited to post any bug reports or feature requests you like
> there. (But note that their scope can then be only in the experimental
> branch.)
> 
> I will soon also scan the items in the two other trackers, so if you
> have already posted a feature request there, you don't have to transfer
> it to the Backlog tracker. I'll do that and notify you on the old
> tracker when I've done it :-)
> 
> Thanks for being so patient, both in staying with EclipseFP and with
> this email :-)) Any comments and suggestions are most welcome.
> 
> Ciao,
> Leif
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> eclipsefp-develop mailing list
> ecl...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop