About CEDET, Completion, and compilers

About CEDET, Completion, and compilers

[Eric M. Ludlam]

Hi all,

The long thread about "Emacs Contributions" that ended up being about 
Clang, CEDET, completion etc was interesting, and reveled problems 
people run into with CEDET, and possibly some misconceptions about what 
CEDET is with respect to the "completion" feature.  I thought I would 
try and help explain a couple things, and I'll wrap up with my thoughts 
on some TODO items that will help make CEDET better for anyone who wants 
to help out.

For those who don't know me, I wrote the first versions of CEDET and 
maintain it over in the SourceForge repository.  http://cedet.sf.net has 
lots of nifty explanations and pictures for anyone wanting to know more.

To start, CEDET is a group of very different tools, each of which covers 
a particular topic, and which work together to create a suite of 
features many associate with a modern IDE.  That includes project 
management, tagging, smart completion, and code-generation tooling.

Each of these elements is built on a framework where the raw data 
needed, such as project definitions, tag lists, and templates is 
represented in an Emacs friendly data structure.  One of CEDET's most 
important features is that data representation and the way it keeps it 
up to date.  It allows a wide range of back-ends or tools to be 
implemented in Emacs with minimal fuss.

When someone talks about using Clang or other external compiler for 
"smart completion", there is a layer in CEDET where that tool can be 
integrated in as a new smart-completion back-end, allowing any 
user-facing tool built using CEDET APIs to work with this new tool.  I 
don't really see using an external compiler as "competing" with CEDET. 
It is just a tool that fits into one corner of the big picture. 
External tools are likely to fail in many cases (ie - like when it isn't 
installed on a machine), and CEDET will simply revert back to the core 
mechanism.

Anyway, while using an external completion engine is nice for someone 
who just wants completion, it leaves out support for tagging, and the 
wide range of features you get with it.  Fortunately, it is also 
possible to integrate in a compiler (if desired) to produce tags as 
well.  In CEDET there is the tagging parser for C/C++ written in Emacs 
Lisp, plus an Exuberent CTags parser that can be used in its stead. 
Exuberent ctags is off by default simply because it isn't good enough, 
but it can be used for basic tagging for files not in buffers.  If a 
compiler such as gcc were to be extended to help support CEDET, 
preferably (from my point of view) by creating CEDET compatible tags, 
that would also allow CEDET to parse files not in buffers, but it may 
not be robust enough to handle incremental parsing as you type the way 
the Emacs parser does.  Fortunately, they do not need to be mutually 
exclusive.  Both can be used at the same time and work together because 
the underlying data structure is well defined.

This is all just basic modularization stuff applied to a particular 
problem.  Lets me discuss where CEDET tends to fall down.  My hope is 
that this could inspire someone interested in participating who just 
needs a starting point.

Detecting & Managing projects:

You can't do completion without knowing the bounds and shape of your 
sources.  One of the most common questions on the mailing list tends to 
be about setting up a "project" to get the tooling to work.  There are 
so many ways to compile code, and the Make systems are generally opaque 
making this a challenging support issue for EDE.  While I think the 
basic premise in EDE (the project management tool) is good, there is a 
diversity of support that is missing.  A good project here is making the 
task of creating a project for Emacs to describe your code a bit easier.

Quality of the C++ parser:

It was frequently noted that C++ is hard to write parsers for. 
Fortunately, the current parser that is written in Emacs Lisp covers the 
basics, and because it is by nature very forgiving, filling in the gaps 
has proven within the reach of a wide range of people.  Anyone who 
discovers a missing c++ feature should feel confident about being able 
to update the parser.

Quality of C++ completions:

The core completion engine here is also in pretty good shape, right up 
until you start playing around with templates and some other exciting 
c++ features.  David Engster has gotten quite a bit working here, but 
I'll defer to him to explain this in more detail for anyone who wants to 
help out.

Performance, and Really Large projects:

There is a core problem in the way CEDET manages tags, which is that it 
keeps them all in memory.  For large code bases, after working in them 
for a while, CEDET will make Emacs' memory use go up so much that a 
garbage collect spends more time swapping that collecting.

Fortunately, the entire system has been abstracted through some Emacs 
data structures that represent databases of tag tables.  I have done 
some work to create databases using external tools such as GNU Global 
which fit into the system transparently providing tag data.  One 
possible solution would be to develop a nice on-disk representation that 
is easy to search to move the bulk of the data out of the Emacs process.

Refactoring is non-existent:

I did start down a road with "semantic-symref" tools that can do 
primitive refactoring, but some of the key features, such as resolving 
polymorphism issues hasn't been implemented.  The data is there, the 
logic just hasn't been implemented.  At the moment it is mostly a fancy 
grep replacement.

