Right now this is more fiddly than it ought to be. Patches for improving the situation (better still, for preventing version mismatches from happening in the first place) would be most welcome. The most straightforward way of determining the variant is by looking at the update site URL which is installed along with the Scala tooling.

Navigate Window = Preferences = Install/Update = Available Software Sites, then look for the org.scala-ide.sdt.update-site entry. If the value in the corresponding location field is ' then you have the tooling for 3.5.x/Galileo installed. If on the other hand the value in the location field is ' then you have the tooling for 3.6.x/Helios installed.

That said, if you have the wrong version installed, it should be immediately obvious. Either way the Scala tooling will fail on startup and you'll see Scala source being interpreted as Java (ie. Errors reported in the editor view against Scala keywords etc.). This can be tested for with a trivial 'Hello world' project. Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin Miles Sabin, 5:29 น. What I saw was: And I also saw the '-35' form, which is not what I want. So I am removing all and trying again.

But clicking the clipboard-copier, I get not the -36. And I went through its install steps, and the -36 still did not appear. I will proceed, and see what appears, because I thought I did the previous one using these very same steps. Is the 'Scala IDE for Eclipse Source Feature' recommended or necessary for ordinary Scala users? I suspect it is not, but there is no readily apparent hint to indicate who is a likely customer of this (part of the) plugin.

Answer: apparently not necessary. Log of clean+build 8:56:50, clicked the 'go' button.

Either You Succeed Or Explain: Eclipse Galileo For Mac Download

8:57:05, build started. On Fri, Nov 12, 2010 at 2:53 PM, David Chase wrote: But clicking the clipboard-copier, I get not the -36. And I went through its install steps, and the -36 still did not appear. That is the recommended update site for most users. As is very clearly stated just below the clipboard copier, this is an Eclipse 3.5.x/Galileo specific version (so no -36 expected). If you're after 3.6.x/Helios then you should follow the instructions and choose an appropriate update site from. Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 7:21 น.

On 2010-11-12, at 10:13 AM, Miles Sabin wrote: On Fri, Nov 12, 2010 at 2:53 PM, David Chase wrote: But clicking the clipboard-copier, I get not the -36. And I went through its install steps, and the -36 still did not appear. That is the recommended update site for most users. As is very clearly stated just below the clipboard copier, this is an Eclipse 3.5.x/Galileo specific version (so no -36 expected). If you're after 3.6.x/Helios then you should follow the instructions and choose an appropriate update site from.

Since I went to the other downloads page, and scrolled down to the Helios builds, and the link I got has 'HELIOS' in the link, either you failed to read my email carefully, or you have really random URL naming at your site. I'm not going to spend 45 minutes on this again until I see some evidence that my email is being read a little more carefully. Yours, David Chase David Chase, 7:32 น. So as to help you in debugging your web site and/or plugin, a little additional information.

I went to THIS PAGE: scrolled down to THIS TEXT Scala IDE helios with Scala toolchain 2.8.1.final This build includes experimental support for Eclipse Helios. Update site URL: Note that it says 'helios' 3 times, in the first line, the second line, and in the text of the URL. And got THIS URL from the Flash widget And that URL contains the word 'Helios', and matches the text of the URL.

I think a rational person would normally expect that this would work with Helios, not Galileo. Did I nonetheless mistakenly click a cleverly misdocumented and misnamed 'Galileo' build? Because if you say that I did, meaning that the website is that confused about names, I will try one more time, but only if you are absolutely certain that this is the case.

Counting time spent yesterday on busted rebuilds, I am somewhere in the 2-3 hours of time spent on this. Yours, David Chase On 2010-11-12, at 10:13 AM, Miles Sabin wrote: Miles Sabin, 7:36 น. On Fri, Nov 12, 2010 at 3:32 PM, David Chase wrote: I think a rational person would normally expect that this would work with Helios, not Galileo. Did I nonetheless mistakenly click a cleverly misdocumented and misnamed 'Galileo' build? No, I misread you mail. Start with a fresh installation of Eclipse 3.6.x/Helios; an.empty.

workspace; install from the 2.8.1.final Helios update site; then create a trivial 'Hello world' project and report back to the list. Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 7:44 น. No, I misread you mail. Start with a fresh installation of Eclipse 3.6.x/Helios; an.empty. workspace; install from the 2.8.1.final Helios update site; then create a trivial 'Hello world' project and report back to the list.

Can you direct me to a good location for starting a 'Hello World' Scala project from scratch? Or, do you perhaps have a subversion or cvs repository from which I could just snag a known-good mixed Scala/Java project, so that we can control for user error there, too. Because otherwise, I have spent a heck of lot of time on this, and I am far from a Scala expert (other people on the team starting writing in Scala, my Scala coding has been tinkering around the edges), and I don't want to spend time with multiple go-arounds where I am told that I did X or Y or Z wrong - I want an end-to-end this-should-work example.

And the build time remains horrible. Is that likely to be addressed in the future? Yours, David Chase Miles Sabin, 7:48 น. On Fri, Nov 12, 2010 at 3:44 PM, David Chase wrote: No, I misread you mail. Start with a fresh installation of Eclipse 3.6.x/Helios; an.empty.

workspace; install from the 2.8.1.final Helios update site; then create a trivial 'Hello world' project and report back to the list. Can you direct me to a good location for starting a 'Hello World' Scala project from scratch? Try the screencast on Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 8:48 น. On 2010-11-12, at 10:48 AM, Miles Sabin wrote: On Fri, Nov 12, 2010 at 3:44 PM, David Chase wrote: No, I misread you mail.

Start with a fresh installation of Eclipse 3.6.x/Helios; an.empty. workspace; install from the 2.8.1.final Helios update site; then create a trivial 'Hello world' project and report back to the list. Works as expected in the utterly fresh Eclipse-3.6.1 with plugin installed, in its own workspace.

Works as expected in the dubiously tainted Eclipse-3.6.1 with plugin installed (that exhibited the bug earlier). Note this is just Scala hello world, no Java, just a toy program. I notice, sadly, that either Helios or the new plugin takes the attitude that my request for it to 'Quit' should not be honored when it is 'busy'. Galileo or the old plugin would quit-for-real on the second quit request, or at least when one was made from the dock icon. The build state is inconsistent either way, because I'm going to Force Quit (because the build will take a dozen or so minutes). Yours, David Chase Miles Sabin, 9:19 น.

On Fri, Nov 12, 2010 at 4:48 PM, David Chase wrote: Works as expected in the utterly fresh Eclipse-3.6.1 with plugin installed, in its own workspace. Works as expected in the dubiously tainted Eclipse-3.6.1 with plugin installed (that exhibited the bug earlier).

Note this is just Scala hello world, no Java, just a toy program. Now what?. Quit both Eclipse instances. Copy (or move) your projects from the old to the new workspace. Restart the new Eclipse.

Import the just-moved project into the new workspace. Let us know how you get on.

Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 11:27 น. Executive summary: failed again, doing the big project build with a clean checkout into a fresh Helios with a freshly installed Helios/2.8.1 Scala IDE plugin. Looking at the details, I have a question - if there is no 'Scala stuff' in the backtrace, is this in fact likely to be a Scala-dependent bug? (The stack trace contains only frames beginning 'org.eclipse.jdt.internal.compiler'. Except, I first saw this bug running Galileo - the appearance of the bug is correlated with the use of a 2.8.1 plugin.) Here are the exact steps I followed, so that someone else can give it a try. I used these instructions as a guide (unsurprising that they worked, since I wrote them): 1: install subversion plugin, found at 2: enlarge heap etc by editing eclipse.ini (you can do this first if you want) -vmargs -Xss8m -Xms600m -Xmx1600m -XX:NewSize=300m -server -XX:+DoEscapeAnalysis -XX:+UseConcMarkSweepGC in place of -Xms40m -Xmx512m 3: restart 4: in SVN Repository exploring, add: 5: right click to 'Checkout.'

, check out as project in new workspace, accept all defaults. It will attempt an automatic build, which will fail, because some generated source files are missing. This won't take long. 6: Special for this testing only to avoid 2.8.0 completely - so that the results are as unambigous as possible. (adequate for basic building and testing, and I don't know what was up with runOpt).

Either You Succeed Or Explain Eclipse Galileo For Mac

IN A TERMINAL WINDOW: cd (e.g., cd /Documents/workspace/PFC) rm ProjectFortress/thirdparty/scala/scala-.-2.8.0.jar ed build.xml /scala-version s/0/1/p w q ed bin/fortressclasspath /2.8.0/ s/0/1/p w q ed bin/runOpt /SV s/0.RC6/1/p w q 7: IN A TERMINAL WONDOW (same directory as previous step, note the DOT-SLASH prefix on ant)./ant operatorsGen parser makeAST (Why like this? Has to do with /.antrc, and heap/stack configuration parameters, and ant auto-locating the wrong version of Java on MacOS at least once upon a time. If this fails, and it might, copy 'antrcsuggested' to /.antrc.) 8: IN ECLIPSE Select project PFC and refresh, watch the build begin. Find some way to occupy yourself for the next 40 minutes. You will see first 'The method depthFirst(T) in the type TopSort is not applicable for the arguments (Iterable)' and then a few seconds later Internal compiler error: java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.initializeTypeVariable(BinaryTypeBinding.java:944) Looking at the stack trace, I notice the distinct lack of any 'Scala' stuff, except for the 'Scala builder' at the top.

Is this in fact a Helios problem, not a Scala-IDE problem? I would include the stack trace, but for whatever reason, all the pretty formatting vanishes when I copy-paste from Eclipse to this email, and it is really useless.

It's all org.eclipse.jdt.internal.compiler, from top to bottom. I'm going to be running errands for a bit, if anyone has any suggestions. Note that I have provided careful instructions to allow other people to waste their own time checking this out.

In particular, I'm really not interested in playing this same, stupid, assume-the-user-is-mistaken, time-wasting game with the guys off in Eclipse-land. Yours, David Chase On 2010-11-12, at 12:19 PM, Miles Sabin wrote: On Fri, Nov 12, 2010 at 4:48 PM, David Chase wrote: Works as expected in the utterly fresh Eclipse-3.6.1 with plugin installed, in its own workspace. Works as expected in the dubiously tainted Eclipse-3.6.1 with plugin installed (that exhibited the bug earlier). Note this is just Scala hello world, no Java, just a toy program. Now what?. Quit both Eclipse instances. Copy (or move) your projects from the old to the new workspace.

