From paul.winalski at gmail.com  Tue Aug  1 02:50:57 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 31 Jul 2017 12:50:57 -0400
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
Message-ID: <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>

On 7/30/17, Alec Muffett <alec.muffett at gmail.com> wrote:
> Dumb question: is there any chance that just as BEL goes <beep>, perhaps
> LAMP illuminated a red warning light or similar?

BEL *did* ring a bell on the model 33 Teletype.  On the DEC VT52, it
sounded a buzzer that was sort of like an electronic raspberry.  On
the VT100, LA36, and other later terminals, it was the familiar feep
sound.

The character we're discussing here was named LANTERN, not LAMP, but
you may have something there regarding it turning on a light.  We'd
need to find an AT&T 4410 terminal, or someone who's used one, to be
sure.

-Paul W.


From rminnich at gmail.com  Tue Aug  1 03:52:51 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 31 Jul 2017 17:52:51 +0000
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
 <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
Message-ID: <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>

ah, on the vt52, that "bell" was called the "feep". It sure was not a bell.,

The vt52 was a real money saving device. From what we could tell, the
printed circuit board on it was cardboard.

On Mon, Jul 31, 2017 at 9:51 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 7/30/17, Alec Muffett <alec.muffett at gmail.com> wrote:
> > Dumb question: is there any chance that just as BEL goes <beep>, perhaps
> > LAMP illuminated a red warning light or similar?
>
> BEL *did* ring a bell on the model 33 Teletype.  On the DEC VT52, it
> sounded a buzzer that was sort of like an electronic raspberry.  On
> the VT100, LA36, and other later terminals, it was the familiar feep
> sound.
>
> The character we're discussing here was named LANTERN, not LAMP, but
> you may have something there regarding it turning on a light.  We'd
> need to find an AT&T 4410 terminal, or someone who's used one, to be
> sure.
>
> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170731/cb9376ff/attachment.html>

From imp at bsdimp.com  Tue Aug  1 06:01:40 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 31 Jul 2017 14:01:40 -0600
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
 <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
 <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>
Message-ID: <CANCZdfq-+GanuLb=qEPGAsPh_zL_Br5Z7+HpLR=9s_n6u0dr7A@mail.gmail.com>

On Mon, Jul 31, 2017 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:

> ah, on the vt52, that "bell" was called the "feep". It sure was not a
> bell.,
>
> The vt52 was a real money saving device. From what we could tell, the
> printed circuit board on it was cardboard.
>
> On Mon, Jul 31, 2017 at 9:51 AM Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> On 7/30/17, Alec Muffett <alec.muffett at gmail.com> wrote:
>> > Dumb question: is there any chance that just as BEL goes <beep>, perhaps
>> > LAMP illuminated a red warning light or similar?
>>
>> BEL *did* ring a bell on the model 33 Teletype.  On the DEC VT52, it
>> sounded a buzzer that was sort of like an electronic raspberry.  On
>> the VT100, LA36, and other later terminals, it was the familiar feep
>> sound.
>>
>> The character we're discussing here was named LANTERN, not LAMP, but
>> you may have something there regarding it turning on a light.  We'd
>> need to find an AT&T 4410 terminal, or someone who's used one, to be
>> sure.
>>
>> -Paul W.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170731/c41206c6/attachment.html>

From imp at bsdimp.com  Tue Aug  1 06:04:40 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 31 Jul 2017 14:04:40 -0600
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
 <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
 <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>
Message-ID: <CANCZdfpS794BAkHojf=_D63TvV-rVkBs6ACRYbBv5gCWkGboYg@mail.gmail.com>

On Mon, Jul 31, 2017 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:

> ah, on the vt52, that "bell" was called the "feep". It sure was not a
> bell.,
>
> The vt52 was a real money saving device. From what we could tell, the
> printed circuit board on it was cardboard.
>

On the VT52 terminals I used, the bell seemed to come in two flavors. One
was a very iconic "gear grinding" sound where there was a small motor that
spun a toothed wheel that ran over a slender finger of plastic. A few,
maybe retrofitted, had what sounded like a random 555 noise that was gated
on/off.

Warner


> On Mon, Jul 31, 2017 at 9:51 AM Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> On 7/30/17, Alec Muffett <alec.muffett at gmail.com> wrote:
>> > Dumb question: is there any chance that just as BEL goes <beep>, perhaps
>> > LAMP illuminated a red warning light or similar?
>>
>> BEL *did* ring a bell on the model 33 Teletype.  On the DEC VT52, it
>> sounded a buzzer that was sort of like an electronic raspberry.  On
>> the VT100, LA36, and other later terminals, it was the familiar feep
>> sound.
>>
>> The character we're discussing here was named LANTERN, not LAMP, but
>> you may have something there regarding it turning on a light.  We'd
>> need to find an AT&T 4410 terminal, or someone who's used one, to be
>> sure.
>>
>> -Paul W.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170731/e2588027/attachment.html>

From earl.baugh at gmail.com  Tue Aug  1 07:25:21 2017
From: earl.baugh at gmail.com (Earl Baugh)
Date: Mon, 31 Jul 2017 17:25:21 -0400
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CANCZdfpS794BAkHojf=_D63TvV-rVkBs6ACRYbBv5gCWkGboYg@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
 <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
 <CAP6exYJnp-Z-kyf9ktQitB4mntfYn7ScGfeZvXEZeaGZuwUjiQ@mail.gmail.com>
 <CANCZdfpS794BAkHojf=_D63TvV-rVkBs6ACRYbBv5gCWkGboYg@mail.gmail.com>
Message-ID: <CANcLFn4yv4+uQCsYq_9G8o5dWMW5_P3n_gJP417Ka65xFpK5dA@mail.gmail.com>

I'll take any sound vs. the "visual bell" flash that I had on the first
terminal I used to learn VI on.
Had I had epilepsy like my sister, I'd have never survived :-)

Earl

On Mon, Jul 31, 2017 at 4:04 PM, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Mon, Jul 31, 2017 at 11:52 AM, ron minnich <rminnich at gmail.com> wrote:
>
>> ah, on the vt52, that "bell" was called the "feep". It sure was not a
>> bell.,
>>
>> The vt52 was a real money saving device. From what we could tell, the
>> printed circuit board on it was cardboard.
>>
>
> On the VT52 terminals I used, the bell seemed to come in two flavors. One
> was a very iconic "gear grinding" sound where there was a small motor that
> spun a toothed wheel that ran over a slender finger of plastic. A few,
> maybe retrofitted, had what sounded like a random 555 noise that was gated
> on/off.
>
> Warner
>
>
>> On Mon, Jul 31, 2017 at 9:51 AM Paul Winalski <paul.winalski at gmail.com>
>> wrote:
>>
>>> On 7/30/17, Alec Muffett <alec.muffett at gmail.com> wrote:
>>> > Dumb question: is there any chance that just as BEL goes <beep>,
>>> perhaps
>>> > LAMP illuminated a red warning light or similar?
>>>
>>> BEL *did* ring a bell on the model 33 Teletype.  On the DEC VT52, it
>>> sounded a buzzer that was sort of like an electronic raspberry.  On
>>> the VT100, LA36, and other later terminals, it was the familiar feep
>>> sound.
>>>
>>> The character we're discussing here was named LANTERN, not LAMP, but
>>> you may have something there regarding it turning on a light.  We'd
>>> need to find an AT&T 4410 terminal, or someone who's used one, to be
>>> sure.
>>>
>>> -Paul W.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170731/56e9c167/attachment.html>

From schoedel at kw.igs.net  Tue Aug  1 09:46:17 2017
From: schoedel at kw.igs.net (Kevin Schoedel)
Date: Mon, 31 Jul 2017 19:46:17 -0400
Subject: [TUHS] Anyone know what a LANTERN is
In-Reply-To: <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
References: <201707301114.v6UBEEmc029284@coolidge.cs.Dartmouth.EDU>
 <CAFWeb9LFZ8t7Gzu1AS-joJ8MZsbbTb-vz2mKRunA1_mFESvizA@mail.gmail.com>
 <CABH=_VRDnCEb-c3EFuABusF=ywWDiopO_jC4Y2FX-vBzgfwjOg@mail.gmail.com>
Message-ID: <p06210205d5a570817b41@[192.168.0.16]>

At 12:50 ?pm -0400 2017/07/31, Paul Winalski wrote:
>The character we're discussing here was named LANTERN, not LAMP, but
>you may have something there regarding it turning on a light.  We'd
>need to find an AT&T 4410 terminal, or someone who's used one, to be
>sure.

A bit of Googling suggests that the Herbert H. Warrick Jr. Museum of
Communications in Seattle has at least one of these recently in operating
condition. <http://www.museumofcommunications.org/unix/>

-- 
Kevin Schoedel <schoedel at kw.igs.net> VA3TCS


From tom.manos at gmail.com  Thu Aug  3 08:46:23 2017
From: tom.manos at gmail.com (Tom Manos)
Date: Wed, 2 Aug 2017 18:46:23 -0400
Subject: [TUHS] SVR 3.2
Message-ID: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>

Hi all,

Sorry if this is the wrong place to ask...

I started my home UNIX hobby in the mid-1980's with Microport SVR2 on Intel
286. With a couple of modems I started a public access UNIX system in
Hampton Roads, VA.

That system graduated to SVR3.0, 3.1, 3.2 on 386, and finally 4.2 with 4
modems running on an AST 4-port card on 486. That was about 1992 when I
started an ISP using SVR4.2. That ISP, also in Hampton Roads, grew quite
large. We were in 100 cities and partnered with newspapers and managed
their content on the brand new web. By then we had graduated to large Alpha
systems and Sun Enterprise.

Now I'm all grown up and and experiencing a 2nd childhood. I run SVR4.2MP
here on a real dual processor Pentium system, but I'd like to get back to
SVR3.2 on period hardware, and later to r2.

My problem is I don't have a copy and don't know where to find one. Do any
of you happen to have a diskette (or disk image) set you can part with?
Ideally I'd like a development system and networking. But I've always been
an optimist :)

I'm happy to pay reasonable fees.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170802/ec4195af/attachment.html>

From andreas.hein at berlan.de  Thu Aug  3 09:02:32 2017
From: andreas.hein at berlan.de (Andreas Hein)
Date: Thu, 03 Aug 2017 01:02:32 +0200
Subject: [TUHS] SVR 3.2
In-Reply-To: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
References: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
Message-ID: <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>

Hello Tom,

yeah, i have the same history. First operating system for my 286 was the Microport ATT  SVR2. I have original 5 1/4  media, the tree manuals (mostly printouts of the original UNIX Man pages beide Intel Assembler and bootloader) and images from the disks. But, as you remember, Microport V.2 had no networking (beside UUCP)

Still Interested ? Send me a email, I will prepare the images and find a way to deliver it to you (earliest tomorrow). And if someone know a way to Boot this images in a hypervirsor, this would help me. The current hypervisors are not able to emulate MFM disks and hercules graphics AFIK

Regards,
Andreas

Am 3. August 2017 00:46:23 MESZ schrieb Tom Manos <tom.manos at gmail.com>:
>Hi all,
>
>Sorry if this is the wrong place to ask...
>
>I started my home UNIX hobby in the mid-1980's with Microport SVR2 on
>Intel
>286. With a couple of modems I started a public access UNIX system in
>Hampton Roads, VA.
>
>That system graduated to SVR3.0, 3.1, 3.2 on 386, and finally 4.2 with
>4
>modems running on an AST 4-port card on 486. That was about 1992 when I
>started an ISP using SVR4.2. That ISP, also in Hampton Roads, grew
>quite
>large. We were in 100 cities and partnered with newspapers and managed
>their content on the brand new web. By then we had graduated to large
>Alpha
>systems and Sun Enterprise.
>
>Now I'm all grown up and and experiencing a 2nd childhood. I run
>SVR4.2MP
>here on a real dual processor Pentium system, but I'd like to get back
>to
>SVR3.2 on period hardware, and later to r2.
>
>My problem is I don't have a copy and don't know where to find one. Do
>any
>of you happen to have a diskette (or disk image) set you can part with?
>Ideally I'd like a development system and networking. But I've always
>been
>an optimist :)
>
>I'm happy to pay reasonable fees.
>
>Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170803/031a9d3d/attachment.html>

From mphuff at gmail.com  Thu Aug  3 09:35:30 2017
From: mphuff at gmail.com (Michael Huff)
Date: Wed, 2 Aug 2017 15:35:30 -0800
Subject: [TUHS] SVR 3.2
In-Reply-To: <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
References: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
 <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
Message-ID: <8da87137-2822-ac6a-9b7b-88cb48485a4a@gmail.com>

I'm not sure how well it works, but there's always pcem: 
http://pcem-emulator.co.uk/ ...it can emulate both a 286, and MFM disks; 
though I'm not sure how accurate that emulation is.


On 08/02/2017 03:02 PM, Andreas Hein wrote:
> Hello Tom,
>
> yeah, i have the same history. First operating system for my 286 was 
> the Microport ATT SVR2. I have original 5 1/4 media, the tree manuals 
> (mostly printouts of the original UNIX Man pages beide Intel Assembler 
> and bootloader) and images from the disks. But, as you remember, 
> Microport V.2 had no networking (beside UUCP)
>
> Still Interested ? Send me a email, I will prepare the images and find 
> a way to deliver it to you (earliest tomorrow). And if someone know a 
> way to Boot this images in a hypervirsor, this would help me. The 
> current hypervisors are not able to emulate MFM disks and hercules 
> graphics AFIK
>
> Regards,
> Andreas
>
> Am 3. August 2017 00:46:23 MESZ schrieb Tom Manos <tom.manos at gmail.com>:
>
>     Hi all,
>
>     Sorry if this is the wrong place to ask...
>
>     I started my home UNIX hobby in the mid-1980's with Microport SVR2
>     on Intel 286. With a couple of modems I started a public access
>     UNIX system in Hampton Roads, VA.
>
>     That system graduated to SVR3.0, 3.1, 3.2 on 386, and finally 4.2
>     with 4 modems running on an AST 4-port card on 486. That was about
>     1992 when I started an ISP using SVR4.2. That ISP, also in Hampton
>     Roads, grew quite large. We were in 100 cities and partnered with
>     newspapers and managed their content on the brand new web. By then
>     we had graduated to large Alpha systems and Sun Enterprise.
>
>     Now I'm all grown up and and experiencing a 2nd childhood. I run
>     SVR4.2MP here on a real dual processor Pentium system, but I'd
>     like to get back to SVR3.2 on period hardware, and later to r2.
>
>     My problem is I don't have a copy and don't know where to find
>     one. Do any of you happen to have a diskette (or disk image) set
>     you can part with? Ideally I'd like a development system and
>     networking. But I've always been an optimist :)
>
>     I'm happy to pay reasonable fees.
>
>     Tom
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170802/738002e3/attachment.html>

From imp at bsdimp.com  Thu Aug  3 10:46:05 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 2 Aug 2017 18:46:05 -0600
Subject: [TUHS] SVR 3.2
In-Reply-To: <8da87137-2822-ac6a-9b7b-88cb48485a4a@gmail.com>
References: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
 <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
 <8da87137-2822-ac6a-9b7b-88cb48485a4a@gmail.com>
Message-ID: <CANCZdfq17w5P1t850etfAe2yBsy4FU7GMRBDy=-o66jUA=t-7A@mail.gmail.com>

mame/mess also offers emulation of early x86 computers as well.
https://github.com/mamedev/mame

Warner

On Wed, Aug 2, 2017 at 5:35 PM, Michael Huff <mphuff at gmail.com> wrote:

> I'm not sure how well it works, but there's always pcem:
> http://pcem-emulator.co.uk/ ...it can emulate both a 286, and MFM disks;
> though I'm not sure how accurate that emulation is.
>
> On 08/02/2017 03:02 PM, Andreas Hein wrote:
>
> Hello Tom,
>
> yeah, i have the same history. First operating system for my 286 was the
> Microport ATT SVR2. I have original 5 1/4 media, the tree manuals (mostly
> printouts of the original UNIX Man pages beide Intel Assembler and
> bootloader) and images from the disks. But, as you remember, Microport V.2
> had no networking (beside UUCP)
>
> Still Interested ? Send me a email, I will prepare the images and find a
> way to deliver it to you (earliest tomorrow). And if someone know a way to
> Boot this images in a hypervirsor, this would help me. The current
> hypervisors are not able to emulate MFM disks and hercules graphics AFIK
>
> Regards,
> Andreas
>
> Am 3. August 2017 00:46:23 MESZ schrieb Tom Manos <tom.manos at gmail.com>
> <tom.manos at gmail.com>:
>>
>> Hi all,
>>
>> Sorry if this is the wrong place to ask...
>>
>> I started my home UNIX hobby in the mid-1980's with Microport SVR2 on
>> Intel 286. With a couple of modems I started a public access UNIX system in
>> Hampton Roads, VA.
>>
>> That system graduated to SVR3.0, 3.1, 3.2 on 386, and finally 4.2 with 4
>> modems running on an AST 4-port card on 486. That was about 1992 when I
>> started an ISP using SVR4.2. That ISP, also in Hampton Roads, grew quite
>> large. We were in 100 cities and partnered with newspapers and managed
>> their content on the brand new web. By then we had graduated to large Alpha
>> systems and Sun Enterprise.
>>
>> Now I'm all grown up and and experiencing a 2nd childhood. I run SVR4.2MP
>> here on a real dual processor Pentium system, but I'd like to get back to
>> SVR3.2 on period hardware, and later to r2.
>>
>> My problem is I don't have a copy and don't know where to find one. Do
>> any of you happen to have a diskette (or disk image) set you can part with?
>> Ideally I'd like a development system and networking. But I've always been
>> an optimist :)
>>
>> I'm happy to pay reasonable fees.
>>
>> Tom
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170802/19bdfc3e/attachment.html>

From tom.manos at gmail.com  Thu Aug  3 22:57:53 2017
From: tom.manos at gmail.com (Tom Manos)
Date: Thu, 3 Aug 2017 08:57:53 -0400
Subject: [TUHS] SYSVR2,3,4
Message-ID: <CAOs6KDebGAOQCxNx0z0=PxBXS9GXpyGqsf7MYQk_zWQPTOKrvg@mail.gmail.com>

Thanks for the replies!

I figured that like other lists I frequent, most here would be BSDish folk.
Glad to know there are others with commercial AT&T experience.

I know r2 has no networking and used UUCP extensively back when. I'll be
using it for local transfer along with Kermit.

My particular sickness requires me to run these operating systems on mostly
period hardware. My SVR4 runs on all period stuff except I use SCSI2SD for
the disk. Old disks are becoming hard to find and expensive, and I really
don't want to be playing with MFM or RLL anymore. I'll likely try to find
some kind of substitute. I know they are out there.

I think r3.2 supported SCSI, so I should be ok there.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170803/16bf5db7/attachment.html>

From gtaylor at tnetconsulting.net  Fri Aug  4 15:25:39 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 3 Aug 2017 23:25:39 -0600
Subject: [TUHS] SVR 3.2
In-Reply-To: <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
References: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
 <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
Message-ID: <9e492443-b66f-5705-b906-15842db16cc7@tnetconsulting.net>

On 08/02/2017 05:02 PM, Andreas Hein wrote:
> And if someone know a way to Boot this images in a hypervirsor, this 
> would help me. The current hypervisors are not able to emulate MFM disks
> and hercules graphics AFIK

Have you looked at Bochs?

I managed to get AIX 1.3 running in it and it was looking for IBM PS/2
hardware.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170803/b76a4e31/attachment.bin>

From ron at ronnatalie.com  Sat Aug  5 00:06:20 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 4 Aug 2017 10:06:20 -0400
Subject: [TUHS] Photo of some Unix greats
In-Reply-To: <1905.1500868544@cesium.clock.org>
References: <15897.1500515767@cesium.clock.org>
 <1905.1500868544@cesium.clock.org>
Message-ID: <003001d30d2a$d97cab10$8c760130$@ronnatalie.com>

Sorry for the late respoinse.     That indeed is me there.    I don't know
who the jacket guy is either.

The guy with the hat and camera in the center of the front row is fellow
BRL-er Doug Kingston.

Oddly  missing is Mike Muuss who I know was there.    Either he's out front
taking a picture or that's him on the far right of the bottom row.   Hard to
tell due to the face being obscured, but I tend to doubt it.   I knew Mike
for decades and that doesn't quite look like him.   The  head peaking out
just to the left of Steve Bellovin's hat is Bob Miles.   Another BRLer who
had left for Northrop by the time this picture was taken I think.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Erik E. Fair
Sent: Sunday, July 23, 2017 11:56 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Photo of some Unix greats

