From: Leif F. <hi...@le...> - 2007-11-19 21:08:21
|
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 |
From: Andrew U. F. <fr...@ge...> - 2007-11-20 11:02:17
|
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 |
From: Andrew U. F. <fr...@ge...> - 2007-11-26 09:01:23
|
dear leiff it is really a pitty that the (minor) differences between EPL and GPL etc are causing as much difficulties and separation as we had before when companies worked together... i realized many years ago, that if a system is in a single language then it is much simpler (i had a PERQ computer, which was operating system up all in pascal - in 1982 - windows and mouse!) this must be even more true in a open source community: it makes it easier to contribute! kind regards - and thank you a lot for the tools! andrew On Tue, 2007-11-20 at 19:17 +0100, Leif Frenzel wrote: > Hi Andrew, > > Thanks for your feedback :-) > > > 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? > I'm much involved with the EclipseDarcs project myself, so I know quite > well what the situation is there ;-) Your colleague is right, the Darcs > plugin is incomplete with covering the Darcs features, and some of the > missing ones are indispensable (e.g. records spanning multiple files), > so that working with Darcs currently means that you have to go to the > command line for certain tasks. However, there are also certain things > that work nicely in the IDE, so it is already a good addition, even > though it cannot yet completely replace the command line. > > The problem there is of course (as so often) lack of time :-) > > We (in the EclipseDarcs project) have also already thought about > directly integrating Darcs's Haskell code. That looks like an > interesting option to me technically; however, there is a license > problem: if we link directly to Darcs code (which is under GPL), we > would have to license our plugin under GPL or a compatible license. But > I'm personally opposed to licensing my code under GPL, and even if I > wasn't there would still be a problem, since the rest of Eclipse is > under the EPL, and that license is also considered incompatible with the > GPL (by the Eclipse Foundation). So either way, we would be in a > somewhat questionable situation. > > The most promising ways out of this would be that Darcs would provide an > API to link against under an EPL-compatible license (e.g. the LGPL), > which was discussed a while ago on the Darcs list, but I don't know what > came out of it, or for the Eclipse Foundation and the FSF to find a way > to iron out their differences and provide mutually compatible versions > of the EPL and the GPL. (But I'm no legally- or politically-minded > enough to know how likely that is ;-) > > From a technical point of view, what we currently do is to call the > Darcs executable, and that works mostly fine. So although it would be > fun to directly use the Haskell code, it would not really save us much > work. The effort-intensive things in EclipseDarcs that would have to be > done are more on the UI side. It's all doable, but it's quite a bit of > work, so it's not really on my radar at the moment :-) > > Thanks && ciao, > Leif > > > > > 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 > > > > > > ------------------------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------------------------- > 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 |
From: Leif F. <hi...@le...> - 2007-11-20 18:17:22
|
Hi Andrew, Thanks for your feedback :-) > 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? I'm much involved with the EclipseDarcs project myself, so I know quite well what the situation is there ;-) Your colleague is right, the Darcs plugin is incomplete with covering the Darcs features, and some of the missing ones are indispensable (e.g. records spanning multiple files), so that working with Darcs currently means that you have to go to the command line for certain tasks. However, there are also certain things that work nicely in the IDE, so it is already a good addition, even though it cannot yet completely replace the command line. The problem there is of course (as so often) lack of time :-) We (in the EclipseDarcs project) have also already thought about directly integrating Darcs's Haskell code. That looks like an interesting option to me technically; however, there is a license problem: if we link directly to Darcs code (which is under GPL), we would have to license our plugin under GPL or a compatible license. But I'm personally opposed to licensing my code under GPL, and even if I wasn't there would still be a problem, since the rest of Eclipse is under the EPL, and that license is also considered incompatible with the GPL (by the Eclipse Foundation). So either way, we would be in a somewhat questionable situation. The most promising ways out of this would be that Darcs would provide an API to link against under an EPL-compatible license (e.g. the LGPL), which was discussed a while ago on the Darcs list, but I don't know what came out of it, or for the Eclipse Foundation and the FSF to find a way to iron out their differences and provide mutually compatible versions of the EPL and the GPL. (But I'm no legally- or politically-minded enough to know how likely that is ;-) From a technical point of view, what we currently do is to call the Darcs executable, and that works mostly fine. So although it would be fun to directly use the Haskell code, it would not really save us much work. The effort-intensive things in EclipseDarcs that would have to be done are more on the UI side. It's all doable, but it's quite a bit of work, so it's not really on my radar at the moment :-) Thanks && ciao, Leif > > 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 > > > ------------------------------------------------------------------------- > 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 > |
From: Leif F. <hi...@le...> - 2007-11-23 20:40:40
|
Hi everybody, I have now created the first milestone build from the experimental EclipseFP 2 branch. This is consequentially version 1.101, and can be found on the sf file releases page for EclipseFP and on the EclipseFP download page. I have decided not to package Eclipse itself, because that would be unreasonably big, but apart from that, everything is in, so you can just unzip into an Eclipse installation and start right away. The most notable new features are of course the Mark Occurrences in the Editor, and the Pointfree refactoring support. For the moment, this is Windows-only, since there are no working Cohatoe builds for Mac and Linux at the moment (but that will change the moment my new MacBook arrives ;-). You also need a GHC 6.4.2 installation on your machine. Have fun :-) Thanks && ciao, Leif |
From: Andrew U. F. <fr...@ge...> - 2007-11-26 09:01:23
|
dear leiff, thank you for your work - i look forward to see a linux built to try it out! andrew ps. could you be more specific in the explanation how to install it (if it is not the ordinary eclipse plug-in method).. unzip into an eclipse installation is not clear to me (revealing my ignorance). On Fri, 2007-11-23 at 21:41 +0100, Leif Frenzel wrote: > Hi everybody, > > I have now created the first milestone build from the experimental > EclipseFP 2 branch. This is consequentially version 1.101, and can be > found on the sf file releases page for EclipseFP and on the EclipseFP > download page. > > I have decided not to package Eclipse itself, because that would be > unreasonably big, but apart from that, everything is in, so you can just > unzip into an Eclipse installation and start right away. > > The most notable new features are of course the Mark Occurrences in the > Editor, and the Pointfree refactoring support. > > For the moment, this is Windows-only, since there are no working Cohatoe > builds for Mac and Linux at the moment (but that will change the moment > my new MacBook arrives ;-). You also need a GHC 6.4.2 installation on > your machine. > > Have fun :-) > > Thanks && 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 |
From: Leif F. <hi...@le...> - 2007-11-26 21:16:28
|
Hi Andrew, > dear leiff, > thank you for your work - i look forward to see a linux built to try it > out! Me too :-) Currently I'm on an old Windows PC that's just only working... > ps. could you be more specific in the explanation how to install it (if > it is not the ordinary eclipse plug-in method).. unzip into an eclipse > installation is not clear to me (revealing my ignorance). Normally, an Eclipse installation has a root folder called eclipse/ and some subfolders, including plugins/, features/ and configuration/, where the plugins all reside. In the old times, one would 'install' by just extracting a zip archive which contained that plugins/-and-features/ folder structure into the eclipse/ folder, restarted eclipse and was done. Nowadays the other method (via the Update UI) is recommended, but the old method still works, provided one starts eclipse once with the command line option -clean after one has extracted stuff into it. Now that I realize that you are on Linux, however, I have to say that things may be arranged somewhat differently there, depending on what distribution you use. For what I do (packaging eclipsefp with a few other plugins, including cohatoe), I found it most easy to just package all together into a tar.gz. So the easiest way to install would be to simply extract an Eclipse Platform archive into a folder and then extract the one-stop-download into the subfolder eclipse/ of that same folder. My original plan was to make it even simpler and just bundle everything, including Eclipse itself, so that one really would have to just download and unzip. But the files are too big, I don't think sf would like that :-) Thanks && ciao, Leif > On Fri, 2007-11-23 at 21:41 +0100, Leif Frenzel wrote: >> Hi everybody, >> >> I have now created the first milestone build from the experimental >> EclipseFP 2 branch. This is consequentially version 1.101, and can be >> found on the sf file releases page for EclipseFP and on the EclipseFP >> download page. >> >> I have decided not to package Eclipse itself, because that would be >> unreasonably big, but apart from that, everything is in, so you can just >> unzip into an Eclipse installation and start right away. >> >> The most notable new features are of course the Mark Occurrences in the >> Editor, and the Pointfree refactoring support. >> >> For the moment, this is Windows-only, since there are no working Cohatoe >> builds for Mac and Linux at the moment (but that will change the moment >> my new MacBook arrives ;-). You also need a GHC 6.4.2 installation on >> your machine. >> >> Have fun :-) >> >> Thanks && 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 > > > ------------------------------------------------------------------------- > 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 > |
From: Leif F. <hi...@le...> - 2007-11-26 21:27:36
|
Andrew U. Frank wrote: > dear leiff > > it is really a pitty that the (minor) differences between EPL and GPL > etc are causing as much difficulties and separation as we had before > when companies worked together... Though one has to say that mostly the open source world functions even in spite of that :-) > > i realized many years ago, that if a system is in a single language then > it is much simpler (i had a PERQ computer, which was operating system up > all in pascal - in 1982 - windows and mouse!) Cool :-) > this must be even more true in a open source community: it makes it > easier to contribute! It does; however, there are situations where this actually leads to an unhappy state. I have been thinking about a related topic recently, in the context of Eclipse-based IDEs - they tend to be written fully in Java, even when they are actually for a completely different language. That way, they are based on Eclipse, which gives them a lot for free, but it excludes the original language's community. And curiously people don't seem to think that's strange ... If you are interested in the topic, you may want to check out these: http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html http://www.eclipse.org/newsportal/article.php?id=50&group=eclipse.technology.imp#50 Thanks && ciao, Leif > > kind regards - and thank you a lot for the tools! > > andrew > > > On Tue, 2007-11-20 at 19:17 +0100, Leif Frenzel wrote: >> Hi Andrew, >> >> Thanks for your feedback :-) >> >>> 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? >> I'm much involved with the EclipseDarcs project myself, so I know quite >> well what the situation is there ;-) Your colleague is right, the Darcs >> plugin is incomplete with covering the Darcs features, and some of the >> missing ones are indispensable (e.g. records spanning multiple files), >> so that working with Darcs currently means that you have to go to the >> command line for certain tasks. However, there are also certain things >> that work nicely in the IDE, so it is already a good addition, even >> though it cannot yet completely replace the command line. >> >> The problem there is of course (as so often) lack of time :-) >> >> We (in the EclipseDarcs project) have also already thought about >> directly integrating Darcs's Haskell code. That looks like an >> interesting option to me technically; however, there is a license >> problem: if we link directly to Darcs code (which is under GPL), we >> would have to license our plugin under GPL or a compatible license. But >> I'm personally opposed to licensing my code under GPL, and even if I >> wasn't there would still be a problem, since the rest of Eclipse is >> under the EPL, and that license is also considered incompatible with the >> GPL (by the Eclipse Foundation). So either way, we would be in a >> somewhat questionable situation. >> >> The most promising ways out of this would be that Darcs would provide an >> API to link against under an EPL-compatible license (e.g. the LGPL), >> which was discussed a while ago on the Darcs list, but I don't know what >> came out of it, or for the Eclipse Foundation and the FSF to find a way >> to iron out their differences and provide mutually compatible versions >> of the EPL and the GPL. (But I'm no legally- or politically-minded >> enough to know how likely that is ;-) >> >> From a technical point of view, what we currently do is to call the >> Darcs executable, and that works mostly fine. So although it would be >> fun to directly use the Haskell code, it would not really save us much >> work. The effort-intensive things in EclipseDarcs that would have to be >> done are more on the UI side. It's all doable, but it's quite a bit of >> work, so it's not really on my radar at the moment :-) >> >> Thanks && ciao, >> Leif >> >>> 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 >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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 > |
From: Andrew U. F. <fr...@ge...> - 2007-11-27 13:20:50
|
thanks for the pointer - you explain very correctly what i experience, eventhough in 1982 the tools were minuscule, but the intellectual investment is major (most people know only one language and some one programming languge - polyglots are rare!) thank you! andrew On Mon, 2007-11-26 at 22:28 +0100, Leif Frenzel wrote: > Andrew U. Frank wrote: > > dear leiff > > > > it is really a pitty that the (minor) differences between EPL and GPL > > etc are causing as much difficulties and separation as we had before > > when companies worked together... > Though one has to say that mostly the open source world functions even > in spite of that :-) > > > > > i realized many years ago, that if a system is in a single language then > > it is much simpler (i had a PERQ computer, which was operating system up > > all in pascal - in 1982 - windows and mouse!) > Cool :-) > > > this must be even more true in a open source community: it makes it > > easier to contribute! > It does; however, there are situations where this actually leads to an > unhappy state. I have been thinking about a related topic recently, in > the context of Eclipse-based IDEs - they tend to be written fully in > Java, even when they are actually for a completely different language. > That way, they are based on Eclipse, which gives them a lot for free, > but it excludes the original language's community. And curiously people > don't seem to think that's strange ... > > If you are interested in the topic, you may want to check out these: > > http://cohatoe.blogspot.com/2007/09/some-reflections-on-eclipse-based.html > http://www.eclipse.org/newsportal/article.php?id=50&group=eclipse.technology.imp#50 > > Thanks && ciao, > Leif > > > > > kind regards - and thank you a lot for the tools! > > > > andrew > > > > > > On Tue, 2007-11-20 at 19:17 +0100, Leif Frenzel wrote: > >> Hi Andrew, > >> > >> Thanks for your feedback :-) > >> > >>> 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? > >> I'm much involved with the EclipseDarcs project myself, so I know quite > >> well what the situation is there ;-) Your colleague is right, the Darcs > >> plugin is incomplete with covering the Darcs features, and some of the > >> missing ones are indispensable (e.g. records spanning multiple files), > >> so that working with Darcs currently means that you have to go to the > >> command line for certain tasks. However, there are also certain things > >> that work nicely in the IDE, so it is already a good addition, even > >> though it cannot yet completely replace the command line. > >> > >> The problem there is of course (as so often) lack of time :-) > >> > >> We (in the EclipseDarcs project) have also already thought about > >> directly integrating Darcs's Haskell code. That looks like an > >> interesting option to me technically; however, there is a license > >> problem: if we link directly to Darcs code (which is under GPL), we > >> would have to license our plugin under GPL or a compatible license. But > >> I'm personally opposed to licensing my code under GPL, and even if I > >> wasn't there would still be a problem, since the rest of Eclipse is > >> under the EPL, and that license is also considered incompatible with the > >> GPL (by the Eclipse Foundation). So either way, we would be in a > >> somewhat questionable situation. > >> > >> The most promising ways out of this would be that Darcs would provide an > >> API to link against under an EPL-compatible license (e.g. the LGPL), > >> which was discussed a while ago on the Darcs list, but I don't know what > >> came out of it, or for the Eclipse Foundation and the FSF to find a way > >> to iron out their differences and provide mutually compatible versions > >> of the EPL and the GPL. (But I'm no legally- or politically-minded > >> enough to know how likely that is ;-) > >> > >> From a technical point of view, what we currently do is to call the > >> Darcs executable, and that works mostly fine. So although it would be > >> fun to directly use the Haskell code, it would not really save us much > >> work. The effort-intensive things in EclipseDarcs that would have to be > >> done are more on the UI side. It's all doable, but it's quite a bit of > >> work, so it's not really on my radar at the moment :-) > >> > >> Thanks && ciao, > >> Leif > >> > >>> 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 > >>> > >>> ------------------------------------------------------------------------- > >>> 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 > >>> > >> > >> ------------------------------------------------------------------------- > >> 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 > > > > > > ------------------------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------------------------- > 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 |