[scala] Scala plugin BETA

[sean.mcdirmid]

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.

[David Pollak]

Sean,

At some point I will start testing the plugin, but there's an absolute
requirement for any plugin: it absolutely has to let me choose the
version of Scala it works with, just like the Java mode in Eclipse
allows for the choice of JDKs.

Each version of Scala has minor (and sometimes major) byte-code
incompatibilities such that code compiled with one version will not work
with any runtime but the runtime that the code way compiled against (as
compared to Javac byte code which has always been forward compatible.)

Having the compiler version baked into the plugin (especially when the
version is often a development version a week or two off from the actual
releases) means that the code generated by the plugin cannot be used
from the command line unless the exact same version of the runtime is
the version invoked with "scala".

I'm looking forward to being able to use the new plugin with the same
version of Scala as I have running from the command line.

Thanks,

David

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.
>

[sean.mcdirmid]

The license is the standard Scala EPFL license (whatever we include with the Scala distribution), you'll be asked to accept it on install. 

The code is located in the LAMP SVN repository (https://lampsvn.epfl.ch/svn-repos/scala/), the plugin consists of three plugin projects:

* scala/trunk - everything Scala, build through ant first (afterwards, the compiler can be built in Eclipse, the library cannot)

* plugin/lampion.core - the parts of the Scala plugin that don't depend on Eclipse (a generic IDE framework and a configuration of the framework for Scala)

* plugin/scala.plugin - the Eclipse-specific parts of the Scala plugin (contains the plugin Activator, the XML extensions, icons, and more code).

You'll need the old Scala plugin to work with these projects (I'm not ready to eat my own dogfood yet). After building all three projects, you'll need to JAR up scala (the scala/trunk project)/build/quick/lib into scala.plugin/lib/scala-library.jar, and JAR up scala/src/library into scala.plugin/lib/scala-library-src.jar. 

To run the code, create a Eclipse application profile where all the old Scala plugins (anything beginning with ch.) are disabled, otherwise the new and old plugins will conflict. 

We are working on an automated build for this, but right now everything must be built manually in Eclipse. If you want to play with this, feel free to ask me any questions.

Sean 

On Sep 18, 2007, at 12:34 PM, Antoine Toulme wrote:

Hi Sean,

congratulations on the release!

I will certainly be happy to test the Scala plugin, and help going forward, if you clear those points for me:

- what is the license for the Eclipse plugin ?
-where is the code located ? I still don't know where it is.

Thanks,

Antoine

[sean.mcdirmid]

Hi David,

For the most part, this is tough to impossible to implement and nobody does it! The plugin is tied in intrinsically with the Scala compiler. The way the JDT team manages this in Eclipse is to just have one compiler that can work with different versions of Java. You can't drop a version of javac that you want into Eclipse (maybe you can for Netbeans, but it doesn't support many features anyways). You can check out the Eclipse source code for yourself if you don't believe me! 

As another option, you can replace the Scala builder with a standard ANT builder and build through build.xml. You lose the benefits of the incremental builder (namely dependency tracking), and editing won't work correctly without IDE files generated in 2.6.1. However, if you are using a version of Scala that can generate IDE files, then it should work well enough. 

If you want to use a different library for your project, just point your .classpath at the library you want to use (you also probably need to import it into the project and put the library on the runtime classpath). If you are using Scala through a scala.home environment variable, just replace ch.epfl.lamp.sdt.launching.SCALA_CONTAINER with ch.epfl.lamp.sdt.launching.SCALA_HOME in your .classpath file. 

Hope this helps,

Sean

On Sep 18, 2007, at 12:39 PM, David Pollak wrote:

Sean,

At some point I will start testing the plugin, but there's an absolute requirement for any plugin: it absolutely has to let me choose the version of Scala it works with, just like the Java mode in Eclipse allows for the choice of JDKs.

Each version of Scala has minor (and sometimes major) byte-code incompatibilities such that code compiled with one version will not work with any runtime but the runtime that the code way compiled against (as compared to Javac byte code which has always been forward compatible.)

Having the compiler version baked into the plugin (especially when the version is often a development version a week or two off from the actual releases) means that the code generated by the plugin cannot be used from the command line unless the exact same version of the runtime is the version invoked with "scala".

I'm looking forward to being able to use the new plugin with the same version of Scala as I have running from the command line.

Thanks,

[sean.mcdirmid]

[EDIT: corrected a couple of mistakes in my instructions]

The license is the standard Scala EPFL license (whatever we include with the Scala distribution), you'll be asked to accept it on install. 

