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: Wed, 14 Oct 2015 22:34:21 +0000 Message-ID: References: <87bnl1vmqf.fsf@lifelogs.com> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c266827a5e4d0522182ae9 X-Trace: ger.gmane.org 1444862139 12676 80.91.229.3 (14 Oct 2015 22:35:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 22:35:39 +0000 (UTC) Cc: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 15 00:35:38 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 1ZmUe2-0001MX-HG for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 00:35:38 +0200 Original-Received: from localhost ([::1]:44814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmUe1-0002pF-Cy for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 18:35:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmUd2-0002j0-Pn for emacs-devel@gnu.org; Wed, 14 Oct 2015 18:34:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmUd1-0007e6-MS for emacs-devel@gnu.org; Wed, 14 Oct 2015 18:34:36 -0400 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:36069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmUcz-0007dN-KC; Wed, 14 Oct 2015 18:34:33 -0400 Original-Received: by wicgb1 with SMTP id gb1so249148660wic.1; Wed, 14 Oct 2015 15:34:30 -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=U06JmIhiac1F1Jrq3+1TbnLExWGltlKCFMrg+Gx1PNE=; b=Sdwgdj7BYjYdfZag9d6cHV7oaH5xmy8hBZxnxJewdowLhltLO4STkynRNmGWq5FK+l CYB++4Bbu1tPjmKKkwL47GB/nh1m+nI9YINBUpyIlmLJ7o+Z29skPmSiT62U9kjJgx1R WMS8Ct0xSrHeSS/MVy7yHCqC2X8ig0NkGNHCyO4eRWICxfIhK9JXPGdMJ7ALaQoPM2DC 4T5r5ChaqeZ+fHVj+HJ8FPpynmEhf+m1v/UWrhgvlznxfUxDGsX2mKYId7fPV8RcGHOF cNQTwhTTXjBXdaan8+GiPt0h8MtFi+luTB88QGpoGHlqIZz5cQkxjnQGVUFiL9YLI3U7 p7IA== X-Received: by 10.180.11.1 with SMTP id m1mr31799380wib.69.1444862070773; Wed, 14 Oct 2015 15:34:30 -0700 (PDT) In-Reply-To: <56117F37.9060808@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:191594 Archived-At: --001a11c266827a5e4d0522182ae9 Content-Type: text/plain; charset=UTF-8 Daniel Colascione schrieb am So., 4. Okt. 2015 um 21:34 Uhr: > On 10/04/2015 02:41 AM, Philipp Stephani wrote: > > > > > > > > > typedef struct emacs_value_tag* emacs_value; > > > > > > > > > I think it's important that this is a pointer to a struct (for type > > > safety and size correctness) rather than just an arbitrary type. > > > > A typedef is exactly as typesafe. The question of whether to use a > > struct or a typedef is aesthetic. I strongly prefer a typedef, just > like > > pthreads, and I believe that the people who advocate using structs > > directly are simply wrong. > > > > > > Ah, I'm not against the typedef, I'm just asking whether you would make > > it part of the API contract that it's a typedef of a struct pointer, or > > whether it can be any type. > > The problem with defining it as a pointer type is that NULL is now the > invalid sentinel value, which seems incompatible with both making this > thing literally a Lisp_Object and Qnil having all zero bits. > > That's why I strongly prefer making emacs_value a _pointer_ to a > Lisp_Object, where we store the Lisp_Object in an array owned by the > emacs_env. This way, allocating local values is very cheap. > A simple fixed array however puts a fixed upper bound on the number of local values used. That might be undesirable, especially for plugins dealing with large data structures. The simplest unbound allocation mechanism would use an array of emacs_value pointers (emacs_value **) stored in the environment object; the array itself and its elements would be allocated using malloc as usual, and the array would be grown using realloc. However, that requires lots of allocations (at least one per local object used) and could make a more complex allocator necessary. --001a11c266827a5e4d0522182ae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am So., 4. Okt. 2015 um 21:34=C2=A0Uhr:
On 10/04/2015 02:41 AM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0typedef struct emacs= _value_tag* emacs_value;
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think it's important that this is a poin= ter to a struct (for type
>=C2=A0 =C2=A0 =C2=A0> safety and size correctness) rather than just = an arbitrary type.
>
>=C2=A0 =C2=A0 =C2=A0A typedef is exactly as typesafe. The question of w= hether to use a
>=C2=A0 =C2=A0 =C2=A0struct or a typedef is aesthetic. I strongly prefer= a typedef, just like
>=C2=A0 =C2=A0 =C2=A0pthreads, and I believe that the people who advocat= e using structs
>=C2=A0 =C2=A0 =C2=A0directly are simply wrong.
>
>
> Ah, I'm not against the typedef, I'm just asking whether you w= ould make
> it part of the API contract that it's a typedef of a struct pointe= r, or
> whether it can be any type.

The problem with defining it as a pointer type is that NULL is now the
invalid sentinel value, which seems incompatible with both making this
thing literally a Lisp_Object and Qnil having all zero bits.

That's why I strongly prefer making emacs_value a _pointer_ to a
Lisp_Object, where we store the Lisp_Object in an array owned by the
emacs_env. This way, allocating local values is very cheap.

A simple fixed array however puts a fixed = upper bound on the number of local values used. That might be undesirable, = especially for plugins dealing with large data structures. The simplest unb= ound allocation mechanism would use an array of emacs_value pointers (emacs= _value **) stored in the environment object; the array itself and its eleme= nts would be allocated using malloc as usual, and the array would be grown = using realloc. However, that requires lots of allocations (at least one per= local object used) and could make a more complex allocator necessary.=C2= =A0
--001a11c266827a5e4d0522182ae9--