Regarding Steve's photo from Summer USENIX, does anyone know who the shorter
guy in a light jacket and polo shirt with a broad horizontal stripe on it,
leaning right in front of me, elbow-to-elbow with Ron Natalie?

I had this odd query from a random a month or two ago about who he is, and I
can't remember his name.

	Erik



From clemc at ccc.com  Sat Aug  5 00:53:02 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 4 Aug 2017 10:53:02 -0400
Subject: [TUHS] Photo of some Unix greats
In-Reply-To: <003001d30d2a$d97cab10$8c760130$@ronnatalie.com>
References: <15897.1500515767@cesium.clock.org>
 <1905.1500868544@cesium.clock.org>
 <003001d30d2a$d97cab10$8c760130$@ronnatalie.com>
Message-ID: <CAC20D2OJe+oCJ2m+AKh3+cCfohd1XDo1xN_kUXM19Q5vygXAYQ@mail.gmail.com>

Thanks Ron, I justed add Bob Miles to the documentation and fixed a
dyslexic spelling error (in Bruce Borden's name) I made years ago -- sigh.

Clem

On Fri, Aug 4, 2017 at 10:06 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> Sorry for the late respoinse.     That indeed is me there.    I don't know
> who the jacket guy is either.
>
> The guy with the hat and camera in the center of the front row is fellow
> BRL-er Doug Kingston.
>
> Oddly  missing is Mike Muuss who I know was there.    Either he's out front
> taking a picture or that's him on the far right of the bottom row.   Hard
> to
> tell due to the face being obscured, but I tend to doubt it.   I knew Mike
> for decades and that doesn't quite look like him.   The  head peaking out
> just to the left of Steve Bellovin's hat is Bob Miles.   Another BRLer who
> had left for Northrop by the time this picture was taken I think.
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Erik E. Fair
> Sent: Sunday, July 23, 2017 11:56 PM
> To: The Eunuchs Hysterical Society
> Subject: Re: [TUHS] Photo of some Unix greats
>
> Regarding Steve's photo from Summer USENIX, does anyone know who the
> shorter
> guy in a light jacket and polo shirt with a broad horizontal stripe on it,
> leaning right in front of me, elbow-to-elbow with Ron Natalie?
>
> I had this odd query from a random a month or two ago about who he is, and
> I
> can't remember his name.
>
>         Erik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170804/fc96f5e8/attachment.html>

From andreas.hein at berlan.de  Sat Aug  5 08:35:20 2017
From: andreas.hein at berlan.de (Andreas Hein)
Date: Sat, 05 Aug 2017 00:35:20 +0200
Subject: [TUHS] SVR 3.2
In-Reply-To: <9e492443-b66f-5705-b906-15842db16cc7@tnetconsulting.net>
References: <CAOs6KDdkB_LtoECJhqY7F=17nD0n206w3tKx7etPi533=dAs5w@mail.gmail.com>
 <7F7B6D0D-1920-4116-BB18-202853B8268E@berlan.de>
 <9e492443-b66f-5705-b906-15842db16cc7@tnetconsulting.net>
Message-ID: <7F5E5F87-0BF0-4B15-98AE-BE03FF4EA613@berlan.de>

Thanks, will try bochs. Seems to be able to handle MFM and Protected-Mode (In Intel 286).

PCem was not that successful. Got double-panic right after kernel initialisation. Virtualbox was able to Boot kernel and run forward into install routine, but then stalled at first attempt of accessing the emulated HDD

KR,
Andreas


>Have you looked at Bochs?
>
>I managed to get AIX 1.3 running in it and it was looking for IBM PS/2
>hardware.


From clemc at ccc.com  Sat Aug  5 00:58:10 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 4 Aug 2017 10:58:10 -0400
Subject: [TUHS] Photo of some Unix greats
In-Reply-To: <CAC20D2OJe+oCJ2m+AKh3+cCfohd1XDo1xN_kUXM19Q5vygXAYQ@mail.gmail.com>
References: <15897.1500515767@cesium.clock.org>
 <1905.1500868544@cesium.clock.org>
 <003001d30d2a$d97cab10$8c760130$@ronnatalie.com>
 <CAC20D2OJe+oCJ2m+AKh3+cCfohd1XDo1xN_kUXM19Q5vygXAYQ@mail.gmail.com>
Message-ID: <CAC20D2N6UQSRDKfD78HChj9A30nOJTjdQkqjvqywnWB4nwH+zg@mail.gmail.com>

Apologies to the mailing list -- here is a color version of similar pic
taken at the same time... adding a few more people although everyone is
smaller in it and some people might be easier to identify.

[image: Inline image 1]

On Fri, Aug 4, 2017 at 10:53 AM, Clem Cole <clemc at ccc.com> wrote:

> Thanks Ron, I justed add Bob Miles to the documentation and fixed a
> dyslexic spelling error (in Bruce Borden's name) I made years ago -- sigh.
>
> Clem
>
> On Fri, Aug 4, 2017 at 10:06 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>
>> Sorry for the late respoinse.     That indeed is me there.    I don't know
>> who the jacket guy is either.
>>
>> The guy with the hat and camera in the center of the front row is fellow
>> BRL-er Doug Kingston.
>>
>> Oddly  missing is Mike Muuss who I know was there.    Either he's out
>> front
>> taking a picture or that's him on the far right of the bottom row.   Hard
>> to
>> tell due to the face being obscured, but I tend to doubt it.   I knew Mike
>> for decades and that doesn't quite look like him.   The  head peaking out
>> just to the left of Steve Bellovin's hat is Bob Miles.   Another BRLer who
>> had left for Northrop by the time this picture was taken I think.
>>
>>
>> -----Original Message-----
>> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Erik E.
>> Fair
>> Sent: Sunday, July 23, 2017 11:56 PM
>> To: The Eunuchs Hysterical Society
>> Subject: Re: [TUHS] Photo of some Unix greats
>>
>> Regarding Steve's photo from Summer USENIX, does anyone know who the
>> shorter
>> guy in a light jacket and polo shirt with a broad horizontal stripe on it,
>> leaning right in front of me, elbow-to-elbow with Ron Natalie?
>>
>> I had this odd query from a random a month or two ago about who he is,
>> and I
>> can't remember his name.
>>
>>         Erik
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170804/836d97c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: USENIX1984.jpg
Type: image/jpeg
Size: 118782 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170804/836d97c9/attachment.jpg>

From wkt at tuhs.org  Tue Aug  8 12:52:36 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 8 Aug 2017 12:52:36 +1000
Subject: [TUHS] Off-topic: any logic designers here?
Message-ID: <20170808025236.GA15869@minnie.tuhs.org>

Hi all, sorry for this off-topic posting.

I just came across this series of videos where a guy built a CPU out
of 7400 series chips on a breadboard: https://eater.net/8bit/

Anyway, I thought it would be fun to do something similar but with
a bigger address space and as few chips as I could get away with.

I've got a design that works in Logisim, but I've never actually
built anything before with real chips. So, if there's someone on the
list who could quickly look at what I've done and point out problems
or gotchas (or indeed, what ROM/RAM chips to use), that would be great!

The design so far: https://github.com/DoctorWkt/eeprom_cpu

Thanks in advance, Warren


From peter at rulingia.com  Thu Aug 10 18:16:20 2017
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 10 Aug 2017 18:16:20 +1000
Subject: [TUHS] Off-topic: any logic designers here?
In-Reply-To: <20170808025236.GA15869@minnie.tuhs.org>
References: <20170808025236.GA15869@minnie.tuhs.org>
Message-ID: <20170810081620.GA39057@server.rulingia.com>

On 2017-Aug-08 12:52:36 +1000, Warren Toomey <wkt at tuhs.org> wrote:
>Hi all, sorry for this off-topic posting.

Well, just promise to port Unix to it and it won't be off-topic.

>Anyway, I thought it would be fun to do something similar but with
>a bigger address space and as few chips as I could get away with.

Well, using a FPGA or microcontroller will reduce the chip count further.

You suggest that you won't use a 74LS181 because they are no longer made.
Whilst that's true, they are still readily available as NOS.  Overall, I
would suggest that using a 74LS181 (or 4) is a cleaner solution than
(ab)using a couple of EPROMs.  (The other option would be a PAL or GAL but
I suspect finding and programming them would be more difficult).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170810/6faaf987/attachment.sig>

From jason-tuhs at shalott.net  Thu Aug 10 19:56:54 2017
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Thu, 10 Aug 2017 02:56:54 -0700 (PDT)
Subject: [TUHS] Off-topic: any logic designers here?
In-Reply-To: <20170808025236.GA15869@minnie.tuhs.org>
References: <20170808025236.GA15869@minnie.tuhs.org>
Message-ID: <alpine.LRH.2.21.1708100254580.6255@waffle.shalott.net>


> Hi all, sorry for this off-topic posting.
>
> I just came across this series of videos where a guy built a CPU out of 
> 7400 series chips on a breadboard: https://eater.net/8bit/
>
> Anyway, I thought it would be fun to do something similar but with a 
> bigger address space and as few chips as I could get away with.

Doubly off-topic, so doubly sorry...

But for anyone who wants to go the other way, there's this:

http://www.megaprocessor.com/


  -Jason



From krewat at kilonet.net  Thu Aug 10 22:41:01 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 10 Aug 2017 08:41:01 -0400
Subject: [TUHS] Off-topic: any logic designers here?
In-Reply-To: <20170808025236.GA15869@minnie.tuhs.org>
References: <20170808025236.GA15869@minnie.tuhs.org>
Message-ID: <a3bf17e3-bb2c-82a5-75ee-5d9dc09f5124@kilonet.net>

I've used static RAM in the past for projects and it's worked out quite 
well. No refresh cycles, easy to deal with.

As an example (not saying you need 1MB of ram, or that this would fit 
your project...) 
http://www.mouser.com/ds/2/100/CY62167E_16_Mbit_1_%20M_%2016_%202%20M_8_Static_RAM-319235.pdf

And only $13.20 each.

side note: A friend of mine and I built a 68000-based computer using 
128Kbit static RAM chips back in the late 80's. I wrote the 68K 
assembler for it in C, and eventually wanted to boot-strap UNIX to it, 
but never got that far. Back then, static RAM was expensive - these were 
"free" ;)

On 8/7/2017 10:52 PM, Warren Toomey wrote:
> Hi all, sorry for this off-topic posting.
>
> I just came across this series of videos where a guy built a CPU out
> of 7400 series chips on a breadboard: https://eater.net/8bit/
>
> Anyway, I thought it would be fun to do something similar but with
> a bigger address space and as few chips as I could get away with.
>
> I've got a design that works in Logisim, but I've never actually
> built anything before with real chips. So, if there's someone on the
> list who could quickly look at what I've done and point out problems
> or gotchas (or indeed, what ROM/RAM chips to use), that would be great!
>
> The design so far: https://github.com/DoctorWkt/eeprom_cpu
>
> Thanks in advance, Warren
>



From clemc at ccc.com  Fri Aug 11 00:35:29 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 10 Aug 2017 10:35:29 -0400
Subject: [TUHS] Off-topic: any logic designers here?
In-Reply-To: <20170810081620.GA39057@server.rulingia.com>
References: <20170808025236.GA15869@minnie.tuhs.org>
 <20170810081620.GA39057@server.rulingia.com>
Message-ID: <CAC20D2ObE=-iWHpqVMVX=Z04nYU5tseUOkFJm8vPkUf=JLhaXQ@mail.gmail.com>

i agree with Peter, WRT the '181 you can certainly find them in small
qualities in the after market, I may have a handful of them myself.   One
thing you are missing is a small barrel shifter, which the '181 does not
support, but for a 8 bit shift it should not be terrible.   Vaxen and such
built their independently, but it is worth while IMO, as it allows in a
single clock tick to perform pretty substantial arithmetic, although
because it's a sq law the cost in die area is huge. If you look at the 68K
for instance, the big area in the middle everyone sees in the pictures is
the shifter (same for the Alpha chips).

Clem

On Thu, Aug 10, 2017 at 4:16 AM, Peter Jeremy <peter at rulingia.com> wrote:

> On 2017-Aug-08 12:52:36 +1000, Warren Toomey <wkt at tuhs.org> wrote:
> >Hi all, sorry for this off-topic posting.
>
> Well, just promise to port Unix to it and it won't be off-topic.
>
> >Anyway, I thought it would be fun to do something similar but with
> >a bigger address space and as few chips as I could get away with.
>
> Well, using a FPGA or microcontroller will reduce the chip count further.
>
> You suggest that you won't use a 74LS181 because they are no longer made.
> Whilst that's true, they are still readily available as NOS.  Overall, I
> would suggest that using a 74LS181 (or 4) is a cleaner solution than
> (ab)using a couple of EPROMs.  (The other option would be a PAL or GAL but
> I suspect finding and programming them would be more difficult).
>
> --
> Peter Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170810/d96675fb/attachment.html>

From wkt at tuhs.org  Sat Aug 12 09:42:14 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Aug 2017 09:42:14 +1000
Subject: [TUHS] Off-topic: any logic designers here?
In-Reply-To: <20170808025236.GA15869@minnie.tuhs.org>
References: <20170808025236.GA15869@minnie.tuhs.org>
Message-ID: <20170811234214.GA21053@minnie.tuhs.org>

On Tue, Aug 08, 2017 at 12:52:36PM +1000, Warren Toomey wrote:
>Anyway, I thought it would be fun to do something similar but with
>a bigger address space and as few chips as I could get away with.

All, many thanks for the feedback. I've taken it all on-board and
hopefully it will help when I get to building the thing :)
Cheers, Warren


From itz at very.loosely.org  Sun Aug 13 03:03:31 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 12 Aug 2017 10:03:31 -0700
Subject: [TUHS] Slightly [OT]: 12 year old bug quashed by debian
Message-ID: <20170812170331.qhrufin32uwebilb@matica.foolinux.mooo.com>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401792

I think this qualifies as history :-)  At least for me personally, the
last 12 years feel like a lifetime.

It is significant that so far the report has not been ported forward to
a newer emacs version (as it had been previously from 21 to 24).  I have
no newer version installed so I cannot check but I bet the bug is still
present.  Maybe someone else on the list can check?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From doug at cs.dartmouth.edu  Sun Aug 13 11:58:19 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 12 Aug 2017 21:58:19 -0400
Subject: [TUHS] origin of string.h and ctype.h
Message-ID: <201708130158.v7D1wJJM026143@coolidge.cs.Dartmouth.EDU>

Jon Steinhart <jon at fourwinds.com> asked this question (not on tuhs).
It highlights some less well known contributors to research Unix.

> I'm trying to find out who came up with strcmp and the idea of
> returning -1,0,1 for a string comparison.  I can see that it's not in
> my V6 manual but is in V7.  Don't see anything in Algol, PL/I, BCPL, or B

The -1,0,1 return from comparisons stems from the interface of qsort,
which was written by Lee McMahon. As far as I know, the interface for
the comparison-function parameter originated with him, but conceivably
he borrowed it from some other sort utility. The negative-zero-positive
convention for the return value encouraged (and perhaps was motivated by)
this trivial comparison function for integers
	int compar(a,b) { return(a-b); }
This screws up on overflow, so cautious folks would write it with
comparisons. And -1,0,1 were the easiest conventional values to return:
	int compar(a,b) {
		if(a<b) return(-1);
		if(a>b) return(1);
		return(0);
	}
qsort was in v2. In v3 a string-comparison routine called "compar"
appeared, with a man page titled "string comparison for sort". So the
convention was established early on.

Compar provided the model for strcmp, one of a package of basic string
operations that came much later, in v7, under the banner of string.h
and ctype.h.

These packages were introduced at the urging of Nils-Peter Nelson, a
good friend of the Unix lab, who was in the Bell Labs comp center.
Here's the story in his own words.

I wrote a memo to dmr with some suggestions for additions to C.  I asked
for the str... because the mainframes had single instructions to implement
them. I know for sure I had a blindingly fast implementation of isupper,
ispunct, etc. I had a table of length 128 integers for the ascii character
set; I assigned bits for upper, lower, numeric, punct, control, etc. So
ispunct(c) became

	#define PUNCT 0400
	return(qtable[c]&PUNCT)
instead of
	if(c==':' || c ==';' || ...
[or
	switch(c) {
		default:
			return 0;
		case ':':
		case ';':
		...
		return 1;
	}
MDM]
dmr argued people could easily write their own but when I showed
him my qtable was 20 times faster he gave in.  I also asked for type
logical which dmr implemented as unsigned, which was especially useful
when bitfields were implemented (a 2 bit int would have values -2, -1,
0, 1 instead of 0, 1, 2, 3).  I requested a way to interject assembler,
which became asm() (yes, a bad idea).


From scj at yaccman.com  Sun Aug 13 13:39:53 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 12 Aug 2017 20:39:53 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <201708130158.v7D1wJJM026143@coolidge.cs.Dartmouth.EDU>
Message-ID: <fad1f52c0d4027058cf5258c4758ba0e159f9a98@webmail.yaccman.com>


Don't have much to add except to note that early FORTRANs had a
version of IF that took three statement numbers and did a (gasp) GOTO
to the first if the expression in the IF was negative, to the second
if it was 0, and to the third if it was positive.   And some
mainframes had an instruction that did exactly that as well...

Steve

----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Sat, 12 Aug 2017 21:58:19 -0400
Subject:[TUHS] origin of string.h and ctype.h

 Jon Steinhart <jon at fourwinds.com> asked this question (not on tuhs).
 It highlights some less well known contributors to research Unix.

 > I'm trying to find out who came up with strcmp and the idea of
 > returning -1,0,1 for a string comparison. I can see that it's not
in
 > my V6 manual but is in V7. Don't see anything in Algol, PL/I, BCPL,
or B

 The -1,0,1 return from comparisons stems from the interface of qsort,
 which was written by Lee McMahon. As far as I know, the interface for
 the comparison-function parameter originated with him, but
conceivably
 he borrowed it from some other sort utility. The
negative-zero-positive
 convention for the return value encouraged (and perhaps was motivated
by)
 this trivial comparison function for integers
 int compar(a,b) { return(a-b); }
 This screws up on overflow, so cautious folks would write it with
 comparisons. And -1,0,1 were the easiest conventional values to
return:
 int compar(a,b) {
 if(a<b) return(-1);
 if(a>b) return(1);
 return(0);
 }
 qsort was in v2. In v3 a string-comparison routine called "compar"
 appeared, with a man page titled "string comparison for sort". So the
 convention was established early on.

 Compar provided the model for strcmp, one of a package of basic
string
 operations that came much later, in v7, under the banner of string.h
 and ctype.h.

 These packages were introduced at the urging of Nils-Peter Nelson, a
 good friend of the Unix lab, who was in the Bell Labs comp center.
 Here's the story in his own words.

 I wrote a memo to dmr with some suggestions for additions to C. I
asked
 for the str... because the mainframes had single instructions to
implement
 them. I know for sure I had a blindingly fast implementation of
isupper,
 ispunct, etc. I had a table of length 128 integers for the ascii
character
 set; I assigned bits for upper, lower, numeric, punct, control, etc.
So
 ispunct(c) became

 #define PUNCT 0400
 return(qtable[c]&PUNCT)
 instead of
 if(c==':' || c ==';' || ...
 [or
 switch(c) {
 default:
 return 0;
 case ':':
 case ';':
 ...
 return 1;
 }
 MDM]
 dmr argued people could easily write their own but when I showed
 him my qtable was 20 times faster he gave in. I also asked for type
 logical which dmr implemented as unsigned, which was especially
useful
 when bitfields were implemented (a 2 bit int would have values -2,
-1,
 0, 1 instead of 0, 1, 2, 3). I requested a way to interject
assembler,
 which became asm() (yes, a bad idea).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170812/c5568a90/attachment.html>

From dave at horsfall.org  Sun Aug 13 14:26:53 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 13 Aug 2017 14:26:53 +1000 (EST)
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <fad1f52c0d4027058cf5258c4758ba0e159f9a98@webmail.yaccman.com>
References: <fad1f52c0d4027058cf5258c4758ba0e159f9a98@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.21.1708131426100.33355@aneurin.horsfall.org>

On Sat, 12 Aug 2017, Steve Johnson wrote:

> Don't have much to add except to note that early FORTRANs had a version 
> of IF that took three statement numbers and did a (gasp) GOTO to the 
> first if the expression in the IF was negative, to the second if it was 
> 0, and to the third if it was positive.   And some mainframes had an 
> instruction that did exactly that as well...

Wasn't that the computed GOTO?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From scj at yaccman.com  Sun Aug 13 15:27:09 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 12 Aug 2017 22:27:09 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <alpine.BSF.2.21.1708131426100.33355@aneurin.horsfall.org>
Message-ID: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>


A little Googling shows that the IF I mentioned was called the
"arithmetic IF".   There was also a Computed GOTO that branched to
one of N labels depending on the value of the expression.   And an
Assigned GOTO whose main use, as I remember, was to allow for error
recovery when a subroutine failed...

Steve 

----- Original Message -----
From: "Dave Horsfall" <dave at horsfall.org>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Sun, 13 Aug 2017 14:26:53 +1000 (EST)
Subject:Re: [TUHS] origin of string.h and ctype.h

 On Sat, 12 Aug 2017, Steve Johnson wrote:

 > Don't have much to add except to note that early FORTRANs had a
version 
 > of IF that took three statement numbers and did a (gasp) GOTO to
the 
 > first if the expression in the IF was negative, to the second if it
was 
 > 0, and to the third if it was positive.   And some mainframes had
an 
 > instruction that did exactly that as well...

 Wasn't that the computed GOTO?

 -- 
 Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170812/262ac1a8/attachment.html>

From dave at horsfall.org  Sun Aug 13 15:43:22 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 13 Aug 2017 15:43:22 +1000 (EST)
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
References: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.21.1708131537420.33355@aneurin.horsfall.org>

On Sat, 12 Aug 2017, Steve Johnson wrote:

> A little Googling shows that the IF I mentioned was called the 
> "arithmetic IF".

Ah yes.  It was in FORTRAN II, as I recall.

> There was also a Computed GOTO that branched to one of N labels
> depending on the value of the expression.

I think that was still in FORTRAN IV?

> And an Assigned GOTO whose main use, as I remember, was to allow for 
> error recovery when a subroutine failed...

A real ugly statement; you assigned a statement number to a variable, then 
did a sort of indirect GOTO (or did the compiler recognise "GOTO I")?

How those poor devils ever debugged their code with such monstrous 
constructions I'll never know.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From arnold at skeeve.com  Sun Aug 13 18:42:40 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 13 Aug 2017 02:42:40 -0600
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
References: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
Message-ID: <201708130842.v7D8geZT025737@freefriends.org>

Ah yes, the arithmetic if.  Long ago, I wrote a short paper in the style of
"real programmers don't use pascal" defending the arithmetic if and
encouraging its adoption in newer languages. (All tongue in cheek, of
course.)

For fun, I found it, and put it up at www.skeeve.com/if.pdf.

Enjoy,

Arnold

"Steve Johnson" <scj at yaccman.com> wrote:

> A little Googling shows that the IF I mentioned was called the
> "arithmetic IF".   There was also a Computed GOTO that branched to
> one of N labels depending on the value of the expression.   And an
> Assigned GOTO whose main use, as I remember, was to allow for error
> recovery when a subroutine failed...
>
> Steve 
>
> ----- Original Message -----
> From: "Dave Horsfall" <dave at horsfall.org>
> To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
> Cc:
> Sent:Sun, 13 Aug 2017 14:26:53 +1000 (EST)
> Subject:Re: [TUHS] origin of string.h and ctype.h
>
>  On Sat, 12 Aug 2017, Steve Johnson wrote:
>
>  > Don't have much to add except to note that early FORTRANs had a
> version 
>  > of IF that took three statement numbers and did a (gasp) GOTO to
> the 
>  > first if the expression in the IF was negative, to the second if it
> was 
>  > 0, and to the third if it was positive.   And some mainframes had
> an 
>  > instruction that did exactly that as well...
>
>  Wasn't that the computed GOTO?
>
>  -- 
>  Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
> suffer."
>



From imp at bsdimp.com  Mon Aug 14 03:24:02 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 13 Aug 2017 11:24:02 -0600
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <alpine.BSF.2.21.1708131537420.33355@aneurin.horsfall.org>
References: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
 <alpine.BSF.2.21.1708131537420.33355@aneurin.horsfall.org>
Message-ID: <CANCZdfr51rTU3QASJ70YzX-NvEW06_BzRytZUimBwbTQQW4gpQ@mail.gmail.com>

On Sat, Aug 12, 2017 at 11:43 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 12 Aug 2017, Steve Johnson wrote:
>
> A little Googling shows that the IF I mentioned was called the "arithmetic
>> IF".
>>
>
> Ah yes.  It was in FORTRAN II, as I recall.


Yes. It originated there.

 There was also a Computed GOTO that branched to one of N labels
>> depending on the value of the expression.
>>
>
> I think that was still in FORTRAN IV?


It was still in Fortran 77.

N=3
goto (10, 20, 30, 40, 50), N

would goto label 30.

 And an Assigned GOTO whose main use, as I remember, was to allow for error
>> recovery when a subroutine failed...
>>
>
> A real ugly statement; you assigned a statement number to a variable, then
> did a sort of indirect GOTO (or did the compiler recognise "GOTO I")?
>
> How those poor devils ever debugged their code with such monstrous
> constructions I'll never know.


assign 10 to N
....
goto N

would goto the label 10 in your fortran program. Label 10 must be in the
same compilation unit, and can't be in the middle of a block.

You could make this one better by giving a list of possible statements. I
saw it used effectively when one of N sub formulas was needed later in a
computation in some code doing a complex computations that used it to avoid
division by zero and also optimize the terms used in part of the
calculation. I've also seen it in some truly horrific code too terrible to
relate. But it was relatively rare in the FORTRAN code I dealt with back in
the day...

What made it not totally horrific was that N had to be assigned a label
that was in the functional unit (so it wasn't arbitrary).

If you'd seen some of the spaghetti FORTRAN code I have, you'd know that
these weren't the worst offenders for making things unreadable nightmares,
though they didn't help.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170813/0a21e94b/attachment.html>

From usotsuki at buric.co  Mon Aug 14 04:23:03 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 13 Aug 2017 14:23:03 -0400 (EDT)
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <CANCZdfr51rTU3QASJ70YzX-NvEW06_BzRytZUimBwbTQQW4gpQ@mail.gmail.com>
References: <69d306adcac795596fda674fd82ec5f2fc975884@webmail.yaccman.com>
 <alpine.BSF.2.21.1708131537420.33355@aneurin.horsfall.org>
 <CANCZdfr51rTU3QASJ70YzX-NvEW06_BzRytZUimBwbTQQW4gpQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1708131422150.8920@frieza.hoshinet.org>

On Sun, 13 Aug 2017, Warner Losh wrote:

> It was still in Fortran 77.
>
> N=3
> goto (10, 20, 30, 40, 50), N
>
> would goto label 30.

Reminds me of Microsoft Basic... ON N GOTO 10, 20, 30, 40, 50

-uso.


From bqt at update.uu.se  Mon Aug 14 07:55:40 2017
From: bqt at update.uu.se (Johnny Billquist)
Date: Sun, 13 Aug 2017 23:55:40 +0200
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
Message-ID: <aee9672f-a25a-4656-32ad-301d1929e653@update.uu.se>

On 2017-08-13 19:24, Dave Horsfall <dave at horsfall.org> wrote:
> On Sat, 12 Aug 2017, Steve Johnson wrote:
>> A little Googling shows that the IF I mentioned was called the
>> "arithmetic IF".
> Ah yes.  It was in FORTRAN II, as I recall.

Still there in FORTRAN 77.

>>  There was also a Computed GOTO that branched to one of N labels
>> depending on the value of the expression.
> I think that was still in FORTRAN IV?

Still there in FORTRAN 77.

>>  And an Assigned GOTO whose main use, as I remember, was to allow for
>> error recovery when a subroutine failed...
> A real ugly statement; you assigned a statement number to a variable, then
> did a sort of indirect GOTO (or did the compiler recognise "GOTO I")?

The compiler recognize "GOTO I". And I have to be assigned to a 
statement number (label). It has to be an integer variable, and when you 
assign it to a label, you cannot do any arithmetic with it anymore. And 
you assign it with a special statement. Thus, it can be used to store 
what label to jump to, but you cannot use arithmetic to set what it 
should jump to.

> How those poor devils ever debugged their code with such monstrous
> constructions I'll never know.

It's actually not that hard. All this stuff is fairly simple to deal 
with. The real horror in FORTRAN is EQUIVALENCE, which can give C a fair 
fight for real horror stories.

But of course, bad programmers can mess things up beyond belief in any 
language.

(And I never went beyond FORTRAN 77, so I don't know how current 
versions look like. I stayed with PDP-11s (well, still do), and nothing 
newer than FORTRAN 77 exists there. :-) )

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From charles.unix.pro at gmail.com  Mon Aug 14 08:26:09 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sun, 13 Aug 2017 15:26:09 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <aee9672f-a25a-4656-32ad-301d1929e653@update.uu.se>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <aee9672f-a25a-4656-32ad-301d1929e653@update.uu.se>
Message-ID: <CANV78LQU2mproMHN-ekbURzr-KebnCPBenu+U=XwsE-FrqH0Ag@mail.gmail.com>

On Sun, Aug 13, 2017 at 2:55 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2017-08-13 19:24, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sat, 12 Aug 2017, Steve Johnson wrote:
>>
>>> A little Googling shows that the IF I mentioned was called the
>>> "arithmetic IF".
>>>
>> Ah yes.  It was in FORTRAN II, as I recall.
>>
>
> Still there in FORTRAN 77.
>
>  There was also a Computed GOTO that branched to one of N labels
>>> depending on the value of the expression.
>>>
>> I think that was still in FORTRAN IV?
>>
>
> Still there in FORTRAN 77.
>
>  And an Assigned GOTO whose main use, as I remember, was to allow for
>>> error recovery when a subroutine failed...
>>>
>> A real ugly statement; you assigned a statement number to a variable, then
>> did a sort of indirect GOTO (or did the compiler recognise "GOTO I")?
>>
>
> The compiler recognize "GOTO I". And I have to be assigned to a statement
> number (label). It has to be an integer variable, and when you assign it to
> a label, you cannot do any arithmetic with it anymore. And you assign it
> with a special statement. Thus, it can be used to store what label to jump
> to, but you cannot use arithmetic to set what it should jump to.
>
> How those poor devils ever debugged their code with such monstrous
>> constructions I'll never know.
>>
>
> It's actually not that hard. All this stuff is fairly simple to deal with.
> The real horror in FORTRAN is EQUIVALENCE, which can give C a fair fight
> for real horror stories.
>

IIRC, PRIMOS was written in FORTRAN, and they had an extension where you
could pass assigned GOTO variables as parameters and to jump globally; I
don't recall the stack semantics, but I would guess setjmp/longjmp style.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170813/fbac560f/attachment.html>

From paul at mcjones.org  Mon Aug 14 10:02:48 2017
From: paul at mcjones.org (Paul McJones)
Date: Sun, 13 Aug 2017 17:02:48 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
Message-ID: <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>

On Sun, 13 Aug 2017, Dave Horsfall wrote:

> On Sat, 12 Aug 2017, Steve Johnson wrote:
> 
>> A little Googling shows that the IF I mentioned was called the 
>> "arithmetic IF".
> 
> Ah yes.  It was in FORTRAN II, as I recall.

It turns out the original FORTRAN (manual published in October 1956; code first shipped around April 1957) included the arithmetic IF as well as the assigned and computed GOTO statements — see chapter 4 of this manual:

J.W. Backus, R.J. Beeber, S. Best, R. Goldberg, H.L. Herrick, R.A. Hughes, L.B. Mitchell, R.A. Nelson, R. Nutt, D. Sayre, P.B. Sheridan, H. Stern, I. Ziller. The FORTRAN Automatic Coding System for the IBM 704 EDPM : Programmer's Reference Manual. Applied Science Division and Programming Research Department, International Business Machines Corporation, October 15, 1956, 51 pages.
http://www.bitsavers.org/pdf/ibm/704/704_FortranProgRefMan_Oct56.pdf

(For more on the original FORTRAN compiler, see http://www.softwarepreservation.org/projects/FORTRAN/.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170813/0d2baa3d/attachment.html>

From sauer at technologists.com  Mon Aug 14 13:15:14 2017
From: sauer at technologists.com (Charles H. Sauer)
Date: Sun, 13 Aug 2017 22:15:14 -0500
Subject: [TUHS] further off topic: Fortran was OK
Message-ID: <4584DCFF-3B13-4F2A-B2C0-89D41791C9D1@technologists.com>

TL;DR - I learned procedural programming in Fortran, wrote essentially the same queueing network solution algorithms and simulator in Fortran, then PL/I, then Pascal. For those purposes, PL/I seemed best, but Fortran was OK. (With Fortran and PL/I) the critical issue was to avoid undesirable constructs of the language.

When I got started with procedural programming at U.T. Austin C.S. in 1971, the dominant machine and language was CDC 6600 Fortran. For my dissertation I needed to write a queueing network simulator to attempt to validate approximate numerical methods I developed. Though by then Pascal was an option, Fortran seemed expedient.

In 1975 I joined IBM Yorktown and was asked to dramatically enhance my simulator. It became the core of the “Research Queueing Package” (http://web.archive.org/web/20130627040507/http://www.research.ibm.com/compsci/performance/history.html#RESQ). For the first year or so, I continued to use Fortran. From my perspective, the biggest problems weren’t the bad features, which I could avoid, but the lack of more natural control structures, pointers, and something like structs. My managers lamented that I wasn’t using PL/I. I spent a couple of weeks crafting a SNOBOL program to successfully translate the Fortran to PL/I. For the next decade plus, RESQ development was in PL/I (even after I left Yorktown and subsequently left IBM).

While writing Computer Systems Performance Modeling (https://www.amazon.com/exec/obidos/ISBN=0131651757/0596-2808191-282542), I wanted to illustrate the analysis, algorithms, and simulation concepts developed with RESQ, but be careful not to take anything directly from RESQ. So I wrote everything for the book in PASCAL. 

For a variety of reasons, I remember much preferring PL/I over Fortran and Pascal. The Pascal development environments I used weren’t as productive as the PL/I environments.  Fortran was missing very useful constructs. But Fortran was OK, in my experience.
--
voice: +1.512.784.7526       e-mail: sauer at technologists.com <mailto:sauer at technologists.com>           
fax: +1.512.346.5240         web: http://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/Skype/Twitter: CharlesHSauer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170813/cf3f8507/attachment.html>

From mutiny.mutiny at rediffmail.com  Mon Aug 14 21:08:26 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 14 Aug 2017 11:08:26 -0000
Subject: [TUHS] =?utf-8?q?origin_of_string=2Eh_and_ctype=2Eh?=
In-Reply-To: <alpine.BSF.2.21.1708131426100.33355@aneurin.horsfall.org>
Message-ID: <1502598467.S.5605.9556.f4-234-243.1502708906.16411@webmail.rediffmail.com>

libc.strcmp() behaves similar.From: Dave Horsfall &lt;dave at horsfall.org&gt;Sent: Sun, 13 Aug 2017 09:57:47To: The Eunuchs Hysterical Society &lt;tuhs at tuhs.org&gt;Subject: Re: [TUHS] origin of string.h and ctype.hOn Sat, 12 Aug 2017, Steve Johnson wrote:&gt; Don&#39;t have much to add except to note that early FORTRANs had a version&gt; of IF that took three statement numbers and did a (gasp) GOTO to the&gt; first if the expression in the IF was negative, to the second if it was&gt; 0, and to the third if it was positive. &nbsp; &nbsp;And some mainframes had an&gt; instruction that did exactly that as well...Wasn&#39;t that the computed GOTO?--Dave Horsfall DTM (VK2KFU) &nbsp;&quot;Those who don&#39;t understand security will suffer.&quot;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170814/daf2e10d/attachment.html>

From paul.winalski at gmail.com  Tue Aug 15 02:09:54 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 14 Aug 2017 12:09:54 -0400
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
Message-ID: <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>

On 8/13/17, Paul McJones <paul at mcjones.org> wrote:
> On Sun, 13 Aug 2017, Dave Horsfall wrote:
>
>> On Sat, 12 Aug 2017, Steve Johnson wrote:
>>
>>> A little Googling shows that the IF I mentioned was called the
>>> "arithmetic IF".
>>
>> Ah yes.  It was in FORTRAN II, as I recall.

The FORTRAN II arithmetic IF, with its three-way branch, was probably
introduced to facilitate use of the conditional branch instructions of
the IBM 704, which test the value of the accumulator and take a branch
accordingly:

    TMI (transfer on minus)
    TMP (transfer on plus)
    TZE (transfer on zero)
    TNZ (transfer on not zero)

It takes at most two of these instructions to implement the arithmetic IF.

-Paul W.
>
> It turns out the original FORTRAN (manual published in October 1956; code
> first shipped around April 1957) included the arithmetic IF as well as the
> assigned and computed GOTO statements — see chapter 4 of this manual:
>
> J.W. Backus, R.J. Beeber, S. Best, R. Goldberg, H.L. Herrick, R.A. Hughes,
> L.B. Mitchell, R.A. Nelson, R. Nutt, D. Sayre, P.B. Sheridan, H. Stern, I.
> Ziller. The FORTRAN Automatic Coding System for the IBM 704 EDPM :
> Programmer's Reference Manual. Applied Science Division and Programming
> Research Department, International Business Machines Corporation, October
> 15, 1956, 51 pages.
> http://www.bitsavers.org/pdf/ibm/704/704_FortranProgRefMan_Oct56.pdf
>
> (For more on the original FORTRAN compiler, see
> http://www.softwarepreservation.org/projects/FORTRAN/.)


From paul at mcjones.org  Tue Aug 15 03:16:57 2017
From: paul at mcjones.org (Paul McJones)
Date: Mon, 14 Aug 2017 10:16:57 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
 <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
Message-ID: <09B7C59A-E3D4-4EA1-8DBE-794110D1CEBE@mcjones.org>

> On Aug 14, 2017, at 9:09 AM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
>>> ...
> 
> The FORTRAN II arithmetic IF, with its three-way branch, was probably
> introduced to facilitate use of the conditional branch instructions of
> the IBM 704, which test the value of the accumulator and take a branch
> accordingly:
> 
>    TMI (transfer on minus)
>    TMP (transfer on plus)
>    TZE (transfer on zero)
>    TNZ (transfer on not zero)
> 
> It takes at most two of these instructions to implement the arithmetic IF.

And the 709 added CAS (compare accumulator with storage): it skips 0, 1, or 2 instructions depending on whether the contents of the accumulator are algebraically greater, equal, or less than the contents of the referenced memory location. (See page 49 of http://www.bitsavers.org/pdf/ibm/709/709_RefMan_Fortran.pdf.)

From dave at horsfall.org  Tue Aug 15 10:37:58 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 Aug 2017 10:37:58 +1000 (EST)
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
 <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1708151035320.33355@aneurin.horsfall.org>

On Mon, 14 Aug 2017, Paul Winalski wrote:

[ Ye olde 704 ]

>    TMP (transfer on plus)

That's rather an odd mnemonic...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From paul at mcjones.org  Tue Aug 15 13:06:02 2017
From: paul at mcjones.org (Paul McJones)
Date: Mon, 14 Aug 2017 20:06:02 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <mailman.1.1502762401.21962.tuhs@minnie.tuhs.org>
References: <mailman.1.1502762401.21962.tuhs@minnie.tuhs.org>
Message-ID: <B0341A0A-9AB5-498F-9567-60782989D47F@mcjones.org>

On Tue, 15 Aug 2017, Dave Horsfall <dave at horsfall.org> wrote:

>> On Mon, 14 Aug 2017, Paul Winalski wrote:
>> 
>> [ Ye olde 704 ]
>> 
>>>   TMP (transfer on plus)
>> 
> That's rather an odd mnemonic…

Actually, the 704 manual of operation gives the mnemonic as TPL:

http://www.bitsavers.org/pdf/ibm/704/24-6661-2_704_Manual_1955.pdf



From grog at lemis.com  Tue Aug 15 13:57:51 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 15 Aug 2017 13:57:51 +1000
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <09B7C59A-E3D4-4EA1-8DBE-794110D1CEBE@mcjones.org>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
 <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
 <09B7C59A-E3D4-4EA1-8DBE-794110D1CEBE@mcjones.org>
Message-ID: <20170815035751.GC20775@eureka.lemis.com>

On Monday, 14 August 2017 at 10:16:57 -0700, Paul McJones wrote:
>> On Aug 14, 2017, at 9:09 AM, Paul Winalski <paul.winalski at gmail.com> wrote:
>>
>>>> ...
>>
>> The FORTRAN II arithmetic IF, with its three-way branch, was probably
>> introduced to facilitate use of the conditional branch instructions of
>> the IBM 704, which test the value of the accumulator and take a branch
>> accordingly:
>>
>>    TMI (transfer on minus)
>>    TMP (transfer on plus)

My reference says TPL.

>>    TZE (transfer on zero)
>>    TNZ (transfer on not zero)
>>
>> It takes at most two of these instructions to implement the arithmetic IF.
>
> And the 709 added CAS (compare accumulator with storage): it skips
> 0, 1, or 2 instructions depending on whether the contents of the
> accumulator are algebraically greater, equal, or less than the
> contents of the referenced memory location.

It was my understanding that the 704 had this instruction too, and
that it was almost certainly the background for arithmetic IF.
Unfortunately, no reference I can find can confirm or deny this
supposition.  Another one is http://www.quadibloc.com/comp/cp0309.htm,
which compares the instruction sets, but it's not categorical enough
for my liking.  But if I interpret it correctly, CAS was implemented
on the 704.

Do you see a proof of the contrary?

In passing, my document also mentions the Honeywell 516, better known
to Unix people as IMP.  It, too, had a CAS-like instruction.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170815/d5060e11/attachment.sig>

From paul at mcjones.org  Tue Aug 15 14:13:41 2017
From: paul at mcjones.org (Paul McJones)
Date: Mon, 14 Aug 2017 21:13:41 -0700
Subject: [TUHS] origin of string.h and ctype.h
In-Reply-To: <20170815035751.GC20775@eureka.lemis.com>
References: <mailman.919.1502645045.3779.tuhs@minnie.tuhs.org>
 <2ECAA475-891E-45D0-A354-B0B17284C138@mcjones.org>
 <CABH=_VSZXxVnVEmC5NeZ-HQ3LcaTAEvA9iduNXy7LVU5dZYBAQ@mail.gmail.com>
 <09B7C59A-E3D4-4EA1-8DBE-794110D1CEBE@mcjones.org>
 <20170815035751.GC20775@eureka.lemis.com>
Message-ID: <669C160E-DB0A-4968-94F0-9D02DB8EFC95@mcjones.org>

On Aug 14, 2017, at 8:57 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> It was my understanding that the 704 had this instruction [CAS] too, and
> that it was almost certainly the background for arithmetic IF.
> Unfortunately, no reference I can find can confirm or deny this
> supposition.  Another one is http://www.quadibloc.com/comp/cp0309.htm,
> which compares the instruction sets, but it's not categorical enough
> for my liking.  But if I interpret it correctly, CAS was implemented
> on the 704.
> 
> Do you see a proof of the contrary?

It turns out CAS is used in many places in the source code of the 4K and 8K drum versions of the final IBM 704 FORTRAN II compiler. See http://www.softwarepreservation.org/projects/FORTRAN/index.html#Source_code; in particular:

Transcribed source: http://www.softwarepreservation.org/projects/FORTRAN/source/fortran-ii/fort1.asm.html
Assembly listing: http://www.softwarepreservation.org/projects/FORTRAN/source/fortran-ii/fort1.lst.html

I didn’t try to figure out if this code generates CAS, but it certainly uses it.

From doug at cs.dartmouth.edu  Thu Aug 17 02:52:20 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 16 Aug 2017 12:52:20 -0400
Subject: [TUHS] TUHS] origin of string.h and ctype.h
Message-ID: <201708161652.v7GGqKCh043689@tahoe.cs.Dartmouth.EDU>

>> the 709 added CAS

> It was my understanding that the 704 had this instruction too

Yes. It's in the manual.

(I searched in vain for an online manual. A quick trip to the
attic turned up the real thing in less time.)

Doug


From paul.winalski at gmail.com  Thu Aug 17 04:04:47 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 16 Aug 2017 14:04:47 -0400
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
Message-ID: <CABH=_VR3_Fp6Fw4weAC0n-Q-sFbs+-L-zmpTXPCSSQXUzP0TmA@mail.gmail.com>

On 8/16/17, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>> the 709 added CAS
>
>> It was my understanding that the 704 had this instruction too
>
> Yes. It's in the manual.
>
> (I searched in vain for an online manual. A quick trip to the
> attic turned up the real thing in less time.)
>
> Doug
>
>From what I've been able to determine, FORTRAN came out shortly after
the IBM 704.  Undoubtedly both were under development at the same
time.  So the question is, was arithmetic IF put in FORTRAN to take
advantage of the CAS instruction, or was CAS added to the IBM 704
instruction set to provide hardware support for arithmetic IF?  Or
maybe neither?

According to the Wikipedia article on FORTRAN, CAS was usually not the
most efficient way to implement arithmetic IF anyway.  CAS takes up
four words of memory and takes three cycles to execute, whereas you
can do it in two words and two cycles with the transfer instructions.

-Paul W.


From grog at lemis.com  Thu Aug 17 09:54:19 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 17 Aug 2017 09:54:19 +1000
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
In-Reply-To: <CABH=_VR3_Fp6Fw4weAC0n-Q-sFbs+-L-zmpTXPCSSQXUzP0TmA@mail.gmail.com>
References: <CABH=_VR3_Fp6Fw4weAC0n-Q-sFbs+-L-zmpTXPCSSQXUzP0TmA@mail.gmail.com>
Message-ID: <20170816235419.GA91313@eureka.lemis.com>

On Wednesday, 16 August 2017 at 14:04:47 -0400, Paul Winalski wrote:
> On 8/16/17, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>>> the 709 added CAS
>>
>>> It was my understanding that the 704 had this instruction too
>>
>> Yes. It's in the manual.
>>
>> (I searched in vain for an online manual. A quick trip to the
>> attic turned up the real thing in less time.)
>
> From what I've been able to determine, FORTRAN came out shortly
> after the IBM 704.  Undoubtedly both were under development at the
> same time.

I think there's some doubt about those statements.  The 704 was
introduced in 1954, and FORTRAN didn't appear until late 1956 or 1957.
That's a long time in the history of computing.

> So the question is, was arithmetic IF put in FORTRAN to take
> advantage of the CAS instruction, or was CAS added to the IBM 704
> instruction set to provide hardware support for arithmetic IF?  Or
> maybe neither?

I think the arithmetic IF was put into FORTRAN because it was easy to
implement with the CAS instruction.  It doesn't make much sense from a
mathematical point of view.

> According to the Wikipedia article on FORTRAN, CAS was usually not the
> most efficient way to implement arithmetic IF anyway.  CAS takes up
> four words of memory and takes three cycles to execute, whereas you
> can do it in two words and two cycles with the transfer instructions.

Looking at the assembly listings of the FORTRAN II compiler
(http://www.softwarepreservation.org/projects/FORTRAN/source/fortran-ii/fort1.lst.html,
mentioned by Paul McJones), a typical use of CAS is followed by two
unconditional TRA (transfer) instructions and further code, though
presumably early FORTRAN compilers would not optimize in this way.
Timing includes loading an operand from memory.  The conditional
transfer instructions are based on accumulator contents, so you'd need
to perform some arithmetic operation first, in the process possibly
destroying accumulator contents that you want.

Doubtless you're right in some (many) cases, but my guess is that the
authors of FORTRAN were looking for the cheapest solution, not the
fastest one.  For decades to come, the fastest solution was assembler.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170817/fc50a99c/attachment.sig>

From doug at cs.dartmouth.edu  Thu Aug 17 23:38:56 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 17 Aug 2017 09:38:56 -0400
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
Message-ID: <201708171338.v7HDcu2s006401@coolidge.cs.Dartmouth.EDU>

> According to the Wikipedia article on FORTRAN, CAS was usually not the
> most efficient way to implement arithmetic IF anyway.  CAS takes up
> four words of memory and takes three cycles to execute, whereas you
> can do it in two words and two cycles with the transfer instructions.

Though the article's conclusion was right, its numbers were wrong. 
As a correct discussion of possible implementations of arithmetic-IF
would be long and essentially off topic, I have chopped most of it
out of the article.

doug


From arnold at skeeve.com  Fri Aug 18 00:42:07 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 08:42:07 -0600
Subject: [TUHS] CSTR 122 on CHEM?
Message-ID: <201708171442.v7HEg7Su008572@freefriends.org>

Does anyone have this, even just in PostScript?

Thanks,

Arnold

P.S. Chem itself is at http://www.netlib.org/typesetting/chem.


From arnold at skeeve.com  Fri Aug 18 00:04:38 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 08:04:38 -0600
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
In-Reply-To: <20170816235419.GA91313@eureka.lemis.com>
References: <CABH=_VR3_Fp6Fw4weAC0n-Q-sFbs+-L-zmpTXPCSSQXUzP0TmA@mail.gmail.com>
 <20170816235419.GA91313@eureka.lemis.com>
Message-ID: <201708171404.v7HE4cRB004661@freefriends.org>

"Greg 'groggy' Lehey" <grog at lemis.com> wrote:

> Looking at the assembly listings of the FORTRAN II compiler
> (http://www.softwarepreservation.org/projects/FORTRAN/source/fortran-ii/fort1.lst.html,
> mentioned by Paul McJones), a typical use of CAS is followed by two
> unconditional TRA (transfer) instructions and further code, though
> presumably early FORTRAN compilers would not optimize in this way.

You'd have to run some FORTRAN through the compiler to see.  :-)

I remember reading an article somewhere on the history of the first
FORTRAN compiler.  The guys doing it wanted it to succeed, and they
were fighting the mentality that high level languages could not possibly
be as efficient as hand-coded assembly, so they put a lot of work into
the optimization of the generated code.

It worked so well that the results that came out of the compiler
sometimes suprised the compiler writers!  They then would have to
dive into the compiler sources to figure out how it was done.

I don't remember where I read this article. If the story rings a
bell with anyone, let me know.

Thanks,

Arnold


From doug at cs.dartmouth.edu  Fri Aug 18 01:14:49 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 17 Aug 2017 11:14:49 -0400
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
Message-ID: <201708171514.v7HFEnUr007131@coolidge.cs.Dartmouth.EDU>

> [Fortran's optimization]  worked so well that the results that came out of the compiler
> sometimes suprised the compiler writers!

Except when it didn't. They gave particular attention to nested
loops with subscripted variables, exemplified by linear-algebra
computations. But their algorithms behaved quite wildly on
nonstandard loops. Vic Vyssotsky cooked up a nest of loops
surrounding a single awful statement that filled up the
maximum 10 continuation lines with triple subscripts in all
permutations of several variables. That statement compiled
into thousands of instructions, far more than a naively
written compiler would have produced.

doug


From steve at quintile.net  Fri Aug 18 02:39:36 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 17 Aug 2017 17:39:36 +0100
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171442.v7HEg7Su008572@freefriends.org>
Message-ID: <77908e10000151ffdc0b77842d8c74ca@quintile.net>

http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 38
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170817/98c0537e/attachment.mht>

From arnold at skeeve.com  Fri Aug 18 00:42:07 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 08:42:07 -0600
Subject: [TUHS] CSTR 122 on CHEM?
Message-ID: <201708171442.v7HEg7Su008572@freefriends.org>

Does anyone have this, even just in PostScript?

Thanks,

Arnold

P.S. Chem itself is at http://www.netlib.org/typesetting/chem.
--upas-hvlhfvqhpsezrrlxpfklpodbgt--


From beebe at math.utah.edu  Fri Aug 18 02:16:36 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 17 Aug 2017 10:16:36 -0600
Subject: [TUHS] [tuhs] new paper on Unix pipes
Message-ID: <CMM.0.95.0.1502986596.beebe@gamma.math.utah.edu>

This new paper was published today, and it is open access, so everyone should
have access:

	Diomidis Spinellis and Marios Fragkoulis
	Extending Unix Pipelines to DAGs
	IEEE Transactions on Computers 66(9) 1547--1561 September 2017
	http://dx.doi.org/10.1109/TC.2017.2695447

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From arnold at skeeve.com  Fri Aug 18 03:52:35 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 11:52:35 -0600
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
Message-ID: <201708171752.v7HHqZVm031375@freefriends.org>

"Steve Simon" <steve at quintile.net> wrote:

> http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz

Most excellent!  Thanks!


From arnold at skeeve.com  Fri Aug 18 03:58:08 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 11:58:08 -0600
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
Message-ID: <201708171758.v7HHw8Gi031951@freefriends.org>

"Steve Simon" <steve at quintile.net> wrote:

> http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz

OK, so how do I actually get the file?  I seem to not be able to figure
out how the Wayback machine works. :-(

Thanks,

Arnold


From arnold at skeeve.com  Fri Aug 18 04:22:58 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Aug 2017 12:22:58 -0600
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171758.v7HHw8Gi031951@freefriends.org>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
 <201708171758.v7HHw8Gi031951@freefriends.org>
Message-ID: <201708171822.v7HIMw2h002732@freefriends.org>

arnold at skeeve.com wrote:

> "Steve Simon" <steve at quintile.net> wrote:
>
> > http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz
>
> OK, so how do I actually get the file?  I seem to not be able to figure
> out how the Wayback machine works. :-(
>
> Thanks,
>
> Arnold

And to answer my own question:

1. Install the wayback machine downloader: https://github.com/hartator/wayback-machine-downloader

2. Download the whole directory with

	wayback_machine_downloader http://cm.bell-labs.com/cm/cs/cstr/

The results will be in websites/cm.bell-labs.com/cm/cs/cstr/ created
in the directory where you run the command.

Warren - can you do this for the archives?

Thanks!

Arnold


From michael at kjorling.se  Fri Aug 18 04:38:30 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Thu, 17 Aug 2017 18:38:30 +0000
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171758.v7HHw8Gi031951@freefriends.org>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
 <201708171758.v7HHw8Gi031951@freefriends.org>
Message-ID: <20170817183829.GD31148@5B3C9D53AD8F45DD93F7082AF345DC1A>

On 17 Aug 2017 11:58 -0600, from arnold at skeeve.com:
>> http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz
> 
> OK, so how do I actually get the file?  I seem to not be able to figure
> out how the Wayback machine works. :-(

Here's a quick way to get the _most recently archived_ version of a
URL from the Wayback Machine:

Take https://web.archive.org/web/99991232235959/

Append the URL of interest, including protocol.

That would be
https://web.archive.org/web/99991232235959/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz

Feed that to your web browser or other HTTP client.

It will redirect to the most recent version, which in this case
appears to be
https://web.archive.org/web/20070203045131/http://cm.bell-labs.com:80/cm/cs/cstr/122.ps.gz

Alternatively, you need Javascript enabled to see on which dates they
archived the URL in question (that'd be the '*' variant, except I
access the Wayback Machine over HTTPS), then hover over a colored date
to see the list of snapshots on that date, then click the time link to
go to that version of the URL.

They used to have until recently a UI that didn't require executing
client-side Javascript... I suppose that's called progress.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From krewat at kilonet.net  Fri Aug 18 04:48:34 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 17 Aug 2017 14:48:34 -0400
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171822.v7HIMw2h002732@freefriends.org>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
 <201708171758.v7HHw8Gi031951@freefriends.org>
 <201708171822.v7HIMw2h002732@freefriends.org>
Message-ID: <f632ab7a-1376-909b-a0d9-bc1d9a4753a6@kilonet.net>

Hover over one of highlighted (capture) dates on the calendar that comes 
up after following this link:

http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz

February 3rd for example. You'll see the time in the bubble. Click on 
the time. It'll start the download.



On 8/17/2017 2:22 PM, arnold at skeeve.com wrote:
> arnold at skeeve.com wrote:
>
>> "Steve Simon" <steve at quintile.net> wrote:
>>
>>> http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz
>> OK, so how do I actually get the file?  I seem to not be able to figure
>> out how the Wayback machine works. :-(
>>
>> Thanks,
>>
>> Arnold
> And to answer my own question:
>
> 1. Install the wayback machine downloader: https://github.com/hartator/wayback-machine-downloader
>
> 2. Download the whole directory with
>
> 	wayback_machine_downloader http://cm.bell-labs.com/cm/cs/cstr/
>
> The results will be in websites/cm.bell-labs.com/cm/cs/cstr/ created
> in the directory where you run the command.
>
> Warren - can you do this for the archives?
>
> Thanks!
>
> Arnold
>



From khm at sciops.net  Fri Aug 18 05:19:43 2017
From: khm at sciops.net (Kurt H Maier)
Date: Thu, 17 Aug 2017 12:19:43 -0700
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171822.v7HIMw2h002732@freefriends.org>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
 <201708171758.v7HHw8Gi031951@freefriends.org>
 <201708171822.v7HIMw2h002732@freefriends.org>
Message-ID: <20170817191943.GA78767@wopr>

Sorry I'm late with this, but this particular file is also available at 
https://9p.io/cm/cs/cstr/122.ps.gz

I'm unsure how complete 9p.io's mirror is, but it hasn't let me down
yet.

khm


From paul at mcjones.org  Fri Aug 18 08:19:49 2017
From: paul at mcjones.org (Paul McJones)
Date: Thu, 17 Aug 2017 15:19:49 -0700
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
In-Reply-To: <mailman.921.1502995544.3779.tuhs@minnie.tuhs.org>
References: <mailman.921.1502995544.3779.tuhs@minnie.tuhs.org>
Message-ID: <98A157E9-CE5C-49D1-9BF4-41D2CBB754A1@mcjones.org>

On Aug 17, 2017, arnold at skeeve.com wrote:

> I remember reading an article somewhere on the history of the first
> FORTRAN compiler.  The guys doing it wanted it to succeed, and they
> were fighting the mentality that high level languages could not possibly
> be as efficient as hand-coded assembly, so they put a lot of work into
> the optimization of the generated code.
> 
> It worked so well that the results that came out of the compiler
> sometimes suprised the compiler writers!  They then would have to
> dive into the compiler sources to figure out how it was done.
> 
> I don't remember where I read this article. If the story rings a
> bell with anyone, let me know.

In his paper "The history of FORTRAN I, II and III” presented at the First ACM SIGPLAN conference on History of Programming Languages (1978), John Backus said:

> It was an exciting period; when later on we began to get fragments of compiled programs out of the system, we were often astonished at the surprising transformations in the indexing operations and in the arrangement of the computation which the compiler made, changes which made the object program efficient but which we would not have thought to make as programmers ourselves (even though, of course, Nelson or Ziller could figure out how the indexing worked, Sheridan could explain how an expresssion had been optimized beyond recognition, and Goldberg or Sayre could tell us how section 5 had generated additional indexing operations). Transfers of control appeared which corresponded to no source statement, expressions were radically rearranged, and the same DO statement might produce no instructions in the object program in one context, and in another it would produce many instructions in different places in the program.

The paper is available here, courtesy of ACM: http://www.softwarepreservation.org/projects/FORTRAN/index.html .

From arnold at skeeve.com  Fri Aug 18 20:38:35 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 18 Aug 2017 04:38:35 -0600
Subject: [TUHS] CSTR 122 on CHEM?
In-Reply-To: <201708171822.v7HIMw2h002732@freefriends.org>
References: <77908e10000151ffdc0b77842d8c74ca@quintile.net>
 <201708171758.v7HHw8Gi031951@freefriends.org>
 <201708171822.v7HIMw2h002732@freefriends.org>
Message-ID: <201708181038.v7IAcZCP012110@freefriends.org>

Thanks to everyone who sent me copies and who sent instructions
and advince on how to use the Wayback machine.  I really appreciate
it.

Arnold

arnold at skeeve.com wrote:

> arnold at skeeve.com wrote:
>
> > "Steve Simon" <steve at quintile.net> wrote:
> >
> > > http://web.archive.org/web/*/http://cm.bell-labs.com/cm/cs/cstr/122.ps.gz
> >
> > OK, so how do I actually get the file?  I seem to not be able to figure
> > out how the Wayback machine works. :-(
> >
> > Thanks,
> >
> > Arnold
>
> And to answer my own question:
>
> 1. Install the wayback machine downloader: https://github.com/hartator/wayback-machine-downloader
>
> 2. Download the whole directory with
>
> 	wayback_machine_downloader http://cm.bell-labs.com/cm/cs/cstr/
>
> The results will be in websites/cm.bell-labs.com/cm/cs/cstr/ created
> in the directory where you run the command.
>
> Warren - can you do this for the archives?
>
> Thanks!
>
> Arnold


From arnold at skeeve.com  Fri Aug 18 20:49:13 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 18 Aug 2017 04:49:13 -0600
Subject: [TUHS] arithmetic IF (was origin of string.h and ctype.h)
In-Reply-To: <98A157E9-CE5C-49D1-9BF4-41D2CBB754A1@mcjones.org>
References: <mailman.921.1502995544.3779.tuhs@minnie.tuhs.org>
 <98A157E9-CE5C-49D1-9BF4-41D2CBB754A1@mcjones.org>
Message-ID: <201708181049.v7IAnDAa013478@freefriends.org>

That's it!  Much thanks!

Arnold

Paul McJones <paul at mcjones.org> wrote:

> On Aug 17, 2017, arnold at skeeve.com wrote:
>
> > I remember reading an article somewhere on the history of the first
> > FORTRAN compiler.  The guys doing it wanted it to succeed, and they
> > were fighting the mentality that high level languages could not possibly
> > be as efficient as hand-coded assembly, so they put a lot of work into
> > the optimization of the generated code.
> > 
> > It worked so well that the results that came out of the compiler
> > sometimes suprised the compiler writers!  They then would have to
> > dive into the compiler sources to figure out how it was done.
> > 
> > I don't remember where I read this article. If the story rings a
> > bell with anyone, let me know.
>
> In his paper "The history of FORTRAN I, II and III??? presented at the
> First ACM SIGPLAN conference on History of Programming Languages (1978),
> John Backus said:
> 
> > It was an exciting period; when later on we began to get fragments
> > of compiled programs out of the system, we were often astonished at
> > the surprising transformations in the indexing operations and in the
> > arrangement of the computation which the compiler made, changes which
> > made the object program efficient but which we would not have thought
> > to make as programmers ourselves (even though, of course, Nelson or
> > Ziller could figure out how the indexing worked, Sheridan could explain
> > how an expresssion had been optimized beyond recognition, and Goldberg
> > or Sayre could tell us how section 5 had generated additional indexing
> > operations). Transfers of control appeared which corresponded to no
> > source statement, expressions were radically rearranged, and the same
> > DO statement might produce no instructions in the object program in one
> > context, and in another it would produce many instructions in different
> > places in the program.
>
> The paper is available here, courtesy of ACM:
> http://www.softwarepreservation.org/projects/FORTRAN/index.html .


From arnold at skeeve.com  Fri Aug 25 21:01:39 2017
From: arnold at skeeve.com (Aharon Robbins)
Date: Fri, 25 Aug 2017 14:01:39 +0300
Subject: [TUHS] CSTR files
Message-ID: <201708251101.v7PB1eo8024529@skeeve.com>

Hi All.

I have made a tarball of all the Bell Labs CSTRs that I could
file:  http://www.skeeve.com/cstr.tar.gz.

It's just under ten megs.  Warren, can we get this into the archives?

Thanks,

Arnold


From wkt at tuhs.org  Fri Aug 25 21:30:16 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 25 Aug 2017 21:30:16 +1000
Subject: [TUHS] CSTR files
In-Reply-To: <201708251101.v7PB1eo8024529@skeeve.com>
References: <201708251101.v7PB1eo8024529@skeeve.com>
Message-ID: <83A4929B-B520-4F9E-9A7C-E51C2F4E89C0@tuhs.org>

Yes. On the road at present. Will grab it when I get back.
Cheers, Warren

On 25 August 2017 9:01:39 pm AEST, Aharon Robbins <arnold at skeeve.com> wrote:
>Hi All.
>
>I have made a tarball of all the Bell Labs CSTRs that I could
>file:  http://www.skeeve.com/cstr.tar.gz.
>
>It's just under ten megs.  Warren, can we get this into the archives?
>
>Thanks,
>
>Arnold

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170825/5bc6571a/attachment.html>

From arnold at skeeve.com  Fri Aug 25 22:32:10 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 25 Aug 2017 06:32:10 -0600
Subject: [TUHS] CSTR files
In-Reply-To: <83A4929B-B520-4F9E-9A7C-E51C2F4E89C0@tuhs.org>
References: <201708251101.v7PB1eo8024529@skeeve.com>
 <83A4929B-B520-4F9E-9A7C-E51C2F4E89C0@tuhs.org>
Message-ID: <201708251232.v7PCWA0C015036@freefriends.org>

Most excellent. Much thanks!

Arnold

Warren Toomey <wkt at tuhs.org> wrote:

> Yes. On the road at present. Will grab it when I get back.
> Cheers, Warren
>
> On 25 August 2017 9:01:39 pm AEST, Aharon Robbins <arnold at skeeve.com> wrote:
> >Hi All.
> >
> >I have made a tarball of all the Bell Labs CSTRs that I could
> >file:  http://www.skeeve.com/cstr.tar.gz.
> >
> >It's just under ten megs.  Warren, can we get this into the archives?
> >
> >Thanks,
> >
> >Arnold
>
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.



From lm at mcvoy.com  Sat Aug 26 00:04:43 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 25 Aug 2017 07:04:43 -0700
Subject: [TUHS] CSTR files
In-Reply-To: <201708251101.v7PB1eo8024529@skeeve.com>
References: <201708251101.v7PB1eo8024529@skeeve.com>
Message-ID: <20170825140443.GB24995@mcvoy.com>

As a *roff fan, I'd love, love, love to see the original roff sources.
Especially anything that uses pic/eqn/chem/etc.

Any chance of that?

On Fri, Aug 25, 2017 at 02:01:39PM +0300, Aharon Robbins wrote:
> Hi All.
> 
> I have made a tarball of all the Bell Labs CSTRs that I could
> file:  http://www.skeeve.com/cstr.tar.gz.
> 
> It's just under ten megs.  Warren, can we get this into the archives?
> 
> Thanks,
> 
> Arnold

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


From torek at torek.net  Sat Aug 26 04:27:44 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 25 Aug 2017 11:27:44 -0700
Subject: [TUHS] CSTR files
In-Reply-To: Your message of "Fri, 25 Aug 2017 07:04:43 -0700."
 <20170825140443.GB24995@mcvoy.com>
Message-ID: <201708251827.v7PIRiRZ079233@elf.torek.net>

Slight digression:

>As a *roff fan, I'd love, love, love to see the original roff sources.

The *original* original (Unix) roff (not sure if there was
a precursor elsewhere) was in pdp-11 assembly.

It was hand-translated to assembly-like C somewhere back
in the v6-ish time frame, certainly soon enough to become
nroff and troff in Phototypesetter V6.

(It wasn't until Kernighan rewrote it that it became sort
of reasonable, but that was much later.  I vaguely recall
trying to fix something in the nroff or troff source in
4.xBSD-on-the-VAX, and wow, that code was awful, on the same
scale as the original vi perhaps.)

>Especially anything that uses pic/eqn/chem/etc.

I remember using tbl and eqn on the 4.xBSD VAX.  (We did not have
pic at that time.)  Then we got TeX and I did everything new in
TeX if possible, but I did actually miss tbl: while its
*formatting* was not so great, it was a much better *markup*
language than original or later LaTeX table constructs.

Chris


From johnl at johnlabovitz.com  Sat Aug 26 06:27:04 2017
From: johnl at johnlabovitz.com (John Labovitz)
Date: Fri, 25 Aug 2017 16:27:04 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <201708251827.v7PIRiRZ079233@elf.torek.net>
References: <201708251827.v7PIRiRZ079233@elf.torek.net>
Message-ID: <31E4B337-C3D7-4B80-AB7F-23EAD058630F@johnlabovitz.com>

On Aug 25, 2017, at 2:27 PM, Chris Torek <torek at torek.net> wrote:

>> As a *roff fan, I'd love, love, love to see the original roff sources.
> 
> The *original* original (Unix) roff (not sure if there was
> a precursor elsewhere) was in pdp-11 assembly.

Last fall, I wrote an article for the American Printing History Association called 'The Electric Typesetter: The Origins of Computing in Typography.’ In doing research, I found the earliest succession of roff predecessors went something like this:

	TJ-2 -> RUNOFF (capitals) -> runoff (lowercase) -> rf -> roff

TJ-2 is described at <http://www.dpbsmith.com/tj2.html>. I don’t have info on the other processors at hand at the moment.

Folks here might be interested in my article, but sadly the journal doesn’t tend to put their content online for quite a while. The TOC for the issue is at <https://printinghistory.org/publications/printing-history/ns/#21>.

—John



From krewat at kilonet.net  Sat Aug 26 07:04:22 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 25 Aug 2017 17:04:22 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <31E4B337-C3D7-4B80-AB7F-23EAD058630F@johnlabovitz.com>
References: <201708251827.v7PIRiRZ079233@elf.torek.net>
 <31E4B337-C3D7-4B80-AB7F-23EAD058630F@johnlabovitz.com>
Message-ID: <4c984c35-0368-5d87-d86e-42cb88785899@kilonet.net>

On 8/25/2017 4:27 PM, John Labovitz wrote:
> TJ-2 -> RUNOFF (capitals) -> runoff (lowercase) -> rf -> roff
That's not RUNOFF on TOPS-10 (or one it's predecessors) is it?

For example, from the TOPS-10 Kermit source, k10133.rno:

.AP.SP 2
.PS 60,70
  Kermit-10 now has a lot of patches put into it.  The first set of
patches is based on those submitted by PIMA.  The subsequent patches are
added in order to make Kermit-10 similar to Kermit-32.  The last patch is
to change all the search file names to K10??? as opposed to KER???.
.B 2
.HL 1;PATCH [127]
  Based on the patches we received from PIMA the following changes have
been added to KERMIT and KERUNV.
.B.LS
.LE;Fix IFN stopcode if syntax error in KERMIT.INI.
.LE;Add help text for connect mode ESCape commands.
Q (Quit) and R (Resume) logging


From imp at bsdimp.com  Sat Aug 26 07:16:07 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 25 Aug 2017 15:16:07 -0600
Subject: [TUHS] CSTR files
In-Reply-To: <4c984c35-0368-5d87-d86e-42cb88785899@kilonet.net>
References: <201708251827.v7PIRiRZ079233@elf.torek.net>
 <31E4B337-C3D7-4B80-AB7F-23EAD058630F@johnlabovitz.com>
 <4c984c35-0368-5d87-d86e-42cb88785899@kilonet.net>
Message-ID: <CANCZdfrYoKtVj3o55uJGYeT7jWLRSyCt62GE6PJY9g1k3RVK-Q@mail.gmail.com>

On Fri, Aug 25, 2017 at 3:04 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> On 8/25/2017 4:27 PM, John Labovitz wrote:
>
>> TJ-2 -> RUNOFF (capitals) -> runoff (lowercase) -> rf -> roff
>>
> That's not RUNOFF on TOPS-10 (or one it's predecessors) is it?
>

They are all interrelated. I've seen a number of family trees over the
years, but couldn't find one via google just now.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170825/d47e2ebd/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Aug 26 06:59:46 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 25 Aug 2017 16:59:46 -0400 (EDT)
Subject: [TUHS] CSTR files
Message-ID: <20170825205946.3B04B18C0A9@mercury.lcs.mit.edu>

    > From: John Labovitz

    > I found the earliest succession of roff predecessors went something like this:
    > 	TJ-2 -> RUNOFF (capitals) -> runoff (lowercase) -> rf -> roff

Did you manage to find out from Jerry if he knew of/anything about TJ2 when he did
RUNOFF?

	Noel


From johnl at johnlabovitz.com  Sat Aug 26 07:33:42 2017
From: johnl at johnlabovitz.com (John Labovitz)
Date: Fri, 25 Aug 2017 17:33:42 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <20170825205946.3B04B18C0A9@mercury.lcs.mit.edu>
References: <20170825205946.3B04B18C0A9@mercury.lcs.mit.edu>
Message-ID: <F28AB948-3746-42AD-9E02-F5E15D068D33@johnlabovitz.com>

On Aug 25, 2017, at 4:59 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: John Labovitz
> 
>> I found the earliest succession of roff predecessors went something like this:
>> 	TJ-2 -> RUNOFF (capitals) -> runoff (lowercase) -> rf -> roff
> 
> Did you manage to find out from Jerry if he knew of/anything about TJ2 when he did
> RUNOFF?

I did not. I was on a pretty tight deadline when I was writing the article, and didn’t have time to explore. I would love to do so some day, though. I’m particularly interested in the evolution of markup systems, and as far as I can tell, not much has been recorded for posterity.

—John



From jnc at mercury.lcs.mit.edu  Sat Aug 26 07:47:23 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 25 Aug 2017 17:47:23 -0400 (EDT)
Subject: [TUHS] CSTR files
Message-ID: <20170825214723.4485218C0A9@mercury.lcs.mit.edu>

    > From: Arthur Krewat

    > That's not RUNOFF on TOPS-10 (or one it's predecessors) is it?

No, RUNOFF on CTSS - _much_ earlier - CTSS RUNOFF was in '64, which was
the year the PDP-6 came out.

	Noel


From mutiny.mutiny at rediffmail.com  Sat Aug 26 19:48:23 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 26 Aug 2017 09:48:23 -0000
Subject: [TUHS] =?utf-8?q?CSTR_files?=
In-Reply-To: <CANCZdfrYoKtVj3o55uJGYeT7jWLRSyCt62GE6PJY9g1k3RVK-Q@mail.gmail.com>
Message-ID: <1503695788.S.6551.10501.f4-234-164.1503740903.13140@webmail.rediffmail.com>

&#39;From: Warner Losh &lt;imp at bsdimp.com&gt;
&nbsp;They are all interrelated. I&#39;ve seen a number of family trees over the years, but couldn&#39;t find one via google just now.&#39;
&nbsp;
Check out: https://manpages.bsd.lv/history.htmlhttps://manpages.bsd.lv/history.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170826/b533433a/attachment.html>

From arnold at skeeve.com  Mon Aug 28 01:11:53 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 27 Aug 2017 09:11:53 -0600
Subject: [TUHS] CSTR files
In-Reply-To: <20170825140443.GB24995@mcvoy.com>
References: <201708251101.v7PB1eo8024529@skeeve.com>
 <20170825140443.GB24995@mcvoy.com>
Message-ID: <201708271511.v7RFBrZl004265@freefriends.org>

The original sources for troff are around, look at the Heirloom Unix
project.

I assume that you meant the sources for the CSTRs themselves. BWK
donated the sources for the troff tutorial and troff manual and I sent
them to Warren some time ago.  The original Bell Labs guys would have
to indicate if they have sources for any of the others.

Undoubtedly some of them could be reconstituted via OCR, but that's
a serious project. (Worth doing, IMHO, but still a serious project; I
don't have the cycles for anything like that...)

Arnold

Larry McVoy <lm at mcvoy.com> wrote:

> As a *roff fan, I'd love, love, love to see the original roff sources.
> Especially anything that uses pic/eqn/chem/etc.
>
> Any chance of that?
>
> On Fri, Aug 25, 2017 at 02:01:39PM +0300, Aharon Robbins wrote:
> > Hi All.
> > 
> > I have made a tarball of all the Bell Labs CSTRs that I could
> > file:  http://www.skeeve.com/cstr.tar.gz.
> > 
> > It's just under ten megs.  Warren, can we get this into the archives?
> > 
> > Thanks,
> > 
> > Arnold
>
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From steve at quintile.net  Mon Aug 28 01:48:31 2017
From: steve at quintile.net (Steve Simon)
Date: Sun, 27 Aug 2017 16:48:31 +0100
Subject: [TUHS] CSTR files
In-Reply-To: <201708271511.v7RFBrZl004265@freefriends.org>
References: <201708251101.v7PB1eo8024529@skeeve.com>
 <20170825140443.GB24995@mcvoy.com>
 <201708271511.v7RFBrZl004265@freefriends.org>
Message-ID: <1A738AAA-2260-4334-ACC0-E36241252C24@quintile.net>

Hi,

i do have a tool for plan9 which attempts to convert html to troff source. this is not the standard plan9 tool but something of my own creation.

at one time some (maybe all) the cstr papers where available as html. if anyone can find copies in html i could try and reverse them.

fyi i even had a go at rfc2ms which works fairly well for some rfcs, it tries to generate a more troff-like doc than 66 lines per page, block caps for emphasis style used in rfcs. it works well for some docs but like many projects, is unfinished.

troff addicts are welcome to the code for both, but beware, the plan9ports toolkit will be needed for [lu]nix.


-Steve


> On 27 Aug 2017, at 16:11, arnold at skeeve.com wrote:
> 
> The original sources for troff are around, look at the Heirloom Unix
> project.
> 
> I assume that you meant the sources for the CSTRs themselves. BWK
> donated the sources for the troff tutorial and troff manual and I sent
> them to Warren some time ago.  The original Bell Labs guys would have
> to indicate if they have sources for any of the others.
> 
> Undoubtedly some of them could be reconstituted via OCR, but that's
> a serious project. (Worth doing, IMHO, but still a serious project; I
> don't have the cycles for anything like that...)
> 
> Arnold
> 
> Larry McVoy <lm at mcvoy.com> wrote:
> 
>> As a *roff fan, I'd love, love, love to see the original roff sources.
>> Especially anything that uses pic/eqn/chem/etc.
>> 
>> Any chance of that?
>> 
>>> On Fri, Aug 25, 2017 at 02:01:39PM +0300, Aharon Robbins wrote:
>>> Hi All.
>>> 
>>> I have made a tarball of all the Bell Labs CSTRs that I could
>>> file:  http://www.skeeve.com/cstr.tar.gz.
>>> 
>>> It's just under ten megs.  Warren, can we get this into the archives?
>>> 
>>> Thanks,
>>> 
>>> Arnold
>> 
>> -- 
>> ---
>> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 



From ches at cheswick.com  Mon Aug 28 07:03:37 2017
From: ches at cheswick.com (William Cheswick)
Date: Sun, 27 Aug 2017 17:03:37 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <1A738AAA-2260-4334-ACC0-E36241252C24@quintile.net>
References: <201708251101.v7PB1eo8024529@skeeve.com>
 <20170825140443.GB24995@mcvoy.com>
 <201708271511.v7RFBrZl004265@freefriends.org>
 <1A738AAA-2260-4334-ACC0-E36241252C24@quintile.net>
Message-ID: <ECAECBE9-7344-4CA6-9154-08F48A64F42A@cheswick.com>

CSTR 145 is mine, if any one cares.  LaTeX, as appropriate for

A Permuted Index for TeX and LaTeX.

I found Lorinda’s permuted index of Unix commands to be an import part of learning which Unix filters were available.

ches



From doug at cs.dartmouth.edu  Mon Aug 28 13:04:18 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 27 Aug 2017 23:04:18 -0400
Subject: [TUHS] CSTR files
Message-ID: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>

> As a *roff fan, I'd love, love, love to see the original roff sources.
> Especially anything that uses pic/eqn/chem/etc.

I have the source for CSTR 155, a trilogy on raster ellipses. It uses
interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
(If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
doesn't have it.)

Doug


From noel.hunt at gmail.com  Mon Aug 28 14:00:26 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Mon, 28 Aug 2017 14:00:26 +1000
Subject: [TUHS] CSTR files
In-Reply-To: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
References: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAGfO01w8tChp-SemrZvjNiCPb+LAFspYcb8qiethbu53Xq5H4w@mail.gmail.com>

> interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
> (If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
> doesn't have it.)

Is the source for ideal, command, manual and the document which
appears in the Tenth Edition Manual, all of which are in the
source that was recently released, not what you are after?

On Mon, Aug 28, 2017 at 1:04 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > As a *roff fan, I'd love, love, love to see the original roff sources.
> > Especially anything that uses pic/eqn/chem/etc.
>
> I have the source for CSTR 155, a trilogy on raster ellipses. It uses
> interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
> (If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
> doesn't have it.)
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170828/75a2c268/attachment.html>

From arnold at skeeve.com  Mon Aug 28 14:16:48 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 27 Aug 2017 22:16:48 -0600
Subject: [TUHS] CSTR files
In-Reply-To: <CAGfO01w8tChp-SemrZvjNiCPb+LAFspYcb8qiethbu53Xq5H4w@mail.gmail.com>
References: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
 <CAGfO01w8tChp-SemrZvjNiCPb+LAFspYcb8qiethbu53Xq5H4w@mail.gmail.com>
Message-ID: <201708280416.v7S4GmfV009367@freefriends.org>

Looks like 'prefer' is in there too. :-)

Noel Hunt <noel.hunt at gmail.com> wrote:

> > interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
> > (If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
> > doesn't have it.)
>
> Is the source for ideal, command, manual and the document which
> appears in the Tenth Edition Manual, all of which are in the
> source that was recently released, not what you are after?
>
> On Mon, Aug 28, 2017 at 1:04 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> > > As a *roff fan, I'd love, love, love to see the original roff sources.
> > > Especially anything that uses pic/eqn/chem/etc.
> >
> > I have the source for CSTR 155, a trilogy on raster ellipses. It uses
> > interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
> > (If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
> > doesn't have it.)
> >
> > Doug
> >


From toby at telegraphics.com.au  Mon Aug 28 14:10:22 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 28 Aug 2017 00:10:22 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
References: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
Message-ID: <939ecf98-144f-0942-9656-93f4ffd8893b@telegraphics.com.au>

On 2017-08-27 11:04 PM, Doug McIlroy wrote:
>> As a *roff fan, I'd love, love, love to see the original roff sources.
>> Especially anything that uses pic/eqn/chem/etc.
> 
> I have the source for CSTR 155, a trilogy on raster ellipses. It uses
> interesting preprocessors that are, alas, mostly lost: ideal, prefer, eqn.
> (If anybody has ideal, I'd love to get it. Even its author, Chris Van Wyk,
> doesn't have it.)

<aside> When people wonder why digital archiving and preservation is so
incredibly hard -- situations like this perfectly illustrate why. </aside>

More on topic though: I'm a typographer with an interest in markup
languages, since I used them commercially in the 1980s (mostly TeX, but
with a large personal macro library, hence invoking the problem above,
if the source documents had even been archived, which they were not --
an even more basic problem).

I'm interested in reading John Labovitz' history, for sure.

--Toby


> 
> Doug
> 



From noel.hunt at gmail.com  Mon Aug 28 14:51:08 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Mon, 28 Aug 2017 14:51:08 +1000
Subject: [TUHS] Ideal
Message-ID: <CAGfO01yH_oDcWq-BwwHN+F=Ki8Lezu9oOoqiDKbspZZ=PDfriQ@mail.gmail.com>

Doug McIlroy's mentioning `ideal' prompts me to ask something
I've long wanted to ask. The only use I ever saw of ideal was
in Peter Weinberger's memo about his C B-tree package. Was ideal
used for anything other than that?

Noel Hunt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170828/e50b4da7/attachment.html>

From johnl at johnlabovitz.com  Mon Aug 28 22:47:28 2017
From: johnl at johnlabovitz.com (John Labovitz)
Date: Mon, 28 Aug 2017 08:47:28 -0400
Subject: [TUHS] CSTR files
In-Reply-To: <939ecf98-144f-0942-9656-93f4ffd8893b@telegraphics.com.au>
References: <201708280304.v7S34IVU099406@tahoe.cs.Dartmouth.EDU>
 <939ecf98-144f-0942-9656-93f4ffd8893b@telegraphics.com.au>
Message-ID: <1B3DD143-0DBD-4CCC-9B15-3417B6979595@johnlabovitz.com>


On Aug 28, 2017, at 12:10 AM, Toby Thain <toby at telegraphics.com.au> wrote:

> More on topic though: I'm a typographer with an interest in markup
> languages, since I used them commercially in the 1980s (mostly TeX, but
> with a large personal macro library, hence invoking the problem above,
> if the source documents had even been archived, which they were not --
> an even more basic problem).
> 
> I'm interested in reading John Labovitz' history, for sure.

Glad to hear it.

I’ve put in a request to the editor of _Printing History,_ asking permission to obtain my article as a PDF, or at worst, something I can format and make available to the list. I’ll let folks know once this happens.

—John



From arnold at skeeve.com  Tue Aug 29 23:07:13 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 29 Aug 2017 07:07:13 -0600
Subject: [TUHS] Bell Labs history question
Message-ID: <201708291307.v7TD7D2K013036@freefriends.org>

Hi.

For a project I'm working on, I wonder if the Bell Labs alumni present
can tell me what was the default group for files for the researchers?
That is, what group did ls -l show?

In particular, in the late 90s - ~ V10 time frame.

Much thanks,

Arnold


From ches at cheswick.com  Wed Aug 30 00:13:21 2017
From: ches at cheswick.com (William Cheswick)
Date: Tue, 29 Aug 2017 10:13:21 -0400
Subject: [TUHS] Bell Labs history question
In-Reply-To: <201708291307.v7TD7D2K013036@freefriends.org>
References: <201708291307.v7TD7D2K013036@freefriends.org>
Message-ID: <833F5F46-9C8F-4A0C-9EB9-26127CCB31A9@cheswick.com>

— coma

I happen to have a tar file from coma, one of the main V10 machines I used.  
A sample file has

UID	115
GID	20

The tar file is dated April 29 1997

The UID was doubtless “ches”.  

— research
I have another file from Oct 14, 1992, named ypsnarf.c,
UID=2009, GUD-2009

This file is probably from research (as in research!ches) and was a MIPS not running V10.
This was probably ches,ches and not helpful.

— bowell

bowell was the master source machine for V10.  A file (proxy.c, Mar  3  1993) I had tarred up from there has
UID:	1696
GID:	4


ches


> On 29Aug 2017, at 9:07 AM, arnold at skeeve.com wrote:
> 
> Hi.
> 
> For a project I'm working on, I wonder if the Bell Labs alumni present
> can tell me what was the default group for files for the researchers?
> That is, what group did ls -l show?
> 
> In particular, in the late 90s - ~ V10 time frame.
> 
> Much thanks,
> 
> Arnold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170829/515ca1c3/attachment.html>

From arnold at skeeve.com  Wed Aug 30 00:29:44 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 29 Aug 2017 08:29:44 -0600
Subject: [TUHS] Bell Labs history question
In-Reply-To: <833F5F46-9C8F-4A0C-9EB9-26127CCB31A9@cheswick.com>
References: <201708291307.v7TD7D2K013036@freefriends.org>
 <833F5F46-9C8F-4A0C-9EB9-26127CCB31A9@cheswick.com>
Message-ID: <201708291429.v7TETi5e022814@freefriends.org>

Thanks!

Any idea what the group names would have been?

Arnold

William Cheswick <ches at cheswick.com> wrote:

> — coma
>
> I happen to have a tar file from coma, one of the main V10 machines I used.  
> A sample file has
>
> UID	115
> GID	20
>
> The tar file is dated April 29 1997
>
> The UID was doubtless “ches”.  
>
> — research
> I have another file from Oct 14, 1992, named ypsnarf.c,
> UID=2009, GUD-2009
>
> This file is probably from research (as in research!ches) and was a MIPS not running V10.
> This was probably ches,ches and not helpful.
>
> — bowell
>
> bowell was the master source machine for V10.  A file (proxy.c, Mar  3  1993) I had tarred up from there has
> UID:	1696
> GID:	4
>
>
> ches
>
>
> > On 29Aug 2017, at 9:07 AM, arnold at skeeve.com wrote:
> > 
> > Hi.
> > 
> > For a project I'm working on, I wonder if the Bell Labs alumni present
> > can tell me what was the default group for files for the researchers?
> > That is, what group did ls -l show?
> > 
> > In particular, in the late 90s - ~ V10 time frame.
> > 
> > Much thanks,
> > 
> > Arnold
>


From arnold at skeeve.com  Wed Aug 30 22:34:54 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 30 Aug 2017 06:34:54 -0600
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
Message-ID: <201708301234.v7UCYsPQ002608@freefriends.org>

	Seek and ye shall find.

	Ask and ye shall receive.

Brian Kernighan was kind enough to find for me everyone's favorite
Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
My Favorite Programming Language".

Attached is the file and his macros.  This will not immediately
format using groff etc.; I hope to create a version that will, sometime
in the next few weeks.

In the meantime, Warren, please add to the archives when you are able.

Enjoy!

Arnold
-------------- next part --------------
.fp 1 PA
.fp 2 PI
.fp 3 PB
.ds pf CW
.so /usr/bwk/src/cprog.mac
.if n .ls 2
....ND "April 2, 1981"
....TM 81-11272-12 11173 39199-11
.TR 100
.TL
Why Pascal is Not My Favorite Programming Language
.AU "MH 2C-518" 6021
Brian W. Kernighan
.AI
.MH
.AB
.PP
The programming language Pascal has become the dominant language
of instruction in computer science education.
It has also strongly influenced languages developed subsequently,
in particular Ada.
.PP
Pascal was originally intended primarily as a teaching language,
but it has been more and more often recommended as a language
for serious programming as well,
for example, for system programming tasks and even operating systems.
.PP
Pascal, at least in its standard form, is just plain not suitable for serious programming.
This paper discusses my personal discovery of some of the reasons why.
.AE
.CS 1 0 1 0 0  18
.NH
Genesis
.PP
This paper has its origins in two events \(em
a spate of papers that compare C and Pascal
.[
%T A Comparison of the Programming Languages C and Pascal \(em Part I: Language Concepts
%A Feuer, A. R.
%A N. H. Gehani
%D September 1979
%R Bell Labs internal memorandum
.]
.[
%T A Comparison of the Programming Languages C and Pascal \(em Part II: Program Properties and Programming Domains
%A N. H. Gehani
%A A. R. Feuer
%D February 1980
%R Bell Labs internal memorandum
.]
.[
%T Pascal versus C: A Subjective Comparison
%A P. Mateti
%J Language Design and Programming Methodology Symposium
%O Sydney, Australia
%D September 1979
%I Springer-Verlag
.]
.[
%T A Comparison of Language C and Pascal
%A A. Springer
%R IBM Technical Report G320-2128, Cambridge Scientific Center
%D August 1979
.]
and a personal attempt to rewrite
.ul
Software Tools
.[
kernighan plauger software tools addison
.]
in Pascal.
.PP
Comparing C and Pascal is rather like comparing
a Learjet to a Piper Cub \(em one is meant for getting something done while
the other is meant for learning \(em
so such comparisons tend to be somewhat farfetched.
But the revision of
.ul
Software Tools
seems a more relevant comparison.
The programs therein were originally written
in Ratfor,
a ``structured'' dialect of Fortran implemented by a preprocessor.
Since Ratfor is really Fortran in disguise, it has few of the
assets that Pascal brings \(em
data types more suited to character processing,
data structuring capabilities for better defining
the organization of one's data,
and strong typing to enforce telling the truth
about the data.
.PP
It turned out to be harder than I had expected
to rewrite the programs in Pascal.
This paper is an attempt to distill out of the experience
some lessons about Pascal's suitability for
programming (as distinguished from learning about programming).
It is
.ul
not
a comparison of Pascal with C or Ratfor.
.PP
The programs were first written in that dialect
of Pascal supported by the Pascal interpreter
.ul
pi
provided by the University of California at Berkeley.
The language is close to the nominal standard
of Jensen and Wirth,
.[
jensen wirth pascal report 1978
%O (2nd edition.)
.]
with good diagnostics and careful run-time checking.
Since then, the programs have also been run, unchanged
except for new libraries of primitives, on four other systems:
an interpreter
from the Free University of Amsterdam
(hereinafter referred to as VU, for Vrije Universiteit),
a VAX version of the Berkeley system (a true compiler),
a compiler purveyed by Whitesmiths, Ltd.,
and UCSD Pascal on a Z80.
All but the last of these Pascal systems are written in C.
.PP
Pascal is a much-discussed language.
A recent bibliography
.[
%A David V. Moffat
%T A Categorized Pascal Bibliography
%J SIGPLAN Notices
%V 15
%N 10
%P 63-75
%D October 1980
.]
lists 175 items under the heading of
``discussion, analysis and debate.''
The most often cited papers (well worth reading) are
a strong critique by Habermann
.[
habermann pascal critical
.]
and an equally strong rejoinder by
Lecarme and Desjardins.
.[
%A O. Lecarme
%A P. Desjardins
%T More Comments on the Programming Language Pascal
%J Acta Informatica
%V 4
%P 231-243
%D 1975
.]
The paper by Boom and DeJong
.[
%T A Critical Comparison of Several Programming Language Implementations
%A H. J. Boom
%A E. DeJong
%J Software Practice and Experience
%V 10
%N 6
%D June 1980
%P 435-473
.]
is also good reading.
Wirth's own assessment of Pascal is found in
.[ [
%T An Assessment of the Programming Language Pascal
%A N. Wirth
%J IEEE Transactions on Software Engineering
%V SE-1
%N 2
%D June, 1975
%P 192-198
.]].
I have no desire or ability to summarize the literature;
this paper represents my personal observations
and most of it necessarily duplicates points made by others.
I have tried to organize the rest of the material
around the issues of
.DS
types and scope
control flow
environment
cosmetics
.DE
and within each area more or less in decreasing order
of significance.
.PP
To state my conclusions at the outset:
Pascal may be an admirable language for teaching beginners
how to program; I have no first-hand experience with that.
It was a considerable achievement for 1968.
It has certainly influenced the design of recent languages,
of which Ada is likely to be the most important.
But in its standard form (both current and proposed),
Pascal is not adequate for writing real programs.
It is suitable only for small, self-contained programs
that have only trivial interactions with their environment
and that make no use of any software written by anyone else.
.NH
Types and Scopes
.PP
Pascal is (almost) a strongly typed language.
Roughly speaking, that means that each object
in a program has a well-defined type which implicitly
defines the legal values of and operations on the object.
The language guarantees that it will prohibit illegal values and operations,
by some mixture of compile- and run-time checking.
Of course compilers may not actually do all the checking implied in
the language definition.
Furthermore, strong typing is
.ul
not
to be confused with dimensional analysis.
If one defines 
types
.UL apple
and
.UL orange
with
.P1
type
	apple = integer;
	orange = integer;
.P2
then any arbitrary arithmetic expression involving
.UL apples
and
.UL oranges 
is perfectly legal.
.PP
Strong typing shows up in a variety of ways.
For instance, arguments to functions and procedures are checked
for proper type matching.
Gone is the Fortran freedom to
pass a floating point number into a subroutine that expects an integer;
this I deem a desirable attribute of Pascal,
since it warns of a construction that will certainly cause an error.
.PP
Integer variables may be declared to have an associated range
of legal values, and the compiler and run-time support
ensure that one does not put large integers
into variables that only hold small ones.
This too seems like a service,
although of course run-time checking does exact a penalty.
.PP
Let us move on to 
some problems of type and scope.
.NH 2
The size of an array is part of its type
.PP
If one declares
.P1
var	arr10 : array [1..10] of integer;
	arr20 : array [1..20] of integer;
.P2
then
.UL arr10
and
.UL arr20
are arrays of 10 and 20 integers respectively.
Suppose we want to write a procedure
.UL sort
to sort an integer array.
Because
.UL arr10
and
.UL arr20
have different types,
it is not possible to write a single procedure
that will sort them both.
.PP
The place where this affects
.ul
Software Tools
particularly, and I think programs in general,
is that it makes it difficult indeed
to create a library of routines for doing common, general-purpose operations
like sorting.
.PP
The particular data type most often affected is
.UL array
.UL of
.UL char ,
for in Pascal a string is an array of characters.
Consider writing a function
.UL index(s,c)
that will return the position in the string
.UL s
where the character
.UL c
first occurs, or zero if it does not.
The problem is how to handle the string argument of
.UL index .
The calls
.UL index('hello',c)
and
.UL index('goodbye',c)
cannot both be legal,
since the strings have different lengths.
(I pass over the question of how the end of a constant string
like
.UL 'hello'
can be detected, because it can't.)
.PP
The next try is
.P1
var temp : array [1..10] of char;

temp := 'hello';

n := index(temp,c);
.P2
but the assignment to
.UL temp
is illegal because
.UL \&'hello'
and
.UL temp
are of different lengths.
.PP
The only escape from this infinite regress
is to define a family of routines
with a member for each possible string size,
or to make all strings
(including constant strings like
.UL 'define' )
of the same length.
.PP
The latter approach is the lesser of two great evils.
In
.IT Tools ,
a type called
.UL string
is declared as
.P1
type string = array [1..MAXSTR] of char;
.P2
where
the constant
.UL MAXSTR
is ``big enough,''
and
all strings in all programs are exactly this size.
This is far from ideal,
although it made it possible to get the programs running.
It does
.ul
not
solve the problem of creating true libraries of useful routines.
.PP
There are some situations where it is simply not acceptable
to use the fixed-size array representation.
For example, the
.ul
Tools
program to sort lines of text
operates by fill\%ing up memory with as many lines as will fit;
its running time depends strongly on how full the memory can be packed.
Thus for
.UL sort ,
another representation is used,
a long array of characters and a set of indices into this array:
.P1
type	charbuf = array [1..MAXBUF] of char;
	charindex = array [1..MAXINDEX] of 0..MAXBUF;
.P2
But
the procedures and
functions written to process the fixed-length representation
cannot be used with the variable-length form;
an entirely new set of routines is needed to
copy and compare strings in this representation.
In Fortran or C the same functions could be used for both.
.PP
As suggested above, a constant string is written as
.P1
\&'this is a string'
.P2
and has the type
.UL packed
.UL array
.UL [1..n]
.UL of
.UL char ,
where
.UL n
is the length.
Thus each string literal of different length has a different type.
The only way to write a routine that will print a message and clean up
is to pad all messages out to the same maximum length:
.P1
error('short message                    ');
error('this is a somewhat longer message');
.P2
.PP
Many commercial Pascal compilers provide a
.UL string
data type that explicitly avoids the problem;
.UL string 's
are all taken to be the same type regardless of size.
This solves the problem for this single data type,
but no other.
It also fails to solve secondary problems
like computing the length of a constant string;
another built-in function is the usual solution.
.PP
Pascal enthusiasts
often claim that
to cope with the array-size problem
one merely has to copy some library routine
and fill in the parameters for the program
at hand,
but the defense sounds weak at best:
.[
%A O. Lecarme
%A P. Desjardins
%T ibid
%O p. 239
.]
.QS
``Since the bounds of an array are part of its type
(or, more exactly, of the type of its indexes),
it is impossible to define a procedure or function
which applies to arrays with differing bounds.
Although this restriction may appear to be a severe one,
the experiences we have had with Pascal tend to show that it
tends to occur very infrequently.
[...]
However, the need to bind the size of parametric arrays
is a serious defect in connection with the use of program libraries.''
.QE
.PP
This botch is the biggest single problem with Pascal.
I believe that if it could be fixed,
the language would be an order of magnitude more usable.
The proposed ISO standard for Pascal
.[
%A A. M. Addyman
%T A Draft Proposal for Pascal
%J SIGPLAN Notices
%D April 1980
%V 15
%N 4
%P 1-66
.]
provides such a fix
(``conformant array schemas''),
but the acceptance of this part of the standard is apparently
still in doubt.
.NH 2
There are no static variables and no initialization
.PP
A
.ul
static
variable
(often called an
.ul
own
variable in Algol-speaking countries)
is one that is private to some routine
and retains its value from one call of the routine to the next.
.ul
De facto,
Fortran variables are internal static, except for COMMON;\(dg
.FS
\(dg Strictly speaking, in Fortran 77 one must use
.UL SAVE 
to force the static attribute.
.FE
in C there is a
.UL static
declaration that can be applied to local variables.
.PP
Pascal has no such storage class.
This means that if a Pascal function or procedure intends to remember
a value from one call to another, the variable used
must be external to the function or procedure.
Thus it must be visible to other procedures,
and its name must be unique in the larger scope.
A simple example of the problem is a random number generator:
the value used to compute the current output must be saved
to compute the next one,
so it must be stored in a variable whose lifetime includes
all calls of the random number generator.
In practice, this is typically the outermost block of the program.
Thus the declaration of such a variable is far removed from the place
where it is actually used.
.PP
One example comes from the text formatter described in Chapter 7 of
.ul
Tools.
The variable 
.UL dir
controls the direction from which
excess blanks are inserted during line justification,
to obtain left and right alternately.
In Pascal, the code looks like this:
.P1
program formatter (...);

var
	dir : 0..1;	{ direction to add extra spaces }
	.
	.
	.
procedure justify (...);
begin
	dir := 1 - dir;	{ opposite direction from last time }
	...
end;

	...

begin { main routine of formatter }
	dir := 0;
	...
end;
.P2
The declaration,
initialization
and use
of the variable
.UL dir
are scattered all over the program,
literally hundreds of lines apart.
In C or Fortran,
.UL dir
can be made private to the only routine
that needs to know about it:
.P1
	...
main()
{
	...
}

	...

justify()
{
	static int dir = 0;

	dir = 1 - dir;
	...
}
.P2
.PP
There are of course many other examples of the same problem on a larger scale;
functions for buffered I/O,
storage management,
and symbol tables all spring to mind.
.PP
There are at least two related problems.
Pascal provides no way to 
initialize variables
statically
(i.e., at compile time);
there is nothing analogous to Fortran's
.UL DATA
statement or initializers like
.P1
int dir = 0;
.P2
in C.
This means that a Pascal program must contain explicit assignment statements
to initialize variables
(like the
.P1
dir := 0;
.P2
above).
This code makes the program source text bigger,
and the program itself bigger at run time.
.PP
Furthermore, the lack of initializers exacerbates the problem
of too-large scope caused by the lack of a static storage class.
The time to initialize
things is at the beginning,
so either the main routine itself begins with a lot of initialization code,
or it calls one or more routines to do the initializations.
In either case,
variables to be initialized
must be visible,
which means in effect at the highest level
of the hierarchy.
The result is that any variable that is to be initialized
has global scope.
.PP
The third difficulty is that there is no way
for two routines to share a variable unless
it is declared at or above their least common ancestor.
Fortran 
.UC COMMON
and
C's external static storage class both provide
a way for two routines to cooperate privately,
without sharing information with their ancestors.
.PP
The new standard does not offer static variables, initialization or non-hierarchical communication.
.NH 2
Related program components must be kept separate
.PP
Since the original Pascal was implemented with a one-pass compiler,
the language believes strongly in declaration before use.
In particular, procedures and functions must be declared (body and all)
before they are used.
The result is that a typical Pascal program reads from the bottom up \(em
all the procedures and functions are displayed before any of the code that
calls them,
at all levels.
This is essentially opposite to the order in which
the functions are designed and used.
.PP
To some extent this can be mitigated by a mechanism like the
.UL #include
facility of C and Ratfor:
source files can be included where needed without cluttering
up the program.
.UL #include
is not part of standard Pascal, although the UCB, VU and Whitesmiths compilers
all provide it.
.PP
There is also a
.UL forward
declaration in Pascal that permits separating the
declaration of the function or procedure header from
the body;
it is intended for defining mutually recursive procedures.
When the body is declared later on,
the header on that may contain only the function name,
and must not repeat the information from the first instance.
.PP
A related problem is that Pascal has a strict order
in which it is willing to accept declarations.
Each procedure or function consists of
.P1
.ta .6i
label	\f2label declarations, if any\fP
const	\f2constant declarations, if any\fP
type	\f2type declarations, if any\fP
var	\f2variable declarations, if any\fP
procedure \f2and\fP function \f2declarations, if any\fP
begin
	\f2body of function or procedure\fP
end
.P2
This means that all declarations of one kind (types, for instance)
must be grouped together for the convenience of the compiler,
even when the programmer would like to keep together
things that are logically related
so as to understand the program better.
Since a program has to be presented to the compiler all at once,
it is rarely possible to keep
the declaration, initialization and use of types and variables
close together.
Even some of the most dedicated Pascal supporters agree:
.[
%A J. Welsh
%A W. J. Sneeringer
%A C. A. R. Hoare
%T Ambiguities and Insecurities in Pascal
%J Software Practice and Experience
%V 7
%P 685-696
%D 1977
.]
.QS
``The inability to make such groupings
in structuring large programs
is one of Pascal's most frustrating limitations.''
.QE
.LP
A file inclusion facility helps only a little here.
.PP
The new standard does not relax the requirements
on the order of declarations.
.NH 2
There is no separate compilation
.PP
The ``official'' Pascal language does not provide separate compilation,
and so each implementation decides on its own what to do.
Some (the Berkeley interpreter, for instance) disallow it entirely;
this is closest to the spirit of the language
and matches the letter exactly.
Many others provide a declaration
that specifies that the body of a function is externally defined.
In any case, all such mechanisms are non-standard, and thus done
differently by different systems.
.PP
Theoretically, there is no need for separate compilation \(em
if one's compiler is very fast
(and if the source for all routines is always available
and if one's compiler has a file inclusion facility so that multiple copies
of source are not needed),
recompiling everything is equivalent.
In practice, of course,
compilers are never fast enough
and source is often hidden
and file inclusion is not part of the language,
so changes are time-consuming.
.PP
Some systems permit separate compilation
but do not validate consistency of types across the boundary.
This creates a giant hole in the strong typing.
(Most other languages do no cross-compilation checking either,
so Pascal is not inferior in this respect.)
I have seen at least one paper (mercifully unpublished) that on page
.IT n
castigates C for
failing to check types across separate compilation boundaries
while suggesting on page
.IT n +1
that the way to cope with Pascal
is to compile procedures separately
to avoid type checking.
.PP
The new standard does not offer separate compilation.
.NH 2
Some miscellaneous problems of type and scope
.PP
Most of the following points are minor irritations,
but I have to stick them in somewhere.
.PP
It is not legal to name a non-basic type
as the literal formal parameter of a procedure;
the following is not allowed:
.P1
procedure add10 (var a : array [1..10] of integer);
.P2
Rather, one must invent a type name, make a type declaration,
and declare the formal parameter to be an instance of that type:
.P1
type	a10 = array [1..10] of integer;
\&...
procedure add10 (var a : a10);
.P2
Naturally the type declaration is physically separated
from the procedure that uses it.
The discipline of inventing type names is helpful
for types that are used often,
but it is a distraction for things used only once.
.PP
It is nice to have the declaration
.UL var
for formal parameters of functions and procedures;
the procedure clearly states that it intends to modify
the argument.
But the calling program has no way to declare that a variable
is to be modified \(em
the information is only in one place, while two places would be better.
(Half a loaf is better than none, though \(em
Fortran tells the user nothing about who will do what
to variables.)
.PP
It is also a minor bother that arrays are passed by value
by default \(em the net effect is that every array
parameter is declared
.UL var
by the programmer more or less without thinking.
If the
.UL var
declaration is inadvertently omitted,
the resulting bug is subtle.
.PP
Pascal's
.UL set
construct seems like a good idea,
providing notational convenience and some free type checking.
For example, a set of tests like
.P1
if (c = blank) or (c = tab) or (c = newline) then ...
.P2
can be written rather more clearly and perhaps more efficiently as
.P1
if c in [blank, tab, newline] then ...
.P2
But in practice, set types are not useful for much more than
this, because the size of a set is strongly implementation
dependent (probably because it was so in the original CDC implementation:
59 bits).
For example, it is natural to attempt to write the function
.UL isalphanum(c)
(``is 
.UL c
alphanumeric?'') as
.P1
{ isalphanum(c) -- true if c is letter or digit }
function isalphanum (c : char) : boolean;
begin
	isalphanum := c in ['a'..'z', 'A'..'Z', '0'..'9']
end;
.P2
But in many implementations of Pascal (including the original)
this code fails because sets are just too small.
Accordingly,
sets are generally best left unused if one intends to write
portable programs.
(This specific routine also runs an order of magnitude slower
with sets than with a range test or array reference.)
.NH 2
There is no escape
.PP
There is no way to override the type mechanism when necessary,
nothing analogous to the ``cast'' mechanism in C.
This means that it is not possible to write programs like
storage allocators or I/O systems in Pascal,
because there is no way to talk about the type of object
that they return,
and no way to force such objects into an arbitrary type for
another use.
(Strictly speaking, there is a large hole in the type-checking
near variant records, through which some otherwise illegal 
type mismatches can be obtained.)
.NH
Control Flow
.PP
The control flow deficiencies of Pascal are minor but numerous
\(em
the death of a thousand cuts,
rather than a single blow to a vital spot.
.PP
There is no guaranteed order of evaluation of the logical operators
.UL and
and
.UL or
\(em nothing like
.UL && 
and
.UL ||
in C.
This failing, which is shared with most other languages,
hurts most often in loop control:
.P1
while (i <= XMAX) and (x[i] > 0) do ...
.P2
is extremely unwise Pascal usage,
since there is no way to ensure that 
.UL i
is tested before
.UL x[i]
is.
.PP
By the way, the parentheses in this code are mandatory \(em
the language has only four levels of operator precedence,
with relationals at the bottom.
.PP
There is no
.UL break
statement for exiting loops.
This is consistent with the one entry-one exit philosophy
espoused by proponents of structured programming,
but it does lead to nasty circumlocutions or duplicated code,
particularly when coupled with the inability to control the order in which
logical expressions are evaluated.
Consider this common situation, expressed in C or Ratfor:
.P1
while (getnext(...)) {
	if (something)
		break
	rest of loop
}
.P2
With no
.UL break
statement, the first attempt in Pascal is
.P1
done := false;
while (not done) and (getnext(...)) do
	if something then
		done := true
	else begin
		rest of loop
	end
.P2
But this doesn't work, because there is no way to force
the 
.UL not "" ``
.UL done ''
to be evaluated before the
next call of
.UL getnext .
This leads, after several false starts, to
.P1
done := false;
while not done do begin
	done := getnext(...);
	if something then
		done := true
	else if not done then begin
		rest of loop
	end
end
.P2
Of course recidivists can use a
.UL goto
and a label (numeric only and it has to be declared) to exit a loop.
Otherwise, early exits are a pain,
almost always requiring the invention of a boolean variable
and a certain amount of cunning.
Compare finding the last non-blank in an array in
Ratfor:
.P1
for (i = max; i > 0; i = i - 1)
	if (arr(i) != ' ')
		break
.P2
with Pascal:
.P1
done := false;
i := max;
while (i > 0) and (not done) do
	if arr[i] = ' ' then
		i := i - 1
	else
		done := true;
.P2
.PP
The index of a
.UL for
loop is undefined outside the loop, so
it is not possible to figure out whether one 
went to the end or not.
The increment of a
.UL for
loop can only be
.UL +1
or
.UL -1 ,
a minor restriction.
.PP
There is no 
.UL return
statement,
again for one in-one out reasons.
A function value is returned by setting the value of a pseudo-variable
(as in Fortran), then falling off the end of the function.
This sometimes leads to contortions to make sure that all paths
actually get to the end of the function with the proper value.
There is also no standard way to terminate execution
except by reaching the end of the outermost block,
although
many implementations
provide a
.UL halt
that causes immediate termination.
.PP
The
.UL case
statement is better designed than in C,
.ul
except
that there is no
.UL default
clause and the behavior is undefined 
if the input expression does not match any of the cases.
This crucial omission
renders the 
.UL case
construct almost worthless.
In over 6000 lines of Pascal in
.IT "Software Tools in Pascal" ,
I used it only four times,
although if there had been a
.UL default ,
a
.UL case
would have served in at least a dozen places.
.PP
The new standard offers no relief on any of these points.
.NH
The Environment
.PP
The Pascal run-time environment is relatively sparse,
and there is no extension mechanism except perhaps source-level
libraries in the ``official'' language.
.PP
Pascal's built-in I/O has a deservedly bad reputation.
It believes strongly in record-oriented input
and output.
It also has a look-ahead convention that is hard to
implement properly in an interactive environment.
Basically, the problem is that the I/O system believes that
it must read one record ahead of the record
that is being processed.
In an interactive system, this means that when a program is started,
its first operation is to try to read the terminal for the first
line of input,
before any of the program itself has been executed.
But in the program
.P1
write('Please enter your name: ');
read(name);
\&...
.P2
read-ahead causes the program to hang, waiting
for input before printing the prompt that asks for it.
.PP
It is possible to escape most of the evil effects of
this I/O design by very careful implementation,
but not all Pascal systems do so,
and in any case it is relatively costly.
.PP
The I/O design reflects the original operating system
upon which Pascal was designed;
even Wirth acknowledges that bias,
though not its defects.
.[
%A N. Wirth
%J ibid.
%O p. 196
.]
It is assumed that text files consist of records,
that is, lines of text.
When the last character of a line is read, the 
built-in function
.UL eoln
becomes true;
at that point, one must call
.UL readln
to initiate reading a new line
and reset
.UL eoln .
Similarly, when the last character of the file is read,
the built-in
.UL eof
becomes true.
In both cases,
.UL eoln
and
.UL eof
must be tested before each
.UL read
rather than after.
.PP
Given this, considerable pains must be taken to simulate sensible input.
This implementation of
.UL getc
works for Berkeley and VU I/O systems,
but may not necessarily work for anything else:
.P1
{ getc -- read character from standard input }
function getc (var c : character) : character;
var
	ch : char;
begin
	if eof then
		c := ENDFILE
	else if eoln then begin
		readln;
		c := NEWLINE
	end
	else begin
		read(ch);
		c := ord(ch)
	end;
	getc := c
end;
.P2
The type
.UL character
is not the same as
.UL char ,
since
.UL ENDFILE
and perhaps
.UL NEWLINE
are not legal values
for a
.UL char
variable.
.PP
There is no notion at all of access to a file system except for predefined files
named by (in effect) logical unit number
in the 
.UL program
statement that begins each program.
This apparently reflects the CDC batch system in which
Pascal was originally developed.
A file variable
.P1
var	fv : file of \f2type\fP
.P2
is a very special kind of object \(em
it cannot be assigned to, nor used except by calls to built-in procedures
like
.UL eof ,
.UL eoln ,
.UL read ,
.UL write ,
.UL reset
and
.UL rewrite .
.UL reset "" (
rewinds a file and makes it ready for re-reading;
.UL rewrite
makes a file ready for writing.)
.PP
Most implementations of Pascal provide an escape hatch
to allow access to files by name from the outside environment,
but not conveniently
and not standardly.
For example, many systems permit a filename argument
in calls to
.UL reset
and
.UL rewrite :
.P1
reset(fv, filename);
.P2
But
.UL reset
and
.UL rewrite
are procedures, not functions \(em
there is no status return and
no way to regain control if for some reason
the attempted access fails.
(UCSD provides a compile-time flag
that disables the normal abort.)
And since
.UL fv 's
can not appear in expressions like
.P1
reset(fv, filename);
if fv = failure then ...
.P2
there is no escape in that direction either.
This straitjacket makes it essentially impossible to write programs
that recover from mis-spelled file names, etc.
I never solved it adequately in the
.ul
Tools
revision.
.PP
There is no notion of access to command-line arguments,
again probably reflecting Pascal's batch-processing origins.
Local routines may allow it by adding non-standard procedures to the environment.
.PP
Since it is not possible to write a general-purpose storage allocator
in Pascal
(there being no way to talk about the types that such a function
would return),
the language has a built-in procedure
called
.UL new
that allocates space from a heap.
Only defined types may be allocated,
so it is not possible to allocate, for example,
arrays of arbitrary size to hold character strings.
The pointers returned by
.UL new
may be passed around but not manipulated:
there is no pointer arithmetic.
There is no way to regain control if storage runs out.
.PP
The new standard offers no change in any of these areas.
.NH
Cosmetic Issues
.PP
Most of these issues are irksome to an experienced programmer,
and some are probably a nuisance even to beginners.
All can be lived with.
.PP
Pascal, in common with most other Algol-inspired languages,
uses the semicolon as a statement separator rather than a terminator
(as it is in PL/I and C).
As a result one must have a reasonably sophisticated notion
of what a statement is to put semicolons in properly.
Perhaps more important, if one is serious about using them
in the proper places, a fair amount of nuisance editing is needed.
Consider the first cut at a program:
.P1
if a then
	b;
c;
.P2
But if something must be inserted before
.UL b ,
it no longer needs a semicolon, because it now precedes an
.UL end :
.P1
if a then begin
	b0;
	b
end;
c;
.P2
Now if we add an
.UL else ,
we
.ul
must
remove the semicolon on the
.UL end :
.P1
if a then begin
	b0;
	b
end
else
	d;
c;
.P2
And so on and so on,
with semicolons rippling up and down the program
as it evolves.
.PP
One generally accepted experimental result in programmer psychology
is that semicolon as separator is about ten times
more prone to error than semicolon as terminator.
.[
%A J. D. Gannon
%A J. J. Horning
%T Language Design for Programming Reliability
%J IEEE Trans. Software Engineering
%V SE-1
%N 2
%D June 1975
%P 179-191
.]
(In Ada,
.[
%T Rationale for the Design of the Ada Programming Language
%A J. D. Ichbiah, et al
%J SIGPLAN Notices
%D June 1979
%V 14
%N 6
.]
the most significant language based on Pascal,
semicolon is a terminator.)
Fortunately, in Pascal one can almost always close one's eyes
and get away with a semicolon as a terminator.
The exceptions are in places like declarations, where the separator vs. terminator problem
doesn't seem as serious anyway,
and just before
.UL else ,
which is easy to remember.
.PP
C and Ratfor programmers find
.UL begin
and
.UL end
bulky compared to
.UL {
and
.UL } .
.PP
A function name by itself is a call of that function;
there is no way to distinguish such a function call from a simple variable
except by knowing the names of the functions.
Pascal uses the Fortran trick
of having the function name act like a variable within the function,
except that where in Fortran the function name really is a variable,
and can appear in expressions,
in Pascal, its appearance in an expression
is a recursive invocation:
if
.UL f
is a zero-argument function,
.UL f:=f+1
is a recursive call of
.UL f .
.PP
There is a paucity of operators (probably related to the
paucity of precedence levels).
In particular, there are no bit-manipulation operators
.UC AND , (
.UC OR ,
.UC XOR ,
etc.).
I simply gave up trying to write the following trivial encryption program
in Pascal:
.P1
i := 1;
while getc(c) <> ENDFILE do begin
	putc(xor(c, key[i]));
	i := i mod keylen + 1
end
.P2
because I couldn't write a sensible
.UL xor
function.
The set types help a bit here (so to speak), but not enough;
people who claim that Pascal is a system programming language
have generally overlooked this point.
For example,
.[ [
%A J. Welsh
%A W. J. Sneeringer
%A C. A. R. Hoare
%T ibid
.], p. 685]
.QS
``Pascal is at the present time
[1977]
the best language in the public domain
for purposes of system programming and software implementation.''
.QE
seems a bit naive.
.PP
There is no null string, 
perhaps because Pascal uses the
doubled quote notation to indicate a quote embedded in a string:
.P1
\&'This is a '' character'
.P2
There is no way to put non-graphic symbols into strings.
In fact, non-graphic characters are unpersons in a stronger sense,
since they are not mentioned in any part of the standard language.
Concepts like newlines, tabs, and so on are handled on each system
in an
.ul
ad hoc
manner,
usually by knowing something about the character set
(e.g., ASCII newline has decimal value 10).
.PP
There is no macro processor.
The
.UL const
mechanism for defining manifest constants
takes care of about 95 percent of the uses of
simple
.UL #define 
statements in C,
but more involved ones are hopeless.
It is certainly possible to put a macro preprocessor on a Pascal compiler.
This allowed me to simulate a sensible 
.UL error
procedure as
.P1
#define  error(s)  begin writeln(s); halt end
.P2
.UL halt "" (
in turn might be defined as a branch to the end of
the outermost block.)
Then calls like
.P1
	error('little string');
	error('much bigger string');
.P2
work
since
.UL writeln
(as part of the standard Pascal environment)
can handle strings of any size.
It is unfortunate that there is no way to make this convenience
available to routines in general.
.PP
The
language prohibits expressions in declarations, so it is not possible
to write things like
.P1
const	SIZE = 10;
type		arr = array [1..SIZE+1] of integer;
.P2
or even simpler ones like
.P1
const	SIZE = 10;
		SIZE1 = SIZE + 1;
.P2
.NH
Perspective
.PP
The effort to rewrite the programs in
.ul
Software Tools
started in March, 1980,
and, in fits and starts, lasted until January, 1981.
The final product
.[
%A B. W. Kernighan
%A P. J. Plauger
%T Software Tools in Pascal
%I Addison-Wesley
%D 1981
.]
was published in June, 1981.
During that time I gradually adapted to most of
the superficial problems with Pascal
(cosmetics, the inadequacies of control flow),
and developed imperfect solutions to the significant ones
(array sizes, run-time environment).
.PP
The programs in the book are meant to be complete, well-engineered
programs that do non-trivial tasks.
But they do not have to be efficient,
nor are their interactions with the operating system
very complicated,
so I was able to get by with some pretty kludgy solutions,
ones that simply wouldn't work for real programs.
.PP
There is no significant way in which I found Pascal superior to C,
but there are several places where it is
a clear improvement over Ratfor.
Most obvious by far is recursion:
several programs are much cleaner when written recursively,
notably the pattern-search, quicksort, and expression evaluation.
.PP
Enumeration data types are a good idea.
They simultaneously delimit the range of legal values
and document them.
Records help to group related variables.
I found relatively little use for pointers.
.PP
Boolean variables are nicer than integers for Boolean conditions;
the original Ratfor programs contained some unnatural constructions because
Fortran's logical variables are badly designed.
.PP
Occasionally Pascal's type checking would warn of a slip
of the hand in writing a program;
the run-time checking of values also indicated errors
from time to time, particularly subscript range violations.
.PP
Turning to the negative side, recompiling a large program from scratch to change a single line
of source is extremely tiresome;
separate compilation, with or without type checking,
is mandatory for large programs.
.PP
I derived little benefit from the fact that
characters are part of Pascal and not part of Fortran,
because the Pascal treatment of strings and non-graphics
is so inadequate.
In both languages, it is appallingly clumsy to initialize literal strings
for tables of keywords, error messages, and the like.
.PP
The finished programs are in general about the same number
of source lines as their Ratfor equivalents.
At first this surprised me,
since my preconception was that Pascal is a wordier and less expressive
language.
The real reason seems to be that Pascal permits arbitrary expressions
in places like loop limits and subscripts
where Fortran (that is, portable Fortran 66) does not,
so some useless assignments can be eliminated;
furthermore, the Ratfor programs declare functions while Pascal ones do not.
.sp
.PP
To close, let me summarize the main points in the case against Pascal.
.IP 1.
Since the size of an array is part of its type,
it is not possible to write general-purpose routines,
that is,
to deal with arrays of different sizes.
In particular, string handling is very difficult.
.IP 2.
The lack of static variables, initialization
and a way to communicate non-hierarchically
combine to destroy the ``locality'' of a program \(em
variables require much more scope than they ought to.
.IP 3.
The one-pass nature of the language forces procedures and functions
to be presented in an unnatural order;
the enforced separation of various declarations scatters program
components that logically belong together.
.IP 4.
The lack of separate compilation impedes the development of large programs
and makes the use of libraries impossible.
.IP 5.
The order of logical expression evaluation cannot be controlled,
which leads to convoluted code and extraneous variables.
.IP 6.
The
.UL case
statement is emasculated because there is no default clause.
.IP 7.
The standard I/O is defective.
There is no sensible provision for dealing with files or program arguments
as part of the standard language,
and no extension mechanism.
.IP 8.
The language lacks most of the tools needed for assembling
large programs, most notably file inclusion.
.IP 9.
There is no escape.
.PP
This last point is perhaps the most important.
The language is inadequate but circumscribed,
because there is no way to escape its limitations.
There are no casts to disable the type-checking
when necessary.
There is no way to replace the defective run-time environment
with a sensible one,
unless one controls the compiler that defines the ``standard procedures.''
The language is closed.
.PP
People who use Pascal for serious programming
fall into a fatal trap.
Because the language is so impotent, it must be extended.
But each group extends Pascal in its own direction,
to make it look like whatever language they really want.
Extensions for separate compilation,
Fortran-like
.UC COMMON ,
string data types,
internal static variables,
initialization,
octal numbers,
bit operators,
etc.,
all add to the utility of the language
for one group,
but destroy its portability to others.
.PP
I feel that it is a mistake to use Pascal for anything much
beyond its original target.
In its pure form,
Pascal is a toy language,
suitable for teaching but not for real programming.
.SH
Acknowledgments
.PP
I am grateful to
Al Aho,
Al Feuer,
Narain Gehani,
Bob Martin,
Doug McIlroy,
Rob Pike,
Dennis Ritchie,
Chris Van Wyk
and
Charles Wetherell
for helpful criticisms
of earlier versions of this paper.
.[
$LIST$
.]
-------------- next part --------------
.ig

	brian's sleazy book macros

..
.ds d .
.nr PS 10	\" text point size
.nr VS 12	\" text vertical (inter-line) spacing
.ps \n(PS
.vs \n(VS
.nr P1 .4i	\" program indent in .P1
.nr dP 1	\" delta point size for program
.nr dV 2p	\" delta vertical for programs
.nr dT 5	\" delta tab stop for programs
.	\" the following are book values
....pl 9.2i	\" page length; this gives 7.2i of text
....nr LL 4.8i	\" line length.  this gives 6x9 book size
....nr LT 4.8i	\" ditto
....FL 4.8i	\" line length in footnotes
....po 1.5i	\" page offset
....nr PD 0	\" paragraph space is zero
....nr PI .2i	\" paragraph indent
.hy 14		\" hyphenation: 2=not last lines; 4= no -xx; 8=no xx-
.hw semi-colon
.hw hexa-decimal
.hw estab-lished
.hw multi-line
.ig
	the next several are all called the same way
	.UC arg
		prints arg in smaller size
	.UC arg right
		prints arg in smaller size, right in regular
	.UC arg right left  [sic]
		prints left regular, arg smaller, right regular
		as in .UC UNIX ) (
..
.de UC		\" print argument in small size but keep surround in regular
\&\\$3\s-1\\$1\\s0\&\\$2
..
.de CW		\" puts first arg in CW font
\%\&\\$3\f(CW\\$1\f1\&\\$2
..
.de IT		\" ditto to italicize argument
\&\\$3\f2\\$1\f1\^\&\\$2
..
.de BI		\" bold italic
\&\\$3\f(BI\\$1\f1\^\&\\$2
..
.de UI		\" CW then italic
\&\f(CW\\$1\f2\\$2\f1\\$3
..
.ig
	programs are displayed between .P1/.P2 pairs
	default is to indent by 1/2 inch, nofill, dP smaller
	.P1 x causes an indent of x instead.

	.P3 can be used to specify optional page-break points
	inside .P1/.P2
..
.nr DV .5v	\" space before start of program
.nr dT 5
.de P1
.nr P1 .4i	\" program indent in .P1
.if \\n(.$ .nr P1 \\$1
.br
.nr v \\n(.v
.di p1
.in \\n(P1u
.nf
.ps -\\n(dP
.vs -\\n(dVu
.ft CW
.nr t \\n(dT*\\w'x'u
.ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu
..
.de P2
.br
.ps \\n(PS
.vs \\n(VSp
.vs \\nvu
.ft 1
.in
.di
.br
.sp \\n(DVu
.br
.if \\n(.$=0 .ne \\n(dnu  \" -\\n(DVu
.p1
.sp \\n(DVu
.br
.fi
..
.de P3	\" provides optional break in P1/P2
.nr x \\n(DV
.nr DV 0
.P2
.P1 \\n(P1u
.nr DV \\nx
..
.de Q1	\" simple version for use within exercises, etc.
.nr P1 .4i
.if \\n(.$ .nr P1 \\$1
.br
.di p1
.sp \\n(DVu
.in \\n(P1u
.nf
.ps -\\n(dP
.vs -\\n(dVu
.ft CW
.nr t \\n(dT*\\w'x'u
.ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu
..
.de Q2
.sp \\n(DVu
.ps +\\n(dP
.vs +\\n(dVu
.ft 1
.in
.di
.if \\n(.$=0 .ne \\n(dnu-\\n(DVu
.br
.p1
.br
.fi
..
.ig
	the .get macro permits inclusion of programs or parts thereof
	usually within .P1/.P2.  Call is
	.get name
		to get contents of file name
	.get name line
		to get line of file;  line is a number or /regexp/
	.get name line1 line2
		get from line1 to line2 inclusive
	.get name line1 line2 exitline
		ditto, but stop when first exitline is seen
	"name" is relative to directory given in \*d
		default name of code directory is Code
	NOTE THAT THE MACRO IS CALLED AS .get.  The "t" is \\$1.
..
.
.de ge	\" get file
.sy /usr/bwk/bin/trget \\n(.$ \\*d/\\$2 '\\$3' '\\$4' '\\$5' >junk.\\n($$
.so junk.\\n($$
..
.de ru	\" .run command, insert input.  note arg 1 is "n"
.sy \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9 >junk.\\n($$
.so junk.\\n($$
..
.\"
.am EM	\" wrap up at end of input
.sy rm -f junk.\\n($$ /tmp/foo\n($$	\" remove temporaries
..
.de ix	\" the index macro.  period.
.ie '\\n(.z'' .tm ix: \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9	\\n(pn
.el \\!.ix \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
..

From ewayte at gmail.com  Thu Aug 31 00:13:51 2017
From: ewayte at gmail.com (Eric Wayte)
Date: Wed, 30 Aug 2017 10:13:51 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <201708301234.v7UCYsPQ002608@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
Message-ID: <CAJc6K3XU2-jBM7XQZ2Na2tp6T_HQ3BniogOEXD1_m_9U1eqx+w@mail.gmail.com>

When I was a budding Computer Science major at UCF in 1983, I requested a
copy of this paper through Interlibrary Loan.  A few weeks later, a copy of
the paper arrived from Bell Labs, with a nice AT&T / Bell Laboratories
cover!

I still have my copy!

On Wed, Aug 30, 2017 at 8:34 AM, <arnold at skeeve.com> wrote:

>         Seek and ye shall find.
>
>         Ask and ye shall receive.
>
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
>
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.
>
> In the meantime, Warren, please add to the archives when you are able.
>
> Enjoy!
>
> Arnold
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/cd134aad/attachment.html>

From michael at kjorling.se  Thu Aug 31 00:30:55 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 30 Aug 2017 14:30:55 +0000
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <201708301234.v7UCYsPQ002608@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
Message-ID: <20170830143055.GE3837@66AACC8FFBE94EA6A2F07399E8E0E647>

On 30 Aug 2017 06:34 -0600, from arnold at skeeve.com:
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
> 
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.

For those who are impatient and don't want to wade through the markup,
I see that there is a copy at
<https://www.lysator.liu.se/c/bwk-on-pascal.html>. I haven't verified
that it's the same one, but at least the date matches.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From ewayte at gmail.com  Thu Aug 31 00:43:19 2017
From: ewayte at gmail.com (Eric Wayte)
Date: Wed, 30 Aug 2017 10:43:19 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170830143055.GE3837@66AACC8FFBE94EA6A2F07399E8E0E647>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170830143055.GE3837@66AACC8FFBE94EA6A2F07399E8E0E647>
Message-ID: <CAJc6K3VOsMSO0fbw-hKDzR-2oXcBgxUy8iOOdNUCvHwpMH3Qsw@mail.gmail.com>

Interesting, my paper copy is dated July 18, 1981 on both the title page
and after the abstract.

On Wed, Aug 30, 2017 at 10:30 AM, Michael Kjörling <michael at kjorling.se>
wrote:

> On 30 Aug 2017 06:34 -0600, from arnold at skeeve.com:
> > Brian Kernighan was kind enough to find for me everyone's favorite
> > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > My Favorite Programming Language".
> >
> > Attached is the file and his macros.  This will not immediately
> > format using groff etc.; I hope to create a version that will, sometime
> > in the next few weeks.
>
> For those who are impatient and don't want to wade through the markup,
> I see that there is a copy at
> <https://www.lysator.liu.se/c/bwk-on-pascal.html>. I haven't verified
> that it's the same one, but at least the date matches.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/4aa0bfde/attachment.html>

From ron at ronnatalie.com  Thu Aug 31 01:34:44 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 30 Aug 2017 11:34:44 -0400
Subject: [TUHS] Bell Labs history question
In-Reply-To: <201708291307.v7TD7D2K013036@freefriends.org>
References: <201708291307.v7TD7D2K013036@freefriends.org>
Message-ID: <3BC74B22-9F95-4801-9BB8-21B61F8E3726@ronnatalie.com>

The last I can probably answer.   Early ls -l would only list the user name not the group.




From mutiny.mutiny at rediffmail.com  Thu Aug 31 03:10:52 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 30 Aug 2017 17:10:52 -0000
Subject: [TUHS]
	=?utf-8?q?Why_Pascal_is_Not_My_Favorite_Programming_Langua?=
	=?utf-8?q?ge_-_Unearthed!?=
In-Reply-To: <201708301234.v7UCYsPQ002608@freefriends.org>
Message-ID: <1504096706.S.48809.14971.f4-234-194.1504113052.564@webmail.rediffmail.com>

check out: https://www.lysator.liu.se/c/bwk-on-pascal.htmlhttp://doc.cat-v.org/bell_labs/why_pascal/https://github.com/bitemyapp/Articles-1/blob/master/General/Why%20Pascal%20is%20Not%20My%20Favorite%20Programming%20Language%20(Kernighan).pdfFrom: arnold at skeeve.comSent: Wed, 30 Aug 2017 18:08:26To: tuhs at tuhs.orgSubject: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!&nbsp;&nbsp;&nbsp;Seek and ye shall find.&nbsp;&nbsp;&nbsp;Ask and ye shall receive.Brian Kernighan was kind enough to find for me everyone&#39;s favoriteComputing Sceince Technical Report, CSTR 100, &quot;Why Pascal is NotMy Favorite Programming Language&quot;.Attached is the file and his macros. &nbsp;This will not immediatelyformat using groff etc.; I hope to create a version that will, sometimein the next few weeks.In the meantime, Warren, please add to the archives when you are able.Enjoy!Arnold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/9bbc7ad1/attachment.html>

From mparson at bl.org  Thu Aug 31 08:33:49 2017
From: mparson at bl.org (Michael Parson)
Date: Wed, 30 Aug 2017 17:33:49 -0500
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <201708301234.v7UCYsPQ002608@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
Message-ID: <7584bb4ccd27f08f443484b80152e4da@bl.org>

On 2017-08-30 07:34, arnold at skeeve.com wrote:
> Seek and ye shall find.
> 
> 	Ask and ye shall receive.
> 
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
> 
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.

I was able to get it to format with groff/refer on my OS X 10.11.6 
system (groff 1.19.2) with a single edit to cstr100, changing the path 
to cprog.mac in line 5 to './cprog.mac'.  It produced a few warnings, 
but produced what seems to be reasonable output:

$ refer < cstr100 | groff -Tps -ms | ps2pdf - cstr100.pdf
refer:<standard input>:70: no matches for `kernighan plauger software 
tools addison'
refer:<standard input>:112: no matches for `jensen wirth pascal report 
1978'
refer:<standard input>:141: no matches for `habermann pascal critical'
refer:<standard input>:1531: found `$LIST$' but not accumulating 
references
<standard input>:10: warning: can't find font `B'
<standard input>:12: warning: can't find font `I'
<standard input>:14: warning: can't find font `R'

The errors in the refer output seem to be legit problems in the source 
file.  I've not been able to figure out what's going on with the font 
errors, those lines seem OK to me, but my (g|t)roff is rusty.

A little bit of searching on Google let me fill in the missing bits for 
refer, but I still haven't fixed the font warnings.

-- diff output --
--- cstr100.orig        2017-08-30 17:32:29.000000000 -0500
+++ cstr100     2017-08-30 17:30:47.000000000 -0500
@@ -2,7 +2,7 @@
  .fp 2 PI
  .fp 3 PB
  .ds pf CW
-.so /usr/bwk/src/cprog.mac
+.so ./cprog.mac
  .if n .ls 2
  ....ND "April 2, 1981"
  ....TM 81-11272-12 11173 39199-11
@@ -66,7 +66,11 @@
  .ul
  Software Tools
  .[
-kernighan plauger software tools addison
+%T Software Tools
+%A B. W. Kernighan
+%A P. J. Plauger
+%I Addison-Wesley
+%D 1976
  .]
  in Pascal.
  .PP
@@ -107,7 +111,9 @@
  The language is close to the nominal standard
  of Jensen and Wirth,
  .[
-jensen wirth pascal report 1978
+%A Jensen Wirth
+%T Pascal User Manual and Report
+%D 1978
  %O (2nd edition.)
  .]
  with good diagnostics and careful run-time checking.
@@ -137,7 +143,11 @@
  The most often cited papers (well worth reading) are
  a strong critique by Habermann
  .[
-habermann pascal critical
+%A A. Nico Habermann
+%T Critical Comments on the Programming Language Pascal
+%D 1973
+%J Acta Informatica
+%V 3
  .]
  and an equally strong rejoinder by
  Lecarme and Desjardins.

-- end diff --

-- 
Michael Parson
Pflugerville, TX
KF5LGQ




From dave at horsfall.org  Thu Aug 31 10:27:42 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 31 Aug 2017 10:27:42 +1000 (EST)
Subject: [TUHS] Bell Labs history question
In-Reply-To: <3BC74B22-9F95-4801-9BB8-21B61F8E3726@ronnatalie.com>
References: <201708291307.v7TD7D2K013036@freefriends.org>
 <3BC74B22-9F95-4801-9BB8-21B61F8E3726@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1708311026580.19665@aneurin.horsfall.org>

On Wed, 30 Aug 2017, Ronald Natalie wrote:

> The last I can probably answer.  Early ls -l would only list the user 
> name not the group.

Yep; you had to say "ls -lg" to get the group.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From cym224 at gmail.com  Thu Aug 31 10:55:35 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 30 Aug 2017 20:55:35 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <7584bb4ccd27f08f443484b80152e4da@bl.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
Message-ID: <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>

On 30 August 2017 at 18:33, Michael Parson <mparson at bl.org> wrote:
> On 2017-08-30 07:34, arnold at skeeve.com wrote:
[...]
>> Attached is the file and his macros.  This will not immediately
>> format using groff etc.; I hope to create a version that will, sometime
>> in the next few weeks.
>
>
> I was able to get it to format with groff/refer on my OS X 10.11.6 system
> (groff 1.19.2) with a single edit to cstr100, changing the path to cprog.mac
> in line 5 to './cprog.mac'.

I tried the following on  my Solaris 10 box:

refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost >cstr100.ps

It composes fine until the first underline (.ul) but puts the
bibliography at the end with the error message "No files Ind"..
Without refer, it composes the entire document fine but without the
references.  No font errors.

N.


From bakul at bitblocks.com  Thu Aug 31 11:13:39 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 30 Aug 2017 18:13:39 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: Your message of "Wed, 30 Aug 2017 06:34:54 MDT."
 <201708301234.v7UCYsPQ002608@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
Message-ID: <20170831011339.9465B124AEA5@mail.bitblocks.com>

On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".

If I may comment on the paper itself....

I used Pascal heavily for about 5-6 years and was also
involved in implementing a variant of Pascal for a couple of
years.  And I have used C since 1981.  I have to say I was
quite happy using Pascal. Some of bwk's criticism (e.g.  re:
sets) applies to pascal compilers, not the language. There is
also some misunderstanding (e.g.
    type apple = integer; orange = integer;
This is renaming, not a new type).  The array problem got
fixed somewhat in the 1985 standard, while arrays are not
even first class objects in C.  Most implementations added
separate compilation as well (1985 standard considers this an
implementation issue but does allow you to declare external
references).

Things I missed in C that were in Pascal:
- enumerated types (type color = (red, blue, green))
- subranges
- nested functions (even if limited)
- first class arrays (even if limited)
- sets
- lexical non-local goto
- bounds checking
- arrays that didn't start at 0.
- function argument checking (K&R C)
- tagged variant records

All in all, both languages are quite comparable.  Each
language had their strong points and weak ones. Basically Pascal
was easier to use /right/ and C more flexible. Pascal code is
easier to read than C code (even today). It was harder to
"cheat" in Pascal but the same is a useful feature of C for
low level work.  To be frank the *main* thing that attracted
me to C was its conciseness :-) If Unix was written in Pascal
I would've happily continued using Pascal!

--bakul


From arnold at skeeve.com  Thu Aug 31 16:20:39 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 31 Aug 2017 00:20:39 -0600
Subject: [TUHS] Bell Labs history question
In-Reply-To: <alpine.BSF.2.21.1708311026580.19665@aneurin.horsfall.org>
References: <201708291307.v7TD7D2K013036@freefriends.org>
 <3BC74B22-9F95-4801-9BB8-21B61F8E3726@ronnatalie.com>
 <alpine.BSF.2.21.1708311026580.19665@aneurin.horsfall.org>
Message-ID: <201708310620.v7V6Kdeu025893@freefriends.org>

> > The last I can probably answer.  Early ls -l would only list the user 
> > name not the group.

This I knew.

> Yep; you had to say "ls -lg" to get the group.

And this too.  V7 ls is this way.

But I would have thought by the V10 timeframe that ls -l would also
have shown the group, and I was wondering what group (group name)
that would have been.

It's not that important.

Thanks to everyone who answered,

Arnold


From arnold at skeeve.com  Thu Aug 31 23:29:43 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 31 Aug 2017 07:29:43 -0600
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
Message-ID: <201708311329.v7VDThNT012493@freefriends.org>

Nemo <cym224 at gmail.com> wrote:

> I tried the following on  my Solaris 10 box:
>
> refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost >cstr100.ps
>
> It composes fine until the first underline (.ul) but puts the
> bibliography at the end with the error message "No files Ind"..
> Without refer, it composes the entire document fine but without the
> references.  No font errors.

You should probably use refer -e to get the references at the end.

The original PS is in the http://www.skeeve.com/cstr.tar.gz tar ball,
for comparison purposes. :-)

I will eventually set up a github repo with this doc and I hope
instructions for formatting with groff.

Thanks,

Arnold


