From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Not using DOC for ELisp files Date: Fri, 7 Jan 2022 17:59:25 -0500 Message-ID: References: <30e03635-843d-f3be-7709-d4b633b2c90a@raeburn.org> <838rvwdh7h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30580"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 08 00:03:51 2022 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 1n5yH1-0007pm-0e for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jan 2022 00:03:51 +0100 Original-Received: from localhost ([::1]:42844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5yGz-0003XZ-Sy for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jan 2022 18:03:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5yCp-0005ZH-Ut for emacs-devel@gnu.org; Fri, 07 Jan 2022 17:59:31 -0500 Original-Received: from [2607:f8b0:4864:20::830] (port=37770 helo=mail-qt1-x830.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5yCo-0002kB-00 for emacs-devel@gnu.org; Fri, 07 Jan 2022 17:59:31 -0500 Original-Received: by mail-qt1-x830.google.com with SMTP id c15so6633289qtc.4 for ; Fri, 07 Jan 2022 14:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=itI2ER+WduEAqaQ3nIr+ALGwgxC4aHdzFoQY4mvv3XY=; b=A3HGhhLRF+lLBQuEhshHnC1n5jfXEXbDN/RcZ4CKEHC2ENRy7vdUtsxUqcc+4vmHKj AcYqXixMGqh/RWyIYNIQt+l0C1bzno5+MS/RaSei7Y/BTt8glfoAcfLjcOh+HguhWAQI K6/qbChV2Kg0Rs6JVkVif6WDTysn+y880zstw0i6wEl89xWxKKewDKVp2822icSrw+Ej hCJvEVhOiXujGUQOLePVMZJ4IXxOcDR4XaDsAEgJf0W9uNrklJ8k7lUPGNhoe49QpcI+ AqGlDN5cvdYBC59GMhwnfHQ5Kf7dohQRGhjpMqHEGuXrrCcsyg8Z5Ss82vVs1Ca4bc/I 6wYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=itI2ER+WduEAqaQ3nIr+ALGwgxC4aHdzFoQY4mvv3XY=; b=SBAU1YgqjHWZaEdppfOQHa4XC6QvySukzfEXCl5aHTqgwFWEEGFlra7G9eRaUYHScc oOdJ83LXpTt25xTO2r0giJKT5jR2XoTAJiiMnOqrTwAS8NRLFwu/d1UDoJhDvrOMZwWa 8jahT8MuONzVMv+dwFJSsDi0wwptDGAfGdMh1BUagLzJZq/8IiKzCOcWgInMAyvt/5vM jDG/qLwAtJfc4NimlEswO0d9Y19Fk/aDJuoDGNaS6Ew3X9jXv62sNNQ7daz5/BkjhT30 QVr7cJk9M+viddA7jO/z/dzIqDKgI5+MgBTcABfg1b7CgkomVMxFKgZD+yjP/D4Er0Ul qVLQ== X-Gm-Message-State: AOAM532H5W36251ZOeZNVwPElJG+19zIVHIh0z/ToN3aablnqTlDDjl+ 0Svju10p1yW7VE03zSCDKxg5rQ== X-Google-Smtp-Source: ABdhPJzs0EsVZhYKif1SxNWdVEanXNhgVGZSWRbRc6f3Qst+RwO6zGRjE41Q4QoMmLafpiV98ndhHg== X-Received: by 2002:ac8:7f12:: with SMTP id f18mr861289qtk.391.1641596367561; Fri, 07 Jan 2022 14:59:27 -0800 (PST) Original-Received: from [192.168.23.135] (c-24-60-138-149.hsd1.ma.comcast.net. [24.60.138.149]) by smtp.googlemail.com with ESMTPSA id d17sm4857997qtb.71.2022.01.07.14.59.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 14:59:27 -0800 (PST) Content-Language: en-US In-Reply-To: <838rvwdh7h.fsf@gnu.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::830 (failed) Received-SPF: none client-ip=2607:f8b0:4864:20::830; envelope-from=raeburn@raeburn.org; helo=mail-qt1-x830.google.com X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-2.691, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=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" Xref: news.gmane.io gmane.emacs.devel:284435 Archived-At: On 2022-01-03 09:30, Eli Zaretskii wrote: >> Date: Mon, 3 Jan 2022 08:48:03 -0500 >> From: Ken Raeburn >> >> Another piece I recall looking at, which I don't remember if I brought >> up on the list at the time, was moving the C based doc strings into the >> generated .o files and the executable > Did you only think about ELF executables, or did you consider how to > do this with any binary formats we support? As I recall, it was a generic approach, putting the strings into char arrays linked in at the C level during compilation. For variables, I think there was some indirection via an array index, to avoid increasing Lisp_Symbol size while also not creating all the doc strings as Lisp strings up front. I don't recall if that part got completed; I tackled function docs first. The annoying part was, it adds a generated header per C source file for these strings. I was looking at whether it could be done without doing so, but make-docfile tacks on the "(fn THIS-ARG THAT-ARG ...)" bit for function documentation which can't _exactly_ be done with preprocessor hacks; cpp has no "upcase" function, though tweaks to the runtime support could work around that. And DEFVAR docs need to be pulled out and (as mentioned above) stuffed into an array of strings. There was an optimization I did, for platforms supporting the "section" attribute extension (at least MacOS and the GNU tools on ELF), to group together the strings in the object file (and hopefully the executable) so that, if the doc strings weren't actually used, none of those pages need be paged in from disk, because they aren't intermixed with other data (except maybe at the ends of the range). But if that support isn't available, the rest should still work fine. And if the non-Lisp doc strings amount to less than a megabyte, as I think an earlier email in this thread indicated, the memory cost of not doing this apparently isn't huge anyway. Ken