From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Hugo Thunnissen Newsgroups: gmane.emacs.devel Subject: Re: Preferred approach to inclusion of data in ELPA package Date: Sat, 19 Aug 2023 13:26:30 +0200 Message-ID: References: <28956ffc-6cc0-1f39-a26b-1453b48d61b1@hugot.nl> <878ra91ie7.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9329"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 19 13:27:39 2023 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 1qXK7G-0002Cw-SI for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Aug 2023 13:27:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXK6c-0002MM-3h; Sat, 19 Aug 2023 07:26:58 -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 1qXK6Z-0002M0-Cs for emacs-devel@gnu.org; Sat, 19 Aug 2023 07:26:55 -0400 Original-Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXK6S-0007dB-Q1 for emacs-devel@gnu.org; Sat, 19 Aug 2023 07:26:51 -0400 Original-Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1qXK6M-00ADUi-J0 for emacs-devel@gnu.org; Sat, 19 Aug 2023 13:26:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hugot.nl; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=/rFrsuKolxLeKKJyAPkjoMKHWcxBoAxerUJagqdnrKU=; b=slB/VVgxjOb40ScqUXFwoOjRX3 A4JqqJhHDNV4AeJ7AOSejCTmwaZM0Nq/BN+khHMilg2PTGMDM2Fi4LkjGeyZz1ClZjrjmiOmIOryG 9yBtt1g0AEUToJqI/Iy76/6Jz/omRW1XQcrgH9k9JBls3J3HoqPQmbIBWU1lFEQQ6PavukiRXJPYd wC7VOLGYquBqWz7DMpxreVOyUdmz/Y4tD0w/NpFoUs1/sEelB/GOvKg1dFpBTE1kPxqXujTeS5mFb kMTbttJXSv0tME1ofOVIJ1/8RpBymsykOP2b5UK3tGDjgd/QtaIbOvme9MacpOVyzmqqbumwv5Bix KThIJ6IA==; Original-Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1qXK6M-0001cI-3p; Sat, 19 Aug 2023 13:26:42 +0200 Original-Received: by submission03.runbox with esmtpsa [Authenticated ID (1060096)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1qXK6B-0008PQ-PK; Sat, 19 Aug 2023 13:26:31 +0200 Content-Language: en-US, nl In-Reply-To: <878ra91ie7.fsf@posteo.net> Received-SPF: pass client-ip=2a0c:5a00:149::25; envelope-from=devel@hugot.nl; helo=mailtransmit04.runbox.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.862, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308932 Archived-At: On 8/17/23 23:14, Philip Kaludercic wrote: > > Another idea is to have a Makefile generate the file, like the one you > describe in option 2., that is generate whenever the package is built > and bundled into a tarball for distribution. That way you don't have to > store a binary blob in your repository, and you can avoid burdening the > user with additional computations at either compile or runtime. > > Does the generation require any special functionality/tools/code to be > provided on the device the index is generated on? The php function/class stubs are generated with a php script, but I'm checking the resulting stubs file into git. The index itself can be built with just my package based on the stubs file. Some more context, as I built and bench-marked a prototype: The resulting index file is 3.1MB of s-expressions  which when compressed with gzip becomes a file of 172K (there's a lot of duplicate symbols/strings in there). Loading this file takes about 30% less time than building the index from scratch (300ms vs 430-450ms on my laptop with Core i5-8250U, byte compiled). I suppose this could be further optimized with a more efficient serialization format, but I don't want to spend much time on implementing that as I'm working towards an initial package release. How would having a Makefile like you suggest work in practice? Would I need to request that the ELPA maintainers add my Makefile to the build process of my package somehow? Or is there a standard automated way to have Makefiles be executed during an ELPA build? Also: If the former is the case, is the reduction in load time that this brings even significant enough to be worth the bother or should I just hold off on this while I look for a more efficient solution?