CEDET

Thanks.  I've checked in this change.

Eric

>>> "S.P.Tseng" <deftsp@...> seems to think that:
>
>I get error "desktop-create-buffer: Invalid function:
>(semantic-desktop-ignore-this-minor-mode)", and I found that the parameter of
>function desktop-minor-mode-handlers should be for form of (MINOR-MODE .
>RESTORE-FUNCTION)
>
>So, the line at the end of the function semantic-add-minor-mode in file
>semantic-util-modes.el. should be
>(cons toggle 'semantic-desktop-ignore-this-minor-mode)))
>instead of
>(list toggle 'semantic-desktop-ignore-this-minor-mode)))
>
>forgive me not to create a diff file.
>

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

Hi,

  I retraced the stack through my code, and it looks like a bug in
`file-truename'.  I'm assuming this because the inputs to it look
valid, and even if I pass bogus stuff in to my version of
file-truename like that, it seems to work.  A wild guess is that it is
because there are spaces in the default directory, though it worked
for me when I tried it.

  A way to find out is, if you have this stack active, you can press
"e" for eval, and get the output of:

default-directory  
  - ie, is it the directory relative to the unknown proxy

M-x find-function RET file-truename

M-x eval-defun

then reproduce it again.  This will point out code in file-truename
with the issue.

When I run this on some linux dirs it seems to work ok.

Eric

>>> Alastair Rankine <arsptr@...> seems to think that:
>Just as the subject line says, I ran semanticdb-create-ebrowse-database 
>on the VC++ 8 headers directory. Semantic didn't seem to like it too much...
>
>
>Debugger entered--Lisp error: (args-out-of-range "unknown-proxy.hh" 0 -1)
>   file-truename("unknown-proxy.hh")
>
>
>Full stack trace is here: http://pastie.org/318303
>
>This is with the latest CVS version of cedet.
>
>Any suggestions?
  [ ... ]

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

Thanks for the help...

 From a bit of playing around I get the same error when file-truename is 
called on any non-existent file. It's not obvious to me what the correct 
return value should be in this case, but it's almost certainly not an 
args-out-of-range error!

I'll chase this down on the windows emacs lists and see if it can be, or 
has been, fixed.

Answers to your questions below:


Eric M. Ludlam wrote:
 > Hi,
 >
 >   I retraced the stack through my code, and it looks like a bug in
 > `file-truename'.  I'm assuming this because the inputs to it look
 > valid, and even if I pass bogus stuff in to my version of
 > file-truename like that, it seems to work.  A wild guess is that it is
 > because there are spaces in the default directory, though it worked
 > for me when I tried it.
 >
 >   A way to find out is, if you have this stack active, you can press
 > "e" for eval, and get the output of:
 >
 > default-directory
 >   - ie, is it the directory relative to the unknown proxy

"c:/Program Files/Microsoft Visual Studio 8/VC/include/"

 > M-x find-function RET file-truename
 >
 > M-x eval-defun
 >
 > then reproduce it again.  This will point out code in file-truename
 > with the issue.

Partial stack trace:

Debugger entered--Lisp error: (args-out-of-range "unknown-proxy.hh" 0 -1)
   substring("unknown-proxy.hh" 0 -17)
   (setq rest (substring filename 0 (* -1 ...)))
   (if longname (setq filename longname) (setq missing (concat "/" ...)) 
(setq rest (substring filename 0 ...)) (setq filename (concat ... missing)))
   (let ((longname ...) missing rest) (if longname (setq filename 
longname) (setq missing ...) (setq rest ...) (setq filename ...)))
   (if (string-match "[[*?]" filename) nil (let (... missing rest) (if 
longname ... ... ... ...)))
   (unless (string-match "[[*?]" filename) (let (... missing rest) (if 
longname ... ... ... ...)))
   (if handler (setq filename (funcall handler ... filename)) (unless 
(string-match "[[*?]" filename) (let ... ...)))
   (let ((handler ...)) (if handler (setq filename ...) (unless ... 
...)) (setq done t))
   (if (eq system-type (quote windows-nt)) (let (...) (if handler ... 
...) (setq done t)))
   (let (done (file-name-handler-alist ...)) (or prev-dirs (setq 
prev-dirs ...)) (if (eq system-type ...) (let ... ... ...)) (while (not 
done) (setcar counter ...) (if ... ...) (let ... ...)) filename)
   file-truename("unknown-proxy.hh")

(remainder of the stack trace seems to be similar to the previous one)

Alastair Rankine wrote:
>  From a bit of playing around I get the same error when file-truename is 
> called on any non-existent file. It's not obvious to me what the correct 
> return value should be in this case, but it's almost certainly not an 
> args-out-of-range error!

OK on second thoughts this seems like a semantic problem.

The documentation for file-truename states that the argument should be 
an absolute path. Semantic is passing it a relative path, ie 
("unknown-proxy.hh").

Anyway the following patch seemed to work for me, or at least it didn't 
crash :)

Index: semanticdb-ebrowse.el
===================================================================
RCS file: /cvsroot/cedet/cedet/semantic/semanticdb-ebrowse.el,v
retrieving revision 1.20
diff -u -r1.20 semanticdb-ebrowse.el
--- semanticdb-ebrowse.el       10 Oct 2008 21:43:14 -0000      1.20
+++ semanticdb-ebrowse.el       19 Nov 2008 22:18:57 -0000
@@ -380,7 +380,7 @@
                     (ebrowse-cs-file class)
                     ;; Not def'd here, assume our current
                     ;; file
-                   "unknown-proxy.hh"))
+                   (concat default-directory "/unknown-proxy.hh")))
          (vars (ebrowse-ts-member-functions tree))
          (fns (ebrowse-ts-member-variables tree))
          (toks nil)
