CEDET

'fajfusio' writes:
> I added semantic-c-dependency-system-include-path set to nil but still no
> success.
> Please help me to force cedet not to parse system headers.

Remove 'system from semanticdb-find-default-throttle. You can do this on
a per-mode basis through

(setq-mode-local c-mode semanticdb-find-default-throttle '(local project unloaded recursive))

If you want to restrict this to one project, I guess you can set the
above through the :local-variables slot (`ede-set-project-variables').

-David

On 10/18/2010 05:11 AM, David Engster wrote:
> 'fajfusio' writes:
>> I added semantic-c-dependency-system-include-path set to nil but still no
>> success.
>> Please help me to force cedet not to parse system headers.
>
> Remove 'system from semanticdb-find-default-throttle. You can do this on
> a per-mode basis through
>
> (setq-mode-local c-mode semanticdb-find-default-throttle '(local project unloaded recursive))
>
> If you want to restrict this to one project, I guess you can set the
> above through the :local-variables slot (`ede-set-project-variables').

I think that this, or possibly the solution David provided yesterday 
that involves the semantic--before-fetch-tags-hook for large files would 
also work.  There isn't much in the way of "don't analyze that" options 
in Semantic.

Eric

> > Hi
> > 
> > How can I force cedet not to parse system libraries.
> > I would like cedet to look only in my c++ project. I tried to configure
> it via
> > the system-include-path as follows but it did not help.
> > 
> > I use:
> > emacs 23
> > cedet 1.0_pre7-r1
> > 
> > ~/.emacs:
> > ; Load CEDET
> > (load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
> > (global-ede-mode t)
> > (semantic-load-enable-code-helpers)
> > (ede-cpp-root-project "myProj"
> >                 :name "myProj"
> >                 :file "~/myProj/main.cpp"
> >                 :system-include-path '("")
> >                 )
> > 
> > thank you for help
> 
> Hi
> 
> I added semantic-c-dependency-system-include-path set to nil but still no
> success.
> Please help me to force cedet not to parse system headers.
> 
> My current ~/.emacs looks as follows:
> 
> ~/.emacs:
> (load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
> (global-ede-mode t)
> (semantic-load-enable-code-helpers)
> (ede-cpp-root-project "myProj"
>                 :name "myProj"
>                 :file "~/myProj/main.cpp"
>                 :system-include-path '("")
>                 :include-path '("")
>                 )
> '(semantic-c-dependency-system-include-path nil)

Looks like I found the necessary command:
(semantic-remove-system-include "/usr/include/" 'c++-mode)

Unfortunately it works only when I execute it directly in emacs. It does 
not
have an effect in ~/.emacs file. I placed it at the end of my ~/.emacs 
file:

(load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
(global-ede-mode t)
(semantic-load-enable-code-helpers)
(ede-cpp-root-project "myProj"
                :name "myProj"
                :file "~/myProj/main.cpp"
                )
(semantic-remove-system-include "/usr/include/" 'c++-mode)

Do you know what's wrong with my emacs configuration ?
thank you for help

'fajfusio' writes:
> Looks like I found the necessary command:
> (semantic-remove-system-include "/usr/include/" 'c++-mode)
>
> Unfortunately it works only when I execute it directly in emacs. It does 
> not
> have an effect in ~/.emacs file.

Did you try the solution I posted last week?
    
-David

> 'fajfusio' writes:
> > Looks like I found the necessary command:
> > (semantic-remove-system-include "/usr/include/" 'c++-mode)
> >
> > Unfortunately it works only when I execute it directly in emacs. It does
> > not
> > have an effect in ~/.emacs file.
> 
> Did you try the solution I posted last week?
>     
> -David

I've just found your previous feedback in my mailbox. I couldn't find it 
at
sourceforge's mailing list archives.

I prepared new configuration according to your suggestions:

(load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
(global-ede-mode t)
(semantic-load-enable-code-helpers)
(ede-cpp-root-project "myProj"
                :name "myProj"
                :file "~/myProj/main.cpp"
                )
(setq-mode-local c-mode semanticdb-find-default-throttle '(local project 
unloaded recursive))

Now semantic does not parse /usr/include and /usr/local/include but still
parses /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/* directories.

When I set the throttle for c++-mode it additionaly parses /usr/include 
and
/usr/local/include (looks like c++-mode does not have an effect).

I haven't tried Eric's suggestion about semantic--before-fetch-tags-hook
yet (most probably with semantic-remove-system-include). I'm going to 
let you
know about the results.

thanks for your patience

On 10/16/2010 01:21 PM, David Engster wrote:
> Eric M. Ludlam writes:
>> On 10/04/2010 01:50 PM, David Engster wrote:
>>   >  +(define-mode-local-override semantic--tag-similar-types-p c-mode
>> (tag1 tag2)
>>   >  +  "For c-mode, if only one of the types is fully qualfied, we
>>   >  +split its name and compare the last element."
>>
>> In this case my mail says there is a qualified typo.
>
> :-)
>
>> But aside from that, after splitting the names, should it compare the
>> last N strings, where N is min( num_tag1_strs, num_tag2_strs ) instead?
>>    That way if you have:
>>
>> foo::bar::someclass myfcn();
>>
>> noodle::poodle::someclass myfcn() { }
>>
>> it won't get confused?
>
> The code did only compare types in case one of them is a string, i.e.,
> not qualified at all. But you are right that comparing the last N
> strings is better, since one of the types could just be 'shorter' (half
> qualified? whatever...), meaning it wouldn't detect that those two
>
> namespace foo {
>    bar::someclass myfcn();
> }
>
> foo::bar::someclass myfcn();
>
> are in fact the same.
>
> I've rewritten the similar-type function to do what you've suggested,
> and I've finally merged that branch into trunk (use 'bzr log -n0' to see
> the single commits).
>

Great!

Thanks for your help on this, and many other things this past week or so.

Only 2 weeks left until my big Punkin Chunkin contest!  I learned that 
my machine will be one of the featured catapults on the Science Channel 
this year, and the Mythbuster guys will be the hosts of the show.  How 
cool will that be?

Yea, I thought so. :)

Eric

> Andreas, the current trunk should be able to deal with all the problems
> you've encountered (or so I hope...).

Re-tested with bzr revision 8010, all ok!
Thanks again, with this CEDET has become really useful for me.
I'll let you know if I can find other interesting test-cases :)

Andreas

Hi, 

I was wondering if a context-sensitive semantic-symref-symbol search is
possible. For example, it would be really powerful to be able to find
references of a member of a class in C++: 

semantic-symref-symbol MyClass::myfunction

Thanks..

Hi, 

I was wondering if a context-sensitive semantic-symref-symbol search is
possible. For example, it would be really powerful to be able to find
references of a member of a class in C++: 

semantic-symref-symbol MyClass::myfunction

Thanks..

On 10/14/2010 03:00 PM, yyetim wrote:
> Hi,
>
> I was wondering if a context-sensitive semantic-symref-symbol search is
> possible. For example, it would be really powerful to be able to find
> references of a member of a class in C++:
>
> semantic-symref-symbol MyClass::myfunction

Hi,

   That was the intent, but that aspect of semantic-symref was never 
implemented.  The way to solve the problem won't be too hard, as it is 
in one place, and the pre-existing Analyzer can be run at that spot to 
do the determination.

   The problem, of course, is that it will be much slower, so if there 
are lots of hits of the name, it could be unbearable.

   If anyone wants to tackle this problem, I have a patch that shows 
where to start and what to think about.

Eric

I would be willing to work on that but in a month or so, unless someone
else wants to try it earlier. 

Thanks,
Yavuz

On Mon, 2010-10-18 at 22:31 -0400, Eric M. Ludlam wrote:
> On 10/14/2010 03:00 PM, yyetim wrote:
> > Hi,
> >
> > I was wondering if a context-sensitive semantic-symref-symbol search is
> > possible. For example, it would be really powerful to be able to find
> > references of a member of a class in C++:
> >
> > semantic-symref-symbol MyClass::myfunction
> 
> Hi,
> 
>    That was the intent, but that aspect of semantic-symref was never 
> implemented.  The way to solve the problem won't be too hard, as it is 
> in one place, and the pre-existing Analyzer can be run at that spot to 
> do the determination.
> 
>    The problem, of course, is that it will be much slower, so if there 
> are lots of hits of the name, it could be unbearable.
> 
>    If anyone wants to tackle this problem, I have a patch that shows 
> where to start and what to think about.
> 
> Eric

On 10/10/2010 09:40 AM, A.Kulgov wrote:
> Hi,
>
> I try to build CEDET from CVS on my xubuntu machine with emacs23, and
> got error on `make utest`:
>
> ...
>   - Running semantic: lex spp table write ...
> File mode specification error: (wrong-type-argument stringp nil)
>     * done
>   - Running semantic: multi-lang parsing ...
>
>  >> Setting up  tests to run @ Sun Oct 10 16:32:27 2010
>
>   - Running multi-lang parsing ...
>   * C tests...
> File mode specification error: (wrong-type-argument stringp nil)
> File mode specification error: (wrong-type-argument stringp nil)
>     * ERROR: (error "Buffer sutest.c was not set up for parsing")
> to debug this test point, execute:
> semantic-utest-main
>
>   ** Exiting Test Suite. **
>
> make: *** [utest] Error 1

This looks like a bug in your c-mode-hook, or other initialization you 
might have for C files as installed by your OS.  Distributions like 
debian will install code that runs when Emacs starts that is not ignored 
in -batch mode for Emacs.  Check for startup messages  at the beginning 
of the utest output that says things like:

(loading package FOO.)

and perhaps one of those is causing this issue.

Eric

Suvayu Ali writes:
> On Wednesday 13 October 2010 12:32 PM, David Engster wrote:
>> Thanks. This happens because semantic-tag-similar-p moved to
>> semantic-tag-ls.el, and now there's a 'require' or autoload cookie
>> missing. It's probably a trivial fix, but I'm not sure where to put
>> this, so I'd rather let Eric do it.
>>
>> For now, you should be able to fix this by putting
>>
>> (require 'semantic-tag-ls)
>>
>> into semantic-tag.el.
>
> I put above require at the top of semantic/semantic-tag.el but then it 
> fails to build with an error message like this, :(

See? That's why I said "I'd rather let Eric do it". ;-)

OK, next try: In semantic.el, change the (require 'semantic-tag) to 

(require 'semantic-tag-ls)

-David

Hi David,

On 13 October 2010 23:39, David Engster <deng@...> wrote:
> Suvayu Ali writes:
>> On Wednesday 13 October 2010 12:32 PM, David Engster wrote:
>>> Thanks. This happens because semantic-tag-similar-p moved to
>>> semantic-tag-ls.el, and now there's a 'require' or autoload cookie
>>> missing. It's probably a trivial fix, but I'm not sure where to put
>>> this, so I'd rather let Eric do it.
>>>
>>> For now, you should be able to fix this by putting
>>>
>>> (require 'semantic-tag-ls)
>>>
>>> into semantic-tag.el.
>>
>> I put above require at the top of semantic/semantic-tag.el but then it
>> fails to build with an error message like this, :(
>
> See? That's why I said "I'd rather let Eric do it". ;-)
>

:-p

> OK, next try: In semantic.el, change the (require 'semantic-tag) to
>
> (require 'semantic-tag-ls)
>

The build finished successfully after that. I'm using Emacs with (setq
debug-on-error t). I'll post back if I see similar problems again.

Thank you soo much. :)


> -David
>

-- 
Suvayu

Open source is the future. It sets us free.

On Thursday 14 October 2010 12:40 PM, suvayu ali wrote:
> The build finished successfully after that. I'm using Emacs with (setq
> debug-on-error t). I'll post back if I see similar problems again.

I have been using for about a day now, no problems so far. So I guess 
that require resolves this. :)

-- 
Suvayu

Open source is the future. It sets us free.

Suvayu Ali writes:
> On Thursday 14 October 2010 12:40 PM, suvayu ali wrote:
>> The build finished successfully after that. I'm using Emacs with (setq
>> debug-on-error t). I'll post back if I see similar problems again.
>
> I have been using for about a day now, no problems so far. So I guess 
> that require resolves this. :)

Thank you for testing. Though I'm not sure this fix is really the best
solution, this bug is *really* annoying (it inhibits yanking), so I've
decided to push this to the trunk. Right after that, I've stumbled upon
another problem in semantic--tag-attribute-similar-p-default, which
should also be fixed now.

-David

On 10/14/2010 02:39 AM, David Engster wrote:
> Suvayu Ali writes:
>> On Wednesday 13 October 2010 12:32 PM, David Engster wrote:
>>> Thanks. This happens because semantic-tag-similar-p moved to
>>> semantic-tag-ls.el, and now there's a 'require' or autoload cookie
>>> missing. It's probably a trivial fix, but I'm not sure where to put
>>> this, so I'd rather let Eric do it.
>>>
>>> For now, you should be able to fix this by putting
>>>
>>> (require 'semantic-tag-ls)
>>>
>>> into semantic-tag.el.
>>
>> I put above require at the top of semantic/semantic-tag.el but then it
>> fails to build with an error message like this, :(
>
> See? That's why I said "I'd rather let Eric do it". ;-)
>
> OK, next try: In semantic.el, change the (require 'semantic-tag) to
>
> (require 'semantic-tag-ls)

Hi,

I normally solve issues like this by just adding an:

;;;###autoload

cookie in front of the missing function.  The autoload build in the make 
process will then catch it, and make it available.  There are many 
others like that in the file.

If someone would like to try this out, please do.  I won't get to it for 
a while.

Eric

Suvayu Ali writes:
> I am having an odd problem, after I checkout CEDET from the bzr HEAD I 
> edit the Makefile and commit the changes and then compile with `make all 
> -j2'. Now when I want to update, I do `make clean-all' then try to 
> update with `bzr merge --pull'. But every time bzr tells me there are 
> other files which have been modified (the changes usually look like only 
> whitespace changes, from the output of `bzr diff').
>
> Since I didn't change them, I presume they get changed during the first 
> build. So I end up deleting the whole directory and checking out afresh 
> again. I am sure I am doing something very stupid. How should I go about 
> doing this? This methodology had worked quite well with emacs 24 HEAD.

Yes, files get changed during the build. This is unfortunate and due to
bzr not preserving timestamps from the repo. Newer bzr versions at least
make sure that all files have the same timestamp; we'll still have to
fix a few things in the grammar-compilation, though.

Anyhow, if you do 'bzr revert' it should reverse those changes and you
can then pull from the repo.

Other people prefer to always have a pristine 'trunk' and to use
branches for everything else. You could create a 'build' branch by doing

bzr branch cedet/trunk cedet/build

Then you only 'pull' in the trunk-directory, whereas you make/hack in
build. After pulling in trunk, you can 'merge' in build to apply the
changes there.

-David

On Saturday 16 October 2010 12:36 AM, David Engster wrote:
> Yes, files get changed during the build. This is unfortunate and due to
> bzr not preserving timestamps from the repo. Newer bzr versions at least
> make sure that all files have the same timestamp; we'll still have to
> fix a few things in the grammar-compilation, though.
>
> Anyhow, if you do 'bzr revert' it should reverse those changes and you
> can then pull from the repo.
>
> Other people prefer to always have a pristine 'trunk' and to use
> branches for everything else. You could create a 'build' branch by doing
>
> bzr branch cedet/trunk cedet/build
>
> Then you only 'pull' in the trunk-directory, whereas you make/hack in
> build. After pulling in trunk, you can 'merge' in build to apply the
> changes there.
>

Thanks a lot David! Both of those seem like very workable solutions to 
me. This has been very helpful. :)

> -David

-- 
Suvayu

Open source is the future. It sets us free.