Restart the new Eclipse. Import the just-moved project into the new workspace. Let us know how you get on. Miles Sabin, 4:35 น. On Fri, Nov 12, 2010 at 7:27 PM, David Chase wrote: 6: Special for this testing only to avoid 2.8.0 completely - so that the results are as unambigous as possible. (adequate for basic building and testing, and I don't know what was up with runOpt). IN A TERMINAL WINDOW: cd (e.g., cd /Documents/workspace/PFC) rm ProjectFortress/thirdparty/scala/scala-.-2.8.0.jar Have you been trying to use the 2.8.1.final compiler (embedded in Eclipse) with the 2.8.0.final library (on you classpath independently of the Scala library classpath container)?

Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 5:29 น. On 2010-11-13, at 7:35 AM, Miles Sabin wrote: On Fri, Nov 12, 2010 at 7:27 PM, David Chase wrote: 6: Special for this testing only to avoid 2.8.0 completely - so that the results are as unambigous as possible.

(adequate for basic building and testing, and I don't know what was up with runOpt). IN A TERMINAL WINDOW: cd (e.g., cd /Documents/workspace/PFC) rm ProjectFortress/thirdparty/scala/scala-.-2.8.0.jar Have you been trying to use the 2.8.1.final compiler (embedded in Eclipse) with the 2.8.0.final library (on you classpath independently of the Scala library classpath container)? Absolutely not. The only 'Scala' on my box, is what is in Eclipse, and the copy of the library and compiler that we package with our software to allow controlled builds. It is not on my personal classpath, ever, and even though I think I have a handle on our project's build/run classpath, I added that deletion step above to be 100%, totally sure that it was gone from the build. Both 2.8.0 and 2.8.1 are packaged into the distribution, 2.8.0 for normal use, 2.8.1 added yesterday, ONLY so that I could run the test that you requested in a clean, canned, reproducible way. Scala library choice is supposed to be controlled by 3 knobs, one in build.xml, one in a common classpath shell script, and one in a.bat script for windows users.

I found two others looking for stray knobs, I hope to remove those, and they are not part of the build anyway. Have you tried my steps to reproduce yet, and found them lacking? Yours, David Chase David Bernard, 5:38 น. On Fri, Nov 12, 2010 at 7:27 PM, David Chase wrote: 8: IN ECLIPSE Select project PFC and refresh, watch the build begin. Find some way to occupy yourself for the next 40 minutes. You will see first 'The method depthFirst(T) in the type TopSort is not applicable for the arguments (Iterable)' That looks like the JDT's Java compiler reporting an error against Scala source.

The typical explanation for that would be disabled or incorrectly installed JDT weaving, but if you've established that that's not the case by sucessfully creating and running a trivial 'Hello world' Scala project in this Eclipse/workspace then it must be something else. Can you post your project's.project and.classpath files? Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 5:42 น. On 2010-11-13, at 8:38 AM, Miles Sabin wrote: On Fri, Nov 12, 2010 at 7:27 PM, David Chase wrote: 8: IN ECLIPSE Select project PFC and refresh, watch the build begin. Find some way to occupy yourself for the next 40 minutes.

You will see first 'The method depthFirst(T) in the type TopSort is not applicable for the arguments (Iterable)' That looks like the JDT's Java compiler reporting an error against Scala source. Can you post your project's.project and.classpath files? Should be in the repository, but here: dr2chase:PFC dr2chase$ cat.project PFC ch.epfl.lamp.sdt.core.scalabuilder ch.epfl.lamp.sdt.core.scalanature org.eclipse.jdt.core.javanature dr2chase:PFC dr2chase$ cat.classpath dr2chase:PFC dr2chase$ Miles Sabin, 5:54 น. On Sat, Nov 13, 2010 at 1:42 PM, David Chase wrote: You will see first 'The method depthFirst(T) in the type TopSort is not applicable for the arguments (Iterable)' That looks like the JDT's Java compiler reporting an error against Scala source. It's not. That's an error coming out of a Java compiler. If it wasn't it would look more like, The method depthFirst(ArrayT) in the type TopSort is not applicable for the arguments (IterableTopSortItemImplString) Can you post your project's.project and.classpath files?

Should be in the repository, but here: As David mentioned you have entries in there from older versions of the Scala IDE. The prefixes 'ch.epfl.lamp.sdt' changed to 'org.scala-ide.sdt' quite sometime ago. The old prefixes should still be supported, but it's possible that this is (part of) your problem. To get the up to date, right click on your project in the Package Explorer, then click Scala = Remove Scala nature, then repeat, this time clicking Add Scala nature and do a clean build. Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Bernard, 5:59 น. On Sat, Nov 13, 2010 at 3:16 PM, David Bernard wrote:.

I open the ticket (to store the info and avoid long comment into code):. I'm able to reduce the clean+build from (+10min to 2min) with. memory set to 2G (else GC use 40%CPU).

a patch on EclipseFile (see ticket), I'll commit it on master/helios branch (I hope there'll be no bad side effect when file/folder is rename/moved) Good catch:-) Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Bernard, 8:09 น. David, Also notice:.

