unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lynn Winebarger <owinebar@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Docstring hack
Date: Sat, 30 Jul 2022 12:32:27 -0400	[thread overview]
Message-ID: <CAM=F=bBk=agYYTT+YCvgD8aM93VVP1NrERFCh1ApuaS9QgwLjQ@mail.gmail.com> (raw)
In-Reply-To: <834jyy61w6.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]

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>
> >
> >  >   (format <control string starting with escaped newline> 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

[-- Attachment #2: Type: text/html, Size: 4770 bytes --]

  reply	other threads:[~2022-07-30 16:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-30 12:14 Docstring hack Lynn Winebarger
2022-07-30 12:25 ` Po Lu
2022-07-30 12:50   ` Lynn Winebarger
2022-07-30 13:04     ` Lynn Winebarger
2022-07-30 13:32     ` Po Lu
2022-07-30 13:28 ` Eli Zaretskii
2022-07-30 13:36   ` Po Lu
2022-07-30 15:11     ` Eli Zaretskii
2022-07-30 15:38       ` Lynn Winebarger
2022-07-30 15:44         ` Eli Zaretskii
2022-07-30 16:32           ` Lynn Winebarger [this message]
2022-07-30 16:43             ` Eli Zaretskii
2022-07-31  2:17               ` Po Lu
2022-07-31  6:27                 ` Eli Zaretskii
2022-07-31  7:24                   ` Po Lu
2022-07-31  7:56                     ` Eli Zaretskii
2022-07-31  8:48                       ` Po Lu
2022-07-31  9:14                         ` Lars Ingebrigtsen
2022-07-31 22:31                           ` Stefan Monnier
2022-08-01 10:38                             ` Lars Ingebrigtsen
2022-08-04  4:12                         ` Lynn Winebarger
2022-07-31 12:53                       ` Lynn Winebarger
2022-07-31 13:05                         ` Eli Zaretskii
2022-07-31 20:29                           ` Lynn Winebarger
2022-08-01  1:05                             ` Po Lu
2022-08-01 11:07                             ` Eli Zaretskii
2022-07-31  8:03                   ` Stefan Monnier
2022-07-31 12:43                     ` Lynn Winebarger
2022-07-31 21:32                       ` Stefan Monnier
2022-08-02 16:55                         ` Lynn Winebarger
2022-07-31 11:57               ` Lynn Winebarger
2022-07-31  0:52       ` Po Lu
2022-07-31  7:52     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM=F=bBk=agYYTT+YCvgD8aM93VVP1NrERFCh1ApuaS9QgwLjQ@mail.gmail.com' \
    --to=owinebar@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).