ede-linux doesn't work with master emacs repo

ede-linux doesn't work with master emacs repo

[Aneesh Kumar K.V]

After the sync with CEDET 1.0, ede-linux support seems to be
broken. Visting a linux kernel directory gives the error

ede-directory-project-p: Cannot open load file: ede-linux

-aneesh

Re: ede-linux doesn't work with master emacs repo

[Chong Yidong]

aneesh.kumar@linux.vnet.ibm.com (Aneesh Kumar K.V) writes:

> After the sync with CEDET 1.0, ede-linux support seems to be
> broken. Visting a linux kernel directory gives the error
>
> ede-directory-project-p: Cannot open load file: ede-linux

Should be fixed now, thanks for the report.

Re: ede-linux doesn't work with master emacs repo

[Aneesh Kumar K. V]

On Sat, 25 Sep 2010 15:19:54 -0400, Chong Yidong <cyd@stupidchicken.com> wrote:
> aneesh.kumar@linux.vnet.ibm.com (Aneesh Kumar K.V) writes:
> 
> > After the sync with CEDET 1.0, ede-linux support seems to be
> > broken. Visting a linux kernel directory gives the error
> >
> > ede-directory-project-p: Cannot open load file: ede-linux
> 
> Should be fixed now, thanks for the report.

I also found that the completion is broken with the update. With simple C
prg like the below, I am not able to complete the member variables of
struct a

struct a {
    int k;
    char b;
} t;

main()
{
    int done;
    int c;
    char k;
    c = done;
    c = t.
}

-aneesh

Re: ede-linux doesn't work with master emacs repo

[Eric M. Ludlam]

Hi Aneesh,

You example works with the CEDET from the CEDET repository.  There have 
been no changes in that area since CEDET 1.0.

A good place to start is with M-x semantic-analyze-debug-assist RET 
which will point at the problem area.  Perhaps something has been 
translated into Emacs incorrectly.

Eric

On 09/25/2010 05:03 PM, Aneesh Kumar K. V wrote:
> On Sat, 25 Sep 2010 15:19:54 -0400, Chong Yidong<cyd@stupidchicken.com>  wrote:
>> aneesh.kumar@linux.vnet.ibm.com (Aneesh Kumar K.V) writes:
>>
>>> After the sync with CEDET 1.0, ede-linux support seems to be
>>> broken. Visting a linux kernel directory gives the error
>>>
>>> ede-directory-project-p: Cannot open load file: ede-linux
>>
>> Should be fixed now, thanks for the report.
>
> I also found that the completion is broken with the update. With simple C
> prg like the below, I am not able to complete the member variables of
> struct a
>
> struct a {
>      int k;
>      char b;
> } t;
>
> main()
> {
>      int done;
>      int c;
>      char k;
>      c = done;
>      c = t.
> }

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [CEDET-devel] ede-linux doesn't work with master emacs repo

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> You example works with the CEDET from the CEDET repository.  There
> have been no changes in that area since CEDET 1.0.
>
> A good place to start is with M-x semantic-analyze-debug-assist RET
> which will point at the problem area.  Perhaps something has been
> translated into Emacs incorrectly.

I probably goofed up somewhere during the merge.  Here's the output of
semantic-analyze-debug-assist from the built-in CEDET, followed by the
output from stand-alone CEDET.

========= built-in CEDET =======================

Unable to find datatype for: "struct a t".
Declared type is: "struct a {}"
Raw data type is: ("a" type (:prototype t :type "struct") nil nil)

Semantic could not find this data type in any of its global tables.

Semantic locates datatypes through either the local scope, or the global
typecache.

Local Scope Information:
 * Tag Class Constraint against SCOPE: (type)
 * No known parents in current scope.
 * No known symbols currently in scope.
 * No known symbols declared locally.
Semantic creates and maintains a type cache for each buffer.
If the type is a global type, then it should appear in they typecache.
To examine the typecache, type:

  M-x semanticdb-typecache-dump RET   [ Do It ]

Current typecache Statistics:
      1 types global in this file
      0 types from includes.

If the datatype is not in the typecache, then your include
path may be incorrect.  

Include Path Summary:

The system include path is:
  /usr/include
  /usr/local/include/
  /usr/lib/gcc/i486-linux-gnu/4.4.3/include/
  /usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed/
  /usr/include/


Include Summary: /home/cyd/tmp/foo.c

foo.c contains 0 includes.

 No unknown includes.

========= stand-along CEDET =======================

Cannot find symbol "" in datatype:
  struct a {}

Semantic has found the datatype struct a {}
and its list of members.  Semantic knows of some
possible completions for "".

Possible completions are:
  int k