that first run will take longer, on my box the 98%-100% is mainly used by java indexer (and presentation compiler) durling 78s. subversion plugin also run when you do a clean+build (in my case I've got lot of warning in the console from where launch eclipse) I attach updated?classpath and.project change are. right plugin/container id (done by Remove Scala Nature + Add Scala Nature). exclude of com/sun/fortress/unicode/.java and com/sun/fortress/useful/.java (link in build.xml) Hope that help you. I think the fix will be part of tomorrow nightly, (I could send you the jar for helios-scala-2.8.0, if you wish) /davidB u David Bernard, 9:11 น. I 'fix' the issue about long build but not about: 'The method depthFirst(T) in the type TopSort is not applicable for the arguments (Iterable)' As eclipse project and ant build don't use same build process (classpath, source files to compile) I don't know what is possible. The classes highlighted by the error are part of the useful package who is not part of scalac compilation pass in build.xml.

And I don't know why/where the compiler find a signature with an array (navigation via click display a method with Iterable ). /davidB David Chase, 9:28 น. Thanks very much. I verified that the new plugin name works with Galileo/2.8.0, so I can make that change now. A 2G VM, that depends on the platform. Unless Apple has changed things in a recent Java or OS release, that's not possible on my box, but I will revisit the limit. Can you explain the interaction with the subversion plugin?

Would I be better off without it? I'm perfectly capable of running subversion from the command line, so if this makes a substantial difference in the performance, I think I will disable it and/or complain to the subclipse developers. I did like the 3-way diffs, but there are other tools that will do that. (I'm doing the subversion experiment right now anyway, to see how builds behave.

This, in the older Eclipse/) David On 2010-11-13, at 11:09 AM, David Bernard wrote: DavidAlso notice:. that first run will take longer, on my box the 98%-100% is mainly used by java indexer (and presentation compiler) durling 78s. subversion plugin also run when you do a clean+build (in my case I've got lot of warning in the console from where launch eclipse) I attach updated?classpath and.project change are. right plugin/container id (done by Remove Scala Nature + Add Scala Nature).

exclude of com/sun/fortress/unicode/.java and com/sun/fortress/useful/.java (link in build.xml) Hope that help you. I think the fix will be part of tomorrow nightly(I could send you the jar for helios-scala-2.8.0, if you wish) /davidB David Bernard, 9:47 น. On Sat, Nov 13, 2010 at 18:28, David Chase wrote: Thanks very much. I verified that the new plugin name works with Galileo/2.8.0, so I can make that change now. A 2G VM, that depends on the platform. Unless Apple has changed things in a recent Java or OS release, that's not possible on my box, but I will revisit the limit. With less memory I can have lot of GC activity (see attached).

From my test 1.8G should be enough if you have only this project open in the workspace Can you explain the interaction with the subversion plugin? Would I be better off without it? I'm perfectly capable of running subversion from the command line, so if this makes a substantial difference in the performance, I think I will disable it and/or complain to the subclipse developers.

I did like the 3-way diffs, but there are other tools that will do that. I don't estimate the impact of Subclipse, I only notice lot of warning on the console (I'm on linux, an warning are about FS notification (on change)) (I'm doing the subversion experiment right now anyway, to see how builds behave.

This, in the older Eclipse/) David On 2010-11-13, at 11:09 AM, David Bernard wrote: DavidAlso notice:. that first run will take longer, on my box the 98%-100% is mainly used by java indexer (and presentation compiler) durling 78s. subversion plugin also run when you do a clean+build (in my case I've got lot of warning in the console from where launch eclipse) I attach updated?classpath and.project change are. right plugin/container id (done by Remove Scala Nature + Add Scala Nature). exclude of com/sun/fortress/unicode/.java and com/sun/fortress/useful/.java (link in build.xml) Hope that help you. I think the fix will be part of tomorrow nightly(I could send you the jar for helios-scala-2.8.0, if you wish) /davidB David Bernard, 10:03 น. On 2010-11-13, at 12:47 PM, David Bernard wrote: On Sat, Nov 13, 2010 at 18:28, David Chase wrote: Thanks very much.

I verified that the new plugin name works with Galileo/2.8.0, so I can make that change now. A 2G VM, that depends on the platform. Unless Apple has changed things in a recent Java or OS release, that's not possible on my box, but I will revisit the limit. with less memory I can have lot of GC activity (see attached). From my test 1.8G should be enough if you have only this project open in the workspace Some limit has been increased, because 1.6G WAS the most I could do (Eclipse would fail on launch if too large, so the test is quick and easy). 1.8G was just verified to work.

Can you explain the interaction with the subversion plugin? I don't estimate the impact of Subclipse, I only notice lot of warning on the console (I'm on linux, an warning are about FS notification (on change)) (I'm doing the subversion experiment right now anyway, to see how builds behave.

This, in the older Eclipse/) Doing the experiment in detail would be tedious, but I think I carved two minutes off the time. 2G just worked (heap size double-checked with jConsole), I am (12:54) trying another clean+build to see how it goes. Finished sometime before 1:08 (14 minutes) with almost 17 minutes of CPU time, using the full 2G heap in the end. I'm not sure, but I suspect the subversion penalty involves some sort of concurrency impediment. Larger heap experiments must wait; we having anomalously good weather, so I must work outdoors (gardening) while I can. David David Bernard, 10:15 น.

