[Mono-dev] Incremental C# compiler

[Jerry Haltom]

The only use I've ever had for edit and continue, which to me, is a very
important use, is in the debugger. I can step through code, find an
error, and quickly replace it immediately, and test the results locally
in that method by stepping back and then forwards again.

Without it, I have to shutdown the entire application, which might have
a large running state to arrive at the bug, and start it again.

On Wed, 2006-07-12 at 13:16 -0500, Jonathan Gilbert wrote:
> t 06:48 PM 12/07/2006 +0200, Robert Jordan wrote:
> >Jonathan Gilbert wrote:
> >> One other possibility which should not be discounted out-of-hand, I think,
> >> is the possibility of resurrecting the interpreter and bringing it
> >> up-to-date. Certainly the hardest part of edit-and-continue of a running
> >
> >Edit-and-continue is best suited to debug/analyze/fix long running
> >applications and/or apps with a long start-up time.
> >The interpreter would kill all benefits of edit-and-continue.
> 
> I disagree with this. The majority of situations where I have seen
> edit-and-continue employed (and have employed it myself) involve GUI
> applications where the logic behind a short event handler is broken. See
> below.
> 
> >Of course, for dudes who use to "massage a method until it works" (TM)
> >the interpreter would be okay, but for those usage patterns
> >I won't implement edit-and-continue ;-)
> 
> Like I said, I don't think the option should be discounted out-of-hand.
> Consider the following:
> 
> 1. The interpreter would only be used for the case where the method being
> edited is *currently executing* on some thread.
> 
> 2. The interpreter would be used to take over only that invocation of the
> method. Thus, any lost speed benefits apply only to code within that
> function for the duration of that call. Situations where a single method is
> in a massively long loop and needs to be edited at runtime are more than
> likely corner cases. Yes, I've written them before, but I've used
> edit-and-continue far more often in GUI applications where the broken code
> is, say, a button click handler that gets an item index from the wrong
> place, or doesn't handle a possible null reference. It's certainly true
> that it's no more than a convenience in this situation, but it's a
> convenience that can greatly reduce development time, since you don't have
> to bring the GUI up to the point of the bug every time you make a change to
> the code.
> 
> 3. Edit-and-continue has never been intended by anyone who has developed it
> to be more than a stopgap measure, a means to test a fix quickly without
> restarting the application. Once the fix has been verified to work, the
> application will inevitably need to be rebuilt at some point. I don't think
> I would feel comfortable using edit-and-continue on a long-running
> application and then running it through to its finish on the "hacked" code.
> I would feel even more uncomfortable running a network server on
> edited-and-continued code.
> 
> 4. The alternative to using an interpreter is very difficult to code. It
> would probably take longer to get right than an entire functional
> interpreter coded from scratch. In essence, it's a choice between having
> the ability to edit methods that are running and not.
> 
> 5. An implementation using an interpreter need not be permanent. It would
> fill an important niche until a developer had the time & expertise to write
> the code to munge the native execution context of the new JIT output.
> 
> 6. An implementation using an interpreter would be inherently
> platform-independent, whereas the "ideal" native version would, as far as I
> can tell, tend to be platform-specific. Even if the native version were
> implemented on some platforms, an interpreter-based implementation could be
> a fallback for the alternative on platforms for which it had not yet been
> written.
> 
> I also happen to think that it's a little bit arrogant to refuse to
> implement a feature on the basis that some people would use it in a pattern
> you disapprove of. It would be a little bit like refusing to implement
> intellisense on the grounds that people only use it because they're too
> lazy to memorize the framework.
> 
> Jonathan Gilbert
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list