CEDET

Hi all,

  There have been several changes checked into CEDET CVS recently.
Let me attempt to enumerate.

First, a while back, I rewrote parts of the INSTALL file and
documentation.  The INSTALL points directly toward a cedet.info file
which can help bootstrap new users.  I think I already discussed this,
so this is just a reminder.  Check it out, and let me know if it
helps.

Second, I found a bug in the semantic-analyzer today.  If you had a
superclass that could not be found, an error would prevent the entire
chain from providing smart completions.  With this fixed, you can at
least get some completions instead of no completions.  This is likely
the "I can't reproduce the problem with a small example" problem that
was floating on the list earlier this summer.

After a couple questions on the ECB mailing list, I added two new
"smart" commands which may be useful.  They are:

semantic-ia-fast-jump - analyze the current context, and jump right to
    that tag.

semantic-ia-describe-class - Show all members of some class, including
    those inherited.  You have to type in the name though.

All the functions in `semantic-ia.el' are supposed to be short
examples on how to use the analyzer tools to do stuff.  As such,
functions here often get promoted to more complex tools once the
basics are understood.  Please give these a try, and if you feel
brave, hack 'em to do what you want.  They are all short functions.

Also in the same completion arena, I fixed a problem in
semanticdb-ebrowse that accidentally disabled some search ability of
semantic even if you weren't using semanticdb-ebrowse.


Next, I have changes to EDE.  I know most folks can't use EDE because
you are working on some big project that EDE doesn't understand.
EDE, however, is my interface for specifying where a project root is,
and how to find files in that project.

For purposes of these large C++ type projects where you don't want to
use the various EDE project types, there is now `ede-cpp-root.el'.
This enables a whole new style of EDE project.  With one line in your
.emacs, you can now take advantage of how semantic uses EDE to find
your header files.  Please read the commentary section of that file
for details.  This bit will be important for allowing users to get
smart completion working well for big C++ projects, so any assistance
in trying it out and testing will be much appreciated.


Thanks all
Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

