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: Sat, 30 Jul 2022 12:32:27 -0400 Message-ID: References: <83bkt6687a.fsf@gnu.org> <871qu2lo29.fsf@yahoo.com> <837d3u63ez.fsf@gnu.org> <834jyy61w6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000541ed805e50851b0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2737"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 30 18:34:44 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 1oHpQK-0000aL-Kq for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 18:34:44 +0200 Original-Received: from localhost ([::1]:58260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHpQJ-0000EL-2S for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 12:34:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHpOc-0007hD-3f for emacs-devel@gnu.org; Sat, 30 Jul 2022 12:32:59 -0400 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:43834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHpOZ-0004Fn-7L; Sat, 30 Jul 2022 12:32:57 -0400 Original-Received: by mail-lf1-x136.google.com with SMTP id f20so4136347lfc.10; Sat, 30 Jul 2022 09:32:54 -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=WhKWZnYPUMxgVHAdGM/kk5mMHylc3oQAsUlgMOmaR2E=; b=W0kCE+294GchggDM64Zd+cUgb9mgAbssAv7E3v6sbOhg8z3L7UNnVFlCR9GLh45t41 WfsPosy+oWXiqf5bYROIBOUKyzbN/H2dTSXsF3GCaAy7ORcRyxjwDyfg0iYVDf3Dmrea mkZlWpW+FdpjuE826fkCoo0RmZLheDIIwdAHgLWjDIWqzB0EyTSHULApQD+95k9O4RAt TCLFp11TmR76myHy5/wUqgZ5j1PVcLSc2K9Ljt+h+hdO9EGyhU6tvHmRSNan/kgNQfsS rUo/aLQ4S9XExojBGxDyTX6i2Oa7z67T4qOgLIvmeAYxVmgObybOM19FEd87jQ9qCnZF Sn4A== 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=WhKWZnYPUMxgVHAdGM/kk5mMHylc3oQAsUlgMOmaR2E=; b=vP3BqicpJi8ALgQTnFyOORADRio8UxCwm9TKgQXQnu5DHpbDrWzmyKABMBrxh93+wp UMMN9JIdDMXI2ZjbzVmIC1Nx3LH4Y4j5jtFh3bCxnEbMBxyOPIgG+PgoZ6ImNqvmn2ba xjPRjU+TYWErN8tuMilLUa9465Q+ylrOvN9qIPz7UJ3gVIwMv7cgYbyIfqKzU3MT0c1g Kod2kYC8dHyr2rr/PuwmXl3sV7HMNmlMEpttXHWY/iJrfIIPyRDzUpKKaZ7HJJZR0tPo oE/MdrDme+PXysqj0zu+Ywh176PKxrULMCryGtdYY8LuG8eHCACPq9H0rUr2WhBLCNtr NTlg== X-Gm-Message-State: AJIora/kWHmyu9CVCezE9FjSIzjc9JB4i7cpHZLRgWkXg9fUza1UxNgi a5pWgIJQpN8BNV+hz+pnhol/l8xRB1VlVMZvmCaJTbat X-Google-Smtp-Source: AGRyM1tPql1px0QrUPEAHPnQUaqBjO7WGJiAd2qD/RAvIjn55Uek47SlB9oLSBH3LB8iFmRcwJo6we3ziLFNigt4DSs= X-Received: by 2002:a05:6512:3e12:b0:48a:a64f:7228 with SMTP id i18-20020a0565123e1200b0048aa64f7228mr3246680lfv.159.1659198770517; Sat, 30 Jul 2022 09:32:50 -0700 (PDT) In-Reply-To: <834jyy61w6.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=owinebar@gmail.com; helo=mail-lf1-x136.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:292882 Archived-At: --000000000000541ed805e50851b0 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 30, 2022, 11:44 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Sat, 30 Jul 2022 11:38:13 -0400 > > Cc: Po Lu , emacs-devel > > > > > (format args...) > > > > > > will result in (format 0 args...) during dumping. > > > > "Result" in what sense? > > > > As in, if you load emacs-lisp/eieio-core in site-load.el with dump-mode > pdump without having byte-compiled > > eieio-core first, the load cedet/semantic/loaddefs.el, you will get a > cryptic error message stating stringp: 0 is > > not a string. And upon investigation, the closure for > def-eieio-autoload mysteriously has a "(format 0 > > cname)" in the code, even though it's not 0 in the eieio-core source > code. > > Does this happen with any package we actually preload via loadup.el? > If you're not going to support using site-load except in the most trivial of ways, then you should say that in the documentation. I don't think it's unreasonable for a user to expect to be able to load a core emacs library in a file provided for loading additional libraries without it blowing up in their face. Being cryptic in your documentation is a poor substitute for just explicitly stating that it won't work for most of the core libraries (unless they are "arranged to be" pre-compiled), and no attempt to facilitate such customization will be supported. Why even include the option in the official distribution? OS vendors are perfectly capable of maintaining patches that modify the build process to customize it to their system. I'm asking because I'm trying to use this supposed feature on a close to stock source distribution. I've only been changing the lisp libraries because I did not want to debug C code just to preload some stock libraries. To the extent a small set of bugs in the C run-time and my ignorance of the process were responsible, I'll gladly dump the changes to the lisp code and make the few small changes to the C and the construction of my site-load file. I'd prefer to make those changes in a way that would be most likely to be accepted to the core (assuming I can get cleared by my employer), so that I don't have to maintain these bug fixes locally indefinitely. And it doesn't hurt that other users might benefit from a usable site configuration in the build process. But if you're not going to be willing to take up such bug fixes on some general principle (that I don't understand in a free software project), that would be useful to know. And yes, I consider segfaults and runaway allocation during the execution of lisp code (not due to the semantics of the lisp code) to be bugs even if it is during the build process. Especially when that behaviour is from loading stock libraries from the distribution itself, and site-init and site-load are documented features. Your inference that a user who doesn't utilize these documented features will not be impacted by bugs in these features is presumably correct. Personally, I am going to proceed with the last option (the fifth) of having the interpreter do the replacement of a documentation string by 0 at the time it's attempted to be stored as documentation during a bootstrap dump, rather than at read time. That seems a lot cleaner and robust to me than either the current approach or my other ideas. It would have the additional benefit of removing the dependency of etc/DOC on any source lisp files. If that functions well, and I'm cleared to assign the rights, I hope it would be considered for inclusion. Lynn --000000000000541ed805e50851b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 30, 2022, 11:44 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Sat, 30 Jul 2022 11:38:13 -0400
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel <emacs-devel= @gnu.org>
>
>=C2=A0 >=C2=A0 =C2=A0(format <control string starting with escape= d newline> args...)
>=C2=A0 >
>=C2=A0 > will result in (format 0 args...) during dumping.
>
>=C2=A0 "Result" in what sense?
>
> As in, if you load emacs-lisp/eieio-core in site-load.el with dump-mod= e pdump without having byte-compiled
> eieio-core first, the load cedet/semantic/loaddefs.el, you will get a = cryptic error message stating stringp: 0 is
> not a string.=C2=A0 And upon investigation, the closure for def-eieio-= autoload mysteriously has a "(format 0
> cname)" in the code, even though it's not 0 in the eieio-core= source code.

