From kdevelop-devel Thu Jul 14 14:21:03 2005 From: Roberto Raggi Date: Thu, 14 Jul 2005 14:21:03 +0000 To: kdevelop-devel Subject: Re: New parser branch (Was: Dumping the source DOM?) Message-Id: <200507141621.04271.roberto () kdevelop ! org> X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=112135099223774 Hi Steven, On Wednesday 13 July 2005 20:16, Steven T. Hatton wrote: > > 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 yeah I tried it. In the very early days I was using a QDomElement node for each AST node. Of course it wasn't a smart idea :-) So I switched to std::auto_ptr and this was another bad idea :-) because now we have a huge amount of call to the memory manager (== new/delete).. In KDevelop 4 I'm using a memory pool. It improves a lot the performances because usually all the nodes in the AST have the same lifetime. You can take a look at the new KDevelop c++ parser.. or the code generated by the KDevelop parser generator http://trolls.troll.no/~rraggi/robe-pg-1.0.tar.gz > > > 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 as I said before.. the better solution is to use a memory pool that contains typed-AST nodes. Have a different type for different nodes is very important. It simplify a lot the code for the visitors. Use an untyped AST(i.e. QDomElement or gcc `tree') is not an option. > 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. you right.. but we're thinking to merge code-model and catalog in one single component. ATM we're trying to use clucene. It seems it provides all the features we need. If we decide to merge catalog and codemodel, than we have to use the same storage for both realtime and one-time symbol lookup. > > 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 yeap. You will never be able to parse everything from an IDE. An IDE needs to be fast! and it needs to understand things in realtime. So you can't ask to an IDE to perform the same kind of analysis perfomed by a compiler. It really doesn't make sense. > > Again, these are just my thoughts. If it seems useful, please use the > ideas. If not, that probably means I'm wrong. :-) ciao robe _______________________________________________ KDevelop-devel mailing list KDevelop-devel@barney.cs.uni-potsdam.de http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel