From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 04 May 2015 06:09:45 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87sibc8xhy.fsf@lifelogs.com> References: <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> <85egmxmdkq.fsf@stephe-leake.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1430734193 11447 80.91.229.3 (4 May 2015 10:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 May 2015 10:09:53 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 04 12:09:48 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 1YpDJq-0007ML-Dg for ged-emacs-devel@m.gmane.org; Mon, 04 May 2015 12:09:46 +0200 Original-Received: from localhost ([::1]:33478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpDJp-0002fS-MH for ged-emacs-devel@m.gmane.org; Mon, 04 May 2015 06:09:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpDJl-0002fK-So for emacs-devel@gnu.org; Mon, 04 May 2015 06:09:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpDJi-0003m2-Cn for emacs-devel@gnu.org; Mon, 04 May 2015 06:09:41 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpDJi-0003lw-6e for emacs-devel@gnu.org; Mon, 04 May 2015 06:09:38 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YpDJf-0007Gg-Ay for emacs-devel@gnu.org; Mon, 04 May 2015 12:09:35 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 May 2015 12:09:35 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 May 2015 12:09:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 31 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:b3QwQtdcoplzc7+AZa56mgqxj1Y= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:186176 Archived-At: On Sun, 03 May 2015 18:44:05 -0500 Stephen Leake wrote: SL> 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. SL> That makes sense, but doesn't actually answer my question. SL> Does the current funcall implementation handle GCPRO on the args SL> adequately, or does it need to be improved/GCPRO added in the module? (You mean the module-side funcall, right? Not the one built in Emacs?) Looking at it, it appears to only pass atomic data types that don't need GC protection right now, so the implementation for passing strings is not done. But I'd love to get some comments from Aurélien, he must have plans and ideas. Ted