From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Sun, 25 Jul 2021 11:01:22 -0700 Message-ID: <86wnpe6znx.fsf@stephe-leake.org> References: <83h7gw6pyj.fsf@gnu.org> <83r1fz5xr9.fsf@gnu.org> <1AAB1BCC-362B-4249-B785-4E0530E15C60@gmail.com> <83czri67h0.fsf@gnu.org> <46BBFF88-76C3-4818-8805-5437409BEA93@gmail.com> <83wnpq46uk.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <8335s64v10.fsf@gnu.org> <5380C92B-6C15-4490-A1E0-1C3132DBB16A@gmail.com> <83k0li2shw.fsf@gnu.org> <83eebq2mpy.fsf@gnu.org> <83lf5w26e3.fsf@gnu.org> <83eebo1c9z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6294"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cc: Yuan Fu , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 25 20:02:06 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m7iRy-0001R9-HO for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Jul 2021 20:02:06 +0200 Original-Received: from localhost ([::1]:48038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7iRx-0005Iw-7Z for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Jul 2021 14:02:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36556) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7iRM-0004cs-5S for emacs-devel@gnu.org; Sun, 25 Jul 2021 14:01:28 -0400 Original-Received: from gateway32.websitewelcome.com ([192.185.145.100]:27633) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7iRK-0000zY-7s for emacs-devel@gnu.org; Sun, 25 Jul 2021 14:01:27 -0400 Original-Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway32.websitewelcome.com (Postfix) with ESMTP id B2B5A2ABABE for ; Sun, 25 Jul 2021 13:01:24 -0500 (CDT) Original-Received: from host2007.hostmonster.com ([67.20.76.71]) by cmsmtp with SMTP id 7iRImejUvsCiy7iRImP9TN; Sun, 25 Jul 2021 13:01:24 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stephe-leake.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kd6T0qmNOQpx0ujQ7yfXn0LmhY83XMmfLUjM1nXHKhw=; b=LpF5Q9yO0zeUXuW93WZOpyQP6d x465wR+xlXACuhwiKNIgX5vPi5nzWFLw5dhcvKJbio8agbnQit+2OSyK3Kf83O2IoR5AS1WCr5x8S pVtqp/jHTd7jlRL48+dIKsvBsa40xaDFrM2O9mCJ0YV8qqfWuu3kwGlbsL+Vsl5+OHGXyEhPcmT0L T5QVMpBbVcTF8IW3+FoO3NtYNkvraFGmchUWF37sPRYeVOjcTkvYcmofBH6GUJoMPfAlu/Jz5hC0k VHXo+ccQZPY7IbaMQ/RoH9K6fwr0N/wcf3w67AEvCKJhFRQgO3i5LgYa9EAUU0GAC7kTLi+6TzNiz 3ZPGnJDA==; Original-Received: from [76.77.182.20] (port=57269 helo=Takver4) by host2007.hostmonster.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m7iRH-000qRw-Tn; Sun, 25 Jul 2021 12:01:23 -0600 In-Reply-To: <83eebo1c9z.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Jul 2021 09:00:56 +0300") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2007.hostmonster.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 76.77.182.20 X-Source-L: No X-Exim-ID: 1m7iRH-000qRw-Tn X-Source-Sender: (Takver4) [76.77.182.20]:57269 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 5 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDIwMDcuaG9zdG1vbnN0ZXIuY29t X-Local-Domain: yes Received-SPF: permerror client-ip=192.185.145.100; envelope-from=stephen_leake@stephe-leake.org; helo=gateway32.websitewelcome.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271618 Archived-At: Eli Zaretskii writes: >> From: Yuan Fu >> Date: Fri, 23 Jul 2021 16:22:59 -0400 >> Cc: Stefan Monnier , >> Cl=C3=A9ment Pit-Claudel , >> emacs-devel@gnu.org >>=20 >> > We must replace this function, if only because the MS-Windows build of >> > Emacs uses a custom malloc implementation. Does TS allow the client >> > to use its own malloc? >>=20 >> Yes, in that case, we need to embed tree-sitter into Emacs, instead >> of using it as a dynamic library, I think. >>=20 >> // Allow clients to override allocation functions >> #ifndef ts_malloc >> #define ts_malloc ts_malloc_default >> #endif >> #ifndef ts_calloc >> #define ts_calloc ts_calloc_default >> #endif >> #ifndef ts_realloc >> #define ts_realloc ts_realloc_default >> #endif >> #ifndef ts_free >> #define ts_free ts_free_default >> #endif >>=20 >> How do we handle such thing in Emacs? > > We use xmalloc, which calls memory_full when allocation fails, which > releases some spare memory we have for this purpose, and tells the > user to save the session and exit. I'm thinking about how this applies to wisi, when migrating to a module. Ada has a built-in allocator; it's probably possible to change that, but I'd like to understand exactly why we need to do that. The Ada allocator throws an exception on allocation fail; is it sufficient to turn that exception into an elisp signal, and arrange for elisp to call memory_full (or take some other action, like killing the parser)? Another possible reason to change the Ada allocator is if we want to expose Ada memory pointers directly to elisp, as Yuan Fu wants to do for tree-sitter (I don't plan to do this for wisi). Does that require that the pointers be allocated by the same allocator? I'm not clear what that would mean for the garbage collector; is it then expected to recover the tree-sitter-allocated memory for the tree? or does it ignore those lisp objects? --=20 -- Stephe