Re: [CEDET-devel] CEDET changes From: Hannu Koivisto <azure@ik...> - 2007-08-31 16:45 "Eric M. Ludlam" <eric@...> writes: > Second, I found a bug in the semantic-analyzer today. If you had a > superclass that could not be found, an error would prevent the entire > chain from providing smart completions. With this fixed, you can at > least get some completions instead of no completions. This is likely > the "I can't reproduce the problem with a small example" problem that > was floating on the list earlier this summer. I suspect you refer to the problem I tried to report but failed :) So I thought I'd start testing this latest version but so far I haven't been able to build it. On Linux with Emacs 21.4. build stops with: ------------------------------------------------------------------- Wrote /home/hannuko/share/emacs21/site-lisp/cedet/contrib/eassist.elc While compiling toplevel forms in file /home/hannuko/share/emacs21/site-lisp/cedet/contrib/wisent-ruby.el: !! error (("Invalid escape character syntax")) ------------------------------------------------------------------- On Windows with Emacs 22.0.990.1 (Emacs-W32) and build started from Cygwin shell (zsh) using Cygwin make (sorry about wrapped lines): ------------------------------------------------------------------- Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo addefs.el for loadpath in . ../common/ ../speedbar/ ../eieio/; do \ echo "(add-to-list 'load-path \"$loadpath\")" >> init-compile-script; \ done; "emacs" -batch --no-site-file -l init-compile-script -f batch-byte-compile ede-l oad.el Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo ad.elc for loadpath in . ../common/ ../speedbar/ ../eieio/; do \ echo "(add-to-list 'load-path \"$loadpath\")" >> ede-compile-script; \ done; "emacs" -batch --no-site-file -l ede-compile-script -f batch-byte-compile projec t-am.el ede.el ede-pmake.el ede-pconf.el ede-proj.el ede-dired.el ede-proj-elisp .el ede-proj-misc.el ede-proj-obj.el ede-proj-prog.el ede-proj-archive.el ede-pr oj-shared.el ede-proj-info.el ede-proj-scheme.el ede-proj-aux.el ede-proj-comp.e l ede-source.el ede-util.el ede-system.el ede-speedbar.el ede-simple.el ede-cpp- root.el In toplevel form: project-am.el:44:4:Error: Cannot open load file: ede-speedbar In global-ede-mode: ede.el:735:37:Warning: `find-file-hooks' is an obsolete variable (as of Emacs 22.1); use `find-file-hook' instead. Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede.el c In toplevel form: ede-pmake.el:47:1:Error: Cannot open load file: ede-speedbar In toplevel form: ede-pconf.el:28:1:Error: Cannot open load file: ede-speedbar In toplevel form: ede-proj.el:33:1:Error: Cannot open load file: ede-speedbar . . . (the same continues) ------------------------------------------------------------------- Both ede-compile-script and init-compile-script contain ------------------------------------------------------------------- (add-to-list 'load-path nil) (add-to-list 'load-path ".") (add-to-list 'load-path "../common/") (add-to-list 'load-path "../speedbar/") (add-to-list 'load-path "../eieio/") (setq debug-on-error t) ------------------------------------------------------------------- *script files in common also have (add-to-list 'load-path nil) as their first lines. I wonder where that nil comes from. But a quick (setq load-path (cons nil load-path)) test seems to indicate that a nil entry doesn't break load-path traversal, so I can't see why it can't open those files... -- Hannu

Re: [CEDET-devel] CEDET changes From: Eric M. Ludlam <eric@si...> - 2007-08-31 20:22 >>> Hannu Koivisto <azure@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: > >> Second, I found a bug in the semantic-analyzer today. If you had a >> superclass that could not be found, an error would prevent the entire >> chain from providing smart completions. With this fixed, you can at >> least get some completions instead of no completions. This is likely >> the "I can't reproduce the problem with a small example" problem that >> was floating on the list earlier this summer. > >I suspect you refer to the problem I tried to report but failed :) >So I thought I'd start testing this latest version but so far I >haven't been able to build it. > >On Linux with Emacs 21.4. build stops with: > >------------------------------------------------------------------- >Wrote /home/hannuko/share/emacs21/site-lisp/cedet/contrib/eassist.elc >While compiling toplevel forms in file /home/hannuko/share/emacs21/site-lisp/cedet/contrib/wisent-ruby.el: > !! error (("Invalid escape character syntax")) >------------------------------------------------------------------- Ah, Daniel had some bad regexps that weren't quoted in properly. Emacs 22 allows those quoted strings to work. I checked in a fix for that. This shouldn't affect the parts you are working with though, that compiles last, and is not needed for C++ completion. >On Windows with Emacs 22.0.990.1 (Emacs-W32) and build started from >Cygwin shell (zsh) using Cygwin make (sorry about wrapped lines): > >------------------------------------------------------------------- >Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo >addefs.el >for loadpath in . ../common/ ../speedbar/ ../eieio/; do \ > echo "(add-to-list 'load-path \"$loadpath\")" >> init-compile-script; > \ > done; >"emacs" -batch --no-site-file -l init-compile-script -f batch-byte-compile ede-l >oad.el >Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/ede-lo >ad.elc >for loadpath in . ../common/ ../speedbar/ ../eieio/; do \ > echo "(add-to-list 'load-path \"$loadpath\")" >> ede-compile-script; >\ > done; >"emacs" -batch --no-site-file -l ede-compile-script -f batch-byte-compile projec >t-am.el ede.el ede-pmake.el ede-pconf.el ede-proj.el ede-dired.el ede-proj-elisp >.el ede-proj-misc.el ede-proj-obj.el ede-proj-prog.el ede-proj-archive.el ede-pr >oj-shared.el ede-proj-info.el ede-proj-scheme.el ede-proj-aux.el ede-proj-comp.e >l ede-source.el ede-util.el ede-system.el ede-speedbar.el ede-simple.el ede-cpp- >root.el > >In toplevel form: >project-am.el:44:4:Error: Cannot open load file: ede-speedbar > [ ... ] It could be that ede-speedbar was somehow whacked during a cvs-update. Deleting the file (if it is in cedet/ede) and doing another cvs update ought to fix that up. >------------------------------------------------------------------- > >Both ede-compile-script and init-compile-script contain > >------------------------------------------------------------------- >(add-to-list 'load-path nil) >(add-to-list 'load-path ".") >(add-to-list 'load-path "../common/") >(add-to-list 'load-path "../speedbar/") >(add-to-list 'load-path "../eieio/") >(setq debug-on-error t) >------------------------------------------------------------------- > >*script files in common also have (add-to-list 'load-path nil) as >their first lines. I wonder where that nil comes from. But a >quick (setq load-path (cons nil load-path)) test seems to indicate >that a nil entry doesn't break load-path traversal, so I can't see >why it can't open those files... Nil means to include the current working directory, which sort-of obsoletes ".". The algorithm that builds that could use some work. Eric -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

Re: [CEDET-devel] CEDET changes From: Hannu Koivisto <azure@ik...> - 2007-09-06 09:12 "Eric M. Ludlam" <eric@...> writes: >>>> Hannu Koivisto <azure@...> seems to think that: ... > Ah, Daniel had some bad regexps that weren't quoted in properly. > Emacs 22 allows those quoted strings to work. I checked in a fix for > that. Thanks, the fix helped. > It could be that ede-speedbar was somehow whacked during a > cvs-update. Deleting the file (if it is in cedet/ede) and doing > another cvs update ought to fix that up. No, that's not it, the file is ok (and yes, I even verified it with your suggestion). There is something weird going on: emacs -batch --no-site-file -l ede-compile-script --eval '(progn (require ''eieio "eieio.el") (require ''ede "ede.el") (message "%s" (require ''ede-speedbar "ede-speedbar.el")))' -f batch-byte-compile project-am.el ede-speedbar Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/project-am.elc ... emacs -batch --no-site-file -l ede-compile-script -f batch-byte-compile project-am.el In toplevel form: project-am.el:44:4:Error: Cannot open load file: ede-speedbar I don't get it. This doesn't happen with 21.4 or 22.0.50.1 (old CVS snapshot) in Linux. Even though I haven't tried with released 22 in Linux, this smells like an Emacs/Windows problem. > Nil means to include the current working directory, which sort-of > obsoletes ".". The algorithm that builds that could use some work. Hm, right, I should have known that. -- Hannu

Re: [CEDET-devel] CEDET changes From: Eric M. Ludlam <eric@si...> - 2007-09-06 10:57 If you find out what it is, let us know. Thanks! Eric >>> Hannu Koivisto <azure@...> seems to think that: [...] >No, that's not it, the file is ok (and yes, I even verified it with >your suggestion). There is something weird going on: > >emacs -batch --no-site-file -l ede-compile-script --eval '(progn (require ''eieio "eieio.el") (require ''ede "ede.el") (message "%s" (require ''ede-speedbar "ede-speedbar.el")))' -f batch-byte-compile project-am.el >ede-speedbar >Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/project-am.elc > >... > >emacs -batch --no-site-file -l ede-compile-script -f batch-byte-compile project-am.el >In toplevel form: >project-am.el:44:4:Error: Cannot open load file: ede-speedbar > >I don't get it. This doesn't happen with 21.4 or 22.0.50.1 (old >CVS snapshot) in Linux. Even though I haven't tried with released >22 in Linux, this smells like an Emacs/Windows problem. [ ... ]

