CEDET

*pink -- not ping (I need to get away from a command line more often)...

On Thu, May 26, 2011 at 5:37 PM, Mitchel Humpherys
<mitch.special@...> wrote:
> Hello list!
>
> I'm working with an implementation of the c++ standard library by WindRiver
> (vxworks) and semantic I guess is having a hard time parsing the files... My
> project is finding the files (they're highlighted yellow, not ping) but
> semantic can't ever parse them. When I visit one of the files in question
> and do semantic-analyze-current-context I get:
>
> semantic-analyze-current-context: Cannot analyze buffers not supported by
> Semantic
>
> Any ideas what's up? I obviously can't supply the files because I don't
> think WindRiver would appreciate that :), so I guess this conversation is
> pointless unless you have access to those headers or have some other ideas
> for me to debug what's going on.
>
>
> -Mitch
>
>

On 05/26/2011 08:37 PM, Mitchel Humpherys wrote:
> Hello list!
>
> I'm working with an implementation of the c++ standard library by
> WindRiver (vxworks) and semantic I guess is having a hard time parsing
> the files... My project is finding the files (they're highlighted
> yellow, not ping) but semantic can't ever parse them. When I visit one
> of the files in question and do semantic-analyze-current-context I get:
>
> semantic-analyze-current-context: Cannot analyze buffers not supported
> by Semantic
>
> Any ideas what's up? I obviously can't supply the files because I don't
> think WindRiver would appreciate that :), so I guess this conversation
> is pointless unless you have access to those headers or have some other
> ideas for me to debug what's going on.

The major mode of your files needs to be C++, or Semantic won't get the 
buffer set up for parsing.  Alternately, if they are C++ files, an error 
may be thrown while the mode is being setup and it is being caught, but 
the buffer isn't setup.

Doing "M-x c++-mode" in the buffer should force something to be revealed.

Eric

Eric M. Ludlam writes:
> On 05/26/2011 08:37 PM, Mitchel Humpherys wrote:
>> Hello list!
>>
>> I'm working with an implementation of the c++ standard library by
>
>> WindRiver (vxworks) and semantic I guess is having a hard time parsing
>> the files... My project is finding the files (they're highlighted
>> yellow, not ping) but semantic can't ever parse them. When I visit one
>> of the files in question and do semantic-analyze-current-context I get:
>>
>> semantic-analyze-current-context: Cannot analyze buffers not supported
>> by Semantic
>>
>> Any ideas what's up? I obviously can't supply the files because I don't
>> think WindRiver would appreciate that :), so I guess this conversation
>> is pointless unless you have access to those headers or have some other
>> ideas for me to debug what's going on.
>
> The major mode of your files needs to be C++, or Semantic won't get the 
> buffer set up for parsing.  Alternately, if they are C++ files, an error 
> may be thrown while the mode is being setup and it is being caught, but 
> the buffer isn't setup.

This is a common problem with STL files like "algorithm" which don't
have a file extension. There are several ways to deal with that:

* Put

  // -*- C++ -*-

  in the first line of all the files (this is what GNU glibc has).

* If all the files start with a C++ comment, use

  (add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))

* Frob auto-mode-alist to include the directory with the STL files, like

  (add-to-list 'auto-mode-alist '("^/usr/include/windriverSTL/" . c++-mode))

-David

> * If all the files start with a C++ comment, use
>
>  (add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
>
> * Frob auto-mode-alist to include the directory with the STL files, like
>
>  (add-to-list 'auto-mode-alist '("^/usr/include/windriverSTL/" . c++-mode))

I was just wondering how I was going to get emacs into c++ mode since
I don't want to edit the source files. Thanks for these ideas.

-Mitch

Mitchel Humpherys writes:
> On 04/26/2011 12:27 PM, Darren Hoo wrote:
>> just wrapping  something around semantic-ia-fast-jump seems trivial
>> here's my settings:

[...]

> I've been using this code for about a month now and have been absolutely 
> loving it! Until a more permanent solution can be worked up I would 
> suggest throwing this into the bzr trunk for all to enjoy :).

Darren, did you contact the FSF regarding copyright papers?

-David

