From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Fri, 16 Jul 2010 21:43:13 +0300 Message-ID: <83bpa7feta.fsf@gnu.org> 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> <87wrsv8l6u.fsf@telefonica.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1279305852 4776 80.91.229.12 (16 Jul 2010 18:44:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 18:44:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 16 20:44:08 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 1OZptF-0005IE-Gk for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 20:44:05 +0200 Original-Received: from localhost ([127.0.0.1]:34781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZptE-0001lw-23 for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 14:44:04 -0400 Original-Received: from [140.186.70.92] (port=55718 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZpt8-0001kt-W9 for emacs-devel@gnu.org; Fri, 16 Jul 2010 14:44:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZpt7-0004eA-Ct for emacs-devel@gnu.org; Fri, 16 Jul 2010 14:43:58 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59113) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZpt7-0004e3-6L for emacs-devel@gnu.org; Fri, 16 Jul 2010 14:43:57 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L5N00000YMYNE00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 16 Jul 2010 21:43:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5N00LO0YO1R470@a-mtaout22.012.net.il>; Fri, 16 Jul 2010 21:43:14 +0300 (IDT) In-reply-to: <87wrsv8l6u.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:127452 Archived-At: > From: =C3=93scar Fuentes > Date: Fri, 16 Jul 2010 18:07:21 +0200 >=20 > > . 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. >=20 > For this I would try to isolate the display manager's memory manage= ment > 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 shoul= d > work. Right? How can a display engine has its memory management isolated, if it needs to call Lisp primitives to access Lisp objects and operate on them? Just a random example: when you bump into a buffer position that is covered by a text property or overlay, you need to call a function that returns that property's value, which requires a call such as prop =3D get_char_property_and_overlay (make_number (position->char= pos), =09=09=09=09=09Qdisplay, object, &overlay); The call to make_number here creates a Lisp object. get_char_property_and_overlay is one of the few basic APIs the displa= y engine calls to find what are the text properties at a specific buffe= r or string position. Rewriting it (and other similar APIs that the display engine needs to call to do its job) to somehow work around th= e need to create Lisp objects and pass them around will lead to a massive rewrite of most of Emacs, or at the very least to a large bod= y of code built on top of the current interfaces. I don't see how you can bypass this issue without getting your job much larger and harder, for no good reason. In my experience, C++ shines when you need to maintain software and want to be able to extend and refactor it without too much pain. It doesn't help you much when you start a new project from scratch. Since you are talking about a throw-away project, I don't really see any gains in C++; I do see a lot of obstacles that are in no way directly relevant to your undertaking, so overcoming those obstacles would be simply waste of time and effort. > A random thought now about something that intrigues me: AFAIK the o= nly > purpose of dumping is to include into Emacs' executable the set of > compiled Elisp code that is required to be usable. I think it was primarily for faster startup, but that's something we should ask Richard. > 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 tim= e > just a bit larger, the simplification on other areas would be > considerable. Doesn't the XEmacs "portable dumper" works like that? Anyway, dumping is the murkiest part of Emacs for me, and I try very hard to stay away of it. I'm happy enough that it works for me, and hope it will never break on the platforms that are important for me. I only know something about its perils because I was once involved in making a standard C library dump-compatible.