CEDET

Yes.  I'd guess it is the namespace macros.  I don't know why it
throws a syntax table error though, as for me it just doesn't parse
correctly when I simulate it.

I have a solution for the glibc version, but I don't want to hard-code
every namespace macro out there into my lexer.  It will need a more
generic solution.

Eric

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>I tried having it lex qobjectdefs.h as well but that didn't fix it
>either. Interestingly, if I run gcc's preprocessor on qpushbutton.h
>(using the -E flag) and save the output to a file, code completion
>*works* within that file. Am I right in thinking this means the
>problem is definitely related to the preprocessor? I'll try looking up
>each of the headers for all of the macros used in qpushbutton.h
>tomorrow....
>
>On Wed, Mar 25, 2009 at 9:58 PM, Joseph Garvin
><joseph.h.garvin@...> wrote:
>> Are you referring to adding these lines?
>>
>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>> qt4-base-dir "/Qt/qconfig.h"))
>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>> qt4-base-dir "/Qt/qconfig-dist.h"))
>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>> qt4-base-dir "/Qt/qglobal.h"))
>>
>> Because they're already in my .emacs :/ Maybe that's not the problem then...
>>
>> On Wed, Mar 25, 2009 at 9:31 PM, Eric M. Ludlam <eric@...> wrote:
>>>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>>>--0016e642d386884f5f0465f9eee6
>>>>Content-Type: text/plain; charset=ISO-8859-1
>>>>Content-Transfer-Encoding: quoted-printable
>>>>
>>>>I still have GNU Global installed, so if semantic tries to
>>>>automatically detect and use it that could be a problem, but no it's
>>>>not enabled in my .emacs anywhere.
>>>>
>>>>I tried enabling semantic-decoration-mode by doing C-u M-x
>>>>semantic-decoration-mode and right clicking but it just deleted text,
>>>>maybe because I have most GUI elements disabled?
>>>>
>>>>I opened /usr/include/qt4/QtGui/QPushButton, and it's a one line filed
>>>>that #include's qpushbutton.h. So I tried opening qpushbutton.h, which
>>>>caused this error to appear in the minibuffer:
>>>>
>>>>Idle Parse Error: "#<buffer qpushbutton.h> - Args out of range: 71005, 7102=
>>>>5"
>>>>
>>>>I've attached the file by itself in case it will help. You can cause
>>>>the error by opening the file then moving the cursor over the
>>>>declaration of QPushButton. I tried toggle-debug-on-error but the
>>>>error still only appears in the minibuffer. After the error shows
>>>>semantic-analyze-debug-assist appears to do nothing as well.
>>>>
>>>>It looks like a lot of C macros are used, maybe that's confusing the parser=
>>>>?
>>>  [ ... ]
>>>
>>> If you are having problems with missing macro declarations, you can
>>> configure semantic-lex-c-preprocessor-symbol-file to be the single Qt
>>> header with all those macros in it.
>>>
>>> See Alex Ott's article here for more on that:
>>> http://xtalk.msk.su/~ott/en/writings/emacs-devenv/EmacsCedet.html
>>>
>>> Eric
>>>
>>> --
>>>          Eric Ludlam:                       eric@...
>>>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>>>
>>
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

(current-buffer) evals to #<buffer main.cpp>, which makes sense I
think, that's the buffer I have open. semantic-lex-syntax-table is
nil.

I just noticed an interesting behavior. If I load a fresh emacs and
then open qpushbutton.h *first*, then open main.cpp, when I try to
semantic-complete-analyze-inline I get the error from before about
args being out of range instead of the error about the syntax table.
Might that be a hint?

No problem on the debugging, if we get this figured out I get nice
code completion ;D

Joe

On Thu, Mar 26, 2009 at 1:23 PM, Eric M. Ludlam <eric@...> wrote:
> When this error happens as below, you can press "e" to get an "Eval:"
> prompt.  It it, what is the value of (current-buffer) ?  If the buffer
> makes sense as something worth parsing, then in the buffer, what is
> the value of semantic-lex-syntax-table?
>
> Semantic needs its special syntax table in order to run lex in the
> buffer.  If the buffer in question is normally parse-able, then the
> problem is how the buffer is loaded in when doing the analysis.
>
> Thanks for debugging through this.
>
> Eric
>
>
>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>Hey Eric, now that I'm getting the syntax-table-p error again I tried
>>debug assist but it just gives the same error, I guess semantic is
>>borked at that point. I toggled debug on to get a backtrace though:
>>
>>Debugger entered--Lisp error: (wrong-type-argument syntax-table-p nil)
>>  set-syntax-table(nil)
>>  semantic-analyze-current-context(199)
>>  semantic-complete-analyze-inline()
>>  call-interactively(semantic-complete-analyze-inline t nil)
>>  execute-extended-command(nil)
>>  call-interactively(execute-extended-command nil nil)
>>
>>Also, the QT_BEGIN_NAMESPACE is defined in qwebkitglobal.h, and having
>>semantic lex that doesn't seem to help. I'll keep looking....
>>
>>On Thu, Mar 26, 2009 at 7:31 AM, Eric M. Ludlam <eric@...> wrote:
>>> Yes.  I'd guess it is the namespace macros.  I don't know why it
>>> throws a syntax table error though, as for me it just doesn't parse
>>> correctly when I simulate it.
>>>
>>> I have a solution for the glibc version, but I don't want to hard-code
>>> every namespace macro out there into my lexer.  It will need a more
>>> generic solution.
>>>
>>> Eric
>>>
>>>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>>>I tried having it lex qobjectdefs.h as well but that didn't fix it
>>>>either. Interestingly, if I run gcc's preprocessor on qpushbutton.h
>>>>(using the -E flag) and save the output to a file, code completion
>>>>*works* within that file. Am I right in thinking this means the
>>>>problem is definitely related to the preprocessor? I'll try looking up
>>>>each of the headers for all of the macros used in qpushbutton.h
>>>>tomorrow....
>>>>
>>>>On Wed, Mar 25, 2009 at 9:58 PM, Joseph Garvin
>>>><joseph.h.garvin@...> wrote:
>>>>> Are you referring to adding these lines?
>>>>>
>>>>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>>>>> qt4-base-dir "/Qt/qconfig.h"))
>>>>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>>>>> qt4-base-dir "/Qt/qconfig-dist.h"))
>>>>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file (concat
>>>>> qt4-base-dir "/Qt/qglobal.h"))
>>>>>
>>>>> Because they're already in my .emacs :/ Maybe that's not the problem then...
>>>>>
>>>>> On Wed, Mar 25, 2009 at 9:31 PM, Eric M. Ludlam <eric@...> wrote:
>>>>>>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>>>>>>--0016e642d386884f5f0465f9eee6
>>>>>>>Content-Type: text/plain; charset=ISO-8859-1
>>>>>>>Content-Transfer-Encoding: quoted-printable
>>>>>>>
>>>>>>>I still have GNU Global installed, so if semantic tries to
>>>>>>>automatically detect and use it that could be a problem, but no it's
>>>>>>>not enabled in my .emacs anywhere.
>>>>>>>
>>>>>>>I tried enabling semantic-decoration-mode by doing C-u M-x
>>>>>>>semantic-decoration-mode and right clicking but it just deleted text,
>>>>>>>maybe because I have most GUI elements disabled?
>>>>>>>
>>>>>>>I opened /usr/include/qt4/QtGui/QPushButton, and it's a one line filed
>>>>>>>that #include's qpushbutton.h. So I tried opening qpushbutton.h, which
>>>>>>>caused this error to appear in the minibuffer:
>>>>>>>
>>>>>>>Idle Parse Error: "#<buffer qpushbutton.h> - Args out of range: 71005, 7102=
>>>>>>>5"
>>>>>>>
>>>>>>>I've attached the file by itself in case it will help. You can cause
>>>>>>>the error by opening the file then moving the cursor over the
>>>>>>>declaration of QPushButton. I tried toggle-debug-on-error but the
>>>>>>>error still only appears in the minibuffer. After the error shows
>>>>>>>semantic-analyze-debug-assist appears to do nothing as well.
>>>>>>>
>>>>>>>It looks like a lot of C macros are used, maybe that's confusing the parser=
>>>>>>>?
>>>>>>  [ ... ]
>>>>>>
>>>>>> If you are having problems with missing macro declarations, you can
>>>>>> configure semantic-lex-c-preprocessor-symbol-file to be the single Qt
>>>>>> header with all those macros in it.
>>>>>>
>>>>>> See Alex Ott's article here for more on that:
>>>>>> http://xtalk.msk.su/~ott/en/writings/emacs-devenv/EmacsCedet.html
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> --
>>>>>>          Eric Ludlam:                       eric@...
>>>>>>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>>          Eric Ludlam:                       eric@...
>>>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>
>

