New parser branch (Was: Dumping the source DOM?)

[Roberto Raggi]

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<AST*> 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