On 03/13/2014 09:40 AM, Andreas Röhler wrote:
Am 13.03.2014 04:04, schrieb Eric M. Ludlam:
[ ... ]
Hi Eric,
yes, CEDET is a very interesting tool.
BTW just reading at SO an answer WRT to IDE's, which IMO also stresses
the usefulness of further CEDET-development:
http://stackoverflow.com/questions/22372526/integrated-development-environments/22372626#22372626
There was a remark in the thread saying something like:
CEDET provides a toolset, but no-one uses it - beside CEDET itself.
I am familiar with this sentiment. I believe this may be true when it comes to
the EDE project style that generates Makefiles. While that is a nifty idea, it
is hard to
implement in a flexible and robust way. As such, it is pretty good for simple
projects, but is too aggressive an idea to claim as a general tool. Folks who
come at CEDET
from the IDE mindset tend to start there and get disappointed.
There are many other tools in CEDET that many users do use and depend on.
There are 345 members on the cedet-devel mailing list. Only 1 of them is me.
That seems like a
pretty good user base.
Maybe it's an occasion to make that point up:
As for me, the maybe silly reason is EIEIO. Never understood what it's
good for - and didn't want to learn something not understood...
WRT what's reported from other OO-tools, was not surprised to experience
slowness.
The problem with OO-programming seems some hardly predictable
multiplying of procedures.
In addition EIEIO is written in Emacs Lisp, which isn't known to be very
fast itself.
So at some point got the idea CEDET will never be reliably fast...
Sorry for that.
Given that's true - what about dropping EIEIO and re-building everything
in plain Emacs Lisp?
Before I wrote CEDET, I built a set of tools that did similar things and ran
into some serious problems making it work. I took a step back, and instead
focused on
infrastructure, such as a parser-generator instead of writing more parsers with
regexp, and then an object system, instead of managing polymorphism by hand
every time I
called a function. I don't think it is really possible to build something as
flexible as CEDET without a CLOS like tool.
The key thing that EIEIO lets me do is define interfaces that allows modules to
work together. For example, there is a tag-table concept in the semantic
system for
managing lists of symbols found in the source code it parses. The parser
system all knows how to populate and maintain a table. There is also code that
searches tables so
you can find a tag to jump to, for example. By defining the core interface as
a table class with EIEIO, I can also create other classes that manages tag
tables from GNU
Global, and just stick it in a list of other tables to search. The code
searching tables doesn't have to know about GNU Global. The Global person
doesn't have to know
about jumping to tags. And no-one has to write some weird bit of code that
reaches into a plist to get a function symbol to call. I was able to move the
Java completion in
CEDET from in-file only to surprisingly robust for Android in an afternoon just
by writing a database that parses a few.jar files. Nifty.
When I think of IDEs that are heavily OO, I tend to think that the UI is built
that way, with more doo-dads to click on than you could possibly use. There is
no UI code
(ie - widgets) in CEDET based on EIEIO. In fact, I think COGRE is the most UI
like thing I've built with EIEIO, mostly on a lark to see if it could be done.
It turned out
ok.
As for performance, there was a time when EIEIO didn't compile. That was
pretty darn slow. I've spent many hours in the profiler tuning it, and it is
much better now, and
EIEIO barely shows up when I profile high-level tools.
Does that help?
Eric