The code is located in the LAMP SVN repository (https://lampsvn.epfl.ch/svn-repos/scala/), the plugin consists of three plugin projects:

* scala/trunk - everything Scala, build through ant first (afterwards, the compiler can be built in Eclipse, the library cannot)

* plugin/lampion.core - the parts of the Scala plugin that don't depend on Eclipse (a generic IDE framework and a configuration of the framework for Scala)

* plugin/scala.plugin - the Eclipse-specific parts of the Scala plugin (contains the plugin Activator, the XML extensions, icons, and more code).

You'll need the old Scala plugin to work with these projects (I'm not ready to eat my own dogfood yet). After building all three projects, you'll need to JAR up the classes in scala (the scala/trunk project)/build/quick/lib/library into scala.plugin/lib/scala-library.jar, and JAR up the source files in scala/src/library into scala.plugin/lib/scala-library-src.jar. 

To run the code, create a Eclipse application profile where all the old Scala plugins (anything beginning with ch.) are disabled, otherwise the new and old plugins will conflict. 

We are working on an automated build for this, but right now everything must be built manually in Eclipse. If you want to play with this, feel free to ask me any questions.

Sean 

On Sep 18, 2007, at 12:34 PM, Antoine Toulme wrote:

Hi Sean,

congratulations on the release!

I will certainly be happy to test the Scala plugin, and help going forward, if you clear those points for me:

- what is the license for the Eclipse plugin ?
-where is the code located ? I still don't know where it is.

Thanks,

Antoine

[Antoine Toulme]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks!

On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:

[EDIT: corrected a couple of mistakes in my instructions]

The license is the standard Scala EPFL license (whatever we include with the Scala distribution), you'll be asked to accept it on install. 

The code is located in the LAMP SVN repository ( https://lampsvn.epfl.ch/svn-repos/scala/), the plugin consists of three plugin projects:

* scala/trunk - everything Scala, build through ant first (afterwards, the compiler can be built in Eclipse, the library cannot)

* plugin/lampion.core - the parts of the Scala plugin that don't depend on Eclipse (a generic IDE framework and a configuration of the framework for Scala)

* plugin/scala.plugin - the Eclipse-specific parts of the Scala plugin (contains the plugin Activator, the XML extensions, icons, and more code).

You'll need the old Scala plugin to work with these projects (I'm not ready to eat my own dogfood yet). After building all three projects, you'll need to JAR up the classes in scala (the scala/trunk project)/build/quick/lib/library into scala.plugin/lib/scala-library.jar, and JAR up the source files in scala/src/library into scala.plugin/lib/scala-library-src.jar. 

To run the code, create a Eclipse application profile where all the old Scala plugins (anything beginning with ch.) are disabled, otherwise the new and old plugins will conflict. 

We are working on an automated build for this, but right now everything must be built manually in Eclipse. If you want to play with this, feel free to ask me any questions.

I will certainly do that.

Sean 

On Sep 18, 2007, at 12:34 PM, Antoine Toulme wrote:

Hi Sean,

congratulations on the release!

I will certainly be happy to test the Scala plugin, and help going forward, if you clear those points for me:

- what is the license for the Eclipse plugin ?
-where is the code located ? I still don't know where it is.

Thanks,

Antoine

--
http://antoine.toulme.name
http://www.lunar-ocean.com
http://www.requirements-tracker.com

[Peter Arrenbrecht]

Congrats, Sean! This sounds exciting. I really hope you won't be
totally lost to the Scala community in the future :-/.
-peo

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.
>
>

[Amir Michail]

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.
>
>

[sean.mcdirmid]

Ah, if you are migrating an old project, it might be that  
the .manager file is conflicting with the new .manager directory. If  
you aren't deleting .manager from within Eclipse, you'll have to "F5"  
refresh the workspace or Eclipse won't detect the change. In the  
meantime, I'll add some code to the plugin to deal with old .manager  
files.

Sean

On Sep 18, 2007, at 4:20 PM, Amir Michail wrote:

> 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.
>>
>>

[Peter Arrenbrecht]

On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:
> 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.

I can tell ;)

> We'll use trac to manage bug
> reports, but check the open bug reports to avoid wasting time on
> duplicate reports.

Do you want the bug reports filed for the component "eclipse plugin"?
Should we flag them somehow to indicate they concern the new beta
version?

-peo

[sean.mcdirmid]

Just flag them as being on the eclipse plugin. I'm not worrying about the
 old plugin anymore, its problems require drastic changes (hence the new
plugin), so its around only until the new version is ready :)

