From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: About CEDET, Completion, and compilers Date: Thu, 13 Mar 2014 20:36:59 -0400 Message-ID: <53224F2B.3070600@siege-engine.com> References: <53212048.70901@siege-engine.com> <5321B561.2030004@online.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1394757426 10590 80.91.229.3 (14 Mar 2014 00:37:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 00:37:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?ISO-8859-1?Q?Andreas_R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 01:37:16 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WOG7f-0002VQ-St for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 01:37:16 +0100 Original-Received: from localhost ([::1]:42182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOG7f-0004Sh-CE for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2014 20:37:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOG7X-0004Jw-Ss for emacs-devel@gnu.org; Thu, 13 Mar 2014 20:37:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOG7S-0006Uf-Bf for emacs-devel@gnu.org; Thu, 13 Mar 2014 20:37:07 -0400 Original-Received: from mail-qa0-x22d.google.com ([2607:f8b0:400d:c00::22d]:63682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOG7S-0006Ub-5h for emacs-devel@gnu.org; Thu, 13 Mar 2014 20:37:02 -0400 Original-Received: by mail-qa0-f45.google.com with SMTP id hw13so1859393qab.32 for ; Thu, 13 Mar 2014 17:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IUrQnjAU7nAtdUkBDDjpxuewMeGp4C88kRrKV2MC2b8=; b=joHhXReFx/mNLHunOABw1A2oxxh8FP3oTFWZJy5Az7w51ECe0dcEpe365gWLLtyiIV IPRMHPcD8oLnn7Qwv4TzMKu9mlC+Ehg4/nOmKJKqCy42tl/R+IKWOlL4FU+7at3W1y52 lAtRrZhOUMvfHnDw3Yq6vYRiTkQz9FfqjYsY63phmwPgSyu48RZqqYJK42V6LQymT9kY nhbWJ0aBlCDP6aETxOlnCbv7YIUIqMw1+nABxP4pwkT8Mk0bjMQwOM4Byqblu7Mmvlyr Q8vdtW7ujTeHdi9AMANDxAquDqD78GFSIyy15IrVDaihmRIBOg6oO5pO3YQ2o/V0ncq6 OxgA== X-Received: by 10.140.44.69 with SMTP id f63mr6038195qga.31.1394757421683; Thu, 13 Mar 2014 17:37:01 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-71-184-209-46.bstnma.fios.verizon.net. [71.184.209.46]) by mx.google.com with ESMTPSA id 21sm1630248qgh.23.2014.03.13.17.37.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 17:37:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <5321B561.2030004@online.de> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170330 Archived-At: 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