From: Ken Raeburn <raeburn@raeburn.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Not using DOC for ELisp files
Date: Fri, 7 Jan 2022 17:59:25 -0500 [thread overview]
Message-ID: <d923f7f0-4229-b278-1edc-ad37ab3c7215@raeburn.org> (raw)
In-Reply-To: <838rvwdh7h.fsf@gnu.org>
On 2022-01-03 09:30, Eli Zaretskii wrote:
>> Date: Mon, 3 Jan 2022 08:48:03 -0500
>> From: Ken Raeburn <raeburn@raeburn.org>
>>
>> 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
next prev parent reply other threads:[~2022-01-07 22:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 1:48 Not using DOC for ELisp files Stefan Monnier
2021-12-28 2:25 ` Po Lu
2021-12-28 3:48 ` Stefan Kangas
2021-12-28 5:39 ` Po Lu
2021-12-28 4:11 ` LdBeth
2021-12-28 5:03 ` Stefan Monnier
2021-12-28 5:38 ` Po Lu
2021-12-28 9:52 ` Phil Sainty
2021-12-28 10:31 ` Po Lu
2021-12-28 12:47 ` Po Lu
2021-12-28 7:10 ` Lars Ingebrigtsen
2021-12-28 3:39 ` Stefan Kangas
2021-12-28 5:10 ` Stefan Monnier
2021-12-28 6:56 ` Lars Ingebrigtsen
2021-12-28 12:44 ` Eli Zaretskii
2021-12-28 17:14 ` Stefan Monnier
2021-12-28 18:17 ` Eli Zaretskii
2021-12-29 0:15 ` Stefan Monnier
2021-12-29 12:30 ` Johann Klähn
2021-12-29 23:08 ` Stefan Monnier
2021-12-29 12:52 ` Eli Zaretskii
2021-12-29 23:23 ` Stefan Monnier
2021-12-30 7:20 ` Eli Zaretskii
2021-12-31 4:19 ` Stefan Monnier
2021-12-31 8:57 ` Eli Zaretskii
2021-12-31 16:16 ` Stefan Monnier
2021-12-31 18:45 ` Eli Zaretskii
2022-01-03 13:48 ` Ken Raeburn
2022-01-03 14:30 ` Eli Zaretskii
2022-01-07 22:59 ` Ken Raeburn [this message]
2022-01-08 7:08 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d923f7f0-4229-b278-1edc-ad37ab3c7215@raeburn.org \
--to=raeburn@raeburn.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.