CEDET

Hi,

  I submitted a change to semantic-tag-file.el which should help in
this case where the #include is a <system> include, and where your
project is help inside EDE.

  If that is not the case, and it is just using the semanticdb project
roots, then I'll need to look into it some more.

  Thanks for identifying this.  It ought to lead to some good
optimizations.

Eric

>>> "Ashish Hanwadikar" <ahanwadi@...> seems to think that:
>I am trying to setup semantic intellisense for a large project (possibly
>more than 1000 files). It is extremely slow and thus, unusable in the
>current state. The relevant .emacs is at the end of this email. I found out
>using 'strace' that it is trying to locate the include file (say, include
><b/a.h>) in my project. The algorithm seems to be the following:
>1) try, current directory/b/a.h -- Not found
>2) then, current directory/a.h -- Not found
>3) the, for each subdirectory in the system include path, try, system
>include dir/subdir/b/a.h -- Not found
>
>The last step, takes a lot of time as it has to through hundreds of sub
>directories. Just like the step 1), why doesn't it directly try, system
>include dir/b/a.h? It will find that file immediately.
>
>I don't know enough lisp to fix this. But if somebody can point to me where
>I should be looking for, I am willing to give it a try.
>
>thanks in advance,
>Ashish Hanwadikar
  [ ... ]

-- 
          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

Actually, I am using semanticdb project roots. After I removed the recursive
option, it is working fine (although, it cannot do intellisense completion
if I used a symbol or struct from a file that is only indirectly included).
I can live with that currently. I am prepared to spend some time to fix this
issue, but I will need a few pointers as to where to start. I was able to
turn on edebug on quit/error and then step through the code in
semanticdb-find.el. But I don't know when exactly the semanticdb-database is
created and how does it go recursively through the paths.

Thx,
Ashish

On 6/22/07, Eric M. Ludlam <eric@...> wrote:
>
> Hi,
>
>   I submitted a change to semantic-tag-file.el which should help in
> this case where the #include is a <system> include, and where your
> project is help inside EDE.
>
>   If that is not the case, and it is just using the semanticdb project
> roots, then I'll need to look into it some more.
>
>   Thanks for identifying this.  It ought to lead to some good
> optimizations.
>
> Eric
>
> >>> "Ashish Hanwadikar" <ahanwadi@...> seems to think that:
> >I am trying to setup semantic intellisense for a large project (possibly
> >more than 1000 files). It is extremely slow and thus, unusable in the
> >current state. The relevant .emacs is at the end of this email. I found
> out
> >using 'strace' that it is trying to locate the include file (say, include
> ><b/a.h>) in my project. The algorithm seems to be the following:
> >1) try, current directory/b/a.h -- Not found
> >2) then, current directory/a.h -- Not found
> >3) the, for each subdirectory in the system include path, try, system
> >include dir/subdir/b/a.h -- Not found
> >
> >The last step, takes a lot of time as it has to through hundreds of sub
> >directories. Just like the step 1), why doesn't it directly try, system
> >include dir/b/a.h? It will find that file immediately.
> >
> >I don't know enough lisp to fix this. But if somebody can point to me
> where
> >I should be looking for, I am willing to give it a try.
> >
> >thanks in advance,
> >Ashish Hanwadikar
>   [ ... ]
>
> --
>           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
>



-- 
Ashish Hanwadikar
Web: http://ashish.typepad.com/ashishs_niti

>>> Tom Tromey <tromey@...> seems to think that:
>I downloaded CEDET 1.0pre4 and built it with make.  I'm using GNU
>Emacs 22.0.990.1 on FC6.  (This is an Emacs 22 pre-release that was
>built in the Fedora "development" repository -- I think it is also
>what appears in F7.)
>
>When I open various files from the GCC source tree, I will
>occasionally see errors from CEDET.  Here are some typical ones:
>
>idle error: "#<buffer c-parser.c> - Invalid function: eldoc-message" [3 times]
>idle error: "#<buffer c-decl.c> - Invalid function: eldoc-message"
>idle error: "#<buffer c-decl.c> - Wrong type argument: arrayp, nil"
>idle error: "#<buffer c-decl.c> - Wrong type argument: arrayp, nil"
>
>This is just GCC svn trunk.  I can email files from it if that will
>help.
  [ ... ]

The missing "eldoc-message" function indicates that the eldoc.el you
have may not have the eldoc-message command, or it has a different
name.  If you had no eldoc.el, then you'd get a different error.

If you do a

M-x find-library RET eldoc RET

it will hopefully find the eldoc you have with your emacs.  It should
have a defun for eldoc-message somewhere.

For the other messages, if you can do this:

M-x toggle-debug-on-error RET

This will enable errors to be thrown out of the idle scheduler.  The
resulting stack would then prove useful for debugging what the problem
might be.  Perhaps it is related to the funny eldoc configuration
issue above.

Thanks
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

>>> Tom Tromey <tromey@...> seems to think that:
>Eric> M-x toggle-debug-on-error RET
>
>Tom> I will try to get a stack trace for you.  I restarted Emacs and I'm
>Tom> still seeing it, but I forgot to enable the debugger first.
>
>I tried again and I couldn't reproduce this.  I also tried deleting
>semantic.cache to see if that would somehow help.  If I manage to see
>this again I'll send a new note -- sorry about that, and thanks for
>your time.
  [ ... ]

That's fine.  I know there is a problem lurking in there, but every
time I teach someone how to get a useful stack trace after they see
it, it can't be reproduced again.  Hmmm.

I tried creating an automatic stack-trace grabber, but it was
unpleasantly slow and had odd behavior.  It'll be found eventually.

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" == Eric M Ludlam <eric@...> writes:

Eric> The missing "eldoc-message" function indicates that the eldoc.el you
Eric> have may not have the eldoc-message command, or it has a different
Eric> name.  If you had no eldoc.el, then you'd get a different error.

Oops -- I had an ancient eldoc.el in my load-path.  Sorry about that.
And, thanks.

Eric> M-x toggle-debug-on-error RET
Eric> This will enable errors to be thrown out of the idle scheduler.  The
Eric> resulting stack would then prove useful for debugging what the problem
Eric> might be.  Perhaps it is related to the funny eldoc configuration
Eric> issue above.

I will try to get a stack trace for you.  I restarted Emacs and I'm
still seeing it, but I forgot to enable the debugger first.

Tom

Eric> M-x toggle-debug-on-error RET

Tom> I will try to get a stack trace for you.  I restarted Emacs and I'm
Tom> still seeing it, but I forgot to enable the debugger first.

I tried again and I couldn't reproduce this.  I also tried deleting
semantic.cache to see if that would somehow help.  If I manage to see
this again I'll send a new note -- sorry about that, and thanks for
your time.

Tom

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

Eric> That's fine.  I know there is a problem lurking in there, but every
Eric> time I teach someone how to get a useful stack trace after they see
Eric> it, it can't be reproduced again.  Hmmm.

I can reproduce the bug right now, reliably, in my running Emacs.
(This is an Emacs without the previous eldoc shadowing problem I had
earlier.)

However if I eval (setq debug-on-error t), I no longer see the idle error.
Likewise, if I (setq stack-trace-on-error t), I don't get a stack trace.

Any other suggestions?

Tom

>>>>> "Tom" == Tom Tromey <tromey@...> writes:

Tom> Any other suggestions?

I was playing around a bit and tried senator-complete-symbol and got
the appended trace.  The error was:

eieiomt-method-list: Wrong type argument: arrayp, nil

I hope this helps.  I'm not sure if this whether the same error as the
other one I see.

