CEDET

Hi,

  Thanks for the example.  I haven't done any work at resolving the
specifics of C++ namespace issues yet.  While there is infrastructure
there to handle multiple scopes, the work of parsing out namespaces
from using statements, or b::name type syntax is not.

  As I am starting to work on C++ code like that, however, it is on
the top of my list of analyzer things to do... after I get 1.0 out
that is.

  If someone wants to tackle this problem, I'd be happy to help.

Eric

>>> Nathan Addy <nathan.addy@...> seems to think that:
>Hi,
>
>I am a relative emacs newbie and a total semantic newbie, so I
>apologize if this is a pretty obvious question/problem.
>
>Today my goal has been to take an out of the box emacs installation
>and get the analyse-possible-completions type stuff to work with a
>medium sized project I'm joining.  I downloaded semantic by installing
>the latest cedet and then ran something like
>
>(load-file "~/bin/emacs/cedet-1.0pre3/semantic/semantic-load.el")
>(setq semantic-load-turn-everything-on t)
>in my .emacs.  
>
>To test it out I entered in some simple cpp file that said something like
>
>class foo
>{
>public:
>int m_int;
>};
>namespace b
>{
>class bar 
>{
>public:
>int m_int;
>};
>}
>int main(int argc, char** argv)
>{
>foo alpha;
>b::bar beta;
>...
>}
>Where all of this is contained in one single cpp file.  
>
>The semantic-complete-analyse-inline will work exactly the way I would
>expect when I use it after typing "alpha."  It completes it to
>alpha.m_int and will expend to the first ambiguity when I give foo
>more public members, etc.  None of this works for beta though.  When I
>type "beta." and execute the function, it offers for completion all
>variables at local scope: main, argc, argv, alpha, and beta.
>
>What, if anything, can I do to make semantic resolve names through
>namespaces?  Thanks very much in advance.
  [ ... ]

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

Thanks!

This seems like a good idea.  The construction of the canonical name
seems like a generally useful thing so I've added something like that
into semantic-format.  That greatly simplifies this function since all
it needs do is find the current and parent tags.  This is already
done with the newer semantic-test-all-format-tag-functions.  I will
check in my changes sometime soon.

I do not know the details on the python parser.  Feel free to edit
semantic/wisent/wisent-python.wy and see if the specification of tag
classes makes sense to you.

Eric

