CEDET

If you use semantic-symref-data-debug-last-result it will show the 
object that contains the data, and it is named after the tool it uses, 
like grep or global.

Eric

On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> Thanks, Eric.  I think it might be working for me.  At least, when I do
> semantic-symref on a Java function in my project, I get a buffer with a
> list of references.  It's a little slow, however, and I'm wondering if
> it's falling back on Grep and not using my Global tags files.  The
> command cedet-gnu-global-show-root does show the right project root,
> however.
>
> Question:  is there a way to verify it's using Global and not Grep?
>
> Thanks!
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Sunday, May 02, 2010 5:47 AM
>> To: David Ventimiglia
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  I've a few, more-specific questions spliced in below.
>>>
>>>> The basic strategy is to get an EDE project pointing to the root of
>>> all
>>>> your code.  I'm assuming all the languages you mentioned are in one
>>> big
>>>> mega-project.  That top level project then needs to know about all
>> the
>>>> targets.  For simplicity sake, you could have one target per
>> language
>>>> type, or more detailed, one target per language/directory.
>>>
>>> So far, I just started with ede-simple-project, which I created with
>> the
>>> command ede-new while visiting a Java file buried deep in that part
>> of
>>> our source-tree.  This put a file in my $HOME/.ede directory
> defining
>>> that ede-simple-project.  I also have run GNU Global in my project
>> root.
>>> What do I do now to enable completion, lookup, and cross-references
>> for
>>> symbols?
>>
>> Ah, good idea with the simple project.  I'd forgotten about that.
>>
>> If you look in cedet/common/cedet.info in the node:
>>
>> (cedet.info)Top::>  GNU Global
>>
>> It lists all the options for enabling GNU Global in a CEDET project.
>>
>>>> As for the symbol references, you can use any of the different
> tools
>>>> you
>>>> prefer, or none.  If you try it (once you have an EDE project
>>>> specifying
>>>> the root) with the find/grep solution and it is fast enough, then
>> you
>>>> can consider yourself done.
>>>
>>> I made these customizations:
>>>
>>> (require 'cedet)
>>> (global-ede-mode 1)
>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>> (setq ede-locate-setup-options
>>>         '(ede-locate-global
>>>           ede-locate-base))
>>>
>>> But when I invoke the command semantic-symref-symbol on some symbol
>> in a
>>> Java file, I get the message:
>>>
>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>
>>> What does this mean?
>>
>>
>> That means that semantic-symref-filepattern-alist needs to be
>> customized.  If you have a good customization, I'll add it to the
>> default value.
>>
>> Probably something like:
>>
>> (add-to-list 'semantic-symref-filepattern-alist
>> 	'(jde-mode "*.java"))
>>
>> I'll fix the error message to be more obvious.
>>
>> Of course, this also means that it failed to auto-detect the GNU
> Global
>> tags file at the root of your project.  Use  M-x
>> cedet-gnu-global-show-root to determine if the detection is working.
>> If
>> it fails, then there is something in the Global doc that might help,
>> since CEDET just calls global with "-pq" options.
>>
>>> Finally, must one use Global, idutils, locate, etc., to do symbol
>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>
>> The symref tool relies on at least one external tool, but it can use
>> find/grep commands to do it, so the other tools are not required, but
>> will instead provide better and faster results.
>>
>>   >What I
>>> mean is, I gather that semantic is parsing and caching the tags for,
>>> say, the Java files that I visit.  Is it possible to have semantic
>> parse
>>
>> Semantic only parses the tags (like ctags) and not the contents.
>>
>>> ALL my Java source files ahead of time (a la Global, idutils, ctags,
>>> etc.), then just use semanticdb to support completion, lookup, and
>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>> evangelize
>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> more
>>> external tools I have to integrate (like finding Windows versions of
>>> Global, idutils, etc.), the harder that sell becomes.  Or, would it
>>> simply be too much of a performance hit to ask semantic to do what
>>> Global et al are optimized to do very fast?
>>
>> Semantic parses it's own tags because tools like global and ctags
>> provide only "quickie" information, and take many short-cuts to do so.
>> To do what CEDET does with tags, it needs to be much more careful.
>>
>> Semantic also already has trouble with really huge projects, and Emacs
>> Lisp is just the wrong language to implement symbol cross-reference
>> database in do the shear size.
>>
>> Instead, things like Global do a pretty good job on references, so I
>> use
>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>> double-check each "hit" with a real analysis to prove that the hit is
>> really a reference to a given symbol, and not some side-effect of
>> polymorphism or other trick.
>>
>> Anyway, Global is probably your best bet unless find/grep is fast
>> enough
>> for you.
>>
>> Good Luck!
>> Eric
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Thanks, Eric.  Unfortunately, it resolutely insists on using grep, or
nothing at all, and I'm afraid there still must be something fundamental
I'm misunderstanding.  I made customizations in stepwise fashion:

Step 1:  Added to .emacs
(require 'cedet)
(semantic-load-enable-code-helpers)
(global-ede-mode 1)
Result:  semantic-symref works, but uses grep

Step 2:  Added to .emacs
(require 'ede-locate)
(setq ede-locate-setup-options
      '(ede-locate-global
        ede-locate-base))
Result:  semantic-symref works, but uses grep

Step 3:  Added to .emacs
(require 'semantic-symref-grep) 
(add-to-list 'semantic-symref-filepattern-alist '(jde-mode "*.java"))
(add-to-list 'semantic-symref-filepattern-alist '(java-mode "*.java"))
Result:  semantic-symref works, but uses grep

Step 4:  Used ede-new to create a Simple project, which landed in
%HOME%/.ede/
Result:  semantic-symref fails, reporting "No references found".

Here's what the file in %HOME%/.ede/ looks like, where the contents of
:directory and :file just refer to things in my particular project
directory tree:
;; Object cc
;; EDE Simple Project
(ede-simple-project "cc"
  :name "cc"
  :directory
"c:/dev/eng/cc/denali/active/core/app-cc/cc/src/com/guidewire/cc/domain/
financials/impl/"
  :file
"!drive_c!dev!eng!cc!denali!active!core!app-cc!cc!src!com!guidewire!cc!d
omain!financials!impl!ProjSimple.ede"
  :targets 'nil
  )

I must be missing something, but I'm afraid I just can't see what it is.

Best,
David


> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 1:26 PM
> To: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> If you use semantic-symref-data-debug-last-result it will show the
> object that contains the data, and it is named after the tool it uses,
> like grep or global.
> 
> Eric
> 
> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> > Thanks, Eric.  I think it might be working for me.  At least, when I
> do
> > semantic-symref on a Java function in my project, I get a buffer
with
> a
> > list of references.  It's a little slow, however, and I'm wondering
> if
> > it's falling back on Grep and not using my Global tags files.  The
> > command cedet-gnu-global-show-root does show the right project root,
> > however.
> >
> > Question:  is there a way to verify it's using Global and not Grep?
> >
> > Thanks!
> > Best,
> > David
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Sunday, May 02, 2010 5:47 AM
> >> To: David Ventimiglia
> >> Cc: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  I've a few, more-specific questions spliced in
> below.
> >>>
> >>>> The basic strategy is to get an EDE project pointing to the root
> of
> >>> all
> >>>> your code.  I'm assuming all the languages you mentioned are in
> one
> >>> big
> >>>> mega-project.  That top level project then needs to know about
all
> >> the
> >>>> targets.  For simplicity sake, you could have one target per
> >> language
> >>>> type, or more detailed, one target per language/directory.
> >>>
> >>> So far, I just started with ede-simple-project, which I created
> with
> >> the
> >>> command ede-new while visiting a Java file buried deep in that
part
> >> of
> >>> our source-tree.  This put a file in my $HOME/.ede directory
> > defining
> >>> that ede-simple-project.  I also have run GNU Global in my project
> >> root.
> >>> What do I do now to enable completion, lookup, and
cross-references
> >> for
> >>> symbols?
> >>
> >> Ah, good idea with the simple project.  I'd forgotten about that.
> >>
> >> If you look in cedet/common/cedet.info in the node:
> >>
> >> (cedet.info)Top::>  GNU Global
> >>
> >> It lists all the options for enabling GNU Global in a CEDET
project.
> >>
> >>>> As for the symbol references, you can use any of the different
> > tools
> >>>> you
> >>>> prefer, or none.  If you try it (once you have an EDE project
> >>>> specifying
> >>>> the root) with the find/grep solution and it is fast enough, then
> >> you
> >>>> can consider yourself done.
> >>>
> >>> I made these customizations:
> >>>
> >>> (require 'cedet)
> >>> (global-ede-mode 1)
> >>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>> (setq ede-locate-setup-options
> >>>         '(ede-locate-global
> >>>           ede-locate-base))
> >>>
> >>> But when I invoke the command semantic-symref-symbol on some
symbol
> >> in a
> >>> Java file, I get the message:
> >>>
> >>> semantic-symref-tool-grep - Needs to be configured for jde-mode
> >>>
> >>> What does this mean?
> >>
> >>
> >> That means that semantic-symref-filepattern-alist needs to be
> >> customized.  If you have a good customization, I'll add it to the
> >> default value.
> >>
> >> Probably something like:
> >>
> >> (add-to-list 'semantic-symref-filepattern-alist
> >> 	'(jde-mode "*.java"))
> >>
> >> I'll fix the error message to be more obvious.
> >>
> >> Of course, this also means that it failed to auto-detect the GNU
> > Global
> >> tags file at the root of your project.  Use  M-x
> >> cedet-gnu-global-show-root to determine if the detection is
working.
> >> If
> >> it fails, then there is something in the Global doc that might
help,
> >> since CEDET just calls global with "-pq" options.
> >>
> >>> Finally, must one use Global, idutils, locate, etc., to do symbol
> >>> lookups?  Is it possible just to rely on the CEDET tools alone?
> >>
> >> The symref tool relies on at least one external tool, but it can
use
> >> find/grep commands to do it, so the other tools are not required,
> but
> >> will instead provide better and faster results.
> >>
> >>   >What I
> >>> mean is, I gather that semantic is parsing and caching the tags
> for,
> >>> say, the Java files that I visit.  Is it possible to have semantic
> >> parse
> >>
> >> Semantic only parses the tags (like ctags) and not the contents.
> >>
> >>> ALL my Java source files ahead of time (a la Global, idutils,
> ctags,
> >>> etc.), then just use semanticdb to support completion, lookup, and
> >>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >> evangelize
> >>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> > more
> >>> external tools I have to integrate (like finding Windows versions
> of
> >>> Global, idutils, etc.), the harder that sell becomes.  Or, would
it
> >>> simply be too much of a performance hit to ask semantic to do what
> >>> Global et al are optimized to do very fast?
> >>
> >> Semantic parses it's own tags because tools like global and ctags
> >> provide only "quickie" information, and take many short-cuts to do
> so.
> >> To do what CEDET does with tags, it needs to be much more careful.
> >>
> >> Semantic also already has trouble with really huge projects, and
> Emacs
> >> Lisp is just the wrong language to implement symbol cross-reference
> >> database in do the shear size.
> >>
> >> Instead, things like Global do a pretty good job on references, so
I
> >> use
> >> those instead, and deal with the inaccuracy of it.  I'm hoping to
> >> double-check each "hit" with a real analysis to prove that the hit
> is
> >> really a reference to a given symbol, and not some side-effect of
> >> polymorphism or other trick.
> >>
> >> Anyway, Global is probably your best bet unless find/grep is fast
> >> enough
> >> for you.
> >>
> >> Good Luck!
> >> Eric
> >>
> >>
> >>
> >
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> 
>
-----------------------------------------------------------------------
> -------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hi,

Did you you use the GNU global command  "gtags" to create the GLOBAL 
database for your code?  I don't remember if you mentioned doing that or 
not.  You need to create the GTAGS files before global will work on your 
code.

cedet-gnu-global-show-root

will tell you if it is detecting GLOBAL files associated with your 
directory or not.

Eric

On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> Thanks, Eric.  Unfortunately, it resolutely insists on using grep, or
> nothing at all, and I'm afraid there still must be something fundamental
> I'm misunderstanding.  I made customizations in stepwise fashion:
>
> Step 1:  Added to .emacs
> (require 'cedet)
> (semantic-load-enable-code-helpers)
> (global-ede-mode 1)
> Result:  semantic-symref works, but uses grep
>
> Step 2:  Added to .emacs
> (require 'ede-locate)
> (setq ede-locate-setup-options
>        '(ede-locate-global
>          ede-locate-base))
> Result:  semantic-symref works, but uses grep
>
> Step 3:  Added to .emacs
> (require 'semantic-symref-grep)
> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode "*.java"))
> (add-to-list 'semantic-symref-filepattern-alist '(java-mode "*.java"))
> Result:  semantic-symref works, but uses grep
>
> Step 4:  Used ede-new to create a Simple project, which landed in
> %HOME%/.ede/
> Result:  semantic-symref fails, reporting "No references found".
>
> Here's what the file in %HOME%/.ede/ looks like, where the contents of
> :directory and :file just refer to things in my particular project
> directory tree:
> ;; Object cc
> ;; EDE Simple Project
> (ede-simple-project "cc"
>    :name "cc"
>    :directory
> "c:/dev/eng/cc/denali/active/core/app-cc/cc/src/com/guidewire/cc/domain/
> financials/impl/"
>    :file
> "!drive_c!dev!eng!cc!denali!active!core!app-cc!cc!src!com!guidewire!cc!d
> omain!financials!impl!ProjSimple.ede"
>    :targets 'nil
>    )
>
> I must be missing something, but I'm afraid I just can't see what it is.
>
> Best,
> David
>
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 1:26 PM
>> To: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> If you use semantic-symref-data-debug-last-result it will show the
>> object that contains the data, and it is named after the tool it uses,
>> like grep or global.
>>
>> Eric
>>
>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  I think it might be working for me.  At least, when I
>> do
>>> semantic-symref on a Java function in my project, I get a buffer
> with
>> a
>>> list of references.  It's a little slow, however, and I'm wondering
>> if
>>> it's falling back on Grep and not using my Global tags files.  The
>>> command cedet-gnu-global-show-root does show the right project root,
>>> however.
>>>
>>> Question:  is there a way to verify it's using Global and not Grep?
>>>
>>> Thanks!
>>> Best,
>>> David
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>> To: David Ventimiglia
>>>> Cc: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
>> below.
>>>>>
>>>>>> The basic strategy is to get an EDE project pointing to the root
>> of
>>>>> all
>>>>>> your code.  I'm assuming all the languages you mentioned are in
>> one
>>>>> big
>>>>>> mega-project.  That top level project then needs to know about
> all
>>>> the
>>>>>> targets.  For simplicity sake, you could have one target per
>>>> language
>>>>>> type, or more detailed, one target per language/directory.
>>>>>
>>>>> So far, I just started with ede-simple-project, which I created
>> with
>>>> the
>>>>> command ede-new while visiting a Java file buried deep in that
> part
>>>> of
>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>> defining
>>>>> that ede-simple-project.  I also have run GNU Global in my project
>>>> root.
>>>>> What do I do now to enable completion, lookup, and
> cross-references
>>>> for
>>>>> symbols?
>>>>
>>>> Ah, good idea with the simple project.  I'd forgotten about that.
>>>>
>>>> If you look in cedet/common/cedet.info in the node:
>>>>
>>>> (cedet.info)Top::>   GNU Global
>>>>
>>>> It lists all the options for enabling GNU Global in a CEDET
> project.
>>>>
>>>>>> As for the symbol references, you can use any of the different
>>> tools
>>>>>> you
>>>>>> prefer, or none.  If you try it (once you have an EDE project
>>>>>> specifying
>>>>>> the root) with the find/grep solution and it is fast enough, then
>>>> you
>>>>>> can consider yourself done.
>>>>>
>>>>> I made these customizations:
>>>>>
>>>>> (require 'cedet)
>>>>> (global-ede-mode 1)
>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>> (setq ede-locate-setup-options
>>>>>          '(ede-locate-global
>>>>>            ede-locate-base))
>>>>>
>>>>> But when I invoke the command semantic-symref-symbol on some
> symbol
>>>> in a
>>>>> Java file, I get the message:
>>>>>
>>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>>>
>>>>> What does this mean?
>>>>
>>>>
>>>> That means that semantic-symref-filepattern-alist needs to be
>>>> customized.  If you have a good customization, I'll add it to the
>>>> default value.
>>>>
>>>> Probably something like:
>>>>
>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>> 	'(jde-mode "*.java"))
>>>>
>>>> I'll fix the error message to be more obvious.
>>>>
>>>> Of course, this also means that it failed to auto-detect the GNU
>>> Global
>>>> tags file at the root of your project.  Use  M-x
>>>> cedet-gnu-global-show-root to determine if the detection is
> working.
>>>> If
>>>> it fails, then there is something in the Global doc that might
> help,
>>>> since CEDET just calls global with "-pq" options.
>>>>
>>>>> Finally, must one use Global, idutils, locate, etc., to do symbol
>>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>>>
>>>> The symref tool relies on at least one external tool, but it can
> use
>>>> find/grep commands to do it, so the other tools are not required,
>> but
>>>> will instead provide better and faster results.
>>>>
>>>>    >What I
>>>>> mean is, I gather that semantic is parsing and caching the tags
>> for,
>>>>> say, the Java files that I visit.  Is it possible to have semantic
>>>> parse
>>>>
>>>> Semantic only parses the tags (like ctags) and not the contents.
>>>>
>>>>> ALL my Java source files ahead of time (a la Global, idutils,
>> ctags,
>>>>> etc.), then just use semanticdb to support completion, lookup, and
>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>>>> evangelize
>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
>>> more
>>>>> external tools I have to integrate (like finding Windows versions
>> of
>>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
> it
>>>>> simply be too much of a performance hit to ask semantic to do what
>>>>> Global et al are optimized to do very fast?
>>>>
>>>> Semantic parses it's own tags because tools like global and ctags
>>>> provide only "quickie" information, and take many short-cuts to do
>> so.
>>>> To do what CEDET does with tags, it needs to be much more careful.
>>>>
>>>> Semantic also already has trouble with really huge projects, and
>> Emacs
>>>> Lisp is just the wrong language to implement symbol cross-reference
>>>> database in do the shear size.
>>>>
>>>> Instead, things like Global do a pretty good job on references, so
> I
>>>> use
>>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>>>> double-check each "hit" with a real analysis to prove that the hit
>> is
>>>> really a reference to a given symbol, and not some side-effect of
>>>> polymorphism or other trick.
>>>>
>>>> Anyway, Global is probably your best bet unless find/grep is fast
>>>> enough
>>>> for you.
>>>>
>>>> Good Luck!
>>>> Eric
>>>>
>>>>
>>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>
>>
> -----------------------------------------------------------------------
>> -------
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Hi Eric,

Sorry for not including that, but yes, I did.  The command
cedet-gnu-global-show-root does indeed report the root directory that
contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
cedet-gnu-global-search, and then invoke that command while in a Java
file below my project root, it seems to work.  I.e., I define:

(defun foo ()
  (interactive)
  (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))

Where "getOpenReserves" is the tag I'm cross-referencing.  If I run the
command foo while in a .java file, I get a *CEDET Global* buffer with
the appropriate tags pulled from GTAGS.  Evidently, semantic-symref and
semantic-symref-global are not calling the cedet-gnu-global-search
function in the right way.

Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 3:03 PM
> To: David Ventimiglia
> Cc: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> Hi,
> 
> Did you you use the GNU global command  "gtags" to create the GLOBAL
> database for your code?  I don't remember if you mentioned doing that
> or
> not.  You need to create the GTAGS files before global will work on
> your
> code.
> 
> cedet-gnu-global-show-root
> 
> will tell you if it is detecting GLOBAL files associated with your
> directory or not.
> 
> Eric
> 
> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> > Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
or
> > nothing at all, and I'm afraid there still must be something
> fundamental
> > I'm misunderstanding.  I made customizations in stepwise fashion:
> >
> > Step 1:  Added to .emacs
> > (require 'cedet)
> > (semantic-load-enable-code-helpers)
> > (global-ede-mode 1)
> > Result:  semantic-symref works, but uses grep
> >
> > Step 2:  Added to .emacs
> > (require 'ede-locate)
> > (setq ede-locate-setup-options
> >        '(ede-locate-global
> >          ede-locate-base))
> > Result:  semantic-symref works, but uses grep
> >
> > Step 3:  Added to .emacs
> > (require 'semantic-symref-grep)
> > (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
"*.java"))
> > (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> "*.java"))
> > Result:  semantic-symref works, but uses grep
> >
> > Step 4:  Used ede-new to create a Simple project, which landed in
> > %HOME%/.ede/
> > Result:  semantic-symref fails, reporting "No references found".
> >
> > Here's what the file in %HOME%/.ede/ looks like, where the contents
> of
> > :directory and :file just refer to things in my particular project
> > directory tree:
> > ;; Object cc
> > ;; EDE Simple Project
> > (ede-simple-project "cc"
> >    :name "cc"
> >    :directory
> > "c:/dev/eng/cc/denali/active/core/app-
> cc/cc/src/com/guidewire/cc/domain/
> > financials/impl/"
> >    :file
> > "!drive_c!dev!eng!cc!denali!active!core!app-
> cc!cc!src!com!guidewire!cc!d
> > omain!financials!impl!ProjSimple.ede"
> >    :targets 'nil
> >    )
> >
> > I must be missing something, but I'm afraid I just can't see what it
> is.
> >
> > Best,
> > David
> >
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 1:26 PM
> >> To: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> If you use semantic-symref-data-debug-last-result it will show the
> >> object that contains the data, and it is named after the tool it
> uses,
> >> like grep or global.
> >>
> >> Eric
> >>
> >> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  I think it might be working for me.  At least, when
> I
> >> do
> >>> semantic-symref on a Java function in my project, I get a buffer
> > with
> >> a
> >>> list of references.  It's a little slow, however, and I'm
wondering
> >> if
> >>> it's falling back on Grep and not using my Global tags files.  The
> >>> command cedet-gnu-global-show-root does show the right project
> root,
> >>> however.
> >>>
> >>> Question:  is there a way to verify it's using Global and not
Grep?
> >>>
> >>> Thanks!
> >>> Best,
> >>> David
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>> To: David Ventimiglia
> >>>> Cc: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
> >> below.
> >>>>>
> >>>>>> The basic strategy is to get an EDE project pointing to the
root
> >> of
> >>>>> all
> >>>>>> your code.  I'm assuming all the languages you mentioned are in
> >> one
> >>>>> big
> >>>>>> mega-project.  That top level project then needs to know about
> > all
> >>>> the
> >>>>>> targets.  For simplicity sake, you could have one target per
> >>>> language
> >>>>>> type, or more detailed, one target per language/directory.
> >>>>>
> >>>>> So far, I just started with ede-simple-project, which I created
> >> with
> >>>> the
> >>>>> command ede-new while visiting a Java file buried deep in that
> > part
> >>>> of
> >>>>> our source-tree.  This put a file in my $HOME/.ede directory
> >>> defining
> >>>>> that ede-simple-project.  I also have run GNU Global in my
> project
> >>>> root.
> >>>>> What do I do now to enable completion, lookup, and
> > cross-references
> >>>> for
> >>>>> symbols?
> >>>>
> >>>> Ah, good idea with the simple project.  I'd forgotten about that.
> >>>>
> >>>> If you look in cedet/common/cedet.info in the node:
> >>>>
> >>>> (cedet.info)Top::>   GNU Global
> >>>>
> >>>> It lists all the options for enabling GNU Global in a CEDET
> > project.
> >>>>
> >>>>>> As for the symbol references, you can use any of the different
> >>> tools
> >>>>>> you
> >>>>>> prefer, or none.  If you try it (once you have an EDE project
> >>>>>> specifying
> >>>>>> the root) with the find/grep solution and it is fast enough,
> then
> >>>> you
> >>>>>> can consider yourself done.
> >>>>>
> >>>>> I made these customizations:
> >>>>>
> >>>>> (require 'cedet)
> >>>>> (global-ede-mode 1)
> >>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>> (setq ede-locate-setup-options
> >>>>>          '(ede-locate-global
> >>>>>            ede-locate-base))
> >>>>>
> >>>>> But when I invoke the command semantic-symref-symbol on some
> > symbol
> >>>> in a
> >>>>> Java file, I get the message:
> >>>>>
> >>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
> >>>>>
> >>>>> What does this mean?
> >>>>
> >>>>
> >>>> That means that semantic-symref-filepattern-alist needs to be
> >>>> customized.  If you have a good customization, I'll add it to the
> >>>> default value.
> >>>>
> >>>> Probably something like:
> >>>>
> >>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>> 	'(jde-mode "*.java"))
> >>>>
> >>>> I'll fix the error message to be more obvious.
> >>>>
> >>>> Of course, this also means that it failed to auto-detect the GNU
> >>> Global
> >>>> tags file at the root of your project.  Use  M-x
> >>>> cedet-gnu-global-show-root to determine if the detection is
> > working.
> >>>> If
> >>>> it fails, then there is something in the Global doc that might
> > help,
> >>>> since CEDET just calls global with "-pq" options.
> >>>>
> >>>>> Finally, must one use Global, idutils, locate, etc., to do
symbol
> >>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
> >>>>
> >>>> The symref tool relies on at least one external tool, but it can
> > use
> >>>> find/grep commands to do it, so the other tools are not required,
> >> but
> >>>> will instead provide better and faster results.
> >>>>
> >>>>    >What I
> >>>>> mean is, I gather that semantic is parsing and caching the tags
> >> for,
> >>>>> say, the Java files that I visit.  Is it possible to have
> semantic
> >>>> parse
> >>>>
> >>>> Semantic only parses the tags (like ctags) and not the contents.
> >>>>
> >>>>> ALL my Java source files ahead of time (a la Global, idutils,
> >> ctags,
> >>>>> etc.), then just use semanticdb to support completion, lookup,
> and
> >>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >>>> evangelize
> >>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> >>> more
> >>>>> external tools I have to integrate (like finding Windows
versions
> >> of
> >>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
> > it
> >>>>> simply be too much of a performance hit to ask semantic to do
> what
> >>>>> Global et al are optimized to do very fast?
> >>>>
> >>>> Semantic parses it's own tags because tools like global and ctags
> >>>> provide only "quickie" information, and take many short-cuts to
do
> >> so.
> >>>> To do what CEDET does with tags, it needs to be much more
careful.
> >>>>
> >>>> Semantic also already has trouble with really huge projects, and
> >> Emacs
> >>>> Lisp is just the wrong language to implement symbol cross-
> reference
> >>>> database in do the shear size.
> >>>>
> >>>> Instead, things like Global do a pretty good job on references,
so
> > I
> >>>> use
> >>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
> >>>> double-check each "hit" with a real analysis to prove that the
hit
> >> is
> >>>> really a reference to a given symbol, and not some side-effect of
> >>>> polymorphism or other trick.
> >>>>
> >>>> Anyway, Global is probably your best bet unless find/grep is fast
> >>>> enough
> >>>> for you.
> >>>>
> >>>> Good Luck!
> >>>> Eric
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ---------
> >>> _______________________________________________
> >>> cedet-semantic mailing list
> >>> cedet-semantic@...
> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >>
> >>
> >
---------------------------------------------------------------------
> --
> >> -------
> >> _______________________________________________
> >> cedet-semantic mailing list
> >> cedet-semantic@...
> >> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >

Looking in semantic-symref, I see that the location of GPATH (a GNU 
Global tags file) needs to exist in the directory that is equivalent to 
what EDE returns as the root directory.

I think you can also set semantic-symref-tool to be 'global to turn off 
the auto-detect feature.  In that case, I don't think anything needs to 
match.

Eric

On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> Hi Eric,
>
> Sorry for not including that, but yes, I did.  The command
> cedet-gnu-global-show-root does indeed report the root directory that
> contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
> cedet-gnu-global-search, and then invoke that command while in a Java
> file below my project root, it seems to work.  I.e., I define:
>
> (defun foo ()
>    (interactive)
>    (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))
>
> Where "getOpenReserves" is the tag I'm cross-referencing.  If I run the
> command foo while in a .java file, I get a *CEDET Global* buffer with
> the appropriate tags pulled from GTAGS.  Evidently, semantic-symref and
> semantic-symref-global are not calling the cedet-gnu-global-search
> function in the right way.
>
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 3:03 PM
>> To: David Ventimiglia
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> Hi,
>>
>> Did you you use the GNU global command  "gtags" to create the GLOBAL
>> database for your code?  I don't remember if you mentioned doing that
>> or
>> not.  You need to create the GTAGS files before global will work on
>> your
>> code.
>>
>> cedet-gnu-global-show-root
>>
>> will tell you if it is detecting GLOBAL files associated with your
>> directory or not.
>>
>> Eric
>>
>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
> or
>>> nothing at all, and I'm afraid there still must be something
>> fundamental
>>> I'm misunderstanding.  I made customizations in stepwise fashion:
>>>
>>> Step 1:  Added to .emacs
>>> (require 'cedet)
>>> (semantic-load-enable-code-helpers)
>>> (global-ede-mode 1)
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 2:  Added to .emacs
>>> (require 'ede-locate)
>>> (setq ede-locate-setup-options
>>>         '(ede-locate-global
>>>           ede-locate-base))
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 3:  Added to .emacs
>>> (require 'semantic-symref-grep)
>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> "*.java"))
>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
>> "*.java"))
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 4:  Used ede-new to create a Simple project, which landed in
>>> %HOME%/.ede/
>>> Result:  semantic-symref fails, reporting "No references found".
>>>
>>> Here's what the file in %HOME%/.ede/ looks like, where the contents
>> of
>>> :directory and :file just refer to things in my particular project
>>> directory tree:
>>> ;; Object cc
>>> ;; EDE Simple Project
>>> (ede-simple-project "cc"
>>>     :name "cc"
>>>     :directory
>>> "c:/dev/eng/cc/denali/active/core/app-
>> cc/cc/src/com/guidewire/cc/domain/
>>> financials/impl/"
>>>     :file
>>> "!drive_c!dev!eng!cc!denali!active!core!app-
>> cc!cc!src!com!guidewire!cc!d
>>> omain!financials!impl!ProjSimple.ede"
>>>     :targets 'nil
>>>     )
>>>
>>> I must be missing something, but I'm afraid I just can't see what it
>> is.
>>>
>>> Best,
>>> David
>>>
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Tuesday, May 04, 2010 1:26 PM
>>>> To: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> If you use semantic-symref-data-debug-last-result it will show the
>>>> object that contains the data, and it is named after the tool it
>> uses,
>>>> like grep or global.
>>>>
>>>> Eric
>>>>
>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>>>> Thanks, Eric.  I think it might be working for me.  At least, when
>> I
>>>> do
>>>>> semantic-symref on a Java function in my project, I get a buffer
>>> with
>>>> a
>>>>> list of references.  It's a little slow, however, and I'm
> wondering
>>>> if
>>>>> it's falling back on Grep and not using my Global tags files.  The
>>>>> command cedet-gnu-global-show-root does show the right project
>> root,
>>>>> however.
>>>>>
>>>>> Question:  is there a way to verify it's using Global and not
> Grep?
>>>>>
>>>>> Thanks!
>>>>> Best,
>>>>> David
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>>>> To: David Ventimiglia
>>>>>> Cc: cedet-semantic@...
>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>> JDEE
>>>>> user
>>>>>> for a (mostly) Java project
>>>>>>
>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
>>>> below.
>>>>>>>
>>>>>>>> The basic strategy is to get an EDE project pointing to the
> root
>>>> of
>>>>>>> all
>>>>>>>> your code.  I'm assuming all the languages you mentioned are in
>>>> one
>>>>>>> big
>>>>>>>> mega-project.  That top level project then needs to know about
>>> all
>>>>>> the
>>>>>>>> targets.  For simplicity sake, you could have one target per
>>>>>> language
>>>>>>>> type, or more detailed, one target per language/directory.
>>>>>>>
>>>>>>> So far, I just started with ede-simple-project, which I created
>>>> with
>>>>>> the
>>>>>>> command ede-new while visiting a Java file buried deep in that
>>> part
>>>>>> of
>>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>>>> defining
>>>>>>> that ede-simple-project.  I also have run GNU Global in my
>> project
>>>>>> root.
>>>>>>> What do I do now to enable completion, lookup, and
>>> cross-references
>>>>>> for
>>>>>>> symbols?
>>>>>>
>>>>>> Ah, good idea with the simple project.  I'd forgotten about that.
>>>>>>
>>>>>> If you look in cedet/common/cedet.info in the node:
>>>>>>
>>>>>> (cedet.info)Top::>    GNU Global
>>>>>>
>>>>>> It lists all the options for enabling GNU Global in a CEDET
>>> project.
>>>>>>
>>>>>>>> As for the symbol references, you can use any of the different
>>>>> tools
>>>>>>>> you
>>>>>>>> prefer, or none.  If you try it (once you have an EDE project
>>>>>>>> specifying
>>>>>>>> the root) with the find/grep solution and it is fast enough,
>> then
>>>>>> you
>>>>>>>> can consider yourself done.
>>>>>>>
>>>>>>> I made these customizations:
>>>>>>>
>>>>>>> (require 'cedet)
>>>>>>> (global-ede-mode 1)
>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>>>> (setq ede-locate-setup-options
>>>>>>>           '(ede-locate-global
>>>>>>>             ede-locate-base))
>>>>>>>
>>>>>>> But when I invoke the command semantic-symref-symbol on some
>>> symbol
>>>>>> in a
>>>>>>> Java file, I get the message:
>>>>>>>
>>>>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>>>>>
>>>>>>> What does this mean?
>>>>>>
>>>>>>
>>>>>> That means that semantic-symref-filepattern-alist needs to be
>>>>>> customized.  If you have a good customization, I'll add it to the
>>>>>> default value.
>>>>>>
>>>>>> Probably something like:
>>>>>>
>>>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>>>> 	'(jde-mode "*.java"))
>>>>>>
>>>>>> I'll fix the error message to be more obvious.
>>>>>>
>>>>>> Of course, this also means that it failed to auto-detect the GNU
>>>>> Global
>>>>>> tags file at the root of your project.  Use  M-x
>>>>>> cedet-gnu-global-show-root to determine if the detection is
>>> working.
>>>>>> If
>>>>>> it fails, then there is something in the Global doc that might
>>> help,
>>>>>> since CEDET just calls global with "-pq" options.
>>>>>>
>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> symbol
>>>>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>>>>>
>>>>>> The symref tool relies on at least one external tool, but it can
>>> use
>>>>>> find/grep commands to do it, so the other tools are not required,
>>>> but
>>>>>> will instead provide better and faster results.
>>>>>>
>>>>>>     >What I
>>>>>>> mean is, I gather that semantic is parsing and caching the tags
>>>> for,
>>>>>>> say, the Java files that I visit.  Is it possible to have
>> semantic
>>>>>> parse
>>>>>>
>>>>>> Semantic only parses the tags (like ctags) and not the contents.
>>>>>>
>>>>>>> ALL my Java source files ahead of time (a la Global, idutils,
>>>> ctags,
>>>>>>> etc.), then just use semanticdb to support completion, lookup,
>> and
>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>>>>>> evangelize
>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
>>>>> more
>>>>>>> external tools I have to integrate (like finding Windows
> versions
>>>> of
>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
>>> it
>>>>>>> simply be too much of a performance hit to ask semantic to do
>> what
>>>>>>> Global et al are optimized to do very fast?
>>>>>>
>>>>>> Semantic parses it's own tags because tools like global and ctags
>>>>>> provide only "quickie" information, and take many short-cuts to
> do
>>>> so.
>>>>>> To do what CEDET does with tags, it needs to be much more
> careful.
>>>>>>
>>>>>> Semantic also already has trouble with really huge projects, and
>>>> Emacs
>>>>>> Lisp is just the wrong language to implement symbol cross-
>> reference
>>>>>> database in do the shear size.
>>>>>>
>>>>>> Instead, things like Global do a pretty good job on references,
> so
>>> I
>>>>>> use
>>>>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>>>>>> double-check each "hit" with a real analysis to prove that the
> hit
>>>> is
>>>>>> really a reference to a given symbol, and not some side-effect of
>>>>>> polymorphism or other trick.
>>>>>>
>>>>>> Anyway, Global is probably your best bet unless find/grep is fast
>>>>>> enough
>>>>>> for you.
>>>>>>
>>>>>> Good Luck!
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>> ---------
>>>>> _______________________________________________
>>>>> cedet-semantic mailing list
>>>>> cedet-semantic@...
>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>
>>>>
>>>>
>>>
> ---------------------------------------------------------------------
>> --
>>>> -------
>>>> _______________________________________________
>>>> cedet-semantic mailing list
>>>> cedet-semantic@...
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Great!  That worked!  I added this to java-mode-hook:

(lambda () (setq semantic-symref-tool 'global))

So, should I be setting this variable, or is there a way to get EDE to
return the proper root directory?  Very likely, I've not set up my EDE
project correctly.

Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 4:41 PM
> To: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> Looking in semantic-symref, I see that the location of GPATH (a GNU
> Global tags file) needs to exist in the directory that is equivalent
to
> what EDE returns as the root directory.
> 
> I think you can also set semantic-symref-tool to be 'global to turn
off
> the auto-detect feature.  In that case, I don't think anything needs
to
> match.
> 
> Eric
> 
> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> > Hi Eric,
> >
> > Sorry for not including that, but yes, I did.  The command
> > cedet-gnu-global-show-root does indeed report the root directory
that
> > contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
> > cedet-gnu-global-search, and then invoke that command while in a
Java
> > file below my project root, it seems to work.  I.e., I define:
> >
> > (defun foo ()
> >    (interactive)
> >    (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))
> >
> > Where "getOpenReserves" is the tag I'm cross-referencing.  If I run
> the
> > command foo while in a .java file, I get a *CEDET Global* buffer
with
> > the appropriate tags pulled from GTAGS.  Evidently, semantic-symref
> and
> > semantic-symref-global are not calling the cedet-gnu-global-search
> > function in the right way.
> >
> > Best,
> > David
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 3:03 PM
> >> To: David Ventimiglia
> >> Cc: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> Hi,
> >>
> >> Did you you use the GNU global command  "gtags" to create the
GLOBAL
> >> database for your code?  I don't remember if you mentioned doing
> that
> >> or
> >> not.  You need to create the GTAGS files before global will work on
> >> your
> >> code.
> >>
> >> cedet-gnu-global-show-root
> >>
> >> will tell you if it is detecting GLOBAL files associated with your
> >> directory or not.
> >>
> >> Eric
> >>
> >> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
> > or
> >>> nothing at all, and I'm afraid there still must be something
> >> fundamental
> >>> I'm misunderstanding.  I made customizations in stepwise fashion:
> >>>
> >>> Step 1:  Added to .emacs
> >>> (require 'cedet)
> >>> (semantic-load-enable-code-helpers)
> >>> (global-ede-mode 1)
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 2:  Added to .emacs
> >>> (require 'ede-locate)
> >>> (setq ede-locate-setup-options
> >>>         '(ede-locate-global
> >>>           ede-locate-base))
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 3:  Added to .emacs
> >>> (require 'semantic-symref-grep)
> >>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> > "*.java"))
> >>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> >> "*.java"))
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 4:  Used ede-new to create a Simple project, which landed in
> >>> %HOME%/.ede/
> >>> Result:  semantic-symref fails, reporting "No references found".
> >>>
> >>> Here's what the file in %HOME%/.ede/ looks like, where the
contents
> >> of
> >>> :directory and :file just refer to things in my particular project
> >>> directory tree:
> >>> ;; Object cc
> >>> ;; EDE Simple Project
> >>> (ede-simple-project "cc"
> >>>     :name "cc"
> >>>     :directory
> >>> "c:/dev/eng/cc/denali/active/core/app-
> >> cc/cc/src/com/guidewire/cc/domain/
> >>> financials/impl/"
> >>>     :file
> >>> "!drive_c!dev!eng!cc!denali!active!core!app-
> >> cc!cc!src!com!guidewire!cc!d
> >>> omain!financials!impl!ProjSimple.ede"
> >>>     :targets 'nil
> >>>     )
> >>>
> >>> I must be missing something, but I'm afraid I just can't see what
> it
> >> is.
> >>>
> >>> Best,
> >>> David
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Tuesday, May 04, 2010 1:26 PM
> >>>> To: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> If you use semantic-symref-data-debug-last-result it will show
the
> >>>> object that contains the data, and it is named after the tool it
> >> uses,
> >>>> like grep or global.
> >>>>
> >>>> Eric
> >>>>
> >>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>>>> Thanks, Eric.  I think it might be working for me.  At least,
> when
> >> I
> >>>> do
> >>>>> semantic-symref on a Java function in my project, I get a buffer
> >>> with
> >>>> a
> >>>>> list of references.  It's a little slow, however, and I'm
> > wondering
> >>>> if
> >>>>> it's falling back on Grep and not using my Global tags files.
> The
> >>>>> command cedet-gnu-global-show-root does show the right project
> >> root,
> >>>>> however.
> >>>>>
> >>>>> Question:  is there a way to verify it's using Global and not
> > Grep?
> >>>>>
> >>>>> Thanks!
> >>>>> Best,
> >>>>> David
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>>>> To: David Ventimiglia
> >>>>>> Cc: cedet-semantic@...
> >>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >> JDEE
> >>>>> user
> >>>>>> for a (mostly) Java project
> >>>>>>
> >>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
> >>>> below.
> >>>>>>>
> >>>>>>>> The basic strategy is to get an EDE project pointing to the
> > root
> >>>> of
> >>>>>>> all
> >>>>>>>> your code.  I'm assuming all the languages you mentioned are
> in
> >>>> one
> >>>>>>> big
> >>>>>>>> mega-project.  That top level project then needs to know
about
> >>> all
> >>>>>> the
> >>>>>>>> targets.  For simplicity sake, you could have one target per
> >>>>>> language
> >>>>>>>> type, or more detailed, one target per language/directory.
> >>>>>>>
> >>>>>>> So far, I just started with ede-simple-project, which I
created
> >>>> with
> >>>>>> the
> >>>>>>> command ede-new while visiting a Java file buried deep in that
> >>> part
> >>>>>> of
> >>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
> >>>>> defining
> >>>>>>> that ede-simple-project.  I also have run GNU Global in my
> >> project
> >>>>>> root.
> >>>>>>> What do I do now to enable completion, lookup, and
> >>> cross-references
> >>>>>> for
> >>>>>>> symbols?
> >>>>>>
> >>>>>> Ah, good idea with the simple project.  I'd forgotten about
> that.
> >>>>>>
> >>>>>> If you look in cedet/common/cedet.info in the node:
> >>>>>>
> >>>>>> (cedet.info)Top::>    GNU Global
> >>>>>>
> >>>>>> It lists all the options for enabling GNU Global in a CEDET
> >>> project.
> >>>>>>
> >>>>>>>> As for the symbol references, you can use any of the
different
> >>>>> tools
> >>>>>>>> you
> >>>>>>>> prefer, or none.  If you try it (once you have an EDE project
> >>>>>>>> specifying
> >>>>>>>> the root) with the find/grep solution and it is fast enough,
> >> then
> >>>>>> you
> >>>>>>>> can consider yourself done.
> >>>>>>>
> >>>>>>> I made these customizations:
> >>>>>>>
> >>>>>>> (require 'cedet)
> >>>>>>> (global-ede-mode 1)
> >>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>>>> (setq ede-locate-setup-options
> >>>>>>>           '(ede-locate-global
> >>>>>>>             ede-locate-base))
> >>>>>>>
> >>>>>>> But when I invoke the command semantic-symref-symbol on some
> >>> symbol
> >>>>>> in a
> >>>>>>> Java file, I get the message:
> >>>>>>>
> >>>>>>> semantic-symref-tool-grep - Needs to be configured for
jde-mode
> >>>>>>>
> >>>>>>> What does this mean?
> >>>>>>
> >>>>>>
> >>>>>> That means that semantic-symref-filepattern-alist needs to be
> >>>>>> customized.  If you have a good customization, I'll add it to
> the
> >>>>>> default value.
> >>>>>>
> >>>>>> Probably something like:
> >>>>>>
> >>>>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>>>> 	'(jde-mode "*.java"))
> >>>>>>
> >>>>>> I'll fix the error message to be more obvious.
> >>>>>>
> >>>>>> Of course, this also means that it failed to auto-detect the
GNU
> >>>>> Global
> >>>>>> tags file at the root of your project.  Use  M-x
> >>>>>> cedet-gnu-global-show-root to determine if the detection is
> >>> working.
> >>>>>> If
> >>>>>> it fails, then there is something in the Global doc that might
> >>> help,
> >>>>>> since CEDET just calls global with "-pq" options.
> >>>>>>
> >>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> > symbol
> >>>>>>> lookups?  Is it possible just to rely on the CEDET tools
alone?
> >>>>>>
> >>>>>> The symref tool relies on at least one external tool, but it
can
> >>> use
> >>>>>> find/grep commands to do it, so the other tools are not
> required,
> >>>> but
> >>>>>> will instead provide better and faster results.
> >>>>>>
> >>>>>>     >What I
> >>>>>>> mean is, I gather that semantic is parsing and caching the
tags
> >>>> for,
> >>>>>>> say, the Java files that I visit.  Is it possible to have
> >> semantic
> >>>>>> parse
> >>>>>>
> >>>>>> Semantic only parses the tags (like ctags) and not the
contents.
> >>>>>>
> >>>>>>> ALL my Java source files ahead of time (a la Global, idutils,
> >>>> ctags,
> >>>>>>> etc.), then just use semanticdb to support completion, lookup,
> >> and
> >>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >>>>>> evangelize
> >>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and
> the
> >>>>> more
> >>>>>>> external tools I have to integrate (like finding Windows
> > versions
> >>>> of
> >>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
> would
> >>> it
> >>>>>>> simply be too much of a performance hit to ask semantic to do
> >> what
> >>>>>>> Global et al are optimized to do very fast?
> >>>>>>
> >>>>>> Semantic parses it's own tags because tools like global and
> ctags
> >>>>>> provide only "quickie" information, and take many short-cuts to
> > do
> >>>> so.
> >>>>>> To do what CEDET does with tags, it needs to be much more
> > careful.
> >>>>>>
> >>>>>> Semantic also already has trouble with really huge projects,
and
> >>>> Emacs
> >>>>>> Lisp is just the wrong language to implement symbol cross-
> >> reference
> >>>>>> database in do the shear size.
> >>>>>>
> >>>>>> Instead, things like Global do a pretty good job on references,
> > so
> >>> I
> >>>>>> use
> >>>>>> those instead, and deal with the inaccuracy of it.  I'm hoping
> to
> >>>>>> double-check each "hit" with a real analysis to prove that the
> > hit
> >>>> is
> >>>>>> really a reference to a given symbol, and not some side-effect
> of
> >>>>>> polymorphism or other trick.
> >>>>>>
> >>>>>> Anyway, Global is probably your best bet unless find/grep is
> fast
> >>>>>> enough
> >>>>>> for you.
> >>>>>>
> >>>>>> Good Luck!
> >>>>>> Eric
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>> ---------
> >>>>> _______________________________________________
> >>>>> cedet-semantic mailing list
> >>>>> cedet-semantic@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>
> >>>>
> >>>>
> >>>
> >
---------------------------------------------------------------------
> >> --
> >>>> -------
> >>>> _______________________________________________
> >>>> cedet-semantic mailing list
> >>>> cedet-semantic@...
> >>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ---------
> >>> _______________________________________________
> >>> cedet-semantic mailing list
> >>> cedet-semantic@...
> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> 
>
-----------------------------------------------------------------------
> -------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

On 05/04/2010 07:54 AM, Rodrigo Canellas wrote:
> Hi,
>
> Does anyone know how to execute a 'goto-definition' and
> 'goto-declaration' implemented in CEDET?
>
> I am using 'semantic-ia-fast-jump', which goes from declaration to
> definition correctly, but it does not go the opposite way.

There is a function semantic-analyze-proto-impl-toggle which "does what 
you want", but it will fail if the file that contains the definition has 
not been parsed yet.  The fast-jump function will attempt to use the 
same fea ture that the proto/impl toggle does.

You can overcome this by either visiting the files you care about, or 
using something like GNU Global as a starting point for the Semantic 
databases.  The manual in cedet/common/cedet.el has the starting point 
for that.

Good Luck
Eric

Hi Dino,

I only have a few moments to answer this question.  I can answer your 
other questions later, but I'm guessing you may have already found the 
answers based on this question.

Also, you should join the mailing list so your mail doesn't get held for 
approval.

In Semantic, a namespace should create a tag of class type, so you can 
just create namespace type tags like this example from the C++ parser:

type
   : typesimple SEMICOLON
     ( ,$1 )
  ;; named namespaces like "namespace XXX {"
   | NAMESPACE symbol namespaceparts
     (TYPE-TAG $2 $1 $3 nil )
  ;; unnamed namespaces like "namespace {"
   | NAMESPACE namespaceparts
     (TYPE-TAG "unnamed" $1 $2 nil )
  ;; David Engster: namespace alias like "namespace foo = bar;"
   | NAMESPACE symbol EQUAL typeformbase SEMICOLON
     (TYPE-TAG $2 $1 (list (TYPE-TAG (car $4) $1 nil nil)) nil :kind 
'alias )
   ;

so it ends up being:

(TYPE-TAG "tagname" "namespace" (list of children) nil)

If you use this convention, all the semantic typedb cache stuff should 
work with C#.

Creating overlays is done via the tags output by semantic-tag-components 
which is overridden on a per-language basis.  The default implementation 
handles types and functions.  The tag tree is traversed (or cooked in 
Semantic parlance) via that function for creating overlays.

Hope that helps.
Eric

On 05/04/2010 01:24 PM, D Chiesa wrote:
> Hi again,
>
> I'm working on making the Csharp support more usable.
>
> I'm looking at semantic-tag.el .  There's a namespace construct in C#,
> nothing more than a scoping structure, a way to organize classes into a
> hierarchical naming space.  Like Java's package, except the syntax is
> different in C#.  The namespace gets a brace block:
>    namespace Foo {
>       public class Bar {
>           ...
>       }
>    }
>
> To support that in the parser, I've created a new tag, namespace-tag.
>
> (defsubst semantic-tag-new-namespace (name members&rest attributes)
>    "Create a semantic tag of class 'namespace.
> NAME is the name of this namespace.
> MEMBERS is a list of strings or semantic tags representing the
> elements that are contained within the namespace.
> ATTRIBUTES is a list of additional attributes belonging to this tag."
>    (apply 'semantic-tag name 'namespace
>           :members members
>           attributes))
>
> This seems to work fine, in the parsing.  But, for some reason, the child
> tags within that tag don't get overlays.  Instead they get vector locations.
> This breaks tag finding stuff, like semantic-get-all-local-variables and so
> on.
>
> If in the Csharp grammar, I treat the namespace keyword as a TYPE-TAG
> instead of NAMESPACE-TAG, then the overlays are properly inserted into the
> tag table.   Why the difference?
>
> Can you tell me, where is the magic that inserts overlays if the parent tag
> is "type" rather than "namespace" ?
>
> Thanks.
>
> Dino Chiesa
> dpchiesa@...
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>