From: "Eric M. Ludlam" <eric@siege-engine.com>
To: "Andreas Röhler" <andreas.roehler@online.de>
Cc: emacs-devel@gnu.org
Subject: Re: About CEDET, Completion, and compilers
Date: Thu, 13 Mar 2014 20:36:59 -0400 [thread overview]
Message-ID: <53224F2B.3070600@siege-engine.com> (raw)
In-Reply-To: <5321B561.2030004@online.de>
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
next prev parent reply other threads:[~2014-03-14 0:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 3:04 About CEDET, Completion, and compilers Eric M. Ludlam
2014-03-13 13:40 ` Andreas Röhler
2014-03-13 14:04 ` João Távora
2014-03-13 14:21 ` Andreas Röhler
2014-03-14 0:36 ` Eric M. Ludlam [this message]
2014-03-14 2:26 ` EIEIO Daniel Colascione
2014-03-14 3:35 ` EIEIO Eric M. Ludlam
2014-03-14 6:42 ` EIEIO David Engster
2014-03-14 9:41 ` EIEIO Eric Abrahamsen
2014-03-14 20:13 ` EIEIO Eric Schulte
2014-03-15 6:54 ` EIEIO Thien-Thi Nguyen
2014-03-16 1:06 ` ELPA Go integration Was: EIEIO Eric Schulte
2014-03-16 10:36 ` Thien-Thi Nguyen
2014-03-24 8:33 ` Thien-Thi Nguyen
2014-03-17 14:36 ` Stefan
2014-03-25 2:05 ` Stefan
2014-03-14 10:24 ` EIEIO João Távora
2014-03-14 6:47 ` About CEDET, Completion, and compilers Andreas Röhler
2014-03-23 14:57 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53224F2B.3070600@siege-engine.com \
--to=eric@siege-engine.com \
--cc=andreas.roehler@online.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.