Language X isn't supported:

The system that supports C++ has been generalized, and supports many 
languages.  C++, Java, and Emacs Lisp are perhaps the best supported so 
far.  There are a lot of opportunities to add support for new languages, 
or enhance an existing language support.


I hope this data is helpful.
Eric

Re: About CEDET, Completion, and compilers

[Andreas Röhler]

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.

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?

Cheers,

Andreas

Re: About CEDET, Completion, and compilers

[João Távora]

Andreas Röhler <andreas.roehler@online.de> writes:

> Given that's true - what about dropping EIEIO and re-building
> everything in plain Emacs Lisp?

FWIW, Eric Schulte's web-server [1] uses EIEIO and has recently been
accepted in Emacs ELPA. Eric reports it to be an roughly an order of
magnitude faster than el-node [2], and it apparently creates an EIEIO
object for every request. The code looks clean enough, but I didn't see
any `defmethod's or complicated inheritance.

But I've also noticed that some dismiss EIEIO as some kind of overkill,
a cannon to kill a fly. That's sometimes true, though I frequently wish
later that I had started out with a cannon. That's why in CL I almost
always start with CLOS right off the bat.

So, I've read some of the EIEIO docs, and know it's not as powerful as
CLOS, but would like to hear some experience about when to use it,
actual downsides experienced, etc...

Using more EIEIO could possibly make some people (including me)
understand, approach, and accept CEDET better.

João

[1] https://github.com/eschulte/emacs-web-server
[2] http://eschulte.github.io/emacs-web-server/benchmark/

Re: About CEDET, Completion, and compilers

[Andreas Röhler]

Am 13.03.2014 15:04, schrieb João Távora:
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> Given that's true - what about dropping EIEIO and re-building
>> everything in plain Emacs Lisp?
>
> FWIW, Eric Schulte's web-server [1] uses EIEIO and has recently been
> accepted in Emacs ELPA. Eric reports it to be an roughly an order of
> magnitude faster than el-node [2], and it apparently creates an EIEIO
> object for every request. The code looks clean enough, but I didn't see
> any `defmethod's or complicated inheritance.
>
>
[  ... ]

That's good news, thanks!

Re: About CEDET, Completion, and compilers

[Eric M. Ludlam]

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

EIEIO

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

On 03/13/2014 05:36 PM, Eric M. Ludlam wrote:
> 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.

Thanks for putting work into CEDET. I expect to be writing some Java in
the near future, so I'll probably be taking a much closer look at it soon.

I agree that polymorphism is useful when implementing and extending a
system like CEDET. Emacs has traditionally used dispatch functions in
cases like this, though: look at file-name-handler-alist. Consequently,
EIEIO feels a bit foreign. What motivated the choice of EIEIO over
dispatch functions or defstructs with function slots?

A while ago, I considered using EIEIO for one of my projects; I decided
to use plain defstructs instead. I didn't like how EIEIO required each
object to have a name (requiring that EIEIO allocate a new string for
each object instance), and I had very simple interface requirements, and
found calling funcall on a struct slot more straightforward than a
generic function. I still don't know how method dispatch actually works
or what the performance characteristics of the various combination
methods are. It's also not clear what happens on method redefinition,
package unloading, and so on.

CLOS is a comprehensive OO system, but I'm not sure we're dealing with a
problem that actually requires its power.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: EIEIO

[Eric M. Ludlam]

On 03/13/2014 10:26 PM, Daniel Colascione wrote:
> On 03/13/2014 05:36 PM, Eric M. Ludlam wrote:
>> 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.
>
> Thanks for putting work into CEDET. I expect to be writing some Java in
> the near future, so I'll probably be taking a much closer look at it soon.
>
> I agree that polymorphism is useful when implementing and extending a
> system like CEDET. Emacs has traditionally used dispatch functions in
> cases like this, though: look at file-name-handler-alist. Consequently,
> EIEIO feels a bit foreign. What motivated the choice of EIEIO over
> dispatch functions or defstructs with function slots?

I was taking a C++ class and learning about OO systems and ORBs back 
when ORBs were new.  It sounded like something useful for Emacs where I 
was having trouble building a precursor to CEDET, so I wrote EIEIO.  I 
never did create the ORB though.

I have vague recollections of trying to use defstructs back then, but 
they stymied me.

> A while ago, I considered using EIEIO for one of my projects; I decided
> to use plain defstructs instead. I didn't like how EIEIO required each
> object to have a name (requiring that EIEIO allocate a new string for
> each object instance), and I had very simple interface requirements, and
> found calling funcall on a struct slot more straightforward than a
> generic function. I still don't know how method dispatch actually works
> or what the performance characteristics of the various combination
> methods are. It's also not clear what happens on method redefinition,
> package unloading, and so on.
>
> CLOS is a comprehensive OO system, but I'm not sure we're dealing with a
> problem that actually requires its power.

