From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 15 Feb 2015 18:21:54 +0900 Message-ID: <87oaovlebx.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <834mqowbnh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423992157 28175 80.91.229.3 (15 Feb 2015 09:22:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 09:22:37 +0000 (UTC) Cc: eggert@cs.ucla.edu, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 10:22:28 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 1YMvPF-0001mi-2C for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 10:22:25 +0100 Original-Received: from localhost ([::1]:33964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMvPE-0006Gl-5u for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 04:22:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMvOx-0006Fh-T1 for emacs-devel@gnu.org; Sun, 15 Feb 2015 04:22:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMvOs-0001Az-W0 for emacs-devel@gnu.org; Sun, 15 Feb 2015 04:22:07 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:42585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMvOn-0001AA-Hj; Sun, 15 Feb 2015 04:21:57 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BE29C1C38A0; Sun, 15 Feb 2015 18:21:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9C44F1A26E3; Sun, 15 Feb 2015 18:21:54 +0900 (JST) In-Reply-To: <834mqowbnh.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:183083 Archived-At: Eli Zaretskii writes: > It looks like modules need: > > . A function to replace the DEFUN macro and the related defsubr call. Aha, so you already figured this out for yourself. > . 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? XEmacs builds a separate compiler driver ellcc that knows how to build modules of the same configuration. > 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. I don't know how you identify type of objects, but since you only have a couple of tag bits left, I have to assume you use a header word of some kind. In XEmacs the header word is a pointer to a table of functions that define the common functionality of Lisp objects used by the interpreter and the virtual machines. Whether a method table pointer or an enum, that header word is pretty much the only thing that's going to be common to all types. Seems to me that's pretty close to opaque already. > . Functions to access values of Lisp objects. Not values, attributes. You don't want to just unbox the Lisp object and give modules access to internals. Rather, each object type should export a specific API in the form of accessors and mutators for its Lisp-visible attributes. This is what XEmacs already does, it's what Python does, and it's those two examples that give me the confidence that it will work for Emacs too. Sounds like it will be a pile of work, but you don't have to convert all types immediately. > . 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. `intern' *is* the creation function for symbols. Uninterned symbols are hardly useful for modules; they already have a private namespace. > . 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. Sounds like a good idea to me. Wouldn't hurt if you rewrote most of the C source under src/ that way too. ;-)