From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: About CEDET, Completion, and compilers Date: Fri, 14 Mar 2014 07:47:25 +0100 Message-ID: <5322A5FD.6030304@online.de> References: <53212048.70901@siege-engine.com> <5321B561.2030004@online.de> <53224F2B.3070600@siege-engine.com> 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 1394779388 3291 80.91.229.3 (14 Mar 2014 06:43:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 06:43:08 +0000 (UTC) Cc: "Eric M. Ludlam" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 07:43:14 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 1WOLpq-0005Jb-2c for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 07:43:14 +0100 Original-Received: from localhost ([::1]:43160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOLpp-0004JU-N3 for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 02:43:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOLph-0004JM-Pw for emacs-devel@gnu.org; Fri, 14 Mar 2014 02:43:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOLpb-00008l-QB for emacs-devel@gnu.org; Fri, 14 Mar 2014 02:43:05 -0400 Original-Received: from moutng.kundenserver.de ([212.227.17.24]:57558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOLpb-00008a-GM for emacs-devel@gnu.org; Fri, 14 Mar 2014 02:42:59 -0400 Original-Received: from purzel.sitgens (brln-4d0c2e7c.pool.mediaWays.net [77.12.46.124]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MWis7-1WdXQI0iFf-00XsV3; Fri, 14 Mar 2014 07:42:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <53224F2B.3070600@siege-engine.com> X-Provags-ID: V02:K0:IQwFIof8k0rwe4pv8SKc9Bllo0u3FHch69vpBAdcVC0 vhdsVuobYS3qIutn6Y4MifxZgvMkeukVjE6y3yyBQCmLcslZM2 9CL1tcpZcHGwlIOKM9SwPEw4QWW/8b6ANGj8iaNMbV1L+3mWD+ XQQBGyJAW2NWQKkwcEV7oV92tyugVGYJhUqkCdI8ISC2qKO2TK O5WUk0Ga7+kHQotxL5PPOpa0S3Xw0saAi5Anw+U48gH5cyKD/I WLOnAyCQOQdBiGX6Ya4+jT2pIStcl/S1zbz0byqjDm9E4mBFHX US/Bw3WxzP27dBo7GcDFCd0uedR35SgZLDv2feF1pj6M3qmJey fQebptGfr/0gLxbfEkLE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.24 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:170338 Archived-At: 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