Apropos of the virtue of negative subscripts.
> by pointing into the middle of another data structure you've created a
data aliasing situation
Not if all references are relative to the offset pointer. The following
example is silly, but I recently used exactly this trick to simplify
calculations on a first-quadrant (x,y) grid by supplying "out-of-bounds"
zeroes at (x,-2), (x,-1) and (-1,y). It was much cleaner to access the
zeroes like ordinary elements than to provide special code to handle the
boundary conditions.
/* Fill an N-element array with Fibonacci numbers, f(i), where 0<=i<N.
The recursion accesses a zero "out of bounds" at i=-1 */
const int N = 100;
int base[N+1];
#define fib(i) base[(i)+1]
void fill() {
int i;
fib(0) = 1;
for(i=1; i<N; i++)
fib(i) = fib(i-2) + fib(i-1);
}
Doug
Hello all,
I know that this isn't strictly a "UNIX history" question, but as I am
working with historic UNIX and this list contains a great number of people
who were instrumental in its development, I figured it would be appropriate
to ask here. If there's a better place for these sorts of questions,
please let me know.
I'm trying to figure out how the array size limits are set in the 2.11BSD
pcc compiler. I've looked through quite a bit of documentation but I don't
see anything that describes this. In theory on a 16 bit system I would
think that the maximum array size would be 64K, but the actual limit that I
found through trial and error is (2^15)-1.
Declaring an array that is too large results in an error of "Constant
required", which is being produced by c01.c in conexp().
https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/ccom/c01.c
I did quite a bit of searching through the source but I was not able to
determine where this limit is being set. This is where my usual tools fall
apart. Normally since I have the source I would compile the program I want
with debugging turned on, and then do a backtrace so that I could see how
we got to conexp(). But as far as I can tell I can't get a backtrace,
since there is no option for debugging information in pcc; adb can only
tell me where a process stopped.
I would appreciate any enlightenment or pointers to other documentation.
Thanks in advance!
-Henry
Lyndon Nerenberg (VE7TFX/VE6BBM):
Oh come on Rob, you should know that for anyone over the age of 50,
the moment you see 'dd' your brain automatically switches to JCL
mode.
===
Rob doubtless got IBM out of his system back in the
late 1970s, when I think he was one of the authors
of a shell that brought the TSO experience to Unix.
Norman Wilson
Toronto ON
On Monday, September 16th, 2024 at 6:28 PM, Henry Bent <henry.r.bent(a)gmail.com> wrote:
> ...
> I also have v9 on a Sun in TME
> ...
>
> -Henry
>
V9 you say...does your setup happen to have the on-line manpages by any chance? I don't think a surviving copy is in the TUHS archive. V9 is a tad bit fragmentary in the archive at present from what I can tell, it may be worth seeing if anything you have fills in blanks.
- Matt G.
Rob Pike:
I don't remember whether late Research Unix [dd] had -if, but Plan 9
certainly did.
===
I don't have a live 10/e system at the moment, but I have
the 10/e source tree handy. Classic parody-IBM syntax
only.
Aside: I'm curious: does anyone else have 8/e, 9/e, or
10/e running these days?
Norman Wilson
Toronto ON
The florid syntax of IBM's DD was rivaled by that of GE's file utility. I
always wondered whether it was named FUTIL unwarily or with tongue in cheek.
Doug
> On 15 Sep 2024, at 20:21, Rik Farrow <rik(a)rikfarrow.com> wrote:
>
> Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'...
Hangover from assembly mnemonics, perhaps.
J
—
John Dow <jmd(a)nelefa.org>
Written by a human.
> https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs
Luckham's introductory remark that all the programmers were men contrasts
with the situation 10 years before, when most of the programmers were
women. Women got shoved aside when it became apparent that programming was
an honorable and challenging engineering profession, not mere routine
translation of conceptual designd into machine language. It took almost 10
more years for the Labs to recognize that women programmers were engineers,
too.
Yet de jure recognition of women programmers has not yet become de facto.
Here at Dartmouth, as at many schools, women form a far smaller fraction of
computer science than they do of the engineering school. In engineering the
proportion of women reflects that in the general population.
Hi all,
I was working with my IRIX 4 machine recently and noticed a mysterious file
- /usr/lib/ecfe. It turns out that this is the Edison Design Group C (not
C++) Front End, included almost certainly by accident with the last release
of the Developer Toolkit for IRIX 4. No other piece of the compiler
toolchain references the EDG product in any way and there is no
documentation for it whatsoever.
The research that I did seems to indicate that this is a source to source
translator, akin to the contemporary Kuck & Associates product - is that
correct? I also found a reference to EDG's tool being used in the Apogee C
compiler. I have a copy of Apogee C for SunOS and it does appear that
"cfe" is the same EDG product. Unfortunately there is no documentation
specific to the C front end, and I don't have a license for Apogee C so I
can't run the compiler to see how it's calling cfe. Just running a C file
"blah.c" through the IRIX front end with no switches results in a
transformed file "blah.int.c". Unfortunately running anything even
moderately complex through the front end results in code that either
doesn't compile or doesn't run, so I feel that I must be missing some flags
or basic options.
Does anyone have any information about SGI's use of this software, or any
documentation/information in general about the EDG product? My usual
sources came up empty.
-Henry
>> I've despaired over the term ever since it wormed its way into
>> computer folks' vocabulary. How does a "use case" differ from a "use"?
>
> Clarity as to whether one is employing a noun or a verb. Both "use" and
> "case" can be either (he said, casing the joint for tomorrow's heist),
> but juxtaposing them thus unambiguously makes a noun phrase.
Usually context makes the nominal use of "use" clear : "many uses", "the
use",
"some uses". I'm not persuaded that "use case" disambiguates any more
reliably.
How do supermarkets display their wares?
For some use cases they use cases.
Metacomment. While the "use" in "nominal use" above must be a noun,
"nominal" isn't compelled to have the intended meaning of "being a noun".
It's a game of whac-a-mot. Kill one ambiguity and spawn another.
Doug
Two remarks about Plan 9, one about an antecedent and the other about the
limits of its influence.
"Communication files" in the Dartmouth Time Sharing System have been cited
as a predecesssor of Unix pipes, although we at Bell Labs were unaware of
the DTSS feature when pipes were first implemented. In fact, communication
files more directly foreshadow Plan 9 than they do Unix.
Unlike Unix processes, which need not be aware that they are talking to
pipes, the process at one end of a communication file, designated as
"master", must be aware that it is a communication file. The master end
controls the semantics of reads, writes and seeks(!) issued at the other
end. Because of this asymmetry, a communication file cannnot serve as a
pipe between pairs of unprepared processes. A pipe could be simulated in
DTSS by a master process that relays flow between communications files
connected to arbitrary end processes, but that seems never to have been
done.
Communication files are a closer antecedent to Plan 9. A master process's
controls correspond to the part of Plan 9's foundational 9P protocol that
handles open files. Though I don't think there's an actual ancestral
connection, this likeness strengthens DTSS's claim to fame and extends
their lead to nearly a quarter century.
Linux has adopted surface features of Plan 9 like union directories,
append-only files and system data access via file interfaces. Meanwhile
Plan 9's revolutionary realization of what Vic Vyssotsky called
distributable computing has not caught on. In distributable computing, the
physical location of processes does not affect their logical interaction.
In today's distributed computing, though, there is a world of difference
between how processes interact remotely and locally. When will the crevasse
between the possible and the normal be bridged?
Doug
Having recently read about the playful literary consortium, Oulipo, I am
reminded of their term for little-known antecedents of their revolutionary
works: "anticipatory plagiarism".
Long before there was Markdown, there was a similar Unix tool. I remember
reading about it before the Internet was popular, probably mid-to-late
1980s. I may have read about it in “Communications of the ACM”.
It was designed to let secretaries compose memos, without learning the dot
commands of troff or nroff. If you indented a space or two, it started a
new paragraph. If you indented several spaces, it centered the line; very
similar to Markdown in concept. It generated a file that could be fed into
troff.
I was thinking it might have been part of the System V Documentors
Workbench, but I read through the doc for it and could not find anything
like that.
Does anyone remember this?
Thanks!
Hi all, Edouard asked me to pass this e-mail on to both TUHS and COFF lists.
Cheers, Warren
----- Forwarded message from Edouard Klein <edouardklein(a)gmail.com> -----
Subject: History tract during the next IWMP9 in Paris next May
Date: Thu, 29 Aug 2024 22:46:30 +0200 (1 week, 4 days, 19 hours ago)
Dear Unix history enthusiasts,
The 11th International Workshop on Plan 9 will be held in Paris on May
22-24 2025.
One of the focus area this year will be Plan 9's history and its
influence on later computer science and industry trends.
The history team at the CNAM (where the conference will be held) has
agreed to help us prepare for the event and stands ready to record oral
histories, or any other format that would make the participants happy.
They had organized in 2017 a "colloque" at which Clem spoke (and I
listened somewhere in the audience) on UNIX:
https://technique-societe.cnam.fr/colloque-international-unix-en-europe-ent…
I will keep the list posted as our efforts pan out, but I thought I'd
get the word out as soon as possible.
I you have historical resources on Plan 9 or Inferno, or are reminded of
any interesting tidbits, you can also share them here, as this list is
already recognized by historians as a legitimate source.
The program committee members, many (if not all) of whom roam this very
list, would welcome any proposal or contributions in this area :)
The CfP is at:
http://iwp9.org/
Looking forward to read what you care to share, or to seeing you in
person in Paris,
Cheers,
Edouard.
----- End forwarded message -----
> From: Kevin Bowling
> https://gunkies.org/wiki/BSD/386 and the parent page on seem to suggest
> it originated off Net/2 directly.
I wouldn't be putting too much weight on what that page says; most of the
*BSD pages were done by people I don't know well, and who might have gotten
details wrong
I myself later just tried to quickly, without much effort, work out roughly
what the relationship was between those *BSD systems, based on what other
people had written. E.g the now-'BSD/OS' page was originally at '386/BSD',
and I seem to have worked out that it's correct name was BSD/OS and moved it
there. The BSD/386 page is probably roughly correct, since it contains a scan
of a contemporary ad for it.
(So confusing that '386BSD' is something different from 'BSD/386'. Was there ever
actually a '386/BSD'?)
Someone who knows the early history of all the *BSD systems (as in, you lived
through all that) is welcome, nay invited, to fix any errors therein.
Noel
So I was flipping through a System V software catalog from Fall 1984 and among
the many AT&T Bell Laboratories items is the "COBOL Syntax Checker".
From the text:
---QUOTE---
The COBOL Syntax Checker allows programmers to edit and check the syntax of COBOL
programs before they are transmitted to mainframes for compilation and execution.
The software increases the chances of a 'clean' compilation and execution and
reduces the chance of a program being rejected due to syntax and simple semantic
errors. As a result, expensive mainframe CPU time is reduced.
The COBOL Syntax Checker processes a COBOL source program and produces three
listings:
1. a diagnostic listing,
2. a cross-reference listing,
3. a source listing.
---END QUOTE---
There are two distributions listed, a C binary distribution for SVR2 for the
3B20 for $2000 and a C source distribution for SVR2 for the VAX 11/780 for $7500,
both listed as released 2Q84.
Some quick Googling only offers up additional catalog and magazine mentions.
To me this sounds like a linter with some extra bits. Does anyone have any
recollections of this software or know if there's much likelihood of the software
itself or any documentation surviving?
Thanks for any insights!
- Matt G.
> From: Noel Chiappa
> Was there ever actually a '386/BSD'?
I decided (for not particular reason) to take a quick read through Marshall
Kirk McKusick's "Twenty Years of Berkeley Unix From AT&T-Owned to Freely
Redistributable":
https://www.oreilly.com/openbook/opensources/book/kirkmck.html
and he refers to Jolitz's system as "386/BSD" (apparently incorrectly). (So
there's a lesson there; even people who '_were_ there' can occasionally get it
wrong - something that professional historians are well aware of. I have a
funny story of my learning that lesson, here:
http://www.chiappa.net/~jnc/nontech/tmlotus.html
in a totally different technical area.)
I have yet to see a _scan_ of contemporary documentation (I believe nothing
that isn't a contemporary _physical artifact_) that confirms it was actually
named "386BSD", but that does seem to be the name as given in the Dr. Dobbs
series on it. That series confirms that it was based directly on the 'Net/2'
BSD release (although 'diff's on the sources are probably the most reliable
proof).
Noel
I have been playing around a bit with this in VirtualBox.
Maybe due to the backing company, I had assumed it was a commercial FreeBSD
variant. But looking a bit harder, it seems like it was a distinct strain
of 386bsd like NetBSD and FreeBSD. There seems to be scant information
about it online. Does anyone know if its story is told somewhere?
Regards,
Kevin
hello everyone,
i recently came across a little window manager, written in Alef, that
i've had in my /tmp folder
for the last five years. it's called Y (probably as a response to X),
and i grabbed it from
9gridchan's public griddisk; run by the late mycroftiv until 2022.
i think it must've been an experimental project by Pike, Rosenthal or
Tom Duff, but i can't find
any documentation about it anywhere. i'd love to know if any of you
remembers this, and if so,
would you share the story behind it?
i uploaded the source code here: http://antares-labs.eu/isometric/Y.tgz
and it runs on 2nd ed plan 9 without issue (see the attached screenshot.)
cheers!
-rodri
> From: Kevin Bowling
> I wonder if we should collect resources like this on a wiki page or
> something?
My habit on the CHWiki is to have the articles on subjects where there is a
lot of documentation online is to have the articles mostly be 'executive
summeries', and corral the links to the stuff online to a section at the end,
so that people who want to see the gory details can look at the original
documentation. See, for example:
https://gunkies.org/wiki/AN/FSQ-7
That works well, even for material that later goes 404, because with the URL,
one can generally find it later in the Internet Archive (things like Google
won't find things that are only there).
Don't ask me to add them, though; I still haven't found time to add the links
to the BSD/OS stuff you found!
Noel
> From: Rodrigo Lopez
>> Google tells me: https://www.y-windows.org/
> from .. the code, that one has nothing to do with this.
It actually makes sense that there are two separate ones called 'Y'. The X
Window System was a descendant of the W window system, so if someone wanted
to do another one, 'Y' was the obvious namee to pick. All it needs now is two
separate people who decide they want to do a window system... voila!
Noel
On Aug 31, 2024, at 11:16 AM, Jaap Akkerhuis <jaapna(a)xs4all.nl> wrote:
>
>> On 31 Aug 2024, at 20:09, Angel M Alganza <ama(a)ugr.es> wrote:
>>
>> On 2024-08-31 11:59, Rodrigo G. López wrote:
>>
>>> i'd love to know if any of you remembers this, and if so, would you share the story behind it?
>
> Google tells me: https://www.y-windows.org/
This is likely a different Y window sys than what Rodrigo found,
which is written in Alef and runs on 2nd ed plan9. Rodrigo may
want to trawl through 9fans mailing list/usenet group archives
or ask there.
Hey there folks, I'm going to find myself in Berkeley for the day this
week and was curious if the buildings where the CSRG group worked are
still standing? Thought it would be a fun place to visit after hacking
on BSD for all these years.
Cheers,
-pete
--
Pete Wright
pete(a)nomadlogic.org
> On Mon, 12 Aug 2024 01:16:41 -0700,"Erik E. Fair" <fair-tuhs(a)netbsd.org <mailto:fair-tuhs@netbsd.org>> wrote:
>
> The main campus computer center was in the basement, but they charged by the CPU/second, so only classes used those systems - in my day (1980-1983), the computer center had a CDC 6400 and six or seven DEC PDP-11/70s.
The CDC 6400 finally went away in September 1982:
September 3rd, 1982
Memo to: Computing Affairs Staff
From: M.Stuart Lynn, Director
Subject: CDC 6400 Departure
The CDC 6400 is no more. ...
https://caltss.computerhistory.org/archive/820903-cdc-6400-departure-msl.pdf
