Haskell support for Eclipse

Leif Frenzel wrote:

> Hi everybody,
>
> I have started to do some cleaning up in the code and I realized that 
> I would like to switch to developing against both Java 5 and Eclipse 3.2.
>
> My main reason for that is the range of improvements there that help 
> with coding. In general, I would like to use generics instead of raw 
> types, @overrides annotations, enhanced for loops, possibly enums. 
> (I'd rather avoid autoboxing, ellipsis and other things that obscure 
> the code, though.) With Eclipse 3.2, these things are better supported 
> than with Eclipse 3.1.x, and in addition there is a lot of improvement 
> in PDE, too (like Manifest validation etc.). In general, there are a 
> number of additional safety belts and coding aids there, and I would 
> like to use them.
>
> As I have seen in Thiago's parser code, there is a dependency to Java 
> 5 there already. Eclipse 3.2 APIs are going to freeze this month, and 
> the 3.2 release itself will be in June. Java 5 is around for about 1 
> 1/2 years. So it seems reasonable to do the switch now.
>
> However, I am aware that there are people working in environments 
> where Java 5 support may not be available or where getting always the 
> latest milestone of Eclipse (approx. every six weeks) is a hassle, so 
> if anybody thinks this would be a problem, please say so :-) We can 
> have a closer look then and see what would be involved in maintaining 
> backwards compatibility.
>
> Thanks && ciao,
> Leif

Hi Leif and Thiago

Congratulations for all the work you have done on Haskell/Eclipse !

Personnaly I use Eclipse 3.2M4 and Java 5.
Java 5 is really a great progress over 1.4, thanks to 'generics'. I've 
modified a lot of code (written by others) to use this feature.

As for Eclipse 3.2M4, it works very well - I never had any problem up to 
now.

Thanks again,
Alain

Leif,

2006/1/8, Leif Frenzel <himself@...>:
> As I have seen in Thiago's parser code, there is a dependency to Java 5
> there already. Eclipse 3.2 APIs are going to freeze this month, and the
> 3.2 release itself will be in June. Java 5 is around for about 1 1/2
> years. So it seems reasonable to do the switch now.

In my opinion, the JVM version-switch is already safe to do. As you
said, it is already 1,5 years since the official release and I use it
for some time now and haven't gone in any huge trouble with it. But
I'd rather wait to go for Eclipse 3.2, since it didn't reach release
stage yet. I know it is pretty much stable by now and everything, but
I don't think we should make our users switch to the
not-yet-fully-stable version of the platform.

Indeed, the switch will be important in the future and I think we
should support Eclipse Platform 3.2 as soon as it gets released. But
we should be careful to not drop support on 3.1.1 yet. Maybe we can go
supporting both platforms until June, at least this is what I am
trying to do with everything I write. I am sure I am not the best
qualified person to say that, but I don't think there are any changes
between 3.1.1 and 3.2 that will make supporting both versions
prohibitively unmanageable. After the API freeze this becomes an even
smaller issue, in my humble opinion.

Maybe we could setup some automatic building and testing to help us
there. I'll take a look at the SF Compile Farm to see what it can do
for us.

Of course we could use 3.2 to write the code, but we should not take
the platform dependence to the end-user.

Just my 2 cents,

Thiago Arrais

> In my opinion, the JVM version-switch is already safe to do. As you
> said, it is already 1,5 years since the official release and I use it
> for some time now and haven't gone in any huge trouble with it.=20
Jupp, I'm not so much concerned with stability, but rather with=20
availability. There may be people working in environments that don't=20
have a reliable Java 5 support yet. (Btw: if anybody uses FreeBSD, what=20
is the state of Java 5 support there?)

 >But
> I'd rather wait to go for Eclipse 3.2, since it didn't reach release
> stage yet. I know it is pretty much stable by now and everything, but
> I don't think we should make our users switch to the
> not-yet-fully-stable version of the platform.
>=20
> Indeed, the switch will be important in the future and I think we
> should support Eclipse Platform 3.2 as soon as it gets released. But
> we should be careful to not drop support on 3.1.1 yet. Maybe we can go
> supporting both platforms until June, at least this is what I am
> trying to do with everything I write. I am sure I am not the best
> qualified person to say that, but I don't think there are any changes
> between 3.1.1 and 3.2 that will make supporting both versions
> prohibitively unmanageable. After the API freeze this becomes an even
> smaller issue, in my humble opinion.
>=20
> Maybe we could setup some automatic building and testing to help us
> there. I'll take a look at the SF Compile Farm to see what it can do
> for us.
>=20
> Of course we could use 3.2 to write the code, but we should not take
> the platform dependence to the end-user.
Well, I agree to a certain degree. The most important thing for me is to=20
code with the 3.2 JDT/PDE (because of the improved coding support).

