The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Lorinda Cherry
@ 2022-02-15 22:31 Douglas McIlroy
  2022-02-15 23:32 ` Steve Nickolas
                   ` (4 more replies)
  0 siblings, 5 replies; 63+ messages in thread
From: Douglas McIlroy @ 2022-02-15 22:31 UTC (permalink / raw)
  To: TUHS main list

Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.

As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.

Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.

Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.

She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.

First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.

Then came "form" and "fed", nominally a form-letter generator
and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.

Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.

Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.

By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.

Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.

Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.

You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.

When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.

Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.

In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.

Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.

Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.

Doug McIlroy

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
@ 2022-02-15 23:32 ` Steve Nickolas
  2022-02-15 23:43   ` Jim Capp
  2022-02-16  0:09 ` George Michaelson
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 63+ messages in thread
From: Steve Nickolas @ 2022-02-15 23:32 UTC (permalink / raw)
  To: TUHS main list

On Tue, 15 Feb 2022, Douglas McIlroy wrote:

> First came "dc", an unlimited-precision desk calculator,
> which is still a Unix staple 45 years on. Building on dc,
> she would later make "bc", which made unlimited precision
> available in familiar programming-language notation and became
> the interface of choice to dc.

In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice 
for quick calculations.

-uso.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 23:32 ` Steve Nickolas
@ 2022-02-15 23:43   ` Jim Capp
  2022-02-15 23:51     ` Larry McVoy
  0 siblings, 1 reply; 63+ messages in thread
From: Jim Capp @ 2022-02-15 23:43 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS main list

Ditto on bc, in Linux. 

> On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
> 
> On Tue, 15 Feb 2022, Douglas McIlroy wrote:
> 
>> First came "dc", an unlimited-precision desk calculator,
>> which is still a Unix staple 45 years on. Building on dc,
>> she would later make "bc", which made unlimited precision
>> available in familiar programming-language notation and became
>> the interface of choice to dc.
> 
> In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
> 
> -uso.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 23:43   ` Jim Capp
@ 2022-02-15 23:51     ` Larry McVoy
  2022-02-16  0:54       ` Will Senn
  0 siblings, 1 reply; 63+ messages in thread
From: Larry McVoy @ 2022-02-15 23:51 UTC (permalink / raw)
  To: Jim Capp; +Cc: TUHS main list

I do a ton of stuff in bc, it works well because when I get an answer
I didn't expect, I can scroll backward and see where I screwed up.

Nice writeup, Doug, I wish I had met her, she sounds like a super
substantial person.

On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote:
> Ditto on bc, in Linux. 
> 
> > On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
> > 
> > ???On Tue, 15 Feb 2022, Douglas McIlroy wrote:
> > 
> >> First came "dc", an unlimited-precision desk calculator,
> >> which is still a Unix staple 45 years on. Building on dc,
> >> she would later make "bc", which made unlimited precision
> >> available in familiar programming-language notation and became
> >> the interface of choice to dc.
> > 
> > In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
> > 
> > -uso.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
  2022-02-15 23:32 ` Steve Nickolas
@ 2022-02-16  0:09 ` George Michaelson
  2022-02-16  0:24   ` Dave Horsfall
  2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
  2022-02-16  0:35 ` Andrew Hume
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 63+ messages in thread
From: George Michaelson @ 2022-02-16  0:09 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

I wrote a major part of the UQ phone directory in EQN, to post process
T/Roff output so the existing bromide-mechanical printing braces for
grouping common phoneline holders could be done in the new
phototypesetter. Eqn was the tool which got me out of a self-dug hole
over-promising delivery of "print-equivalent" outcome here.

I use BC as a daily driver like most people. I never quite got DC, and
wondered at the duality of them. Very interesting to have the
background explained.

The trigraph spelling checker sounds wonderful.

Thanks for posting this.

_G

On Wed, Feb 16, 2022 at 8:35 AM Douglas McIlroy
<douglas.mcilroy@dartmouth.edu> wrote:
>
> Lorinda Cherry, a long-time member of the original Unix Lab
> died recently. Here is a slightly edited reminiscence that
> I sent to the president of the National Center for Women and
> Information Technology in 2018 when they honored her with
> their Pioneer in Tech award.
>
> As Lorinda Cherry's longtime colleague at Bell Labs, I was
> very pleased to hear she has been chosen for the NCWIT Pioneer
> Award. At the risk of telling you things you already know,
> I offer some remarks about her career. I will mainly speak of
> things I saw at first hand when our offices were two doors
> apart, from the early '70s through 1994, when Lorinda left
> Bell Labs in the AT&T/Lucent split. Most of the work I describe
> broke new ground in computing; "pioneer" is an apt term.
>
> Lorinda, like many women (including my own mother and my wife),
> had to fight the system to be allowed to study math and science
> in college. She was hired by Visual and Acoustics Research
> at Bell Labs as a TA--the typical fate of women graduates,
> while their male counterparts were hired as full members of
> technical staff. It would take another decade for that unequal
> treatment to be rectified. Even then, one year she received
> a statement of benefits that explained what her wife would
> receive upon her death. When Lorinda called HR to confirm that
> they meant spouse, they said no, and demanded that the notice
> be returned. (She declined.) It seemed that husbands would not
> get equal treatment until AT&T lost a current court case. The
> loss was a foregone conclusion; still AT&T preferred to pay
> lawyers rather than widowers, and fought it to the bitter end.
>
> Lorinda moved to my department in Computing Science when
> the Unix operating system was in its infancy. Initially she
> collaborated with Ken Knowlton on nascent graphics applications:
> Beflix, a system for producing artistically pixillated films,
> and an early program for rendering ball-and-stick molecular
> models.
>
> She then joined the (self-organized) Unix team, collaborating
> on several applications with Bob Morris.
>
> First came "dc", an unlimited-precision desk calculator,
> which is still a Unix staple 45 years on. Building on dc,
> she would later make "bc", which made unlimited precision
> available in familiar programming-language notation and became
> the interface of choice to dc.
>
> Then came "form" and "fed", nominally a form-letter generator
> and editor. In fact they were more of a personal memory
> bank, a step towards Vannevar Bush's famous Memex concept--an
> interesting try that didn't pay off at that scale. Memex had to
> sleep two more decades before mutating into the Worldwide Web.
>
> Lorinda had a hand in "typo", too, a Morris invention that
> found gross spelling mistakes by statistical analysis. Sorting
> the words of a document by the similarity of their trigrams
> to those in the rest of the document tended to bring typos to
> the front of the list. This worked remarkably well and gained
> popularity as a spell-checker until a much less interesting
> program backed by a big dictionary took over.
>
> Taken together, these initial forays foretold a productive
> computer science career centered around graphics, little
> languages, and text processing.
>
> By connecting a phototypesetter as an output device for Unix,
> Joe Ossanna initiated a revolution in document preparation. The
> new resource prompted a flurry of disparate looking documents
> until Mike Lesk brought order to the chaos by creating a macro
> package to produce a useful standard paper format.
>
> Taking over from Lesk, Lorinda observed the difficulty of
> typesetting the mathematics (which the printing industry counted
> as "penalty copy") that occurred in many research papers,
> and set out to simplify the task of rendering mathematical
> formulas, Brian Kernighan soon joined her effort. The result
> was "eqn", which built on the way people read formulas aloud
> to make a quite intuitive language for describing display
> formulas. Having pioneered a pattern that has been adopted
> throughout the industry, eqn is still in use forty years later.
>
> Lorinda also wrote an interpreter to render phototypesetter
> copy on a cathode-ray terminal. This allowed one to see
> typeset documents without the hassle of exposing and developing
> film. Though everyone has similar technology at their fingertips
> today, this was genuinely pioneering work at the time.
>
> You are certainly aware of Writers Workbench, which gained
> national publicity, including Lorinda's appearance on the Today
> Show. It all began as a one-woman skunk-works project. Noticing
> the very slow progress in natuaral-language processing, she
> identified a useful subtask that could be carved out of the
> larger problem: identifying parts of speech. Using a vocabulary
> of function words (articles, pronouns, prepositions and
> conjunctions) and rules of inflection, she was able to classify
> parts of speech in running text with impressive accuracy.
>
> When Rutgers professor William Vesterman proposed a
> style-assessing program, with measures such as the frequencies
> of adjectives, subordinate clauses, or compound sentences,
> Lorinda was able to harness her "parts" program to implement
> the idea in a couple of weeks. Subsequently Nina MacDonald,
> with Lorinda's support, incorporated it into a larger suite
> that checked and made suggestions about other stylistic issues
> such as cliches, malapropisms, and redundancy.
>
> Another aspect of text processing that Lorinda addressed was
> topic identification. Terms (often word pairs) that occur with
> abnormal frequency are likely to describe the topic at hand. She
> used this idea to construct first drafts of indexes. One
> in-house application was to the Unix manual, which up until
> that time had only a table of contents, but no index. This
> was a huge boon for a document so packed with detail.
>
> In her final years at Bell Labs, Lorinda teamed up with AT&T
> trouble-call centers to analyze the call transcripts that
> attendants recorded on the fly--very sketchy prose, replete
> with ad-hoc contractions and misspellings. The purpose was
> to identify systemic problems that would not be obvious from
> transcripts considered individually. When an unusual topic
> appeared at the same time in multiple transcripts, those
> transcripts were singled out for further study. The scheme
> worked and led to early detection of system anomalies. In one
> case, it led AT&T to suspend publication of a house organ that
> rubbed customers the wrong way.
>
> Lorinda was not cut from the same mold as most of her
> colleagues. First she was a woman, which meant she faced
> special obstacles. Then, while there were several pilots
> among us, there was only one shower of dogs and only one car
> racer--moreover one who became a regional exec of the Sports
> Car Club of America. For years she organized and officiated
> at races as well as participating.
>
> Lorinda was always determined, but never pushy. The
> determination shows in her success in text analysis, which
> involves much sheer grit--there are no theoretical shortcuts
> in this subject. She published little, but did a lot. I am
> glad to see her honored.
>
> Doug McIlroy

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  0:09 ` George Michaelson
@ 2022-02-16  0:24   ` Dave Horsfall
  2022-02-16  7:54     ` arnold
  2022-02-16 14:34     ` [TUHS] dc after bc Ralph Corderoy
  2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
  1 sibling, 2 replies; 63+ messages in thread
From: Dave Horsfall @ 2022-02-16  0:24 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 16 Feb 2022, George Michaelson wrote:

> I use BC as a daily driver like most people. I never quite got DC, and 
> wondered at the duality of them. Very interesting to have the background 
> explained.

You know you're a greybeard if you can remember why the DC sequence 
"99k2vp8opq" was so popular...

-- Dave

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
  2022-02-15 23:32 ` Steve Nickolas
  2022-02-16  0:09 ` George Michaelson
@ 2022-02-16  0:35 ` Andrew Hume
  2022-02-16  8:02 ` Thomas Paulsen
  2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
  4 siblings, 0 replies; 63+ messages in thread
From: Andrew Hume @ 2022-02-16  0:35 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

for many years, my office was diagonally opposite lorinda’s.
we worked together most closely on the Unix manuals
(ninth and tenth editions); lorinda spent considerable work
on the permuted indices and the papers on Volume 2.

she also shared in my my own weird story of synchronicity.
i had been doing some work on polyhedra composed of
regular polyhedra. to prove to myself that i had gotten things
correct, i constructed a folding program to form the polyhedra
by folding a flat network of faces. i did this in bc and verified that
the vertices were sufficiently close together. and indeed, as i increased
the precision, the points coincided. except one didn’t.
for one polyhedra, one vertex stubbornly never got closer
than about 1e-6 from its (supposedly) coincident alter points.
it took about 3-4 days before i found the problem; in some exceptionally
rare cases, division in bc yielded the wrong answer.
i race around to lorinda to show her the problem (it was in the underlying
dc code). to my astonishment, lorinda listened and said
“you know, not 30 minutes ago, Vic Vyssotsky (our executive director)
came in with exactly the same problem.” he had discovered it by using
an extremely long-winded cyclical calculation used to detect errors
in arithmetic units. she then discovered the bug occurred when she converted
the original assembler code into C. the weird part was that this bug
had been latent for some years, and two different people reported it
to her with 30 minutes.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 23:51     ` Larry McVoy
@ 2022-02-16  0:54       ` Will Senn
  2022-02-16  2:58         ` Steve Nickolas
  0 siblings, 1 reply; 63+ messages in thread
