From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Mon, 1 Dec 2014 17:28:01 +0100 Message-ID: References: <87k32sh50f.fsf@lifelogs.com> <85tx1rg64e.fsf_-_@stephe-leake.org> <87siha7r3b.fsf@lifelogs.com> <87lhmz4mtj.fsf@lifelogs.com> <87sih575rc.fsf@lifelogs.com> <8361dyaqf1.fsf@gnu.org> <837fycae5p.fsf@gnu.org> <87y4qs19mi.fsf@lifelogs.com> <874mtfu0et.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 1417451295 21485 80.91.229.3 (1 Dec 2014 16:28:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 16:28:15 +0000 (UTC) To: Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 17:28:09 2014 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 1XvTpY-0002sv-Gy for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 17:28:08 +0100 Original-Received: from localhost ([::1]:60780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTpY-0001m2-2j for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 11:28:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTpT-0001kU-Sh for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:28:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvTpS-0006tB-Qj for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:28:03 -0500 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:43327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTpS-0006sT-Hq for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:28:02 -0500 Original-Received: by mail-la0-f53.google.com with SMTP id gm9so8869121lab.40 for ; Mon, 01 Dec 2014 08:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=rZvNhg4XolHjhodMi1p1jbDqKjGElWBqjY2jYFhKe2s=; b=KmcwGuJ3HALGb5gcEHvgisaLw2/WTbeRcM9uOcGQ5TOnkmj4Twg82vSmIqJABUHf9u Mfb3KRqqWSDSsA3PJqijyAsDwnCRQa5VBWHm/pNQwQL0ZyeaPi4bUwTtA6aZwBpBLrjk weymPUoug+cU/8xHPwmGS7f4yXlIU80i+c64qknBrji1eGiXqMZ/Thq8V7tYjMJZUdCi xSPeArvrsorChX5n/O+qROG7bbcJYeNnChTZ5eHsLzGB8PLrav7+9q1DqkHGU0WwOrFT DaEXpVbFToCDNrxfWEQX+plkwQztQZzBrVKzEdV+opYrqmbgjCiSSILNJyCdmIY0JgBn WuqA== X-Received: by 10.152.121.1 with SMTP id lg1mr56863655lab.28.1417451281726; Mon, 01 Dec 2014 08:28:01 -0800 (PST) Original-Received: by 10.114.77.131 with HTTP; Mon, 1 Dec 2014 08:28:01 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: ukNxrMUG2YtJOwVR7Kbfxgg_XTA X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:178591 Archived-At: Stefan's 3 part plan is sound. I agree that using any Emacs function in modules is too fragile and we need to define a subset or a new layer to expose Emacs features to modules. On Mon, Dec 1, 2014 at 4:36 PM, Ted Zlatanov wrote: > On Mon, 01 Dec 2014 10:04:34 -0500 Stefan Monnier wrote: > > SM> By "API" I meant something like a .h file which modules can include t= o > SM> define the functions and datatypes that they can use. I.e. by API > SM> I mean those things that the module code can do, rather than the thin= gs > SM> that Emacs code can do with modules. > > By API I meant both directions, the module API for registration and > metadata, and the Emacs API that modules can use. So I still think a > call-only API (only in the direction of calling the module) is best for > now, so that .h file is unnecessary. In order to do anything useful (even in a "call-only" API) you need access to Emacs facilities. At the very least access to Elisp data structures (symbols, numbers, strings and buffers). The point of compiled modules is also efficiency so the access has to be low level enough (no big conversion or copying needed). > I agree with the rest of your comments, except that it's not clear when > you'll feel that the module loading is settled enough to merge into the > master branch. I think the module metadata should be formalized, at > least, so it can be obtained before loading the module. Aur=C3=A9lien, i= s > that possible? And do you have any comments? Apart from the the new module/opaque type I'd like to add, the way I see it the branch can already be merged and used as a very experimental new feature. Writing the yaml module was a good exercise. We need people to try writing modules and see what they end up using/needing in order to choose what we should keep in the API. For me a module package will be composed of a metadata file, a bunch of C files implementing small and simple primitives and a bunch of elisp files for the logic.