Re: [CEDET-devel] CEDET changes From: Hannu Koivisto <azure@ik...> - 2007-09-07 15:38 "Eric M. Ludlam" <eric@...> writes: > If you find out what it is, let us know. Thanks! This sure was "fun" to debug. The cause and effect chain goes like this: I have set HOME to 'c:\documents and settings\hannuko' in my environment. The directory is actually named 'c:\Documents and Settings\hannuko' but since Windows is case-insensitive (well, to an extent anyway), it has never caused any trouble (this far). ede-project-placeholder-cache-file in ede.el is set to to (expand-file-name "~/.projects.ede") and ~/ is expanded using $HOME so the result is "c:/documents and settings/hannuko/.projects.ede". When ede.el is loaded, it calls ede-load-cache, which find-file-noselects ede-project-placeholder-cache-file. The buffer-file-name of that ends up being "c:/Documents and Settings/hannuko/.projects.ede". At the end of ede-load-cache it tries to get-file-buffer ede-project-placeholder-cache-file so that it can close the buffer. That fails, because buffer-file-name of the buffer does not match exactly (as the documentation of get-file-buffer says) ede-project-placeholder-cache-file. So the buffer is left open and not only that, it is left as the current buffer. This means that for the rest of ede.el's execution buffer local variables are those of ede-project-placeholder-cache-file buffer. Including default-directory. At the end of ede.el ede-speedbar-file-setup is called. It should be autoloaded from ede-speedbar. But since the only path that pointed to the ede directory was relative and default-directory is now something else than what it should be, autoloading fails. So, I was able to get rid of the problem by fixing my HOME environment variable. Nevertheless, I think something should be done about this. Perhaps get-file-buffer and/or expand-file-name should be changed but then again, I believe buffer-file-name of a loaded file can be different from what is given to find-file-noselect for other reasons as well (see find-file-visit-truename), so I'd also modify ede-load-cache so that it kills the buffer find-file-noselect returns. -- Hannu

Re: [CEDET-devel] CEDET changes From: Eric M. Ludlam <eric@si...> - 2007-09-07 19:43 Thanks for the detailed description! That was very helpful. I did what you suggest, and store the buffer in a variable during ede-load-cache. I also wrapped the whole thing in a (save-excursion ...) for good measure. I also found that this wasn't needed during a byte-compile, so it won't call ede-load-cache in batch mode. Hopefully, all these precautions will solve this class of problem. I really appreciate you discovering the reasons for this bug. I clearly would never have been able to find it since I run Linux and the file system doesn't work that way. The anon CVS version of ede.el should be updating shortly. Thanks Eric >>> Hannu Koivisto <azure@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: > >> If you find out what it is, let us know. Thanks! > >This sure was "fun" to debug. The cause and effect chain goes like >this: > >I have set HOME to 'c:\documents and settings\hannuko' in my >environment. The directory is actually named 'c:\Documents and >Settings\hannuko' but since Windows is case-insensitive (well, to >an extent anyway), it has never caused any trouble (this far). > >ede-project-placeholder-cache-file in ede.el is set to to >(expand-file-name "~/.projects.ede") and ~/ is expanded using $HOME >so the result is "c:/documents and settings/hannuko/.projects.ede". >When ede.el is loaded, it calls ede-load-cache, which >find-file-noselects ede-project-placeholder-cache-file. The >buffer-file-name of that ends up being "c:/Documents and >Settings/hannuko/.projects.ede". At the end of ede-load-cache it >tries to get-file-buffer ede-project-placeholder-cache-file so that >it can close the buffer. That fails, because buffer-file-name of >the buffer does not match exactly (as the documentation of >get-file-buffer says) ede-project-placeholder-cache-file. > >So the buffer is left open and not only that, it is left as the >current buffer. This means that for the rest of ede.el's execution >buffer local variables are those of >ede-project-placeholder-cache-file buffer. Including >default-directory. At the end of ede.el ede-speedbar-file-setup is >called. It should be autoloaded from ede-speedbar. But since >the only path that pointed to the ede directory was relative and >default-directory is now something else than what it should be, >autoloading fails. > >So, I was able to get rid of the problem by fixing my HOME >environment variable. Nevertheless, I think something should be >done about this. Perhaps get-file-buffer and/or expand-file-name >should be changed but then again, I believe buffer-file-name of a >loaded file can be different from what is given to >find-file-noselect for other reasons as well (see >find-file-visit-truename), so I'd also modify ede-load-cache so >that it kills the buffer find-file-noselect returns. >

1 message has been excluded from this view by a project administrator.