From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 03 May 2015 20:16:03 -0400 Message-ID: References: <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.org> <54E382A5.5030408@dancol.org> <54F789B2.6030105@dancol.org> <87egnel6ac.fsf@lifelogs.com> <87vbgpk1po.fsf@lifelogs.com> <85mw20gmeo.fsf@stephe-leake.org> <871tiy9bhy.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430698582 14135 80.91.229.3 (4 May 2015 00:16:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 May 2015 00:16:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 04 02:16:15 2015 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 1Yp43Q-0008LM-7F for ged-emacs-devel@m.gmane.org; Mon, 04 May 2015 02:16:12 +0200 Original-Received: from localhost ([::1]:60543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp43P-00054n-JB for ged-emacs-devel@m.gmane.org; Sun, 03 May 2015 20:16:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp43M-00054g-OG for emacs-devel@gnu.org; Sun, 03 May 2015 20:16:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yp43I-0003Wi-Hu for emacs-devel@gnu.org; Sun, 03 May 2015 20:16:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp43I-0003We-EW for emacs-devel@gnu.org; Sun, 03 May 2015 20:16:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVjMLNBIUGA2IN6IRi3sBAQcCBgxYA4M+AwNPgx4Eo2OEWA X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVjMLNBIUGA2IN6IRi3sBAQcCBgxYA4M+AwNPgx4Eo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="118160175" Original-Received: from 69-165-139-108.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2015 20:16:04 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DC5CEAE12D; Sun, 3 May 2015 20:16:03 -0400 (EDT) In-Reply-To: <871tiy9bhy.fsf@lifelogs.com> (Ted Zlatanov's message of "Sun, 03 May 2015 06:55:05 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:186167 Archived-At: >>> I would go simple for now: always make a copy of the string using UTF-8 >>> encoding in the args, assuming that the majority of C modules can deal >>> with it, and we can stop worrying about string sharing and encoding for >>> now (we can revisit them later). We should free the copy right after >>> calling so the module doesn't have to free it. I don't like this idea of making copies just to avoid memory management. Especially since we already have a GC available to solve this problem. But I missed the context, so I don't really know what I'm talking about. SL> We also need to document the GCPRO issues; > ... SL> should the module do GCPRO around the funcall, or does the funcall SL> handle that? > IMHO Emacs should manage memory, period. Any time modules are given that > responsibility, it's an opportunity for bugs and a premature > optimization. It's an illusion to think that all memory management can be moved to the Emacs side. But I think the best way to move most of it to the Emacs side is to let the modules benefit from the Emacs's GC, and hence export the "GC protocol" to the modules side. As mentioned elsewhere, we probably want to skip the GCPRO part of the protocol (and hence only support dynamic loading on those platforms where we use conservative stack scanning), so as to move even more of the memory management onto the Emacs's side. SL> Also, we need to do something about the doc strings for lisp objects SL> declared in modules. I don't think they need to be available before the SL> module is loaded; if a particular author wants that, they can define an SL> elisp wrapper with autoloads. Agreed. The same holds for .el files. The only difference is that for .el files we have autoload.el which can auto-generate the "wrapper with autoloads". Maybe we could create a similar system for dynloaded packages, but there's no hurry for it. Stefan