From: Will Senn @ 2022-02-16  0:54 UTC (permalink / raw)
  To: Larry McVoy, Jim Capp; +Cc: TUHS main list

bc is my all time favorite calculator. I feel incomplete whenever I sit 
down at a Windows machine and have to pull up the so-called calculator 
there. And nothing beats it for simple base conversion, either. As a 
front-end for dc it's fun to have students wonder about the dual 
processes, then show them how they work together. Really good example of 
the unix way of doing things. Too bad they went and combined them in 
recent days.


On 2/15/22 5:51 PM, Larry McVoy wrote:
> I do a ton of stuff in bc, it works well because when I get an answer
> I didn't expect, I can scroll backward and see where I screwed up.
>
> Nice writeup, Doug, I wish I had met her, she sounds like a super
> substantial person.
>
> On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote:
>> Ditto on bc, in Linux.
>>
>>> On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
>>>
>>> ???On Tue, 15 Feb 2022, Douglas McIlroy wrote:
>>>
>>>> First came "dc", an unlimited-precision desk calculator,
>>>> which is still a Unix staple 45 years on. Building on dc,
>>>> she would later make "bc", which made unlimited precision
>>>> available in familiar programming-language notation and became
>>>> the interface of choice to dc.
>>> In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
>>>
>>> -uso.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  0:54       ` Will Senn
@ 2022-02-16  2:58         ` Steve Nickolas
  0 siblings, 0 replies; 63+ messages in thread
From: Steve Nickolas @ 2022-02-16  2:58 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

On Tue, 15 Feb 2022, Will Senn wrote:

> bc is my all time favorite calculator. I feel incomplete whenever I sit down 
> at a Windows machine and have to pull up the so-called calculator there. And 
> nothing beats it for simple base conversion, either. As a front-end for dc 
> it's fun to have students wonder about the dual processes, then show them how 
> they work together. Really good example of the unix way of doing things. Too 
> bad they went and combined them in recent days.

You can use GNU's bc on Windows - that's what I do ;)

-uso.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  0:24   ` Dave Horsfall
@ 2022-02-16  7:54     ` arnold
  2022-02-16  8:13       ` markus schnalke
  2022-02-16 14:34     ` [TUHS] dc after bc Ralph Corderoy
  1 sibling, 1 reply; 63+ messages in thread
From: arnold @ 2022-02-16  7:54 UTC (permalink / raw)
  To: tuhs, dave

Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 16 Feb 2022, George Michaelson wrote:
>
> > I use BC as a daily driver like most people. I never quite got DC, and 
> > wondered at the duality of them. Very interesting to have the background 
> > explained.
>
> You know you're a greybeard if you can remember why the DC sequence 
> "99k2vp8opq" was so popular...
>
> -- Dave

I guess I'm not enough of a greybeard:

$ dc
99k2vp8opq
1.4142135623730950488016887242096980785696718753769480731766797379907\
32478462107038850387534327641572
1.3240474631771674622042627661154672512575174353366027242235650231664\
2753102603147144252257620301035270505416503

I recognize the first value as the square root of two. What is
the second value?

Thanks,

Arnold

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
                   ` (2 preceding siblings ...)
  2022-02-16  0:35 ` Andrew Hume
@ 2022-02-16  8:02 ` Thomas Paulsen
  2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
  4 siblings, 0 replies; 63+ messages in thread
From: Thomas Paulsen @ 2022-02-16  8:02 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: tuhs

I didn't know that. R.I.P great programmer!

--- Ursprüngliche Nachricht ---
Von: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Datum: 15.02.2022 23:31:03
An: TUHS main list <tuhs@minnie.tuhs.org>
Betreff: [TUHS] Lorinda Cherry

Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.

As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.

Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.

Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.

She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.

First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.

Then came "form" and "fed", nominally a form-letter generator

and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.

Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.

Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.

By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.

Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.

Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.

You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.

When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.

Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.

In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.

Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.

Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.

Doug McIlroy




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  7:54     ` arnold
@ 2022-02-16  8:13       ` markus schnalke
  2022-02-16 14:54         ` Leah Neukirchen
  0 siblings, 1 reply; 63+ messages in thread
From: markus schnalke @ 2022-02-16  8:13 UTC (permalink / raw)
  To: tuhs

Hoi.

[2022-02-16 00:54] arnold@skeeve.com
> Dave Horsfall <dave@horsfall.org> wrote:
> > On Wed, 16 Feb 2022, George Michaelson wrote:
> >
> > > I use BC as a daily driver like most people. I never quite got DC, and 
> > > wondered at the duality of them. Very interesting to have the background 
> > > explained.
> >
> > You know you're a greybeard if you can remember why the DC sequence 
> > "99k2vp8opq" was so popular...
> >
> > -- Dave
> 
> I guess I'm not enough of a greybeard:
> 
> $ dc
> 99k2vp8opq
> 1.4142135623730950488016887242096980785696718753769480731766797379907\
> 32478462107038850387534327641572
> 1.3240474631771674622042627661154672512575174353366027242235650231664\
> 2753102603147144252257620301035270505416503
> 
> I recognize the first value as the square root of two. What is
> the second value?

Decoding the program with the manpage:

	99k	set scaling factor to 99 (i.e. 99 digits on output)
	2v	square root of 2
	p	print it (but leave it on the stack)
	8o	switch to octal output
	p	print the same value (now in octal)
	q	quit

More interesting is the question why you need sqrt(2) in octal?


meillo

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [TUHS] Shower of Dogs.
  2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
                   ` (3 preceding siblings ...)
  2022-02-16  8:02 ` Thomas Paulsen
@ 2022-02-16 14:05 ` Ralph Corderoy
  2022-02-16 14:09   ` Andrew Hume
                     ` (2 more replies)
  4 siblings, 3 replies; 63+ messages in thread
From: Ralph Corderoy @ 2022-02-16 14:05 UTC (permalink / raw)
  To: TUHS; +Cc: Douglas McIlroy

Hi,

Doug wrote:
> Then, while there were several pilots among us,
> there was only one shower of dogs

What's a shower of dogs refer to in this context?

I've been mulling it over for a while.  I checked Wiktionary for shower
and dogs and nothing obvious pops out as to what the phrase may mean in
American to this English speaker.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
@ 2022-02-16 14:09   ` Andrew Hume
  2022-02-16 15:01     ` Larry McVoy
                       ` (2 more replies)
  2022-02-16 14:09   ` Chet Ramey
  2022-02-16 15:08   ` Rich Morin
  2 siblings, 3 replies; 63+ messages in thread
From: Andrew Hume @ 2022-02-16 14:09 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: TUHS, Douglas McIlroy

lorinda was an avid dog owner.
she spent a long time recycling racing greyhounds.
she would own a few of these at any one time

> On Feb 16, 2022, at 6:05 AM, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> 
> Hi,
> 
> Doug wrote:
>> Then, while there were several pilots among us,
>> there was only one shower of dogs
> 
> What's a shower of dogs refer to in this context?
> 
> I've been mulling it over for a while.  I checked Wiktionary for shower
> and dogs and nothing obvious pops out as to what the phrase may mean in
> American to this English speaker.
> 
> -- 
> Cheers, Ralph.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
  2022-02-16 14:09   ` Andrew Hume
@ 2022-02-16 14:09   ` Chet Ramey
  2022-02-16 14:35     ` Ron Natalie
  2022-02-16 14:41     ` Ralph Corderoy
  2022-02-16 15:08   ` Rich Morin
  2 siblings, 2 replies; 63+ messages in thread
From: Chet Ramey @ 2022-02-16 14:09 UTC (permalink / raw)
  To: Ralph Corderoy, TUHS; +Cc: Douglas McIlroy

On 2/16/22 9:05 AM, Ralph Corderoy wrote:
> Hi,
> 
> Doug wrote:
>> Then, while there were several pilots among us,
>> there was only one shower of dogs
> 
> What's a shower of dogs refer to in this context?

Someone who trains dogs and competes with them at dog shows.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [TUHS] dc after bc.
  2022-02-16  0:24   ` Dave Horsfall
  2022-02-16  7:54     ` arnold
@ 2022-02-16 14:34     ` Ralph Corderoy
  1 sibling, 0 replies; 63+ messages in thread
From: Ralph Corderoy @ 2022-02-16 14:34 UTC (permalink / raw)
  To: tuhs

Hi,

Dave Horsfall wrote:
> > I never quite got DC, and wondered at the duality of them.
>
> You know you're a greybeard if you can remember why the DC sequence
> "99k2vp8opq" was so popular...

I used to use bc, and still do when ‘a(1)*4’ would be useful, but moved
to dc because I didn't know it well and wanted to improve.  Plus reverse
Polish tends to better match what I want to enter.

But I think I'm missing the idiomatic way to use it; I'm puzzled there's
no command to print and pop the top of stack followed by a linefeed.

- ‘p’ prints the top of stack without popping it, and then linefeed.
- ‘n’ pops and prints the top of stack but without a linefeed.
- ‘f’ prints the stack, one number per line.
- ‘c’ clears the stack.

This means my multiple unrelated calculations tend to end with ‘pc’ as
otherwise the stack builds up and I might accidentally use old stuff on
the stack if the operators for this next sum don't push enough operands
of their own.

If I use n then the stack is popped, which I want, but the cursor
remains after the number.  I could see that's useful if the number was
still the top of stack because I could continue typing on the same line
to make use of it.

So I'm left with ‘pc’ or ‘fc’, or ‘n10P’.  Popping without printing is
‘ss’ or similar to store it in register s.  So ‘pss’ prints ToS and pops
just it, simpler than ‘n10P’.

