speedbar requirement

Hi,
I'm wondering whether it is necessary to install a custom "speedbar"  
with cedet.
I've got speedbar 1.0 as it comes with Emacs 22 (speedbar-version is  
"1.0"), and I wonder whether CEDET really requires the fix that went  
into 1.0.1.

I would like to avoid overriding the speedbar in Aquamacs until it  
has been updated in the GNU Emacs CVS.
(I can modify cedet-packages to achieve this, but I thought I'd ask  
you first.)

Thank you.

- David

--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: speedbar requirement

Hi,

  I diffed Emacs 22 speedbar vs my speedbar, and it seems to have
moved ahead.  I don't think there is anything specific about the
CEDET/speedbar version needed for the CEDET to work, but there ARE
things in the Emacs/Speedbar version that Emacs 22 needs, for GUD in
particular.

  I'll merge those Emacs changes in that I can, but some I cannot move
forward as they are needed to keep speedbar working in older versions
of Emacs.

  To make Emacs speedbar work w/ CEDET, you can tweek the file
cedet/common/cedet.el, and update the version number required to the
version number in Emacs, and CEDET will stop shadowing with the CEDET
version of speedbar.

Good Luck
Eric

>>> David Reitter <david.reitter <at> gmail.com> seems to think that:
>Hi,
>I'm wondering whether it is necessary to install a custom "speedbar"  
>with cedet.
>I've got speedbar 1.0 as it comes with Emacs 22 (speedbar-version is  
>"1.0"), and I wonder whether CEDET really requires the fix that went  
>into 1.0.1.
>
>I would like to avoid overriding the speedbar in Aquamacs until it  
>has been updated in the GNU Emacs CVS.

Re: failed to define function semantic-default-c-setup

>>>>> On Sat, 14 Jul 2007, Dave Milter wrote:

