From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Thu, 15 Oct 2015 01:05:40 +0000 Message-ID: References: <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> <561ED963.4050207@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134c69ca4d73805221a47df X-Trace: ger.gmane.org 1444871220 13980 80.91.229.3 (15 Oct 2015 01:07:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 01:07:00 +0000 (UTC) Cc: Eli Zaretskii , Stephen Leake , Emacs development discussions To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 15 03:06:55 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 1ZmX0Q-0000Kn-FP for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 03:06:54 +0200 Original-Received: from localhost ([::1]:45252 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmX0Q-0004qA-1d for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 21:06:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmWzS-0004oD-1g for emacs-devel@gnu.org; Wed, 14 Oct 2015 21:05:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmWzQ-0004Hi-RT for emacs-devel@gnu.org; Wed, 14 Oct 2015 21:05:53 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:38512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmWzO-0004HB-Km; Wed, 14 Oct 2015 21:05:50 -0400 Original-Received: by wieq12 with SMTP id q12so108354689wie.1; Wed, 14 Oct 2015 18:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=3ZGfc15Fd8pVi7lM5kSfQUDZMOYAB+Jeeaxt21vKhzY=; b=kYmn39VT9eGF1nTVL41wR+P+yhNBiJGI2YrPl8X2FMhuwZHigRAuTnJgD9X+LnTqWo 6ic8qPXvjLQOBtl1mrHktgf2k3TGty7B5CAs660m5eamcSKZUV6F1SkRqBLQQDziGBVQ CmuTkO7CXyWL7dkuuW2FVenIoNeau5XctEP2NWm1jaQovsiVdZ3zR4RvEVXWxGT3BHdJ CdKDf0ERgHkvV/m9QAX2iLqexXp3QoHSIoOJXEJVhkPcId2JwIPJBdoPy1SXDoZImzKQ 3hUVxibYPU8sxsIWx1vhCMZh6CxK4BFXRHOS7uTMmNSW8U044tbI3nDoSC6/ioMCiwrW 93sw== X-Received: by 10.180.216.36 with SMTP id on4mr7611918wic.65.1444871150030; Wed, 14 Oct 2015 18:05:50 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b 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:191605 Archived-At: --001a1134c69ca4d73805221a47df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am Do., 15. Ok= t. 2015 um 01:32 Uhr: > Your approach is interesting but it currently works as-is for 64bits > platforms and 32bits platform without wide-int and can be fixed later > without breaking the API, if I understand correctly. > I would be more worried about representation of nullptr. With casting nullptr can stand for a valid Lisp value, so that it's not possible to return invalid values, which is visible to the user. > * Loading > > I know that on OSX there's both ".dyn" and ".so" but I don't know much > about it. Is supporting both worth it? > According to http://stackoverflow.com/a/2339910/178761 there are two types: bundles and dynamic libraries. The differences were bigger in the past (only bundles could be loaded dynamically), but now they are mostly equivalent. Apparently .so and .bundle are usually used for bundles and .dylib for dynamic libraries, but e.g. your example modules compile as dynamic libraries with an .so extension and Emacs is totally happy. So supporting .so should be enough. > > Couldn't we simply pick an extension like ".edm" (emacs dynamic > module) and rename the generated lib on each system when a module is > built? > I'd prefer using the conventional extensions. A custom extension might confuse users and clash with existing meanings of that extension. > > * Doc strings > > If we use the doxygen syntax, it won't follow the various elisp > conventions (args in caps, first line must be descriptive, etc). > Jumping to definition is also pretty convenient, should we keep that > feature for modules? Also how should we load the docstrings > themselves? > > Can't modules already run the equivalent of (put 'module-func 'function-documentation "docstring") ? With that the basics should already be there. > * Packaging > > We need to extend the spec of ELisp packages to take into account > modules. The way I see it a module will have a "core" source file in C > (or something else) and a bunch of helpers implemented in elisp on top > that expose the package features in a more user-friendly way. > That is one option, but modules consisting entirely of non-Elisp files are also to be expected, given that the module API is as powerful as Elisp. --001a1134c69ca4d73805221a47df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Aur=C3= =A9lien Aptel <aurel= ien.aptel+emacs@gmail.com> schrieb am Do., 15. Okt. 2015 um 01:32=C2= =A0Uhr:
Your approach is interestin= g but it currently works as-is for 64bits
platforms and 32bits platform without wide-int and can be fixed later
without breaking the API, if I understand correctly.
<= br>
I would be more worried about representation of nullptr. With= casting nullptr can stand for a valid Lisp value, so that it's not pos= sible to return invalid values, which is visible to the user.
=C2= =A0
* Loading

I know that on OSX there's both ".dyn" and ".so"= ; but I don't know much
about it. Is supporting both worth it?

= According to=C2=A0htt= p://stackoverflow.com/a/2339910/178761=C2=A0there are two types: bundle= s and dynamic libraries. The differences were bigger in the past (only bund= les could be loaded dynamically), but now they are mostly equivalent. Appar= ently .so and .bundle are usually used for bundles and .dylib for dynamic l= ibraries, but e.g. your example modules compile as dynamic libraries with a= n .so extension and Emacs is totally happy. So supporting .so should be eno= ugh.
=C2=A0

Couldn't we simply pick an extension like ".edm" (emacs dynam= ic
module) and rename the generated lib on each system when a module is
built?

I'd prefer using the convent= ional extensions. A custom extension might confuse users and clash with exi= sting meanings of that extension.
=C2=A0

* Doc strings

If we use the doxygen syntax, it won't follow the various elisp
conventions (args in caps, first line must be descriptive, etc).
Jumping to definition is also pretty convenient, should we keep that
feature for modules? Also how should we load the docstrings
themselves?


Can't modules already run the equi= valent of

(put 'module-func 'function-docu= mentation "docstring")

? With that the b= asics should already be there.
=C2=A0
* Packaging

We need to extend the spec of ELisp packages to take into account
modules. The way I see it a module will have a "core" source file= in C
(or something else) and a bunch of helpers implemented in elisp on top
that expose the package features in a more user-friendly way.

That is one option, but modules consisting entirely = of non-Elisp files are also to be expected, given that the module API is as= powerful as Elisp.
--001a1134c69ca4d73805221a47df--