How did dc's users balance printing the results with not building stack
detritus?

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:09   ` Chet Ramey
@ 2022-02-16 14:35     ` Ron Natalie
  2022-02-16 14:41     ` Ralph Corderoy
  1 sibling, 0 replies; 63+ messages in thread
From: Ron Natalie @ 2022-02-16 14:35 UTC (permalink / raw)
  To: chet.ramey, Ralph Corderoy, TUHS; +Cc: Douglas McIlroy

It helps to pronounce it with a long O.   As a SHOW - er of dogs, rather 
than shower like rain coming down.

------ Original Message ------
From: "Chet Ramey" <chet.ramey@case.edu>
To: "Ralph Corderoy" <ralph@inputplus.co.uk>; "TUHS" 
<tuhs@minnie.tuhs.org>
Cc: "Douglas McIlroy" <douglas.mcilroy@dartmouth.edu>
Sent: 2/16/2022 9:09:41 AM
Subject: Re: [TUHS] Shower of Dogs.

>On 2/16/22 9:05 AM, Ralph Corderoy wrote:
>>  Hi,
>>
>>  Doug wrote:
>>>  Then, while there were several pilots among us,
>>>  there was only one shower of dogs
>>
>>  What's a shower of dogs refer to in this context?
>
>Someone who trains dogs and competes with them at dog shows.
>
>--
>``The lyf so short, the craft so long to lerne.'' - Chaucer
>		 ``Ars longa, vita brevis'' - Hippocrates
>Chet Ramey, UTech, CWRU    chet@case.eduhttp://tiswww.cwru.edu/~chet/


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:09   ` Chet Ramey
  2022-02-16 14:35     ` Ron Natalie
@ 2022-02-16 14:41     ` Ralph Corderoy
  1 sibling, 0 replies; 63+ messages in thread
From: Ralph Corderoy @ 2022-02-16 14:41 UTC (permalink / raw)
  To: TUHS; +Cc: Douglas McIlroy

Chet wrote:
> Someone who trains dogs and competes with them at dog shows.

Ah, got it, thanks Chet, and the rest who responded on and off list.
We have dog shows, but I think they tend to have exhibitors parading
their charges; I didn't read it as shower as in show.  :-)

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  8:13       ` markus schnalke
@ 2022-02-16 14:54         ` Leah Neukirchen
  2022-02-16 22:27           ` Dave Horsfall
  2022-02-17 19:59           ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 2 replies; 63+ messages in thread
From: Leah Neukirchen @ 2022-02-16 14:54 UTC (permalink / raw)
  To: markus schnalke; +Cc: tuhs

markus schnalke <meillo@marmaro.de> writes:

> Hoi.
>
> [2022-02-16 00:54] arnold@skeeve.com
>> Dave Horsfall <dave@horsfall.org> wrote:
>> >
>> > You know you're a greybeard if you can remember why the DC sequence 
>> > "99k2vp8opq" was so popular...
>> >
>> > -- Dave
>> 
>> I guess I'm not enough of a greybeard:
>> 
>> $ dc
>> 99k2vp8opq
>> 1.4142135623730950488016887242096980785696718753769480731766797379907\
>> 32478462107038850387534327641572
>> 1.3240474631771674622042627661154672512575174353366027242235650231664\
>> 2753102603147144252257620301035270505416503
>> 
>> I recognize the first value as the square root of two. What is
>> the second value?
>
> Decoding the program with the manpage:
>
> 	99k	set scaling factor to 99 (i.e. 99 digits on output)
> 	2v	square root of 2
> 	p	print it (but leave it on the stack)
> 	8o	switch to octal output
> 	p	print the same value (now in octal)
> 	q	quit
>
> More interesting is the question why you need sqrt(2) in octal?

Apparently it was a popular benchmark back in the day:
https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf

> Tim Long: Quick Benchmarks of the Machines on Display
> A simple cpu-bound benchmark was run on each of the machines on display.
> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It uses dc
> (the desk calculator) to calculate the square root of 2 to 99 decimal places,
> and to "print" the result in decimal and then in octal. The results are in
> fact never printed, being piped to /dev/null. The user time is all that is
> compared.
> This benchmark has been applied to a large number of machines° It has
> (up until now) been useful because most manufacturers have not optimised dc,
> so the results are not likely to have been distorted by attempts to optimise
> for benchmarks.

> The results were:
> DoEo UNITY (DE-68K) 11.3 sec
> Plexus P/25 14.1 sec
> NCR Tower 21.3 sec
> Wicat 150WS 27.3 sec
> Unison 32.6 sec

> By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs
> range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19
> secs depending upon the presence of a cache. Perkin-Elmer range from 12o5
> secs (32/10) to 7°9 secs (32/40)o

I looks like V7 dc used 100-limbs internally, so printing in decimal
was fast, but printing in octal required conversion.

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:09   ` Andrew Hume
@ 2022-02-16 15:01     ` Larry McVoy
  2022-02-16 16:57     ` Douglas McIlroy
  2022-02-16 17:03     ` Dennis Boone
  2 siblings, 0 replies; 63+ messages in thread
From: Larry McVoy @ 2022-02-16 15:01 UTC (permalink / raw)
  To: Andrew Hume; +Cc: TUHS, Douglas McIlroy

On Wed, Feb 16, 2022 at 06:09:31AM -0800, Andrew Hume wrote:
> lorinda was an avid dog owner.
> she spent a long time recycling racing greyhounds.
> she would own a few of these at any one time

Good on her, I have a friend who does this.  Sweet dogs that deserve a
retirement.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
  2022-02-16 14:09   ` Andrew Hume
  2022-02-16 14:09   ` Chet Ramey
@ 2022-02-16 15:08   ` Rich Morin
  2022-02-16 21:21     ` Dave Horsfall
  2 siblings, 1 reply; 63+ messages in thread
From: Rich Morin @ 2022-02-16 15:08 UTC (permalink / raw)
  To: TUHS

> On Feb 16, 2022, at 06:05, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> 
> Doug wrote:
>> while there were several pilots among us, there was only one shower of dogs.
> 
> What's a shower of dogs refer to in this context?

To understand this, you have to know the American idiom "raining cats and dogs".  A "shower of dogs" is thus a heavy burst of large drops, which would of course be of concern to a pilot (:-).

-r


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:09   ` Andrew Hume
  2022-02-16 15:01     ` Larry McVoy
@ 2022-02-16 16:57     ` Douglas McIlroy
  2022-02-16 17:03     ` Dennis Boone
  2 siblings, 0 replies; 63+ messages in thread
From: Douglas McIlroy @ 2022-02-16 16:57 UTC (permalink / raw)
  To: Andrew Hume; +Cc: TUHS

Lorinda kept dobermans as household pets and show dogs. She even had
an RV for taking them to exhibit in distant shows. She eventually
switched to rescuing retired racing greyhounds and sold the RV.

Doug

On Wed, Feb 16, 2022 at 9:09 AM Andrew Hume <andrew@humeweb.com> wrote:
>
> lorinda was an avid dog owner.
> she spent a long time recycling racing greyhounds.
> she would own a few of these at any one time
>
> > On Feb 16, 2022, at 6:05 AM, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> >
> > Hi,
> >
> > Doug wrote:
> >> Then, while there were several pilots among us,
> >> there was only one shower of dogs
> >
> > What's a shower of dogs refer to in this context?
> >
> > I've been mulling it over for a while.  I checked Wiktionary for shower
> > and dogs and nothing obvious pops out as to what the phrase may mean in
> > American to this English speaker.
> >
> > --
> > Cheers, Ralph.
>

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 14:09   ` Andrew Hume
  2022-02-16 15:01     ` Larry McVoy
  2022-02-16 16:57     ` Douglas McIlroy
@ 2022-02-16 17:03     ` Dennis Boone
  2022-02-16 17:18       ` Warner Losh
  2 siblings, 1 reply; 63+ messages in thread
From: Dennis Boone @ 2022-02-16 17:03 UTC (permalink / raw)
  To: TUHS

Between envisioning the rain of canines and the recycled greyhounds,
this thread has provided me with several pre-caffeinated smiles so far.
Thanks all!

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 17:03     ` Dennis Boone
@ 2022-02-16 17:18       ` Warner Losh
  0 siblings, 0 replies; 63+ messages in thread
From: Warner Losh @ 2022-02-16 17:18 UTC (permalink / raw)
  To: Dennis Boone; +Cc: TUHS

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

On Wed, Feb 16, 2022 at 10:15 AM Dennis Boone <drb@msu.edu> wrote:

> Between envisioning the rain of canines and the recycled greyhounds,
> this thread has provided me with several pre-caffeinated smiles so far.
>

Indeed. Reading it as a description of weather at first left me baffled.
But knowing it
is more of a title makes it make more sense.

Warner

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16  0:09 ` George Michaelson
  2022-02-16  0:24   ` Dave Horsfall
@ 2022-02-16 19:08   ` Diomidis Spinellis
  2022-02-16 20:55     ` John P. Linderman
                       ` (2 more replies)
  1 sibling, 3 replies; 63+ messages in thread
From: Diomidis Spinellis @ 2022-02-16 19:08 UTC (permalink / raw)
  To: TUHS main list

A description of text processing work at Bell Labs, including the use of 
trigrams for spell checking, readability analysis, and word class 
assignment was published in the BSTJ.

L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The 
Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
DOI: 10.1002/j.1538-7305.1978.tb02146.x

You can find it openly available online at:
https://archive.org/details/bstj57-6-2137/mode/2up

The article was part of an amazing special issue of BSTJ devoted to 
Unix.  A second such issue, 63(8) was published on October 1984.  In the 
late 1980s both issues were also sold as books by Prentice Hall under 
the title "UNIX System Readings and Applications".  I broke the bank 
buying them as a student, but didn't regret it.

Diomidis - https://www.spinellis.gr

On 16-Feb-22 2:09, George Michaelson wrote:
> The trigraph spelling checker sounds wonderful.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
@ 2022-02-16 20:55     ` John P. Linderman
  2022-02-16 21:17       ` Andrew Hume
  2022-02-16 21:59       ` Marshall Conover
  2022-02-17  5:51     ` arnold
  2022-02-17 22:09     ` Will Senn
  2 siblings, 2 replies; 63+ messages in thread
From: John P. Linderman @ 2022-02-16 20:55 UTC (permalink / raw)
  To: Diomidis Spinellis; +Cc: TUHS main list

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

Someone unearthed a 1982 video in which Lorinda explains some of her work.

https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s

You can watch the whole thing by just lopping off the '&t=828s' at the end.

On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis <dds@aueb.gr> wrote:

