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: Wed, 22 Apr 2015 11:25:51 -0500 Message-ID: <85mw20gmeo.fsf@stephe-leake.org> References: <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1429719996 8178 80.91.229.3 (22 Apr 2015 16:26:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Apr 2015 16:26:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 22 18:26:27 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 1YkxTl-0003HJ-Ur for ged-emacs-devel@m.gmane.org; Wed, 22 Apr 2015 18:26:26 +0200 Original-Received: from localhost ([::1]:36075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkxTl-0000Tq-8W for ged-emacs-devel@m.gmane.org; Wed, 22 Apr 2015 12:26:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkxTh-0000Tj-M0 for emacs-devel@gnu.org; Wed, 22 Apr 2015 12:26:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkxTb-00022i-EY for emacs-devel@gnu.org; Wed, 22 Apr 2015 12:26:21 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:36591) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1YkxTb-00022T-7X for emacs-devel@gnu.org; Wed, 22 Apr 2015 12:26:15 -0400 Original-Received: (qmail 6526 invoked by uid 0); 22 Apr 2015 16:26:10 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Apr 2015 16:26:10 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id K4S51q00R2UdiVW014S85l; Wed, 22 Apr 2015 10:26:10 -0600 X-Authority-Analysis: v=2.1 cv=Avp9goNP c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=2wGvvwaKUHMA:10 a=IkcTkHD0fZMA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=e9J7MTPGsLIA:10 a=f11AndE4AAAA:8 a=pGLkceISAAAA:8 a=NEAV23lmAAAA:8 a=D2CkWZDrX73n_WPJDBsA:9 a=QEXdDO2ut3YA:10 Original-Received: from [76.218.37.33] (port=50026 helo=TAKVER) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1YkxTQ-0005HC-SI for emacs-devel@gnu.org; Wed, 22 Apr 2015 10:26:05 -0600 In-Reply-To: <87vbgpk1po.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 21 Apr 2015 10:14:43 -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: 69.89.18.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:185783 Archived-At: Ted Zlatanov writes: > On Tue, 21 Apr 2015 10:58:06 +0200 Aur=C3=A9lien Aptel wrote:=20 > > AA> On Tue, Apr 21, 2015 at 1:38 AM, Ted Zlatanov wrot= e: >>> I like it. Can you provide a simple example in the branch of how it >>> would be used from both sides? I can restart the testing and keep it in >>> sync with the Emacs repo again. > > AA> It's already in there: > > AA> https://github.com/aaptel/emacs-dynamic-module/tree/dynamic-modules-2= /modules/basic > > Right! > > As far as the coding style and barriers this enforces, I think it's just > right. Thanks to you and Dan Colascione and the others for working on > it. +1 > As far as capabilities, the basic module should have a string exchange, > as you've started to implement in `copy_string_contents' > and `make_string'. I think it's impossible to move forward without > that. For my parser module, I plan on calling the elisp lexer currently in ada-mode (which uses the sytax class information, forward-sexp, etc). That avoids copying the entire buffer text to the module, or dealing with direct access. I haven't got it working yet, so I'm not entirely sure that will be fast enough, but the lexer is a small portion of the full parser. > 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'm not clear who is freeing what here; the module API does need to document that clearly. We also need to document the GCPRO issues; for example, given the following call: emacs_value pairs[] =3D { env->make_fixnum (env, 1), ada_grammar_names[341], /* statement-start= */ env->make_fixnum (env, 2), ada_grammar_names[342], /* statement-other= */ env->make_fixnum (env, 4), ada_grammar_names[343] /* statement-end */ }; emacs_value args_2[] =3D { env->funcall (env, vector, 6, pairs) }; env->funcall (env, wisi_statement_action, 1, args_2); where 'wisi_statement_action' is an elisp function that uses 'pairs' to set text properties, should the module do GCPRO around the funcall, or does the funcall handle that? Also, we need to do something about the doc strings for lisp objects declared in modules. I don't think they need to be available before the module is loaded; if a particular author wants that, they can define an elisp wrapper with autoloads. At a minimum, default doc string should be provided that gives a pointer to the module source code. > I think `plugin_is_GPL_compatible' should be a float indicating the GPL > version. Maybe even a char[] to express flavors, from a constrained set > of choices. +1 for the char[]. The variable could be named 'license_terms', so it could be used by non-GPL in special circumstances. --=20 -- Stephe