@@ -425,7 +425,7 @@
                       (ebrowse-cs-file (ebrowse-ts-class tree))
                       ;; Not def'd here, assume our current
                       ;; file
-                     "unknown-proxy.hh")))
+                     (concat default-directory "/unknown-proxy.hh"))))

    (let* ((tab (or (semanticdb-file-table dbe fname)
                   (semanticdb-create-table dbe fname)))

Thanks for the patch.  It seems like a reasonable thing to do.

Eric

>>> Alastair Rankine <arsptr@...> seems to think that:
>Alastair Rankine wrote:
>>  From a bit of playing around I get the same error when file-truename is 
>> called on any non-existent file. It's not obvious to me what the correct 
>> return value should be in this case, but it's almost certainly not an 
>> args-out-of-range error!
>
>OK on second thoughts this seems like a semantic problem.
>
>The documentation for file-truename states that the argument should be 
>an absolute path. Semantic is passing it a relative path, ie 
>("unknown-proxy.hh").
>
>Anyway the following patch seemed to work for me, or at least it didn't 
>crash :)
>
>Index: semanticdb-ebrowse.el
>===================================================================
>RCS file: /cvsroot/cedet/cedet/semantic/semanticdb-ebrowse.el,v
>retrieving revision 1.20
>diff -u -r1.20 semanticdb-ebrowse.el
>--- semanticdb-ebrowse.el       10 Oct 2008 21:43:14 -0000      1.20
>+++ semanticdb-ebrowse.el       19 Nov 2008 22:18:57 -0000
>@@ -380,7 +380,7 @@
>                     (ebrowse-cs-file class)
>                     ;; Not def'd here, assume our current
>                     ;; file
>-                   "unknown-proxy.hh"))
>+                   (concat default-directory "/unknown-proxy.hh")))
>          (vars (ebrowse-ts-member-functions tree))
>          (fns (ebrowse-ts-member-variables tree))
>          (toks nil)
>@@ -425,7 +425,7 @@
>                       (ebrowse-cs-file (ebrowse-ts-class tree))
>                       ;; Not def'd here, assume our current
>                       ;; file
>-                     "unknown-proxy.hh")))
>+                     (concat default-directory "/unknown-proxy.hh"))))
>
>    (let* ((tab (or (semanticdb-file-table dbe fname)
>                   (semanticdb-create-table dbe fname)))
>
  [ ... ]

Eric M. Ludlam wrote:
>   I was studying idutils and GNU Global to understand them better for
> a project unrelated to Semantic.  It occurred to me that integrating
> such a tool w/ Semantic would be pretty easy, especially after I got
> exuberant ctags working as a parsing back-end.
> 
>   I'll probably only ever get around to integrating one such tool, and
> am looking for advice on the best tool out there for reference
> tracking, incremental database updates, emacs-readable output, breadth
> of language support with C/C++ being most important, and any bonus
> features that may be available.

I've used GNU Global before and it does a decent job of tagging C++ code 
in my experience. It's not perfect of course, but nothing is! I think it 
would get my vote anyway, FWIW.

Hi,

  If you are using the CVS version of CEDET, you can set
semantic-lex-c-preprocessor-symbol-file to ave whichever tricky files
you have in it.  I suspect this may solve your problem, though I am
not entirely sure I grok the entire situation.

Eric

>>> Hannes Janetzek <hannes.janetzek@...> seems to think that:
>Hello, 
>I ran into a problem with semantics way of parsing
>headerfiles so that completion does not work correctly. The project
>I'm hacking on (enlightenment 0.17) first includes all typedefs and
>then the definitions. the main header file looks like this:
>#define E_TYPEDEFS 1
>#include "e_includes.h"
>#undef E_TYPEDEFS
>#include "e_includes.h"
>
>the included headers like this: 
>#ifdef E_TYPEDEFS
>typedef struct _E_Border E_Border;
>...
>#else
>struct _E_Border..
>#endif
>
>This causes semantic to exclude the typedefs.  Is there a way to solve
>this problem? 
  [ ... ]

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

Hello again,

On 11/4/08, Eric M. Ludlam <eric@...> wrote:
> Hi,
>
>   If you are using the CVS version of CEDET, you can set
> semantic-lex-c-preprocessor-symbol-file to ave whichever tricky files

as far as I understood the documentation this is only to replace or
insert things with the preprocessor. the thing here is that one would
have to parse the file twice, with and without E_TYPEDEFS set. since
from the construct mentioned before one part of the file is always
'disabled' for parsing:
>>#ifdef E_TYPEDEFS
>>typedef struct _E_Border E_Border;
>>...
>>#else
>>struct _E_Border..
>>#endif

I guess what is needed to make this work would be that semantic
searches for includes recursively, remembers the #defines from all the
'parent' files and if a file is included two times the second scan
should not overwrite the first scan.

But no hurry :) To me this is not essential atm, just wanted to see
the state of cedet and it really got much better than last time I
tried. looking forward to see it in emacs.

Best Regards



> you have in it.  I suspect this may solve your problem, though I am
> not entirely sure I grok the entire situation.
>
> Eric
>
>>>> Hannes Janetzek <hannes.janetzek@...> seems to think that:
>>Hello,
>>I ran into a problem with semantics way of parsing
>>headerfiles so that completion does not work correctly. The project
>>I'm hacking on (enlightenment 0.17) first includes all typedefs and
>>then the definitions. the main header file looks like this:
>>#define E_TYPEDEFS 1
>>#include "e_includes.h"
>>#undef E_TYPEDEFS
>>#include "e_includes.h"
>>
>>the included headers like this:
>>#ifdef E_TYPEDEFS
>>typedef struct _E_Border E_Border;
>>...
>>#else
>>struct _E_Border..
>>#endif
>>
>>This causes semantic to exclude the typedefs.  Is there a way to solve
>>this problem?
>   [ ... ]
>
> --
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>

Ah, I was worried about that.  This is something I don't think any
tagging utilities will work with since all the code involved in the
smart completion and such assumes a static named space unrelated to
position in the code you are completing in.

Your best bet is probably to pick what is most likely the value, and
set it explicitly in the c-mode-hook based on filename perhaps.

Eric

>>> "hannes.janetzek@..." <hannes.janetzek@...> seems to think that:
>Hello again,
>
>On 11/4/08, Eric M. Ludlam <eric@...> wrote:
>> Hi,
>>
>>   If you are using the CVS version of CEDET, you can set
>> semantic-lex-c-preprocessor-symbol-file to ave whichever tricky files
>
>as far as I understood the documentation this is only to replace or
>insert things with the preprocessor. the thing here is that one would
>have to parse the file twice, with and without E_TYPEDEFS set. since
>from the construct mentioned before one part of the file is always
>'disabled' for parsing:
>>>#ifdef E_TYPEDEFS
>>>typedef struct _E_Border E_Border;
>>>...
>>>#else
>>>struct _E_Border..
>>>#endif
>
>I guess what is needed to make this work would be that semantic
>searches for includes recursively, remembers the #defines from all the
>'parent' files and if a file is included two times the second scan
>should not overwrite the first scan.
>
>But no hurry :) To me this is not essential atm, just wanted to see
>the state of cedet and it really got much better than last time I
>tried. looking forward to see it in emacs.
>
>Best Regards
>
>
>
>> you have in it.  I suspect this may solve your problem, though I am
>> not entirely sure I grok the entire situation.
>>
>> Eric
>>
>>>>> Hannes Janetzek <hannes.janetzek@...> seems to think that:
>>>Hello,
>>>I ran into a problem with semantics way of parsing
>>>headerfiles so that completion does not work correctly. The project
>>>I'm hacking on (enlightenment 0.17) first includes all typedefs and
>>>then the definitions. the main header file looks like this:
>>>#define E_TYPEDEFS 1
>>>#include "e_includes.h"
>>>#undef E_TYPEDEFS
>>>#include "e_includes.h"
>>>
>>>the included headers like this:
>>>#ifdef E_TYPEDEFS
>>>typedef struct _E_Border E_Border;
>>>...
>>>#else
>>>struct _E_Border..
>>>#endif
>>>
>>>This causes semantic to exclude the typedefs.  Is there a way to solve
>>>this problem?
  [ ... ]

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