Hi,

  I'm not quite sure how to continue debugging.  I added an error
check into semantic-analyze-current-context, but I suspect it will
just throw that error instead of the buffer initialization function.

  I think I'd try the next steps.

First, update from CVS, and see if it just complains about the buffer
not being setup instead of the syntax table.

If it does, then there was some error captured during buffer setup.
See semantic-new-buffer-fcn.  Use edebug to step through and see what
is going on.  To do that, put the cursor in that function (in
semantic.el) and do

M-x edebug-defun RET

Then use C-x C-f and read in main.cpp.  It will stop in that fcn.
Press SPC to step.  If it unexpectedly leaps out to nowhere, make note
of what line it was.  That would be an important next clue.

If that runs fine, then we will need to analyze main.cpp more.   The
function semantic-c-describe-environment in main.cpp might help some,
though that is C specific.  The problem seems to be more generic.

If all that checks out, it might be that some function somewhere is
killing the Semantic setup.  You can restart Emacs and do:

M-x debug-on-entry RET kill-all-local-variables RET

and go through the repro steps. Each time it stops, check the stack to
be sure it makes sense.  For example, c++-mode should call it.  Also
check the current buffer to see if it is a logical buffer to have up.
If it is called from some odd place or stray minor mode, that is
probably the culprit.

If that doesn't reveal anything, I'm not quite sure what else to
suggest.

Eric

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>(current-buffer) evals to #<buffer main.cpp>, which makes sense I
>think, that's the buffer I have open. semantic-lex-syntax-table is
>nil.
>
>I just noticed an interesting behavior. If I load a fresh emacs and
>then open qpushbutton.h *first*, then open main.cpp, when I try to
>semantic-complete-analyze-inline I get the error from before about
>args being out of range instead of the error about the syntax table.
>Might that be a hint?
>
>No problem on the debugging, if we get this figured out I get nice
>code completion ;D
>
>Joe
>
>On Thu, Mar 26, 2009 at 1:23 PM, Eric M. Ludlam <eric@...> wrote:
>> When this error happens as below, you can press "e" to get an "Eval:"
>> prompt.  It it, what is the value of (current-buffer) ?  If the buffer
>> makes sense as something worth parsing, then in the buffer, what is
>> the value of semantic-lex-syntax-table?
>>
>> Semantic needs its special syntax table in order to run lex in the
>> buffer.  If the buffer in question is normally parse-able, then the
>> problem is how the buffer is loaded in when doing the analysis.
>>
>> Thanks for debugging through this.
>>
  [ ... ]

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Now the error I get is "Cannot analyze buffers not supported by
semantic" when I try semantic-complete-analyze-inline.

If I try stepping through semantic-new-buffer-fcn while loading
main.cpp, it completes without error. Also, for some reason the
function runs 5 or 6 times (maybe once for each header I've specified
to lex?). Interestingly, the second time the function runs, the
semantic--parse-table part seems to fail (the function exits right
away). My emacs debug-fu is weak, so I'm not sure how to inspect what
file it's trying to deal with there (the function doesn't take any
parameters so I'm not sure what variable to look at).

I tried running semantic-c-describe-environment and have attached the
output, as well as semantic-lex-spp-describe. I don't see any of the
QT macros in there.

I tried the debug-on-entry step idea, but it loads the buffer and lets
me try semantic-complete-analyze-inline without ever jumping into the
debugger.

Joe

On Thu, Mar 26, 2009 at 8:08 PM, Eric M. Ludlam <eric@...> wrote:
> Hi,
>
>  I'm not quite sure how to continue debugging.  I added an error
> check into semantic-analyze-current-context, but I suspect it will
> just throw that error instead of the buffer initialization function.
>
>  I think I'd try the next steps.
>
> First, update from CVS, and see if it just complains about the buffer
> not being setup instead of the syntax table.
>
> If it does, then there was some error captured during buffer setup.
> See semantic-new-buffer-fcn.  Use edebug to step through and see what
> is going on.  To do that, put the cursor in that function (in
> semantic.el) and do
>
> M-x edebug-defun RET
>
> Then use C-x C-f and read in main.cpp.  It will stop in that fcn.
> Press SPC to step.  If it unexpectedly leaps out to nowhere, make note
> of what line it was.  That would be an important next clue.
>
> If that runs fine, then we will need to analyze main.cpp more.   The
> function semantic-c-describe-environment in main.cpp might help some,
> though that is C specific.  The problem seems to be more generic.
>
> If all that checks out, it might be that some function somewhere is
> killing the Semantic setup.  You can restart Emacs and do:
>
> M-x debug-on-entry RET kill-all-local-variables RET
>
> and go through the repro steps. Each time it stops, check the stack to
> be sure it makes sense.  For example, c++-mode should call it.  Also
> check the current buffer to see if it is a logical buffer to have up.
> If it is called from some odd place or stray minor mode, that is
> probably the culprit.
>
> If that doesn't reveal anything, I'm not quite sure what else to
> suggest.
>
> Eric
>
>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>(current-buffer) evals to #<buffer main.cpp>, which makes sense I
>>think, that's the buffer I have open. semantic-lex-syntax-table is
>>nil.
>>
>>I just noticed an interesting behavior. If I load a fresh emacs and
>>then open qpushbutton.h *first*, then open main.cpp, when I try to
>>semantic-complete-analyze-inline I get the error from before about
>>args being out of range instead of the error about the syntax table.
>>Might that be a hint?
>>
>>No problem on the debugging, if we get this figured out I get nice
>>code completion ;D
>>
>>Joe
>>
>>On Thu, Mar 26, 2009 at 1:23 PM, Eric M. Ludlam <eric@...> wrote:
>>> When this error happens as below, you can press "e" to get an "Eval:"
>>> prompt.  It it, what is the value of (current-buffer) ?  If the buffer
>>> makes sense as something worth parsing, then in the buffer, what is
>>> the value of semantic-lex-syntax-table?
>>>
>>> Semantic needs its special syntax table in order to run lex in the
>>> buffer.  If the buffer in question is normally parse-able, then the
>>> problem is how the buffer is loaded in when doing the analysis.
>>>
>>> Thanks for debugging through this.
>>>
>  [ ... ]
>
> --
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
  [ ... ]
>Now the error I get is "Cannot analyze buffers not supported by
>semantic" when I try semantic-complete-analyze-inline.
>
>If I try stepping through semantic-new-buffer-fcn while loading
>main.cpp, it completes without error. Also, for some reason the
>function runs 5 or 6 times (maybe once for each header I've specified
>to lex?). Interestingly, the second time the function runs, the
>semantic--parse-table part seems to fail (the function exits right
>away). My emacs debug-fu is weak, so I'm not sure how to inspect what
>file it's trying to deal with there (the function doesn't take any
>parameters so I'm not sure what variable to look at).

This function should run once for each file you pull in for
preprocessor symbols.  It would then run again for main.cpp.

As you had this problem before setting up your macro files, it would
be good to disable all that, and trying this again.

When stopped in the debugger with edebug, press "d" to get a stack to
appear.  My stack looks like this:

  semantic-new-buffer-fcn()
  run-hooks(mode-local-init-hook)
  #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings run-hooks mode-local-init-hook] 2]()
  mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207" [activate-mode-local-bindings run-hooks mode-local-init-hook] 2] #[nil "	=?\207" [mode-local--init-mode major-mode] 2] (#<buffer foo.cpp>))
  mode-local-post-major-mode-change()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer foo.cpp> "/tmp/foo.cpp" nil nil "/tmp/foo.cpp" (200586 770))
  find-file-noselect("/tmp/foo.cpp" nil nil t)
  find-file("/tmp/foo.cpp" t)
  call-interactively(find-file nil nil)

Hopefully yours is similar.

If you get multiple calls in again, then that is the problem, and a
stack will help identify what is going on.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

So first I just tried commenting out all the lines telling semantic to
lex the various qt4 headers, and confirmed that the error still
happened.

On the first call the stack looks like this:

  semantic-new-buffer-fcn()
  run-hooks(mode-local-init-hook)
  #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings
run-hooks mode-local-init-hook] 2]()
  mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207"
[activate-mode-local-bindings run-hooks mode-local-init-hook] 2] #[nil
"	=?\207" [mode-local--init-mode major-mode] 2] (#<buffer
c++config.h> #<buffer main.cpp>))
  mode-local-post-major-mode-change()
  run-hooks(find-file-hook)
  after-find-file(nil nil)
  find-file-noselect-1(#<buffer c++config.h>
"/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h" t nil
"/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h" (601325
2051))
  find-file-noselect("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h"
t nil nil)
  semantic-find-file-noselect("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h"
t)
  semanticdb-create-table-for-file-not-in-buffer("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h")
  semanticdb-file-table-object("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h")
  semantic-c-reset-preprocessor-symbol-map()
  #[(sym value) "\302	\"\210\303\304\305\217\207" [sym value
set-default nil (semantic-c-reset-preprocessor-symbol-map) (...)]
3](semantic-lex-c-preprocessor-symbol-map (("__DBL_MIN_EXP__" .
"(-1021)") ("__FLT_MIN__" . "1.17549435e-38F") ("__DEC64_DEN__" .
"0.000000000000001E-383DD") ("__CHAR_BIT__" . "8") ("__WCHAR_MAX__" .
"2147483647") ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1" . "1")
("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2" . "1")
("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4" . "1") ("__DBL_DENORM_MIN__" .
"4.9406564584124654e-324") ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8" .
"1") ("__FLT_EVAL_METHOD__" . "0") ("__unix__" . "1") ("__x86_64" .
"1") ("__DBL_MIN_10_EXP__" . "(-307)") ("__FINITE_MATH_ONLY__" . "0")
("__LP64__" . "1") ("__GNUC_PATCHLEVEL__" . "2") ("__DEC64_MAX_EXP__"
. "384") ("__SHRT_MAX__" . "32767") ("__LDBL_MAX__" .
"1.18973149535723176502e+4932L") ("__linux" . "1")
("__DEC32_EPSILON__" . "1E-6DF") ("__unix" . "1") ("__LDBL_MAX_EXP__"
. "16384") ("__linux__" . "1") ("__SCHAR_MAX__" . "127")
("__DBL_DIG__" . "15") ("_FORTIFY_SOURCE" . "2") ("__SIZEOF_INT__" .
"4") ("__SIZEOF_POINTER__" . "8") ("__STDC_HOSTED__" . "1")
("__LDBL_HAS_INFINITY__" . "1") ("__FLT_EPSILON__" . "1.19209290e-7F")
("__GXX_WEAK__" . "1") ("__LDBL_MIN__" .
"3.36210314311209350626e-4932L") ("__DEC32_MAX__" . "9.999999E96DF")
("__SIZEOF_LONG__" . "8") ("__DECIMAL_DIG__" . "21") ("__gnu_linux__"
. "1") ("__LDBL_HAS_QUIET_NAN__" . "1") ("__GNUC__" . "4")
("__GXX_RTTI" . "1") ("__MMX__" . "1") ("__FLT_HAS_DENORM__" . "1")
("__SIZEOF_LONG_DOUBLE__" . "16") ("__DBL_MAX__" .
"1.7976931348623157e+308") ("__DBL_HAS_INFINITY__" . "1")
("__DEC32_MIN_EXP__" . "(-95)") ("__LDBL_HAS_DENORM__" . "1")
("__cplusplus" . "1") ...))
  custom-initialize-reset(semantic-lex-c-preprocessor-symbol-map nil)
  custom-declare-variable(semantic-lex-c-preprocessor-symbol-map nil
("/home/prophet/opt/cedet-cvs/semantic/bovine/semantic-c.elc" . 5073)
:group c :type (repeat (cons (string :tag "Keyword") (sexp :tag
"Replacement"))) :set #[(sym value) "\302	\"\210\303\304\305\217\207"
[sym value set-default nil (semantic-c-reset-preprocessor-symbol-map)
(...)] 3])
  semantic-default-c-setup()
  run-hooks(c-mode-common-hook c++-mode-hook)
  apply(run-hooks (c-mode-common-hook c++-mode-hook))
  run-mode-hooks(c-mode-common-hook c++-mode-hook)
  c++-mode()
  set-auto-mode-0(c++-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer main.cpp> "~/work/uber/main.cpp" nil
nil "~/work/uber/main.cpp" (1343954 2051))
  find-file-noselect("~/work/uber/main.cpp" nil nil t)
  find-file("~/work/uber/main.cpp" t)
  call-interactively(find-file nil nil)

The second time (it still runs twice with all the lex lines commented
out) it exits right away (the semantic--parse-table returns nil) and
the stack at the beginning looks like this:

  semantic-new-buffer-fcn()
  run-hooks(mode-local-init-hook)
  #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings
run-hooks mode-local-init-hook] 2]()
  mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207"
[activate-mode-local-bindings run-hooks mode-local-init-hook] 2] #[nil
"	=?\207" [mode-local--init-mode major-mode] 2] (#<buffer
c++config.h> #<buffer main.cpp>))
  mode-local-post-major-mode-change()
  run-hooks(find-file-hook)
  after-find-file(nil nil)
  find-file-noselect-1(#<buffer c++config.h>
"/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h" t nil
"/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h" (601325
2051))
  find-file-noselect("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h"
t nil nil)
  semantic-find-file-noselect("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h"
t)
  semanticdb-create-table-for-file-not-in-buffer("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h")
  semanticdb-file-table-object("/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h")
  semantic-c-reset-preprocessor-symbol-map()
  #[(sym value) "\302	\"\210\303\304\305\217\207" [sym value
set-default nil (semantic-c-reset-preprocessor-symbol-map) (...)]
3](semantic-lex-c-preprocessor-symbol-map (("__DBL_MIN_EXP__" .
"(-1021)") ("__FLT_MIN__" . "1.17549435e-38F") ("__DEC64_DEN__" .
"0.000000000000001E-383DD") ("__CHAR_BIT__" . "8") ("__WCHAR_MAX__" .
"2147483647") ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1" . "1")
("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2" . "1")
("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4" . "1") ("__DBL_DENORM_MIN__" .
"4.9406564584124654e-324") ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8" .
"1") ("__FLT_EVAL_METHOD__" . "0") ("__unix__" . "1") ("__x86_64" .
"1") ("__DBL_MIN_10_EXP__" . "(-307)") ("__FINITE_MATH_ONLY__" . "0")
("__LP64__" . "1") ("__GNUC_PATCHLEVEL__" . "2") ("__DEC64_MAX_EXP__"
. "384") ("__SHRT_MAX__" . "32767") ("__LDBL_MAX__" .
"1.18973149535723176502e+4932L") ("__linux" . "1")
("__DEC32_EPSILON__" . "1E-6DF") ("__unix" . "1") ("__LDBL_MAX_EXP__"
. "16384") ("__linux__" . "1") ("__SCHAR_MAX__" . "127")
("__DBL_DIG__" . "15") ("_FORTIFY_SOURCE" . "2") ("__SIZEOF_INT__" .
"4") ("__SIZEOF_POINTER__" . "8") ("__STDC_HOSTED__" . "1")
("__LDBL_HAS_INFINITY__" . "1") ("__FLT_EPSILON__" . "1.19209290e-7F")
("__GXX_WEAK__" . "1") ("__LDBL_MIN__" .
"3.36210314311209350626e-4932L") ("__DEC32_MAX__" . "9.999999E96DF")
("__SIZEOF_LONG__" . "8") ("__DECIMAL_DIG__" . "21") ("__gnu_linux__"
. "1") ("__LDBL_HAS_QUIET_NAN__" . "1") ("__GNUC__" . "4")
("__GXX_RTTI" . "1") ("__MMX__" . "1") ("__FLT_HAS_DENORM__" . "1")
("__SIZEOF_LONG_DOUBLE__" . "16") ("__DBL_MAX__" .
"1.7976931348623157e+308") ("__DBL_HAS_INFINITY__" . "1")
("__DEC32_MIN_EXP__" . "(-95)") ("__LDBL_HAS_DENORM__" . "1")
("__cplusplus" . "1") ...))
  custom-initialize-reset(semantic-lex-c-preprocessor-symbol-map nil)
  custom-declare-variable(semantic-lex-c-preprocessor-symbol-map nil
("/home/prophet/opt/cedet-cvs/semantic/bovine/semantic-c.elc" . 5073)
:group c :type (repeat (cons (string :tag "Keyword") (sexp :tag
"Replacement"))) :set #[(sym value) "\302	\"\210\303\304\305\217\207"
[sym value set-default nil (semantic-c-reset-preprocessor-symbol-map)
(...)] 3])
  semantic-default-c-setup()
  run-hooks(c-mode-common-hook c++-mode-hook)
  apply(run-hooks (c-mode-common-hook c++-mode-hook))
  run-mode-hooks(c-mode-common-hook c++-mode-hook)
  c++-mode()
  set-auto-mode-0(c++-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer main.cpp> "~/work/uber/main.cpp" nil
nil "~/work/uber/main.cpp" (1343954 2051))
  find-file-noselect("~/work/uber/main.cpp" nil nil t)
  find-file("~/work/uber/main.cpp" t)
  call-interactively(find-file nil nil)