Does this happen with any package we actually preload via loadup.el?

If you&= #39;re not going to support using site-load except in the most trivial of w= ays, then you should say that in the documentation.=C2=A0 I don't think= it's unreasonable for a user to expect to be able to load a core emacs= library in a file provided for loading additional libraries without it blo= wing up in their face.=C2=A0 Being cryptic in your documentation is a poor = substitute for just explicitly stating that it won't work for most of t= he core libraries (unless they are "arranged to be" pre-compiled)= , and no attempt to facilitate such customization will be supported.=C2=A0 = Why even include the option in the official distribution?=C2=A0 OS vendors = are perfectly capable of maintaining patches that modify the build process = to customize it to their system.=C2=A0=C2=A0

=C2=A0I'm asking because I'm trying to use thi= s supposed feature on a close to stock source distribution.=C2=A0 I've = only been changing the lisp libraries because I did not want to debug C cod= e just to preload some stock libraries.=C2=A0 To the extent a small set of = bugs in the C run-time and my ignorance of the process were responsible, I&= #39;ll gladly dump the changes to the lisp code and make the few small chan= ges to the C and the construction of my site-load file.=C2=A0 I'd prefe= r to make those changes in a way that would be most likely to be accepted t= o the core (assuming I can get cleared by my employer), so that I don't= have to maintain these bug fixes locally indefinitely.=C2=A0 And it doesn&= #39;t hurt that other users might benefit from a usable site configuration = in the build process.
But if you're not going to= be willing to take up such bug fixes on some general principle (that I don= 't understand in a free software project), that would be useful to know= .
And yes, I consider segfaults and runaway allocati= on during the execution of lisp code (not due to the semantics of the lisp = code) to be bugs even if it is during the build process.=C2=A0 Especially w= hen that behaviour is from loading stock libraries from the distribution it= self, and site-init and site-load are documented features.
Your inference that a user who doesn't utilize these documented = features will not be impacted by bugs in these features is presumably corre= ct.
Personally, I am going to proceed with the last = option (the fifth) of having the interpreter do the replacement of a docume= ntation string by 0 at the time it's attempted to be stored as document= ation during a bootstrap dump, rather than at read time.=C2=A0 That seems a= lot cleaner and robust to me than either the current approach or my other = ideas.=C2=A0 It would have the additional benefit of removing the dependenc= y of etc/DOC on any source lisp files.=C2=A0 If that functions well, and I&= #39;m cleared to assign the rights, I hope it would be considered for inclu= sion.

Lynn

--000000000000541ed805e50851b0--