From kdevelop-devel Wed Jul 13 18:16:13 2005 From: "Steven T. Hatton" Date: Wed, 13 Jul 2005 18:16:13 +0000 To: kdevelop-devel Subject: Re: New parser branch (Was: Dumping the source DOM?) Message-Id: <200507131416.14057.hattons () globalsymmetry ! com> X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=112127867207843 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. -- Regards, Steven _______________________________________________ KDevelop-devel mailing list KDevelop-devel@barney.cs.uni-potsdam.de http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel