From: Eric Wong <e@yhbt.net>
To: meta@public-inbox.org
Subject: [PATCH v2 0/2] rerolled doc updates
Date: Mon, 13 Apr 2020 11:32:43 +0000 [thread overview]
Message-ID: <20200413113245.9282-1-e@yhbt.net> (raw)
Thanks to Kyle and Leah for comments.
Eric Wong (2):
doc: add technical/whyperl
doc: start reproducibility document
Documentation/reproducibility.txt | 29 +++++
Documentation/technical/whyperl.txt | 170 ++++++++++++++++++++++++++++
2 files changed, 199 insertions(+)
create mode 100644 Documentation/reproducibility.txt
create mode 100644 Documentation/technical/whyperl.txt
Interdiff against v1:
diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt
index 4e56ada4..af3e5366 100644
--- a/Documentation/reproducibility.txt
+++ b/Documentation/reproducibility.txt
@@ -3,7 +3,7 @@ reproducibility => forkability
The ability to fork a project is a checks and balances
system for free software projects. Reproducibility is key
-to forkability since every mirror is potential fork.
+to forkability since every mirror is a potential fork.
git makes the code history of projects fully reproducible.
public-inbox uses git to make the email history of projects
diff --git a/Documentation/technical/whyperl.txt b/Documentation/technical/whyperl.txt
index b0a0d16b..11ae7c2a 100644
--- a/Documentation/technical/whyperl.txt
+++ b/Documentation/technical/whyperl.txt
@@ -11,7 +11,7 @@ Other languages and runtimes may eventually be a possibility
for us, and this document can serve as our requirements list
for possible replacements.
-As always, comments and corrections and additions welcome at
+As always, comments, corrections and additions are welcome at
<meta@public-inbox.org>. We're not Perl experts, either.
Good Things
@@ -26,9 +26,9 @@ Good Things
have to waste bandwidth or space with giant toolchains or
architecture-specific binaries.
- Furthermore, Perl documentation is typically installed as
- manpages, allowing users to quickly access and learn it
- offline.
+ Furthermore, Perl documentation is typically installed
+ locally as manpages, allowing users to quickly refer
+ to documentation as needed.
* Scripted, always editable by the end user
@@ -48,15 +48,14 @@ Good Things
* Predictable performance
While Perl is neither fast or memory-efficient, its
- performance and memory use are predictable and does not
- require GC tuning by the user.
+ performance and memory use are predictable.
public-inbox is developed for (and mostly on) old
hardware. Perl was fast enough to power the web of the
late 1990s, and any cheap VPS today has more than enough
RAM and CPU for handling plain-text email.
- Low hardware requirements increases the reach of our software
+ Low hardware requirements increase the reach of our software
to more users, improving centralization resistance.
* Compatibility
@@ -79,12 +78,12 @@ Good Things
GNU/Linux distros and BSD ports.
There should be no need to rely on language-specific
- package managers such as cpan(1), those systems increase
+ package managers such as cpan(1). Those systems increase
the learning curve for users and systems administrators.
* Compactness and terseness
- Less code generally means less bugs. We try to avoid the
+ Less code generally means fewer bugs. We try to avoid the
"line noise" stereotype of some Perl codebases, yet still
manage to write less code than one would with
non-scripting languages.
@@ -160,7 +159,7 @@ being used, they're just not interesting.
* Lightweight threading
While lightweight threading implementations are
- convenient, they tend to be significantly heavier than a
+ convenient, they tend to be significantly heavier than
pure event-loop systems (or multi-threaded event-loop
systems)
next reply other threads:[~2020-04-13 11:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 11:32 Eric Wong [this message]
2020-04-13 11:32 ` [PATCH v2 1/2] doc: add technical/whyperl Eric Wong
2020-04-13 11:32 ` [PATCH v2 2/2] doc: start reproducibility document Eric Wong
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://public-inbox.org/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200413113245.9282-1-e@yhbt.net \
--to=e@yhbt.net \
--cc=meta@public-inbox.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 public inbox
https://80x24.org/public-inbox.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).