Re: [scala] Scala plugin BETA

> Hi,
>
> I get this error:
>
> Errors running builder 'Scala Builder' on project 'myprojectname'.
>
> Resource '/myprojectname/.manager' already exists.
>
> I tried renaming the .manager directory, but that didn't help.
>
> Amir
>
> On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:
>> Hi,
>>
>> As some of you might know, I've been working on a new Scala plugin
>> for the past year and a half with the intention of replacing the
>> current plugin, which I hacked together in the course of a couple of
>> months. Our goals with the new plugin are pretty ambitious and have
>> required exploring lots of new technology (incremental parsing, type
>> checking) as well as obtaining a better understanding of Eclipse. I'm
>> happy to announce that it is kind of done and I'd like to start BETA
>> testing in the community. The update site for the new plugin BETA is
>> at http://lamp.epfl.ch/~mcdirmid/scala.update (http://lamp.epfl.ch/
>> ~mcdirmid/scala.update/site.jar if you prefer an archive install).
>> Notable features:
>>
>> * Truly incremental syntax/type checking and semantic highlighting
>> (no more ctrl-shift-z!), works fast even in very large files.
>>
>> * Code completion (content assist) that works reliably and  
>> responsively
>>
>> * Almost 100% semantic highlighting coverage (better for search and
>> refactoring later...)
>>
>> * Better integration with Java. Java-doc comments from Java source
>> now show in hover help (if the Java-doc attachment is set) and can
>> hyperlink to Java definitions (if the Java source attachment is set).
>>
>> * The incremental builder now knows about changes to classfiles in
>> other Scala and Java projects, and will rebuild accordingly
>> (hopefully, still needs more testing). The Scala editor also knows
>> about classfile changes.
>>
>> * Can now set breakpoints in Scala-derived classfiles. When the
>> debugger triggers a break point in a Scala-derived classfile, the
>> debugger opens the breakpoint in a Scala editor and not a Java editor
>> as before. Also, when Scala-derived classfiles are opened up through
>> the Project Explorer (but unfortunately, not the Package Explorer),
>> they will open up in a Scala editor rather than a Java editor as  
>> before.
>>
>> * Position/highlighting information is saved so Scala-derived
>> classfiles can be opened very quickly (assuming the Scala source
>> attachment is set).
>>
>> * Folding and Scala-centric auto indenting!
>>
>> * Better editor preferences dialogue.
>>
>> * For keyboard junkies, goto declaration has been implemented (using
>> the JDT configured key binding, by default F3).
>>
>> Because the technology used in the plugin is very new and untested, I
>> initially expect that there will be ALOT of bugs. I'm continuously
>> afraid whenever I'm editing in the new plugin that any keystroke will
>> cause a crash :) I really need the community's help if the plugin is
>> going to become stable. Please keep your error log view open while
>> using the plugin, as this could fill up pretty quickly and you'll
>> only be notified of the first crash. We'll use trac to manage bug
>> reports, but check the open bug reports to avoid wasting time on
>> duplicate reports. Also, I've checked in the source if you want to
>> hack on it or add features. In particular, Documentation would be
>> greatly appreciated. I haven't documented the code yet, and we don't
>> have a DOM, so if you want to implement a feature that requires
>> compiler information, please talk to me.
>>
>> On a personal note, I'm leaving EPFL (and the western hemisphere) at
>> the end of October, and we don't know who will take this over yet.
>> I'm still going to try and fix bugs and keep releases going, but for
>> this to work we really need to open it up and attract community
>> contributions. Suggestions on how to do this would be greatly
>> appreciated.
>>
>> Please read the following release notes if you want to use the new
>> plugin (also included in the plugin documentation):
>>
>> * The plugin is currently based on (and comes with) the unfinished
>> 2.6.1 Scala release. No feature for 2.6.1 has yet been set in stone
>> and 2.6.1 probably contains some new bugs not in 2.6.0.
>>
>> * The plugin currently relies heavily on "IDE" files. Please clean-
>> rebuild your existing projects in the new plugin before opening up
>> files in the editor.
>>
>> * Existing .project files must be updated in the following way:
>> ch.epfl.lamp.sdt.core.scalabuilder becomes scala.plugin.scalabuilder
>> and ch.epfl.lamp.sdt.core.scalanature becomes
>> scala.plugin.scalanature. Thankfully, .classpath files don't need to
>> be migrated.
>>
>> * Existing application and Scala breakpoint profiles cannot be
>> migrated. Please remove them from your workspace before installing
>> the new plugin.
>>
>> * Its probably not a good idea to have both the old and new plugin
>> installed on the same Eclipse installation. Please uninstall or
>> disable the old plugin before installing the new one, or use a
>> different configuration profile.
>>
>> * The IDE file is used to ensure that the file is opened quickly, but
>> parsing and type checking will not occur until the first edit
>> ("breaking the ice"). This means that there will be a lag on the
>> first edit of a large file (due to parsing, which occurs in the UI
>> thread) and then later when type checking completes (as the type
>> checking results are integrated into the UI). While type checking is
>> occurring, no type-dependent services will work (e.g., hover help,
>> code completion). Type checking for most edits is incremental and so
>> completes fast enough that this is not an issue. The biggest type
>> checking times occur when (a) modifying a top-level import in a large
>> file or (b) when you start editing a large file. As an example,
>> Typers.scala, which is around 3300 lines of DENSE Scala code, takes
>> around 8 seconds to type check initially in the editor. This will
>> balloon to 20 or so seconds if you edit a top-level import. Import
>> statements are currently a big problem given the way they are
>> represented in the compiler, we still don't have a fix in mind for  
>> this.
>>
>> * You are free to change the parse tree while type checking occurs in
>> the background, it shouldn't crash the compiler :) All changed parse
>> nodes are scheduled for type checking in the background.
>>
>> * Parsing and type checking will not occur if braces (including
>> comments and double quotes) in the file are unbalanced. For this
>> reason, brace completion (as implemented in the IDE) is essential to
>> keep things lively and is definitely not a save-on-typing
>> convenience. If you type over any closing brace, a new closing brace
>> won't be inserted. Braces can go unbalanced (e.g., if you block paste
>> in some code with unbalanced braces), but many IDE features will not
>> work during this time.  There are a few more features that aid in
>> keeping braces balanced: deleting an opening brace will delete its
>> matched closing brace; typing a closing brace will move out or in an
>> existing closing brace in certain contexts; and you can select a
>> block of text and type ",`,(,{,[,/ to enclose the block in double
>> quotes, back quotes, parentheses, curly braces, brackets, or a multi-
>> line comment, respectively.
>>
>> * There is currently no XML support. Support is planned, but not
>> right now.
>>
>> *  The content outliner, interpreter, and test pad views are not yet
>> implemented for the new plugin.
>>
>> * There is still no support for refactoring or search.
>>
>> * The Project Explorer replaces the Package Explorer as the preferred
>> navigation view of Scala projects (the Package Explorer will still
>> work). However, I've noticed some conflicts with the JDT "Java
>> Element" content view, you'll probably have to disable it (click the
>> down white triangle in the project explorer view, select the
>> "Customize View" menu, select the "Content" tab, uncheck "Java
>> Elements").
>>
>> * For some strange reason, no default highlighting colors are
>> configured when the plugin is first installed. Go to Preferences/
>> Scala/Scala Editor Preferences, hit "Restore Defaults", "Ok" then
>> colors will be enabled. I know the default color scheme is atrocious,
>> but you can also customize Scala highlighting colors.
>>
>> * Scala classpath entries do not make use of Java-doc attachments
>> (all scala-doc entries are extracted from source attachments) while
>> Java requires these attachments even if source is available. Make
>> sure your Java-doc/source code attachments are configured correctly
>> for your JRE_CONTAINER. Source attachments are included for the
>> embedded Scala library.
>>
>>