Hi,

  My brief look at your patch indicates you have the right idea here.
For me to accept a patch of 10 or more "new" lines, you will need to
have signed papers with the FSF for contributions to Emacs.

  You can send email to copyright-clerk@... specifying your
intent, and they will help you out.

  As I'm sure you have noticed, the current SRecode support for
regenerating tag code is proof-of-concept and does need help for many
more languages.  I'm excited to know this is proving useful.

  In your patch, you ask "Is there a better way?"

  Instead of a new section dictionary, you could simply set a value in
the current dictionary for CONST which would be "const ".  If it is
not const, set CONST to be "".

Eric

>>> Jan Moringen <jan.moringen@...> seems to think that:
>Hi,
>
>I am currently writing an srecode application, which should work for
>object oriented languages. When testing my C++ templates, I had the
>impression, that some dictionary entries, specific to C++, should be
>added using the mode local override in the language support file.
>
>The attached patch implements this. The patch is not that useful without
>extended language templates (see below). I am not sure how to implement
>binary alternatives with srecode. Consequently the treatment of
>'variable tags may not be optimal.
>
>If there is interest, I would also like to contribute the srecode
>application, the mode local override for Java and the extended templates
>for C++, Python and Java when they are ready.
  [ ... ]

Hi.

>   My brief look at your patch indicates you have the right idea here.
> For me to accept a patch of 10 or more "new" lines, you will need to
> have signed papers with the FSF for contributions to Emacs.
> 
>   You can send email to copyright-clerk@... specifying your
> intent, and they will help you out.