EIEIO is not the best solution for all problems.  It sounds like you had 
a problem that could be solved in a self contained system, so it didn't 
need to be organized with an extra level of abstraction that EIEIO provides.

If you have a problem where you want to provide interfaces for external 
developers to code against, you will probably find EIEIO more useful. 
The learning curve is higher, sometimes debugging is more challenging if 
your have a lot methods overloading each other, but I've found it has 
served the goal of enabling several other developers to extend different 
parts of CEDET as intended, enabling them to implement complex behaviors 
(ie - wide interfaces) with no impact to the core.

As for method dispatch, that is a long topic.  Suffice it to say that 
EIEIO does not implement the CLOS pattern matching mechanism.  It only 
does first argument dispatching which simplified the implementation, and 
was sufficient for what I was doing in CEDET.  There are also 3 dispatch 
algorithms, so you can pick how you would like (call-next-method) to 
behave.  There are also fun things like :BEFORE and :AFTER methods which 
are nifty.  The more of those features you use, the longer it takes to 
execute those methods... naturally.  If you only have one method with a 
particular name, then it is quite fast, ie - about 5 extra lines of code 
to execute, mostly error checking.

Eric

Re: EIEIO

[David Engster]

Daniel Colascione writes:
> A while ago, I considered using EIEIO for one of my projects; I decided
> to use plain defstructs instead. I didn't like how EIEIO required each
> object to have a name (requiring that EIEIO allocate a new string for
> each object instance), and I had very simple interface requirements, and
> found calling funcall on a struct slot more straightforward than a
> generic function.

For simple projects, I don't use EIEIO either. However, from my
experience, the defstruct/funcall thing soon becomes tedious and
confusing on bigger projects. I think the main problem is that those
things aren't "self-documenting", which makes understanding and
maintaining such a code base difficult. In EIEIO, you can provide
documentation for pretty much anything, and it is integrated in Emacs'
help system[1], allowing you to jump to the different implementations of
a method. I find this to be a big advantage, well worth the initial
learning time.

-David

[1] At least this was the case for EIEIO in CEDET upstream, where we did
this through defadvice. Unfortunately, it took until a few weeks ago to
properly integrate this in Emacs proper.

Re: EIEIO

[Eric Abrahamsen]

Daniel Colascione <dancol@dancol.org> writes:

> On 03/13/2014 05:36 PM, Eric M. Ludlam wrote:
>> 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.
>
> Thanks for putting work into CEDET. I expect to be writing some Java in
> the near future, so I'll probably be taking a much closer look at it soon.
>
> I agree that polymorphism is useful when implementing and extending a
> system like CEDET. Emacs has traditionally used dispatch functions in
> cases like this, though: look at file-name-handler-alist. Consequently,
> EIEIO feels a bit foreign. What motivated the choice of EIEIO over
> dispatch functions or defstructs with function slots?
>
> A while ago, I considered using EIEIO for one of my projects; I decided
> to use plain defstructs instead. I didn't like how EIEIO required each
> object to have a name (requiring that EIEIO allocate a new string for
> each object instance), and I had very simple interface requirements, and
> found calling funcall on a struct slot more straightforward than a
> generic function. I still don't know how method dispatch actually works
> or what the performance characteristics of the various combination
> methods are. It's also not clear what happens on method redefinition,
> package unloading, and so on.
>
> CLOS is a comprehensive OO system, but I'm not sure we're dealing with a
> problem that actually requires its power.

FWIW, while debugging gnus, I have wished with great fervor that it was
written in an OO style. Half of the functions look like "(funcall (assoc
'current-context enormous-context-list)..." and it's murder trying to
figure out what context we're in. It seems like gnus is a perfect case
study for the benefits of object-oriented programming: encapsulation and
polymorphism. They should teach it in school!

Re: EIEIO

[Eric Schulte]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> On 03/13/2014 05:36 PM, Eric M. Ludlam wrote:
>>> The key thing that EIEIO lets me do is define interfaces that allows
>>> modules to work together.

One more experiential point in this thread.  I implemented an Emacs GO
mode recently and (thanks to EIEIO) I was able to transparently support
reading/writing of moves/game-state to/from multiple GO engines, network
protocols, game formats (sgf) and even the Emacs display and user, all
through a single API [1].

I would not have even attempted this without EIEIO, but with EIEIO it
was a pleasure.

Best,

Footnotes: 
[1]  https://raw.github.com/eschulte/el-go/master/go-api.el

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: EIEIO

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

