user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
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)
 

             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).