From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sat, 14 Feb 2015 21:12:02 +0200 Message-ID: <834mqowbnh.fsf@gnu.org> References: <85k31coixa.fsf@stephe-leake.org> <85oapy5kt6.fsf@stephe-leake.org> <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <54D80098.3020209@cs.ucla.edu> <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423941142 450 80.91.229.3 (14 Feb 2015 19:12:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 19:12:22 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 14 20:12:13 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 1YMi8T-0003i3-A8 for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 20:12:13 +0100 Original-Received: from localhost ([::1]:60899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMi8S-0007oI-14 for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 14:12:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMi8O-0007oD-G0 for emacs-devel@gnu.org; Sat, 14 Feb 2015 14:12:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMi8J-0000so-K3 for emacs-devel@gnu.org; Sat, 14 Feb 2015 14:12:08 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:44573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMi8J-0000sX-Bd for emacs-devel@gnu.org; Sat, 14 Feb 2015 14:12:03 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NJR00A00ZZYFP00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 14 Feb 2015 21:12:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJS00ASI0018G90@a-mtaout21.012.net.il>; Sat, 14 Feb 2015 21:12:01 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:183071 Archived-At: > From: Stefan Monnier > Date: Fri, 13 Feb 2015 14:11:33 -0500 > Cc: Paul Eggert , emacs-devel@gnu.org > > > I would start by coming up with the minimum set of requirements a > > module needs to be able to communicate with Emacs. > > Easy: take the existing sample modules and see what they need. No one seems to care, so I will bite the bullet. The below is based on looking at the modules branch. It looks like modules need: . A function to replace the DEFUN macro and the related defsubr call. . Some definition of Lisp_Object This already presents at least 2 problems. The first is 32- vs 64-bit issues. We need some way of checking that a 32-bit module isn't loaded by a 64-bit Emacs, and vice versa. The other problem is more serious: Emacs can be built with or without --check-lisp-object-type, and with or without --wide-int; how will the module know which implementation to use? Perhaps the solution is to make Lisp_Object an opaque data type for the modules, and not use the definition we have on lisp.h. . Functions to access values of Lisp objects. We shouldn't rely on C macros like XINT and XWINDOW for that, because macros track too closely the internals of each object. So I propose to use functions that will be exposed via the API. . Functions to create Lisp objects and/or set their values. Again, we shouldn't rely on the likes of XSETCONS. There should be a function make_FOO for each object type FOO. This includes creating symbols, so 'intern' should not be needed by modules. . A function to create a Lisp object that is a container for a C struct or pointer. The above means that most of the C source files under modules/ should be thoroughly rewritten. They are currently written as if the code were an integral part of Emacs on one of the Emacs C files. Going that way means that modules will have to be recompiled from sources for each Emacs version, and practically will have to live in the Emacs tree. Maybe this is what we want, I don't know.