I wasn't aware of that, but I will try to figure this out.

> As I'm sure you have noticed, the current SRecode support for
> regenerating tag code is proof-of-concept and does need help for many
> more languages.  I'm excited to know this is proving useful.

Actually, the things I have tried so far worked pretty well. I will
report any progress or problems as I go along.

> In your patch, you ask "Is there a better way?"
> 
>   Instead of a new section dictionary, you could simply set a value in
> the current dictionary for CONST which would be "const ".  If it is
> not const, set CONST to be "".

If I understand your suggestion correctly, you would assign the actual
text (or nothing) to the dictionary key. I thought of that as well, but
it would prevent users from "fine-tuning" whitespaces and newlines
surrounding the "const". That is why I went with the section dictionary.
Maybe I am thinking overly general in this case.

By the way, I unintendedly submitted the part which tries to store the
fully qualified name using the FULLNAME key. As far as I can see,
semantic-tag-full-name is not overloaded for any mode, so this part
doesn't make any sense. (Unless I don't include the mode local
implementation of semantic-tag-full-name, that is ;)

Once I have taken care of those FSF papers, I will send an updated
patch.

Kind regards,
Jan

>>> Jan Moringen <jan.moringen@...> seems to think that:
>Hi.
>
>>   My brief look at your patch indicates you have the right idea here.
>> For me to accept a patch of 10 or more "new" lines, you will need to
>> have signed papers with the FSF for contributions to Emacs.
>> 
>>   You can send email to copyright-clerk@... specifying your
>> intent, and they will help you out.
>
>I wasn't aware of that, but I will try to figure this out.

This is because CEDET will be integrated into Emacs sometime soon.
You will need to send signed papers saying that you will give the
copyright to code you write for Emacs to the FSF.  You will also need
to get something signed by your business or school where they claim no
ownership.  The first is easy.  The second is not usually too
difficult.

>> As I'm sure you have noticed, the current SRecode support for
>> regenerating tag code is proof-of-concept and does need help for many
>> more languages.  I'm excited to know this is proving useful.
>
>Actually, the things I have tried so far worked pretty well. I will
>report any progress or problems as I go along.
>
>> In your patch, you ask "Is there a better way?"
>> 
>>   Instead of a new section dictionary, you could simply set a value in
>> the current dictionary for CONST which would be "const ".  If it is
>> not const, set CONST to be "".
>
>If I understand your suggestion correctly, you would assign the actual
>text (or nothing) to the dictionary key. I thought of that as well, but
>it would prevent users from "fine-tuning" whitespaces and newlines
>surrounding the "const". That is why I went with the section dictionary.
>Maybe I am thinking overly general in this case.

If "CONST" were added generically, then I would agree.  In this case
it is for C++ only.  Since the templates you will write will be
matched to the code adding CONST to the dictionary, it may not matter.

You may need to distinguish from something that is const and a macro,
as something like:

#define FOO 1

is also const.

>By the way, I unintendedly submitted the part which tries to store the
>fully qualified name using the FULLNAME key. As far as I can see,
>semantic-tag-full-name is not overloaded for any mode, so this part
>doesn't make any sense. (Unless I don't include the mode local
>implementation of semantic-tag-full-name, that is ;)
  [ ... ]

The fullname function was added for the benefit of Java and, more
specifically JDEE.  I guess it was never used.  It would make a lot of
sense to add overloads for C++ also, as this is now derivable from the
:parent attribute.  I think there are some cases that could take
advantage of this, such as code using semantic-analyze-unsplit-name
perhaps.  I'll have to investigate that concept.

Eric

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