() Eric Schulte <schulte.eric@gmail.com>
() Fri, 14 Mar 2014 14:13:07 -0600

   [1]  https://raw.github.com/eschulte/el-go/master/go-api.el

Btw, IMHO you should add el-go to ELPA.  That way, i can more easily
snarf the fetching SVG-display design/implementation for gnugo.el, or
even rebase (thinking longer term :-D) gnugo.el on top of that API.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

ELPA Go integration Was: EIEIO

[Eric Schulte]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> () Eric Schulte <schulte.eric@gmail.com>
> () Fri, 14 Mar 2014 14:13:07 -0600
>
>    [1]  https://raw.github.com/eschulte/el-go/master/go-api.el
>
> Btw, IMHO you should add el-go to ELPA.  That way, i can more easily
> snarf the fetching SVG-display design/implementation for gnugo.el, or
> even rebase (thinking longer term :-D) gnugo.el on top of that API.

Done.

As the ELPA README suggests,

> ** Public incubation
> 
> If you want to develop a package publicly prior to its first release (to
> benefit from others' feedback, primarily), but not in an external repo,
> you can push to an "ephemeral" branch -- subject to rebase and eventual
> removal upon finishing merge -- for the duration of the incubation.

and I don't believe el-go is ready for a public release to users, I've
pushed it to a branch of the ELPA repo named "go".

I hope you find it useful.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: ELPA Go integration Was: EIEIO

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

() Eric Schulte <schulte.eric@gmail.com>
() Sat, 15 Mar 2014 19:06:00 -0600

   > [add el-go to ELPA]

   Done.

Cool.

   and I don't believe el-go is ready for a public release to users,
   I've pushed it to a branch of the ELPA repo named "go".

OK.  What are your plans to get to release?

   I hope you find it useful.

I think how useful i find it depends mostly on how stable it is/becomes,
as declared/determined at time of release.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: ELPA Go integration Was: EIEIO

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

() Thien-Thi Nguyen <ttn@gnu.org>
() Sun, 16 Mar 2014 11:36:57 +0100

   () Eric Schulte <schulte.eric@gmail.com>
   () Sat, 15 Mar 2014 19:06:00 -0600

      I hope you find it useful.

   I think how useful i find it depends mostly on how stable it
   is/becomes, as declared/determined at time of release.

After some reflection (and off-list clue from helpful people), i
realize how haughty this remark may seem.  Better to simply and
sincerely say: Thanks; i look forward to learning how el-go works.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: ELPA Go integration Was: EIEIO

[Stefan]

> As the ELPA README suggests,

>> ** Public incubation
>> 
>> If you want to develop a package publicly prior to its first release (to
>> benefit from others' feedback, primarily), but not in an external repo,
>> you can push to an "ephemeral" branch -- subject to rebase and eventual
>> removal upon finishing merge -- for the duration of the incubation.

Actually, better would be to change the elpa-archive building script so
that you can prevent it from making a release simply by setting
something like "Version: -1".


        Stefan

Re: ELPA Go integration Was: EIEIO

[Stefan]

> Actually, better would be to change the elpa-archive building script so
> that you can prevent it from making a release simply by setting
> something like "Version: -1".

I just installed this change, so if you want you can now move your code
to elpa's main branch and just set "Version:" to "-1", which will tell
the elpa build scripts not to publish it in the GNU ELPA archive.


        Stefan

Re: EIEIO

[João Távora]

Daniel Colascione <dancol@dancol.org> writes:

> to use plain defstructs instead. I didn't like how EIEIO required each
> object to have a name (requiring that EIEIO allocate a new string for
> each object instance)

I can also see how something like this would scare me off, but those
would be the premature optimization voices-in-my-head speaking. Perhaps
you had case where that was indeed a problem.

Anyway, If I'm reading the docs and the code of `make-instance'
correctly, the implicit name slot is only used for printing an
object. In that case I see no reason why multiple instances of the same
class can't share the same string.

João

Re: About CEDET, Completion, and compilers

[Andreas Röhler]

Am 14.03.2014 01:36, schrieb Eric M. Ludlam:
> 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
>
>

Thanks a lot! Will have a closer look again ASAP.

Cheers,

Andreas

Re: About CEDET, Completion, and compilers

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    When someone talks about using Clang or other external compiler for 
    "smart completion", there is a layer in CEDET where that tool can be 
    integrated in as a new smart-completion back-end, allowing any 
    user-facing tool built using CEDET APIs to work with this new tool.  I 
    don't really see using an external compiler as "competing" with CEDET. 

I agree with you on this point: Clang is not competing with CEDET.
The problem with Clang is that it is competing with GCC.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.