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: Mon, 28 Sep 2015 15:42:43 +0000 Message-ID: References: <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <55F70C4E.8030805@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0444e9e9e9c2a10520d08c38 X-Trace: ger.gmane.org 1443486533 31931 80.91.229.3 (29 Sep 2015 00:28:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 00:28:53 +0000 (UTC) Cc: Tom Tromey , Stephen Leake , Daniel Colascione , Emacs development discussions , Paul Eggert To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 29 02:28:49 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 1Zgimn-0003Uw-0e for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2015 02:28:49 +0200 Original-Received: from localhost ([::1]:42931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgiml-0004oy-UD for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 20:28:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgaZt-0005sv-Pf for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:42:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgaZp-0002U1-Pv for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:42:57 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:38341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgaZp-0002Tw-Gw for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:42:53 -0400 Original-Received: by wiclk2 with SMTP id lk2so107663046wic.1 for ; Mon, 28 Sep 2015 08:42:53 -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=ur3FahsLGZVpf44tO8WPJZqnIaNYIgJXr372YGuXgX4=; b=WOAM2doVg5LvloKQZgboDr3g0C1IW9XitJVAQko1lZQsrErg8o3p0BShzQjJMEsfAS xN0/bCOET4GvGwF43VITmSwibDK0cDpgbim/rAIrCQtzBjroUzIXbk1lGjs4OHM0t7Ka H7az9RMVtXsCmCL02kCuugvCQw58A13mHAgrnL4skpPMV4QcxL8s+BlSf8tgxyrsb2VB xOAiubvKGmy+IZUYIqKsRC9chEatY38c98drruC6fXQ+fSTqlOnQaJpE9fCP8Cbg4Jo2 lUVCflu2di6ZJL65YOB7nh37MfyncFstmypYVelZX+5W4QqKgJ+pjOivej50OVWPvdfp PB5g== X-Received: by 10.180.103.72 with SMTP id fu8mr19682777wib.7.1443454972967; Mon, 28 Sep 2015 08:42:52 -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::22e 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:190446 Archived-At: --f46d0444e9e9e9c2a10520d08c38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am Sa., 26. Se= p. 2015 um 16:56 Uhr: > How should module docstring be written? We either: > > * pick a new syntax and teach make-docfile how to parse it. This is > the clean approach IMO, but it requires more work. We can use a > sufficiently simple syntax so that it can be embedded in comments in > other languages than C. > * define DEFVAR/DEFUN macro in module API header file to a noop so > that make-docfile can parse it as it is. > Library headers should respect namespace conventions. Because in C all symbols are global, it's important to pick names that are unlikely to clash. Usually this is done by prefixing all names with a string that is thought to be sufficiently unique, like "emacs" in your case. But DEFVAR/DEFUN don't follow that convention, so they can't be used in the header file. There are some documentation frameworks available, e.g. Doxygen. It might be a good idea to use one of them instead of trying to define your own syntax. > > As for the finalizer, I wanted to add a function in the API: > > /* Finalizer prototype */ > typedef int (*emacs_finalizer_function)(void *ptr); > > emacs_value make_user_ptr (emacs_env *env, > void *ptr, emacs_finalizer_function *fin); > I still don't understand why we need finalizers. Using finalizers in languages without deterministic garbage collection is generally an antipattern. > > > Or we can have a full "method table" with printer function and other > things we might need in the future. Although It's a bit overkill with > just finalizer/printer... > > /* Printer prototype */ > typedef emacs_value (*emacs_printer_function)(void *ptr); > > /* User-ptr operations */ > typedef struct { > emacs_finalizer_function *fin; > emacs_printer_function *print; > /* ... */ > } emacs_user_ptr_ops; > > emacs_value make_user_ptr (emacs_env *env, > void *ptr, emacs_user_ptr_ops *ops); > What is the use case for this? Is the "user_ptr" functionality really needed? --f46d0444e9e9e9c2a10520d08c38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Aur=C3= =A9lien Aptel <aurel= ien.aptel+emacs@gmail.com> schrieb am Sa., 26. Sep. 2015 um 16:56=C2= =A0Uhr:
How should module docstring= be written? We either:

* pick a new syntax and teach make-docfile how to parse it. This is
the clean approach IMO, but it requires more work. We can use a
sufficiently simple syntax so that it can be embedded in comments in
other languages than C.
* define DEFVAR/DEFUN macro in module API header file to a noop so
that make-docfile can parse it as it is.

Library headers should respect namespace conventions. Because in C all sy= mbols are global, it's important to pick names that are unlikely to cla= sh. Usually this is done by prefixing all names with a string that is thoug= ht to be sufficiently unique, like "emacs" in your case. But DEFV= AR/DEFUN don't follow that convention, so they can't be used in the= header file.
There are some documentation frameworks available, = e.g. Doxygen. It might be a good idea to use one of them instead of trying = to define your own syntax.
=C2=A0

As for the finalizer, I wanted to add a function in the API:

/* Finalizer prototype */
typedef int (*emacs_finalizer_function)(void *ptr);

emacs_value make_user_ptr (emacs_env *env,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void *ptr, emacs_fin= alizer_function *fin);

I still don'= t understand why we need finalizers.=C2=A0 Using finalizers in languages wi= thout deterministic garbage collection is generally an antipattern.
=C2=A0


Or we can have a full "method table" with printer function and ot= her
things we might need in the future. Although It's a bit overkill with just finalizer/printer...

/* Printer prototype */
typedef emacs_value (*emacs_printer_function)(void *ptr);

/* User-ptr operations */
typedef struct {
=C2=A0 emacs_finalizer_function *fin;
=C2=A0 emacs_printer_function *print;
=C2=A0 /* ... */
} emacs_user_ptr_ops;

emacs_value make_user_ptr (emacs_env *env,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void *ptr, emacs_use= r_ptr_ops *ops);

What is the use case f= or this? Is the "user_ptr" functionality really needed?=C2=A0
--f46d0444e9e9e9c2a10520d08c38--