The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: steffen@sdaoden.eu (Steffen Nurpmeso)
Subject: [TUHS] // comment in C++
Date: Fri, 10 Feb 2017 18:39:32 +0100	[thread overview]
Message-ID: <20170210173932.xRFc0%steffen@sdaoden.eu> (raw)
In-Reply-To: <201702092114.v19LEUgJ091850@tahoe.cs.Dartmouth.EDU>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7503 bytes --]

That is an honour to me, Mr. Doug McIlroy.

Doug McIlroy <doug at cs.dartmouth.edu> wrote:
 |With no offense intended, I can't help noting the irony of the
 |following paragraph appearing in a message in the company of
 |others that address Unix "bloat".

To me writing documentation is an enormous pain.  I find it
extraordinary hard to find the words to describe some technical
aspect to an imaginery broad audience of human beings.
It requires many iterations until i am somewhat satisfied, and, as
something like an excuse, this specific part is very fresh.

 |Except for the ISO citations, this paragraph says the same
 |thing more succinctly.
 |
 |'\cX'    represents a nonprintable character Y in terms of the
 |          printable character X whose binary code is obtained
 |          by adding 0x40 (decimal 64) to that for Y. (In some
 |          historical contexts, '^' plays the role of '\c'.)
 |          Alternative standard representations for certain
 |          nonprinting characters, e.g. '\a', '\n', '\t' above,
 |          are preferred by S-nail. '\c@' (NUL) serves as a
 |          string terminator regardless of following characters.
 |
 |And this version, 1/3 the length of the original, tells all
 |one really needs to know.
 |
 |'\cX'    represents a nonprintable character Y in terms of the
 |          printable character X whose binary code is obtained
 |          by adding 0x40 (decimal 64) to that for Y. '\c@'
 |          (NUL) serves as a string terminator regardless of
 |          following characters.

This is brief and concise.  The last sentence could not be used
like that, because the \c@ is an extension that, different to \0*,
\x0*, \[uU]0*, really terminates the entire argument list, not
"further output for the quoted argument".  I have to mark it as
a non-standard extension.  Thanks for pointing this out.

I am wondering.  Chekhov said:

  Ich glaube nicht an unsere Intelligenz, die heuchlerisch,
  falsch, hysterisch, ungebildet und faul ist, ich glaube ihr
  sogar dann nicht, wenn sie leidet und klagt, denn ihre
  Unterdrücker kommen doch aus ihrem eigenen Schoß. Ich glaube an
  den einzelnen Menschen, ich sehe die Rettung in den
  Einzelpersönlichkeiten[.]

  I don't believe in our Intelligence, that is insincere, false,
  hysterical, illiterate and lazy, i don't believe in it even when
  she [it] suffers and laments, because her [its] suppressors
  still come from her [its] own womb.  I believe in the individual
  Human, i see the Salvage in the Individual.

I know for sure that this last example of yours is too concise for
a broad audience, a "nonprintable character" without a describing
context is an anachronism.  To me the question is, in a world of
increasingly omnipresent trivialism, where the human being remains
just as hormone driven, and not in only a small propertion
somewhat unreflected, as it always has been, but becomes more and
more de-facto controllable, far, far beyond the purging sunday
morning thunderstorm from the pulpit (and here being optimistic,
and wearing western world glasses), faster, much faster than most
souls, and here the story of the African Expedition which was
beaten along by the white master, until after some days the
bearers refused to march on at any cost, to "wait for their souls
to catch up", are, so how to strengthen the individual with its,
that is my believe, as a Buddhist, sole obligation of doing that
step towards reflection, of self-awareness in a holistic whole.

I know the software i maintain is by far not where i want to see
it, also regarding the documentation.  For one we are by far not
powerful enough, other aspects are much too bloated.  We do not
yet fully comply to the POSIX standard.  But we slowly become more
reliable, also for non-interactive use cases.  And correct.  And
i refer to the not yet released version, which will be a step
forward, after one year and a half of what i call full-time
development.

I want us to move to a place where even an inexperienced user can
teach her- or himself, and gain -- hopefully -- satisfying results
simply by reading the manual.  To get a notion of what actually
happens, or at least a notion of the problems that are involved.
Or, at the very least, to get some hints to keep in mind for the
next time Internet is accessible or an experienced user can be
talked to etc.  I think that, and i want to see and have a lower
hurdle on the documentation side.  I get frustrated when i really
have to go Google, and cannot get any help, but see a nice and
stylish link asking whether "this page was helpful".  Or HTMLized
GNU info pages, with a paragraph per HTML page.  I think that such
behaviour increases aggression, increases the feeling of
inferiority, and if its under the surface.  It will at least try
to rise to the surface, one way or the other, that is programmed
in the afterbrain, or at a not too much higher level.  Some
intellegent millionairs and other alpha leaders may even think it
is funny to play with that, but i, for myself, reject that
direction.