>>> Stefan =?iso-8859-1?Q?Reich=F6r?= <stefan@...> seems to think that:
>Hi!
>
>I have hacked the defadvice for add-log-current-defun.
>It returns now the class and the method name, if both are available.
>
>It works for me with python and with C++
>
>(defadvice add-log-current-defun (around senator activate)
>  "Return name of function definition point is in, or nil."
>  (if senator-minor-mode
>      (let ((cd (nreverse (semantic-find-tag-by-overlay)))
>            (type-name)
>            (function-name)
>            (name nil))
>
>        (while cd
>          ;; type is used e.g. for python
>          (when (eq (semantic-tag-class (car cd)) 'type)
>            (setq type-name (semantic-tag-name (car cd))))
>          (when (eq (semantic-tag-class (car cd)) 'function)
>            (setq function-name (semantic-tag-name (car cd)))
>            (unless type-name
>              ;; the function-parent is used e.g. in C++
>              (setq type-name (semantic-tag-function-parent (car cd)))))
>          (setq cd (cdr cd)))
>
>        ;; return type::function, if both are available
>        (if (and type-name function-name)
>            (setq name (concat type-name "::" function-name))
>          (setq cd (nreverse (semantic-find-tag-by-overlay)))
>          (while (and cd (not name))
>            (if (memq (semantic-tag-class (car cd))
>                      senator-add-log-tags)
>                (setq name (semantic-tag-name (car cd)))
>              (setq cd (cdr cd)))))
>        (if name
>            (setq ad-return-value name)
>          ad-do-it))
>    ad-do-it))
>
>
>A question: Why do the python and the c++ parser store similar things
>in different places?
>
>* Python uses semantic-tag-class 'type for the class name
>* C++ uses the semantic-tag-function-parent
>
>I think it would be useful to provide a similar interface for both
>languages.
>
>
>
>Stefan.
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>cedet-semantic mailing list
>cedet-semantic@...
>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Hi Eric!

> Thanks!
>
> This seems like a good idea.  The construction of the canonical name
> seems like a generally useful thing so I've added something like that
> into semantic-format.  That greatly simplifies this function since all
> it needs do is find the current and parent tags.  This is already
> done with the newer semantic-test-all-format-tag-functions.  I will
> check in my changes sometime soon.

I look forward to the improved functionality. You haven't checked it in
yet - have you?

> I do not know the details on the python parser.  Feel free to edit
> semantic/wisent/wisent-python.wy and see if the specification of tag
> classes makes sense to you.

Hm. The defadvice that I have sent is the first contact that I had
with semantic. So I don't know the big picture to make such a change.

However, I looked in wisent-python.wy. I think the following parts are relevant:

;; funcdef: 'def' NAME parameters ':' suite
funcdef
  : DEF NAME function_parameter_list COLON suite
    (FUNCTION-TAG $2 nil $3)
  ;

;; classdef: 'class' NAME ['(' testlist ')'] ':' suite
class_declaration
  : CLASS NAME paren_class_list_opt COLON suite
    (TYPE-TAG $2 $1             ;; Name "class"
              $5                ;; Members
              (cons $3 nil)     ;; (SUPERCLASSES . INTERFACES)
              )
  ;


But I have no idea, how to set the :parent tag for the funcdef.
Any pointers?


Stefan.

>>> Stefan =?iso-8859-1?Q?Reich=F6r?= <stefan@...> seems to think that:
>Hi Eric!
>
>> Thanks!
>>
>> This seems like a good idea.  The construction of the canonical name
>> seems like a generally useful thing so I've added something like that
>> into semantic-format.  That greatly simplifies this function since all
>> it needs do is find the current and parent tags.  This is already
>> done with the newer semantic-test-all-format-tag-functions.  I will
>> check in my changes sometime soon.
>
>I look forward to the improved functionality. You haven't checked it in
>yet - have you?

I did get an entire half-hour to hack this past weekend.  I should be
putting the 1.0 release together, but instead I fiddled with a new
format function for canonical names.  Doing so revealed inadequacies
in the base proposed algorithm for languages like C++ with multiple
nested namespaces.  I'll figure it out eventually.

>> I do not know the details on the python parser.  Feel free to edit
>> semantic/wisent/wisent-python.wy and see if the specification of tag
>> classes makes sense to you.
>
>Hm. The defadvice that I have sent is the first contact that I had
>with semantic. So I don't know the big picture to make such a change.
>
>However, I looked in wisent-python.wy. I think the following parts are relevant:
>
>;; funcdef: 'def' NAME parameters ':' suite
>funcdef
>  : DEF NAME function_parameter_list COLON suite
>    (FUNCTION-TAG $2 nil $3)
>  ;
>
>;; classdef: 'class' NAME ['(' testlist ')'] ':' suite
>class_declaration
>  : CLASS NAME paren_class_list_opt COLON suite
>    (TYPE-TAG $2 $1             ;; Name "class"
>              $5                ;; Members
>              (cons $3 nil)     ;; (SUPERCLASSES . INTERFACES)
>              )
>  ;
>
>
>But I have no idea, how to set the :parent tag for the funcdef.
>Any pointers?
  [ ... ]

It seems that a class should indeed be a type class.  I suspect that
the 'parent' is found via nesting instead of via a :parent attribute.

As such, I now better understand the original question.

If you have a definition like this in some invented language:

class foo {

  method whatever {
  }

}

then 'whatever' has a parent determined by tag nesting.  ie:

(semantic-tag-functio-parent whatevertag)
=> nil

but

(semantic-tag-components footag)
=> <#TAG whatever>

where 'components' just means "more tags inside this one".  In the
case of a tag of class type, that means methods and fields.  For a
function, it may be arguments to the function.

In C++, you can do this instead:

class foo {

  void whatever();

}

void foo::whatever() {
}

and in this file, there are two 'whatever' tags.  The first is as
described above.  The second has a :parent attribute which contains
the name of the 'foo' tag.  To get the foo tag, you would need to
perform some sort of semantic search.

Does that make sense?  Basically, tag tables mirror the code, and it
is up to various programs to make logical sense from the bounty of
language implementations.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

>>However, I looked in wisent-python.wy. I think the following parts are relevant:
>>
>>;; funcdef: 'def' NAME parameters ':' suite
>>funcdef
>>  : DEF NAME function_parameter_list COLON suite
>>    (FUNCTION-TAG $2 nil $3)
>>  ;
>>
>>;; classdef: 'class' NAME ['(' testlist ')'] ':' suite
>>class_declaration
>>  : CLASS NAME paren_class_list_opt COLON suite
>>    (TYPE-TAG $2 $1             ;; Name "class"
>>              $5                ;; Members
>>              (cons $3 nil)     ;; (SUPERCLASSES . INTERFACES)
>>              )
>>  ;
>>
>>
>>But I have no idea, how to set the :parent tag for the funcdef.
>>Any pointers?
>   [ ... ]
>
> It seems that a class should indeed be a type class.  I suspect that
> the 'parent' is found via nesting instead of via a :parent attribute.
>
> As such, I now better understand the original question.
>
> If you have a definition like this in some invented language:
>
> class foo {
>
>   method whatever {
>   }
>
> }
>
> then 'whatever' has a parent determined by tag nesting.  ie:
>
> (semantic-tag-functio-parent whatevertag)
> => nil
>
> but
>
> (semantic-tag-components footag)
> => <#TAG whatever>
>
> where 'components' just means "more tags inside this one".  In the
> case of a tag of class type, that means methods and fields.  For a
> function, it may be arguments to the function.

The situation you described above is exactly the case for python.

> In C++, you can do this instead:
>
> class foo {
>
>   void whatever();
>
> }
>
> void foo::whatever() {
> }
>
> and in this file, there are two 'whatever' tags.  The first is as
> described above.  The second has a :parent attribute which contains
> the name of the 'foo' tag.  To get the foo tag, you would need to
> perform some sort of semantic search.
>
> Does that make sense?  Basically, tag tables mirror the code, and it
> is up to various programs to make logical sense from the bounty of
> language implementations.

Thanks for that nice explanation, now I see the difference between
python and C++ from the viewpoint of semantic.

My use case (get class name + method name) for the point position
didn't need that distinction.

If I understood you correct, the new format function will provide a
unified way to get class name + method name for every supported
language.


Stefan.