Thread: [cedet-semantic] How does EDE find C++ implementation files
Brought to you by:
zappo
From: Barry O. <gun...@gm...> - 2013-03-22 14:53:23
|
Hi, if I open a .h file and go to a function declaration and execute semantic-analyze-proto-impl-toggle , I find that it is not able to find the implementation if Emacs has not visited it yet. For example, if I open only Util.h then it won't find the function implementation in Util.cc. But if I open Util.h and Util.cc in Emacs, then it does. I imagine it's because I haven't indicated to EDE a way to find .cc files. The directory structure is like this: (common-sub-root)/inc/Util.h (common-sub-root)/src/Util.cc How may I customize my EDE project to know where to find .cc files? I've observed semantic-analyze-proto-impl-toggle does not lead to a call to ede-expand-filename-impl which calls locate-fcn . |
From: David E. <de...@ra...> - 2013-03-22 20:50:29
|
Barry OReilly writes: > Hi, if I open a .h file and go to a function declaration and execute > semantic-analyze-proto-impl-toggle , I find that it is not able to find the > implementation if Emacs has not visited it yet. For example, if I open only > Util.h then it won't find the function implementation in Util.cc. But if I > open Util.h and Util.cc in Emacs, then it does. > > I imagine it's because I haven't indicated to EDE a way to find .cc files. > > The directory structure is like this: > (common-sub-root)/inc/Util.h > (common-sub-root)/src/Util.cc > How may I customize my EDE project to know where to find .cc files? I've > observed semantic-analyze-proto-impl-toggle does not lead to a call to > ede-expand-filename-impl which calls locate-fcn . The easiest way is to use GNU Global. It will tell Semantic where it can find symbols of this name, and it will then visit those symbols and check if it is the correct definition to your declaration. For using GNU Global, create the tag database in the root of your project. Then use (semanticdb-enable-gnu-global-databases 'c-mode) (semanticdb-enable-gnu-global-databases 'c++-mode) (setq ede-locate-setup-options '(ede-locate-global ede-locate-base)) -David |
From: Barry O. <gun...@gm...> - 2013-03-25 22:03:50
|
> The easiest way is to use GNU Global. It will tell Semantic where it can > find symbols of this name, and it will then visit those symbols and > check if it is the correct definition to your declaration. I downloaded latest GNU Global (6.2.8), ran gtags at the root, opened my Util.h only, issued semantic-analyze-proto-impl-toggle for myUtilFunc, waited for 26 minutes, and then Semantic successfully opened Util.cc and placed me at myUtilFunc's definition. To keep whatever caches there are warm, I kept the same Emacs session open, including the Util.h and Util.cc buffers, went to the same declaration of myUtilFunc in Util.h, and issued semantic-analyze-proto-impl-toggle again. This caused another 26 minute wait. During the command, Emacs visits many .cc files, which are in same the source tree but have nothing to do with my Util class. I executed 'global myUtilFunc' at the command line and that returns very quickly with two .cc files, one of which is the correct one. Another class has a function of the same name. Here's the top lines of an elp profile of the semantic-analyze-proto-impl-toggle command: semantic-analyze-proto-impl-toggle 1 1591.447626 1591.447626 semantic-analyze-tag-references 1 1591.444366 1591.444366 semantic-analyze-tag-references-default 1 1591.444355 1591.444355 semantic--analyze-refs-full-lookup 1 1591.078446 1591.078446 semantic--analyze-refs-full-lookup-with-parents 1 1591.078438 1591.078438 semanticdb-find-tags-collector 3 1590.857997 530.28599900 semanticdb-find-tags-by-name-method 61 1590.700132 26.077051344 semanticdb-deep-find-tags-by-name-method 119 1589.770119 13.359412764 semantic-symref-result-get-tags 2 1589.478069 794.7390345 semantic-find-file-noselect 1238 1542.5541070 1.2460049329 semantic-new-buffer-fcn 1240 121.49295800 0.0979781919 semanticdb-semantic-init-hook-fcn 1240 118.70507000 0.0957298951 semantic--set-buffer-cache 1240 88.824982000 0.0716330500 semanticdb-synchronize-table 2480 88.813512000 0.0358119000 semanticdb-refresh-references 1241 88.650469 0.0714347050 semanticdb-add-reference 8515 88.556084999 0.0104000099 semanticdb-find-table-for-include 8532 88.441814000 0.0103658947 semanticdb-find-table-for-include-c-mode 8532 88.244368000 0.0103427529 semanticdb-find-table-for-include-default 8532 88.193447999 0.0103367848 semanticdb-find-load-unloaded 8329 46.279124000 0.0055563841 semanticdb-file-table-object 8329 46.189997999 0.0055456835 semanticdb-create-database 2258 41.165646999 0.0182310217 semantic-dependency-tag-file 7550 40.495623000 0.0053636586 semanticdb-create-table-for-file 2029 36.623327999 0.0180499398 semanticdb-file-loaded-p 2258 30.506237999 0.0135102914 semanticdb-directory-loaded-p 1913 26.149703000 0.0136694736 semantic--tag-unlink-from-buffer 31971 14.830222999 0.0004638648 semantic--tag-link-to-buffer 32046 14.077294000 0.0004392839 semanticdb-get-database 229 6.6853550000 0.0291936899 semanticdb-load-database 360 6.6024469999 0.0183401305 semanticdb-kill-hook 2844 4.7509360000 0.0016705119 semantic--tag-unlink-cache-from-buffer 1238 4.6449330000 0.0037519652 semantic-tag-components-with-overlays 64017 4.4400929999 6.935...e-05 semantic--tag-link-cache-to-buffer 1240 4.3657529999 0.0035207685 semantic-tag-components-with-overlays-default 64017 3.8343440000 5.989...e-05 semanticdb-enable-gnu-global-hook 1240 2.4876780000 0.0020061919 semanticdb-enable-gnu-global-in-buffer 1240 2.4800890000 0.0020000717 semantic-tag-components 94026 2.0972709999 2.230...e-05 semanticdb-cache-filename 2258 2.0192759999 0.0008942763 semanticdb-file-name-directory 2258 1.8109210000 0.0008020022 |
From: Eric M. L. <er...@si...> - 2013-03-26 00:01:54
|
On 03/25/2013 06:03 PM, Barry OReilly wrote: > > The easiest way is to use GNU Global. It will tell Semantic where it can > > find symbols of this name, and it will then visit those symbols and > > check if it is the correct definition to your declaration. > > I downloaded latest GNU Global (6.2.8), ran gtags at the root, opened my > Util.h only, issued semantic-analyze-proto-impl-toggle for myUtilFunc, > waited for 26 minutes, and then Semantic successfully opened Util.cc and > placed me at myUtilFunc's definition. To keep whatever caches there are > warm, I kept the same Emacs session open, including the Util.h and > Util.cc buffers, went to the same declaration of myUtilFunc in Util.h, > and issued semantic-analyze-proto-impl-toggle again. This caused > another 26 minute wait. During the command, Emacs visits many .cc > files, which are in same the source tree but have nothing to do with my > Util class. > > I executed 'global myUtilFunc' at the command line and that returns very > quickly with two .cc files, one of which is the correct one. Another > class has a function of the same name. > > Here's the top lines of an elp profile of the > semantic-analyze-proto-impl-toggle command: > > semantic-analyze-proto-impl-toggle 1 > 1591.447626 1591.447626 > semantic-analyze-tag-references 1 > 1591.444366 1591.444366 > semantic-analyze-tag-references-default 1 > 1591.444355 1591.444355 > semantic--analyze-refs-full-lookup 1 > 1591.078446 1591.078446 > semantic--analyze-refs-full-lookup-with-parents 1 > 1591.078438 1591.078438 > semanticdb-find-tags-collector 3 > 1590.857997 530.28599900 > semanticdb-find-tags-by-name-method 61 > 1590.700132 26.077051344 > semanticdb-deep-find-tags-by-name-method 119 > 1589.770119 13.359412764 > semantic-symref-result-get-tags 2 > 1589.478069 794.7390345 Well, here's a problem. When adding GNU Global, when it is called via semanticdb-deep-find-tags-by-name, it has to convert all those hits into tags. The only way it can do that is to load the file into a buffer, put the cursor at the hit location, and extract the tag. The problem is that code changes out from under GNU Global, so as you edit code, the line numbers change, so we need to snoop around to find the tag you're looking for. I'm guessing we could have a fast mode that doesn't do that, and just 'trusts' that if it finds a tag by name around some line number, that is good enough. Of course, why are there 1238 hits from global? I'm guessing from your explanation above that the parent of myUtilFunc is some generic word like "std" or something. In order for the impl-proto jump to work, it has to find the correct parent of the symbol you want to toggle on on the off chance that your tag is in a bunch of different names spaces/classes. The assumption, of course, is that you might have oodles of hits on the tag name, and less on the parent name, but your case is the opposite. A quick hack might be to visit the function semantic--analyze-refs-full-lookup and force the if statement to only do the simple lookup. If it "works" and is fast, then we'll know we're on the right track, and perhaps that code should do the simple search first, see if it is successful, then try the slower version. > semantic-find-file-noselect 1238 > 1542.5541070 1.2460049329 Yep, 1238 file hits. That's a lot of files to open. Twice. Not sure about the 26 minutes though. That's just crazy. Eric |
From: Barry O. <gun...@gm...> - 2013-03-26 14:24:37
|
> The problem is that code changes out from under GNU Global, so as you > edit code, the line numbers change, so we need to snoop around to find > the tag you're looking for. Well, if I get the feature working reasonably, I'll probably use it when editing code. Why go through the trouble of snooping around the code when GNU Global's incremental updating is fast? Can't CEDET run 'global -u' and then assume line number accuracy? > Of course, why are there 1238 hits from global? I'm guessing from your > explanation above that the parent of myUtilFunc is some generic word > like "std" or something. In order for the impl-proto jump to work, it > has to find the correct parent of the symbol you want to toggle on on > the off chance that your tag is in a bunch of different names > spaces/classes. It's not in the std namespace. The structure is like: namespace A { namespace B { namespace C { myUtilFunc declaration } } } CEDET visited .cc files with no members in the B or C namespace. Most of the project is in the A namespace, so I'm not sure if it would open files without a namespace A. > The assumption, of course, is that you might have oodles of hits on the > tag name, and less on the parent name, but your case is the opposite. Yes, that's true. I would think this would be true for most projects, since functions are named very particularly and namespaces typically have many members. Thus, shouldn't the default behavior be to get the matches for the tag first and then use parents to narrow that set of results? > A quick hack might be to visit the function > semantic--analyze-refs-full-lookup and force the if statement to only do > the simple lookup. If it "works" and is fast, then we'll know we're on > the right track, and perhaps that code should do the simple search > first, see if it is successful, then try the slower version. Well, it was reasonably fast at about one second, but is now incorrect. It took me to the other definition of a myUtilFunc rather than the correct one. |
From: Eric M. L. <er...@si...> - 2013-03-28 02:34:54
|
On 03/26/2013 10:24 AM, Barry OReilly wrote: > > The problem is that code changes out from under GNU Global, so as you > > edit code, the line numbers change, so we need to snoop around to find > > the tag you're looking for. > > Well, if I get the feature working reasonably, I'll probably use it when > editing code. > > Why go through the trouble of snooping around the code when GNU Global's > incremental updating is fast? Can't CEDET run 'global -u' and then > assume line number accuracy? That seems like a good idea. I had avoided that in case the user had some custom way to call global on their project. If that seems unlikely, I could make it the default and have an option to disable it. I spent some time looking into if it is possible to skip the full file load step and I think doing so will take a bit of time as the entire search feature will need to be re-written, and I'll need to figure out how to test the two flavors, since there are cases where the files need to load. David is also asking about tag linking when it isn't necessary. That is closely related, and skipping the tag linking will speed things up too. Eric |
From: Eric M. L. <er...@si...> - 2013-03-29 01:02:37
|
On 03/27/2013 10:34 PM, Eric M. Ludlam wrote: > On 03/26/2013 10:24 AM, Barry OReilly wrote: >> > The problem is that code changes out from under GNU Global, so as you >> > edit code, the line numbers change, so we need to snoop around to find >> > the tag you're looking for. >> >> Well, if I get the feature working reasonably, I'll probably use it when >> editing code. >> >> Why go through the trouble of snooping around the code when GNU Global's >> incremental updating is fast? Can't CEDET run 'global -u' and then >> assume line number accuracy? > > That seems like a good idea. I had avoided that in case the user had > some custom way to call global on their project. If that seems > unlikely, I could make it the default and have an option to disable it. > > I spent some time looking into if it is possible to skip the full file > load step and I think doing so will take a bit of time as the entire > search feature will need to be re-written, and I'll need to figure out > how to test the two flavors, since there are cases where the files need > to load. I was looking into this more today. The database store tags by character location. GNU Global uses line numbers. There is no map between the two except in the file itself. I think alternative mechanisms may be needed to speed this up. :( Eric |
From: Barry O. <gun...@gm...> - 2013-03-29 13:39:18
|
Could you explain why it's necessary to visit files that are so unrelated? Command line GNU Global indicates two .cc files contain the function I'm searching on, and neither has dependence in one direction or the other on the files CEDET opens. CEDET opens unit test .cc files in completely unrelated areas of the source tree. The only things in common that I can identify are the high level namespace and the fact that they're in this large source tree together. To make semantic-analyze-proto-impl-toggle in particular perform better, you could just ff-find-other-file and look for the tag in that one file. It would be fast without GNU Global, so more readily helpful to general users. If that doesn't find the tag, then perhaps it could fallback to the existing means. Unfortunately, the semantic-symref command suffers the same intolerable processing time due to opening of unrelated .cc files -- but only when GNU Global is enabled via semanticdb-enable-gnu-global-databases. Performance is quite reasonable with the default grepping technique. Using 'global -r' at the command line to find references is fast, so GNU Global does not seem to be the source of the trouble. |
From: Eric M. L. <er...@si...> - 2013-03-30 02:41:28
|
On 03/29/2013 09:39 AM, Barry OReilly wrote: > Could you explain why it's necessary to visit files that are so unrelated? Sure. If you have: A::B::MyFcn all the different MyFcn occurrences need to be checked to see if they are in A::B, and not some other location. That means we need the definitions of A, and A::B, so those are all looked up and fully defined as well. Your suggestion below of just looking up the actual locations, and not all the other stuff makes sense. I think what we have is a chain that asks for each of the pieces independently, and then compares. This would be completely accurate. A short-cut version would need some specialty code instead of depending on more standardized searches, and it would depend on incomplete info. That Might be ok. A key starting point would be some code where maybe there are 4 files, and only 2 should get loaded, but in the current system 4 are. We can then start experimenting to see if we can get the load characteristics correct. A good thing to realize is that the impl-proto toggle was written independently of the global support. Each was tested against different things, and not together. Due to the way the infrastructure works, it is possible to use them together, so I'm glad to know it does work, though the 26 minute thing is a bit silly. You have some other good ideas too. I tend to operate on very small code segments that force strange referencing schemes, or code constructs, not large projects that test efficiency, so having solid requirements in the small test such as "make sure that file doesn't get loaded" is important. Eric |
From: Eric M. L. <er...@si...> - 2013-04-04 02:45:57
|
On 04/01/2013 12:17 PM, Barry OReilly wrote: > Ok. I attached cedet-play.tar.gz to demonstrate the problem on a small > scale. Untar, follow instructions in the README. Hi Barry, Maybe I learned this but then forgot. Global appears to not parse any prototype tags, only actual definitions. This means it doesn't ever find Util.h. That kind of makes it a 1-way search from prototypes down to impl. Anyway, I found this replicating your example in a test environment, so I can currently fail the test. Passing will have to wait to another day. Eric |
From: Barry O. <gun...@gm...> - 2013-04-04 14:04:44
|
> Global appears to not parse any prototype tags, only actual definitions. I'm not sure either how to do that with GNU Global. I'm not set on using it; I tried GNU Global for the first time upon David Engster's recommendation earlier in this thread. Perhaps a useful way to proceed is to get CEDET to toggle with something similar to ff-find-other-file rather than GNU Global. ff-find-other-file uses cc-search-directories to find matching .h and .cc files. If CEDET can leverage this same setting and use Semantic to navigate to the right tag, that would be nice. CEDET could fallback to more exhaustive means if necessary. My custom-set-variables has: '(cc-search-directories (quote ("." "/usr/include" "/usr/local/include/*" "./src" "../src" "../../src" "./include" "../include" "./inc" "../inc"))) This setting allows ff-find-other-file to work in the cedet-play source. On Wed, Apr 3, 2013 at 10:45 PM, Eric M. Ludlam <er...@si...>wrote: > On 04/01/2013 12:17 PM, Barry OReilly wrote: > >> Ok. I attached cedet-play.tar.gz to demonstrate the problem on a small >> scale. Untar, follow instructions in the README. >> > > Hi Barry, > > Maybe I learned this but then forgot. Global appears to not parse any > prototype tags, only actual definitions. > > This means it doesn't ever find Util.h. That kind of makes it a 1-way > search from prototypes down to impl. > > Anyway, I found this replicating your example in a test environment, so I > can currently fail the test. Passing will have to wait to another day. > > Eric > |
From: David E. <de...@ra...> - 2013-04-04 18:04:23
|
Eric M. Ludlam writes: > On 04/01/2013 12:17 PM, Barry OReilly wrote: >> Ok. I attached cedet-play.tar.gz to demonstrate the problem on a small >> scale. Untar, follow instructions in the README. > > Maybe I learned this but then forgot. Global appears to not parse any > prototype tags, only actual definitions. It does not "understand" declarations, that's right, but it can find them as references, so you should be able to see them when searching with '-r'. -David |
From: Eric M. L. <er...@si...> - 2014-01-02 02:34:41
|
On 04/01/2013 12:33 PM, Eric M. Ludlam wrote: > This is great! Thanks! > > Eric > > On 04/01/2013 12:17 PM, Barry OReilly wrote: >> > I tend to operate on very small code segments that force strange >> referencing schemes, or code constructs, not large projects that test >> efficiency, so having solid requirements in the small test such as "make >> sure that file doesn't get loaded" is important. >> >> Ok. I attached cedet-play.tar.gz to demonstrate the problem on a small >> scale. Untar, follow instructions in the README. >> Hi, This is a very long overdue reply: Back when this thread was active, I got most of an automated test suite together based on your examples, and a base concept together for fixing part of the problem. I checked in the test suite, and it passes based on my notes in this thread. The symref tool with GNU Global will still load too many files. The README leaves trying to fix that up for later. I also checked in an optimization which for the tests cuts the number of files loads from somewhere around 7 or 8 files down to 3. This should make this faster than 26 minutes for the original case, but is still too many files. Sorry for the long delay. Eric |
From: Jai D. <day...@gm...> - 2014-02-05 20:08:37
|
have I been banned from this list? On Wed, Jan 1, 2014 at 9:34 PM, Eric M. Ludlam <er...@si...>wrote: > On 04/01/2013 12:33 PM, Eric M. Ludlam wrote: > > This is great! Thanks! > > > > Eric > > > > On 04/01/2013 12:17 PM, Barry OReilly wrote: > >> > I tend to operate on very small code segments that force strange > >> referencing schemes, or code constructs, not large projects that test > >> efficiency, so having solid requirements in the small test such as "make > >> sure that file doesn't get loaded" is important. > >> > >> Ok. I attached cedet-play.tar.gz to demonstrate the problem on a small > >> scale. Untar, follow instructions in the README. > >> > > Hi, > > This is a very long overdue reply: > > Back when this thread was active, I got most of an automated test suite > together based on your examples, and a base concept together for fixing > part of the problem. > > I checked in the test suite, and it passes based on my notes in this > thread. The symref tool with GNU Global will still load too many files. > The README leaves trying to fix that up for later. > > I also checked in an optimization which for the tests cuts the number of > files loads from somewhere around 7 or 8 files down to 3. This should > make this faster than 26 minutes for the original case, but is still too > many files. > > Sorry for the long delay. > Eric > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > |