From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 03 May 2015 18:44:05 -0500 Message-ID: <85egmxmdkq.fsf@stephe-leake.org> 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 1430696687 21004 80.91.229.3 (3 May 2015 23:44:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 May 2015 23:44:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 04 01:44:36 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 1Yp3Yp-0005Mn-2r for ged-emacs-devel@m.gmane.org; Mon, 04 May 2015 01:44:35 +0200 Original-Received: from localhost ([::1]:60511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp3Yn-0001a0-Pm for ged-emacs-devel@m.gmane.org; Sun, 03 May 2015 19:44:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp3Yk-0001Zk-QI for emacs-devel@gnu.org; Sun, 03 May 2015 19:44:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yp3Yh-0003gs-Ko for emacs-devel@gnu.org; Sun, 03 May 2015 19:44:30 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:53321) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Yp3Yh-0003gg-Db for emacs-devel@gnu.org; Sun, 03 May 2015 19:44:27 -0400 Original-Received: (qmail 8249 invoked by uid 0); 3 May 2015 23:44:16 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 3 May 2015 23:44:16 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id Pbk61q00C2UdiVW01bk9xF; Sun, 03 May 2015 17:44:14 -0600 X-Authority-Analysis: v=2.1 cv=FPmImYYs c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=2wGvvwaKUHMA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=h1PgugrvaO0A:10 a=f11AndE4AAAA:8 a=cRbscTHpNPWS1tAEN0UA:9 Original-Received: from [76.218.37.33] (port=54079 helo=TAKVER) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Yp3YO-0001x5-CI for emacs-devel@gnu.org; Sun, 03 May 2015 17:44:08 -0600 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/24.4 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.33.93 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:186165 Archived-At: Ted Zlatanov writes: > On Wed, 22 Apr 2015 11:25:51 -0500 Stephen Leake wrote: > > SL> Ted Zlatanov writes: > > > 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. Perhaps we'll find it necessary later to give this > responsibility to some modules, but let's not do it now. That makes sense, but doesn't actually answer my question. Does the current funcall implementation handle GCPRO on the args adequately, or does it need to be improved/GCPRO added in the module? -- -- Stephe