Sean

引言 Peter Arrenbrecht <peter.arrenbrecht@...>:

> I can tell ;)
>
> > We'll use trac to manage bug
> > reports, but check the open bug reports to avoid wasting time on
> > duplicate reports.
>
> Do you want the bug reports filed for the component "eclipse plugin"?
> Should we flag them somehow to indicate they concern the new beta
> version?
>
> -peo
>

[Alex Boisvert-3]

Hi Sean,

Thanks for pushing this far with the Scala plugin, I'm really thrilled about it!!

On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:

* There is currently no XML support. Support is planned, but not
right now.

Could you expand a little on this subject?  Does that mean I can't use XML syntax in Scala files?  What happens if I do?  Are there any workarounds?

cheers,
alex

[mighdoll]

> On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:
>         * There is currently no XML support. Support is planned, but
>         not
>         right now.
>
>
> Could you expand a little on this subject?  Does that mean I can't use
> XML syntax in Scala files?  What happens if I do?  Are there any
> workarounds?

Just tried it with a trivial example.  The eclipse error log pops up and
spits out an assert from the plugin on every edit with xml in the file.
A few edits later the editor hung and I had to restart eclipse.  (Sean
-- let me know if you need a test case for this.)  I'm assuming we need
to avoid xml until the next rev of the plugin.

Before I messed with xml, the code completion looked very cool and
responsive.  The plugin looks like it'll be wonderful when we get it
shaken out a bit.

[sean.mcdirmid]

Yes, the XML lack of support is indicated by an assert(false)
implementation of the XML methods.

If XMLSTART is encountered, the plugin will just blowup, I
should probably suppress this token and ignore XML
completely.

<rant>
XML is going to be a pain to support, especially in the
non-delimited form that Scala supports. Essentially, if
you see a '>' in an XML block, you have no idea if its
the end, the beginning of the end, or the end of the
beginning. Also, Scala separates its lexical and
syntactic parts, while XML does not. The only way to
know that you are outside of an XML block is to...
parse the entire XML block! This all stems
back to the fact that XML was not designed to be
edited by humans, rather it was designed to be
processed quickly by computers.
</rant>

As far as I know, there are no incremental error
recovering parsers out there for XML that can be
used in an editor context. If anyone knows of such
a beast, please let me know.

Sean

引言 Lee MIghdoll <lee@...>:

> > On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:
> >         * There is currently no XML support. Support is planned, but
> >         not
> >         right now.
> >
> >
> > Could you expand a little on this subject?  Does that mean I can't
> use
> > XML syntax in Scala files?  What happens if I do?  Are there any
> > workarounds?
>
> Just tried it with a trivial example.  The eclipse error log pops up
> and
> spits out an assert from the plugin on every edit with xml in the
> file.
> A few edits later the editor hung and I had to restart eclipse.  (Sean
> -- let me know if you need a test case for this.)  I'm assuming we
> need
> to avoid xml until the next rev of the plugin.
>
> Before I messed with xml, the code completion looked very cool and
> responsive.  The plugin looks like it'll be wonderful when we get it
> shaken out a bit.
>
>
>
>
>

[n8han]

(Sorry if this dups, but after a day my Gmane message is still not showing.)

Does this beta support targeting JDK 1.5? I created a new project with the beta, and set target JDK 1.5 in the Scala panel of the project options, but I'm still getting warnings when I use an annotation.

Otherwise, looks great!

Nathan

[Amir Michail]

On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:

> Yes, the XML lack of support is indicated by an assert(false)
> implementation of the XML methods.
>
> If XMLSTART is encountered, the plugin will just blowup, I
> should probably suppress this token and ignore XML
> completely.
>
> <rant>
> XML is going to be a pain to support, especially in the
> non-delimited form that Scala supports. Essentially, if
> you see a '>' in an XML block, you have no idea if its
> the end, the beginning of the end, or the end of the
> beginning. Also, Scala separates its lexical and
> syntactic parts, while XML does not. The only way to
> know that you are outside of an XML block is to...
> parse the entire XML block! This all stems

What's wrong with parsing the entire XML block?  Is that hard to do
with the current plugin architecture?

Amir