> I time to time get this message:
> Loading semantic-c...done
> File mode specification error: (error "Autoloading failed to define
> function semantic-default-c-setup")

Hi,

Gentoo has received a similar bug report, reported by Jules Colding:
<https://bugs.gentoo.org/show_bug.cgi?id=191341>
The facts destilled from it are the following:

With CEDET 1.0pre4 and GNU Emacs 22.1, opening a C file always shows
the following error message:

   File mode specification error: (error "Autoloading failed to define
   function semantic-default-c-setup")

The problem is due to semantic/bovine/semantic-c.elc being truncated;
the byte-compiled file is very short (less than 800 bytes) and, as far
as I can see, contains only the code of the "require" statements at the
beginning of semantic-c.el.

Interestingly, this happens only if a CEDET version is already
installed in /usr/share/emacs/site-lisp during compilation (it doesn't
matter if upgrading from pre3 or recompiling pre4). If the installed
version is removed from site-lisp before the new compilation,
semantic-c.el will compile cleanly.

Build failure for CEDET 1.0pre4 with Emacs 21.4

Hi,

looks like wisent needs bovinator as a prerequisite to build unter
Emacs 21.4. See <https://bugs.gentoo.org/show_bug.cgi?id=183205>
for the details.

Patch is included below.

Ulrich

--- cedet-1.0pre4/semantic/Makefile~	2007-06-06 04:00:10.000000000 +0200
+++ cedet-1.0pre4/semantic/Makefile	2007-06-27 00:45:06.000000000 +0200
 <at>  <at>  -114,7 +114,7  <at>  <at> 
 	"$(EMACS)" -batch --no-site-file -l $ <at> -compile-script -f batch-byte-compile $^

 .PHONY:wisent
-wisent:
+wisent: bovinator
 	cd wisent; $(MAKE)

 .PHONY:Tests

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Semantic ("Hierarchical") Syntax Highlighting

Hey,

I'm rather new to Cedet, Lisp and Emacs, coming from the world of
Textmate.  I really like what I see, but there is one thing that I think
Semantic has very nearly done, but from what I can tell has left undone.

Let me explain a bit of context, first, though.

Textmate has the concept of "scopes" which allows certain features, most
importantly the syntax highlighting and tab triggers, to know their spot
in the parse tree.  Textmate is lame and does this via regexes (although
recursively submatching elements to form the tree, as far as I know),
although it still is a very powerful system.

The highlighting in Textmate can therefore be somewhat similar to CSS,
in how it cascades.  A "scope selector" is very similar to a CSS
selector but for TM themes; for example, one could have a
background-style for "source.lisp", another style for "keyword" (e.g.
bold), and then a style for "source.lisp keyword" which, like CSS, would
inherit the properties from both the other elements (or could simply
change the color, and not add any conflicting rules, so all would be
applied).

Now, the CSS-like syntax is a bit complicated, and I don't see how it
could fit into Lisp easily.  However, to me, it makes a lot of sense to
have a syntax highlighter based on the Semantic parser, rather what I
see in Font Lock (very simple highlighting that is rather unintelligent,
relatively).

Because the parse tree already exists, I assume doing something like

Re: Semantic ("Hierarchical") Syntax Highlighting

Hi Jeff,

  The Semantic parse could do what you are looking for, but there is
no infrastructure to handle it.

  In addition, most of the parsers, such as the ones for C++, do not
parse function bodies.  There are built-in functions in Emacs Lisp
that balance parenthetic expressions, such as the { } in C, so those
are used to make parsing faster.

  In addition, Semantic doesn't keep a full parse tree.  The parsers
only collect tag information, so that's the extent of the parse tree
that is left.

  As such, to do what you want, you would have to write a parser from
scratch that parsed all of C (or whatever language you wanted) and
then build up a little infrastructure to do coloring instead of
creating tags.  It's been on my todo list to try it out for a long
time, but I've been trying to get the smart completion thingy and some
code generation tools working reliably instead.

  If you use Java, then you are in luck as David has written a Java
parser that will parse the whole file.

Good Luck
Eric

>>> Jeff Wheeler <jeff <at> nokrev.com> seems to think that:
>Hey,
>

Updates to Semantic

Greetings all,

  After a couple weeks of hacking around in Semantic, I made several
check-ins over the weekend.  I started just trying to get 'using'
statements in C++ working as members of the local scope so you could
complete through the shortened names.  I ended up instead going
through and refactoring the analyzer.

  There are a few new utilities which would likely be useful for
anyone using them.

  First up, semanticdb-ref.el manages references between semantic
databases (via #include style statements.)  This is the key component
to the next set of caches which allow a file which is reparse to flush
caches on dependent files.

  Next, semanticdb-find.el has a cache for the list of all files
dependent on, such as the list of include statements.  A typical
analysis will request the list of includes several times, so the cache
will prevent all that extra work from happening.  (Saving a whopping
.02 seconds or so.)

  semanticdb-typecache.el is the next big change.  This manages a
cache of all the datatypes you can get to from a given file (excluding
scoped types.)  The analyzer used to do a search, and then merge all
similarly named namespaces together.  This is now the job of the
typecache.

  The typecache can take a good 10 to 15 seconds to build the first
time in a particularly large source-code base (like the one I have at

Variable binding depth exceeds max-specpdl-size

Hello,

I just updated my cvs-copy of cedet. I fired up emacs and opened one of
my source files.
At a good place, I began to type and did a
"semantic-complete-analyze-inline".

In the mini-buffer I got the message:
"Variable binding depth exceeds max-specpdl-size"

Unfortantly I was unable to reproduce the error in a short exampel :(

Greetings,
Nathan

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

Does semantic know the array size?

I have some C code which reads binary data directly into various structs
(i.e. it was not written to be portable). The binary format now cannot be
changed, but I would like to correct the code to make it portable.

For example, a struct like this:

typedef struct
{
 CHAR8 sLibName[ 256 ];
 INT32 iUsed;
 UINT16 iSort;
 BOOLEAN fContainsSubDirectories;
} HEADER;

is currently being loaded with:

fread(&FileHeader, sizeof(FileHeader), 1, hFile)

and I want to replace the call to fread with a call to a portable function
which works independently of endianness or struct padding. The function
would look something like:

BOOLEAN load_HEADER(HEADER * data, FILE * hFile)
{
  UINT8 buf[263];

  if (fread(buf, sizeof(buf), 1, hFile) != 1)
    return FALSE;

  memcpy(data->sLibName, &buf[0], 256);

Re: Variable binding depth exceeds max-specpdl-size

>>> =?ISO-8859-15?Q?Nathan_H=FCsken?= <cedet <at> lonely-star.org> seems to think that:
>Hello,
>
>I just updated my cvs-copy of cedet. I fired up emacs and opened one of
>my source files.
>At a good place, I began to type and did a
>"semantic-complete-analyze-inline".
>
>In the mini-buffer I got the message:
>"Variable binding depth exceeds max-specpdl-size"
>
>Unfortantly I was unable to reproduce the error in a short exampel :(
>
>Greetings,
>Nathan
  [ ... ]

Hi,

  Does toggle-debug-on-error show a stack ok?  There are a couple new
recursive routines, but I thought I was able to get rid of that
problem.

  If the stack is particularly large an ornery you can just mail it to
me directly so the list isn't flooded.

Thanks
Eric

--

--