On 05/19/2011 12:18 PM, David Engster wrote:
> Eric M. Ludlam writes:
>> On 03/30/2011 05:53 PM, David Engster wrote:
>>> Hi,
>>>
>>> consider the following:
>>
>>>
>>> ---------------------
>>> class testclass {
>>> public:
>>>     struct someStruct {int a; int b;};
>>>     someStruct aVar;
>>>     //  [.... constructor/other stuff ...]
>>>     someStruct getVar() { return aVar; }
>>> };
>>>
>>> void f()
>>> {
>>>     testclass c;
>>>     c.getVar().//<-- complete here
>>> }
>>> ---------------------
>>>
>>> Completion won't work because Semantic cannot find 'someStruct'. It can
>>> only find it if you explicitly use testclass::someStruct.
>>>
>>> The problem is in semantic-analyze-find-tag-sequence-default, where the
>>> line
>>>
>>> (semantic-analyze-tag-type tmp scope)
>>>
>>> won't find the return type of getVar in 'scope'. A similar problem
>>> exists when you have meta-tags like typedefs which refer to such locally
>>> scoped types. But here the problem is in
>>> semantic-analyze-dereference-metatype-1 with the line
>>>
>>> (semantic-scope-find (semantic-tag-name ans) 'type scope)))
>>>
>>> Also, you cannot find those types in the typecache, since you'd still
>>> need the fully qualified name.
>>>
>>> I'm not sure how this should be tackled. Any hints?
>>
>> Hi David,
>>
>> This can probably be solved using the scope input.  Note that in
>> semantic-analyze-find-tag-sequence-default around line 306 there is a
>> mini-scope being calculated.  I'd guess around line 316 (the line you
>> quote) we'd need to add something similar, where the tag we just found
>> (tmp == getVar in this case) came from somewhere, and a new scope should
>> be generated from that location.  Perhaps a call to
>> semantic-tag-calculate-parent can get a datatype from which a miniscope
>> can be generated?
>
> It's been a while, but I've been using this patch in my local branch for
> the past weeks without problems:
>

That looks exactly like what I expected.  This would be great to check 
in.  With a bonus test too.  Huzzah!

Thanks
Eric

Eric M. Ludlam writes:
> That looks exactly like what I expected.  This would be great to check 
> in.  With a bonus test too.  Huzzah!

Well, I've changed my mind. :-)

I'm afraid just including the parent into the scope is not
enough. Consider the following example:

-------------------------------------------
namespace foo {
  struct myStruct {int foo1; int foo2;};

  class MyClass
  {
  public:
    myStruct bla;
  };
}

void func()
{
  foo::MyClass c;
  c.bla. // Complete here
}
-------------------------------------------

'myStruct' is member of the namespace 'foo', but not of 'MyClass'. And
now, just for fun, let's throw a template and typedef into the mix:

---------------------------------------
namespace foo {

  template<typename _T>
  struct myStruct {_T foo1; _T foo2;};

  template<typename T>
  class MyClass
  {
  public:
    typedef myStruct<T> myType;
    myType bla;
  };
}

void func()
{
  foo::MyClass<int> c;
  c.bla. // Complete here
}
--------------------------------------

While Semantic does find 'foo1/2', it assumes those are of type
'T'. This is because the dereferencer doesn't get the chance to
dereference the template and the typedef at the same time; it will first
dereference the template for MyClass when dealing with 'c', and it will
then separately deal with the typedef when looking at 'bla'. However,
there it will only see 'MyClass<T>' as the parent and not
'MyClass<myStruct>', which obviously doesn't exist anywhere in written
form.

Here's a snippet which should deal with both:

--- trunk/semantic/semantic-analyze.el  2011-03-09 12:09:43.000000000 +0100
+++ poly-template/semantic/semantic-analyze.el  2011-05-23 17:43:27.000000000 +0200
@@ -341,6 +341,21 @@
        (when (and fname (semantic-tag-p tmp)
                   (not (semantic-tag-in-buffer-p tmp)))
          (semantic--tag-put-property tmp :filename fname))
+
+       (when (and tmp (semantic-tag-p tmp))
+         (let ((tagscope
+                (save-excursion
+                  (semantic-go-to-tag tmp)
+                  (semantic-calculate-scope)))
+               (rawscope
+                (semantic-tag-type-members tmptype)
+               ))
+           (when tagscope
+             (oset scope fullscope
+                   (append rawscope
+                           (oref tagscope fullscope)
+                           (oref scope fullscope))))))
+
        (setq tag (cons tmp tag))
        (setq tagtype (cons tmptype tagtype))
        )