But there is a couple of issues there (I have been constantly using the=20
latest milestones against the last releases in customer projects, and my=20
experience was mixed with such a scenario). Especially if some=20
developers use 3.1.x and some use 3.2, the compiler settings files etc.=20
are constantly screwed up. So the price for maintaining a version that=20
runs on both version is considerable, even with automated testing=20
against both versions.

The thing is: the milestones are called 'Stable builds' (as compared to=20
release builds) and they actually are very stable. Sometimes they may=20
have nasty little bugs, but I have never seen one that prevented me from=20
working with it. Therefore, most developers that I know use the 3.2=20
milestones. Companies that build upon the platform normally go with the=20
releases, because of the API stability (API changes throughout the cycle=20
require adjustments every time, so they'd rather do this only once a=20
year after the final release.) But developers would rather have all the=20
new features earlier. So that's the reason I'm asking around: if anybody=20
works on 3.1 anymore and would have to go through a major hassle, I'd go=20
the extra mile and keep compatibility. But if everybody is gladly=20
hacking away with 3.2 anyway, then why bother with the old stuff? :-)

Ciao,
Leif

>=20
> Just my 2 cents,
>=20
> Thiago Arrais
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk
> _______________________________________________
> eclipsefp-develop mailing list
> eclipsefp-develop@...
> https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop
>=20
>=20

2006/1/9, Leif Frenzel <himself@...>:
> Jupp, I'm not so much concerned with stability, but rather with
> availability. There may be people working in environments that don't
> have a reliable Java 5 support yet.

That is another important issue, I think we should prepare to reach
the most large number of users (that was indeed one of the main
concerns for writing the parser code in Java). Does anybody know of
any other platform (that we should support and) in which Java 5 isn't
yet fully supported?

> (Btw: if anybody uses FreeBSD, what
> is the state of Java 5 support there?)

It would be a very good idea to ask that on a Java or FreeBSD
discussion group. But I would bet that after 1,5 year it is already
stable. I could be wrong, of course.

> Well, I agree to a certain degree. The most important thing for me is to
> code with the 3.2 JDT/PDE (because of the improved coding support).
>
> But there is a couple of issues there (I have been constantly using the
> latest milestones against the last releases in customer projects, and my
> experience was mixed with such a scenario). Especially if some
> developers use 3.1.x and some use 3.2, the compiler settings files etc.
> are constantly screwed up.

I have happened to see that, and it is not very nice to deal with
those issues (although not impossible).

There are two issues here. The first is the choice among our users to
have a mix of Eclipse platforms on their environment. The second is
_our_ decision to use different platforms. I think the second issue is
very easy to solve, we just need to agree on a platform version for us
to use on the development of EclipseFP. The first one is a slightly
more difficult issue, maybe we should warn our users (somewhere on our
website) that there are such compatibility issues and to advise them
to choose a unique platform to work with.

I would agree that we can switch our environment to 3.2 already (I am
actually already doing it to some extent).

> The thing is: the milestones are called 'Stable builds' (as compared to
> release builds) and they actually are very stable. Sometimes they may
> have nasty little bugs, but I have never seen one that prevented me from
> working with it. Therefore, most developers that I know use the 3.2
> milestones. Companies that build upon the platform normally go with the
> releases, because of the API stability (API changes throughout the cycle
> require adjustments every time, so they'd rather do this only once a
> year after the final release.) But developers would rather have all the
> new features earlier. So that's the reason I'm asking around: if anybody
> works on 3.1 anymore and would have to go through a major hassle, I'd go
> the extra mile and keep compatibility. But if everybody is gladly
> hacking away with 3.2 anyway, then why bother with the old stuff? :-)

Very well said. But I am concerned with new users we might get too.
Maybe a new Eclipse adopter (we can even think of someone that
downloaded Eclipse just in order to use FP) won't be as open to using
a development version of the platform as the old-timers (that know
that _those_ particular version are _indeed_ very stable). Eclipse.org
itself encourages newcomers to download and install the latest
release. The downloads page has a huge link for platform 3.1.1 and a
tiny link to 3.2M4. The 3.1.1 version is in fact the most downloaded
package.

Maybe I am underestimating, but I don't think maintaining backwards
compatibility will be a big issue. I think we can get going until June
2006.

Cheers,

Thiago Arrais