Just to confirm, your patches should work with 2.8.1 in both Galileo and Helios? And the same for your config changes? (I'll test to be sure, but if they're not intended to work, it will save time to know ahead of time.) I'll need to modify your path slightly to put the 'useful' stuff back on it. In theory, yes, a change to 'useful' requires a from-scratch rebuild, but in practice, not, and we add things from time to time and expect an automatic rebuild. When the dust clears, I'll have a look at the TopSort weirdness.

That's Java code, both signatures are present, no idea what causes the spurious error, and I'd be very unsurprised to find a workaround at the call site (and realistically, I have no shame, if it keeps things working I'll replace the array-arg constructor with a static factory method.) David On 2010-11-13, at 1:15 PM, David Bernard wrote: In every case retry after tomorrow (when nightly build with my patch will be made), and with the eclipse conf, I sent. Nice outdoors, it rains here. David Bernard, 0:05 น.

On Sat, Nov 13, 2010 at 22:44, David Chase wrote: Just to confirm, your patches should work with 2.8.1 in both Galileo and Helios? It should, but not tested. And the same for your config changes? (I'll test to be sure, but if they're not intended to work, it will save time to know ahead of time.) Idem I'll need to modify your path slightly to put the 'useful' stuff back on it.

In theory, yes, a change to 'useful' requires a from-scratch rebuild, but in practice, not, and we add things from time to time and expect an automatic rebuild. Yes, I add an entry into.classpath for JDK/lib/tools.jar When the dust clears, I'll have a look at the TopSort weirdness. That's Java code, both signatures are present, no idea what causes the spurious error, and I'd be very unsurprised to find a workaround at the call site (and realistically, I have no shame, if it keeps things working I'll replace the array-arg constructor with a static factory method.) When you do a clean+build from eclipse, the content of build/ dir is emptied, it's why I add an ant builder (in eclipse before ScalaBuilder) to do the same task done before compileAll in build.xml.

/davidB David On 2010-11-13, at 1:15 PM, David Bernard wrote: In every case retry after tomorrow (when nightly build with my patch will be made), and with the eclipse conf, I sent. Nice outdoors, it rains here. David Chase, 8:58 น. (Looking into a fix for the internal-compiler-error class-cast bug.) There's glitches in the config files - I had no JDKTOOLS variable, and it's whining about the 'Integrated External Tool Builder'. So I rolled those back to what they were. I'm still seeing the complaint - did I get the wrong version of the plugin?

I just did a regular update against the helios/2.8.1 plugin from the site, and got Scala IDE for Eclipse 1.0.0.02 org.scala-ide.sdt.feature.feature.group Uninstalled plugin, reinstalled, taking care to go get Helios 2.8.1 nightly, restarted, cleaned. Bug is still there. Did the fix not make it in yet? David David Bernard, 10:32 น. On 2010-11-15, at 1:32 PM, David Bernard wrote: DavidI introduce (manually) into your project:.

