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: Sun, 15 Feb 2015 19:34:16 +0200 Message-ID: <83lhjzulif.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> <834mqowbnh.fsf@gnu.org> <87oaovlebx.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1424021694 13365 80.91.229.3 (15 Feb 2015 17:34:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 17:34:54 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 18:34:41 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 1YN35b-00033i-F2 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 18:34:39 +0100 Original-Received: from localhost ([::1]:36102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN35a-0000W8-U0 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 12:34:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN35I-0000Vo-Ev for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:34:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN35D-0000fx-Gh for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:34:20 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:42825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN35D-0000fp-8A for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:34:15 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJT00900Q2N6S00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 15 Feb 2015 19:34:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJT008BOQ50YB70@a-mtaout20.012.net.il>; Sun, 15 Feb 2015 19:34:13 +0200 (IST) In-reply-to: <87oaovlebx.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:183097 Archived-At: > From: "Stephen J. Turnbull" > Cc: Stefan Monnier , > eggert@cs.ucla.edu, > emacs-devel@gnu.org > Date: Sun, 15 Feb 2015 18:21:54 +0900 > > > . 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. That won't support binary distributions of modules, would it? > > 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. Making a Lisp_Object opaque, one way or the other, is easy. Getting people to accept that it will be opaque is harder. I posted my suggestion to try to convince that this is the way to go, but I'm not holding my breath, frankly. > > . Functions to access values of Lisp objects. > > Not values, attributes. I don't think the difference matters for the purposes of this discussion. The intent is to allow extracting a C int from Emacs integer, a C double from a Lisp float, a C char array from a Lisp string, a pointer to buffer text for buffers, etc. > 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. I don't think modules will settle for using only the Lisp attributes, they would like access to C attributes as well. > > 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. ;-) I'm not holding my breath.