From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Docstring hack Date: Sun, 31 Jul 2022 08:53:57 -0400 Message-ID: References: <83bkt6687a.fsf@gnu.org> <871qu2lo29.fsf@yahoo.com> <837d3u63ez.fsf@gnu.org> <834jyy61w6.fsf@gnu.org> <831qu25z5x.fsf@gnu.org> <87mtcqhvot.fsf@yahoo.com> <83sfmh4x0o.fsf@gnu.org> <878ro9iw2q.fsf@yahoo.com> <83o7x54swu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001f97a005e51961c5" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18680"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 31 14:56:03 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 1oI8UF-0004kZ-9i for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 14:56:03 +0200 Original-Received: from localhost ([::1]:56894 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI8UD-0008AJ-Sj for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 08:56:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI8ST-000608-Si for emacs-devel@gnu.org; Sun, 31 Jul 2022 08:54:13 -0400 Original-Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]:36391) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oI8SS-0003HE-3Q; Sun, 31 Jul 2022 08:54:13 -0400 Original-Received: by mail-pf1-x42a.google.com with SMTP id g12so8314248pfb.3; Sun, 31 Jul 2022 05:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UsPrsZvDb2eQJPQ9ukhD8OFH8tYicLypwavJ4b9L7Eo=; b=O0Bdh72uwF1iI0fB4Z0B1YjgLxCtsTMfc46WyNTgUQORuNi4y1+oJeoQnNXyVcUCuk LwTGBdARVYMFvoUOEwrUFwDrB8Kg1/KeG7szUEWbUrtQu2RhHr4b12oSODdsQJRz3qsN 6ogj6N3cYHBsA84yZYklvESaF0b/oELJ+7kMt9JJgbu7Tv21FZiD/FjDFn610gEICDiV qQq3Wx7oIJ1vQRkgslPNtfOEbqoiE0PmxiV14b7ZVXWVA3Sx4jX/jhUFvDFGRJgIjC40 uLAA8g/yv7PS1G5LsnE6z9kT4AIVydnIgjC3vpr+9zf/H9wbVyicEvAWuRX+zzrd3GCv ppSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UsPrsZvDb2eQJPQ9ukhD8OFH8tYicLypwavJ4b9L7Eo=; b=wLY2yhYIwACxpt9M5XQQintXDOWs/yg424RfbOwkAuhmYVEE2dgNfgVlxy4SU9ODAh yezQJEl5gcI0OoZEk6KwBhs7cuJvgGXHnvM7KgvrBpZ/YASzsVnaVv9xEEvRsyASKCCP sTUzaU4kH0PgeJxbaGPtviuBPkd0jrpPrGWIZzokgTPbPbp8+XIP0je0IcVo8szPEaEF p+HFSRR5DDMqgZbWps3XRtlLxMnkgyUe6dYlS4FBe5/BS2GeQM8dNAw/mfmRm5dVUfDE N2Fht1F4SnQR9lRvmZ5sbIoEfBawoUa6MVfZ+wjKBDBq81Y1cZisxmqDnLIIniigImP7 W54Q== X-Gm-Message-State: AJIora87XLpkjfhHPls1Bz9AlphGJyBJeSyI9QuqWI+Imt3gXDsyQDoU ySuytC6uMOFpABAdBk3XJ64OCNv+1kVuhuvv0CgmEUQ3 X-Google-Smtp-Source: AGRyM1vmHvhcLRDWEmGl4Pyxx8SQCApYScO3Qb9QLtSBfPT7OzadOdLyV8TAQvszXoIb9SBCKUI0PwbifDwRMeQG03M= X-Received: by 2002:a05:6a00:298d:b0:52b:cf1f:5738 with SMTP id cj13-20020a056a00298d00b0052bcf1f5738mr11828737pfb.0.1659272049955; Sun, 31 Jul 2022 05:54:09 -0700 (PDT) In-Reply-To: <83o7x54swu.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::42a; envelope-from=owinebar@gmail.com; helo=mail-pf1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:292916 Archived-At: --0000000000001f97a005e51961c5 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 31, 2022, 3:56 AM Eli Zaretskii wrote: > > From: Po Lu > > Cc: owinebar@gmail.com, emacs-devel@gnu.org > > Date: Sun, 31 Jul 2022 15:24:13 +0800 > > > > Eli Zaretskii writes: > > > > > OK, but I still lack some glue to understand the issue. Specifically: > > > > > > . the OP said "strings that are erroneously treated as docstrings in > > > dump mode" -- where's the code which makes that mistake, and how > > > is read_literal_string related to that mistake? > > > > He's referring to this part of lread.c: > > > > /* If purifying, and string starts with \ newline, > > return zero instead. This is for doc strings > > that we are really going to find in etc/DOC.nn.nn. */ > > if (!NILP (Vpurify_flag) && NILP (Vdoc_file_name) && cancel) > > { > > unbind_to (count, Qnil); > > return make_fixnum (0); > > } > > Does this mean that just resetting purify-flag is enough to avoid the > problem? If so, I think purify-flag is only meant for preloaded > packages, and dumping Emacs with additional packages isn't supposed to > set that flag. Or maybe loadup.el should load an additional file > (beyond site-load and site-init), after it resets purify-flag? > I'm not sure why you'd not want to use the purify flag, since there are a lot of explicit calls to purecopy that appear intended to take advantage of hash consing. I don't know why that benefit should not apply to libraries being preloaded by site-load and site-init. An alternative is, of course, to make that code in lread.c smarter in > detecting doc strings and applying that handling only to doc strings. > > > > . why isn't there an alternative to fix read_literal_string not to > > > generate zero instead of the format template? the other > > > alternatives all look like partial kludges to me > > > > I can't answer this question, sorry. You'll have to ask the OP. > > I did: the OP was on the CC list. > My fifth alternative was to implement the substitution of 0 directly in the evaluator semantics, so that it would only record 0 for actual docstrings identified while evaluating source code forms during dump mode. That seems like overkill if this is only required for loaddefs. But the manual should probably state that files loaded in site-load and site-init need to be byte compiled for their docstrings to be dynamically loaded. Lynn --0000000000001f97a005e51961c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 31, 2022, 3:56 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Po Lu <luangruo@yahoo.com>
> Cc: owinebar@gmail.com,=C2=A0 emacs-devel@gnu.org
> Date: Sun, 31 Jul 2022 15:24:13 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > OK, but I still lack some glue to understand the issue.=C2=A0 Spe= cifically:
> >
> >=C2=A0 =C2=A0. the OP said "strings that are erroneously trea= ted as docstrings in
> >=C2=A0 =C2=A0 =C2=A0dump mode" -- where's the code which = makes that mistake, and how
> >=C2=A0 =C2=A0 =C2=A0is read_literal_string related to that mistake= ?
>
> He's referring to this part of lread.c:
>
>=C2=A0 =C2=A0/* If purifying, and string starts with \ newline,
>=C2=A0 =C2=A0 =C2=A0 return zero instead.=C2=A0 This is for doc strings=
>=C2=A0 =C2=A0 =C2=A0 that we are really going to find in etc/DOC.nn.nn.= =C2=A0 */
>=C2=A0 =C2=A0if (!NILP (Vpurify_flag) && NILP (Vdoc_file_name) = && cancel)
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0unbind_to (count, Qnil);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return make_fixnum (0);
>=C2=A0 =C2=A0 =C2=A0}

Does this mean that just resetting purify-flag is enough to avoid the
problem?=C2=A0 If so, I think purify-flag is only meant for preloaded
packages, and dumping Emacs with additional packages isn't supposed to<= br> set that flag.=C2=A0 Or maybe loadup.el should load an additional file
(beyond site-load and site-init), after it resets purify-flag?

I'm not sure why you'd not want to use the purify flag= , since there are a lot of explicit calls to purecopy that appear intended = to take advantage of hash consing.=C2=A0 I don't know why that benefit = should not apply to libraries being preloaded by site-load and site-init.


An alternative= is, of course, to make that code in lread.c smarter in
detecting doc strings and applying that handling only to doc strings.

> >=C2=A0 =C2=A0. why isn't there an alternative to fix read_lite= ral_string not to
> >=C2=A0 =C2=A0 =C2=A0generate zero instead of the format template? = the other
> >=C2=A0 =C2=A0 =C2=A0alternatives all look like partial kludges to = me
>
> I can't answer this question, sorry.=C2=A0 You'll have to ask = the OP.

I did: the OP was on the CC list.

My fifth alternative was to implement the = substitution of 0 directly in the evaluator semantics, so that it would onl= y record 0 for actual docstrings identified while evaluating source code fo= rms during dump mode.
That seems like overkill if th= is is only required for loaddefs.=C2=A0 But the manual should probably stat= e that files loaded in site-load and site-init need to be byte compiled for= their docstrings to be dynamically loaded.

Lynn

--0000000000001f97a005e51961c5--