Eric M. Ludlam | 1 Feb 06:11 2008

Semantic idle-summary optimization & srecode-maps

Greetings,

  I hit upon a nice way to speed up idle-summary mode in semantic.
The parsing of hoards of files has been a bit of a drag for me in my
big code base at work.  The idea is that summary-mode will disable the
'unloaded option in semanticdb-find-default-throttle while it does
lookups.

  As such, idle-summary will be very fast.  If you then use one of the
many other semantic commands that access the full database, then those
unloaded tables will then get loaded.

  It was a bit tricky as the simple concept conflicted with all the
caching mechanisms I added late last year..  I got it worked out
though and all the inter-file dependencies now track correctly.  Yay!

  Those who use this feature alot and use CVS/CEDET.  Please give it a
try and let me know how it goes.  Thanks!

  In other news, I checked in the second half of my SRecode plan,
which is a template file map that keeps itself up-to-date.  This means
that user templates (in ~/.srecode) will be automatically tracked and
loaded as needed.  That makes it easy to override particular templates
from the core templates, thus allowing customizations of higher-level
templates.  Yay again!

  If that sounds confusing, well...  Sorry.  At the moment SRecode is
yet another template writing / insertion system that happens to be a
bit complex.  For me it's more than that, as the core of a generalized
code generation system.  Hints of that system appear in a couple of
(Continue reading)

Perry Smith | 2 Feb 16:30 2008

Trouble with speedbar and svn

I discovered speedbar without ecb.  Someone in Rails has added a Rails  
view that is really nice.

But I don't get the extra characters after the file to tell me that  
the file is controlled by a version control system.  Emacs knows it is  
because the mode line says so.  And ecb properly tells me about it  
with its various icons.  But I don't see the characters described in  
the documentation.

Any ideas?  I've looked around my init files and I don't see where  
I've turned anything off.

Thanks,
Perry

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Perry Smith | 2 Feb 17:01 2008

Thinking out loud...

This note may not exactly fit this list but I thought it came close.