In words:

  - Calculate a local scope for 'tmp' (which in the first example is
    'foo::MyClass::bla') and include it into scope.

  - Include all the type members of the type we're currently dealing
    with (in the second example those are the members of the
    dereferenced 'MyClass<int>'). It's also important that those members
    are at the front of the scope list.

I haven't tested this fully; I'm also not sure how this will affect
speed (how expensive is `semantic-calculate-scope'?). I probably will
have to benchmark this. But maybe you have a better idea?

BTW, it might be that the second example doesn't work at all with
trunk. I'm working with my local branch, which already has a ton of
changes to better deal with templates...

-David

Hi David,

Interesting new issues.  To figure out performance, just put the cursor 
on some example, and do:

M-x semantic-elp-analyze RET

I would guess your code won't do much if the local context doesn't have 
the case where this extra work is needed??  That would be the best 
solution as a little performance issue is fine for more complex problems.

Eric

On 05/23/2011 02:04 PM, David Engster wrote:
> Eric M. Ludlam writes:
>> That looks exactly like what I expected.  This would be great to check
>> in.  With a bonus test too.  Huzzah!
>
> Well, I've changed my mind. :-)
>
> I'm afraid just including the parent into the scope is not
> enough. Consider the following example:
>
> -------------------------------------------
> namespace foo {
>    struct myStruct {int foo1; int foo2;};
>
>    class MyClass
>    {
>    public:
>      myStruct bla;
>    };
> }
>
> void func()
> {
>    foo::MyClass c;
>    c.bla. // Complete here
> }
> -------------------------------------------
>
> 'myStruct' is member of the namespace 'foo', but not of 'MyClass'. And
> now, just for fun, let's throw a template and typedef into the mix:
>
> ---------------------------------------
> namespace foo {
>
>    template<typename _T>
>    struct myStruct {_T foo1; _T foo2;};
>
>    template<typename T>
>    class MyClass
>    {
>    public:
>      typedef myStruct<T>  myType;
>      myType bla;
>    };
> }
>
> void func()
> {
>    foo::MyClass<int>  c;
>    c.bla. // Complete here
> }
> --------------------------------------
>
> While Semantic does find 'foo1/2', it assumes those are of type
> 'T'. This is because the dereferencer doesn't get the chance to
> dereference the template and the typedef at the same time; it will first
> dereference the template for MyClass when dealing with 'c', and it will
> then separately deal with the typedef when looking at 'bla'. However,
> there it will only see 'MyClass<T>' as the parent and not
> 'MyClass<myStruct>', which obviously doesn't exist anywhere in written
> form.
>
> Here's a snippet which should deal with both:
>
> --- trunk/semantic/semantic-analyze.el  2011-03-09 12:09:43.000000000 +0100
> +++ poly-template/semantic/semantic-analyze.el  2011-05-23 17:43:27.000000000 +0200
> @@ -341,6 +341,21 @@
>          (when (and fname (semantic-tag-p tmp)
>                     (not (semantic-tag-in-buffer-p tmp)))
>            (semantic--tag-put-property tmp :filename fname))
> +
> +       (when (and tmp (semantic-tag-p tmp))
> +         (let ((tagscope
> +                (save-excursion
> +                  (semantic-go-to-tag tmp)
> +                  (semantic-calculate-scope)))
> +               (rawscope
> +                (semantic-tag-type-members tmptype)
> +               ))
> +           (when tagscope
> +             (oset scope fullscope
> +                   (append rawscope
> +                           (oref tagscope fullscope)
> +                           (oref scope fullscope))))))
> +
>          (setq tag (cons tmp tag))
>          (setq tagtype (cons tmptype tagtype))
>          )
>
>
> In words:
>
>    - Calculate a local scope for 'tmp' (which in the first example is
>      'foo::MyClass::bla') and include it into scope.
>
>    - Include all the type members of the type we're currently dealing
>      with (in the second example those are the members of the
>      dereferenced 'MyClass<int>'). It's also important that those members
>      are at the front of the scope list.
>
> I haven't tested this fully; I'm also not sure how this will affect
> speed (how expensive is `semantic-calculate-scope'?). I probably will
> have to benchmark this. But maybe you have a better idea?
>
> BTW, it might be that the second example doesn't work at all with
> trunk. I'm working with my local branch, which already has a ton of
> changes to better deal with templates...
>
> -David
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

Yes, C-c . is a popular prefix key for both EDE, and a few other random 
minor modes.  There just aren't enough prefixes out there. ;)

Eric

On 05/18/2011 06:55 PM, York Zhao wrote:
> Hi,
>
> I have noticed a bug for awhile and decided to report here. The problem
> is that when cedet is loaded, the "\C-c." keybinding in org-mode no
> longer works.
>
> Thanks,
>
> York
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel

On 05/17/2011 02:46 AM, David Engster wrote:
> We have both functions mentioned in the subject and they seem to be
> identical, so I suggest we get rid of one of them. A quick grep shows
> that semantic-tag-prototype-p is used more, so should we drop the
> semantic-analyze-* one?

I think that makes sense.  The log indicates that 
semantic-tag-prototype-p is a copy of the one in the analyzer.  Probably 
because I wanted code unrelated to the analyzer to not depend on 
analyzer functions, but I think the reverse is certainly ok.

Thanks for noticing that.
Eric

Eric M. Ludlam writes:
> On 05/17/2011 02:46 AM, David Engster wrote:
>> We have both functions mentioned in the subject and they seem to be
>> identical, so I suggest we get rid of one of them. A quick grep shows
>> that semantic-tag-prototype-p is used more, so should we drop the
>> semantic-analyze-* one?
>
> I think that makes sense.  The log indicates that 
> semantic-tag-prototype-p is a copy of the one in the analyzer.  Probably 
> because I wanted code unrelated to the analyzer to not depend on 
> analyzer functions, but I think the reverse is certainly ok.

OK, I've now removed semantic-analyze-tag-prototype-p and replaced the
few occurrences with semantic-tag-prototype-p.

> Thanks for noticing that.

Well, I learned it the hard way (which is overloading
semantic-tag-prototype-p and wondering why it didn't work ;-) ).

-David

On 05/16/2011 01:34 PM, York Zhao wrote:
> Hi Eric and David,
>
> I'm having the problem that 'semantic-decoration-include-visit' is not
> working on all my C++ source files. on one of my source files, it always
> reported the error "Point is not on an include tag". Debugged into
> 'semantic-decoration-include-visit' and noticed that the
> 'semantic-tag-class' was nil when it should be "'include". What can I do
> about it to identify the cause of program?

Hi,

If you create a short test file that replicates the empty include, that 
would be a good first step.  Just copy the top of some file over with 
the bogus include, and trim stuff out till you have the smallest piece, 
then perhaps we can analyze what is going on.

Thanks!
Eric

On 05/13/2011 11:03 PM, Daniel Philip Katz wrote:
> Hi -
>
> I'm running cedet from the bzr trunk with emacs-23.3.1 on an Ubuntu 11.4 box.  What I've noticed is that I keep getting prompted by process-kill-buffer-query-function all the time!  After getting sufficiently annoyed, I set a breakpoint and found the following backtrace:
>
> Debugger entered--entering a function:
> * process-kill-buffer-query-function()
>   kill-buffer(#<buffer  *tmp object write*>)
> [... lots of byte-code and stuff ...]
>   semanticdb-save-all-db-idle()
>   run-hooks(auto-save-hook)
>
> My read of this is as follows:
>
>   - semantic-db-save-all-db-idle creates a temp buffer that has a process attached, does a bunch of stuff, and then kills the buffer
>   - GNU emacs (as of 23.2, based on the NEWS file) now asks for confirmation when killing a buffer with a running process
>
> It's possible to get around this problem just removing process-kill-buffer-query-function from kill-buffer-query-functions, but I don't want to remove that behavior globally.  Ideally, I'd like to just (set-process-query-on-exit-flat<whatever-semantic-db-process-this-is>  nil), but I don't have a simple hook for that that I see offhand.  And anyway, are the transaction semantics of semanticdb-save-all-db-idle() sufficiently robust that they don't mind if the process just gets killed without any notice?
>
>
> I figured that before I started trying to tweak the semanticdb code to deal with this I ought to ask if other people have seen this and if there's a better solution that what I've outlined here.

I am unfamiliar with the issue you describe.  There should be no 
processes associated with the object write buffer.  do you perhaps have 
some unusual hooks in your .emacs file that is creating subprocesses in 
some way?  Perhaps a call to

M-x list-process RET

will reveal something when the debugger is stopped.

Good Luck
Eric