Re: [Geany-devel] tagmanager changes
On 02/05/2012 05:46, Lex Trotman wrote:
Hi All,
To summarise since the thread has several subthreads.
1. Tagmanager Understandability
a. I generated the doxygen documentation for tagmanager, it works if
you set recursive, but didn't help much:
- if its not OOP why does it say things like TMWorkspace is derived
from TMWorkObject and similar?
documentation bug IMO
- its not clear how it all goes together, the workspace contains
global tags and work_objects, or is that files and whats the
workspace work objects are document tags. global tags explained in
geany's manual.
difference between source_file and file_entry?
It doesn't look like tm_file_entry_ is really used.
- similarly whats the difference between symbol and tag?
tm_symbol_ doesn't seem to be used.
2. Ability to expand tagmanager to handle names declared in lexical
scopes (not to be confused with struct/class scopes). Here is the
example again with some numbers so I can refer to them
{ struct a o; struct a p;
o./* struct a members */
{ struct b o;
o./* struct b members */
p./* struct a members */
}
o./* struct a members */
p./* struct a members1 */
{ struct c o;
o./* struct c members */
p./* struct a members2 */
}
o./* struct a members */
p./* struct a members */
}
a. yep, tries use more memory than an array, the usual speed/space,
pick one, tradeoff :)
b. @Nick, when you say sort by scope then name, are you wanting to
have an entry in the table for each declaration of the name?
no
- If so this makes the array much bigger to search and your search
speed depends on size, and it doesn't get you anything, you can't
search by scope since you don't know if the name is declared in the
scope you are in or an outer scope compare p at1 and2
- having a single name array which then points to scope info for the
name is a viable approach (disclosure, thats how I'm doing the symbol
table for a language I'm developing) but the table being searched is
usually larger than if you have nested arrays. Being smaller these
are faster to search if the search isn't O(1), hence the suggestion of
trie instead of bsearch.
the gain in simplicity makes a bigger array to search worth it.
Remember, global tags aren't included in the workspace array of
tagmanager, so we're not talking a big number of tags, and we have o(log
n) searching.
4. Ctags parsers
Agree with Nick that the parsers are usable, but if we start modifying
them to handle local declarations then they will be totally
incompatible with the Ctags project so I guess it doesn't matter other
than for getting languages we don't currently parse.
ctags c.c already parses local tags
5. Overloaded symbols
Since Colombans patch, overloaded symbols are now stable for all
practical code (I think theoretically it could get confused if the
overloads are on the same line but thats unlikely enough to ignore for
human generated code)
If you're talking about master, I think I still experienced wrong
parenting on reparsing when removing lines.
6. Moving functionality from symbols.c to tagmanager
a. Since its the 100th anniversary of the Titanic sinking, I think
that shuffling the deckchairs is an apt analogy, the functionality
has to be somewhere, its only useful to move it if the destination
significantly reduces the effort required.
I don't think I suggested moving functionality. I wondered whether TM
could help make symbols.c less complex. I would need to understand the
complexity to know whether this is appropriate or not.
Titanic comment is bizarre. My suggestion could equally apply to
ctagsmanager.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 07/05/2012 17:04, Nick Treleaven wrote: On 02/05/2012 05:46, Lex Trotman wrote: - its not clear how it all goes together, the workspace contains global tags and work_objects, or is that files and whats the workspace work objects are document tags. global tags explained in geany's manual. difference between source_file and file_entry? It doesn't look like tm_file_entry_ is really used. - similarly whats the difference between symbol and tag? tm_symbol_ doesn't seem to be used. Also, tm_project_ is not used either. 2. Ability to expand tagmanager to handle names declared in lexical scopes (not to be confused with struct/class scopes). Here is the example again with some numbers so I can refer to them b. @Nick, when you say sort by scope then name, are you wanting to have an entry in the table for each declaration of the name? no - If so this makes the array much bigger to search and your search speed depends on size, and it doesn't get you anything, you can't search by scope since you don't know if the name is declared in the scope you are in or an outer scope compare p at1 and2 - having a single name array which then points to scope info for the name is a viable approach (disclosure, thats how I'm doing the symbol table for a language I'm developing) but the table being searched is usually larger than if you have nested arrays. Being smaller these are faster to search if the search isn't O(1), hence the suggestion of trie instead of bsearch. the gain in simplicity makes a bigger array to search worth it. Remember, global tags aren't included in the workspace array of tagmanager, so we're not talking a big number of tags, and we have o(log n) searching. Oops, forget the global/workspace division, we still need to search global scopes. But I don't know why you think this is too slow. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Request: multithreaded tag generation?
On 07/11/2011 15:35, Harold Aling wrote: I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files. The Generate tags for all project files causes this massive delay, but I really need that feature. At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation? As a workaround I wonder if the plugin could generate a temporary global tags file (with geany -g). This would be a separate thread. Then tell Geany to load the tags file - this is faster in Geany Git as it avoids resorting all global tags. We would need to add a way to remove global tags though, but this is probably straightforward. Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 8 May 2012 02:04, Nick Treleaven nick.trelea...@btinternet.com wrote:
On 02/05/2012 05:46, Lex Trotman wrote:
Hi All,
To summarise since the thread has several subthreads.
1. Tagmanager Understandability
a. I generated the doxygen documentation for tagmanager, it works if
you set recursive, but didn't help much:
- if its not OOP why does it say things like TMWorkspace is derived
from TMWorkObject and similar?
documentation bug IMO
O-K, clearly the documenter obviously had a meaning for the term in
mind since it occurs in several places, what do you think they meant?
- its not clear how it all goes together, the workspace contains
global tags and work_objects, or is that files and whats the
workspace work objects are document tags. global tags explained in geany's
manual.
And the work objects/document tags are in a different array to global
tags if I read your comment on the next post right?
difference between source_file and file_entry?
It doesn't look like tm_file_entry_ is really used.
Along with your comment below and about project on the next post,
sounds like tm code could be reduced significantly. Might help :)
- similarly whats the difference between symbol and tag?
tm_symbol_ doesn't seem to be used.
2. Ability to expand tagmanager to handle names declared in lexical
scopes (not to be confused with struct/class scopes). Here is the
example again with some numbers so I can refer to them
{ struct a o; struct a p;
o./* struct a members */
{ struct b o;
o./* struct b members */
p./* struct a members */
}
o./* struct a members */
p./* struct a members1 */
{ struct c o;
o./* struct c members */
p./* struct a members2 */
}
o./* struct a members */
p./* struct a members */
}
a. yep, tries use more memory than an array, the usual speed/space,
pick one, tradeoff :)
b. @Nick, when you say sort by scope then name, are you wanting to
have an entry in the table for each declaration of the name?
no
So what did you mean?
- If so this makes the array much bigger to search and your search
speed depends on size, and it doesn't get you anything, you can't
search by scope since you don't know if the name is declared in the
scope you are in or an outer scope compare p at1 and2
- having a single name array which then points to scope info for the
name is a viable approach (disclosure, thats how I'm doing the symbol
table for a language I'm developing) but the table being searched is
usually larger than if you have nested arrays. Being smaller these
are faster to search if the search isn't O(1), hence the suggestion of
trie instead of bsearch.
the gain in simplicity makes a bigger array to search worth it. Remember,
global tags aren't included in the workspace array of tagmanager, so we're
not talking a big number of tags, and we have o(log n) searching.
Ok, but to date document tags don't include local variables (see
below) so they will add many more names, with lots of replication.
4. Ctags parsers
Agree with Nick that the parsers are usable, but if we start modifying
them to handle local declarations then they will be totally
incompatible with the Ctags project so I guess it doesn't matter other
than for getting languages we don't currently parse.
ctags c.c already parses local tags
No it doesn't AFAICT:
on brace open createTags() calls tagCheck() and nest(),
on brace open checkTag() only makes a tag for a preceding function or
contextual entity (== class, enum, namespace struct or union) it does
not look at the contents of the {},
and nest() only recurses if the { opens a class, enum, namespace,
struct, union otherwise it skips everything in the {},
so no local declarations are parsed unless I've missed something?
5. Overloaded symbols
Since Colombans patch, overloaded symbols are now stable for all
practical code (I think theoretically it could get confused if the
overloads are on the same line but thats unlikely enough to ignore for
human generated code)
If you're talking about master, I think I still experienced wrong parenting
on reparsing when removing lines.
HEAD of master gives me no stability problems with C++, can't cause
any problems with C either, can you reproduce?
6. Moving functionality from symbols.c to tagmanager
a. Since its the 100th anniversary of the Titanic sinking, I think
that shuffling the deckchairs is an apt analogy, the functionality
has to be somewhere, its only useful to move it if the destination
significantly reduces the effort required.
I don't think I suggested moving functionality.
OK, I read it that you were suggesting that.
I wondered whether TM could
help make symbols.c less complex. I would need to understand the complexity
to know whether this is appropriate or not.
Titanic comment is bizarre. My suggestion could equally apply to
ctagsmanager.
Oh dear, misdirected attempt at
Re: [Geany-devel] tagmanager changes
On 12-05-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.com wrote: On 02/05/2012 05:46, Lex Trotman wrote: 4. Ctags parsers Agree with Nick that the parsers are usable, but if we start modifying them to handle local declarations then they will be totally incompatible with the Ctags project so I guess it doesn't matter other than for getting languages we don't currently parse. ctags c.c already parses local tags No it doesn't AFAICT: I'm guessing he's referring to the upstream CTags c.c, which does have a l kind for local variables (off by default). See `ctags --list-kinds=C`. I'm not sure if the Geany fork has this, was forked before it was added, or if the guy that wrote TM took it out. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 8 May 2012 13:27, Matthew Brush mbr...@codebrainz.ca wrote: On 12-05-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.com wrote: On 02/05/2012 05:46, Lex Trotman wrote: 4. Ctags parsers Agree with Nick that the parsers are usable, but if we start modifying them to handle local declarations then they will be totally incompatible with the Ctags project so I guess it doesn't matter other than for getting languages we don't currently parse. ctags c.c already parses local tags No it doesn't AFAICT: I'm guessing he's referring to the upstream CTags c.c, which does have a l kind for local variables (off by default). See `ctags --list-kinds=C`. I'm not sure if the Geany fork has this, was forked before it was added, or if the guy that wrote TM took it out. Ok, I havn't looked at Ctags c.c because IIUC from other comments it isn't really mergable with our c.c. Does upstream c.c use tagmanager, and if so how does it structure scopes? (A good exercise for your compiler :) Cheers Lex Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
