From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Fri, 16 Jul 2010 18:07:21 +0200 Message-ID: <87wrsv8l6u.fsf@telefonica.net> References: <87sk3lbvv0.fsf@telefonica.net> <83hbk1grnq.fsf@gnu.org> <4C3EBCDC.8050709@swipnet.se> <83d3upgmwj.fsf@gnu.org> <4C3ECB4C.6050208@swipnet.se> <83aaptgly1.fsf@gnu.org> <4C3ED4F9.4080603@swipnet.se> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <877hkwbth6.fsf@telefonica.net> <83pqyofzdg.fsf@gnu.org> <8739vkbpq5.fsf@telefonica.net> <83oce8fwlq.fsf@gnu.org> <87tyo0a11p.fsf@telefonica.net> <83k4ovg7rn.fsf@gnu.org> <87630fa4j8.fsf@telefonica.net> <83d3unfo92.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279297758 9077 80.91.229.12 (16 Jul 2010 16:29:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 16:29:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 16 18:29:17 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZnmi-0003rb-Vn for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 18:29:17 +0200 Original-Received: from localhost ([127.0.0.1]:47835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZnWo-0004YE-RC for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 12:12:46 -0400 Original-Received: from [140.186.70.92] (port=47835 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZnSi-00039N-O4 for emacs-devel@gnu.org; Fri, 16 Jul 2010 12:08:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZnRj-0002p3-T0 for emacs-devel@gnu.org; Fri, 16 Jul 2010 12:07:34 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:41419) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZnRj-0002op-EI for emacs-devel@gnu.org; Fri, 16 Jul 2010 12:07:31 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZnRi-0002uz-1n for emacs-devel@gnu.org; Fri, 16 Jul 2010 18:07:30 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2010 18:07:30 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Jul 2010 18:07:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:4SfvWgjgS7P10NKKTEtrWX4hNSU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127441 Archived-At: Eli Zaretskii writes: >> > I meant link-time and run-time compatibility, not syntactic >> > compatibility. >> >> I use C code on my C++ projects all the time, without those issues. Why >> Emacs should be different? > > Because Emacs uses some techniques that a rare C program does. I > mentioned some of them in another thread. Here's a recap: > > . The "relocatable allocator" which moves memory of allocated > objects (such as the buffer text) when large chunks of memory are > allocated or freed. Also, allocation of memory off the pure > space, during the build process. These will probably need a > custom new/delete implementations, and various C++ techniques such > as smart pointers may need to be adjusted, or not used. For this I would try to isolate the display manager's memory management from the rest of Emacs. As far as the display manager doesn't need to allocate or free objects created by Emacs, and vice-versa, it should work. Right? > . The dump and restart process: it's possible that various C++ > features such as static constructors will ``need some work'' to > survive these atrocities. That might need hacking the libraries > you use, if you have the sources. Good one. I can go without using static/global constructors, but dunno about Qt. There are other potential issues with that: vtables, RTTI... Thanks for the remarks. A random thought now about something that intrigues me: AFAIK the only purpose of dumping is to include into Emacs' executable the set of compiled Elisp code that is required to be usable. I guess that the approach made sense when distributing Emacs as a single executable could be useful. But now hardly anyone installs Emacs without the extensive Elisp library and other auxiliary files, so the "self-contained functional Emacs executable" has little value. Of course I may be wrong when guessing this, but if it is right, wouldn't make more sense to dump all that Elisp bytecode to a single file that is loaded on startup? On exchange of a startup time just a bit larger, the simplification on other areas would be considerable. [snip]