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, 22 Oct 2015 22:49:01 +0000 Message-ID: References: <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> <56259FDD.8040401@dancol.org> <87zizeme8k.fsf@tromey.com> <5625B166.3080104@dancol.org> <86zizdczhp.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c38dc0f744720522b94dc6 X-Trace: ger.gmane.org 1445554183 15158 80.91.229.3 (22 Oct 2015 22:49:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 22:49:43 +0000 (UTC) Cc: Eli Zaretskii , Daniel Colascione , Stephen Leake , Emacs development discussions , Tom Tromey To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 23 00:49:37 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 1ZpOfw-0006ni-26 for ged-emacs-devel@m.gmane.org; Fri, 23 Oct 2015 00:49:36 +0200 Original-Received: from localhost ([::1]:34912 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpOfu-0007bH-Oq for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 18:49:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpOfg-0007bC-10 for emacs-devel@gnu.org; Thu, 22 Oct 2015 18:49:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpOfe-0005hZ-Tw for emacs-devel@gnu.org; Thu, 22 Oct 2015 18:49:19 -0400 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:33513) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpOfc-0005df-TR; Thu, 22 Oct 2015 18:49:17 -0400 Original-Received: by wijp11 with SMTP id p11so53350343wij.0; Thu, 22 Oct 2015 15:49:16 -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=++X0X1KiFC5LhMc+xx2dY3hcTC9zgo12p4fqaoEd9w4=; b=yEJJBJdvLUVFLXmWRGlbBBZoasjPwr2HS0WnMoW0b5mn8nJTfZZVSTdWdzUWFun/PT NbrWNg3iNCnn+9QCgJGbwsaQGtZ/S8uHZIo2Sp3lYk6CaEVzxnkE8OfRtjCJrRh1accd x9Xor65/s0llIyF0H6zzSg4lWGTAhcPaCjt4+IDHabnvke7Spp87R8MjuAhY2LZyy7qm Z7YhHfkMLDVg7zCX99MwdJQs0nOQjM05JPmshiQmbOLMRBj/kKbUa5voNFkACGcSyeOF tkdBNei11moxnC2hWgeIWSnXKS0s798ZIqpDkgnQ3ouj5p9mOi9jEJZieCBB3j08BW6j MVOQ== X-Received: by 10.180.188.97 with SMTP id fz1mr765038wic.28.1445554155895; Thu, 22 Oct 2015 15:49:15 -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::22f 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:192437 Archived-At: --001a11c38dc0f744720522b94dc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am Do., 22. Ok= t. 2015 um 14:57 Uhr: > I've added user-pointer objects. Some feedback I had off-list: > > * add functions to the API for fast vector access as it currently > requires too much boxing/unboxing of integers for doing > length/indexing stuff. > This would make sense. Same with things like car and cdr etc. However, we should be careful not to overload the module interface. It might make sense to do some basic measurements using a real-life example and optimize only the hotspots. > * expose fast read-only string access (not sure how do-able this is > considering the encoding problem) > If the internal Emacs encoding is not defined, then we probably shouldn't expose it to modules. What should modules do with such string access? They could only treat the contents as opaque byte arrays. > * consider NULL as a no-op finalizer. > > Philip, you obviously have more experienced in this memory handling > stuff so I'm going to trust you and merge what you did (but there are > merge conflicts on the last pull requests atm, havent looked into it). > Thanks again for your work :) > You're welcome, thanks for implementing the module stuff in the first place! I'm not really experienced either, I've simply implemented what Daniel has proposed (a simple list of blocks). I've merged your branch and pushed to my fork, so you should be able to merge one of the PRs now. > > This module API is slowly but surely materializing. The interface is > lot more clean and user-friendly than my initial plan. I hope we can > have good performances where it matters to make it really useful :) > --001a11c38dc0f744720522b94dc6 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., 22. Okt. 2015 um 14:57=C2= =A0Uhr:
I've added user-pointer= objects. Some feedback I had off-list:

* add functions to the API for fast vector access as it currently
requires too much boxing/unboxing of integers for doing
length/indexing stuff.

This would make = sense. Same with things like car and cdr etc.
However, we should = be careful not to overload the module interface. It might make sense to do = some basic measurements using a real-life example and optimize only the hot= spots.
=C2=A0
* expose fast read-only string access (not sure how do-able this is
considering the encoding problem)

If th= e internal Emacs encoding is not defined, then we probably shouldn't ex= pose it to modules. What should modules do with such string access? They co= uld only treat the contents as opaque byte arrays.
=C2=A0
* consider NULL as a no-op finalizer.

Philip, you obviously have more experienced in this memory handling
stuff so I'm going to trust you and merge what you did (but there are merge conflicts on the last pull requests atm, havent looked into it).
Thanks again for your work :)

You'r= e welcome, thanks for implementing the module stuff in the first place! I&#= 39;m not really experienced either, I've simply implemented what Daniel= has proposed (a simple list of blocks).
I've merged your bra= nch and pushed to my fork, so you should be able to merge one of the PRs no= w.
=C2=A0

This module API is slowly but surely materializing. The interface is
lot more clean and user-friendly than my initial plan. I hope we can
have good performances where it matters to make it really useful :)
--001a11c38dc0f744720522b94dc6--