It is a little bit ridiculous.
For now i end up with

  ‘\cX’    Emits the non-printable (ASCII and compatible) C0 con‐
           trol codes 0 (NUL) to 31 (US), and 127 (DEL).  Print‐
           able representations of ASCII control codes can be
           created by mapping them to a different part of the
           ASCII character set, which is possible by adding the
           number 64 for the codes 0 to 31, e.g., 7 (BEL) is ‘7 +
           64 = 71 = G’.  The real operation is a bitwise logical
           XOR with 64 (bit 7 set, see vexpr[253]), thus also
           covering code 127 (DEL), which is mapped to 63 (ques-
           tion mark): ‘vexpr ^ 127 64’.

           Whereas historically circumflex notation has often
           been used for visualization purposes of control codes,
           e.g., ‘^G’, the reverse solidus notation has been
           standardized: ‘\cG’.  Some control codes also have
           standardized (ISO 10646, ISO C) aliases, as shown
           above (e.g., ‘\a’, ‘\n’, ‘\t’): whenever such an alias
           exists it will be used for display purposes.  The con‐
           trol code NUL (‘\c@’, a non-standard extension) ends
           argument processing without producing further output.

The vexpr[253] is an active link.  (In a capable less(1).  And to
yet another new builtin command which performs arithmetic and
string operations, but we now have macros with arguments, and even
though we do not yet have loop control statements, managing
counters etc. may already be useful.  As an overall question, if
we would have a multi-process approach, like sam has, maybe we
could simply use a communication channel to some arbitrary shell
or awk script to perform such things.  But this software will see
its 39th birthday in six weeks and one day from now on, and it was
not designed that way.  So it is easier to have a 483 line `vexpr'
implementation.  It also does have saturated signed 64-bit
arithmetic.  And it provides the right error messages.  I do hope
the future will bring some size reduction again nonetheless, while
also providing better message access.  Or any access at all.  In
the end, it does not make sense to provide a clean program if it
is of no use at all, nor can be plugged together with other
programs to form a Unix pipe that provides something useful.
I hope for both, and that increasingly reliable.)

--steffen


  reply	other threads:[~2017-02-10 17:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 21:14 Doug McIlroy
2017-02-10 17:39 ` Steffen Nurpmeso [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-02-09 14:44 Noel Chiappa
2017-02-09 16:51 ` Steffen Nurpmeso
2017-02-09 19:36   ` Steffen Nurpmeso
     [not found] <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>
2017-02-09  0:03 ` Paul McJones
2017-02-09  2:28   ` Marc Rochkind
2017-02-09 13:11   ` Tony Finch
2017-02-08 18:06 ron minnich
2017-02-08 18:08 ` A. P. Garcia
2017-02-08 18:17 ` arnold
2017-02-08 23:39   ` Steve Johnson
2017-02-08 23:52     ` Dave Horsfall
2017-02-09  2:11       ` Corey Lindsly
2017-02-09  2:46         ` Dave Horsfall
2017-02-09  2:53           ` Corey Lindsly
2017-02-09  4:38           ` Warner Losh
2017-02-09  2:47       ` Steve Nickolas
2017-02-09  4:55         ` Steve Johnson
2017-02-09 11:59           ` Michael Kjörling
2017-02-09 21:56             ` Dave Horsfall
2017-02-10  0:17               ` Dan Cross
2017-02-10  1:58                 ` Dave Horsfall
2017-02-10  2:46                   ` Nemo
2017-02-10  2:49                     ` Dave Horsfall
2017-02-10  9:30                   ` arnold
2017-02-10  9:19               ` arnold
2017-02-09 12:18           ` Brantley Coile
2017-02-09 13:31             ` Nick Downing
2017-02-08 22:45 ` Greg 'groggy' Lehey
2017-02-08 22:50   ` Ron Natalie
2017-02-08 23:22     ` Greg 'groggy' Lehey
2017-02-09 12:12     ` Michael Kjörling
2017-02-09 12:26       ` Lars Brinkhoff
2017-02-09 14:37         ` Random832
2017-02-09 14:49           ` Random832
2017-02-09 12:31       ` Paul Ruizendaal
2017-02-09 13:07         ` Steffen Nurpmeso
2017-02-08 22:51   ` ron minnich
2017-02-08 23:22     ` Greg 'groggy' Lehey

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=20170210173932.xRFc0%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    /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.
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 NNTP newsgroup(s).