the JDKTOOLS variable, because your code need tools.jar (part of. But did your fix make it in to the Helios+2.8.1 plugin? I thought that it would, but I am still seeing the compiler class cast error. I can sort out the build configuration later; it should just be an optimization, right?

I'm testing the 'trunk' plugin just to see if that is where the fix went, but superficially that looks like it is likely to be a doomed test, because I saw the '2.9.0' in the name. It's been churning along for 40 CPU minutes in a 2GB heap. I'll give it till 45, then kill it to see how things work with a 2.8.0 plugin in Helios. David David Bernard, 10:57 น.

I don't know how nighty for scala 2.8.1 are created, I think there were build from branch helios with the build script for 2.8.0 and for 2.8.1, so my changes should be part of the lasted nighlty (I push the change yesterday). If you like I could build locally the helios-2.8.1 and share it (on a temporary update-site). The JDKTOOLS and other changes in eclipse's project configuration (listed in previous mail/thread and in the archive I sent) fix the compilation.

I only have warnings (same as from ant + some due to my eclipse java analyzer configuration). I don't have class cast error. /davidB Miles Sabin, 10:59 น. On Mon, Nov 15, 2010 at 6:57 PM, David Bernard wrote: I don't know how nighty for scala 2.8.1 are created, I think there were build from branch helios with the build script for 2.8.0 and for 2.8.1, so my changes should be part of the lasted nighlty (I push the change yesterday). That's correct. If you like I could build locally the helios-2.8.1 and share it (on a temporary update-site).

Shouldn't be necessary. Cheers, Miles - Miles Sabin tel: +44 7813 944 528 gtalk: skype: milessabin David Chase, 11:25 น. On 2010-11-15, at 1:57 PM, David Bernard wrote: The JDKTOOLS and other changes in eclipse's project configuration (listed in previous mail/thread and in the archive I sent) fix the compilation. I only have warnings (same as from ant + some due to my eclipse java analyzer configuration). I don't have class cast error.

I'm afraid I don't entirely understand. Are you saying that the fix for the compiler's internal error, is to change the project configuration to add a working JDKTOOLS and modify the builder to invoke ant? I would normally expect this to be something that would be fixed by a change to the compiler. The trunk-nightly (marked 2.9.0) exhibited the same error, finally, using an unfixed configuration (because I have not yet figured out what a fixed, corrected, configuration would look like). Helios+2.8.0 did not show the same error, and managed to run to completion automatically beginning with whatever debris the trunk-nightly left in its failed attempt. Astonishingly, running the resulting program (using a 2.8.1 library!) worked. So, I'll pursue the JDKTOOLS step (note that this was not necessary to build with 2.8.0, but if it doesn't hurt, I might as well try it) and see if I can enhance the external-builders step.

This still seems like a bug to be fixed in the compiler itself. I think the spurious complaint about 'depthFirst(T)' is a Helios bug. (It still remained.) The code in question is written in Java, not Scala, so it is case of a Java compiler complaining about Java code.

I think it is a poorly reported type inference failure - adding an explicit type parameter made it go away: List ordered = TopSort.depthFirst(table.values); ^-added this to fix bug-^ David David Bernard, 11:43 น. On 2010-11-15, at 3:00 PM, David Bernard wrote: I setup a full eclipse 3.6.1 + scala-IDE helios-2.8.1-final.

And I've got the ClassCastException after few minutes. An other bug to investigate/fix but not tonight (for my side). I'll setup and try eclipse 3.6.1 + scala-ide-helios-2.8.0-final (I previously work on 3.6.0 + scala-ide-helios-2.8.0-final) to see if the issue is with helios of scala version. A few details to know (I am tinkering at my end) - if you check out the latest from the projectfortress repository, that TopSort bug is, or will be, gone. I think it is a Helios bug, it appears with both 2.8.0 and 2.8.1 Scala plugins under Helios, and adding an explicit type parameter to the call made it go away. R4744 = revision referenced in earlier how-to-reproduce email r4745 = fixed.classpath and.project for new Scala conventions (but no classpath cleanup) + renamed the array version of the 'depthFirst' method to remove overloading. R4746 = adds explicit static parameter at call site, making inference unnecessary.

R4747 = trimmed.classpath I am not sure why ant/build.xml references 'tools.jar' - on my Mac, at least, whatever that variable is set to, is not found, yet the build proceeds correctly. I seem to recall something about it being necessary for Linux, but the details elude me, and I could not find them in our own email or svn comments. Another colleague reports, 'maybe it was for Solaris'. With the (latest, r4747) classpath in the projectfortress repository, I just now built on Helios+2.8.0 from 'clean project' in about 7 CPU minutes (2GB heap), which is fast. Note that there is NO subversion plugin in the Eclipse I am testing; that only muddies the waters, so I left it out.

Galileo+2.8.0 also works with trimmed classpath, somewhat slower, but that's an old Eclipse filled with plugins (but also with a 2GB heap). And I just now verified that Helios+2.8.1 continues to exhibit the compiler error / class cast exception, in not too many minutes. When you DO finally get to the point where the compiler errors are gone, you may notice that our Java files (e.g., com/sun/fortress/compiler/codegen/Codegen.java) are littered with spurious errors in the display. I have no earthly idea what causes that, and they aren't listed as real errors in the 'Problems' pane, so I don't know why they are there, either.) yours, David.

The results of the Eclipse Community Survey 2010 are. Thank you to everyone, all 1696 people, that took the time to give us your feedback. A challenge for lots of open source communities is understanding the dynamics in the community, so these results provide a useful data point. We have published a report, called the, that provides a summary of the survey results. The detailed results and numbers are also available. For those interesting in trends, we have done a similar surveys in.

Each year I learn a lot analyzing the survey results. The popular products used in the Eclipse community and in 2010 a lot of those same products are still very popular. However, some things did jump out as interesting trends for 2010. Linux on the developers desktop continues to grow. We asked developers what was their primary operating system for software development. In 2007, 20% said Linux was their development operating system. Now, in 2010 almost a third (33%) say Linux.

The biggest loser seems to be Windows 73.8% in 2007 down to 58.3% in 2010. Interestingly, Mac OS X has only gone from 3.5% to 7.9%. JQuery has a lot of momentum and usage in the RIA space. JQuery ranked the highest (26.9%) RIA framework of those the stated RIA/Web Apps was their primary style of software. Th next closest was Adobe Flex at 9.1%. In the 2009 survey, JQuery had around 5% adoption.

Open JDK has gain a lot of adoption. I don’t follow the JVM market that closely but I was pleasantly surprised to see 21.7% of the respondents state they target Open JDK.

Sun Hotspot predictably scored the highest at 68.8%. DVCS usage is growing; CVS is shrinking. DVCS is a hot trend for software development and Git support is a hot topic for Eclipse project committers. Therefore, I was not surprised to see Git usage up from 2.4% (2009) to 6.8% (2010).

Mercurial usage also increased from 1.1% to 3%. This growth seems to be coming from the decreased use of CVS, 20% (2009) to 12.6% (2010). Subversion continues to be the most popular at 58.3%. Eclipse users upgrade quickly to new releases. 75.5% of the respondents said they were using Eclipse 3.5 (Galileo) and an additional 7.1% use the Helios milestones.

I’ve always known the Eclipse community moves quickly to a new release but 82+% in less than 1 year is pretty impressive. If you are building products that target Eclipse users, providing support for older versions of Eclipse might not be that important. Granted, products that are built on top of Eclipse probably don’t move as fast.

Lots of fragmentation in the methodology space. I don’t follow the software methodology space that closely but I was surprised by the fact that 1) 25% of the respondents don’t use a methodology and 2) the most popular, Scrum, has only 15% adoption. The rest of the respondents identified over 18 different methodologies that they use for a development methodology.