Tom

  eieiomt-next(nil)
  eieiomt-method-list(semanticdb-needs-refresh-p 0 nil)
  eieio-generic-call(semanticdb-needs-refresh-p (nil))
  semanticdb-needs-refresh-p(nil)
  semanticdb-file-table-object("mode-classes.def" nil)
  semanticdb-find-table-for-include-default(("mode-classes.def" include nil nil [1172 1199]) nil)
  semanticdb-find-table-for-include(("mode-classes.def" include nil nil [1172 1199]))
  semanticdb-find-translate-path-includes-default(nil)
  semanticdb-find-translate-path-default(nil nil)
  semanticdb-find-translate-path(nil nil)
  semanticdb-find-tags-collector(#[(table tags) "\303	
#\207" [table prefix tags semanticdb-find-tags-for-completion-method] 4] nil nil)
  semanticdb-find-tags-for-completion("n")
  semantic-analyze-find-tags-by-prefix("n")
  semantic-analyze-possible-completions-default([object semantic-analyze-context "context" (3960 . 3961) ("n") (function variable) nil nil nil nil #<buffer c-lex.c>])
  semantic-analyze-possible-completions([object semantic-analyze-context "context" (3960 . 3961) ("n") (function variable) nil nil nil nil #<buffer c-lex.c>])
  senator-find-tag-for-completion("n")
  senator-complete-symbol()
  call-interactively(senator-complete-symbol)

Nice Stack.  Thanks!

I'm guessing the appended patch (at the bottom) will fix this specific
instance.

I'm guessing that you have something like:

#include "mode-classes.def"

so semantic thinks it can load it, but when it does, no parser is
available, and no database table is created for it.

The patch below will fix the immediate problem, but I'm not sure what
a nil flowing through the rest of the system will do... yet.

I'll likely concoct my own same sometime this weekend and work out the
details.

Another option for you is to modify the auto-mode-alist so that .def
files go into c++ mode.

The other problem looks like eieio is providing a rather lame error
message.

Thanks!
Eric

>>> Tom Tromey <tromey@...> seems to think that:
>>>>>> "Tom" == Tom Tromey <tromey@...> writes:
>
>Tom> Any other suggestions?
>
>I was playing around a bit and tried senator-complete-symbol and got
>the appended trace.  The error was:
>
>eieiomt-method-list: Wrong type argument: arrayp, nil
>
>I hope this helps.  I'm not sure if this whether the same error as the
>other one I see.
>
>Tom
>
>  eieiomt-next(nil)
>  eieiomt-method-list(semanticdb-needs-refresh-p 0 nil)
>  eieio-generic-call(semanticdb-needs-refresh-p (nil))
>  semanticdb-needs-refresh-p(nil)
>  semanticdb-file-table-object("mode-classes.def" nil)
>  semanticdb-find-table-for-include-default(("mode-classes.def" include nil nil [1172 1199]) nil)
>  semanticdb-find-table-for-include(("mode-classes.def" include nil nil [1172 1199]))
>  semanticdb-find-translate-path-includes-default(nil)
>  semanticdb-find-translate-path-default(nil nil)
>  semanticdb-find-translate-path(nil nil)
>  semanticdb-find-tags-collector(#[(table tags) "\303	
>#\207" [table prefix tags semanticdb-find-tags-for-completion-method] 4] nil nil)
>  semanticdb-find-tags-for-completion("n")
>  semantic-analyze-find-tags-by-prefix("n")
>  semantic-analyze-possible-completions-default([object semantic-analyze-context "context" (3960 . 3961) ("n") (function variable) nil nil nil nil #<buffer c-lex.c>])
>  semantic-analyze-possible-completions([object semantic-analyze-context "context" (3960 . 3961) ("n") (function variable) nil nil nil nil #<buffer c-lex.c>])
>  senator-find-tag-for-completion("n")
>  senator-complete-symbol()
>  call-interactively(senator-complete-symbol)
  [ ... ]

--------

*** semanticdb.el	20 May 2007 11:56:43 -0400	1.84
--- semanticdb.el	15 Jun 2007 09:17:09 -0400	
***************
*** 656,662 ****
  		;; the first time, and the idle scheduler didn't get a
  		;; chance to trigger a parse before the file buffer is
  		;; killed.
! 		(when (semanticdb-needs-refresh-p semanticdb-current-table)
  		  (semanticdb-refresh-table semanticdb-current-table))
  		(prog1
  		    semanticdb-current-table
--- 656,664 ----
  		;; the first time, and the idle scheduler didn't get a
  		;; chance to trigger a parse before the file buffer is
  		;; killed.
! 		(when (and 
! 		       semanticdb-current-table
! 		       (semanticdb-needs-refresh-p semanticdb-current-table))
  		  (semanticdb-refresh-table semanticdb-current-table))
  		(prog1
  		    semanticdb-current-table

-- 
          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" == Eric M Ludlam <eric@...> writes:

Eric> I'm guessing the appended patch (at the bottom) will fix this specific
Eric> instance.

Yes, this worked for the senator-complete-symbol problem.

Initially, even with this patch, I still saw the idle error.
But after running senator-complete-symbol, it seems to have gone away.

Eric> I'm guessing that you have something like:
Eric> #include "mode-classes.def"
Eric> so semantic thinks it can load it, but when it does, no parser is
Eric> available, and no database table is created for it.

Yes, indeed.  Some of the .def files in GCC have c-mode set in their
local variables section, but the majority of them do not.

Eric> Another option for you is to modify the auto-mode-alist so that .def
Eric> files go into c++ mode.

I may give this a try.  Thanks for the quick patch :-)

Tom

>>> <klaus.berndl@...> seems to think that:
>Hannes Janetzek wrote:
>> Hi,
>> I'm pretty new to emacs, so perhaps this is already possible. So what
>> do you think of the feature that the creation of a sourcepath can call
>> a hook that could be used to create tags for the sourcepath folder,
>> an ede-project or other things?
>
>yes, sounds as a nifty suggestion - i will add it to the todo list....
>Thanks a lot.
>
>> 
>> Another question, which should probably go to the cedet list too: is
>> it possible that semantic uses etags? since I'm uncomfortable with
>> the idea that all files are parsed by semantic AND etags.
>
>yes,  think with the new pre4 of cedet you can add arbitrary backends...
>
>ask in the cedet-list for this...
>
>Klaus

Any tagger could be used in semantic for a backend when searching for
tags by name.  Only semantic provides the details needed for editing
conveniences, or non-name based searching.

There is currently no canned support for etags.  If it were written,
it would be useful when pointing CEDET at a new batch of source-code
for the first time, but after a while, CEDET would have parsed
everything and the TAGS file would be ignored.  You can already do
this with EBROWSE.  See `semanticdb-create-ebrowse-database`.

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

Henri Servomaa wrote:
> On 13.6.2007, at 16:41, Martin Buchmann wrote:
>=20
>> Klaus and Arne,
>>=20
>> sorry for being imprecise. Carbonemacs is is a Carbon/OSX
>> distribution of GNU Emacs, with moderate amount of UNIX & Mac
>> integration. I use the same cedet/ECB (pre4/2.33beta1) with both
>> builds of Emacs. I tried to use the debugger as you suggested but the
>> backtrace only looks like this:
>>=20
>> Debugger entered--Lisp error: (quit)
>>    signal(quit nil)
>>    keyboard-quit()
>>    call-interactively(keyboard-quit)
>>=20
>> The file I am editing is stored on a local volume and it already
>> happens if I really am editing only one file. Emacs just becomes
>> unusable, i.e. I can't move in the file, change buffers or type
>> without a delay of some seconds.
>>=20
>> I've tested the new CVS Emacs even without any of my customization
>> and then loaded cedet and ECB and ended up in the same situation. It
>> also doesn't depend on the file which is edited, i.e. the modes that
>> are loaded when opening a file do seem to play a role. As the older
>> CVS built is usable as usually I will keep on using this.
>>=20
>> Thanks for your help so far
>>    Martin
>=20
> Hi folks,
>=20
> I suspect something has changed in emacs.
> With *everything else* being the same, a carbon emacs build after
> June 2 is
> very very slow with ecb.
> I don't see any errors though, and it's slow on both nfs mounted and
> local files.

Sorry, i can not test here with a carbon emacs, so i can't help you in
finding the problem, sorry... maybe a look into the change-log of the =
latest
build would help................

Is it also slow when opening a file which is not supported by a =
semantic-grammar?
In such a case at least the idle-timers of cedet should not run....

Here is a list of all pre/post-command-hooks and idle-timers of ecb - =
just
take a look at the values of the following variables:

ecb-idle-timer-alist
ecb-post-command-hooks
ecb-pre-command-hooks

The idle-timer-alist contains cons-cells with car =3D functionsymbol of =
that function
run by the idle-timer and cdr ist an timer-object as returned by =
run-with-idle-timer.

Unfortunately i have no clue what could be the problem-root...

Klaus

>=20
> For now, I am staying with a build from June 1st.
>=20
> Cheers

klaus.berndl@... wrote:

  Hi

> >> sorry for being imprecise. Carbonemacs is is a Carbon/OSX
> >> distribution of GNU Emacs, with moderate amount of UNIX & Mac
> >> integration. I use the same cedet/ECB (pre4/2.33beta1) with both
> >> builds of Emacs.

  I haven't followed this thread very closely, but my Emacs did very
slow down on Windows when I updated the CVS a few months ago, as well
as with the fresh official 22.1 build.  It was related to the variable
'timer-idle-list'.  To display the content of this variable when the
sympthom happens:

    C-h v timer-idle-list RET

  You can then try to set this variable to nil to see if the problem
disapear (don't try that in a real Emcs session with important work
within):

    M-: (setq timer-idle-list nil) RET

  I really not sure that this will help you, but that could be worth
trying.

  Regards,

--drkm























      
	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Hi,

  Speedbar doesn't operate in the same Emacs frame, because there is
no simple way to protect the created window for speedbar without doing
a whole lot of work.

  The ECB project (http://ecb.sf.net) has a few acres of code
dedicated to maintaining speedbar like frames in the main Emacs
frame.  It will also embed speedbar for you.

Eric


>>> Leo <sdl.web@...> seems to think that:
>Hi,
>
>I wonder if speedbar could be made not to use a separate frame. We have
>seen many users want it this feature.
>
>There is a hack in this url¹ but it might be a good idea to support it
>properly upstream.
>
>Footnotes: 
>¹  http://www.emacswiki.org/cgi-bin/wiki/SpeedBar

-- 
          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 wrote:
> Hi,
>=20
>   Speedbar doesn't operate in the same Emacs frame, because there is
> no simple way to protect the created window for speedbar without doing
> a whole lot of work.
>=20
>   The ECB project (http://ecb.sf.net) has a few acres of code
> dedicated to maintaining speedbar like frames in the main Emacs
> frame.=20

Eric is fully right... you need thousands lines of elisp-code to offer =
some "special" windows
in an Emacs-frame which are are protected against "to be deleted by =
commands like
delete-other-windwos etc...". Take a look at ECB as mentioned by Eric - =
and take=20
a look in the code of ecb-layout.el - this and more is necessary to =
offer what
you want...

Currently there are two different approaches out there:
- speedbar running in a separate frame
- ECB running all browsing windows in the same frame as you edit your =
code...all of them
  proteced in the meaning above - ECB offers you to run the speedbar in =
one of its
  protected windows...

Choose the approach you like most...

Klaus

> It will also embed speedbar for you.
>=20
> Eric
>=20
>=20
>>>> Leo <sdl.web@...> seems to think that: Hi,
>>=20
>> I wonder if speedbar could be made not to use a separate frame. We
>> have seen many users want it this feature.
>>=20
>> There is a hack in this url=B9 but it might be a good idea to support
>> it properly upstream.=20
>>=20
>> Footnotes:
>> =B9  http://www.emacswiki.org/cgi-bin/wiki/SpeedBar