ctags one more...

Richard Dale Richard_Dale at tipitina.demon.co.uk
Tue Apr 17 20:28:03 UTC 2001


On Tue, 17 Apr 2001, Roland Krause wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > But we have an excellent class parser, which handles "Goto
> > Definition/Declaration" perfectly well. 
> 
> ??? So then let me rant a bit :-) 
> >From a users point of view, the way "Goto Declartion/Definition" is
> available in the current version (KDEVELOP_1_4) sucks! 
>
> These edit fields in the tool bar are a useless duplication of
> functinality alread available in the class browser! On top of that, the
> completion business makes them *extremely* slow, sometimes kdevelop
> seems to literally hang for multiple seconds. Dont know whos fault that
> is but sometimes I thing the completion classes dont reallt scale very
> well. Please edit kdevelop in itself to see this. 
These are UI issues, not parser issues. I've only used KDevelop 1.2, and that
didn't have any 'completion business' - what feature is that? It is certainly
very quick to extract info from the KDevelop class store, any speed issues here
are not related to that.

> What I would need is interactively jumping through code upon RMC just
> as it is in VC6. If I already know the class I am in I might as well go
> to the class browser and open the file myself. But most of the time, I
> dont care what class I am in, I am just searching for something and
> following tags through the code. It has to be fast. 
Currently we provide a visual representation of the underlying parse tree,
where the nodes are represented by icons. If you would like to navigate a parse
tree where the nodes are represented by ctags (ie 13 character text fields), as
keys on a hash table which an associated value of the relevant node(s) in the
class tree. Well you can do that with the current class store structure, plus a
QDict I think. Do you have weak references to the values in a QDict, so you can
remove an entry when it disappears from the class store - you need to keep the
two structures in step?

> Ctags doesnt care whether you're in a class or a struct or whatever. 
> > I measured the performance of
> > the
> > KDevelop parser vs. the ctags one the other day, and KDevelop is
> > faster. I
> > later commented out the QDom insertion code in KDEStudio, and it took
> > 6s to
> > open a project instead of 7s (KDevelop 3.0 took 4s). 
> 
> Ok, but we are talking about nonlinear data structures here so you need
> to say what you opened and how it scales with N. Essentially we are
> talking tree vs. hash table insertion, right? 
If you have measured a problem with the scaleability of the KDevelop class
parser, then we might look into fixing it. We not talking anything without
relevant measurements - ie do we have a problem in the first place?

> > I compared how long KDevelop 2.0 took to open its own project,
> > compared with
> > KDevelop 3.0; they both took the same time 15s.
> 
> Hmmm, that may well be, arent they using the same class parser?
> Shouldnt be such a surprise then. Still, for me this is >> 45s at home
> on my PII 300. I didnt think I had such an old box. Same on the SPARC
> btw.. 
I use an entry level iMac for the 15s timing. I measured both 2.0 and 3.0
because you mentioned a problem with 2.0 where it seemed to hang for 30s on
startup, and I had noticed that happening with 3.0. But both KDevelops seem
quite speedy on my iMac.

> > KDevelop handles classes, methods, functions, variables, structs in
> > C, C++,
> > Objective-C and Java. 
> > 
> > ctags has support for Fortran and Eiffel, which we would get in
> > return for
> > losing Objective-C, the native language of Apple's Cocoa on Mac OS X.
> > I think
> > that is a poor trade-off. I've just successfully ported ctags 3.2 to
> > KDEStudio,
> > so I can confirm that there are no technical problems to replacing
> > the parser in
> > KDevelop, but I can't see any reason why we should.
> 
> I dont say that we should, all I said was, that I would like ctags
> support, so I will hack it in. I also said, we *could* think of
> replacing the parser code for reasons of speed and that wasnt even my
> idea, I am really not that smart, I think it was John who brought it up
> but it makes much sense to me. 
> 
> I dont know any Objective C, is it very different from C++? 
Yes, completely different - much more dynamic (more so than Java even). It is
like Smalltalk embedded in C. Please find attached the java version of the
standard Qt scribble example.

> 
> >From the ctags homepage: 
> 
> Version 5.0.1 [15 April 2001]: Now supports the following languages:
> 
> Assembler, AWK, ASP, BETA, Bourne/Korn/Zsh Shell, C, C++, COBOL,
> Eiffel, Fortran, Java, Lisp, Make, Pascal, Perl, PHP, Python, REXX,
> Ruby, S-Lang, Scheme, Tcl, and Vim.
Gosh! I still think the ctags parser is excellent, but so is the KDevelop one.

-- Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example8.m
Type: text/english
Size: 10698 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20010417/bd51c0c8/attachment.bin>


More information about the KDevelop-devel mailing list