From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#69952: [PATCH] Support pdumping compiled queries by dumping their source Date: Wed, 29 May 2024 12:35:24 -0400 Message-ID: References: <86r0g1zaqi.fsf@gnu.org> <86le5hr9oj.fsf@gnu.org> <861q709y5y.fsf@gnu.org> <9B2A2190-AB42-4F1B-9F9D-5623B343CF0A@gmail.com> <86frvf8gf9.fsf@gnu.org> <86eday6j9o.fsf@gnu.org> <868r157wdy.fsf@gnu.org> <868r0phq6e.fsf@gnu.org> <493C3C1B-74F2-405D-830F-213B4D76DDC1@gmail.com> <86wmnrecr0.fsf@gnu.org> <61C9A0EB-D97D-4223-B257-FCA8DB150AA6@gmail.com> <86ikz66m5l.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="27169"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Yuan Fu , dancol@dancol.org, 69952@debbugs.gnu.org, serg.foo@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 29 18:36:30 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sCMHu-0006rr-E2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 May 2024 18:36:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCMHM-00047i-SL; Wed, 29 May 2024 12:35:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCMHI-000454-L1 for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 12:35:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sCMHI-0008WV-Bf for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 12:35:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCMHS-00073N-4w for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 12:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 May 2024 16:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69952 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 69952-submit@debbugs.gnu.org id=B69952.171700054927076 (code B ref 69952); Wed, 29 May 2024 16:36:02 +0000 Original-Received: (at 69952) by debbugs.gnu.org; 29 May 2024 16:35:49 +0000 Original-Received: from localhost ([127.0.0.1]:43634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCMHA-00072W-8N for submit@debbugs.gnu.org; Wed, 29 May 2024 12:35:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCMH5-000723-W1 for 69952@debbugs.gnu.org; Wed, 29 May 2024 12:35:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCMGq-0008Mp-MG; Wed, 29 May 2024 12:35:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ZL8yQoCvJ4vAuQhI5dqPY/R5v51ddDdGqmG9HWDfslU=; b=K6Dny9+mMOv2/XDJ7WYL 0IGJ155FfeFFk9vsR8VtyU6VnPhiZmQWMSVhXe/20qAiKOn9jB24F2r60QATIKhdl51NPLmgWZFw3 Mhr7N9jMOVF9BVCoeipEkjY6MLgNtBehrdVtaef5iEfsmXTWyaUpo2UBdpDxOADQlMPOxBoSA6sbl OoruJoIR0qwg2V8Exn1o3QZtkmnlgDHrPXGTCbKMiRVkW0zeBuIjOg2qUFu8lZwrbQELTeYDYX+bd gGCYTc9QuzzpyqklhtNs8GfK1ti+CdwUO3CuznZH5+3hKJW3a12pF9AXvoadhiY6PTzI9Nl2ZvmYf O4QPryZQCHZDDA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sCMGq-000646-Dh; Wed, 29 May 2024 12:35:24 -0400 In-Reply-To: <86ikz66m5l.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 May 2024 15:55:50 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286168 Archived-At: Eli Zaretskii writes: >> From: Yuan Fu >> Date: Tue, 21 May 2024 23:36:47 -0700 >> Cc: serg.foo@gmail.com, >> dancol@dancol.org, >> 69952@debbugs.gnu.org >>=20 >> >>>> Yes, most likely a function-undefined signal, since all the >> >>> treesit.c functions like treesit-query-capture or >> >>> treesit-query-compile will be nonexistent. And usually the Lisp >> >>> program trying to use the query would check for tree-sitter >> >>> availability with treesit-available-p before trying to use any >> >>> tree-sitter functions; so that signal will be usually avoided as >> >>> well. >> >>>=20 >> >>> Can you suggest such an addition to the patch? >> >>=20 >> >> Let me take a look. >> >>=20 >> >> Yuan >>=20 >> Am I missing something? It seems the patch doesn=E2=80=99t include anyth= ing about loading a dumped query? > > Looks like that, yes. > >> I guess that=E2=80=99s the addition you=E2=80=99re talking about? If I w= ant to add a special loader, where should I start? > > I guess in dump_do_emacs_relocation and/or dump_do_dump_relocation? Yes that's correct. > Alternatively, perhaps it's better to define a hook via > pdumper_do_now_and_after_load_impl or > pdumper_do_now_and_after_late_load_impl, in which case the hook will > be run after loading the dump file. This sounds easier if you can > access all the loaded queries one by one, instead of catching them > as they are being loaded. Note also that if one decides to execute code at LATE_RELOCS or VERY_LATE_RELOCS time he has the lisp machinery at disposal (including allocation), but native code becomes functional only after VERY_LATE_RELOCS relocs are done (not sure this can impact you here). On this might be necessary if Yuan goes for the hook and needs native Lisp code to be working, to add 'pdumper_do_now_and_after_very_late_load_impl' (which I think I didn't bothered at the time). Andrea