From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 28 Sep 2015 15:39:45 -0400 Message-ID: References: <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: text/plain X-Trace: ger.gmane.org 1443489537 10593 80.91.229.3 (29 Sep 2015 01:18:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 01:18:57 +0000 (UTC) Cc: Daniel Colascione , Emacs development discussions , Paul Eggert , =?windows-1252?Q?Aur=E9lien?= Aptel , Tom Tromey , Stephen Leake To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 29 03:18:52 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 1ZgjZD-00036h-R5 for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2015 03:18:51 +0200 Original-Received: from localhost ([::1]:43628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgjZD-0008IZ-9P for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 21:18:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgeH8-0005f5-AQ for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:39:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgeH4-0006QT-Se for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:39:50 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgeH4-0006QF-Pb for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:39:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CVDQA731xV/wihxEVcgxCEAsEVh0sEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQcCIIs6hQUHhC0FnxeSFIIUgUUjgWaCLiKCeAEBAQ X-IPAS-Result: A0CVDQA731xV/wihxEVcgxCEAsEVh0sEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQcCIIs6hQUHhC0FnxeSFIIUgUUjgWaCLiKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="166112298" Original-Received: from 69-196-161-8.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.8]) by ironport2-out.teksavvy.com with ESMTP; 28 Sep 2015 15:39:45 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6D54F61769; Mon, 28 Sep 2015 15:39:45 -0400 (EDT) In-Reply-To: (Philipp Stephani's message of "Mon, 28 Sep 2015 15:42:43 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:190464 Archived-At: > 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. Using doxygen sounds like a good idea. Since the only thing we really need to formalize is the place and format of the "compiled" docstrings (e.g. "a DOC file"), there could even be several tools available which allow placing the docstring in various ways in the source code. And each module could use the tool it prefers. > I still don't understand why we need finalizers. Using finalizers in > languages without deterministic garbage collection is generally an > antipattern. Maybe that's "generally" the case, but when you need to interface a GC'd language with a manually-managed library, it's the standard technique (and pretty much only/best). The finalizer of course has to be "invisible". Typically, it will do nothing more than call "free" (or something equivalent) on a few objects. > What is the use case for this? Is the "user_ptr" functionality really > needed? Think of a module which tries to provide bignums to Elisp via GMP. It'll need to provide the new "bignum" objects, and they'll be internally represented as GMP objects (which are manually allocated/freed). So it has to define a new Lisp_Object type, and some of its fields are not Lisp_Objects but some pointer to an internal thingy that needs to be freed iff the Lisp_Object is reclaimed. Stefan