From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 27 Sep 2015 23:01:02 -0400 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 X-Trace: ger.gmane.org 1443409351 23139 80.91.229.3 (28 Sep 2015 03:02:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 03:02:31 +0000 (UTC) Cc: Daniel Colascione , Emacs development discussions , Philipp Stephani , Paul Eggert , Tom Tromey , Stephen Leake To: =?windows-1252?Q?Aur=E9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 05:02:22 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 1ZgOhp-0001YL-Hg for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 05:02:21 +0200 Original-Received: from localhost ([::1]:60043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgOho-0000u8-S0 for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2015 23:02:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgOhd-0000u0-63 for emacs-devel@gnu.org; Sun, 27 Sep 2015 23:02:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgOhY-0000Lz-73 for emacs-devel@gnu.org; Sun, 27 Sep 2015 23:02:09 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgOhY-0000Lm-0f for emacs-devel@gnu.org; Sun, 27 Sep 2015 23:02:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtCwA731xV/2yixEVcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQEGAgEfijiBAoUFB4QtBbM/gUUjgWaCLiKCeAEBAQ X-IPAS-Result: A0CtCwA731xV/2yixEVcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQEGAgEfijiBAoUFB4QtBbM/gUUjgWaCLiKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="165998969" Original-Received: from 69-196-162-108.dsl.teksavvy.com (HELO pastel.home) ([69.196.162.108]) by ironport2-out.teksavvy.com with ESMTP; 27 Sep 2015 23:01:02 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4F4A162239; Sun, 27 Sep 2015 23:01:02 -0400 (EDT) In-Reply-To: (=?windows-1252?Q?=22Aur=E9lien?= Aptel"'s message of "Sat, 26 Sep 2015 16:56:59 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:190424 Archived-At: > I've implemented signal() What means "implemented signal()"? You mean, you export Fsignal to the modules? > 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? How does this relate to whether or not "funcall() returns to module code on error right now"? What means "returns to module code"? Do you provide "cdr"? 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). > * pick a new syntax and teach make-docfile how to parse it. This is > the clean approach IMO, but it requires more work. We can use a > sufficiently simple syntax so that it can be embedded in comments in > other languages than C. > * define DEFVAR/DEFUN macro in module API header file to a noop so > that make-docfile can parse it as it is. 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? > Or we can have a full "method table" with printer function and other > things we might need in the future. Although It's a bit overkill with > just finalizer/printer... 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 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). Stefan