I just ran diff on these and it looks like the stack is identical in
both cases, so I'm assuming the state of a global somewhere is
changing.


On Thu, Mar 26, 2009 at 11:35 PM, Eric M. Ludlam <eric@...> wrote:
>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>  [ ... ]
>>Now the error I get is "Cannot analyze buffers not supported by
>>semantic" when I try semantic-complete-analyze-inline.
>>
>>If I try stepping through semantic-new-buffer-fcn while loading
>>main.cpp, it completes without error. Also, for some reason the
>>function runs 5 or 6 times (maybe once for each header I've specified
>>to lex?). Interestingly, the second time the function runs, the
>>semantic--parse-table part seems to fail (the function exits right
>>away). My emacs debug-fu is weak, so I'm not sure how to inspect what
>>file it's trying to deal with there (the function doesn't take any
>>parameters so I'm not sure what variable to look at).
>
> This function should run once for each file you pull in for
> preprocessor symbols.  It would then run again for main.cpp.
>
> As you had this problem before setting up your macro files, it would
> be good to disable all that, and trying this again.
>
> When stopped in the debugger with edebug, press "d" to get a stack to
> appear.  My stack looks like this:
>
>  semantic-new-buffer-fcn()
>  run-hooks(mode-local-init-hook)
>  #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings run-hooks mode-local-init-hook] 2]()
>  mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207" [activate-mode-local-bindings run-hooks mode-local-init-hook] 2] #[nil "   =?\207" [mode-local--init-mode major-mode] 2] (#<buffer foo.cpp>))
>  mode-local-post-major-mode-change()
>  run-hooks(find-file-hook)
>  after-find-file(nil t)
>  find-file-noselect-1(#<buffer foo.cpp> "/tmp/foo.cpp" nil nil "/tmp/foo.cpp" (200586 770))
>  find-file-noselect("/tmp/foo.cpp" nil nil t)
>  find-file("/tmp/foo.cpp" t)
>  call-interactively(find-file nil nil)
>
> Hopefully yours is similar.
>
> If you get multiple calls in again, then that is the problem, and a
> stack will help identify what is going on.
>
> Eric
>
> --
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>So first I just tried commenting out all the lines telling semantic to
>lex the various qt4 headers, and confirmed that the error still
>happened.
  [ ... ]

This is the same problem I seem to remember from before on this
mailing list, but now there are a few more details.

The quick fix is to just go and edit the file:

/usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h

and force it to reparse and save the data base.  When you restart
Emacs, things should be ok.  It will take me a while to unravel from
your stack traces what is going on, as this doesn't happen to everyone
who bootstraps in a new CEDET.  I may need to call on you again to try
out some stuff even if you get it work with this quick fix.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

err, I realized my last e-mail was unclear. The cannot find types
error didn't occur I think until after I tried
semantic-complete-analyze-inline.

On Fri, Mar 27, 2009 at 5:11 PM, Joseph Garvin
<joseph.h.garvin@...> wrote:
> I edited the file in emacs, saved it, undid the changes, saved it,
> said yes to creating .semanticdb, and exited. Then I loaded emacs up
> again and opened main.cpp and lo and behold it started parsing a ton
> of headers! After that though, it came up with the old can't find
> types for QPushButton hello () error. Then I tried editing my .emacs
> to uncomment the lex lines relating to QT's headers, restarted emacs,
> and tried again, but this time got the "Cannot analyze buffers not
> supported by semantic" error again.
>
> I've attached that header in case it's the one that's problematic.
> Given the path, is it possible that the people like myself having this
> problem are all on 64-bit? I'm running 64-bit ubuntu intrepid.
>
> On Fri, Mar 27, 2009 at 4:51 PM, Eric M. Ludlam <eric@...> wrote:
>>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>>So first I just tried commenting out all the lines telling semantic to
>>>lex the various qt4 headers, and confirmed that the error still
>>>happened.
>>  [ ... ]
>>
>> This is the same problem I seem to remember from before on this
>> mailing list, but now there are a few more details.
>>
>> The quick fix is to just go and edit the file:
>>
>> /usr/include/c++/4.3/x86_64-linux-gnu/bits/c++config.h
>>
>> and force it to reparse and save the data base.  When you restart
>> Emacs, things should be ok.  It will take me a while to unravel from
>> your stack traces what is going on, as this doesn't happen to everyone
>> who bootstraps in a new CEDET.  I may need to call on you again to try
>> out some stuff even if you get it work with this quick fix.
>>
>> Eric
>>
>> --
>>          Eric Ludlam:                       eric@...
>>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>
>

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>--001636426a09a940240466202e72
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>I edited the file in emacs, saved it, undid the changes, saved it,
>said yes to creating .semanticdb, and exited. Then I loaded emacs up
>again and opened main.cpp and lo and behold it started parsing a ton
>of headers! After that though, it came up with the old can't find
>types for QPushButton hello () error. Then I tried editing my .emacs
>to uncomment the lex lines relating to QT's headers, restarted emacs,
>and tried again, but this time got the "Cannot analyze buffers not
>supported by semantic" error again.
>
>I've attached that header in case it's the one that's problematic.
>Given the path, is it possible that the people like myself having this
>problem are all on 64-bit? I'm running 64-bit ubuntu intrepid.
>
  [ ... ]

Thanks for the header.  It parsed fine on my machine and caused no
errors so it didn't help.

I moved some stuff around in semantic-c to try and prevent the stacks
you had provided.  Could you try it?

I have a 64 debian at work, and CEDET works fine for me there too.

I suppose another option is that you have some mysterious extra
package installed that is somehow interfering.  For a different
reason, I checked in a change to try and detect a pre-installed CEDET
today.  Perhaps that will turn something up.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

First I tried completion in main.cpp without deleting .semanticdb, and
I still got the couldn't find types error. Then I closed emacs,
deleted .semanticdb, then loaded main.cpp, and tried completion, and
got the buffers not supported error again. Also it didn't try to parse
a ton of headers like it did after the time editing c++config.h.

In case it's something specific about my configuration, I've attached
my .emacs. It's not too long, maybe you could see if I'm doing
something crazy?

On Fri, Mar 27, 2009 at 7:33 PM, Eric M. Ludlam <eric@...> wrote:
>>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>>--001636426a09a940240466202e72
>>Content-Type: text/plain; charset=ISO-8859-1
>>Content-Transfer-Encoding: quoted-printable
>>
>>I edited the file in emacs, saved it, undid the changes, saved it,
>>said yes to creating .semanticdb, and exited. Then I loaded emacs up
>>again and opened main.cpp and lo and behold it started parsing a ton
>>of headers! After that though, it came up with the old can't find
>>types for QPushButton hello () error. Then I tried editing my .emacs
>>to uncomment the lex lines relating to QT's headers, restarted emacs,
>>and tried again, but this time got the "Cannot analyze buffers not
>>supported by semantic" error again.
>>
>>I've attached that header in case it's the one that's problematic.
>>Given the path, is it possible that the people like myself having this
>>problem are all on 64-bit? I'm running 64-bit ubuntu intrepid.
>>
>  [ ... ]
>
> Thanks for the header.  It parsed fine on my machine and caused no
> errors so it didn't help.
>
> I moved some stuff around in semantic-c to try and prevent the stacks
> you had provided.  Could you try it?
>
> I have a 64 debian at work, and CEDET works fine for me there too.
>
> I suppose another option is that you have some mysterious extra
> package installed that is somehow interfering.  For a different
> reason, I checked in a change to try and detect a pre-installed CEDET
> today.  Perhaps that will turn something up.
>
> Eric
>
> --
>          Eric Ludlam:                       eric@...
>   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

>>> Joseph Garvin <joseph.h.garvin@...> seems to think that:
>First I tried completion in main.cpp without deleting .semanticdb, and
>I still got the couldn't find types error. Then I closed emacs,
>deleted .semanticdb, then loaded main.cpp, and tried completion, and
>got the buffers not supported error again. Also it didn't try to parse
>a ton of headers like it did after the time editing c++config.h.

Hi,

  I updated a few more things in semantic-c to try and capture
potential errors when generating the lexical table from the file list.
I checked that into CVS.  Your stacks from before indicate is it
loading in semantic-c, and while doing so is initializing these
buffers.  Hopefully the re-arranging I did will allow things to
initialize properly for you.

>In case it's something specific about my configuration, I've attached
>my .emacs. It's not too long, maybe you could see if I'm doing
>something crazy?
  [ ... ]

Nothing looked odd to me.

If you can try the latest version from CVS, let me know how it goes.

Thanks
Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

>>> Nathan Huesken <cedet@...> seems to think that:
>Hi,
>
>I have trouble with ca2+ and semantic. I am not sure what the problem
>is, so I am writing to this list.
>My setup works perfectly on another computer. But now I am on this one,
>got the newest ca2+ and cedet version and having emacs-snapshot
>(ubuntu), which is 23.0.60.1, installed.
>
>Now, when I try to start emacs I get the error I appended.
>
>Anyone knows what the error could be?
>
>Thanks!
>Nathan
  [ ... ]

I would guess that you need to do the CEDET init before calling the
ca2+ init.  That way the autoloads that have
define-overloadable-function would be available for solving the
problem.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi,

Thanks for your reply.
I exchanged the loading of ca2+ and semantic, and now I have a different
problem.
cedet loading fails because of inversion-require-emacs.
I find this strange, but just do not know enough about emacs.
I appended the error output.
What could it be?

Thanks!
Nathan

On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
> >>> Nathan Huesken <cedet@...> seems to think that:
> >Hi,
> >
> >I have trouble with ca2+ and semantic. I am not sure what the problem
> >is, so I am writing to this list.
> >My setup works perfectly on another computer. But now I am on this one,
> >got the newest ca2+ and cedet version and having emacs-snapshot
> >(ubuntu), which is 23.0.60.1, installed.
> >
> >Now, when I try to start emacs I get the error I appended.
> >
> >Anyone knows what the error could be?
> >
> >Thanks!
> >Nathan
>   [ ... ]
> 
> I would guess that you need to do the CEDET init before calling the
> ca2+ init.  That way the autoloads that have
> define-overloadable-function would be available for solving the
> problem.
> 
> Eric
> 
> -- 
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> 

--

Hi,

  Did you compile CEDET?  If you use CVS, you need to compile CEDET
for both performance reasons, and to build the autoload files.  The
autoload files is what will make these symbols available.

  Compilation should be done with the Makefile, or with the all-emacs
build.  The INSTALL file explains how.

Eric


>>> Nathan Huesken <cedet@...> seems to think that:
>Hi,
>
>Thanks for your reply.
>I exchanged the loading of ca2+ and semantic, and now I have a different
>problem.
>cedet loading fails because of inversion-require-emacs.
>I find this strange, but just do not know enough about emacs.
>I appended the error output.
>What could it be?
>
>Thanks!
>Nathan
>
>On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
>> >>> Nathan Huesken <cedet@...> seems to think that:
>> >Hi,
>> >
>> >I have trouble with ca2+ and semantic. I am not sure what the problem
>> >is, so I am writing to this list.
>> >My setup works perfectly on another computer. But now I am on this one,
>> >got the newest ca2+ and cedet version and having emacs-snapshot
>> >(ubuntu), which is 23.0.60.1, installed.
>> >
>> >Now, when I try to start emacs I get the error I appended.
>> >
>> >Anyone knows what the error could be?
>> >
>> >Thanks!
>> >Nathan
>>   [ ... ]
>> 
>> I would guess that you need to do the CEDET init before calling the
>> ca2+ init.  That way the autoloads that have
>> define-overloadable-function would be available for solving the
>> problem.
>> 
>> Eric
>> 
>> -- 
>>           Eric Ludlam:                       eric@...
>>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>> 
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi,

yes, I compiled cedet. I am under ubuntu and therefore compiled it with
make EMACS=emacs-snapshot

I also got lines, like
Generating autoloads for cedet-contrib.el...
Generating autoloads for cedet-contrib.el...done

Maybe cedet can not find the autoloads or something?
I load cedet with
(load-file "~/cedet/common/cedet.el")

Can I find out if something goes wrong with the autoloads?

Thanks!
Nathan


On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
> Hi,
> 
>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
> for both performance reasons, and to build the autoload files.  The
> autoload files is what will make these symbols available.
> 
>   Compilation should be done with the Makefile, or with the all-emacs
> build.  The INSTALL file explains how.
> 
> Eric
> 
> 
> >>> Nathan Huesken <cedet@...> seems to think that:
> >Hi,
> >
> >Thanks for your reply.
> >I exchanged the loading of ca2+ and semantic, and now I have a different
> >problem.
> >cedet loading fails because of inversion-require-emacs.
> >I find this strange, but just do not know enough about emacs.
> >I appended the error output.
> >What could it be?
> >
> >Thanks!
> >Nathan
> >
> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >Hi,
> >> >
> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
> >> >is, so I am writing to this list.
> >> >My setup works perfectly on another computer. But now I am on this one,
> >> >got the newest ca2+ and cedet version and having emacs-snapshot
> >> >(ubuntu), which is 23.0.60.1, installed.
> >> >
> >> >Now, when I try to start emacs I get the error I appended.
> >> >
> >> >Anyone knows what the error could be?
> >> >
> >> >Thanks!
> >> >Nathan
> >>   [ ... ]
> >> 
> >> I would guess that you need to do the CEDET init before calling the
> >> ca2+ init.  That way the autoloads that have
> >> define-overloadable-function would be available for solving the
> >> problem.
> >> 
> >> Eric
> >> 
> >> -- 
> >>           Eric Ludlam:                       eric@...
> >>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> >> 
> >
> 
> -- 
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> 

--

Sorry for my last double-posting/confusing-posting.

I checked common/cedet-loaddefs.el and found
(autoload 'inversion-require-emacs "inversion" "\
Declare that you need either EMACS-VER, or XEMACS-VER.
Only checks one based on which kind of Emacs is being run.

\(fn EMACS-VER XEMACS-VER)" nil nil)

I do not know if it is correct, but it is there.

When I start emacs, do M-x describe-function, I can not find
inversion-require-emacs

But after I did a C-x C-e on the lines above, I can find it!
So maybe cedet-loaddefs.el is not executed for some reseons?

Now I find this line:
(load "cedet-loaddefs" nil t)

Doing C-x C-e does not give me inversion-require-emacs in
M-x describe-function (as I would have expected).

Regards,
Nathan

On Fri, Mar 27, 2009 at 12:38:07PM -0400, Eric M. Ludlam wrote:
> It would be good to check in the common//cedet-loaddefs.el file to make sure things
> like the missing inversion function is there.  Then we'd need to
> figure out why it didn't add it.
> 
> The autoloads generator has always been a bit persnickity when the
> Emacs developers change things.  Perhaps I need to update my Emacs
> from CVS.  I'd been delaying due to the RMAIL changes.
> 
> Eric
> 
> >>> Nathan Huesken <ls@...> seems to think that:
> >Hi,
> >
> >yes, I compiled cedet. I am under ubuntu and therefore compiled it with
> >make EMACS=emacs-snapshot
> >
> >I also got lines, like
> >Generating autoloads for cedet-contrib.el...
> >Generating autoloads for cedet-contrib.el...done
> >
> >Maybe cedet can not find the autoloads or something?
> >I load cedet with
> >(load-file "~/cedet/common/cedet.el")
> >
> >Can I find out if something goes wrong with the autoloads?
> >
> >Thanks!
> >Nathan
> >
> >On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
> >> Hi,
> >> 
> >>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
> >> for both performance reasons, and to build the autoload files.  The
> >> autoload files is what will make these symbols available.
> >> 
> >>   Compilation should be done with the Makefile, or with the all-emacs
> >> build.  The INSTALL file explains how.
> >> 
> >> Eric
> >> 
> >> 
> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >Hi,
> >> >
> >> >Thanks for your reply.
> >> >I exchanged the loading of ca2+ and semantic, and now I have a different
> >> >problem.
> >> >cedet loading fails because of inversion-require-emacs.
> >> >I find this strange, but just do not know enough about emacs.
> >> >I appended the error output.
> >> >What could it be?
> >> >
> >> >Thanks!
> >> >Nathan
> >> >
> >> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >> >Hi,
> >> >> >
> >> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
> >> >> >is, so I am writing to this list.
> >> >> >My setup works perfectly on another computer. But now I am on this one,
> >> >> >got the newest ca2+ and cedet version and having emacs-snapshot
> >> >> >(ubuntu), which is 23.0.60.1, installed.
> >> >> >
> >> >> >Now, when I try to start emacs I get the error I appended.
> >> >> >
>   [ ... ]
> 
> -- 
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> 

--

You might have some other version of CEDET installed, though I would
guess it would be recent enough to have the inversion-require-emacs
line.

You can find out by starting emacs with -q, then using M-x
locate-library on things like cedet-loaddefs, or inversion.

If this is the case, let me know.  I may be able to update cedet.el to
detect and warn about this sort of thing.

Eric

>>> Nathan Huesken <cedet@...> seems to think that:
>Sorry for my last double-posting/confusing-posting.
>
>I checked common/cedet-loaddefs.el and found
>(autoload 'inversion-require-emacs "inversion" "\
>Declare that you need either EMACS-VER, or XEMACS-VER.
>Only checks one based on which kind of Emacs is being run.
>
>\(fn EMACS-VER XEMACS-VER)" nil nil)
>
>I do not know if it is correct, but it is there.
>
>When I start emacs, do M-x describe-function, I can not find
>inversion-require-emacs
>
>But after I did a C-x C-e on the lines above, I can find it!
>So maybe cedet-loaddefs.el is not executed for some reseons?
>
>Now I find this line:
>(load "cedet-loaddefs" nil t)
>
>Doing C-x C-e does not give me inversion-require-emacs in
>M-x describe-function (as I would have expected).
>
>Regards,
>Nathan
>
>On Fri, Mar 27, 2009 at 12:38:07PM -0400, Eric M. Ludlam wrote:
>> It would be good to check in the common//cedet-loaddefs.el file to make sure things
>> like the missing inversion function is there.  Then we'd need to
>> figure out why it didn't add it.
>> 
>> The autoloads generator has always been a bit persnickity when the
>> Emacs developers change things.  Perhaps I need to update my Emacs
>> from CVS.  I'd been delaying due to the RMAIL changes.
>> 
>> Eric
>> 
>> >>> Nathan Huesken <ls@...> seems to think that:
>> >Hi,
>> >
>> >yes, I compiled cedet. I am under ubuntu and therefore compiled it with
>> >make EMACS=emacs-snapshot
>> >
>> >I also got lines, like
>> >Generating autoloads for cedet-contrib.el...
>> >Generating autoloads for cedet-contrib.el...done
>> >
>> >Maybe cedet can not find the autoloads or something?
>> >I load cedet with
>> >(load-file "~/cedet/common/cedet.el")
>> >
>> >Can I find out if something goes wrong with the autoloads?
>> >
>> >Thanks!
>> >Nathan
>> >
>> >On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
>> >> Hi,
>> >> 
>> >>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
>> >> for both performance reasons, and to build the autoload files.  The
>> >> autoload files is what will make these symbols available.
>> >> 
>> >>   Compilation should be done with the Makefile, or with the all-emacs
>> >> build.  The INSTALL file explains how.
>> >> 
>> >> Eric
>> >> 
>> >> 
>> >> >>> Nathan Huesken <cedet@...> seems to think that:
>> >> >Hi,
>> >> >
>> >> >Thanks for your reply.
>> >> >I exchanged the loading of ca2+ and semantic, and now I have a different
>> >> >problem.
>> >> >cedet loading fails because of inversion-require-emacs.
>> >> >I find this strange, but just do not know enough about emacs.
>> >> >I appended the error output.
>> >> >What could it be?
>> >> >
>> >> >Thanks!
>> >> >Nathan
>> >> >
>> >> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
>> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
>> >> >> >Hi,
>> >> >> >
>> >> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
>> >> >> >is, so I am writing to this list.
>> >> >> >My setup works perfectly on another computer. But now I am on this one,
>> >> >> >got the newest ca2+ and cedet version and having emacs-snapshot
>> >> >> >(ubuntu), which is 23.0.60.1, installed.
>> >> >> >
>> >> >> >Now, when I try to start emacs I get the error I appended.
>> >> >> >
>>   [ ... ]
>> 
>> -- 
>>           Eric Ludlam:                       eric@...
>>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>> 
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

It is the case!
I think:
Library is file /usr/share/emacs21/site-lisp/cedet-common/cedet-loaddefs.elc
says everything.

Unfortantly I have no root access to the computer. Is there something I
can about it without removing the old cedet?

Thanks!
Nathan

On Fri, Mar 27, 2009 at 02:21:42PM -0400, Eric M. Ludlam wrote:
> You might have some other version of CEDET installed, though I would
> guess it would be recent enough to have the inversion-require-emacs
> line.
> 
> You can find out by starting emacs with -q, then using M-x
> locate-library on things like cedet-loaddefs, or inversion.
> 
> If this is the case, let me know.  I may be able to update cedet.el to
> detect and warn about this sort of thing.
> 
> Eric
> 
> >>> Nathan Huesken <cedet@...> seems to think that:
> >Sorry for my last double-posting/confusing-posting.
> >
> >I checked common/cedet-loaddefs.el and found
> >(autoload 'inversion-require-emacs "inversion" "\
> >Declare that you need either EMACS-VER, or XEMACS-VER.
> >Only checks one based on which kind of Emacs is being run.
> >
> >\(fn EMACS-VER XEMACS-VER)" nil nil)
> >
> >I do not know if it is correct, but it is there.
> >
> >When I start emacs, do M-x describe-function, I can not find
> >inversion-require-emacs
> >
> >But after I did a C-x C-e on the lines above, I can find it!
> >So maybe cedet-loaddefs.el is not executed for some reseons?
> >
> >Now I find this line:
> >(load "cedet-loaddefs" nil t)
> >
> >Doing C-x C-e does not give me inversion-require-emacs in
> >M-x describe-function (as I would have expected).
> >
> >Regards,
> >Nathan
> >
> >On Fri, Mar 27, 2009 at 12:38:07PM -0400, Eric M. Ludlam wrote:
> >> It would be good to check in the common//cedet-loaddefs.el file to make sure things
> >> like the missing inversion function is there.  Then we'd need to
> >> figure out why it didn't add it.
> >> 
> >> The autoloads generator has always been a bit persnickity when the
> >> Emacs developers change things.  Perhaps I need to update my Emacs
> >> from CVS.  I'd been delaying due to the RMAIL changes.
> >> 
> >> Eric
> >> 
> >> >>> Nathan Huesken <ls@...> seems to think that:
> >> >Hi,
> >> >
> >> >yes, I compiled cedet. I am under ubuntu and therefore compiled it with
> >> >make EMACS=emacs-snapshot
> >> >
> >> >I also got lines, like
> >> >Generating autoloads for cedet-contrib.el...
> >> >Generating autoloads for cedet-contrib.el...done
> >> >
> >> >Maybe cedet can not find the autoloads or something?
> >> >I load cedet with
> >> >(load-file "~/cedet/common/cedet.el")
> >> >
> >> >Can I find out if something goes wrong with the autoloads?
> >> >
> >> >Thanks!
> >> >Nathan
> >> >
> >> >On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
> >> >> Hi,
> >> >> 
> >> >>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
> >> >> for both performance reasons, and to build the autoload files.  The
> >> >> autoload files is what will make these symbols available.
> >> >> 
> >> >>   Compilation should be done with the Makefile, or with the all-emacs
> >> >> build.  The INSTALL file explains how.
> >> >> 
> >> >> Eric
> >> >> 
> >> >> 
> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >> >Hi,
> >> >> >
> >> >> >Thanks for your reply.
> >> >> >I exchanged the loading of ca2+ and semantic, and now I have a different
> >> >> >problem.
> >> >> >cedet loading fails because of inversion-require-emacs.
> >> >> >I find this strange, but just do not know enough about emacs.
> >> >> >I appended the error output.
> >> >> >What could it be?
> >> >> >
> >> >> >Thanks!
> >> >> >Nathan
> >> >> >
> >> >> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
> >> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >> >> >Hi,
> >> >> >> >
> >> >> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
> >> >> >> >is, so I am writing to this list.
> >> >> >> >My setup works perfectly on another computer. But now I am on this one,
> >> >> >> >got the newest ca2+ and cedet version and having emacs-snapshot
> >> >> >> >(ubuntu), which is 23.0.60.1, installed.
> >> >> >> >
> >> >> >> >Now, when I try to start emacs I get the error I appended.
> >> >> >> >
> >>   [ ... ]
> >> 
> >> -- 
> >>           Eric Ludlam:                       eric@...
> >>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> >> 
> >
> 
> -- 
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> 

--

This implies that the cedet load is being done by one of Emacs's
startup scripts.  In the Emacs manual, there is a section on start up,
and how to control what gets run when.  You would need to figure out
which step loads that file, and disable it, likely via a command line
switch.

Good Luck
Eric

>>> Nathan Huesken <cedet@...> seems to think that:
>It is the case!
>I think:
>Library is file /usr/share/emacs21/site-lisp/cedet-common/cedet-loaddefs.elc
>says everything.
>
>Unfortantly I have no root access to the computer. Is there something I
>can about it without removing the old cedet?
>
>Thanks!
>Nathan
>
>On Fri, Mar 27, 2009 at 02:21:42PM -0400, Eric M. Ludlam wrote:
>> You might have some other version of CEDET installed, though I would
>> guess it would be recent enough to have the inversion-require-emacs
>> line.
>> 
>> You can find out by starting emacs with -q, then using M-x
>> locate-library on things like cedet-loaddefs, or inversion.
>> 
>> If this is the case, let me know.  I may be able to update cedet.el to
>> detect and warn about this sort of thing.
>> 
>> Eric
>> 
>> >>> Nathan Huesken <cedet@...> seems to think that:
>> >Sorry for my last double-posting/confusing-posting.
>> >
>> >I checked common/cedet-loaddefs.el and found
>> >(autoload 'inversion-require-emacs "inversion" "\
>> >Declare that you need either EMACS-VER, or XEMACS-VER.
>> >Only checks one based on which kind of Emacs is being run.
>> >
>> >\(fn EMACS-VER XEMACS-VER)" nil nil)
>> >
>> >I do not know if it is correct, but it is there.
>> >
>> >When I start emacs, do M-x describe-function, I can not find
>> >inversion-require-emacs
>> >
>> >But after I did a C-x C-e on the lines above, I can find it!
>> >So maybe cedet-loaddefs.el is not executed for some reseons?
>> >
>> >Now I find this line:
>> >(load "cedet-loaddefs" nil t)
>> >
>> >Doing C-x C-e does not give me inversion-require-emacs in
>> >M-x describe-function (as I would have expected).
>> >
>> >Regards,
>> >Nathan
>> >
>> >On Fri, Mar 27, 2009 at 12:38:07PM -0400, Eric M. Ludlam wrote:
>> >> It would be good to check in the common//cedet-loaddefs.el file to make sure things
>> >> like the missing inversion function is there.  Then we'd need to
>> >> figure out why it didn't add it.
>> >> 
>> >> The autoloads generator has always been a bit persnickity when the
>> >> Emacs developers change things.  Perhaps I need to update my Emacs
>> >> from CVS.  I'd been delaying due to the RMAIL changes.
>> >> 
>> >> Eric
>> >> 
>> >> >>> Nathan Huesken <ls@...> seems to think that:
>> >> >Hi,
>> >> >
>> >> >yes, I compiled cedet. I am under ubuntu and therefore compiled it with
>> >> >make EMACS=emacs-snapshot
>> >> >
>> >> >I also got lines, like
>> >> >Generating autoloads for cedet-contrib.el...
>> >> >Generating autoloads for cedet-contrib.el...done
>> >> >
>> >> >Maybe cedet can not find the autoloads or something?
>> >> >I load cedet with
>> >> >(load-file "~/cedet/common/cedet.el")
>> >> >
>> >> >Can I find out if something goes wrong with the autoloads?
>> >> >
>> >> >Thanks!
>> >> >Nathan
>> >> >
>> >> >On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
>> >> >> Hi,
>> >> >> 
>> >> >>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
>> >> >> for both performance reasons, and to build the autoload files.  The
>> >> >> autoload files is what will make these symbols available.
>> >> >> 
>> >> >>   Compilation should be done with the Makefile, or with the all-emacs
>> >> >> build.  The INSTALL file explains how.
>> >> >> 
>> >> >> Eric
>> >> >> 
>> >> >> 
>> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
>> >> >> >Hi,
>> >> >> >
>> >> >> >Thanks for your reply.
>> >> >> >I exchanged the loading of ca2+ and semantic, and now I have a different
>> >> >> >problem.
>> >> >> >cedet loading fails because of inversion-require-emacs.
>> >> >> >I find this strange, but just do not know enough about emacs.
>> >> >> >I appended the error output.
>> >> >> >What could it be?
>> >> >> >
>> >> >> >Thanks!
>> >> >> >Nathan
>> >> >> >
>> >> >> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
>> >> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
>> >> >> >> >Hi,
>> >> >> >> >
>> >> >> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
>> >> >> >> >is, so I am writing to this list.
>> >> >> >> >My setup works perfectly on another computer. But now I am on this one,
>> >> >> >> >got the newest ca2+ and cedet version and having emacs-snapshot
>> >> >> >> >(ubuntu), which is 23.0.60.1, installed.
>> >> >> >> >
>> >> >> >> >Now, when I try to start emacs I get the error I appended.
>> >> >> >> >
>> >>   [ ... ]
>> >> 
>> >> -- 
>> >>           Eric Ludlam:                       eric@...
>> >>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>> >> 
>> >
>> 
>> -- 
>>           Eric Ludlam:                       eric@...
>>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>> 
>

If anyone wants to know: so far the problem has been solved by starting
emacs like this:

emacs-snapshot -Q -l .emacs

On Fri, Mar 27, 2009 at 04:46:39PM -0400, Eric M. Ludlam wrote:
> This implies that the cedet load is being done by one of Emacs's
> startup scripts.  In the Emacs manual, there is a section on start up,
> and how to control what gets run when.  You would need to figure out
> which step loads that file, and disable it, likely via a command line
> switch.
> 
> Good Luck
> Eric
> 
> >>> Nathan Huesken <cedet@...> seems to think that:
> >It is the case!
> >I think:
> >Library is file /usr/share/emacs21/site-lisp/cedet-common/cedet-loaddefs.elc
> >says everything.
> >
> >Unfortantly I have no root access to the computer. Is there something I
> >can about it without removing the old cedet?
> >
> >Thanks!
> >Nathan
> >
> >On Fri, Mar 27, 2009 at 02:21:42PM -0400, Eric M. Ludlam wrote:
> >> You might have some other version of CEDET installed, though I would
> >> guess it would be recent enough to have the inversion-require-emacs
> >> line.
> >> 
> >> You can find out by starting emacs with -q, then using M-x
> >> locate-library on things like cedet-loaddefs, or inversion.
> >> 
> >> If this is the case, let me know.  I may be able to update cedet.el to
> >> detect and warn about this sort of thing.
> >> 
> >> Eric
> >> 
> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >Sorry for my last double-posting/confusing-posting.
> >> >
> >> >I checked common/cedet-loaddefs.el and found
> >> >(autoload 'inversion-require-emacs "inversion" "\
> >> >Declare that you need either EMACS-VER, or XEMACS-VER.
> >> >Only checks one based on which kind of Emacs is being run.
> >> >
> >> >\(fn EMACS-VER XEMACS-VER)" nil nil)
> >> >
> >> >I do not know if it is correct, but it is there.
> >> >
> >> >When I start emacs, do M-x describe-function, I can not find
> >> >inversion-require-emacs
> >> >
> >> >But after I did a C-x C-e on the lines above, I can find it!
> >> >So maybe cedet-loaddefs.el is not executed for some reseons?
> >> >
> >> >Now I find this line:
> >> >(load "cedet-loaddefs" nil t)
> >> >
> >> >Doing C-x C-e does not give me inversion-require-emacs in
> >> >M-x describe-function (as I would have expected).
> >> >
> >> >Regards,
> >> >Nathan
> >> >
> >> >On Fri, Mar 27, 2009 at 12:38:07PM -0400, Eric M. Ludlam wrote:
> >> >> It would be good to check in the common//cedet-loaddefs.el file to make sure things
> >> >> like the missing inversion function is there.  Then we'd need to
> >> >> figure out why it didn't add it.
> >> >> 
> >> >> The autoloads generator has always been a bit persnickity when the
> >> >> Emacs developers change things.  Perhaps I need to update my Emacs
> >> >> from CVS.  I'd been delaying due to the RMAIL changes.
> >> >> 
> >> >> Eric
> >> >> 
> >> >> >>> Nathan Huesken <ls@...> seems to think that:
> >> >> >Hi,
> >> >> >
> >> >> >yes, I compiled cedet. I am under ubuntu and therefore compiled it with
> >> >> >make EMACS=emacs-snapshot
> >> >> >
> >> >> >I also got lines, like
> >> >> >Generating autoloads for cedet-contrib.el...
> >> >> >Generating autoloads for cedet-contrib.el...done
> >> >> >
> >> >> >Maybe cedet can not find the autoloads or something?
> >> >> >I load cedet with
> >> >> >(load-file "~/cedet/common/cedet.el")
> >> >> >
> >> >> >Can I find out if something goes wrong with the autoloads?
> >> >> >
> >> >> >Thanks!
> >> >> >Nathan
> >> >> >
> >> >> >On Fri, Mar 27, 2009 at 12:09:07PM -0400, Eric M. Ludlam wrote:
> >> >> >> Hi,
> >> >> >> 
> >> >> >>   Did you compile CEDET?  If you use CVS, you need to compile CEDET
> >> >> >> for both performance reasons, and to build the autoload files.  The
> >> >> >> autoload files is what will make these symbols available.
> >> >> >> 
> >> >> >>   Compilation should be done with the Makefile, or with the all-emacs
> >> >> >> build.  The INSTALL file explains how.
> >> >> >> 
> >> >> >> Eric
> >> >> >> 
> >> >> >> 
> >> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >> >> >Hi,
> >> >> >> >
> >> >> >> >Thanks for your reply.
> >> >> >> >I exchanged the loading of ca2+ and semantic, and now I have a different
> >> >> >> >problem.
> >> >> >> >cedet loading fails because of inversion-require-emacs.
> >> >> >> >I find this strange, but just do not know enough about emacs.
> >> >> >> >I appended the error output.
> >> >> >> >What could it be?
> >> >> >> >
> >> >> >> >Thanks!
> >> >> >> >Nathan
> >> >> >> >
> >> >> >> >On Fri, Mar 27, 2009 at 11:10:48AM -0400, Eric M. Ludlam wrote:
> >> >> >> >> >>> Nathan Huesken <cedet@...> seems to think that:
> >> >> >> >> >Hi,
> >> >> >> >> >
> >> >> >> >> >I have trouble with ca2+ and semantic. I am not sure what the problem
> >> >> >> >> >is, so I am writing to this list.
> >> >> >> >> >My setup works perfectly on another computer. But now I am on this one,
> >> >> >> >> >got the newest ca2+ and cedet version and having emacs-snapshot
> >> >> >> >> >(ubuntu), which is 23.0.60.1, installed.
> >> >> >> >> >
> >> >> >> >> >Now, when I try to start emacs I get the error I appended.
> >> >> >> >> >
> >> >>   [ ... ]
> >> >> 
> >> >> -- 
> >> >>           Eric Ludlam:                       eric@...
> >> >>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> >> >> 
> >> >
> >> 
> >> -- 
> >>           Eric Ludlam:                       eric@...
> >>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
> >> 
> >
> 

--

Thanks for the info.

I've checked in a small change to cedet.el to signal an error if cedet
is already loaded.  Hopefully this will make things faster to solve
for similar situations.

As it is a bit fundamental, it would be great for folks to try it out
and make sure it has no unintended consequences in some different
situations.

Thanks!
Eric


>>> Nathan Huesken <cedet@...> seems to think that:
>If anyone wants to know: so far the problem has been solved by starting
>emacs like this:
>
>emacs-snapshot -Q -l .emacs
>
>On Fri, Mar 27, 2009 at 04:46:39PM -0400, Eric M. Ludlam wrote:
>> This implies that the cedet load is being done by one of Emacs's
>> startup scripts.  In the Emacs manual, there is a section on start up,
>> and how to control what gets run when.  You would need to figure out
>> which step loads that file, and disable it, likely via a command line
>> switch.
>> 
>> Good Luck
>> Eric
>> 
  [ ... ]

Hi,

  In that case, it probably didn't know EXPORTAPI was a lexical
symbol.  If the spp table were dumped, it would probably not be
there.  It would then assume it is a type name because it shows up as:

const EXPORTAPI foo();

so in this case, it looks like some arbitrary data type.

  Were you able to get the CVS version of CEDET?  In it I added the
declspec keyword so if you set semantic-lex-c-preprocessor-symbol-file
to include the header with EXPORTAPI it it, things should then go
smoothly.

Eric

>>> kiwilex <kiwilex@...> seems to think that:
>
>Eric,
>
>I have perhaps some clue to help concerning this issue. I have run the
>command (semantic-analyze-debug-assist) and I have the following
>
>Unable to find datatype for: "const EXPORTAPI".
>Declared type is: nil
>
>why the parse do not consider only EXPORTAPI ?
>
>Have you any idea ?
>
>Thanks,
>
>Cyril
>
>2009/3/24 Eric M. Ludlam <eric@...>
>
>> >>> kiwilex <kiwilex@...> seems to think that:
>> >Hi,
>> >
>> >Thanks for your reply
>> >
>> >For this example, I have only set the macro in the
>> >semantic-lex-c-preprocessor-symbol-map. I do not have huse
>> >semantic-lex-c-preprocessor-symbol-file.
>> >
>> >This is strange. Perhaps my emacs version has some trouble. I don't know.
>> >Moreover, if I replace EXPORTAPI with __THROW which is defined in
>> >semantic-lex-c-preprocessor-symbol-file-built-in the parse is ok.
>>
>> Well, it seems things are ok for your config.  I just can't guess what
>> the problem is.
>>
>> >I have looked quickly a the code, and I wonder if the value generated for
>> >semantic-lex-spp-macro-symbol-obarray is ok ?
>> >
>> > [0 0 EXPORTAPI 0 __THROW 0 0 0 __restrict 0 0 0 0]
>> >
>> >Concerning active macro this would be great but user should define wich
>> >macro is used to do such thing like NDEBUG ....
>>   [ ... ]
>>
>> An obarray is a vector of symbols.  If you have an obarra "Ob", you
>> would access it like this:
>>
>>  (let ((sym (intern-soft "EXPORTAPI" Ob)))
>>    (symbol-value sym))
>>
>> where 'sym' is a symbol that is not in the global symbol space.  When
>> you print an obarray, it shows up as a vector of symbols.  The symbols
>> don't print their values, but they are there.  That is why the special
>> dump command is needed to map all the symbol atoms to some print
>> routine.  See `semantic-lex-spp-macros' for details on mapping across
>> obarrays.
>>
>> Eric
  [ ... ]

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net