Known members of a:
  int k
  char b

When there are known members that would make good completion
candidates that are not in the completion list, then the most likely
cause is a type constraint.  Semantic has determined that there is a
type constraint looking for the type "int {}".

Re: ede-linux doesn't work with master emacs repo

[Eric M. Ludlam]

That looks like a problem with the C/C++ parser.  It knows that t is a 
struct, but claims it is a prototype.  I think you are missing a change 
from a short series of checkins ending on 2010-03-14 that deal with the 
way compound tags (where you have a named struct, AND a declaration of a 
variable t) are dealt with.

I'll take a wild guess that semantic-c.el was not imported right.

Eric

On 09/25/2010 07:28 PM, Chong Yidong wrote:
> "Eric M. Ludlam"<eric@siege-engine.com>  writes:
>
>> You example works with the CEDET from the CEDET repository.  There
>> have been no changes in that area since CEDET 1.0.
>>
>> A good place to start is with M-x semantic-analyze-debug-assist RET
>> which will point at the problem area.  Perhaps something has been
>> translated into Emacs incorrectly.
>
> I probably goofed up somewhere during the merge.  Here's the output of
> semantic-analyze-debug-assist from the built-in CEDET, followed by the
> output from stand-alone CEDET.
>
> ========= built-in CEDET =======================
>
> Unable to find datatype for: "struct a t".
> Declared type is: "struct a {}"
> Raw data type is: ("a" type (:prototype t :type "struct") nil nil)
>
> Semantic could not find this data type in any of its global tables.
>
> Semantic locates datatypes through either the local scope, or the global
> typecache.
>
> Local Scope Information:
>   * Tag Class Constraint against SCOPE: (type)
>   * No known parents in current scope.
>   * No known symbols currently in scope.
>   * No known symbols declared locally.
> Semantic creates and maintains a type cache for each buffer.
> If the type is a global type, then it should appear in they typecache.
> To examine the typecache, type:
>
>    M-x semanticdb-typecache-dump RET   [ Do It ]
>
> Current typecache Statistics:
>        1 types global in this file
>        0 types from includes.
>
> If the datatype is not in the typecache, then your include
> path may be incorrect.
>
> Include Path Summary:
>
> The system include path is:
>    /usr/include
>    /usr/local/include/
>    /usr/lib/gcc/i486-linux-gnu/4.4.3/include/
>    /usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed/
>    /usr/include/
>
>
> Include Summary: /home/cyd/tmp/foo.c
>
> foo.c contains 0 includes.
>
>   No unknown includes.
>
> ========= stand-along CEDET =======================
>
> Cannot find symbol "" in datatype:
>    struct a {}
>
> Semantic has found the datatype struct a {}
> and its list of members.  Semantic knows of some
> possible completions for "".
>
> Possible completions are:
>    int k
>
>
> Known members of a:
>    int k
>    char b
>
> When there are known members that would make good completion
> candidates that are not in the completion list, then the most likely
> cause is a type constraint.  Semantic has determined that there is a
> type constraint looking for the type "int {}".
>
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [CEDET-devel] ede-linux doesn't work with master emacs repo

[Aneesh Kumar K. V]

On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam" <eric@siege-engine.com> wrote:
> That looks like a problem with the C/C++ parser.  It knows that t is a 
> struct, but claims it is a prototype.  I think you are missing a change 
> from a short series of checkins ending on 2010-03-14 that deal with the 
> way compound tags (where you have a named struct, AND a declaration of a 
> variable t) are dealt with.
> 
> I'll take a wild guess that semantic-c.el was not imported right.
> 
> Eric

Any update here ? Is there a test branch i can test ?

-aneesh

Re: [CEDET-devel] ede-linux doesn't work with master emacs repo

[Chong Yidong]

"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> writes:

> On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam" <eric@siege-engine.com> wrote:
>> That looks like a problem with the C/C++ parser.  It knows that t is
>> a struct, but claims it is a prototype.  I think you are missing a
>> change from a short series of checkins ending on 2010-03-14 that deal
>> with the way compound tags (where you have a named struct, AND a
>> declaration of a variable t) are dealt with.
>>
>> I'll take a wild guess that semantic-c.el was not imported right.
>>
>> Eric
>
> Any update here ? Is there a test branch i can test ?

I'm still trying to figure it out.  I did find one set of changes from
semantic-c.el that I had omitted, but after merging it in, and checking
that the relevant files (bovine/c vs semantic-c, bovine/c-by vs
semantic-c-by, and semantic/analyze vs semantic-analyze) have no more
relevant differences, the bug remains.

Eric, other than semantic-c, is there any other file I should keep an
eye out for?

