alternative to ECB

alternative to ECB

[joerg.schuster]

Hello,

I am looking for a kind of IDE for emacs. It should at least be able to
deal with C and C++.
I am aware of ECB (emacs code browser). I do like its design, but it is
so slow that it cannot be used with really large projects.

Is there another package of this kind? Or is it possible to leave away
part of ecb's functionality in order to make it faster?

Jörg Schuster

Re: alternative to ECB

[Klaus Berndl]

On 15 Dec 2005, joerg schuster wrote:

>  Hello,
>  
>  I am looking for a kind of IDE for emacs. It should at least be able to
>  deal with C and C++.
>  I am aware of ECB (emacs code browser). I do like its design, but it is
>  so slow that it cannot be used with really large projects.

Could you please be a little bit more specific? Which operations are "so slow",
what are you doing? Is it slow in opening files, in parsing files or what is
slow? 

Please also remember that ECB is the "displayor" of parsing informations! The
parsing-job is done completely by the cedet-tools - maybe the problem lies
there, but to find this out we need details...
>  
>  Is there another package of this kind? Or is it possible to leave away
>  part of ecb's functionality in order to make it faster?

Probably yes, but for this i need some more details....

In general is it a smart move to send a problem report to either the
ECB-mailing-list or/and the cedet-mailing-list - see the docu...

Ciao,
Klaus

>  
>  Jörg Schuster

-- 
Klaus Berndl			mailto: klaus.berndl@sdm.de
sd&m AG				http://www.sdm.de
software design & management	
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220

Re: alternative to ECB

[dienekes]

Klaus Berndl wrote:
> On 15 Dec 2005, joerg schuster wrote:
>
>   
>>  Hello,
>>  
>>  I am looking for a kind of IDE for emacs. It should at least be able to
>>  deal with C and C++.
>>  I am aware of ECB (emacs code browser). I do like its design, but it is
>>  so slow that it cannot be used with really large projects.
>>     
>
>
>   
>
>   

I never experienced any ECB related slowness. I'm running ECB 2.31 with 
semantic 1.4.4, eieio 0.17 and speedbar 0.14beta4.

-Dienekes

Re: alternative to ECB

[joerg.schuster]

> Could you please be a little bit more specific?

When I try to edit a certain program of mine in ECB, my laptop (1GB
memory, Centrino,  1.6 GHz), doesn't do anything but trying to parse
the program. It is impossible to type anything then. The program is
about 4500 lines long and it is written in Python.

Jörg

Re: alternative to ECB

[joerg.schuster]

Hello Klaus,

I have just installed a new emacs version. The ECB problems have now
disappeared completely. Sorry for claiming ECB was slow.

It just did not occur to me that Emacs itself (or my installation)
could be the problem.

I am glad to be able to use ECB now ...


Jörg

Re: alternative to ECB

[joerg.schuster]

Hello again,

unfortunately, the problems have come back. My .emacs.el has the
following lines:

(load-file "~/bin/emacs/var/cedet/cedet-1.0pre3/common/cedet.el")
(setq load-path
      (append '("~/bin/emacs/var"
                "~/bin/emacs/var/ecb/ecb-2.32"
                )
       load-path))
