From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 15 Feb 2015 13:09:25 -0600 Message-ID: <85y4nzat5m.fsf@stephe-leake.org> References: <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> <85egpsgf5z.fsf@stephe-leake.org> <83oaovull2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424027415 8025 80.91.229.3 (15 Feb 2015 19:10:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 19:10:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 20:10:04 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 1YN4Zu-0001Id-P7 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 20:10:03 +0100 Original-Received: from localhost ([::1]:36294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN4Zu-0008Mo-1r for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 14:10:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN4Zc-0008Ll-6J for emacs-devel@gnu.org; Sun, 15 Feb 2015 14:09:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN4ZW-00052V-LD for emacs-devel@gnu.org; Sun, 15 Feb 2015 14:09:44 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:42790) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1YN4ZW-00052Q-DY for emacs-devel@gnu.org; Sun, 15 Feb 2015 14:09:38 -0500 Original-Received: (qmail 7315 invoked by uid 0); 15 Feb 2015 19:09:34 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 15 Feb 2015 19:09:34 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id sj9V1p00K2UdiVW01j9Yax; Sun, 15 Feb 2015 12:09:34 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=TeMFXEv2S7AA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=jrwKn-8xaegA:10 a=0HtSIViG9nkA:10 a=mDV3o1hIAAAA:8 a=1iURHAM0ShalWOhWhMcA:9 Original-Received: from [70.94.38.149] (port=51844 helo=takver) by host114.hostmonster.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1YN4ZN-0001H7-52 for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:09:29 -0700 In-Reply-To: <83oaovull2.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 15 Feb 2015 19:32:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 70.94.38.149 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 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:183110 Archived-At: Eli Zaretskii writes: >> From: Stephen Leake >> Date: Sat, 14 Feb 2015 19:02:48 -0600 >> >> I took a stab at creating emacs_module_api.h; attached. >> >> To do this, I replaced "#include " >> in modules/curl/curl.c with "#include ", and copied >> stuff from lisp.h and other headers to emacs_module_api.h until it >> compiled. Note the FIXMEs; I could not figure out what was going on in >> some places, so I just kludged it for now. > > Thanks. > > I started to write comments to that file, but gave up in despair. My > overall conclusion from reviewing it is that, if we want the > tightly-coupled version of modules, we might as well compile them as > any other C source file in the Emacs tree, i.e. we could simply > include lisp.h in its entirety, and all the other headers that it > pulls in. I see no other workable alternative that would let modules > use Lisp objects transparently (as opposed to using them as opaque > objects), call Lisp primitives directly like we do in Emacs sources, > etc. I agree. >> > 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. > >> Good point. That's a special case of "don't load a module compiled for >> processor X in an Emacs compiled for processor Y". gnu binutils has >> facilities for that. > > Not sure how Binutils could help here. AFAIK, dlopen and dlsym (and > their equivalents) don't invoke Binutils on any platform. I was thinking Emacs could invoke some binutils function to query the .dll for this info, before calling dlopen. >> > 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? >> >> Similar check when the module is loaded. Which means we need some >> metainfo for each module, and a standard function to retrieve it. > > That "metainfo", whatever it will be, will also have to support > compilation of modules: we need to know at compile time what values of > USE_LSB_TAG, ENABLE_CHECKING, WIDE_EMACS_INT, optimization flags, > etc. were used when Emacs was built, because those affect the layout > of objects inside Emacs and also the availability of certain functions > in the Emacs binary. Right. One solution is to only distribute source, and provide an elisp function 'module-make' (suggested by Stefan) that provides command-line options to a module makefile for all of those settings. >> > . 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. >> >> If we follow Stefan's suggestion, then either this function approach is >> not viable, or we need another #ifdef for module vs emacs. > > If we don't use the function approach, we can only have modules that > are tightly coupled with the version of Emacs for which they were > written and compiled. We have no hope of binary compatibility with > other versions of Emacs, except by sheer luck, and even source-level > compatibility will be a challenge. Right. >> > 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. >> >> This is the model I had in mind. Since I need max speed with mixed >> Ada/lisp code, I need tight integration with the core. The people who >> need that speed for Ada mode will simply have to recompile the module >> for each Emacs release; they are coders, so that's not a problem. > > Being an Ada programmer (or even a C programmer) doesn't necessarily > mean you know how to fix compile- and link-time problems with Emacs. > You've just bumped into that yourself. Yes, and I'm becomming more sympathetic to your point of view :). > In practice, I think this means maintainers of modules will have to > adapt their modules to each Emacs version, and perhaps also keep > several branches, one each for every version they want to support. Yes, that was my plan. I do that now at the elisp level. >> Rather than splitting out emacs_module_api.h from lisp.h, we could add >> __declspec(dllexport) to a subset of the functions in lisp.h; I suspect >> that will be a small number. > > What for? Mostly just to get a confirmed list of the functions that curl.c currently calls. But I guess the link-time errors I started with is good enough for that. So let's take a stab at something closer to your approach. I'm not familiar with the idioms for making an opaque type in C; would that just be a pointer to void? something like: typedef void* Lisp_Object_Ptr; -- -- Stephe