Re: ede-linux doesn't work with master emacs repo

[Eric M. Ludlam]

On 09/28/2010 12:33 PM, Chong Yidong wrote:
> "Aneesh Kumar K. V"<aneesh.kumar@linux.vnet.ibm.com>  writes:
>
>> On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam"<eric@siege-engine.com>  wrote:
>>> That looks like a problem with the C/C++ parser.  It knows that t is
>>> a struct, but claims it is a prototype.  I think you are missing a
>>> change from a short series of checkins ending on 2010-03-14 that deal
>>> with the way compound tags (where you have a named struct, AND a
>>> declaration of a variable t) are dealt with.
>>>
>>> I'll take a wild guess that semantic-c.el was not imported right.
>>>
>>> Eric
>>
>> Any update here ? Is there a test branch i can test ?
>
> I'm still trying to figure it out.  I did find one set of changes from
> semantic-c.el that I had omitted, but after merging it in, and checking
> that the relevant files (bovine/c vs semantic-c, bovine/c-by vs
> semantic-c-by, and semantic/analyze vs semantic-analyze) have no more
> relevant differences, the bug remains.
>
> Eric, other than semantic-c, is there any other file I should keep an
> eye out for?

I'm not sure.  Let me map out the process, and see what turns up.

First, your C file (with Aneesh's example) needs to be parsed correctly.

M-x bovinate RET

will dump out the results.  It should be:

--------------
(("a" type
   (:members
    (("k" variable
      (:type "int")
      (reparse-symbol classsubparts)
      #<overlay from 16 to 22 in foo.c>)
     ("b" variable
      (:type "char")
      (reparse-symbol classsubparts)
      #<overlay from 27 to 34 in foo.c>))
    :type "struct")
   (unlink-copy-hook
    (semantic--tag-unlink-copy-secondary-overlays)
    link-hook
    (semantic--tag-link-secondary-overlays)
    secondary-overlays
    (#<overlay from 1 to 12 in foo.c>)
    unlink-hook
    (semantic--tag-unlink-secondary-overlays))
   #<overlay from 1 to 39 in foo.c>)
  ("t" variable
   (:type
    ("a" type
     (:prototype t :type "struct")
     nil nil))
   (:filename "/tmp/foo.c")
   #<overlay from 1 to 39 in foo.c>)
  ("main" function
   (:type "int")
   (unlink-copy-hook
    (semantic--tag-unlink-copy-secondary-overlays)
    link-hook
    (semantic--tag-link-secondary-overlays)
    secondary-overlays
    (#<overlay from 41 to 48 in foo.c>)
    unlink-hook
    (semantic--tag-unlink-secondary-overlays))
   #<overlay from 41 to 113 in foo.c>))
---------------

Or something similar.  Note that the variable "t" is marked as being of 
:type "a", so the parser (c.by) and the c support file (semantic-c.el) 
has converted the single "struct a {} t;" tag into two tags.  If it 
doesn't do this try:

C-u M-x bovinate RET M-x bovinate RET

to force the buffer to be reparsed, and see if you get a match.  If so, 
you have probably fixed the problem which was due to cached tag info.

If this doesn't work, the next thing to check, since your debug output 
claims it could not find "struct a" is to check the typecache, which is 
where the types are found.  Use:

M-x semanticdb-typecache-dump RET

Pressing SPC on a line expands it.  It should read:

---------------
]#<semanticdb-typecache /tmp/foo.c>
    ] Name: "/tmp/foo.c"
    ] Class: #'semanticdb-typecache
    ] filestream #<TAG LIST: 1 entries>
      * a : struct
    ] includestream : nil
    ] stream : nil
    ] dependants #<list o' stuff: 1 entries>
------------------

thus exposing "a" in the typecache.  If that isn't there, the merge 
issue may be semanticdb-typecache.el.  I see 4 changes that are likely 
not relevant since this past Feb.  A January 2010 change might be 
relevant.  Unfortunately, your debug output said:

---------
Current typecache Statistics:
       1 types global in this file
       0 types from includes.
---------

so I'll guess that "a" is in there.  At least, something is in there.

Since we are all in one file with no external dependencies, none of the 
"semanticdb-find" related code is going to be involved.

There isn't much else to the process that seems relevant to me.

Eric

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [CEDET-devel] ede-linux doesn't work with master emacs repo

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> First, your C file (with Aneesh's example) needs to be parsed correctly.
>
> M-x bovinate RET
>
> will dump out the results.

Here's what I get:

(("a" type
  (:members
   (("k" variable
     (:type "int")
     (reparse-symbol classsubparts)
     #<overlay from 16 to 22 in foo.c>)
    ("b" variable
     (:type "char")
     (reparse-symbol classsubparts)
     #<overlay from 27 to 34 in foo.c>))
   :type "struct")
  nil #<overlay from 1 to 39 in foo.c>)
 ("t" variable
  (:type
   ("a" type
    (:prototype t :type "struct")
    nil nil))
  nil #<overlay from 1 to 39 in foo.c>)
 ("main" function
  (:type "int")
  nil #<overlay from 41 to 113 in foo.c>))

I notice that the unlink-copy-hook entries are not present.  The above
results are identical to the bovinate output for Emacs 23.2 with
built-in CEDET.

Re: ede-linux doesn't work with master emacs repo

[Eric M. Ludlam]

On 09/28/2010 07:48 PM, Chong Yidong wrote:
> "Eric M. Ludlam"<eric@siege-engine.com>  writes:
>
>> First, your C file (with Aneesh's example) needs to be parsed correctly.
>>
>> M-x bovinate RET
>>
>> will dump out the results.
>
> Here's what I get:
>
> (("a" type
>    (:members
>     (("k" variable
>       (:type "int")
>       (reparse-symbol classsubparts)
>       #<overlay from 16 to 22 in foo.c>)
>      ("b" variable
>       (:type "char")
>       (reparse-symbol classsubparts)
>       #<overlay from 27 to 34 in foo.c>))
>     :type "struct")
>    nil #<overlay from 1 to 39 in foo.c>)
>   ("t" variable
>    (:type
>     ("a" type
>      (:prototype t :type "struct")
>      nil nil))
>    nil #<overlay from 1 to 39 in foo.c>)
>   ("main" function
>    (:type "int")
>    nil #<overlay from 41 to 113 in foo.c>))
>
> I notice that the unlink-copy-hook entries are not present.  The above
> results are identical to the bovinate output for Emacs 23.2 with
> built-in CEDET.

That's good.  The unlink hooks were because I have a decoration mode 
turned on which you probably don't have.  They are also removed during a 
save.

This seems spooky in that it cannot find "struct a" when it is right 
there in this file.  Searches for types, however, generally go through 
the typecache.  Does the typecache (from semanticdb-typecache-dump) show 
a in the cache?  If it is there, then I'm lost here, and debugging the 
analyzer will need to occur.

To do that, you can get the gist of what's going on by using edebug with 
semantic-analyze-find-tag-sequence-default.  It will probably fail in a 
call to semantic-analyze-type which is a hairy function dealing with 
inheritance, aliases, typedefs, etc.  The last non-doc fix in here was 
from 2009-04-01.

The only other hint was someone discovered a bug where the 'current 
buffer' would change in the middle of some calls to the parser.  If the 
buffer changes, then this C file would not be current, and would be 
excluded from type searches.  You can test for that while debugging the 
above.  In that case, there were some recent changes I made in the C 
parser for that, and also in semanticdb-typecache for that.

Eric

Eric

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: ede-linux doesn't work with master emacs repo

[David Engster]

Eric M. Ludlam writes:
> This seems spooky in that it cannot find "struct a" when it is right
> there in this file.  Searches for types, however, generally go through
> the typecache.  Does the typecache (from semanticdb-typecache-dump)
> show a in the cache?  If it is there, then I'm lost here, and
> debugging the analyzer will need to occur.

It's actually very simple: in semanticdb-typecache-find-default, the

(featurep 'semanticdb)

has to be changed to (featurep 'semantic/db). A quick grep shows that
there are three more:

semantic/fw.el:   (if (featurep 'semanticdb-find)
semantic/grammar.el:            (and (featurep 'semanticdb)
semantic/imenu.el:               (featurep 'semanticdb)

-David

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: ede-linux doesn't work with master emacs repo

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

> Eric M. Ludlam writes:
>> This seems spooky in that it cannot find "struct a" when it is right
>> there in this file.  Searches for types, however, generally go through
>> the typecache.  Does the typecache (from semanticdb-typecache-dump)
>> show a in the cache?  If it is there, then I'm lost here, and
>> debugging the analyzer will need to occur.
>
> It's actually very simple: in semanticdb-typecache-find-default, the
>
> (featurep 'semanticdb)
>
> has to be changed to (featurep 'semantic/db). A quick grep shows that
> there are three more:
>
> semantic/fw.el:   (if (featurep 'semanticdb-find)
> semantic/grammar.el:            (and (featurep 'semanticdb)
> semantic/imenu.el:               (featurep 'semanticdb)

Bingo.

I've checked the fix into the emacs-23 branch, and will merge it into
the trunk soon.  Thanks.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev