New parser branch (Was: Dumping the source DOM?)
Steven T. Hatton
hattons at globalsymmetry.com
Wed Jul 13 20:17:03 UTC 2005
On Wednesday 13 July 2005 10:51, Roberto Raggi wrote:
> Hi Richard!
> On Wednesday 13 July 2005 13:36, Richard Dale wrote:
> > On Wednesday 13 July 2005 13:55, Roberto Raggi wrote:
> > Ashley Winters is suggesting using an xml translation unit dump for the
> > next version of the Smoke bindings library. And he is also suggesting
> > doing
> turns the AST into an xml file should be easy. You must create a visitor
> that coverts the nodes into an xml node.
Glad you agree.
There is another, more intrusive way which *may* have some advantages. That
is, build some of the actual XML DOM into the nodes of the CodeModel (I think
that's where it would go.) It's just an interface for nodes in a tree. It
would constitute adding member functions to the existing nodes. That might
make using XPath on the existing model possible.
It's just an idea, not a request.
> well it is if you want to use it in a realtime environment. I tried a
> couple of months ago with dbxml and it was very slow.
What happens if you run it against a memory resident DOM? Could you pull in
enough of the dbxml to cover the working code loaded in the IDE? If I
understand the existing bdb mechanism (and that's a BIG IF) it is loading a
file at a time. I'm not really sure if that is once when the project is
opened, or only when a given file is opened.
It seems reasonable that the same, or similar, could be done with dbxml. I
guess if you had code that couldn't be parsed to fit into per-token XML
elements, you could save it as raw text in a text node. I'm pretty sure you
could save each individual file as a DOM. Gluing it all back together when
you retreive it may be more difficult.
> I'm working on the error recovery engine. I have a couple of ideas to mix
> "correcting" and "non correcting" error recovery. Unfortunatly in KDevelop
> we need the AST so a full "non correcting" error recovery is not an option.
> Even if it produce a better result :(
Are you saying you need to live with code that won't parse? What if you could
take the part that won't parse and stick it in a text node of a DOM element
until it can be fixed up?
Again, these are just my thoughts. If it seems useful, please use the ideas.
If not, that probably means I'm wrong.
More information about the KDevelop-devel