Open source participation seems to be stalled. In the survey, we asked a question about the corporate policies towards open source participation. In 2009 48% claimed they could contribute back to OSS but in 2010 only 35.4% claim they could contribute back. Conversely, 41% in 2010 claimed they use open source software but do not contribute back but in 2009 it was 27.1%. Obviously not a trend any open source community would like to see. I am not sure the reason companies would become less restrictive in their open source policies.

Any insight or feedback from the community would be appreciated. The community is satisfied. Once again it appears the Eclipse community is pretty satisfied, 39.9% are very satisfied and 48.5% are satisfied. Pretty consistent with last year, so congratulations to everyone the makes Eclipse a great place. There is a lot more information available in the and in the detailed data. Let me know what you learned and your impressions.

As with any survey, there are obvious biases and this is just one data point but I do think it represents a decent view of what developers are doing. Thanks for these interesting findings, Ian. However, we should not forget that this feedback is given by the most active members of the Eclipse community. The Eclipse users base is much more larger. Especially, when looking at Trend #5 – adopting new releases. It is naturally to expect that the most active Eclipse users use the packages distributed on Eclipse.org and upgrade quickly to newer releases. But this is not exactly true for users of an adopters product.

There are vendors that are just releasing their fresh new products based on Ganymede! And there are customers of these vendors that don’t rush upgrading, because of the license cost of upgrading. I am developing a plug-in, which my initial plan for was to support Europa and later. But a customer found it useful for a product based on Callisto and he asked if I can downport it 🙂 So, plug-in developers still need to pay attention at the older Eclipse releases. I actually second Kaloyan’s opinions.

I think some of the trends extracted here are a bit far fetched especially when it comes to corporate developers. Having access to real customers in my new job, I can see that the reality of corporate adoptions of new releases of eclipse is much different than what you see here. Rather than being set by the eclipse releases, the adoption is set by the pace at which tool vendors adopt eclipse, which is far from being yearly. I think it would be of general benefit to the community of add-on providers, to gather from various eclipse members the number of deployed instance of eclipse they have and which version.