CEDET

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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()
...

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Eric M. Ludlam wrote:
>>>> Alastair Rankine <arsptr@...> 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.

>>> Alastair Rankine <arsptr@...> seems to think that:
>Eric M. Ludlam wrote:
>>>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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.

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Thanks Eric for the quick turnaround...

Eric M. Ludlam wrote:
>>>> Alastair Rankine <arsptr@...> 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.

>>> Alastair Rankine <arsptr@...> seems to think that:
>Thanks Eric for the quick turnaround...
>
>Eric M. Ludlam wrote:
>>>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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.

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Eric M. Ludlam wrote:
>>>> Alastair Rankine <arsptr@...> 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>)

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?

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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)

>>> Alastair Rankine <arsptr@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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.