Thread: [CEDET-devel] Apparently circular structure
Brought to you by:
zappo
From: Alastair R. <ar...@in...> - 2008-06-11 04:05:10
|
Hi, First off thanks to Eric for the fantastic work on CEDET. I've just upgraded to the CVS version and am loving it. As per instructions I've got it configured to parse my c++ headers, including Boost (1.34.1 if it matters). This mostly works, although causes the following error message: Save Error: "Apparently circular structure being printed": [path to semanticdb]/!drive_d!dev!include!boost!preprocessor!seq!semantic.cache A similar error occurs for drive_d!dev!include!boost!preprocessor!repetition!semantic.cache BTW the file boost/preprocessor/seq.hpp looks pretty harmless: http://svn.boost.org/trac/boost/browser/branches/RC_1_34_0/boost/boost/preprocessor/seq.hpp I don't know how to debug this any further, suggestions? |
From: Eric M. L. <er...@si...> - 2008-06-11 12:04:51
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Hi, > >First off thanks to Eric for the fantastic work on CEDET. I've just >upgraded to the CVS version and am loving it. > >As per instructions I've got it configured to parse my c++ headers, >including Boost (1.34.1 if it matters). This mostly works, although >causes the following error message: > >Save Error: "Apparently circular structure being printed": [path to >semanticdb]/!drive_d!dev!include!boost!preprocessor!seq!semantic.cache > >A similar error occurs for >drive_d!dev!include!boost!preprocessor!repetition!semantic.cache > >BTW the file boost/preprocessor/seq.hpp looks pretty harmless: >http://svn.boost.org/trac/boost/browser/branches/RC_1_34_0/boost/boost/preprocessor/seq.hpp > >I don't know how to debug this any further, suggestions? [ ... ] I encountered that exact same boost file yesterday. The boost repetition file has recursive macros which do indeed refer to themselves somehow, though I doubt it's circular. (I'm not a boost expert.) In order to get cpp macros resolved during parse time from headers, the lexical tables are now stored in semanticdb, so that is where the write error comes in. I wrote a custom printer for the lex table that short-circuits for very large macros. Hopefully if you update from CVS again, this should fix up that issue, though I had also turned off my boost header parsing since I had actual work stuff to get done too, so I'm not entirely sure. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-11 23:30:13
|
Eric M. Ludlam wrote: > In order to get cpp macros resolved during parse time from headers, > the lexical tables are now stored in semanticdb, so that is where the > write error comes in. I wrote a custom printer for the lex table that > short-circuits for very large macros. Hopefully if you update from > CVS again, this should fix up that issue, though I had also turned off > my boost header parsing since I had actual work stuff to get done too, > so I'm not entirely sure. With the latest CVS, I'm getting an error on load: Debugger entered--Lisp error: (void-function inversion-require-emacs) inversion-require-emacs("21.1" "21.4") Commenting this out, I'm getting parsing errors (elided backtrace:) Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p (1 . 25)) semantic-make-overlay(1 (1 . 25) #<buffer myFile.cpp>) semantic--tag-link-to-buffer(("globalPch.hpp" include nil nil [1 (1 . 25)])) mapcar(semantic--tag-link-to-buffer (("globalPch.hpp" include nil nil [1 ...]) ("boost/bind.hpp" include (:system-flag t) nil [27 ...]) ("myLib/myFile.hpp" include nil nil [54 ...]) ("Tibra" type (:members ... :type "namespace") nil [106 2597]))) semantic-fetch-tags() ... |
From: Eric M. L. <er...@si...> - 2008-06-12 02:23:53
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Eric M. Ludlam wrote: > >> In order to get cpp macros resolved during parse time from headers, >> the lexical tables are now stored in semanticdb, so that is where the >> write error comes in. I wrote a custom printer for the lex table that >> short-circuits for very large macros. Hopefully if you update from >> CVS again, this should fix up that issue, though I had also turned off >> my boost header parsing since I had actual work stuff to get done too, >> so I'm not entirely sure. > >With the latest CVS, I'm getting an error on load: > >Debugger entered--Lisp error: (void-function inversion-require-emacs) > inversion-require-emacs("21.1" "21.4") What version of Emacs are you running. Not 20.x or some-such? >Commenting this out, I'm getting parsing errors (elided backtrace:) > >Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p >(1 . 25)) > semantic-make-overlay(1 (1 . 25) #<buffer myFile.cpp>) > semantic--tag-link-to-buffer(("globalPch.hpp" include nil nil [1 (1 . >25)])) > mapcar(semantic--tag-link-to-buffer (("globalPch.hpp" include nil nil >[1 ...]) ("boost/bind.hpp" include (:system-flag t) nil [27 ...]) >("myLib/myFile.hpp" include nil nil [54 ...]) ("Tibra" type (:members >... :type "namespace") nil [106 2597]))) > semantic-fetch-tags() >... [ ... ] That's a bit of a mystery. It may be that one of your cache files got a bit messed up. Deleting your ~/.semanticdb/... file that matches the directory you are working in should tidy up the issue if it was unique to some write-error you were getting before with boost. If there is a write-error of some sort, this will repeat next time you exit (and save the caches) and restart. As it looks specific to an include tag, it may be simple to create a reproducable file. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-12 05:34:52
|
Eric M. Ludlam wrote: >>>> Alastair Rankine <ar...@in...> seems to think that: >> Commenting this out, I'm getting parsing errors (elided backtrace:) >> > > That's a bit of a mystery. It may be that one of your cache files got > a bit messed up. Deleting your ~/.semanticdb/... file that matches > the directory you are working in should tidy up the issue if it was > unique to some write-error you were getting before with boost. If > there is a write-error of some sort, this will repeat next time you > exit (and save the caches) and restart. Thanks, I took the nuclear option and reset all my semanticdb caches and did a fresh cedet checkout from CVS. Aside from a wierd problem with line endings causing a compilation failure in semantic-grammar-wy.el (easily fixed), I seem to be ... back where I started :) Or maybe. I'm still getting the "Apparently circular structure" error message when trying to save <path>!boost!preprocessor!repetition!semantic.cache Is there a way of finding out exactly what is the circularity that is causing the problem? Alternatively, can I just punt and exclude this entire subdirectory from being parsed in the first place? (I've tried excluding individual files by pre-defining their header guards, but it's hit-or-miss and so far all miss...) Thanks again. |
From: Eric M. L. <er...@si...> - 2008-06-12 11:05:22
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Eric M. Ludlam wrote: >>>>> Alastair Rankine <ar...@in...> seems to think that: >>> Commenting this out, I'm getting parsing errors (elided backtrace:) >>> >> >> That's a bit of a mystery. It may be that one of your cache files got >> a bit messed up. Deleting your ~/.semanticdb/... file that matches >> the directory you are working in should tidy up the issue if it was >> unique to some write-error you were getting before with boost. If >> there is a write-error of some sort, this will repeat next time you >> exit (and save the caches) and restart. > >Thanks, I took the nuclear option and reset all my semanticdb caches and >did a fresh cedet checkout from CVS. Aside from a wierd problem with >line endings causing a compilation failure in semantic-grammar-wy.el >(easily fixed), I seem to be ... back where I started :) Drat. >Or maybe. I'm still getting the "Apparently circular structure" error >message when trying to save ><path>!boost!preprocessor!repetition!semantic.cache > >Is there a way of finding out exactly what is the circularity that is >causing the problem? Use: M-x toggle-debug-on-error Then find-file some file in that boost directory, like repetion.h, or whichever it is called. Now do: M-: (eieio-persistent-save semanticdb-current-database) RET which will do the save, and allow errors to be caught by the debugger. This stack, will probably point at writing out some list that has pre-processor symbols in it. I worked around that a couple days ago, but your header may be slightly different. >Alternatively, can I just punt and exclude this entire subdirectory from >being parsed in the first place? (I've tried excluding individual files >by pre-defining their header guards, but it's hit-or-miss and so far all >miss...) [ ... ] If the issue is in the preprocessor writer, perhaps the limiter I placed there is too large. Try shrinking: semantic-lex-spp-macro-max-length-to-save to 1, which should certainly fix it. Then increase it to 10, or whichever is needed for any macros you require out of your header files. You can change this variable, then try: M-x semanticdb-save-db to see if it works. Alternatively, use semantic--before-fetch-tags-hook to shut things off for particular files. Something like this: (add-hook 'semantic--before-fetch-tags-hook (lambda () (if (string-match "^/path/I/dont/like" (buffer-file-name)) nil t))) If the max-length var fixes it, please let me know, as I can fiddle the default and other things to make this not occur. Thanks Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-13 04:38:50
|
Eric M. Ludlam wrote: > M-: (eieio-persistent-save semanticdb-current-database) RET > > which will do the save, and allow errors to be caught by the > debugger. This stack, will probably point at writing out some list > that has pre-processor symbols in it. I worked around that a couple > days ago, but your header may be slightly different. OK, well here is the stack dump: http://pastie.org/214130.txt I have not the expertise to work out what it means, but I can't help noticing that the first macro in the list is BOOST_PP_REPEAT_2_I, which is defined thus: # define BOOST_PP_REPEAT_2_I(c, m, d) BOOST_PP_REPEAT_2_ ## c(m, d) Is the token pasting used here causing the problem? Or does it point in the right direction? > If the issue is in the preprocessor writer, perhaps the limiter I > placed there is too large. Try shrinking: > > semantic-lex-spp-macro-max-length-to-save > > to 1, which should certainly fix it. Then increase it to 10, or > whichever is needed for any macros you require out of your header > files. You can change this variable, then try: > > M-x semanticdb-save-db OK so that seemed to work initially. I reduced it to 1, did a semanticdb-save-all-db and all seemed well. Specifically, there was a cache file created for this directory. A bit later and it is obviously parsing other files, and I'm still getting the error, even with the max length still set to 1. In this case there are two errors, in a slightly different location: <path>!boost!preprocessor!seq!semantic.cache <path>!boost!preprocessor!seq!detail!semantic.cache > Alternatively, use semantic--before-fetch-tags-hook to shut things off > for particular files. Something like this: > > (add-hook 'semantic--before-fetch-tags-hook > (lambda () (if (string-match "^/path/I/dont/like" > (buffer-file-name)) > nil > t))) That works nicely, thanks. |
From: Eric M. L. <er...@si...> - 2008-06-13 12:18:09
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Eric M. Ludlam wrote: >> M-: (eieio-persistent-save semanticdb-current-database) RET >> >> which will do the save, and allow errors to be caught by the >> debugger. This stack, will probably point at writing out some list >> that has pre-processor symbols in it. I worked around that a couple >> days ago, but your header may be slightly different. > >OK, well here is the stack dump: http://pastie.org/214130.txt Thanks for the stack. I put some protection into that top function to hopefully catch such issues quickly and let you keep going. I checked this into CVS this morning in semantic-lex-spp.el >I have not the expertise to work out what it means, but I can't help >noticing that the first macro in the list is BOOST_PP_REPEAT_2_I, which >is defined thus: > ># define BOOST_PP_REPEAT_2_I(c, m, d) BOOST_PP_REPEAT_2_ ## c(m, d) Indeed. It does look as if it is repeating itself so the printer is confused, as opposed to actually identifying a circular list. >Is the token pasting used here causing the problem? Or does it point in >the right direction? > >> If the issue is in the preprocessor writer, perhaps the limiter I >> placed there is too large. Try shrinking: >> >> semantic-lex-spp-macro-max-length-to-save >> >> to 1, which should certainly fix it. Then increase it to 10, or >> whichever is needed for any macros you require out of your header >> files. You can change this variable, then try: >> >> M-x semanticdb-save-db > >OK so that seemed to work initially. I reduced it to 1, did a >semanticdb-save-all-db and all seemed well. Specifically, there was a >cache file created for this directory. > >A bit later and it is obviously parsing other files, and I'm still >getting the error, even with the max length still set to 1. In this case >there are two errors, in a slightly different location: > ><path>!boost!preprocessor!seq!semantic.cache ><path>!boost!preprocessor!seq!detail!semantic.cache [ ... ] If you could try my patch to see if it also fixes these, that would be great. Thanks Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-16 02:07:48
|
Thanks Eric for the quick turnaround... Eric M. Ludlam wrote: >>>> Alastair Rankine <ar...@in...> seems to think that: >> OK, well here is the stack dump: http://pastie.org/214130.txt > > Thanks for the stack. I put some protection into that top function to > hopefully catch such issues quickly and let you keep going. > > I checked this into CVS this morning in semantic-lex-spp.el OK so I did a fresh CVS checkout [*] and reset the semanticdb cache files. Now I'm getting a wierd error in the idle work function, here is a stack dump: http://pastie.org/215620.txt (unfortunately I've had to remove some sensitive information in the form of file/directory names but hopefully you get the idea...) From what I can tell the error seems to relate to not being able to find the EDE project root, and yet I'm pretty sure it is set up fine. If I run M-: (ede-toplevel) from one of my project's files, it correctly returns the project that I had configured in my .emacs file: (ede-cpp-root-project "MyProject" :file "d:/path/to/project/root.txt" :include-path '( "/" ) :system-include-path '( "d:/dev/include/" "c:/Program Files/Microsoft Visual Studio 8/VC/include/" ) :spp-table '( ( "_MSC_VER" . "1400" ) ) ) Haven't changed anything here in the last few days, but that's not to say it wasn't broken to begin with :) [*] Eventually I realised that my CVS updates weren't working because it thought that some of my *.el files were locally modified. Unfortunately I couldn't work a) why the files were modified in the first place (all I did was "make"), and b) how to do the CVS equivalent of "revert" (it's been too long :). Enlightenment on these two issues is very welcome. |
From: Eric M. L. <er...@si...> - 2008-06-16 11:35:11
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Thanks Eric for the quick turnaround... > >Eric M. Ludlam wrote: >>>>> Alastair Rankine <ar...@in...> seems to think that: >>> OK, well here is the stack dump: http://pastie.org/214130.txt >> >> Thanks for the stack. I put some protection into that top function to >> hopefully catch such issues quickly and let you keep going. >> >> I checked this into CVS this morning in semantic-lex-spp.el > >OK so I did a fresh CVS checkout [*] and reset the semanticdb cache files. > >Now I'm getting a wierd error in the idle work function, here is a stack >dump: http://pastie.org/215620.txt > >(unfortunately I've had to remove some sensitive information in the form >of file/directory names but hopefully you get the idea...) > > From what I can tell the error seems to relate to not being able to >find the EDE project root, and yet I'm pretty sure it is set up fine. If >I run M-: (ede-toplevel) from one of my project's files, it correctly >returns the project that I had configured in my .emacs file: > >(ede-cpp-root-project "MyProject" > :file "d:/path/to/project/root.txt" > :include-path '( "/" ) > :system-include-path '( "d:/dev/include/" > "c:/Program >Files/Microsoft Visual Studio 8/VC/include/" ) > :spp-table '( ( "_MSC_VER" . "1400" ) ) > ) > >Haven't changed anything here in the last few days, but that's not to >say it wasn't broken to begin with :) Your stack implies that ede-minor-mode is somehow 't' in a directory related to boost/variant/variant.hpp but it does not actually have a project associated with it. If you loaded that file, and tried: M-: ede-object RET does it say nil, while M-: ede-minor-mode RET is t? I checked in a small change that should catch the error, though I can't imagine why it is true. >[*] Eventually I realised that my CVS updates weren't working because it > thought that some of my *.el files were locally modified. >Unfortunately I couldn't work a) why the files were modified in the >first place (all I did was "make"), and b) how to do the CVS equivalent >of "revert" (it's been too long :). Enlightenment on these two issues is >very welcome. [ ... ] I'm not sure why your local .el files were locally modified. If you get "M"s in your cvs update output, you can just delete the files if you want them to update. You can use PCL CVS from the "Tools" menu in Emacs to find and fix this sort of thing, and even do your CVS updates. This might help in your case. Good Luck Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-17 01:52:38
|
Eric M. Ludlam wrote: > Your stack implies that ede-minor-mode is somehow 't' in a directory > related to boost/variant/variant.hpp but it does not actually have a > project associated with it. > > If you loaded that file, and tried: > > M-: ede-object RET > > does it say nil, while > > M-: ede-minor-mode RET > > is t? Actually no - both functions return nil for that file when the error occurs. I will email a complete stack dump if it helps. I initially thought this might be related to global-ede-mode although I have verified the problem with this both enabled and disabled. Do you have any other suggestions? Other than PEBKAC of course. > I'm not sure why your local .el files were locally modified. If you > get "M"s in your cvs update output, you can just delete the files if > you want them to update. > > You can use PCL CVS from the "Tools" menu in Emacs to find and fix > this sort of thing, and even do your CVS updates. This might help in > your case. Thanks for the pointer - I had used it in the past and forgotten about it. I just did an update through PCL CVS and build with no problems, or locally-modified files. |
From: Eric M. L. <er...@si...> - 2008-06-17 02:15:31
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Eric M. Ludlam wrote: >> Your stack implies that ede-minor-mode is somehow 't' in a directory >> related to boost/variant/variant.hpp but it does not actually have a >> project associated with it. >> >> If you loaded that file, and tried: >> >> M-: ede-object RET >> >> does it say nil, while >> >> M-: ede-minor-mode RET >> >> is t? > >Actually no - both functions return nil for that file when the error >occurs. I will email a complete stack dump if it helps. > >I initially thought this might be related to global-ede-mode although I >have verified the problem with this both enabled and disabled. > >Do you have any other suggestions? Other than PEBKAC of course. [ ... ] I had wrapped the specific pieces your last stack pointed at with a (condition-case ...) If you are still getting an error from it, I would like to see the stack, as presumably it will be different. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-06-17 05:23:09
|
Eric M. Ludlam wrote: >>>> Alastair Rankine <ar...@in...> seems to think that: >> Eric M. Ludlam wrote: >>> Your stack implies that ede-minor-mode is somehow 't' in a directory >>> related to boost/variant/variant.hpp but it does not actually have a >>> project associated with it. >>> >>> If you loaded that file, and tried: >>> >>> M-: ede-object RET >>> >>> does it say nil, while >>> >>> M-: ede-minor-mode RET >>> >>> is t? >> Actually no - both functions return nil for that file when the error >> occurs. I will email a complete stack dump if it helps. >> >> I initially thought this might be related to global-ede-mode although I >> have verified the problem with this both enabled and disabled. >> >> Do you have any other suggestions? Other than PEBKAC of course. > [ ... ] > > I had wrapped the specific pieces your last stack pointed at with a > (condition-case ...) If you are still getting an error from it, I would like > to see the stack, as presumably it will be different. > Already emailed, but just for posterity, here is a small test case: OK so here is a simplified case to try to reproduce this idle work error. Basically boost 1.34.1 is installed in d:/dev/include/boost. Other files are as listed below, and complete stack trace is at the bottom. Hopefully this is helpful? ### d:/tmp/dummy/CMakeLists.txt: (empty) ### d:/tmp/dummy/foo/bar.hpp: #ifndef FOO_BAR_HPP #define FOO_BAR_HPP #include <boost/variant.hpp> namespace Foo { namespace Bar { void BarFunc(); } } #endif // FOO_BAR_HPP ### d:/tmp/dummy/foo/bar.cpp: #include "globalPch.hpp" #include "foo/bar.hpp" namespace Foo { namespace Bar { void BarFunc(); } } ### .emacs project definition: (semantic-add-system-include "d:/dev/include/" 'c++-mode) (semantic-add-system-include "c:/Program Files/Microsoft Visual Studio 8/VC/include/" 'c++-mode) (ede-cpp-root-project "Dummy" :file "d:/tmp/dummy/CMakeLists.txt" :include-path '( "/" ) :spp-table '( ( "_MSC_VER" . "1400" ) ) ) ### stack trace: Debugger entered--Lisp error: (wrong-type-argument arrayp nil) eieiomt-next(nil) eieiomt-method-list(ede-project-root 0 nil) eieio-generic-call(ede-project-root (nil)) ede-project-root(nil) ede-toplevel() byte-code("..." " [tag ede-expand-filename ede-toplevel] 4) semantic-dependency-tag-file(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593])) semanticdb-find-table-for-include-default(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593]) [object semanticdb-table "bar.cpp" [object semanticdb-project-database-file "foo/" "d:/tmp/dummy/foo/" semanticdb-table nil ([object semanticdb-table "foo.cpp" #1 c++-mode ... [object semanticdb-find-search-index "#<semanticdb-table foo.cpp> index" #3 ... [object semanticdb-typecache "d:/tmp/dummy/foo/foo.cpp" nil nil nil ...]] ... "foo.cpp" nil nil 105 104 ... nil nil] #0 [object semanticdb-table "bar.hpp" #1 c++-mode ... unbound ... "bar.hpp" t ... 150 149 ... nil ...]) "c:/Documents and Settings/alastair.rankine/.emacs.d/semanticdb/!drive_d!tmp!dummy!foo!semantic.cache" "2.0pre5" "2.0pre5"] c++-mode (("globalPch.hpp" include nil ... #<overlay from 1 to 25 in bar.cpp>) ("foo/bar.hpp" include nil ... #<overlay from 27 to 49 in bar.cpp>) ("Foo" type ... ... #<overlay from 51 to 104 in bar.cpp>)) [object semanticdb-find-search-index "#<semanticdb-table bar.cpp> index" #0 nil [object semanticdb-typecache "d:/tmp/dummy/foo/bar.cpp" nil nil nil ...]] ([object semantic-scope-cache "Cache" #0 nil nil nil nil nil nil nil]) "bar.cpp" t nil 105 104 (18519 7196) nil nil]) semanticdb-find-table-for-include(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593]) [object semanticdb-table "bar.cpp" [object semanticdb-project-database-file "foo/" "d:/tmp/dummy/foo/" semanticdb-table nil ([object semanticdb-table "foo.cpp" #1 c++-mode ... [object semanticdb-find-search-index "#<semanticdb-table foo.cpp> index" #3 ... [object semanticdb-typecache "d:/tmp/dummy/foo/foo.cpp" nil nil nil ...]] ... "foo.cpp" nil nil 105 104 ... nil nil] #0 [object semanticdb-table "bar.hpp" #1 c++-mode ... unbound ... "bar.hpp" t ... 150 149 ... nil ...]) "c:/Documents and Settings/alastair.rankine/.emacs.d/semanticdb/!drive_d!tmp!dummy!foo!semantic.cache" "2.0pre5" "2.0pre5"] c++-mode (("globalPch.hpp" include nil ... #<overlay from 1 to 25 in bar.cpp>) ("foo/bar.hpp" include nil ... #<overlay from 27 to 49 in bar.cpp>) ("Foo" type ... ... #<overlay from 51 to 104 in bar.cpp>)) [object semanticdb-find-search-index "#<semanticdb-table bar.cpp> index" #0 nil [object semanticdb-typecache "d:/tmp/dummy/foo/bar.cpp" nil nil nil ...]] ([object semantic-scope-cache "Cache" #0 nil nil nil nil nil nil nil]) "bar.cpp" t nil 105 104 (18519 7196) nil nil]) semanticdb-find-translate-path-includes--internal(#<buffer bar.cpp>) semanticdb-find-translate-path-includes-default(#<buffer bar.cpp>) semanticdb-find-translate-path-default(#<buffer bar.cpp> nil) semanticdb-find-translate-path(#<buffer bar.cpp> nil) semantic-idle-work-for-one-buffer(#<buffer bar.cpp>) |
From: Alastair R. <ar...@in...> - 2008-06-24 02:17:46
|
Alastair Rankine wrote: > OK so here is a simplified case to try to reproduce this idle work error. > > Basically boost 1.34.1 is installed in d:/dev/include/boost. Other files > are as listed below, and complete stack trace is at the bottom. Eric, any thoughts on this? Alternatively, is there a workaround? |
From: Eric M. L. <er...@si...> - 2008-06-28 15:11:44
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Alastair Rankine wrote: >> OK so here is a simplified case to try to reproduce this idle work error. >> >> Basically boost 1.34.1 is installed in d:/dev/include/boost. Other files >> are as listed below, and complete stack trace is at the bottom. > >Eric, any thoughts on this? > >Alternatively, is there a workaround? [ ... ] Hi, I haven't had time to look into this in any detail recently, but upon short investigation today, I see that I can repro very easily by pulling in /usr/include/stdio.h, and then M-: (ede-toplevel). Assuming this is the same (based on your stack) as your issue, I checked in a fix to ede. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-07-02 06:45:44
|
Eric M. Ludlam wrote: > I haven't had time to look into this in any detail recently, but > upon short investigation today, I see that I can repro very easily by > pulling in /usr/include/stdio.h, and then M-: (ede-toplevel). > Assuming this is the same (based on your stack) as your issue, I > checked in a fix to ede. Thanks for the update but unfortunately it didn't seem to resolve the problem. The stack dump is slightly different though, see below. A couple of quick questions: 1. If I load boost/variant.hpp and then (ede-toplevel), it returns nil. This is as expected, right? 2. How do I write a file locate function for the ede-cpp-root-project? The docs specify that it should accept two arguments, NAME and DIR, but what are acceptable return values? Specifically: can it return nil to indicate using the default ede-expand-filename function? Also, if returning "/foo", is that relative to the project root (as per the include-path) or is it absolute (ie we need to prepend DIR)? (suspect the latter, just want to confirm) Thanks, Debugger entered--Lisp error: (wrong-type-argument arrayp nil) eieiomt-next(nil) eieiomt-method-list(ede-expand-filename 0 nil) eieio-generic-call(ede-expand-filename (nil "boost/variant/variant.hpp")) ede-expand-filename(nil "boost/variant/variant.hpp") byte-code("..." [tag ede-expand-filename ede-toplevel] 4) semantic-dependency-tag-file(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593])) semanticdb-find-table-for-include-default(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593]) [object semanticdb-table "bar.cpp" [object semanticdb-project-database-file "foo/" "d:/tmp/dummy/foo/" semanticdb-table nil (#0 [object semanticdb-table "bar.hpp" #1 c++-mode ... unbound nil "bar.hpp" nil nil 149 148 ... nil ...]) "c:/Documents and Settings/alastair.rankine/.emacs.d/semanticdb/!drive_d!tmp!dummy!foo!semantic.cache" "2.0pre5" "2.0pre5"] c++-mode (("globalPch.hpp" include nil ... #<overlay from 1 to 25 in bar.cpp>) ("foo/bar.hpp" include nil ... #<overlay from 27 to 49 in bar.cpp>) ("Foo" type ... ... #<overlay from 51 to 118 in bar.cpp>)) [object semanticdb-find-search-index "#<semanticdb-table bar.cpp> index" #0 (#0) [object semanticdb-typecache "d:/tmp/dummy/foo/bar.cpp" ... nil nil ...]] ([object semantic-scope-cache "Cache" #0 ... nil nil nil nil nil nil nil]) "bar.cpp" nil nil 119 118 (18539 8453) nil nil]) semanticdb-find-table-for-include(("boost/variant/variant.hpp" include nil (:filename "d:/dev/include/boost/variant.hpp") [557 593]) [object semanticdb-table "bar.cpp" [object semanticdb-project-database-file "foo/" "d:/tmp/dummy/foo/" semanticdb-table nil (#0 [object semanticdb-table "bar.hpp" #1 c++-mode ... unbound nil "bar.hpp" nil nil 149 148 ... nil ...]) "c:/Documents and Settings/alastair.rankine/.emacs.d/semanticdb/!drive_d!tmp!dummy!foo!semantic.cache" "2.0pre5" "2.0pre5"] c++-mode (("globalPch.hpp" include nil ... #<overlay from 1 to 25 in bar.cpp>) ("foo/bar.hpp" include nil ... #<overlay from 27 to 49 in bar.cpp>) ("Foo" type ... ... #<overlay from 51 to 118 in bar.cpp>)) [object semanticdb-find-search-index "#<semanticdb-table bar.cpp> index" #0 (#0) [object semanticdb-typecache "d:/tmp/dummy/foo/bar.cpp" ... nil nil ...]] ([object semantic-scope-cache "Cache" #0 ... nil nil nil nil nil nil nil]) "bar.cpp" nil nil 119 118 (18539 8453) nil nil]) semanticdb-find-translate-path-includes--internal(#<buffer bar.cpp>) semanticdb-find-translate-path-includes-default(#<buffer bar.cpp>) semanticdb-find-translate-path-default(#<buffer bar.cpp> nil) semanticdb-find-translate-path(#<buffer bar.cpp> nil) semantic-idle-work-for-one-buffer(#<buffer bar.cpp>) byte-code(...) semantic-idle-work-core-handler() semantic-debug-idle-work-function() call-interactively(semantic-debug-idle-work-function t nil) execute-extended-command(nil) call-interactively(execute-extended-command nil nil) |
From: Eric M. L. <er...@si...> - 2008-07-02 14:25:14
|
>>> Alastair Rankine <ar...@in...> seems to think that: >Eric M. Ludlam wrote: >> I haven't had time to look into this in any detail recently, but >> upon short investigation today, I see that I can repro very easily by >> pulling in /usr/include/stdio.h, and then M-: (ede-toplevel). >> Assuming this is the same (based on your stack) as your issue, I >> checked in a fix to ede. > >Thanks for the update but unfortunately it didn't seem to resolve the >problem. The stack dump is slightly different though, see below. I checked in a different change based on the stack. I can't seem to reproduce it here though. Perhaps it will work now. >A couple of quick questions: > >1. If I load boost/variant.hpp and then (ede-toplevel), it returns nil. >This is as expected, right? Yes. This indicates that there is no project there. >2. How do I write a file locate function for the ede-cpp-root-project? >The docs specify that it should accept two arguments, NAME and DIR, but >what are acceptable return values? Specifically: can it return nil to >indicate using the default ede-expand-filename function? Also, if >returning "/foo", is that relative to the project root (as per the >include-path) or is it absolute (ie we need to prepend DIR)? (suspect >the latter, just want to confirm) [ ... ] I updated the doc there. It should return the fully qualified file name passed in from NAME. If that file does not exist, it should return nil. Good Luck. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Alastair R. <ar...@in...> - 2008-07-03 04:10:39
|
Eric M. Ludlam wrote: >> Thanks for the update but unfortunately it didn't seem to resolve the >> problem. The stack dump is slightly different though, see below. > > I checked in a different change based on the stack. I can't seem to > reproduce it here though. Perhaps it will work now. Hooray, that fixed it. Semantic now parses perfectly, thanks so much. |