[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.lepido] Debugger architecture (was Re: Editor for flowscript file)

Sandor Spruit wrote:

Sylvain Wallez wrote:

Sandor Spruit wrote:

<snip/>

I have recently used the JavaScript debugger in Mozilla. It seemed to work quite good. Just open a webpage, set a breakpoint and off you go.


Yeah, I love it also. But the purpose of the JS debugger in Lepido is different: we want to be able do debug server-side flowscript files. Sure, there is the Swing debugger that comes with Rhino, but having it all in a single environment (including multi-language breakpoints and stacktraces) would definitely be better.


So, you want multi-language (as in: programming language) server-side flowscript debugging? Isn't that a little over-ambitious to start with?


The multi-language debugger potentially targets all interpreted languages used in Cocoon. This includes flowscript, the sitemap, xslt, jxtemplate, etc. I already made some experiments that make me confident that this is possible, and the Lepido proposal outlines the planned architecture.

In my experience: get something that actually works, then take the next step - use refactoring when needed. Divide and conquer.


Sure, the dividing here will be to have a simple debugging framework and a collection or "language drivers". We'll start by the most important ones and implement others as we see the need for them.

Unless, of course, all the components are already lying around anyway.


Just a few successful experiments at intercepting sitemap execution with some AOP techniques. And this makes me pretty much confident that this is technically not that difficult.

To be able to write a debugger driver for something, it must fulfill a few requirements:
- it has to be an engine that "executes" some objects representing "instructions", which can be either terminal (a statement) or composite (a block that adds a level to the stacktrace)
- instructions should be able to provide their locations
- the engine should provide some kind of execution context that can be mapped to local variables


If you look at this list of requirements, this perfectly fits with sitemap and XSLT (at least Xalan which I looked at). JXTemplate doesn't match exactly this architecture, but we should more concentrate on the new Template block. Cocoon form request processing and binding is also a good candidate. Rhino also provides some debugger hooks that we can use.

Some languages will require more than just being able to handle breakpoints and local variable introspection. For the sitemap, we will want to have a look at the various stages of the processing pipeline.

How does that sound?

Sylvain

--
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director