>> (Btw: if anybody uses FreeBSD, what
>> is the state of Java 5 support there?)
>>     
>
> It would be a very good idea to ask that on a Java or FreeBSD
> discussion group. But I would bet that after 1,5 year it is already
> stable. I could be wrong, of course.
>   
With FreeBSD in particular there were licensing issues, I remember, when 
I looked at it half a year ago. I would be interested if someone 
actually uses Eclipse with Java 5 on FreeBSD. But that's just my 
curiosity, the main platforms that we target with eclipsefp are Windows, 
Linux and MacOS X.
>   
>> Well, I agree to a certain degree. The most important thing for me is to
>> code with the 3.2 JDT/PDE (because of the improved coding support).
>>
>> But there is a couple of issues there (I have been constantly using the
>> latest milestones against the last releases in customer projects, and my
>> experience was mixed with such a scenario). Especially if some
>> developers use 3.1.x and some use 3.2, the compiler settings files etc.
>> are constantly screwed up.
>>     
>
> I have happened to see that, and it is not very nice to deal with
> those issues (although not impossible).
>
> There are two issues here. The first is the choice among our users to
> have a mix of Eclipse platforms on their environment. The second is
> _our_ decision to use different platforms. I think the second issue is
> very easy to solve, we just need to agree on a platform version for us
> to use on the development of EclipseFP. The first one is a slightly
> more difficult issue, maybe we should warn our users (somewhere on our
> website) that there are such compatibility issues and to advise them
> to choose a unique platform to work with.
>
> I would agree that we can switch our environment to 3.2 already (I am
> actually already doing it to some extent).
>   
Yes, I'm doing that too. Then the proposal is:

For eclipsefp development:
- Eclipse 3.2 as development IDE,
- Eclipse 3.1.x as target platform (although with an eye on 3.2 
compatibility)
- Java 5 - code (i.e. generics allowed)

For eclipsefp users:
- Eclipse 3.1.x and Java 5 runtime, but
- Eclipse 3.2 and Java 5 runtime has also a good chance to work (see below).

>   
>> The thing is: the milestones are called 'Stable builds' (as compared to
>> release builds) and they actually are very stable. Sometimes they may
>> have nasty little bugs, but I have never seen one that prevented me from
>> working with it. Therefore, most developers that I know use the 3.2
>> milestones. Companies that build upon the platform normally go with the
>> releases, because of the API stability (API changes throughout the cycle
>> require adjustments every time, so they'd rather do this only once a
>> year after the final release.) But developers would rather have all the
>> new features earlier. So that's the reason I'm asking around: if anybody
>> works on 3.1 anymore and would have to go through a major hassle, I'd go
>> the extra mile and keep compatibility. But if everybody is gladly
>> hacking away with 3.2 anyway, then why bother with the old stuff? :-)
>>     
>
> Very well said. But I am concerned with new users we might get too.
> Maybe a new Eclipse adopter (we can even think of someone that
> downloaded Eclipse just in order to use FP) won't be as open to using
> a development version of the platform as the old-timers (that know
> that _those_ particular version are _indeed_ very stable). Eclipse.org
> itself encourages newcomers to download and install the latest
> release. The downloads page has a huge link for platform 3.1.1 and a
> tiny link to 3.2M4. The 3.1.1 version is in fact the most downloaded
> package.
>   
True indeed.

> Maybe I am underestimating, but I don't think maintaining backwards
> compatibility will be a big issue. I think we can get going until June
> 2006.
>
>   
Right. I'm not religious about that issue, and the point about newcoming 
users is valid. So let's say we do our best and try to support both 
versions, and should we get into a situation where we really break 
compatibility, then we can re-discuss :-)

Ciao,
Leif

2006/1/9, Leif Frenzel <lfrenzel@...>:
[...]
> Then the proposal is:
>
> For eclipsefp development:
> - Eclipse 3.2 as development IDE,
> - Eclipse 3.1.x as target platform (although with an eye on 3.2
> compatibility)
> - Java 5 - code (i.e. generics allowed)
>
> For eclipsefp users:
> - Eclipse 3.1.x and Java 5 runtime, but
> - Eclipse 3.2 and Java 5 runtime has also a good chance to work (see belo=
w).
[...]
> So let's say we do our best and try to support both
> versions, and should we get into a situation where we really break
> compatibility, then we can re-discuss :-)

Agreed. Let's get going.

Maybe we should modify the website after our tests to help clarify
that 3.2 is also supported, although 3.1.1 is currently the most
recommended version.

Also, I haven't said so, but I took the liberty to change the link
from the old downloads page to the new one. I thought it was stable
enough for publishing.

-- Thiago Arrais

Hi Alain,

>
> Congratulations for all the work you have done on Haskell/Eclipse !
:-))
>
>
> Personnaly I use Eclipse 3.2M4 and Java 5.
> Java 5 is really a great progress over 1.4, thanks to 'generics'. I've 
> modified a lot of code (written by others) to use this feature.
>
> As for Eclipse 3.2M4, it works very well - I never had any problem up 
> to now.
>
Great :-) That's 1:0 for Java 5.

Thanks for the feedback && ciao,
Leif

> Thanks again,
> Alain
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> eclipsefp-develop mailing list
> eclipsefp-develop@...
> https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop