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: Dynamic loading progress Date: Mon, 28 Sep 2015 12:13:25 +0200 Message-ID: References: <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <55F70C4E.8030805@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1443453274 15712 80.91.229.3 (28 Sep 2015 15:14:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 15:14:34 +0000 (UTC) Cc: Daniel Colascione , Emacs development discussions , Philipp Stephani , Paul Eggert , Tom Tromey , Stephen Leake To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 17:14:33 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 1Zga8L-0006fc-ED for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 17:14:29 +0200 Original-Received: from localhost ([::1]:37812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zga8L-00037e-1O for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 11:14:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgVR2-0002sX-8l for emacs-devel@gnu.org; Mon, 28 Sep 2015 06:13:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgVR0-0001GJ-Rs for emacs-devel@gnu.org; Mon, 28 Sep 2015 06:13:28 -0400 Original-Received: from mail-ig0-x230.google.com ([2607:f8b0:4001:c05::230]:36104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgVR0-0001Fr-MR for emacs-devel@gnu.org; Mon, 28 Sep 2015 06:13:26 -0400 Original-Received: by igcrk20 with SMTP id rk20so49502906igc.1 for ; Mon, 28 Sep 2015 03:13:26 -0700 (PDT) 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:cc:content-type; bh=/Cjgfjbj4HSqjGVPTIKvMAItc4jM1zQLWE9blSwk1SU=; b=Dr2INIozb05igHNNiufj6sVEMf2As92wjGFPGE7s5egXq6VzP7tZicSWpct+r4VCSr NOEfyZuhDY/QJLbtPQcwioicSJu/7G/DeTvUhTt5EB2mCLo1g/QFbHdZ2f5AFb1umB/i RbvGuQyNMR35EqkqG+MdKkbOejB6TCxufnD++o0314o2QgrJLw0i0ct633U2VYLPR1a5 PXlCqx/lOUdvxrVyyk3jVjSBmNEnqw1hpG9rfR53QvAYu9tS3Va2xz8BKOnxh33BV2lJ 3UiPoTPhY9Tx71v1/6RUc7rn8aMrGKZwd80F10BkaWJ8d6mqKdnXADhrY8DaeLOH4PN8 6p3w== X-Received: by 10.50.20.38 with SMTP id k6mr7997834ige.57.1443435205990; Mon, 28 Sep 2015 03:13:25 -0700 (PDT) Original-Received: by 10.36.146.193 with HTTP; Mon, 28 Sep 2015 03:13:25 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: e6snCHcv0QM84haWP2uQwvDBW_4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::230 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:190438 Archived-At: I wrote what we agreed on... On Mon, Sep 28, 2015 at 5:01 AM, Stefan Monnier wrote: > What means "implemented signal()"? You mean, you export Fsignal to > the modules? yes >> Except for signal() all error related functions are unimplemented >> (they are not useful because funcall() doesn't return to module code >> on error right now). > > I'm not sure what that means. What other error-related functions? Look at error_* function in the API (src/emacs_module.h [1]). error_get() lets you get the signal symbol & data. error_check() simply tells you if there was an error and error_clear() clears current error. They will be implemented once we have a safe funcall. The safe funcall() will have a catch-all condition-case and will set a global error state than will be accessible via the API. (Daniel's design) > on error right now"? What means "returns to module code"? "Returns to module code" means when a function (funcall in this case) exits normally via return (no longjmp). Since funcall() is called by modules, when it returns it returns to module code. Hence "returns to module code". > Do you provide "cdr"? no, not directly. You have to intern "cdr" and call funcall(). > If so, what does it do when a module calls it on > a string object? I'd expect it to signal the error and longjmp to the > nearest condition-case that catches it (presumably from outside of the > module code, unless the module code setup condition_case as well). Correct. condition-case is not part of the API though. Like for cdr you have to intern "condition-case", setup the lisp forms as arguments yourself and funcall() it. Haven't tested it yet. > You're talking about how to get docstrings from the source code, but > I think we should expect Emacs to need/fetch them during "load" at which > point we'll be looking at the compiled code. So the first question is > where should those docstrings (regardless of whether they were found and > prepared by make-docfile or by some new tool) be located? Inside the > .so file? Is the source code which should be placed nearby? In some > kind of separate DOC file? Like with my old module branch, I was thinking of having multiple DOC files. When a module is built a DOC file is also generated from the source of the module. When a module is loaded it looks for the module DOC file and uses it. This involves changing the doc field of a symbol from int to Lisp_Object that stores ("path/to/doc" . POSITION), iirc. See previous discussions we had on this. We can always do things differently, its not too late. The pro of docfile is that you can also store the position of the definition in the source code, which is always helpful. > Even without a printer function, I think it makes sense at least to > provide some kind of "type" information so that it's obvious when two > "user objects" are "of the same type". The method table can play the > role of a "type". > > Also, it might make sense to let Emacs build this "method table" object. > So instead of exposing an emacs_user_ptr_ops structure, export > a function which creates a pointer to such an object. This way the > actual emacs_user_ptr_ops structure can more easily evolve, and Emacs > can more easily fill the various slots with default values where Good idea. > applicable (e.g. one slot might point to the module that owns the object > and might better be filled by the Emacs core than by the module itself). Currently each instance of the emacs_env (the struct that holds function pointers to the API that is created upon request from modules) has a unique id used for module identification. That way the module API implementation can know which module is using each API function. 1: https://github.com/aaptel/emacs-dynamic-module/blob/dynamic-modules-2/src/emacs_module.h