From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 4 Oct 2015 16:11:35 +0200 Message-ID: References: <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <55F70C4E.8030805@dancol.org> <87mvvzdzml.fsf@tromey.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1443967912 31547 80.91.229.3 (4 Oct 2015 14:11:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 14:11:52 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , Daniel Colascione , Stephen Leake To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 16:11:50 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 1Zik10-0004Ob-A3 for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 16:11:50 +0200 Original-Received: from localhost ([::1]:42546 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zik0z-0003vI-Iu for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 10:11:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zik0n-0003vA-Au for emacs-devel@gnu.org; Sun, 04 Oct 2015 10:11:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zik0m-000202-AT for emacs-devel@gnu.org; Sun, 04 Oct 2015 10:11:37 -0400 Original-Received: from mail-io0-x22c.google.com ([2607:f8b0:4001:c06::22c]:36129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zik0m-0001zp-5P for emacs-devel@gnu.org; Sun, 04 Oct 2015 10:11:36 -0400 Original-Received: by ioii196 with SMTP id i196so161851517ioi.3 for ; Sun, 04 Oct 2015 07:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7tvNQylewGo0bA4wxGxweTkUiR6mJe2e7XFC4R/amq4=; b=Su5MpgDaHAgMas6fjUW+NhPS7rZrDirT+J/ecocGi0KlF/OIV04E0EhTpJzKyxw+gO Nt4hTjwv8gSjQlvNvCim0HARZLPv1g7l2cMRVGDDl5ypxokCxZDme7QX9GkduuVtgr1q EJ4aaZgiKKFh2IExhPVR3i0JrCjVqZhW8w2woYncN7l1VJi2AYk3QocoORwoTJBKqmdz j4QpvrT4CNO2rtI0rDmpihnCc82QsCravlKIPgXk6roBQVphfWhyAzh8MojaJs1f+BAv EYMUudTSsAsWTtCEnySQMhs5mBRF/TVCMJ7l0WodlFJN6NbZVkc8Z/SDJ/KXp1SyR1xi Yqjw== X-Received: by 10.107.136.88 with SMTP id k85mr22862259iod.135.1443967895511; Sun, 04 Oct 2015 07:11:35 -0700 (PDT) Original-Received: by 10.36.146.193 with HTTP; Sun, 4 Oct 2015 07:11:35 -0700 (PDT) In-Reply-To: <87mvvzdzml.fsf@tromey.com> X-Google-Sender-Auth: ftZI3xrRzcTqQkCAyM3HkMLDXto X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c06::22c 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:190880 Archived-At: On Sun, Oct 4, 2015 at 6:30 AM, Tom Tromey wrote: > Tonight I tried to use the module code to write an FFI module using > libffi. I found some holes that make this difficult to do. Cool :) > It would be great to be able to make new types from C. That would let > me wrap up various C objects I'd like to return opaquely to Lisp. > Wrapping pointers would be good enough (for now I am using bit vectors) > but having more control would be much better. > > Overkill here is better. You'll want to extend this vtable over time, > for example to add a GC mark function. I don't particularly care if the > vtable is exposed or private. > > Of course, if you can add types from C, why not from Lisp? But I guess > I could write a module to allow that :) We have to be careful with this vtable thing. I don't want to end up with C++-level complexity with operator overloading, copy/move constructor, etc. To store pointers you can currently use bit-vectors as you did or also have a table that maps integers to pointers on the module side. For example, a module could return new "types" using a cons ('my-type . ID) where ID is an integer index into a pointer table handled by the module author. It's more work for module writers but it works and keeps the complexity of the module interface low. The only thing we cannot do rigth now is finalizers. But looking through the commits I saw that Daniel added support for "finalizer" in emacs core but I haven't looked into what it actually does. Maybe we can re-use this feature instead of doing it again basically. > * I found the emacs_runtime / emacs_env split strange. I don't know > what the purpose of this is. Also there doesn't seem to be a way to Daniel's design is modeled after the JNI spec where the env must be used from the thread that created the runtime the env came from, IIRC. I have added a "private" module_id field in the env structure which is used to index a module global refs. I was also thinking that you could have for example a module that lets you write sub-modules in python, each with a different module_id but the same runtime. > free an emacs_env, which I suppose makes sense in a way; though > shouldn't they simply be GC'd as well? Nothing can be unloaded in elisp but I didn't made that assumption for modules and I've indexed global refs by module so that you can clear them per module if we ever implement that. > * module-call never frees "args". Fixed, thanks. > * For error handling for now I ended up just calling Emacs stuff > directly. Ok. If you have a public repo somewhere I'd be interested to have a look at your experiements.