So far, I have not gotten font-lock for Ruby to work 100%.  And part  
of the problem is that parsing Ruby is really hard to do by, what I  
call, guessing.  E.g. % string   (there is a space before and after  
string.  If the % comes in some parse states, then the whole thing is  
a string but if it shows up in other parse states, then the % is an  
operator and string is an identifier.  There is also this toe tapping  
and noise touching you have to do if strings can take up multiple  
lines.  All this is based upon the assumption that a full and complete  
parse is not possible.

Well... it is.  And probably for a lot less cost than all the guessing  
currently being done.  So, here's my vague grand idea:

Using tools like wisent, implement a full parser and lexer.  Something  
that totally parses the entire language.  As it is parsing, it adds  
properties to the text.  One thought is to add them only to  
significant characters like the first character of an identifier --  
mostly to save space and time.

These properties are to be defined but generally they represent the  
state of the parser at that moment.  This might be just the top non- 
terminal on the parse stack or it might be the whole parse stack.   
And, another property will be the lexical name of the token.  IDENT or  
STRING or whatever.

The file is loaded, we run through it, parse and mark it.

Now, we can properly do font-lock based upon the token properties.  No  
(Continue reading)

Eric M. Ludlam | 2 Feb 19:46 2008

Re: Trouble with speedbar and svn

>>> Perry Smith <pedz <at> easesoftware.com> seems to think that:
>I discovered speedbar without ecb.  Someone in Rails has added a Rails  
>view that is really nice.
>
>But I don't get the extra characters after the file to tell me that  
>the file is controlled by a version control system.  Emacs knows it is  
>because the mode line says so.  And ecb properly tells me about it  
>with its various icons.  But I don't see the characters described in  
>the documentation.
>
>Any ideas?  I've looked around my init files and I don't see where  
>I've turned anything off.
  [ ... ]

Hello,

  Speedbar will only show VC state if a file is checked out (ie,
writable).  It uses the vc to make the determination.  I just tried it
in Emacs from CVS from a few months ago, and it still seems to work.

  The key variable to check is `speedbar-vc-do-check' to make sure
it's on.

Good Luck
Eric

--

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

(Continue reading)

Eric M. Ludlam | 2 Feb 19:57 2008

Re: Thinking out loud...

Hi,

  To the best of my knowledge, everything you need to give this a try
is available in CEDET.

  Start by making a copy of cedet/contrib/wisent-ruby.wy which is a
great contribution from Daniel Debertin.  Replace the various actions
with code that calls put-text-property for various colors instead.

  In addition, the various lexers for strings and comments could add
the colors right at detection time.

  I think you'd need to disable font-lock in that buffer to make it
work though.

  Even when the parser doesn't work, you can enable
`global-semantic-show-unmatched-syntax-mode' to show what doesn't
work.  Since Semantic implements iterative parsing, it makes handling
errors very simple since bogus text is just ignored.

  As for editing, Semantic already supports incremental parsing during
editing for tags.  It ought to be possible to take advantage of that.

  It might be possible to mix tag creation and font-locking.  If this
is the case, the tag caching of semanticdb would be a detriment since
you'd have to store the entire color scheme to disk too, or do the
parse.

  Disabling font-lock for ruby, and adding a single text property
setting into the existing ruby parser would likely be a great way to
(Continue reading)

Perry Smith | 4 Feb 05:16 2008

Re: Thinking out loud...

I got up today to start looking into this more.  I wanted first to understand the existing Ruby parser.  Ruby 1.9 was just released and there is much talk about version 2.  Most people are running 1.8.6.  The changes in parse.y between 1.8.6 and 1.9 are hugh.  Matz is introduction new syntaxes and removing things he doesn't like.  That didn't scare me too bad.  But then I noticed that yylex is 1286 lines of code and very intimately tied into the parser.  And I saw some comment which I didn't understand that "such-n-such syntax is impossible to do with bison".  But currently they are using bison.  So, I don't know exactly what this means.  This was on a blog site documenting the changes between 1.8 and 1.9.  Anyhow, the more I looked, the more I was convinced I didn't want to write a parser from scratch.

I've looked at Daniel's work a few times.  It would be really hard for me to get "right".  Ruby has so many odd things that I want to parse properly that Daniel did not address.  I can understand why now.

Eventually, after much poking and hoping, I came across Ripper.  It is a ruby class that is built in 1.9.  parse.y has these funny comments in it which I hoped were there for a reason.  In fact, I found Ripper by grepping all the Ruby source for the funny comment string. %%%

They process Ruby's parse.y into ripper.y, wrap it in a ruby class, and create a "SAX-oriented" lexer/parser.  I guess they are referring to this:  SAX (So, all of this part of it is in C)

The parser and lexer generate events that are sent to a class built up from Ripper (which is written in Ruby) through registered functions.  They have a trivial example that simply recreates the parse tree.  The lexer events give you the token and the line and column number.  The parser events give you how the tokens fit into the parse.  The parser events map directly to the bison C code which are basically the parser's reduce actions.

The beauty here is that the parser really does parse Ruby -- by definition.  I timed the parse time for the largest ruby file I could find -- 2000+ lines.  And it took 0m0.098s real time.  While back porting Ripper to 1.8.6 may not be easy (or worth while), it appears as if it is in Ruby to stay so, anyone on 1.9 or later will be able to use Ripper.  And, since it is built from the Ruby source, it will track the syntax of the version of Ruby that the user is using.  I'm really ecstatic about this.

So, my thoughts at this point is to hook up a parser as a separate program much like cscope or ispell.  Send text to it, retrieve the output, and then process it.  Since the functions that catch the parse events can do anything they want, they could produce lisp directly which would then just be executed -- maybe.  It could also produce Semantic tags.  And, I'm wanting cross reference like cscope.  That seems plausible at this point too.



On Feb 2, 2008, at 12:57 PM, Eric M. Ludlam wrote:

Hi,

 To the best of my knowledge, everything you need to give this a try
is available in CEDET.

 Start by making a copy of cedet/contrib/wisent-ruby.wy which is a
great contribution from Daniel Debertin.  Replace the various actions
with code that calls put-text-property for various colors instead.

 In addition, the various lexers for strings and comments could add
the colors right at detection time.

 I think you'd need to disable font-lock in that buffer to make it
work though.

 Even when the parser doesn't work, you can enable
`global-semantic-show-unmatched-syntax-mode' to show what doesn't
work.  Since Semantic implements iterative parsing, it makes handling
errors very simple since bogus text is just ignored.

 As for editing, Semantic already supports incremental parsing during
editing for tags.  It ought to be possible to take advantage of that.

 It might be possible to mix tag creation and font-locking.  If this
is the case, the tag caching of semanticdb would be a detriment since
you'd have to store the entire color scheme to disk too, or do the
parse.

 Disabling font-lock for ruby, and adding a single text property
setting into the existing ruby parser would likely be a great way to
see how it might work.  The harder part would likely be the
infrastructure you'd need to keep it working unobtrusively.

Good Luck
Eric

Perry Smith <pedz <at> easesoftware.com> seems to think that:
This note may not exactly fit this list but I thought it came close.

So far, I have not gotten font-lock for Ruby to work 100%.  And part  
of the problem is that parsing Ruby is really hard to do by, what I  
call, guessing.  E.g. % string   (there is a space before and after  
string.  If the % comes in some parse states, then the whole thing is  
a string but if it shows up in other parse states, then the % is an  
operator and string is an identifier.  There is also this toe tapping  
and noise touching you have to do if strings can take up multiple  
lines.  All this is based upon the assumption that a full and complete  
parse is not possible.

Well... it is.  And probably for a lot less cost than all the guessing  
currently being done.  So, here's my vague grand idea:

Using tools like wisent, implement a full parser and lexer.  Something  
that totally parses the entire language.  As it is parsing, it adds  
properties to the text.  One thought is to add them only to  
significant characters like the first character of an identifier --  
mostly to save space and time.

These properties are to be defined but generally they represent the  
state of the parser at that moment.  This might be just the top non-
terminal on the parse stack or it might be the whole parse stack.   
And, another property will be the lexical name of the token.  IDENT or  
STRING or whatever.

The file is loaded, we run through it, parse and mark it.

Now, we can properly do font-lock based upon the token properties.  No  
guess work at all is needed.

Problem 1: what about adding or deleting text?  My blue sky idea is to  
back up until we find a parse stack property.  Then start parsing as  
before.  We stop when we come to a parse stack property in the text  
that matches the current parser's parse stack.  You can see a trade  
off between the frequency that we mark the text.  Lots of marks we  
need to re-parse and re-color smaller pieces but we also trade off  
space and time adding the marks.

Problem 2: Parse Failures...  Lets break this down to sub problems.

2.A: In languages like C that have a preprocessor, a single file is  
usually not legal C until all of the preprocessing has been done.   
And, with conditional compilation, the output of the preprocessor  
skips sections of C code.  In these languages, probably the most  
practical approach is to start guessing again.  When the error happen,  
try and recover as best as possible.  Perhaps allow special comments  
in the code to identify particular structures to re-sync the parse.  
e.g. /** start of function **/.  Or patterns that could be set to  
identify the start of a function.  That would resync most parsing  
problems and keep the vague, unparsed areas down to a minimum.

2.B: truly illegal code: in this case, flag it in a warning color.   
Recovery from parse errors is still key

Really, all the parse failure problems put us back into guess mode but  
yacc/bison parse error recovery is well researched and it could be  
augmented  with patterns (including special comments) to help out.

pedz


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Eric M. Ludlam | 4 Feb 12:40 2008

Re: Thinking out loud...

Hi,

  Using Ripper sounds like a good way to tackle the problem.  If you
are looking to font-lock a buffer, it could certainly generate font
locking code directly without using any semantic tools.

  As a Semantic parser, it would probably work well too.  If it spit
out the code to make raw Semantic tags, where START and END show up at
the tail of a new tag, they could be "cooked" into usable tags.  ie:

  (semantic-tag-new-function "moose" "int" :attrib1 "a" start end)

  Those tags then get expanded.  See semantic-texi-expand-tag as an
example.

  As for the wisent parser in CEDET, the handy thing about generating
tags, or even font lock code, is that it is not required to be
complete, or even terribly accurate.  Accepting bogus syntax in tough
spots is fine for what Semantic or font lock might do with it.

  Sounds like there are some interesting options to look at.  Good
Luck.

Eric

>>> Perry Smith <pedz <at> easesoftware.com> seems to think that:

>I got up today to start looking into this more.  I wanted first to  
>understand the existing Ruby parser.  Ruby 1.9 was just released and  
>there is much talk about version 2.  Most people are running 1.8.6.   
>The changes in parse.y between 1.8.6 and 1.9 are hugh.  Matz is  
>introduction new syntaxes and removing things he doesn't like.  That  
>didn't scare me too bad.  But then I noticed that yylex is 1286 lines  
>of code and very intimately tied into the parser.  And I saw some  
>comment which I didn't understand that "such-n-such syntax is  
>impossible to do with bison".  But currently they are using bison.   
>So, I don't know exactly what this means.  This was on a blog site  
>documenting the changes between 1.8 and 1.9.  Anyhow, the more I  
>looked, the more I was convinced I didn't want to write a parser from  
>scratch.
>
>I've looked at Daniel's work a few times.  It would be really hard for  
>me to get "right".  Ruby has so many odd things that I want to parse  
>properly that Daniel did not address.  I can understand why now.
>
>Eventually, after much poking and hoping, I came across Ripper.  It is  
>a ruby class that is built in 1.9.  parse.y has these funny comments  
>in it which I hoped were there for a reason.  In fact, I found Ripper  
>by grepping all the Ruby source for the funny comment string. %%%
>
>They process Ruby's parse.y into ripper.y, wrap it in a ruby class,  
>and create a "SAX-oriented" lexer/parser.  I guess they are referring  
>to this:  SAX (So, all of this part of it is in C)
>
>The parser and lexer generate events that are sent to a class built up  
>from Ripper (which is written in Ruby) through registered functions.   
>They have a trivial example that simply recreates the parse tree.  The  
>lexer events give you the token and the line and column number.  The  
>parser events give you how the tokens fit into the parse.  The parser  
>events map directly to the bison C code which are basically the  
>parser's reduce actions.
>
>The beauty here is that the parser really does parse Ruby -- by  
>definition.  I timed the parse time for the largest ruby file I could  
>find -- 2000+ lines.  And it took 0m0.098s real time.  While back  
>porting Ripper to 1.8.6 may not be easy (or worth while), it appears  
>as if it is in Ruby to stay so, anyone on 1.9 or later will be able to  
>use Ripper.  And, since it is built from the Ruby source, it will  
>track the syntax of the version of Ruby that the user is using.  I'm  
>really ecstatic about this.
>
>So, my thoughts at this point is to hook up a parser as a separate  
>program much like cscope or ispell.  Send text to it, retrieve the  
>output, and then process it.  Since the functions that catch the parse  
>events can do anything they want, they could produce lisp directly  
>which would then just be executed -- maybe.  It could also produce  
>Semantic tags.  And, I'm wanting cross reference like cscope.  That  
>seems plausible at this point too.
  [ ... ]

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Stefano Sabatini | 7 Feb 10:54 2008
X-Face
Picon

cedet-cvs: problem compiling srecode

Hi, 

I'm using emacs 22 and cedet CVS of the day.

I have thos problem when trying to compile srecode:
cd srecode; make 

make
for loadpath in . ../common/ ../common/ ../semantic/ ../eieio/ ../speedbar/ ../semantic/bovine/
../semantic/wisent/; do \
	   echo "(add-to-list 'load-path \"$loadpath\")" >> autoloads-compile-script; \
	done;
"emacs" -batch --no-site-file -l autoloads-compile-script -f cedet-batch-update-autoloads
srecode-loaddefs.el .
Loading vc-cvs...
Updating header...
Updating header...done
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-loaddefs.el
"emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages srecode-template.wy
Compiling Grammars from: /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/semantic/semantic-grammar.elc
Package `srecode-template-wy' is up to date.
for loadpath in . ../common/ ../common/ ../semantic/ ../eieio/ ../speedbar/ ../semantic/bovine/
../semantic/wisent/; do \
	   echo "(add-to-list 'load-path \"$loadpath\")" >> srecode-compile-script; \
	done;
"emacs" -batch --no-site-file -l srecode-compile-script -f batch-byte-compile srecode.el
srecode-mode.el srecode-compile.el srecode-insert.el srecode-template-mode.el
srecode-semantic.el srecode-load.el srecode-template.el srecode-dictionary.el srecode-args.el
srecode-table.el srecode-filters.el srecode-find.el srecode-ctxt.el srecode-getset.el
srecode-cpp.el srecode-expandproto.el srecode-el.el srecode-srt.el srecode-texi.el srecode-map.el
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode.elc

In toplevel form:
srecode-mode.el:27:1:Error: Symbol's function definition is void: srecode-template-mode
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-compile.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-insert.elc

In end of data:
srecode-template-mode.el:153:1:Warning: the function `mmm-mode-on' is not
    known to be defined.
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-template-mode.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-semantic.elc

In end of data:
srecode-load.el:36:1:Warning: the function `global-srecode-minor-mode' is not
    known to be defined.
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-load.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-template.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-dictionary.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-args.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-table.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-filters.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-find.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-ctxt.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-getset.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-cpp.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-expandproto.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-el.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-srt.elc
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-texi.elc

In end of data:
srecode-map.el:352:1:Warning: the function `srecode-template-mode' is not
    known to be defined.
Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-map.elc
make: *** [srecode] Error 1

PS Unrelated: Eric, did you ever considered to switch to SVN?

Best regards.
--

-- 
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Stefano Sabatini | 7 Feb 11:57 2008
Picon

Problem with ede-cpp-root

Hi all cedeters,

I recently started to use cedet CVS, and I discovered with pleasure
the new ede-cpp-root feature, since I have a lot of pre-existing
projects which I cannot adapt for the use with EDE generated automake
files.

I downloaded cedet CVS into ~/share/emacs/site-elisp/cedet-cvs, I'm
loading it im my init.el with: 

(load-file (expand-file-name "~/share/emacs/site-lisp/lisp/cedet-cvs/common/cedet.el"))

Since the cedet-cvs dir doesn't seem to appear in the load-path
(shouldn't cedet.el already include it?) I do:
(add-to-list 'load-path "~/share/emacs/site-lisp/lisp/cedet-cvs/ede")

Then when I try to do:
(require 'ede-cpp-root)

I get:
Debugger entered--Lisp error: (invalid-slot-name "#<ede-project-autoload cpp-root>" :proj-root)
  signal(invalid-slot-name ("#<ede-project-autoload cpp-root>" :proj-root))
  eieio-default-superclass([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] :proj-root oset ede-cpp-root-project-root)
  apply(eieio-default-superclass ([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] :proj-root oset ede-cpp-root-project-root))
  eieio-generic-call(slot-missing ([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] :proj-root oset ede-cpp-root-project-root))
  slot-missing([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] :proj-root oset ede-cpp-root-project-root)
  eieio-default-superclass([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root))
  apply(eieio-default-superclass ([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root)))
  eieio-generic-call(shared-initialize ([object ede-project-autoload "cpp-root" "CPP ROOT"
ede-cpp-root ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file
ede-cpp-root :proj-file ede-cpp-root-project-file-for-dir :proj-root
ede-cpp-root-project-root :load-type ede-cpp-root-load :class-sym ede-cpp-root)))
  shared-initialize([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root))
  eieio-default-superclass([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root))
  apply(eieio-default-superclass ([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root)))
  eieio-generic-call(initialize-instance ([object ede-project-autoload "cpp-root" "CPP ROOT"
ede-cpp-root ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file
ede-cpp-root :proj-file ede-cpp-root-project-file-for-dir :proj-root
ede-cpp-root-project-root :load-type ede-cpp-root-load :class-sym ede-cpp-root)))
  initialize-instance([object ede-project-autoload "cpp-root" "CPP ROOT" ede-cpp-root
ede-cpp-root-project-file-for-dir nil unbound unbound t] (:name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root))
  eieio-default-superclass(ede-project-autoload "cpp-root" :name "CPP ROOT" :file ede-cpp-root
:proj-file ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root)
  apply(eieio-default-superclass (ede-project-autoload "cpp-root" :name "CPP ROOT" :file
ede-cpp-root :proj-file ede-cpp-root-project-file-for-dir :proj-root
ede-cpp-root-project-root :load-type ede-cpp-root-load :class-sym ede-cpp-root))
  eieio-generic-call(constructor (ede-project-autoload "cpp-root" :name "CPP ROOT" :file
ede-cpp-root :proj-file ede-cpp-root-project-file-for-dir :proj-root
ede-cpp-root-project-root :load-type ede-cpp-root-load :class-sym ede-cpp-root))
  constructor(ede-project-autoload "cpp-root" :name "CPP ROOT" :file ede-cpp-root :proj-file
ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root)
  apply(constructor ede-project-autoload "cpp-root" (:name "CPP ROOT" :file ede-cpp-root :proj-file
ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root))
  ede-project-autoload("cpp-root" :name "CPP ROOT" :file ede-cpp-root :proj-file
ede-cpp-root-project-file-for-dir :proj-root ede-cpp-root-project-root :load-type
ede-cpp-root-load :class-sym ede-cpp-root)
  byte-code("ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÇ&
Ï#ˆÐÑÒÓÔ$ˆÐÕÖ×Ø$‡" [add-to-list ede-project-class-files ede-project-autoload
"cpp-root" :name "CPP ROOT" :file ede-cpp-root :proj-file ede-cpp-root-project-file-for-dir
:proj-root ede-cpp-root-project-root :load-type ede-cpp-root-load :class-sym t eieio-defclass
ede-cpp-root-target (ede-target) nil ("EDE cpp-root project target.\nAll directories need at least
one target.") ede-cpp-root-project (eieio-instance-tracker ede-project) ((tracking-symbol
:initform ...) (include-path :initarg :include-path :initform ... :type list :documentation "The
default locate function expands filenames within a project.\nIf a header file (.h, .hh, etc) name is
expanded, and\nthe :locate-fcn slot is nil, then the include path is checked\nfirst, and other
directories are ignored.  For very large\nprojects, this optimization can save a lot of
time.\n\nDirectory names in the path can be relative to the current\nbuffer's `default-directory'
(not starting with a /).  Directories\nthat are relative to the project's root should start with a /.")
(header-match-regexp :initarg :header-match-regexp :initform
"\\.\\(h\\(h\\|xx\\|pp\\|\\+\\+\\)?\\|H\\)$\\|\\<\\w+$" :type string :documentation "Regexp
used to identify C/C++ header files.") (locate-fcn :initarg :locate-fcn :initform nil :type ...
:documentation "The locate function can be used in place of\n`ede-expand-filename' so you can quickly
customize your custom target\nto use specialized local routines instead of the EDE routines.\nThe
function symbol must take two arguments:\n  NAME - The name of the file to find.\n  DIR - The directory root
for this cpp-root project.")) ("EDE cpp-root project class.\nEach directory needs a a project file to
control it.")] 16)
  require(ede-cpp-root)
  eval((require (quote ede-cpp-root)))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

Compilation performed with:
cd ede; make

goes along just fine, and I got a ede-cpp-root.elc file.

Any hint?

Please let me know if I can provide more informations.

Best regards.
--

-- 
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Eric M. Ludlam | 7 Feb 13:42 2008

Re: cedet-cvs: problem compiling srecode

Hi,

  I had a similar problem.  For some reason when I added an autoload
cookie for srecode-template-mode to solve this warning a CVS updated
version of srecode of mine didn't update the autoloads file
correctly.  I had deleted srecode-loaddefs.el and rebuilt and it was
fine.

Good Luck
Eric

>>> Stefano Sabatini <stefano.sabatini-lala <at> poste.it> seems to think that:
>Hi, 
>
>I'm using emacs 22 and cedet CVS of the day.
>
>I have thos problem when trying to compile srecode:
>cd srecode; make 
>
  [ ... ]
>In end of data:
>srecode-map.el:352:1:Warning: the function `srecode-template-mode' is not
>    known to be defined.
>Wrote /home/stefano/share/emacs/site-lisp/lisp/cedet-cvs/srecode/srecode-map.elc
>make: *** [srecode] Error 1
>
>PS Unrelated: Eric, did you ever considered to switch to SVN?
>
>Best regards.

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Gmane