Cezar | 11 Jan 2007 18:17
Picon

ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size


Hello,

 I've just installed ecb-2.32 and cedet-cvs (since latest cedet had an
 issue with eating 100% CPU). Now after I deactivate ecb (with
 ecb-deactivate) I can't close any frame, I get : 

 ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size

emacs version : GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version
2.10.3) of 2006-09-20 on rothera, modified by Debian

Best regards,
Cezar

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Eric M. Ludlam | 12 Jan 2007 04:48
Gravatar

Updates to CEDET CVS (at long last!)

Hi,

  For those CEDET users who have been long patient, rejoice!  I have
found some time to spend on this project recently.

  I have been endeavoring to integrate in the changes that Joakim
Verona had provide many months ago, including the test infrastructure
and ebrowse database, and have had some success.

  You may recall that Joakim had problems getting the default
semanticdb find routines to use the ebrowse database he had made.
This was due to some core deficiencies in the dependency lookup
system.

  I have checked in changes to extract dependency management into
semantic-dep.el, which can now manage lists of include paths for both
a generic system or for system includes specifically.

  The ebrowse support Joakim wrote now sports an interactive function
that will create a new DB by calling out to the ebrowse program, load
the new database, and add what was created to the dependency search
path.  ebrowse can parse all of /usr/include/c++/<ver> in under a
second, and now I get semantic summaries on C++ standard functions.
Spiffy!

  There is certainly more to do hiding in this most recent change.  I
am hoping a couple brave souls will try it out, and perhaps find ways
to improve the system.  Please see the commentary in
semanticdb-ebrowse for some simple user level doc.

(Continue reading)

Leo | 12 Jan 2007 07:51
Face
Picon
Gravatar

Re: Updates to CEDET CVS (at long last!)

Eric M. Ludlam [01/12/2007] said:

> Hi,
>
>   For those CEDET users who have been long patient, rejoice!  I have
> found some time to spend on this project recently.
>
>   I have been endeavoring to integrate in the changes that Joakim
> Verona had provide many months ago, including the test infrastructure
> and ebrowse database, and have had some success.
>
>   You may recall that Joakim had problems getting the default
> semanticdb find routines to use the ebrowse database he had made.
> This was due to some core deficiencies in the dependency lookup
> system.
>
>   I have checked in changes to extract dependency management into
> semantic-dep.el, which can now manage lists of include paths for both
> a generic system or for system includes specifically.
>
>   The ebrowse support Joakim wrote now sports an interactive function
> that will create a new DB by calling out to the ebrowse program, load
> the new database, and add what was created to the dependency search
> path.  ebrowse can parse all of /usr/include/c++/<ver> in under a
> second, and now I get semantic summaries on C++ standard functions.
> Spiffy!
>
>   There is certainly more to do hiding in this most recent change.  I
> am hoping a couple brave souls will try it out, and perhaps find ways
> to improve the system.  Please see the commentary in
(Continue reading)

Eric M. Ludlam | 12 Jan 2007 13:33
Gravatar

Re: Updates to CEDET CVS (at long last!)

Thanks for the info!

The work I had done on the semantic pre-processor many months ago was
in my updated makefile.  My apologies.

I've checked in the deltas I have for semantic-lex and
semantic-lex-spp which should fix the below problem.

Sadly, those lex changes makes the use of the lexer a tiny bit slower
(an extra if.)  Compilation makes it unnoticeable.

Eventually, that will let me check in a new C parser update that is
macro aware, and will actually do substitutions (as one might expect)
as you parse a file.  ie:

---
#define MOOSE "spiffname"

void MOOSE(int a) { ... }
---

If anyone encounters obviously slower code parsing, please let me
know. I'd rather remove this feature than slow things down any more.

The new semantic-lex-test now provides timing information.

Good Luck
Eric

>>> Leo <sdl.web <at> gmail.com> seems to think that:
(Continue reading)

Eric M. Ludlam | 12 Jan 2007 13:37
Gravatar

Re: ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size

Hi,

  If you use

M-x toggle-debug-on-error

  you could get a stack trace.  That would help identify the culprit.

Thanks
Eric

>>> Cezar <cezar <at> mixandgo.ro> seems to think that:
>
>Hello,
>
> I've just installed ecb-2.32 and cedet-cvs (since latest cedet had an
> issue with eating 100% CPU). Now after I deactivate ecb (with
> ecb-deactivate) I can't close any frame, I get : 
>
> ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size
>
>emacs version : GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version
>2.10.3) of 2006-09-20 on rothera, modified by Debian
>
>Best regards,
>Cezar
  [ ... ]

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
(Continue reading)

Cezar | 13 Jan 2007 11:15
Picon

Re: ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size