> A description of text processing work at Bell Labs, including the use of
> trigrams for spell checking, readability analysis, and word class
> assignment was published in the BSTJ.
>
> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The
> Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>
> You can find it openly available online at:
> https://archive.org/details/bstj57-6-2137/mode/2up
>
> The article was part of an amazing special issue of BSTJ devoted to
> Unix.  A second such issue, 63(8) was published on October 1984.  In the
> late 1980s both issues were also sold as books by Prentice Hall under
> the title "UNIX System Readings and Applications".  I broke the bank
> buying them as a student, but didn't regret it.
>
> Diomidis - https://www.spinellis.gr
>
> On 16-Feb-22 2:09, George Michaelson wrote:
> > The trigraph spelling checker sounds wonderful.
>

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 20:55     ` John P. Linderman
@ 2022-02-16 21:17       ` Andrew Hume
  2022-02-16 21:59       ` Marshall Conover
  1 sibling, 0 replies; 63+ messages in thread
From: Andrew Hume @ 2022-02-16 21:17 UTC (permalink / raw)
  To: John P. Linderman; +Cc: TUHS main list

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

what a hoot of a program!!
so many folks: john mashey, vi vyssocki[sic], denis, thommo,
lorinda, cathi brooks (my second supervisor at the labs, system 3 days),
kernighan, al aho.

> On Feb 16, 2022, at 12:55 PM, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> Someone unearthed a 1982 video in which Lorinda explains some of her work.
> 
> https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s <https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s>
> 


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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 15:08   ` Rich Morin
@ 2022-02-16 21:21     ` Dave Horsfall
  2022-02-16 21:25       ` John Cowan
  0 siblings, 1 reply; 63+ messages in thread
From: Dave Horsfall @ 2022-02-16 21:21 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 16 Feb 2022, Rich Morin wrote:

> To understand this, you have to know the American idiom "raining cats 
> and dogs".  A "shower of dogs" is thus a heavy burst of large drops, 
> which would of course be of concern to a pilot (:-).

Also used in British/Australian English; the Americans probably picked it 
up from the British.

-- Dave, who is British/Australian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 21:21     ` Dave Horsfall
@ 2022-02-16 21:25       ` John Cowan
  2022-02-17  3:31         ` Chet Ramey
  0 siblings, 1 reply; 63+ messages in thread
From: John Cowan @ 2022-02-16 21:25 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

On Wed, Feb 16, 2022 at 4:23 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 16 Feb 2022, Rich Morin wrote:
>
> > To understand this, you have to know the American idiom "raining cats
> > and dogs".  A "shower of dogs" is thus a heavy burst of large drops,
> > which would of course be of concern to a pilot (:-).
>
> Also used in British/Australian English; the Americans probably picked it
> up from the British.


What is worse than raining cats and dogs?

Hailing taxis;

>
>

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 20:55     ` John P. Linderman
  2022-02-16 21:17       ` Andrew Hume
@ 2022-02-16 21:59       ` Marshall Conover
  1 sibling, 0 replies; 63+ messages in thread
From: Marshall Conover @ 2022-02-16 21:59 UTC (permalink / raw)
  To: John P. Linderman; +Cc: TUHS main list

Oh wow - a week or two ago I linked this video to a coworker who asked
me how to "get into" nix systems when he saw me chaining a few
commands together with pipes. Lorinda's section was one of the ones I
pointed to as 'definitely pay hard attention to this bit' - well,
maybe up until the coffee sipping with the numbers being read out. (Of
course, that's not to say the rest of the video isn't important!)

Thanks all for sharing your memories.

Cheers,

Marshall


On Wed, Feb 16, 2022 at 4:02 PM John P. Linderman <jpl.jpl@gmail.com> wrote:
>
> Someone unearthed a 1982 video in which Lorinda explains some of her work.
>
> https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s
>
> You can watch the whole thing by just lopping off the '&t=828s' at the end.
>
> On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis <dds@aueb.gr> wrote:
>>
>> A description of text processing work at Bell Labs, including the use of
>> trigrams for spell checking, readability analysis, and word class
>> assignment was published in the BSTJ.
>>
>> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The
>> Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
>> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>>
>> You can find it openly available online at:
>> https://archive.org/details/bstj57-6-2137/mode/2up
>>
>> The article was part of an amazing special issue of BSTJ devoted to
>> Unix.  A second such issue, 63(8) was published on October 1984.  In the
>> late 1980s both issues were also sold as books by Prentice Hall under
>> the title "UNIX System Readings and Applications".  I broke the bank
>> buying them as a student, but didn't regret it.
>>
>> Diomidis - https://www.spinellis.gr
>>
>> On 16-Feb-22 2:09, George Michaelson wrote:
>> > The trigraph spelling checker sounds wonderful.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 14:54         ` Leah Neukirchen
@ 2022-02-16 22:27           ` Dave Horsfall
  2022-02-16 22:40             ` Andrew Diller
                               ` (2 more replies)
  2022-02-17 19:59           ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 3 replies; 63+ messages in thread
From: Dave Horsfall @ 2022-02-16 22:27 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

On Wed, 16 Feb 2022, Leah Neukirchen wrote:

> Apparently it was a popular benchmark back in the day:
> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf

Yep.

> > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
> > uses dc (the desk calculator) to calculate the square root of 2 to 99 
> > decimal places,

Ugh; that "I" ought to be "|" (and I can see other typos), so someone 
really needs to proofread those PDF scans if they're going to be regarded 
as authoritative.  Yes, I can help...

> > This benchmark has been applied to a large number of machines° It has 
> > (up until now) been useful because most manufacturers have not 
> > optimised dc, so the results are not likely to have been distorted by 
> > attempts to optimise for benchmarks.

Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being 
used and optimised for it...  Wasn't all that long ago that vehicle 
manufacturers also started doing the same thing :-)

> > Wicat 150WS 27.3 sec
> > Unison 32.6 sec

The WICAT 150 was just a terminal with several serial ports, and was 
p*ss-awful (I worked for Lionel Singer, and had to support the poxy 
thing); I'm surprised that it beat another box, though...

> I looks like V7 dc used 100-limbs internally, so printing in decimal was 
> fast, but printing in octal required conversion.

Yep; extra work for the CPU.  Not much of a benchmark these days, as CPUs 
are really fast; when I was supporting Unify I used to use its automatic 
tutorial as a benchmark, and I used to joke that I needed a calendar on 
some boxes...

Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up 
at an AUUG conference, giggling whenever someone tried that benchmark; 
what they didn't know was that the prominent window was actually an 
"rlogin" to the Gould that we also sold...  The looks on their faces were 
priceless :-)

-- Dave

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:27           ` Dave Horsfall
@ 2022-02-16 22:40             ` Andrew Diller
  2022-02-17 10:14               ` Peter Jeremy via TUHS
  2022-02-17 10:24               ` Andy Kosela
  2022-02-16 22:42             ` Larry McVoy
  2022-02-17 12:36             ` [TUHS] Lorinda Cherry Stuart Remphrey
  2 siblings, 2 replies; 63+ messages in thread
From: Andrew Diller @ 2022-02-16 22:40 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society



> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> 
>> Apparently it was a popular benchmark back in the day:
>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> 
> Yep.
> 
>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 
>>> decimal places,
> 

I tried that on some of the systems I have at hand. It didn't even register on my Mac....


-------------------------------------------------

33 MHZ MIPS R3010
# echo 99k2vp8opq | /bin/time dc > /dev/null

real        0.4
user        0.3
sys         0.0
# uname -a
power power 3.3.2 12031609 IP7

-------------------------------------------------

900 MHZ MIPS R160000
$ echo 99k2vp8opq | /bin/time dc > /dev/null

real 0.009
user 0.003
sys  0.002
dillera@fuel ~ $ uname -a
IRIX64 fuel 6.5 07202013 IP35 mips IP35 Irix

-------------------------------------------------

3.5GHZ Xeon E5
$ echo 99k2vp8opq | time dc > /dev/null
        0.00 real         0.00 user         0.00 sys

dillera@trashcan ~ $ uname -a
Darwin trashcan 20.6.0 Darwin Kernel Version 20.6.0: root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

-------------------------------------------------


-andy



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:27           ` Dave Horsfall
  2022-02-16 22:40             ` Andrew Diller
@ 2022-02-16 22:42             ` Larry McVoy
  2022-02-16 22:56               ` Clem Cole
  2022-02-16 23:49               ` [TUHS] Benchmarks Bakul Shah
  2022-02-17 12:36             ` [TUHS] Lorinda Cherry Stuart Remphrey
  2 siblings, 2 replies; 63+ messages in thread
From: Larry McVoy @ 2022-02-16 22:42 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote:
> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being 
> used and optimised for it...  Wasn't all that long ago that vehicle 
> manufacturers also started doing the same thing :-)

Indeed.  I hated when people cheated because benchmarks should teach you
the capabilities of the machine being benchmarked.  They aren't useful
if people cheat.

When I did LMbench, the rules were "cc -O2" and you could not link with
any benchmarking libraries and you could only report a result if you
reported all results.

I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he
had some toy OS that didn't have a VM system, didn't have networking,
didn't have much of anything, but boy oh boy, did it context switch
fast (because there was no context to speak of).  He reported those
numbers in blatant violation of my rules and I had to escalate to 
get him to stop.  The bummer is he is a smart guy, capable of good
work, there is no need to cheat.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:42             ` Larry McVoy
@ 2022-02-16 22:56               ` Clem Cole
  2022-02-16 23:49                 ` Paul Winalski
  2022-02-16 23:49               ` [TUHS] Benchmarks Bakul Shah
  1 sibling, 1 reply; 63+ messages in thread
From: Clem Cole @ 2022-02-16 22:56 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

And before that, Fortran compilers were known to recognize Whetstone.
Mashey did his wonder talk called 'Lies, Damn Lies and Benchmarks' in the
mid-80s which begat the SPEC suite.  Wasn't perfect but it did help.
 Marketing people in particular like to grab a single number for 'goodness'
just to try to show mine is better than yours (my current disgust has been
the clock rate of the processors which sadly, my employer was one of the
worst in using as a figure of merit).

On Wed, Feb 16, 2022 at 5:44 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote:
> > Indeed, when a lot of compilers recognised the Sieve of Eratosthenes
> being
> > used and optimised for it...  Wasn't all that long ago that vehicle
> > manufacturers also started doing the same thing :-)
>
> Indeed.  I hated when people cheated because benchmarks should teach you
> the capabilities of the machine being benchmarked.  They aren't useful
> if people cheat.
>
> When I did LMbench, the rules were "cc -O2" and you could not link with
> any benchmarking libraries and you could only report a result if you
> reported all results.
>
> I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he
> had some toy OS that didn't have a VM system, didn't have networking,
> didn't have much of anything, but boy oh boy, did it context switch
> fast (because there was no context to speak of).  He reported those
> numbers in blatant violation of my rules and I had to escalate to
> get him to stop.  The bummer is he is a smart guy, capable of good
> work, there is no need to cheat.
>

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:56               ` Clem Cole
@ 2022-02-16 23:49                 ` Paul Winalski
  0 siblings, 0 replies; 63+ messages in thread
From: Paul Winalski @ 2022-02-16 23:49 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On 2/16/22, Clem Cole <clemc@ccc.com> wrote:
>  Marketing people in particular like to grab a single number for 'goodness'
> just to try to show mine is better than yours (my current disgust has been
> the clock rate of the processors which sadly, my employer was one of the
> worst in using as a figure of merit).
>
That, and instructions/second.  The IBM S/370 model 158 was a true 1
MIPS machine.  The VAX-11/780 executed about 500 KIPS.  But the 11/780
and the model 158 were almost a dead heat when it came to the
execution speed of real world applications.  Why?  Mainly because the
VAX architecture was a lot CISC-ier than S/370, which was basically a
load/compute/store architecture.  The VAX got a lot more done with
each individeual instruction than the S/370.

-Paul W.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [TUHS] Benchmarks....
  2022-02-16 22:42             ` Larry McVoy
  2022-02-16 22:56               ` Clem Cole
@ 2022-02-16 23:49               ` Bakul Shah
  2022-02-17  1:02                 ` Larry McVoy
  1 sibling, 1 reply; 63+ messages in thread
From: Bakul Shah @ 2022-02-16 23:49 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society



> On Feb 16, 2022, at 2:42 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote:
>> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being 
>> used and optimised for it...  Wasn't all that long ago that vehicle 
>> manufacturers also started doing the same thing :-)
> 
> Indeed.  I hated when people cheated because benchmarks should teach you
> the capabilities of the machine being benchmarked.  They aren't useful
> if people cheat.
> 
> When I did LMbench, the rules were "cc -O2" and you could not link with
> any benchmarking libraries and you could only report a result if you
> reported all results.
> 
> I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he
> had some toy OS that didn't have a VM system, didn't have networking,
> didn't have much of anything, but boy oh boy, did it context switch
> fast (because there was no context to speak of).  He reported those
> numbers in blatant violation of my rules and I had to escalate to 
> get him to stop.  The bummer is he is a smart guy, capable of good
> work, there is no need to cheat.

My guess is, it was EROS, based on KeyKOS (or GNOSIS), a capability
OS. It used the VM hardware to enforce capabilities so I imagine
it did have a VM system!

http://flint.cs.yale.edu/cs428/doc/eros.pdf

The paper does say "microbenchmarks ... inspired by those of 
lmbench". My guess is Jon Shapiro wanted to show off his system's
nimbleness. Should not be seen as an apples to apples comparison
with commercial Unix systems.

[Don't want to reopen a microkernel/capability system discussion
 here though]



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Benchmarks....
  2022-02-16 23:49               ` [TUHS] Benchmarks Bakul Shah
@ 2022-02-17  1:02                 ` Larry McVoy
  0 siblings, 0 replies; 63+ messages in thread
From: Larry McVoy @ 2022-02-17  1:02 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

On Wed, Feb 16, 2022 at 03:49:18PM -0800, Bakul Shah wrote:
> My guess is, it was EROS, based on KeyKOS (or GNOSIS), a capability
> OS. It used the VM hardware to enforce capabilities so I imagine
> it did have a VM system!
> 
> http://flint.cs.yale.edu/cs428/doc/eros.pdf
> 
> The paper does say "microbenchmarks ... inspired by those of 
> lmbench". My guess is Jon Shapiro wanted to show off his system's
> nimbleness. Should not be seen as an apples to apples comparison
> with commercial Unix systems.

"inspired" == blatent ripoff to get around the reporting rules of LMbench.
I had pretty harsh words with Jon, that paper should never have been
published, he ripped off the benchmarks and published some of the results
without all of them.

You'll note that Eros is pretty dead, nothing came of it.  It was an 
academic thing in search of a problem and Jon had to cheat to make it
look good.  It's not a good look on him, color me very disappointed
but it isn't the first time some pointy headed PhD dude claimed a
bunch of stuff that wasn't quite true.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Shower of Dogs.
  2022-02-16 21:25       ` John Cowan
@ 2022-02-17  3:31         ` Chet Ramey
  0 siblings, 0 replies; 63+ messages in thread
From: Chet Ramey @ 2022-02-17  3:31 UTC (permalink / raw)
  To: John Cowan, Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On 2/16/22 4:25 PM, John Cowan wrote:

> What is worse than raining cats and dogs?
> 
> Hailing taxis;

No one can argue with this.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
  2022-02-16 20:55     ` John P. Linderman
@ 2022-02-17  5:51     ` arnold
  2022-02-17 22:09     ` Will Senn
  2 siblings, 0 replies; 63+ messages in thread
From: arnold @ 2022-02-17  5:51 UTC (permalink / raw)
  To: tuhs, dds

Diomidis Spinellis <dds@aueb.gr> wrote:

> The article was part of an amazing special issue of BSTJ devoted to 
> Unix.  A second such issue, 63(8) was published on October 1984.

I have original copies of both, bought directly from Bell Labs, back
in the day. :-)

I should dig them out and go through them again.

Arnold

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:40             ` Andrew Diller
@ 2022-02-17 10:14               ` Peter Jeremy via TUHS
  2022-02-17 15:50                 ` Adam Thornton
  2022-02-17 10:24               ` Andy Kosela
  1 sibling, 1 reply; 63+ messages in thread
From: Peter Jeremy via TUHS @ 2022-02-17 10:14 UTC (permalink / raw)
  To: Andrew Diller; +Cc: The Eunuchs Hysterical Society

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

On 2022-Feb-16 17:40:18 -0500, Andrew Diller <dillera@gmail.com> wrote:
>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
>> 
>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>> 
>>> Apparently it was a popular benchmark back in the day:
>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>> 
>> Yep.
>> 
>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 
>>>> decimal places,
>> 
>
>I tried that on some of the systems I have at hand. It didn't even register on my Mac....

Not only didn't it register on my Ryzen 3, it didn't even register on
2.11BSD running in simh on that box.

I did get a non-zero reading on an original RPi:
$ echo 99k2vp8opq | time dc > /dev/null
        0.13 real         0.10 user         0.02 sys

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:40             ` Andrew Diller
  2022-02-17 10:14               ` Peter Jeremy via TUHS
@ 2022-02-17 10:24               ` Andy Kosela
  2022-02-17 16:05                 ` Andrew Hume
  1 sibling, 1 reply; 63+ messages in thread
From: Andy Kosela @ 2022-02-17 10:24 UTC (permalink / raw)
  To: Andrew Diller; +Cc: The Eunuchs Hysterical Society

On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com> wrote:
>
>
>
> > On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> >
> > On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> >
> >> Apparently it was a popular benchmark back in the day:
> >> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> >
> > Yep.
> >
> >>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> >>> uses dc (the desk calculator) to calculate the square root of 2 to 99
> >>> decimal places,
> >
>
> I tried that on some of the systems I have at hand. It didn't even register on my Mac....

This would be more appropriate on modern machines:

moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
> /dev/null
machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
real         1.87
user         1.87
sys          0.00

--Andy

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 22:27           ` Dave Horsfall
  2022-02-16 22:40             ` Andrew Diller
  2022-02-16 22:42             ` Larry McVoy
@ 2022-02-17 12:36             ` Stuart Remphrey
  2 siblings, 0 replies; 63+ messages in thread
From: Stuart Remphrey @ 2022-02-17 12:36 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

Sad news. Had read her papers in BSTJ early in my career. Very interesting
to read of her career, and thanks for the links.

I'm a daily/weekly "dc" guy (RPN ftw).
Never got into bc. Occasionally used eqn et al.

-----
> Wicat 150WS 27.3 sec
> Unison 32.6 sec
Unison must have been real slow!

Dave H. -- remember LSC's ads/posters:
    "WICAT with *new* GLTC Technology"
Lionel/someone just made up the term.
For a while no-one asked, eventually it was revealed to stand for "Goes
Like The Clappers". ("A Wet Week" more like it)

Fortunately I supported the Unix stuff from LSC Brisbane/Qld. So in my
first UNIX job I got to play with Sun2-Sun4, lots'a Pyramids, one Convex.
Don't recall LSC's Gould though; before I joined?

When our sales reps sold WICAT (68000 or 68020?) it was mostly running PICK
ported by a bloke in our office (another Dave? I recall him destroying a
phone in frustration over the UART/terminal driver). Weird O/S: efficient
on-disk hashed DB; but very prone to corruption on unclean shutdown.

On Thu, 17 Feb 2022, 06:30 Dave Horsfall, <dave@horsfall.org> wrote:

> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>
> > Apparently it was a popular benchmark back in the day:
> > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>
> Yep.
>
> > > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> > > uses dc (the desk calculator) to calculate the square root of 2 to 99
> > > decimal places,
>
> Ugh; that "I" ought to be "|" (and I can see other typos), so someone
> really needs to proofread those PDF scans if they're going to be regarded
> as authoritative.  Yes, I can help...
>
> > > This benchmark has been applied to a large number of machines° It has
> > > (up until now) been useful because most manufacturers have not
> > > optimised dc, so the results are not likely to have been distorted by
> > > attempts to optimise for benchmarks.
>
> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being
> used and optimised for it...  Wasn't all that long ago that vehicle
> manufacturers also started doing the same thing :-)
>
> > > Wicat 150WS 27.3 sec
> > > Unison 32.6 sec
>
> The WICAT 150 was just a terminal with several serial ports, and was
> p*ss-awful (I worked for Lionel Singer, and had to support the poxy
> thing); I'm surprised that it beat another box, though...
>
> > I looks like V7 dc used 100-limbs internally, so printing in decimal was
> > fast, but printing in octal required conversion.
>
> Yep; extra work for the CPU.  Not much of a benchmark these days, as CPUs
> are really fast; when I was supporting Unify I used to use its automatic
> tutorial as a benchmark, and I used to joke that I needed a calendar on
> some boxes...
>
> Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up
> at an AUUG conference, giggling whenever someone tried that benchmark;
> what they didn't know was that the prominent window was actually an
> "rlogin" to the Gould that we also sold...  The looks on their faces were
> priceless :-)
>
> -- Dave

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 10:14               ` Peter Jeremy via TUHS
@ 2022-02-17 15:50                 ` Adam Thornton
  2022-02-17 20:23                   ` Dave Horsfall
  0 siblings, 1 reply; 63+ messages in thread
From: Adam Thornton @ 2022-02-17 15:50 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

Today I learned that "time" is a shell built-in in zsh!

adam@m1-wired:~$ echo 99k2vp8opq | time dc > /dev/null
dc > /dev/null  0.00s user 0.01s system 69% cpu 0.011 total