(require 'ecb)

It seems that these lines alone (i.e. without me activating ECB) cause
Emacs to "freeze" when I open my Python program. When an instance of
Emacs "freezes", it doesn't show one single character of the program.
Besides, you cannot type anything. It is not possible to quit Emacs.
Neither is it possible to shut the window in which the Emacs instance
runs. Killing through the program 'kill' is still possible.

Curiously, it is no problem to open other (much smaller) Python
programs.

What could be the problem?


Jörg

Re: alternative to ECB

[Eric Ludlam]

It may be that you have found a bug in the python parser.  Can you
break out of the hang w/ C-g?  If so, you could do this:

M-x toggle-debug-on-error
;; do the reproduction
C-g

and then send the stack to cedet-devel mailing list @lists.sf.net.

Eric

>>> joerg.schuster@gmail.com seems to think that:
>Hello again,
>
>unfortunately, the problems have come back. My .emacs.el has the
>following lines:
>
>(load-file "~/bin/emacs/var/cedet/cedet-1.0pre3/common/cedet.el")
>(setq load-path
>      (append '("~/bin/emacs/var"
>                "~/bin/emacs/var/ecb/ecb-2.32"
>                )
>       load-path))
>(require 'ecb)
>
>It seems that these lines alone (i.e. without me activating ECB) cause
>Emacs to "freeze" when I open my Python program. When an instance of
>Emacs "freezes", it doesn't show one single character of the program.
>Besides, you cannot type anything. It is not possible to quit Emacs.
>Neither is it possible to shut the window in which the Emacs instance
>runs. Killing through the program 'kill' is still possible.
>
>Curiously, it is no problem to open other (much smaller) Python
>programs.
>
>What could be the problem?
>
>
>Jörg
>

-- 
Eric Ludlam                    The MathWorks x 7556  eludlam@mathworks.com
http://www.siege-engine.com                       http://www.mathworks.com

Re: alternative to ECB

[joerg.schuster]

> Can you
> break out of the hang w/ C-g?

No, I can't.

Unfortunately, I cannot give you the file I am having problems with.
But you should be able to produce similar problems with any Python
program that is at least 5000 lines long. Here is one such program:

http://www.tundraware.com/Software/twander/


Jörg

Re: alternative to ECB

[Klaus Berndl]

Well, but now it seems that the freeze comes not from ECB but from cedet -
right?

Klaus

On 20 Dec 2005, joerg schuster wrote:

> > Can you
> > break out of the hang w/ C-g?
>  
>  No, I can't.
>  
>  Unfortunately, I cannot give you the file I am having problems with.
>  But you should be able to produce similar problems with any Python
>  program that is at least 5000 lines long. Here is one such program:
>  
>  http://www.tundraware.com/Software/twander/
>  
>  
>  Jörg

-- 
Klaus Berndl			mailto: klaus.berndl@sdm.de
sd&m AG				http://www.sdm.de
software design & management	
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220

Re: alternative to ECB

[Eric Ludlam]

CEDET Background parsing enables C-g, as it is off by default in timer
fcns and in some hooks.  If ECB is doing some work in such a way and
calling the parser, it would be very helpful if it too enabled C-g.

Something like this:

    (let ((inhibit-quit nil)
          )
       (do stuff)
     ) 

If C-g is enabled at that time, I'm not sure why it would fail to exit
on C-g.  Perhaps some built-in function is being given bad parameters
or some-such.

Eric

>>> Klaus Berndl <klaus.berndl@sdm.de> seems to think that:
>
>Well, but now it seems that the freeze comes not from ECB but from cedet -
>right?
>
>Klaus
>
>On 20 Dec 2005, joerg schuster wrote:
>
>> > Can you
>> > break out of the hang w/ C-g?
>>  
>>  No, I can't.
>>  
>>  Unfortunately, I cannot give you the file I am having problems with.
>>  But you should be able to produce similar problems with any Python
>>  program that is at least 5000 lines long. Here is one such program:
>>  
>>  http://www.tundraware.com/Software/twander/>  
>>  
>>  Jörg
>

Re: alternative to ECB

[Kevin Rodgers]

joerg.schuster@gmail.com wrote:
> unfortunately, the problems have come back. My .emacs.el has the
> following lines:
> 
> (load-file "~/bin/emacs/var/cedet/cedet-1.0pre3/common/cedet.el")
> (setq load-path
>       (append '("~/bin/emacs/var"
>                 "~/bin/emacs/var/ecb/ecb-2.32"
>                 )
>        load-path))
> (require 'ecb)
> 
> It seems that these lines alone (i.e. without me activating ECB) cause
> Emacs to "freeze" when I open my Python program. When an instance of
> Emacs "freezes", it doesn't show one single character of the program.
> Besides, you cannot type anything. It is not possible to quit Emacs.
> Neither is it possible to shut the window in which the Emacs instance
> runs. Killing through the program 'kill' is still possible.
> 
> Curiously, it is no problem to open other (much smaller) Python
> programs.
> 
> What could be the problem?

Why are you putting the ~/bin/emacs/var and ~/bin/emacs/var/ecb/ecb-2.32
directories at the front of load-path?  Perhaps they are shadowing lisp
files distributed with Emacs; use `M-x list-load-path-shadows' to find
out if that's the case.

-- 
Kevin Rodgers

Re: alternative to ECB

[joerg.schuster]

> use `M-x list-load-path-shadows' to find
> out if that's the case.

I have done this. The answer was

[...]
22 Emacs Lisp load-path shadowings were found

But what does this mean?

Jörg

Re: alternative to ECB

[Peter Dyballa]

Am 21.12.2005 um 10:44 schrieb joerg.schuster@gmail.com:

> 22 Emacs Lisp load-path shadowings were found
>
> But what does this mean?
>

I think something went wrong with some installation and you now have 
multiple branches of the whole emacs/lisp or emacs/<version 
number>/lisp (and site-lisp) directory trees. I remember that I had the 
same some time.

--
Mit friedvollen Grüßen

   Pete

The box said "Use Windows 95 or better," so I got a Macintosh

Re: alternative to ECB

[Kevin Rodgers]

joerg.schuster@gmail.com wrote:
>>use `M-x list-load-path-shadows' to find
>>out if that's the case.
> 
> 
> I have done this. The answer was
> 
> [...]
> 22 Emacs Lisp load-path shadowings were found
> 
> But what does this mean?

It depends on which libraries are shadowed, and whether the
shadowing files are equivalent to the originals or are responsible
for the problem.

Did you try appending your personal directories after the
default load-path, instead of before it?

-- 
Kevin Rodgers

Re: alternative to ECB

[joerg.schuster]

I don't know where exactly the default load-path is "applied". The only
statement about load-path
in my .emacs.el currently reads as follows:

(setq load-path
      (append '("~/bin/emacs/js"
		"~/bin/emacs/var"
 		;; "~/bin/emacs/var/ecb/ecb-2.32"
		)

       load-path))

Is this bad?

Jörg

Re: alternative to ECB

[Kevin Rodgers]

joerg.schuster@gmail.com wrote:
> I don't know where exactly the default load-path is "applied". The only
> statement about load-path
> in my .emacs.el currently reads as follows:
> 
> (setq load-path
>       (append '("~/bin/emacs/js"
> 		"~/bin/emacs/var"
>  		;; "~/bin/emacs/var/ecb/ecb-2.32"
> 		)
> 
>        load-path))
> 
> Is this bad?

Maybe.  I think you should try this instead because the order of the
directories in load-path matters:

(setq load-path
       (append load-path
               '("~/bin/emacs/js"
		"~/bin/emacs/var"
  		;; "~/bin/emacs/var/ecb/ecb-2.32"
		)
               ))

-- 
Kevin Rodgers

Re: alternative to ECB

[joerg.schuster]

Thanks for the hint. I will use your version, though, in my case, it
doesn't seem to make any difference.

Jörg

Re: alternative to ECB

[Klaus Berndl]

On Tue, 20 Dec 2005, Eric Ludlam wrote:



>  CEDET Background parsing enables C-g, as it is off by default in timer
>  fcns and in some hooks.  If ECB is doing some work in such a way and
>  calling the parser, it would be very helpful if it too enabled C-g.
>  
>  Something like this:
>  
>      (let ((inhibit-quit nil)
>            )
>         (do stuff)
>       ) 

Just for ensuring not to misunderstand you:

Do you recommend, enabling C-g every time ECB calls the parser
programmatically (e.g. via `semantic-fetch-tags')?

Thanks,
Klaus

>  
>  If C-g is enabled at that time, I'm not sure why it would fail to exit
>  on C-g.  Perhaps some built-in function is being given bad parameters
>  or some-such.
>  
>  Eric
>  
> >>> Klaus Berndl <klaus.berndl@sdm.de> seems to think that:
> >
> >Well, but now it seems that the freeze comes not from ECB but from cedet -
> >right?
> >
> >Klaus
> >
> >On 20 Dec 2005, joerg schuster wrote:
> >
> >> > Can you
> >> > break out of the hang w/ C-g?
> >>  
> >>  No, I can't.
> >>  
> >>  Unfortunately, I cannot give you the file I am having problems with.
> >>  But you should be able to produce similar problems with any Python
> >>  program that is at least 5000 lines long. Here is one such program:
> >>  
> >>  http://www.tundraware.com/Software/twander/>  
> >>  
> >>  Jörg
> >

-- 
Klaus Berndl			mailto: klaus.berndl@sdm.de
sd&m AG				http://www.sdm.de
software design & management	
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220