> back to the fact that XML was not designed to be
> edited by humans, rather it was designed to be
> processed quickly by computers.
> </rant>
>
> As far as I know, there are no incremental error
> recovering parsers out there for XML that can be
> used in an editor context. If anyone knows of such
> a beast, please let me know.
>
> Sean
>
> 引言 Lee MIghdoll <lee@...>:
>
> > > On 9/18/07, sean mcdirmid <sean.mcdirmid@...> wrote:
> > >         * There is currently no XML support. Support is planned, but
> > >         not
> > >         right now.
> > >
> > >
> > > Could you expand a little on this subject?  Does that mean I can't
> > use
> > > XML syntax in Scala files?  What happens if I do?  Are there any
> > > workarounds?
> >
> > Just tried it with a trivial example.  The eclipse error log pops up
> > and
> > spits out an assert from the plugin on every edit with xml in the
> > file.
> > A few edits later the editor hung and I had to restart eclipse.  (Sean
> > -- let me know if you need a test case for this.)  I'm assuming we
> > need
> > to avoid xml until the next rev of the plugin.
> >
> > Before I messed with xml, the code completion looked very cool and
> > responsive.  The plugin looks like it'll be wonderful when we get it
> > shaken out a bit.
> >
> >
> >
> >
> >
>
>

[sean.mcdirmid]

We can definitely parse the whole block, and if people type only
well-formed XML in each edit, we have no problem. Of course,
thats called a structure editor, and they are incredibly unusable.

How do we handle intermediate edits? E.g., someone begins to
type some XML...the XML parser doesn't have much error recovery
in it, it will only determine that the block is invalid when it hits
EOF. It can't tell us where the incomplete XML block ends.

Thats the big issue, how do we handle people editing XML?

Sean

引言 Amir Michail <amichail@...>:
> On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:

> What's wrong with parsing the entire XML block?  Is that hard to do
> with the current plugin architecture?

[Amir Michail]

On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:

> We can definitely parse the whole block, and if people type only
> well-formed XML in each edit, we have no problem. Of course,
> thats called a structure editor, and they are incredibly unusable.
>
> How do we handle intermediate edits? E.g., someone begins to
> type some XML...the XML parser doesn't have much error recovery
> in it, it will only determine that the block is invalid when it hits
> EOF. It can't tell us where the incomplete XML block ends.
>
> Thats the big issue, how do we handle people editing XML?
>

People generally enter XML in a structured way, so take advantage of that.

Amir

> Sean
>
> 引言 Amir Michail <amichail@...>:
> > On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:
>
> > What's wrong with parsing the entire XML block?  Is that hard to do
> > with the current plugin architecture?
>
>

[Amir Michail]

On 9/19/07, Amir Michail <amichail@...> wrote:

> On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:
> > We can definitely parse the whole block, and if people type only
> > well-formed XML in each edit, we have no problem. Of course,
> > thats called a structure editor, and they are incredibly unusable.
> >
> > How do we handle intermediate edits? E.g., someone begins to
> > type some XML...the XML parser doesn't have much error recovery
> > in it, it will only determine that the block is invalid when it hits
> > EOF. It can't tell us where the incomplete XML block ends.
> >
> > Thats the big issue, how do we handle people editing XML?
> >
>
> People generally enter XML in a structured way, so take advantage of that.
>

BTW, I believe that such issues would be non-existent with an
IDE-based approach to programming where one is always working with
syntactically correct code.

See:  http://en.wikipedia.org/wiki/Intentional_programming

Amir

> Amir
>
> > Sean
> >
> > 引言 Amir Michail <amichail@...>:
> > > On 9/19/07, sean.mcdirmid@... <sean.mcdirmid@...> wrote:
> >
> > > What's wrong with parsing the entire XML block?  Is that hard to do
> > > with the current plugin architecture?
> >
> >
>

[sean.mcdirmid]

Hi Alex,

Definitely! These are the most interesting bugs: the build compiler
says yes but the presentation compiler chokes on them. Its
usually because I'm not adapting right (T required on T, for some
reason the T symbol is being duplicated and not reused), or
because my incremental compiler algorithm does something
that the batch compiler algorithm doesn't. They are based on
the same code, but there are a lot of hacks to make type checking
incremental.

Curious, did you build first before you opened up the files in the
editor? This sounds like the IDE file wasn't found or something,
but it could be that your code does something I didn't anticipate.

Thanks,

Sean

引言 Alex Boisvert <boisvert@...>:

> Hi Sean,
>
> What kind of bug reports are you interested in at this time?   For
> example,
> I have source files that compile just fine although the plugin
> red-underlines some tokens with messages such as:
>
> 1) type mismatch; found : T  required T
> 2) BAD:null   (on the "case" of case classes)
> 3) bad signature   (on an object declaration)
> ...
>
> Is it worth filing bugs for these with my source attached?   (Again,
> the
> source compiles fine so this is mostly visual noise)
>
> alex
>