(M1 MacBook Air, late 2020, MacOS 12.2.1)

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 10:24               ` Andy Kosela
@ 2022-02-17 16:05                 ` Andrew Hume
  2022-02-17 16:38                   ` Warner Losh
  0 siblings, 1 reply; 63+ messages in thread
From: Andrew Hume @ 2022-02-17 16:05 UTC (permalink / raw)
  To: Andy Kosela; +Cc: The Eunuchs Hysterical Society

altho i date back to those days, i don’t recall using that benchmark.
when i’ve needed something bc-ish to take some time, i normally
use a bessel function from bc -l

> On Feb 17, 2022, at 2:24 AM, Andy Kosela <akosela@andykosela.com> wrote:
> 
> On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com> wrote:
>> 
>> 
>> 
>>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
>>> 
>>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>>> 
>>>> Apparently it was a popular benchmark back in the day:
>>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>>> 
>>> Yep.
>>> 
>>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
>>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99
>>>>> decimal places,
>>> 
>> 
>> I tried that on some of the systems I have at hand. It didn't even register on my Mac....
> 
> This would be more appropriate on modern machines:
> 
> moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
>> /dev/null
> machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
> real         1.87
> user         1.87
> sys          0.00
> 
> --Andy


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 16:05                 ` Andrew Hume
@ 2022-02-17 16:38                   ` Warner Losh
  0 siblings, 0 replies; 63+ messages in thread
From: Warner Losh @ 2022-02-17 16:38 UTC (permalink / raw)
  To: Andrew Hume; +Cc: The Eunuchs Hysterical Society

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

Damn, you guys found a bug in my venix emulation:

% echo 99k2vp8opq | ./git/venix/tools/vm86venix/venix
./git/venix/tools/vm86venix/disbt/usr/bin/dc
pid 70803 (venix): sigreturn eflags = 0x0

I'll have to see how hard it is to setup my Rainbow 100B running Venix and
if the benchmark works there or not.
Or if this is a bug in venix's dc...

Warner

On Thu, Feb 17, 2022 at 9:33 AM Andrew Hume <andrew@humeweb.com> wrote:

> altho i date back to those days, i don’t recall using that benchmark.
> when i’ve needed something bc-ish to take some time, i normally
> use a bessel function from bc -l
>
> > On Feb 17, 2022, at 2:24 AM, Andy Kosela <akosela@andykosela.com> wrote:
> >
> > On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com>
> wrote:
> >>
> >>
> >>
> >>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> >>>
> >>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> >>>
> >>>> Apparently it was a popular benchmark back in the day:
> >>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> >>>
> >>> Yep.
> >>>
> >>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> >>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99
> >>>>> decimal places,
> >>>
> >>
> >> I tried that on some of the systems I have at hand. It didn't even
> register on my Mac....
> >
> > This would be more appropriate on modern machines:
> >
> > moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
> >> /dev/null
> > machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
> > real         1.87
> > user         1.87
> > sys          0.00
> >
> > --Andy
>
>

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 14:54         ` Leah Neukirchen
  2022-02-16 22:27           ` Dave Horsfall
@ 2022-02-17 19:59           ` Tom Ivar Helbekkmo via TUHS
  2022-02-17 21:18             ` Dave Horsfall
  1 sibling, 1 reply; 63+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-02-17 19:59 UTC (permalink / raw)
  To: TUHS

Leah Neukirchen <leah@vuxu.org> writes:

> Apparently it was a popular benchmark back in the day:
> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>> [...]
>> By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs
>> range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19
>> secs depending upon the presence of a cache. Perkin-Elmer range from 12o5
>> secs (32/10) to 7°9 secs (32/40)o

Well, I just had to run it on some older hardware...

12MHz 80286 running MINIX 1.6.25 and the classic C version of dc:
real        4.00
user        3.56
sys         0.25

DEC MicroPDP-11/23 running PWB UNIX 1.0 and the assembly coded dc:
real       29.0
user       22.2
sys         0.7

Watching the prime number generator (from the Wikipedia page on dc)
running on the 11/23 is much more entertaining than doing it on the
modern workstation I'm typing this on:

2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x

Incidentally, the Wikipedia page only lists Robert Morris as author of
dc.  If anyone here is able to edit Wikipedia, now would be a good time
to get Lorinda Cherry's name on there, too.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 15:50                 ` Adam Thornton
@ 2022-02-17 20:23                   ` Dave Horsfall
  0 siblings, 0 replies; 63+ messages in thread
From: Dave Horsfall @ 2022-02-17 20:23 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 17 Feb 2022, Adam Thornton wrote:

> Today I learned that "time" is a shell built-in in zsh!

It's been a built-in in a lot of shells for ages; there is also 
[/usr]/bin/time if you want The Real Thing [tm].

-- Dave

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 19:59           ` Tom Ivar Helbekkmo via TUHS
@ 2022-02-17 21:18             ` Dave Horsfall
  2022-02-17 21:44               ` Bakul Shah
                                 ` (2 more replies)
  0 siblings, 3 replies; 63+ messages in thread
From: Dave Horsfall @ 2022-02-17 21:18 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:

> Watching the prime number generator (from the Wikipedia page on dc) 
> running on the 11/23 is much more entertaining than doing it on the 
> modern workstation I'm typing this on:
> 
> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x

Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient 
FreeBSD box.

> Incidentally, the Wikipedia page only lists Robert Morris as author of 
> dc.  If anyone here is able to edit Wikipedia, now would be a good time 
> to get Lorinda Cherry's name on there, too.

Anyone can edit Wikipedia; if you're an editor then you have your name 
shown instead of your IP address (and someone ought to fix that stupid 
"cat file | cmd" construct as well), but beware of the edit-nazis who seem 
to think that they "own" something that is factually wrong and keep 
changing it back to suit their own cultural views e.g. Kokoda Track vs. 
Trail.

-- Dave

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 21:18             ` Dave Horsfall
@ 2022-02-17 21:44               ` Bakul Shah
  2022-02-18  8:33                 ` Otto Moerbeek
  2022-02-20 17:29                 ` Derek Fawcus
  2022-02-17 22:00               ` David Arnold
  2022-02-18  9:58               ` Tom Ivar Helbekkmo via TUHS
  2 siblings, 2 replies; 63+ messages in thread
From: Bakul Shah @ 2022-02-17 21:44 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> 
>> Watching the prime number generator (from the Wikipedia page on dc) 
>> running on the 11/23 is much more entertaining than doing it on the 
>> modern workstation I'm typing this on:
>> 
>> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> 
> Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient 
> FreeBSD box.

That may be because FreeBSD continues computing primes while the MacOS
dc gives up after a while!

freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
^C       11.93 real        11.79 user         0.13 sys
$ wc xxx
   47161   47161  319109 xxx
$ size `which dc`
    text   data     bss      dec       hex   filename
  238159   2784   11072   252015   0x3d86f   /usr/bin/dc

MacOS (m1 pro, prob. 2Ghz)
$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
time: command terminated abnormally
        1.00 real         0.98 user         0.01 sys
[2]    37135 segmentation fault  command time dc <<<  > xxx
$ wc xxx
    7342    7342   42626 xxx
$ size `which dc`
__TEXT	__DATA	__OBJC	others	dec	hex
32768	16384	0	4295016448	4295065600	100018000


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 21:18             ` Dave Horsfall
  2022-02-17 21:44               ` Bakul Shah
@ 2022-02-17 22:00               ` David Arnold
  2022-02-18  9:58               ` Tom Ivar Helbekkmo via TUHS
  2 siblings, 0 replies; 63+ messages in thread
From: David Arnold @ 2022-02-17 22:00 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

> On 18 Feb 2022, at 08:18, Dave Horsfall <dave@horsfall.org> wrote:

<…>

>> Incidentally, the Wikipedia page only lists Robert Morris as author of 
>> dc.  If anyone here is able to edit Wikipedia, now would be a good time 
>> to get Lorinda Cherry's name on there, too.
> 
> Anyone can edit Wikipedia; if you're an editor then you have your name 
> shown instead of your IP address (and someone ought to fix that stupid 
> "cat file | cmd" construct as well), but beware of the edit-nazis who seem 
> to think that they "own" something that is factually wrong and keep 
> changing it back to suit their own cultural views e.g. Kokoda Track vs. 
> Trail.

The best solution to that is citing an irrefutable source (I mean, at
least for non-contested things).  I can edit if you can point me at
something definitive?




d


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
  2022-02-16 20:55     ` John P. Linderman
  2022-02-17  5:51     ` arnold
@ 2022-02-17 22:09     ` Will Senn
  2 siblings, 0 replies; 63+ messages in thread
From: Will Senn @ 2022-02-17 22:09 UTC (permalink / raw)
  To: Diomidis Spinellis, TUHS main list

Diomidis,

Thanks for the reading suggestion. I've done a lot of work with n-grams. 
Nice to see a pragmatic treatment of the subject. Too bad I didn't read 
it back in school. BTW, Volume 1 UNIX System Readings and Applications 
(reprint of 1978 BSTJ 57:6 part 2 - the UNIX issue) is available at:

http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_1_1987.pdf

And, volume 2 UNIX System Readings and Applications (1984 BSTJ 63:8 - 
the 2nd UNIX issue) is also available, at:

http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_2_1987.pdf

Much cleaner than the other copies.

Will


On 2/16/22 1:08 PM, Diomidis Spinellis wrote:
> A description of text processing work at Bell Labs, including the use 
> of trigrams for spell checking, readability analysis, and word class 
> assignment was published in the BSTJ.
>
> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. 
> The Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>
> You can find it openly available online at:
> https://archive.org/details/bstj57-6-2137/mode/2up
>
> The article was part of an amazing special issue of BSTJ devoted to 
> Unix.  A second such issue, 63(8) was published on October 1984.  In 
> the late 1980s both issues were also sold as books by Prentice Hall 
> under the title "UNIX System Readings and Applications".  I broke the 
> bank buying them as a student, but didn't regret it.
>
> Diomidis - https://www.spinellis.gr
>
> On 16-Feb-22 2:09, George Michaelson wrote:
>> The trigraph spelling checker sounds wonderful.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 21:44               ` Bakul Shah
@ 2022-02-18  8:33                 ` Otto Moerbeek
  2022-02-22 10:39                   ` Ralph Corderoy
  2022-02-20 17:29                 ` Derek Fawcus
  1 sibling, 1 reply; 63+ messages in thread
From: Otto Moerbeek @ 2022-02-18  8:33 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:

> On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave@horsfall.org> wrote:
> > 
> > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> > 
> >> Watching the prime number generator (from the Wikipedia page on dc) 
> >> running on the 11/23 is much more entertaining than doing it on the 
> >> modern workstation I'm typing this on:
> >> 
> >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> > 
> > Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient 
> > FreeBSD box.
> 
> That may be because FreeBSD continues computing primes while the MacOS
> dc gives up after a while!
> 
> freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> ^C       11.93 real        11.79 user         0.13 sys
> $ wc xxx
>    47161   47161  319109 xxx
> $ size `which dc`
>     text   data     bss      dec       hex   filename
>   238159   2784   11072   252015   0x3d86f   /usr/bin/dc
> 
> MacOS (m1 pro, prob. 2Ghz)
> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> time: command terminated abnormally
>         1.00 real         0.98 user         0.01 sys
> [2]    37135 segmentation fault  command time dc <<<  > xxx
> $ wc xxx
>     7342    7342   42626 xxx
> $ size `which dc`
> __TEXT	__DATA	__OBJC	others	dec	hex
> 32768	16384	0	4295016448	4295065600	100018000
> 

MacOS uses the GNU implementation which has a long standing issue with
deep recursion. It even cannot handle the tail recursive calls used
here and will run out of its stack.

	-Otto

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 21:18             ` Dave Horsfall
  2022-02-17 21:44               ` Bakul Shah
  2022-02-17 22:00               ` David Arnold
@ 2022-02-18  9:58               ` Tom Ivar Helbekkmo via TUHS
  2 siblings, 0 replies; 63+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2022-02-18  9:58 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

Dave Horsfall <dave@horsfall.org> writes:

>> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
>
> Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient 
> FreeBSD box.

That program shouldn't be redirected to /dev/null, but watched.
It doesn't terminate; it just keeps printing prime numbers.  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-17 21:44               ` Bakul Shah
  2022-02-18  8:33                 ` Otto Moerbeek
@ 2022-02-20 17:29                 ` Derek Fawcus
  1 sibling, 0 replies; 63+ messages in thread
From: Derek Fawcus @ 2022-02-20 17:29 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
> MacOS (m1 pro, prob. 2Ghz)
> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> time: command terminated abnormally
>         1.00 real         0.98 user         0.01 sys
> [2]    37135 segmentation fault  command time dc <<<  > xxx
> $ wc xxx
>     7342    7342   42626 xxx
> $ size `which dc`
> __TEXT	__DATA	__OBJC	others	dec	hex
> 32768	16384	0	4295016448	4295065600	100018000

So macOS has got worse, or the systems have:

$ sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU     U9400  @ 1.40GHz
$ uname -a
Darwin Old-MBA.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64
Old-MBA:~ derek$ time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
Segmentation fault: 11

real	0m14.982s
user	0m12.608s
sys	0m0.206s
$ wc xxx
    7868    7868   45782 xxx

My old machine computed more primes before the program crashed!
Given the comment about the GNU s/w running out of stack, I guess the x86 version uses smaller stack frames.

DF

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-18  8:33                 ` Otto Moerbeek
@ 2022-02-22 10:39                   ` Ralph Corderoy
  2022-02-22 15:53                     ` Otto Moerbeek
  0 siblings, 1 reply; 63+ messages in thread
From: Ralph Corderoy @ 2022-02-22 10:39 UTC (permalink / raw)
  To: Otto Moerbeek; +Cc: The Eunuchs Hysterical Society

Hi Otto,

> MacOS uses the GNU implementation which has a long standing issue with
> deep recursion.  It even cannot handle the tail recursive calls used
> here and will run out of its stack.

When learning dc and seeing it relied on tail calls, the first thing
I did was check it did tail-call elimination, and it did.  That was
GNU dc.

Trying just now, I see no growth in memory usage despite heavy CPU load
shown by TIME increasing.

    $ dc
    !ps u `pidof dc`
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    ralph    11489  0.0  0.0   2332  1484 pts/1    S+   10:33   0:00 dc
    [lmx]smlmx
    ^C
    Interrupt!
    !ps u `pidof dc`
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    ralph    11489 75.5  0.0   2332  1488 pts/1    S+   10:33   0:46 dc

The memory used remained at that level during the macro execution too,
watched from outside.

Do you have more detail on what GNU dc can't handle?  dc without
tail-call elimination is a bit crippled.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-22 10:39                   ` Ralph Corderoy
@ 2022-02-22 15:53                     ` Otto Moerbeek
  0 siblings, 0 replies; 63+ messages in thread
From: Otto Moerbeek @ 2022-02-22 15:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, Feb 22, 2022 at 10:39:48AM +0000, Ralph Corderoy wrote:

> Hi Otto,
> 
> > MacOS uses the GNU implementation which has a long standing issue with
> > deep recursion.  It even cannot handle the tail recursive calls used
> > here and will run out of its stack.
> 
> When learning dc and seeing it relied on tail calls, the first thing
> I did was check it did tail-call elimination, and it did.  That was
> GNU dc.
> 
> Trying just now, I see no growth in memory usage despite heavy CPU load
> shown by TIME increasing.
> 
>     $ dc
>     !ps u `pidof dc`
>     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>     ralph    11489  0.0  0.0   2332  1484 pts/1    S+   10:33   0:00 dc
>     [lmx]smlmx
>     ^C
>     Interrupt!
>     !ps u `pidof dc`
>     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>     ralph    11489 75.5  0.0   2332  1488 pts/1    S+   10:33   0:46 dc
> 
> The memory used remained at that level during the macro execution too,
> watched from outside.
> 
> Do you have more detail on what GNU dc can't handle?  dc without
> tail-call elimination is a bit crippled.
> 
> -- 
> Cheers, Ralph.

On MacOS:

$ dc --version
dc (GNU bc 1.06) 1.3
...
$ dc
[lmx]smlmx 
Segmentation fault: 11
$

On debian bullseye:
$ dc --version
dc (GNU bc 1.07.1) 1.4.1
...
$ dc
[lmx]smlmx 
...

all ok.

So the basic tail recursion case seems to be fixed in recent versions.

But note that 

	[laxp]sa
	1 lax

still segfaults on both GNU dc versions while on OpenBSD, using the
dc I wrote:

dc: recursion too deep: Cannot allocate memory

This is not a tail recursion case, but segfaulting is not nice at all.

	-Otto


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-22  0:02 [TUHS] Lorinda Cherry Brian Walden
@ 2022-03-01 21:51 ` Terry Jones
  0 siblings, 0 replies; 63+ messages in thread
From: Terry Jones @ 2022-03-01 21:51 UTC (permalink / raw)
  To: Brian Walden, tuhs

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

I’m also a fan of dc, and still a daily user after 40 years (not much in this group, I know, but a pretty good chunk of my life at least).

To get more functionality, I wrote a Python RPN calculator (with some key bindings identical to dc). It makes 300+ functions from standard Python libraries directly available and you can push Python objects and functions onto the stack. See https://github.com/terrycojones/rpnpy

Terry

From: TUHS <tuhs-bounces@minnie.tuhs.org> on behalf of Brian Walden <tuhs@cuzuco.com>
Reply to: Brian Walden <tuhs@cuzuco.com>
Date: Tuesday, 22. February 2022 at 01:02
To: <tuhs@minnie.tuhs.org>
Subject: [TUHS] Lorinda Cherry

I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt

calculator was an HP-45 (circa 1973) RPN felt right. However I think

dc pre-dates ALL HP calculators, since there was one in the 1st Edition

written in assembly.

I extened my version of dc (way before gnu existed)

based on common buttons I used from HP calculators:

CMD WHAT

# comment, to new line

~ change sign of top of stack (CHS key)

| 1/top of stack (1/x key)

e push 99 digits of e (2.718..) on the stack

@ push 99 digits of pi on the stack (looks like a circle)

r reverse top of stack (x<>y key)

I had been fascinated with pi stemimg from the Star Trek epsiode Wolf

in the Fold where Spock uses it to usa all computing power

"Computer, this is a Class A compulsory directive. Compute to

the last digit the value of pi."

"As we know, the value of pi is a transcendental figure without

resolution. The computer banks will work on this problem to the

exclusion of all else until we order it to stop."

As it was supposed to be "arbitrary precision" here was my tool.

So I wrote Machin formula in dc slowing increasing the scale and printing

the results. In the orginal dc, yes the whole part was arbitrary, but the

decimal part (scale) was limited to 99. Well that became a disappiontment.

(this program is lost to time)

So I decided to rewrite it but increasing pi as a whole numbers instead

of increasing scale (ex. 31415, 314159, 3141592, ... etc)

I still have that program which is simply this --

[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ

1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx

if you run it you'll notice the last 1 to 2 digits are wrong due to precision.

The next problem became small memory. I still have thes saved output before

it crashed at 1024 digits. No idea what specs of the machine it was run

on anymore its really old --

3141592653589793238462643383279502884197169399375105820974944592307816\

4062862089986280348253421170679821480865132823066470938446095505822317\

2535940812848111745028410270193852110555964462294895493038196442881097\

5665933446128475648233786783165271201909145648566923460348610454326648\

2133936072602491412737245870066063155881748815209209628292540917153643\

6789259036001133053054882046652138414695194151160943305727036575959195\

3092186117381932611793105118548074462379962749567351885752724891227938\

1830119491298336733624406566430860213949463952247371907021798609437027\

7053921717629317675238467481846766940513200056812714526356082778577134\

2757789609173637178721468440901224953430146549585371050792279689258923\

5420199561121290219608640344181598136297747713099605187072113499999983\

7297804995105973173281609631859502445945534690830264252230825334468503\

5261931188171010003137838752886587533208381420617177669147303598253490\

4287554687311595628638823537875937519577818577805321712268066130019278\

76611195909216420198938095257201065485862972

out of space: salloc

all 8587356 rel 8587326 headmor 1

nbytes -28318

stk 71154 rd 125364 wt 125367 beg 125364 last 125367

83 11 0

30 IOT trap - core dumped

But I was much happier with that.

On a side note: programming dc is hard. There was no comment character.

And it's a pain to read, and it's a pain to debug.

When I discovered the Chudnovsky algorithm for pi, of course I implemented it

in dc --

[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP

7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx

At 99 digits of scale it ran out in 7 rounds, but now with that limitation

removed and large memeories it just goes on and on.....

-Brian

PS: Thanks for the fast OpenBSD version of dc, Otto.

Otto Moerbeek wrote:

> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
>> On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> >
>
>> > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
>
>> >
>
>> >> Watching the prime number generator (from the Wikipedia page on dc)
>
>> >> running on the 11/23 is much more entertaining than doing it on the
>
>> >> modern workstation I'm typing this on:
>
>> >>
>
>> >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
>
>> >
>
>> > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient
>
>> > FreeBSD box.
>
>>
>
>> That may be because FreeBSD continues computing primes while the MacOS
>
>> dc gives up after a while!
>
>>
>
>> freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
>
>> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
>
>> ^C 11.93 real 11.79 user 0.13 sys
>
>> $ wc xxx
>
>> 47161 47161 319109 xxx
>
>> $ size `which dc`
>
>> text data bss dec hex filename
>
>> 238159 2784 11072 252015 0x3d86f /usr/bin/dc
>
>>
>
>> MacOS (m1 pro, prob. 2Ghz)
>
>> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
>
>> time: command terminated abnormally
>
>> 1.00 real 0.98 user 0.01 sys
>
>> [2] 37135 segmentation fault command time dc <<< > xxx
>
>> $ wc xxx
>
>> 7342 7342 42626 xxx
>
>> $ size `which dc`
>
>> __TEXT __DATA __OBJC others dec hex
>
>> 32768 16384 0 4295016448 4295065600 100018000
>
>>
>
> MacOS uses the GNU implementation which has a long standing issue with
>
> deep recursion. It even cannot handle the tail recursive calls used
>
> here and will run out of its stack.
>
> -Otto

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [TUHS] Lorinda Cherry
@ 2022-02-22  0:02 Brian Walden
  2022-03-01 21:51 ` Terry Jones
  0 siblings, 1 reply; 63+ messages in thread
From: Brian Walden @ 2022-02-22  0:02 UTC (permalink / raw)
  To: tuhs

I enjoy this dc(1) discussion.  I am a daily dc user, and since my fisrt
calculator was an HP-45 (circa 1973) RPN felt right. However I think
dc pre-dates ALL HP calculators, since there was one in the 1st Edition
written in assembly.

I extened my version of dc (way before gnu existed)
based on common buttons I used from HP calculators:

    CMD    WHAT
    #      comment, to new line
    ~      change sign of top of stack (CHS key)
    |      1/top of stack (1/x key)
    e      push 99 digits of e (2.718..) on the stack
    @      push 99 digits of pi on the stack (looks like a circle)
    r      reverse top of stack (x<>y key)

I had been fascinated with pi stemimg from the Star Trek epsiode Wolf
in the Fold where Spock uses it to usa all computing power

   "Computer, this is a Class A compulsory directive. Compute to
    the last digit the value of pi."

   "As we know, the value of pi is a transcendental figure without
    resolution. The computer banks will work on this problem to the
    exclusion of all else until we order it to stop."

As it was supposed to be "arbitrary precision" here was my tool.

So I wrote Machin formula in dc slowing increasing the scale and printing
the results. In the orginal dc, yes the whole part was arbitrary, but the
decimal part (scale) was limited to 99. Well that became a disappiontment.
(this program is lost to time)

So I decided to rewrite it but increasing pi as a whole numbers instead
of increasing scale (ex. 31415, 314159, 3141592, ... etc)

I still have that program which is simply this --

[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ
1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx


if you run it you'll notice the last 1 to 2 digits are wrong due to precision.

The next problem became small memory. I still have thes saved output before
it crashed at 1024 digits. No idea what specs of the machine it was run
on anymore its really old --

3141592653589793238462643383279502884197169399375105820974944592307816\
4062862089986280348253421170679821480865132823066470938446095505822317\
2535940812848111745028410270193852110555964462294895493038196442881097\
5665933446128475648233786783165271201909145648566923460348610454326648\
2133936072602491412737245870066063155881748815209209628292540917153643\
6789259036001133053054882046652138414695194151160943305727036575959195\
3092186117381932611793105118548074462379962749567351885752724891227938\
1830119491298336733624406566430860213949463952247371907021798609437027\
7053921717629317675238467481846766940513200056812714526356082778577134\
2757789609173637178721468440901224953430146549585371050792279689258923\
5420199561121290219608640344181598136297747713099605187072113499999983\
7297804995105973173281609631859502445945534690830264252230825334468503\
5261931188171010003137838752886587533208381420617177669147303598253490\
4287554687311595628638823537875937519577818577805321712268066130019278\
76611195909216420198938095257201065485862972
out of space: salloc
all 8587356 rel 8587326 headmor 1
nbytes -28318
stk 71154 rd 125364 wt 125367 beg 125364 last 125367
83 11 0
30 IOT trap - core dumped


But I was much happier with that.

On a side note: programming dc is hard. There was no comment character.
And it's a pain to read, and it's a pain to debug.

When I discovered the Chudnovsky algorithm for pi, of course I implemented it
in dc --

[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP
7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx

At 99 digits of scale it ran out in 7 rounds, but now with that limitation
removed and large memeories it just goes on and on.....

-Brian

PS: Thanks for the fast OpenBSD version of dc, Otto.

Otto Moerbeek wrote:
> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
> > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > >
> > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> > >
> > >> Watching the prime number generator (from the Wikipedia page on dc)
> > >> running on the 11/23 is much more entertaining than doing it on the
> > >> modern workstation I'm typing this on:
> > >>
> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> > >
> > > Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient
> > > FreeBSD box.
> >
> > That may be because FreeBSD continues computing primes while the MacOS
> > dc gives up after a while!
> >
> > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > ^C       11.93 real        11.79 user         0.13 sys
> > $ wc xxx
> >    47161   47161  319109 xxx
> > $ size `which dc`
> >     text   data     bss      dec       hex   filename
> >   238159   2784   11072   252015   0x3d86f   /usr/bin/dc
> >
> > MacOS (m1 pro, prob. 2Ghz)
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > time: command terminated abnormally
> >         1.00 real         0.98 user         0.01 sys
> > [2]    37135 segmentation fault  command time dc <<<  > xxx
> > $ wc xxx
> >     7342    7342   42626 xxx
> > $ size `which dc`
> > __TEXT      __DATA  __OBJC  others  dec     hex
> > 32768       16384   0       4295016448      4295065600      100018000
> >
>
> MacOS uses the GNU implementation which has a long standing issue with
> deep recursion. It even cannot handle the tail recursive calls used
> here and will run out of its stack.
>
>       -Otto

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-18  3:18 Norman Wilson
@ 2022-02-18  9:10 ` Peter Jeremy via TUHS
  0 siblings, 0 replies; 63+ messages in thread
From: Peter Jeremy via TUHS @ 2022-02-18  9:10 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

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

On 2022-Feb-17 22:18:25 -0500, Norman Wilson <norman@oclsc.org> wrote:
>Perhaps the best irrefutable source for Lorinda's contribution
>to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry?
>
>It is, by the way, Doug's A Research UNIX Reader.  Those who
>subscribe to this list and haven't read it ought to do so; it's
>full of tidbits of history.

It was already referenced from the dc entry and I've added Lorinda
as a co-author with that as a citation.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
@ 2022-02-18  3:18 Norman Wilson
  2022-02-18  9:10 ` Peter Jeremy via TUHS
  0 siblings, 1 reply; 63+ messages in thread
From: Norman Wilson @ 2022-02-18  3:18 UTC (permalink / raw)
  To: tuhs

Perhaps the best irrefutable source for Lorinda's contribution
to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry?

It is, by the way, Doug's A Research UNIX Reader.  Those who
subscribe to this list and haven't read it ought to do so; it's
full of tidbits of history.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 21:17 John P. Linderman
  2022-02-15 21:26 ` Dave Horsfall
@ 2022-02-15 21:33 ` Jeffrey Joshua Rollin
  1 sibling, 0 replies; 63+ messages in thread
From: Jeffrey Joshua Rollin @ 2022-02-15 21:33 UTC (permalink / raw)
  To: John P. Linderman; +Cc: The Eunuchs Hysterical Society

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

Sad news.

Jeff

Sent from my iPad

> On 15 Feb 2022, at 21:21, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> 
> I got his from a friend today (15 February):
> 
> ===========
> 
> I'm sorry to report that Lorinda passed away a few days ago.  I got a call from her sister today.  Apparently the dog walker hadn't seen her for a few days and called the police.  The police entered the house and found her there.  Her sister says they are assuming either a heart attack or a stroke.

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [TUHS] Lorinda Cherry
  2022-02-15 21:17 John P. Linderman
@ 2022-02-15 21:26 ` Dave Horsfall
  2022-02-15 21:33 ` Jeffrey Joshua Rollin
  1 sibling, 0 replies; 63+ messages in thread
From: Dave Horsfall @ 2022-02-15 21:26 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Sic transit gloria mundi...

This probably ought to go to COFF as well.

-- Dave

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [TUHS] Lorinda Cherry
@ 2022-02-15 21:17 John P. Linderman
  2022-02-15 21:26 ` Dave Horsfall
  2022-02-15 21:33 ` Jeffrey Joshua Rollin
  0 siblings, 2 replies; 63+ messages in thread
From: John P. Linderman @ 2022-02-15 21:17 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

I got his from a friend today (15 February):

===========

I'm sorry to report that Lorinda passed away a few days ago.  I got a call
from her sister today.  Apparently the dog walker hadn't seen her for a few
days and called the police.  The police entered the house and found her
there.  Her sister says they are assuming either a heart attack or a stroke.

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

^ permalink raw reply	[flat|nested] 63+ messages in thread

end of thread, other threads:[~2022-03-01 22:05 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 22:31 [TUHS] Lorinda Cherry Douglas McIlroy
2022-02-15 23:32 ` Steve Nickolas
2022-02-15 23:43   ` Jim Capp
2022-02-15 23:51     ` Larry McVoy
2022-02-16  0:54       ` Will Senn
2022-02-16  2:58         ` Steve Nickolas
2022-02-16  0:09 ` George Michaelson
2022-02-16  0:24   ` Dave Horsfall
2022-02-16  7:54     ` arnold
2022-02-16  8:13       ` markus schnalke
2022-02-16 14:54         ` Leah Neukirchen
2022-02-16 22:27           ` Dave Horsfall
2022-02-16 22:40             ` Andrew Diller
2022-02-17 10:14               ` Peter Jeremy via TUHS
2022-02-17 15:50                 ` Adam Thornton
2022-02-17 20:23                   ` Dave Horsfall
2022-02-17 10:24               ` Andy Kosela
2022-02-17 16:05                 ` Andrew Hume
2022-02-17 16:38                   ` Warner Losh
2022-02-16 22:42             ` Larry McVoy
2022-02-16 22:56               ` Clem Cole
2022-02-16 23:49                 ` Paul Winalski
2022-02-16 23:49               ` [TUHS] Benchmarks Bakul Shah
2022-02-17  1:02                 ` Larry McVoy
2022-02-17 12:36             ` [TUHS] Lorinda Cherry Stuart Remphrey
2022-02-17 19:59           ` Tom Ivar Helbekkmo via TUHS
2022-02-17 21:18             ` Dave Horsfall
2022-02-17 21:44               ` Bakul Shah
2022-02-18  8:33                 ` Otto Moerbeek
2022-02-22 10:39                   ` Ralph Corderoy
2022-02-22 15:53                     ` Otto Moerbeek
2022-02-20 17:29                 ` Derek Fawcus
2022-02-17 22:00               ` David Arnold
2022-02-18  9:58               ` Tom Ivar Helbekkmo via TUHS
2022-02-16 14:34     ` [TUHS] dc after bc Ralph Corderoy
2022-02-16 19:08   ` [TUHS] Lorinda Cherry Diomidis Spinellis
2022-02-16 20:55     ` John P. Linderman
2022-02-16 21:17       ` Andrew Hume
2022-02-16 21:59       ` Marshall Conover
2022-02-17  5:51     ` arnold
2022-02-17 22:09     ` Will Senn
2022-02-16  0:35 ` Andrew Hume
2022-02-16  8:02 ` Thomas Paulsen
2022-02-16 14:05 ` [TUHS] Shower of Dogs Ralph Corderoy
2022-02-16 14:09   ` Andrew Hume
2022-02-16 15:01     ` Larry McVoy
2022-02-16 16:57     ` Douglas McIlroy
2022-02-16 17:03     ` Dennis Boone
2022-02-16 17:18       ` Warner Losh
2022-02-16 14:09   ` Chet Ramey
2022-02-16 14:35     ` Ron Natalie
2022-02-16 14:41     ` Ralph Corderoy
2022-02-16 15:08   ` Rich Morin
2022-02-16 21:21     ` Dave Horsfall
2022-02-16 21:25       ` John Cowan
2022-02-17  3:31         ` Chet Ramey
  -- strict thread matches above, loose matches on Subject: below --
2022-02-22  0:02 [TUHS] Lorinda Cherry Brian Walden
2022-03-01 21:51 ` Terry Jones
2022-02-18  3:18 Norman Wilson
2022-02-18  9:10 ` Peter Jeremy via TUHS
2022-02-15 21:17 John P. Linderman
2022-02-15 21:26 ` Dave Horsfall
2022-02-15 21:33 ` Jeffrey Joshua Rollin

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