*Backtrace* looks like this :

Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)

  .......

  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
  delete-frame()
  call-interactively(delete-frame)

"Eric M. Ludlam" <eric <at> siege-engine.com> writes:

> Hi,
>
>   If you use
>
> M-x toggle-debug-on-error
>
>   you could get a stack trace.  That would help identify the culprit.
>
> Thanks
> Eric
(Continue reading)

Eric M. Ludlam | 15 Jan 2007 18:49
Gravatar

Re: [CEDET-devel] ad-Orig-delete-frame: Variable binding depth exceeds max-specpdl-size

I think ECB overloads delete-frame with advice.  

I've CC'd that mailing list to see if Klaus has a notion.

Eric

>>> Cezar <cezar <at> mixandgo.ro> seems to think that:
>
>*Backtrace* looks like this :
>
>Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>
>  .......
>
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  ad-Orig-delete-frame(#<frame .emacs - emacs <at> localhost 0x865a690> nil)
>  delete-frame()
>  call-interactively(delete-frame)
>
>
>"Eric M. Ludlam" <eric <at> siege-engine.com> writes:
>
>> Hi,
>>
(Continue reading)

VerlSnake | 17 Jan 2007 11:03
Picon

How to switch between semantic, imenu and etags parsing support ? Examples for each of these parsing backends.

Hello CEDET/ECB fellows !
 
I have extended html-helper-mode for my development purposes and want to support this
extended mode using ECB. As a first shot I want to provide tags using exuberant ctags as
the parsing backend.
 
But though I have configured ECB to use ctags to my best knowledge, it is not invoked by
ecb-rebuild-methods-buffer().
 
I have found out that ecb-rebuild-methods-buffer() invokes
ecb-rebuild-methods-buffer-for-semantic() because ecb--semantic-active-p has the value "t".
 
Questions:
- How is a major-mode associated with a parsing backend ? In this case how is
  html-helper-mode associated with semantic parsing support ?
- How can I switch between the parsing backends semantic, imenu, etags/ctags ?
- Are there concrete examples out there how to provide new language support using each of
  these three parsing engines ?
 

TIA for Your answers
 
Kai Tischler from Northrhine-Westfalia in Germany
 
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
VerlSnake | 19 Jan 2007 18:14
Picon

XEmacs does NOT provide Ebrowse and CEDET CVS compilation fails

Hello CEDET/ECB fellows !
 
I have just checked out the newest CEDET CVS sources; during compilation,
semanticdb-ebrowse.el issues error messages ...
 
The main issue is: semanticdb-ebrowse.el depends on the presence of ebrowse - it contains
(require 'ebrowse) - and XEmacs does NOT provide Ebrowse !
 
I have then downloaded ebrowse.el and view.el from somewhere, but now compilation fails
because of the unknown symbol "display-mouse-p" ...
 
Is CEDET no longer XEmacs-compliant ? Or what would be the painless solution to make CEDET
compilable again ?
 

And yes: What is this XEmacs versus GNUEmacs thing all about ? Does it make sense for
XEmacs users to migrate over to GNUEmacs ?
 
I will be grateful for further Emacs insights in general and a compilable and runnable CEDET in
particular.

TIA for Your answers
 
Kai Tischler from Northrhine-Westfalia in Germany
 
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Eric M. Ludlam | 19 Jan 2007 21:30
Gravatar

Re: XEmacs does NOT provide Ebrowse and CEDET CVS compilation fails

Hi,

  It is my intention that CEDET work in all Emacsen.
semanticdb-ebrowse is a new file, and is also optional.  I will
endeavor to fix the build process to keep make that more reliable.

  In the meantime you can use EDE, or edit the Makefile and strike
semanticdb-ebrowse.el from the build process.

Eric

>>> "VerlSnake" <verlsnake <at> compuserve.de> seems to think that:
>Hello CEDET/ECB fellows !
>
>I have just checked out the newest CEDET CVS sources; during compilation,
>semanticdb-ebrowse.el issues error messages ...
>
>The main issue is: semanticdb-ebrowse.el depends on the presence of ebrowse - it contains
>(require 'ebrowse) - and XEmacs does NOT provide Ebrowse !
>
>I have then downloaded ebrowse.el and view.el from somewhere, but now compilation fails
>because of the unknown symbol "display-mouse-p" ...
>
>Is CEDET no longer XEmacs-compliant ? Or what would be the painless solution to make CEDET
>compilable again ?
>
>
>And yes: What is this XEmacs versus GNUEmacs thing all about ? Does it make sense for
>XEmacs users to migrate over to GNUEmacs ?
>
>I will be grateful for further Emacs insights in general and a compilable and runnable CEDET in
>particular.
>
>
>TIA for Your answers
>
>Kai Tischler from Northrhine-Westfalia in Germany
>

--

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Gmane