Thread: [CEDET-devel] Endless parsing...
Brought to you by:
zappo
From: David H. <dav...@gm...> - 2008-06-11 06:38:28
|
Hi, my *Messages* buffer is full of these. CEDET seems to never stop parsing some header files. This is from the system headers of ,----[ pkg-config --modversion gtk+-2.0 ] | 2.12.9 `---- Fontifying gtktext.h... (regexps........................) Fill column set to 79 (was 70) Mark set Fill column set to 79 (was 70) Fontifying gtktree.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying gtktreeitem.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying gtktext.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying gtktree.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying gtktreeitem.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) |
From: Eric M. L. <er...@si...> - 2008-06-11 12:07:53
|
Hi, I tried parsing those files, but had no issue. Are you using the latest CVS version of CEDET? If so, do: M-x toggle-debug-on-quit RET and then let it go. When it starts babbling, press C-g to get a useful stacktrace. Thanks Eric >>> David Hansen <dav...@gm...> seems to think that: >Hi, > >my *Messages* buffer is full of these. CEDET seems to never stop >parsing some header files. > >This is from the system headers of > >,----[ pkg-config --modversion gtk+-2.0 ] >| 2.12.9 >`---- > >Fontifying gtktext.h... (regexps........................) >Fill column set to 79 (was 70) >Mark set >Fill column set to 79 (was 70) >Fontifying gtktree.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying gtktreeitem.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying gtktext.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying gtktree.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying gtktreeitem.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] [ ... ] -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-11 22:23:23
|
On Wed, 11 Jun 2008 08:07:44 -0400 Eric M. Ludlam wrote: > I tried parsing those files, but had no issue. Are you using the > latest CVS version of CEDET? If so, do: > > M-x toggle-debug-on-quit RET > > and then let it go. When it starts babbling, press C-g to get a > useful stacktrace. The stacktrace is in your moderator queue (was to big). I just rebooted Emacs and noticed it started to parse again a whole bunch of system header files. Is this really necessary? I'm 100% sure they haven't changed a bit (and cedet didn't as well). Also wouldn't it make sense to disable font-lock, or maybe even use `fundamental-mode' when a file is read for parsing only? David |
From: Eric M. L. <er...@si...> - 2008-06-12 02:12:05
|
>>> David Hansen <dav...@gm...> seems to think that: >On Wed, 11 Jun 2008 08:07:44 -0400 Eric M. Ludlam wrote: > >> I tried parsing those files, but had no issue. Are you using the >> latest CVS version of CEDET? If so, do: >> >> M-x toggle-debug-on-quit RET >> >> and then let it go. When it starts babbling, press C-g to get a >> useful stacktrace. > >The stacktrace is in your moderator queue (was to big). > >I just rebooted Emacs and noticed it started to parse again a whole >bunch of system header files. Is this really necessary? I'm 100% sure >they haven't changed a bit (and cedet didn't as well). > >Also wouldn't it make sense to disable font-lock, or maybe even use >`fundamental-mode' when a file is read for parsing only? [ ... ] Hi, Thanks for the info and stack. According to the stack, I expect that there are just lots of headers to include, and it appears that EDE is getting involved with Webkit, as Webkit probably has Makefile.am files in it. If Webkit is particularly large, then it seems likely that loading all the Makefiles just goes and slows things down. EDE is used explicitly to help find dependencies between headers pulled from other projects. If you go and edit "Editor.h", and Emacs starts spinning, then the issue is in EDE loading webkit. A short-term fix would be to remove project-am from the autoload list in ede.el (around line 131). If it is just slow, and not really an infinite loop, you could run M-x semanticdb-find-test-translate-path and see if you get any duplicates in the resulting list, and we might be able derive why they are there, such as same header with different dir names, or something like that. I'm not sure about the font-lock thing. I don't see it font-locking messages when files are parsed in the background for me. I remember trying to get it shut off, but don't see code for it in a quick search. I can't disable all the file-init stuff since that is how Semantic gets initialized so I can parse stuff. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-12 08:53:20
|
On Wed, 11 Jun 2008 22:11:54 -0400 Eric M. Ludlam wrote: > Thanks for the info and stack. According to the stack, I expect > that there are just lots of headers to include, and it appears that > EDE is getting involved with Webkit, as Webkit probably has > Makefile.am files in it. It's not related to WebKit, just a coincidence. This time i opened just a single .c file (apart from *scratch* no buffer that is of any interest for cedet) and cedet got again stuck while parsing GTK system headers. This file is not that complex: ,----[ tst.c ] | #include <gtk/gtk.h> `---- I can produce tons of stacktraces if you like, this happens reliable every time I lean back sipp some tea or smoke a cigarette. I'm not quit sure this would help. > If Webkit is particularly large, then it seems likely that loading > all the Makefiles just goes and slows things down. EDE is used > explicitly to help find dependencies between headers pulled from other > projects. No Makefiles or any other build system anywhere in sight this time. > If it is just slow, and not really an infinite loop, you could run > > M-x semanticdb-find-test-translate-path No duplicates. > I'm not sure about the font-lock thing. I don't see it font-locking > messages when files are parsed in the background for me. I remember > trying to get it shut off, but don't see code for it in a quick > search. I can't disable all the file-init stuff since that is how > Semantic gets initialized so I can parse stuff. Not that I have the slightest idea how semantic works but can't you just initialize it and (with-temp-buffer (insert-file-contents file-name) (parse-it)) Maybe something wrong with my config? I have to admit my emacs config is a big mess and a lot of try & error and guesswork: http://www.alice-dsl.net/david.hansen/cedet-cfg.el David |
From: Eric M. L. <er...@si...> - 2008-06-12 11:24:59
|
>>> David Hansen <dav...@gm...> seems to think that: >On Wed, 11 Jun 2008 22:11:54 -0400 Eric M. Ludlam wrote: > >> Thanks for the info and stack. According to the stack, I expect >> that there are just lots of headers to include, and it appears that >> EDE is getting involved with Webkit, as Webkit probably has >> Makefile.am files in it. > >It's not related to WebKit, just a coincidence. This time i opened just >a single .c file (apart from *scratch* no buffer that is of any interest >for cedet) and cedet got again stuck while parsing GTK system headers. > >This file is not that complex: > >,----[ tst.c ] >| #include <gtk/gtk.h> >`---- > >I can produce tons of stacktraces if you like, this happens reliable >every time I lean back sipp some tea or smoke a cigarette. I'm not quit >sure this would help. I tried this (after cleaning up my semanticdb caches) and it went off parsing stuff for a while, but it did not duplicate anything that I could tell. You can use: M-x semantic-debug-idle-function and M-x semantic-debug-idle-work-function to make it replicate the idle timer function. The second time I ran the function in the sample file, it did nothing. If you saw: fontifying gtkwhatever.h (.......) flickering up over an over, then that is likely because the parsing statements from semantic put back whatever message was there before the parse, not because it is re-fontifying anything. Your messages buffer, though, had a cycle in it, so this may not be the case. [ ... ] >> I'm not sure about the font-lock thing. I don't see it font-locking >> messages when files are parsed in the background for me. I remember >> trying to get it shut off, but don't see code for it in a quick >> search. I can't disable all the file-init stuff since that is how >> Semantic gets initialized so I can parse stuff. > >Not that I have the slightest idea how semantic works but can't you just >initialize it and > >(with-temp-buffer (insert-file-contents file-name) (parse-it)) Ahh yes. I've fiddled with these things. If I do anything that doesn't involve the regular find-file type activity that I don't control wholely within CEDET, then I will eventually hit a file where someone says "Hey, my file with some special hook I have didn't parse correctly." In addition, if I hand-run (c++-mode), or some other thing like that, then it will still run c-mode-hooks, after-change-major-mode-hook, and others, often initializing the thing I didn't want. Having the mode active is required for all the buffer-local variables, and custom hooks users need to control include path and parsing. As an experiment, you could use: semantic-before-idle-scheduler-reparse-hooks and semantic-after-idle-scheduler-reparse-hooks to shut off/re-enable global-font-lock-mode, but I'd guess you'd hit some other weirdness. >Maybe something wrong with my config? I have to admit my emacs config >is a big mess and a lot of try & error and guesswork: > >http://www.alice-dsl.net/david.hansen/cedet-cfg.el [ ... ] Your config is much more complex than I'd expect but seems ok. How do you enable font-lock, and what version of Emacs are you running? Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-12 23:38:22
Attachments:
sys_errlist.h
|
On Thu, 12 Jun 2008 07:24:48 -0400 Eric M. Ludlam wrote: >>>> David Hansen <dav...@gm...> seems to think that: >>On Wed, 11 Jun 2008 22:11:54 -0400 Eric M. Ludlam wrote: >> >>> Thanks for the info and stack. According to the stack, I expect >>> that there are just lots of headers to include, and it appears that >>> EDE is getting involved with Webkit, as Webkit probably has >>> Makefile.am files in it. >> >>It's not related to WebKit, just a coincidence. This time i opened just >>a single .c file (apart from *scratch* no buffer that is of any interest >>for cedet) and cedet got again stuck while parsing GTK system headers. >> >>This file is not that complex: >> >>,----[ tst.c ] >>| #include <gtk/gtk.h> >>`---- >> >>I can produce tons of stacktraces if you like, this happens reliable >>every time I lean back sipp some tea or smoke a cigarette. I'm not quit >>sure this would help. > > I tried this (after cleaning up my semanticdb caches) and it went off > parsing stuff for a while, but it did not duplicate anything that I > could tell. I have a candidate for the offending file (but no hard evidence, it just popped up a lot in the *messages* buffer): the attached /usr/include/bits/sys_errlist.h. After opening it semantic parsed a lot in /usr/include/ and finally seems to stfu. Can I somehow get evidence? Like removing all caches and setting some var to 'barf-when-failing-to-parse-sys-errlist? |
From: David H. <dav...@gm...> - 2008-06-13 07:08:27
|
On Fri, 13 Jun 2008 01:36:43 +0200 David Hansen wrote: > I have a candidate for the offending file (but no hard evidence, it just > popped up a lot in the *messages* buffer): the attached > /usr/include/bits/sys_errlist.h. Ah, f*** it, false alarm i guess, but it's mostly three file from gtk and sys_errlist.h, is there a way to find the offender? And I forgot last time, both young and innocent: GNU Emacs 23.0.60.9 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-06-12 on robotron CEDET Version: 1.0pre5 Requested File Loaded Package Version Version Version ---------------------------------------------------------- cedet: 1.0pre5 ok ok cogre: 0.6 ok Not Loaded ede: 1.0pre5 ok ok eieio: 1.0.1 ok ok semantic: 2.0pre5 ok ok speedbar: 1.0.2 ok ok srecode: 0.1 ok ok cedet-contrib: 1.0pre5 ok Not Loaded C-h f cedet-version RET for details on output format. |
From: Eric M. L. <er...@si...> - 2008-06-13 12:16:01
|
>>> David Hansen <dav...@gm...> seems to think that: >> >> I tried this (after cleaning up my semanticdb caches) and it went off >> parsing stuff for a while, but it did not duplicate anything that I >> could tell. > >I have a candidate for the offending file (but no hard evidence, it just >popped up a lot in the *messages* buffer): the attached >/usr/include/bits/sys_errlist.h. > >After opening it semantic parsed a lot in /usr/include/ and finally >seems to stfu. Can I somehow get evidence? Like removing all caches >and setting some var to 'barf-when-failing-to-parse-sys-errlist? Hmmm. I have that same file. When I loaded it up into a buffer, it spent a bunch of time parsing all the neighboring files, but then didn't do it a second time. Perhaps you there are too many nearby files for Emacs to parse. I checked in a change adding this option: semantic-idle-work-parse-neighboring-files-flag to disable the new neighboring file parsing feature. Perhaps this will fix the performance issues you are seeing. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-14 04:23:24
|
On Fri, 13 Jun 2008 08:15:50 -0400 Eric M. Ludlam wrote: >>>> David Hansen <dav...@gm...> seems to think that: >>> >>> I tried this (after cleaning up my semanticdb caches) and it went off >>> parsing stuff for a while, but it did not duplicate anything that I >>> could tell. >> >>I have a candidate for the offending file (but no hard evidence, it just >>popped up a lot in the *messages* buffer): the attached >>/usr/include/bits/sys_errlist.h. >> >>After opening it semantic parsed a lot in /usr/include/ and finally >>seems to stfu. Can I somehow get evidence? Like removing all caches >>and setting some var to 'barf-when-failing-to-parse-sys-errlist? > > Hmmm. I have that same file. When I loaded it up into a buffer, it > spent a bunch of time parsing all the neighboring files, but then > didn't do it a second time. > > Perhaps you there are too many nearby files for Emacs to parse. > > I checked in a change adding this option: > > semantic-idle-work-parse-neighboring-files-flag > > to disable the new neighboring file parsing feature. Perhaps this > will fix the performance issues you are seeing. It shouldn't be a pure performance issue. It's not the latest and greatest but far away from being archaic trash: ,----[ cat /proc/cpuinfo ] | processor : 0 | vendor_id : AuthenticAMD | cpu family : 6 | model : 8 | model name : AMD Athlon(tm) XP 2200+ | stepping : 1 | cpu MHz : 1792.455 | cache size : 256 KB | fdiv_bug : no | hlt_bug : no | f00f_bug : no | coma_bug : no | fpu : yes | fpu_exception : yes | cpuid level : 1 | wp : yes | flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov | pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts | bogomips : 3586.41 | clflush size : 32 | `---- I let my box running for a while not touching anything. It always ended up (according to *Messages*) with parsing these all over again: Fontifying gtktext.h... (regexps........................) Fill column set to 79 (was 70) Mark set Fill column set to 79 (was 70) Fontifying gtktree.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying gtktreeitem.h... (regexps........................) Fill column set to 79 (was 70) [2 times] Mark set Fill column set to 79 (was 70) Fontifying sys_errlist.h... (regexps........................) Fill column set to 79 (was 70) [2 times] After several hours it should have finished these, shouldn't it? I'm sorry but I have no idea how to produce more useful information. David |
From: Eric M. L. <er...@si...> - 2008-06-15 02:37:32
|
>>> David Hansen <dav...@gm...> seems to think that: >On Fri, 13 Jun 2008 08:15:50 -0400 Eric M. Ludlam wrote: [ ... ] >It shouldn't be a pure performance issue. It's not the latest and >greatest but far away from being archaic trash: > >,----[ cat /proc/cpuinfo ] >| processor : 0 >| vendor_id : AuthenticAMD >| cpu family : 6 >| model : 8 >| model name : AMD Athlon(tm) XP 2200+ >| stepping : 1 >| cpu MHz : 1792.455 >| cache size : 256 KB >| fdiv_bug : no >| hlt_bug : no >| f00f_bug : no >| coma_bug : no >| fpu : yes >| fpu_exception : yes >| cpuid level : 1 >| wp : yes >| flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov >| pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts >| bogomips : 3586.41 >| clflush size : 32 >| >`---- My machine is very similar in vintage. >I let my box running for a while not touching anything. It always ended >up (according to *Messages*) with parsing these all over again: > >Fontifying gtktext.h... (regexps........................) >Fill column set to 79 (was 70) >Mark set >Fill column set to 79 (was 70) >Fontifying gtktree.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying gtktreeitem.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] >Mark set >Fill column set to 79 (was 70) >Fontifying sys_errlist.h... (regexps........................) >Fill column set to 79 (was 70) [2 times] > >After several hours it should have finished these, shouldn't it? I'm >sorry but I have no idea how to produce more useful information. [ ... ] For this, I'd start with: M-x debug-on-entry RET set-fill-column RET and see why it keeps setting the fill column. I agree with your earlier assessment that when loading up files I need to disable other random tools, but it is unclear how I can do that safely. If you identify this other tool, perhaps I can work with it to find something good. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-15 02:53:26
|
On Sat, 14 Jun 2008 22:37:23 -0400 Eric M. Ludlam wrote: >>>> David Hansen <dav...@gm...> seems to think that: >> >>Fontifying gtktext.h... (regexps........................) >>Fill column set to 79 (was 70) >>[...] > > For this, I'd start with: > > M-x debug-on-entry RET set-fill-column RET > > and see why it keeps setting the fill column. Probably because I change it in `c-mode-common-hook'. David |
From: Eric M. L. <er...@si...> - 2008-06-15 12:30:01
|
>>> David Hansen <dav...@gm...> seems to think that: >On Sat, 14 Jun 2008 22:37:23 -0400 Eric M. Ludlam wrote: > >>>>> David Hansen <dav...@gm...> seems to think that: >>> >>>Fontifying gtktext.h... (regexps........................) >>>Fill column set to 79 (was 70) >>>[...] >> >> For this, I'd start with: >> >> M-x debug-on-entry RET set-fill-column RET >> >> and see why it keeps setting the fill column. > >Probably because I change it in `c-mode-common-hook'. [ ... ] Ah. Well, for that you could just put in: (setq fill-column 79) and be done with that message. I'm a little confused by the font lock, since you are running Emacs 23 also. That version of font-lock appears, for me anyway, to not actually do any font locking when I read the file in. I put a hack into semanticdb to disable font-lock specifically, and checked that in. My fear is that this won't actually change anything as it had no real effect for me. Do you have your files in some sort of auto-mount system using file-system aliases? If this were the case, I use `file-truename' when storing tables in semanticdb, but your system include path may point at the alias. For example, if you had your path as: /home/dhansen/include/gtk-2.0/ but this is an alias for a real path of: /automount/home/dhansen/include/gtk-2.0/ then it may be confusing the bit that doesn't repeat parsing. You could try: M-: (file-truename "/home/dhansen/include/gtk-2.0/") RET and see if it's different. file-truename is a bit pokey, so I've tried to delay using it to non-time-critical tasks. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-15 13:08:26
|
On Sun, 15 Jun 2008 08:29:51 -0400 Eric M. Ludlam wrote: >>>> David Hansen <dav...@gm...> seems to think that: >>On Sat, 14 Jun 2008 22:37:23 -0400 Eric M. Ludlam wrote: >> >>>>>> David Hansen <dav...@gm...> seems to think that: >>>> >>>>Fontifying gtktext.h... (regexps........................) >>>>Fill column set to 79 (was 70) >>>>[...] >>> >>> For this, I'd start with: >>> >>> M-x debug-on-entry RET set-fill-column RET >>> >>> and see why it keeps setting the fill column. >> >>Probably because I change it in `c-mode-common-hook'. > [ ... ] > > Ah. Well, for that you could just put in: > > (setq fill-column 79) > > and be done with that message. I think it would be more interesting to get semantic to stop parsing files it already parsed for several hundred times. > I put a hack into semanticdb to disable font-lock specifically, and > checked that in. My fear is that this won't actually change anything > as it had no real effect for me. I'll report back if it's doing something. > Do you have your files in some sort of auto-mount system using > file-system aliases? If this were the case, I use `file-truename' > when storing tables in semanticdb, but your system include path may > point at the alias. No symbolic links/automount/NFS involved. One FS for /usr/ a different one for /home/ both on the same local HD. Pretty typical setup. Is semantic looking at $C_INCLUDE_PATH ? I have set that in addition to `semantic-add-system-include' (if not, that may be a nice little feature). David |
From: David H. <dav...@gm...> - 2008-06-15 13:53:22
|
On Sun, 15 Jun 2008 14:58:31 +0200 David Hansen wrote: >> I put a hack into semanticdb to disable font-lock specifically, and >> checked that in. My fear is that this won't actually change anything >> as it had no real effect for me. > > I'll report back if it's doing something. The fontification messages disappeared from the *Messages* buffer. There's is still something showing up in the echo area (maybe the fontification "progress bar"?) but it disappears to fast. Maybe the difference between our setups is that I define a bunch of keywords using `font-lock-add-keywords' (`FIXME:', `XXX:' and stuff). I also use `column-marker' mode (an external package you can use to highlight a specific column or over long lines). If it will help, I can fiddle around a bit with my config and report back. David |
From: Eric M. L. <er...@si...> - 2008-06-15 14:43:25
|
I checked in a new tool to try and find out why tags are parsed more than once. If you can get the updates from CVS, you can try: M-x semanticdb-find-adebug-scanned-includes RET and it will list every tag representing a include file found, and what it did with it. You can then decide if the same file was scanned multiple times. Eric >>> David Hansen <dav...@gm...> seems to think that: >On Sun, 15 Jun 2008 14:58:31 +0200 David Hansen wrote: > >>> I put a hack into semanticdb to disable font-lock specifically, and >>> checked that in. My fear is that this won't actually change anything >>> as it had no real effect for me. >> >> I'll report back if it's doing something. > >The fontification messages disappeared from the *Messages* buffer. >There's is still something showing up in the echo area (maybe the >fontification "progress bar"?) but it disappears to fast. > >Maybe the difference between our setups is that I define a bunch of >keywords using `font-lock-add-keywords' (`FIXME:', `XXX:' and stuff). I >also use `column-marker' mode (an external package you can use to >highlight a specific column or over long lines). > >If it will help, I can fiddle around a bit with my config and report >back. [ ... ] -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-16 03:38:28
|
On Sun, 15 Jun 2008 10:43:14 -0400 Eric M. Ludlam wrote: > I checked in a new tool to try and find out why tags are parsed more > than once. If you can get the updates from CVS, you can try: > > M-x semanticdb-find-adebug-scanned-includes RET > > and it will list every tag representing a include file found, and what > it did with it. You can then decide if the same file was scanned > multiple times. Hmm, I added (message "XXX: %s" (buffer-file-name)) to my c-mode hook. The usual suspects are opened over and over again: [...] XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h XXX: /usr/include/bits/sys_errlist.h [2 times] Quit Mark set Mark saved where search started Mark set Mark saved where search started Auto-saving...done XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h XXX: /usr/include/bits/sys_errlist.h [2 times] [...] But `semanticdb-find-adebug-scanned-includes' shows them as parsed and not duplicated (there show up a lot of duplicates but none of the above files). Here is the full output for above file: *scanned gtk/gtktext.h : /home/dhansen/include/gtk-2.0/gtk/gtk.h | Name: "gtk/gtktext.h" | Class: 'include | Position: 5427 -> 5451 in gtk.h | Attributes: # :system-flag : 't | Properties: # dependency-file : "/home/dhansen/include/gtk-2.0/gtk/gtktext.h" # :filename : "/home/dhansen/include/gtk-2.0/gtk/gtk.h" *scanned gtk/gtktree.h : /home/dhansen/include/gtk-2.0/gtk/gtk.h | Name: "gtk/gtktree.h" | Class: 'include | Position: 5829 -> 5853 in gtk.h | Attributes: # :system-flag : 't | Properties: # :filename : "/home/dhansen/include/gtk-2.0/gtk/gtk.h" # dependency-file : "/home/dhansen/include/gtk-2.0/gtk/gtktree.h" *scanned gtk/gtktreeitem.h : /home/dhansen/include/gtk-2.0/gtk/gtk.h | Name: "gtk/gtktreeitem.h" | Class: 'include | Position: 5882 -> 5910 in gtk.h | Attributes: # :system-flag : 't | Properties: # :filename : "/home/dhansen/include/gtk-2.0/gtk/gtk.h" # dependency-file : "/home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h" *scanned bits/sys_errlist.h : /usr/include/stdio.h | Name: "bits/sys_errlist.h" | Class: 'include | Position: 28190 -> 28219 in stdio.h | Attributes: # :system-flag : 't | Properties: # :filename : "/usr/include/stdio.h" David |
From: Eric M. L. <er...@si...> - 2008-06-16 11:27:23
|
>>> David Hansen <dav...@gm...> seems to think that: >On Sun, 15 Jun 2008 10:43:14 -0400 Eric M. Ludlam wrote: > >> I checked in a new tool to try and find out why tags are parsed more >> than once. If you can get the updates from CVS, you can try: >> >> M-x semanticdb-find-adebug-scanned-includes RET >> >> and it will list every tag representing a include file found, and what >> it did with it. You can then decide if the same file was scanned >> multiple times. > >Hmm, I added (message "XXX: %s" (buffer-file-name)) to my c-mode hook. >The usual suspects are opened over and over again: > >[...] >XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h >Mark set >XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h >XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h >Mark set >XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h >XXX: /usr/include/bits/sys_errlist.h [2 times] >Quit [ ... ] Thanks for the info. I like your idea with the hook better. If you set up your hook like this: (defun my-c-debug-hook () (message "XXX %s" (buffer-file-name))) and then (add-hook 'c-mode-hook 'my-c-debug-hook ) you could then do: M-x debug-on-entry RET my-c-debug-hook RET and generate a stack for each duplicate hit. This will tell us what is loading in these files, or perhaps what is running `c-mode' on them without loading them. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-16 15:23:23
|
On Mon, 16 Jun 2008 07:27:12 -0400 Eric M. Ludlam wrote: > M-x debug-on-entry RET my-c-debug-hook RET > > and generate a stack for each duplicate hit. This will tell us what > is loading in these files, or perhaps what is running `c-mode' on them > without loading them. Here are two rounds of backtraces: http://www.alice-dsl.net/david.hansen/bt.txt.gz David |
From: Eric M. L. <er...@si...> - 2008-06-17 01:24:55
|
>>> David Hansen <dav...@gm...> seems to think that: >On Mon, 16 Jun 2008 07:27:12 -0400 Eric M. Ludlam wrote: > >> M-x debug-on-entry RET my-c-debug-hook RET >> >> and generate a stack for each duplicate hit. This will tell us what >> is loading in these files, or perhaps what is running `c-mode' on them >> without loading them. > >Here are two rounds of backtraces: > >http://www.alice-dsl.net/david.hansen/bt.txt.gz [ ... ] Hi, It certainly looks like semantic is confused. I wrote a new debug function for you to try out. It is in CVS in semantic-adebug.el M-x semanticdb-debug-file-tag-check RET /some/file/name RET or you can script it. If you load a fresh Emacs, it should provide useful info about why it may choose to refresh a file. It should safely list out file sizes and mod times which are now used to make sure those headers aren't changing. If Semantic thinks the file has changed, it will reparse it. The above function should reveal the specific piece of data causing it to think those files need a refresh. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-17 05:38:23
|
On Mon, 16 Jun 2008 21:24:45 -0400 Eric M. Ludlam wrote: > It certainly looks like semantic is confused. I wrote a new debug > function for you to try out. It is in CVS in semantic-adebug.el > > > M-x semanticdb-debug-file-tag-check RET /some/file/name RET > > or you can script it. If you load a fresh Emacs, it should provide > useful info about why it may choose to refresh a file. It should > safely list out file sizes and mod times which are now used to make > sure those headers aren't changing. If Semantic thinks the file has > changed, it will reparse it. > > The above function should reveal the specific piece of data causing it > to think those files need a refresh. > Here you go. The first data comes from right after I started emacs, only the *scratch* buffer there: Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables)> Found Table is: #<semanticdb-table gtktext.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 7120 Needs Refresh: t No tags in table. File Size is: 7119 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 7119 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktree.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktree.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables DIRTY)> Found Table is: #<semanticdb-table gtktree.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 4606 Needs Refresh: t No tags in table. File Size is: 4605 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 4605 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables DIRTY)> Found Table is: #<semanticdb-table gtktreeitem.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 3038 Needs Refresh: t No tags in table. File Size is: 3037 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 3037 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /usr/include/bits/sys_errlist.h TrueName is: /usr/include/bits/sys_errlist.h Directory Part is: /usr/include/bits/ Found Database is: #<semanticdb-project-database-file bits/ (100 tables)> Found Table is: #<semanticdb-table sys_errlist.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 1285 Needs Refresh: t No tags in table. File Size is: 1284 File Mod Time is: 2008-06-03 03:51:23 Saved file size is: 1284 Saved Mod time is: 2008-06-03 03:51:23 Now I opened one .c file that I knew would start the endless reparsing, had a tea and cigarette and waited for the idle timer to start. The *Messages* buffer displayed: XXX: /usr/lib/gcc/i486-linux-gnu/4.2/include/stdarg.h XXX: /usr/lib/gcc/i486-linux-gnu/4.2/include/stddef.h XXX: /usr/lib/gcc/i486-linux-gnu/4.2/include/stdbool.h XXX: /home/dhansen/include/gtk-2.0/gtk/gtktext.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktext.h XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktree.h XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h Mark set XXX: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h XXX: /usr/include/bits/sys_errlist.h [2 times] Mark set [2 times] and the `semanticdb-debug-file-tag-check': Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables)> Found Table is: #<semanticdb-table gtktext.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 7120 Needs Refresh: t No tags in table. File Size is: 7119 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 7119 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktree.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktree.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables DIRTY)> Found Table is: #<semanticdb-table gtktree.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 4606 Needs Refresh: t No tags in table. File Size is: 4605 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 4605 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktreeitem.h Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ Found Database is: #<semanticdb-project-database-file gtk/ (196 tables DIRTY)> Found Table is: #<semanticdb-table gtktreeitem.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 3038 Needs Refresh: t No tags in table. File Size is: 3037 File Mod Time is: 2008-06-03 23:29:26 Saved file size is: 3037 Saved Mod time is: 2008-06-03 23:29:26 Starting file is: /usr/include/bits/sys_errlist.h TrueName is: /usr/include/bits/sys_errlist.h Directory Part is: /usr/include/bits/ Found Database is: #<semanticdb-project-database-file bits/ (100 tables)> Found Table is: #<semanticdb-table sys_errlist.h (0 tags)> Action Summary: Found table that needs refresh. Saved pointmax: 1285 Needs Refresh: t No tags in table. File Size is: 1284 File Mod Time is: 2008-06-03 03:51:23 Saved file size is: 1284 Saved Mod time is: 2008-06-03 03:51:23 David |
From: Eric M. L. <er...@si...> - 2008-06-17 11:58:17
|
>>> David Hansen <dav...@gm...> seems to think that: >On Mon, 16 Jun 2008 21:24:45 -0400 Eric M. Ludlam wrote: [ ... ] >> M-x semanticdb-debug-file-tag-check RET /some/file/name RET [ ... ] >> The above function should reveal the specific piece of data causing it >> to think those files need a refresh. >> > >Here you go. The first data comes from right after I started emacs, >only the *scratch* buffer there: > >Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h >TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h >Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ >Found Database is: #<semanticdb-project-database-file gtk/ (196 tables)> >Found Table is: #<semanticdb-table gtktext.h (0 tags)> > >Action Summary: Found table that needs refresh. > Saved pointmax: 7120 Needs Refresh: t > No tags in table. > File Size is: 7119 > File Mod Time is: 2008-06-03 23:29:26 > Saved file size is: 7119 > Saved Mod time is: 2008-06-03 23:29:26 > [ ... ] > >Starting file is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h >TrueName is: /home/dhansen/include/gtk-2.0/gtk/gtktext.h >Directory Part is: /home/dhansen/include/gtk-2.0/gtk/ >Found Database is: #<semanticdb-project-database-file gtk/ (196 tables)> >Found Table is: #<semanticdb-table gtktext.h (0 tags)> > >Action Summary: Found table that needs refresh. > Saved pointmax: 7120 Needs Refresh: t > No tags in table. > File Size is: 7119 > File Mod Time is: 2008-06-03 23:29:26 > Saved file size is: 7119 > Saved Mod time is: 2008-06-03 23:29:26 [ ... ] Aha! Inside gtktext.h is the line: #ifdef GTK_ENABLE_BROKEN for the whole file, resulting in no tags being parsed, thus it always needs to be refreshed. You could enable GTK_ENABLE_BROKEN in your preprocessor table (to thus enable completion on these parts.) I have (I would guess) the same gtk headers, but for some reason the reparsing was invisible to me. No tags was a flag for semantic to do a reparse, but since I added file size and last mod-time monitoring, it should no longer be needed. Try out this patch, and let me know if it helps, or if it starts messing things up. I tried it on a gtk header, and it seemed find, but I haven't tried too many other permutations. I also noticed my todo statement is now stale. :) Thanks Eric ---------------- *** semanticdb.el 15 Jun 2008 08:21:43 -0400 1.114 --- semanticdb.el 17 Jun 2008 07:48:16 -0400 *************** *** 498,504 **** ) (or (not (slot-boundp obj 'tags)) ! (not (oref obj tags)) ;; @TODO - use fsize instead (/= (or (oref obj fsize) 0) actualsize) (not (equal (oref obj lastmodtime) actualmod)) --- 498,504 ---- ) (or (not (slot-boundp obj 'tags)) ! ;; (not (oref obj tags)) --> not needed anymore? ;; @TODO - use fsize instead (/= (or (oref obj fsize) 0) actualsize) (not (equal (oref obj lastmodtime) actualmod)) -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: David H. <dav...@gm...> - 2008-06-17 14:53:25
|
On Tue, 17 Jun 2008 07:58:07 -0400 Eric M. Ludlam wrote: > Aha! Inside gtktext.h is the line: > > #ifdef GTK_ENABLE_BROKEN Hooray! :) > Try out this patch, and let me know if it helps, or if it starts > messing things up. I tried it on a gtk header, and it seemed find, > but I haven't tried too many other permutations. Just applied it. Seems to do a good job. > Thanks > Eric I have to thank you for your patience and this nice piece of software. David |
From: Eric M. L. <er...@si...> - 2008-06-17 17:04:04
|
>>> David Hansen <dav...@gm...> seems to think that: [ ... ] >> Try out this patch, and let me know if it helps, or if it starts >> messing things up. I tried it on a gtk header, and it seemed find, >> but I haven't tried too many other permutations. > >Just applied it. Seems to do a good job. > >> Thanks >> Eric > >I have to thank you for your patience and this nice piece of software. [ ... ] Great. I checked in the change. Thanks also for running all those crazy scripts to try an narrow things down. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |