[Monodevelop-devel] [MonoDevelop] Current SVN version may be buggy/dom changes

Lluis Sanchez Gual lluis at novell.com
Mon Jul 28 19:15:00 EDT 2008


Mike, can you give the estimated number of days it will take you to fix
all this?

El dl 28 de 07 de 2008 a les 14:30 -0400, en/na Michael Hutchinson va
escriure:
> On Sun, Jul 27, 2008 at 6:51 AM, Mike Krüger <mkrueger at novell.com> wrote:
> > Hi
> >
> > Today I've submitted my latest dom changes. Do not use the current SVN
> > version for daily use. I've tested the changes and work with the
> > version.
> >
> > We'll add nice features like C#3 support, instant code completion and a
> > new code completion database backend based on sqlite. (Also the new code
> > completion should be faster on large files - but I need to test it)
> > Currently all refactoring support is broken. I think I've fixed it next
> > week. The next weeks I'll work on stabilizing the new changes and adding
> > c#3 support.
> 
> The DOM changes have resulted in severe regressions in the ASP.NET
> binding, among many other things (including C# completion,
> refactoring, stetic, etc). The CodeBehind member generation is
> completely broken, and will have to be ported to use the new DOM, as
> will the BindingService and CodeRefactorer that it uses.
> 
> More importantly, the Parser infrastructure and the type/member lookup
> used by the ASP.NET code completion is totally non-operational. As I'm
> working on the ASP.NET code completion, this makes things difficult
> for me. I can work around it for now, but I need this stuff to be
> operational soon.
> 
> How soon are these likely to be fixed? Could we have a summary of the
> changes that need to be made to existing code to port it to the new
> parser infrastructure and DOM?
> 
> If these won't be fixed soon, I suggest that we move the changes into
> a svn branch, and revert the changes on trunk. We could then remove
> the old DOM and parser infrastructure in order to track down *ALL* the
> places that need to be fixed, before merging back to trunk.
> 



More information about the Monodevelop-devel-list mailing list