[TUHS} Running V8 ...

[TUHS} Running V8 ...

[Doug McIlroy]

> How realistic would the experience be to actually running the system
> described in the Unix Programming Environment [v8] if it's actually
running > BSD 4.1... Thanks for any insights y'all might have on this.

This question bears on a recent thread about favorite flavors of Unix. My
favorite flavor is Universal Unix, namely the stuff that just works
everywhere. That's essentially what K&P is about.

That's also what allowed me to use a giant Cray with no instruction
whatsoever. And to do everyday "programmering" on the previously
inscrutable Macintosh, thanks to OS X.

The advent of non-typewriter input put a damper on Universal Unix. One has
to learn something to get started with a novel device. I am impressed,
though, by the breadth of Universal Unix that survives behind those
disparate facades.

[TUHS} Running V8 ...

[Don Hopkins]

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


> On 16 Oct 2017, at 13:58, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> How realistic would the experience be to actually running the system
>> described in the Unix Programming Environment [v8] if it's actually
> running > BSD 4.1... Thanks for any insights y'all might have on this.
> 
> This question bears on a recent thread about favorite flavors of Unix. My
> favorite flavor is Universal Unix, namely the stuff that just works
> everywhere. That's essentially what K&P is about.
> 
> That's also what allowed me to use a giant Cray with no instruction
> whatsoever. And to do everyday "programmering" on the previously
> inscrutable Macintosh, thanks to OS X.
> 
> The advent of non-typewriter input put a damper on Universal Unix. One has
> to learn something to get started with a novel device. I am impressed,
> though, by the breadth of Universal Unix that survives behind those
> disparate facades.

I love the OpenFirmware “L1-A Forth” built into SparcStations. It has the “SEE” word, that decompiles FORTH words and disassembles FORTH primitives. You can start with “SEE SEE”, and then recursively climb down and see each of the words and primitives that defines it, or anything else! 

-Don

[TUHS} Running V8 ...

[Clem Cole]

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

On Mon, Oct 16, 2017 at 7:58 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> This question bears on a recent thread about favorite flavors of Unix. My
> favorite flavor is Universal Unix, namely the stuff that just works
> everywhere. That's essentially what K&P is about.


​+1 I would add, to me that's what the 'standardization' efforts were
really about as a >>user<<.   To settle on the minimum subset needed to the
get the job do and stop adding 'sugar' because you could.​  The ISVs wanted
to maximize (SPEC1170 et al), but to me 'Universal' was what do I really
need/use every day.

In fact, its why I switch from EMACS to vi early in my UNIX career.   Vi
and (ed) were everywhere (K&P style).  EMACS was not and if I found a
flavor for that system, it was always 'different.'  I could sit down at
anything from MS-DOS to a Cray and stuff worked well enough that I could do
what I needed to do.  [I'm not a great fan of "vim" for that reason either
BTW -- I just want the basics to 'be there' and 'be reliable' - do what I
want without me having to rethink].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171016/b64274eb/attachment-0001.html>

[TUHS} Running V8 ...

[Will Senn]

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

On 10/16/17 6:58 AM, Doug McIlroy wrote:
> The advent of non-typewriter input put a damper on Universal Unix. One has
> to learn something to get started with a novel device. I am impressed,
> though, by the breadth of Universal Unix that survives behind those
> disparate facades.

Doug,

I totally agree. In 2005, I bought a Powerbook because I liked the 
aesthetics of it over Windows laptops of that era. I had been using 
Linux for fun but not without a significant bit of pain since the early 
1990's (0.9 kernel), but never seriously. When I opened up my first 
terminal on the Powerbook, I began to love my Powerbook and Unix - 
beauty AND power! As a result of that exposure, I'm comfortable with 
pretty much any *nix and am only frustrated when distributions mess with 
the core tools or leave out system documentation.

To digress a little, my recent exposure to V6 an V7 have only served to 
reinforce my appreciation for the universal aspects of Unix. How is it 
remotely possible that OS's that are approaching 40 years old have so 
much in common with their modern ancestors? The thing that most 
impresses me though, is the durability of the documentation. I was 
reading K&R's "Programming Unix" in volume 2 of the V7 programmer's 
guide. When I came across a concise and informative description of fork:

    Now  we  will  show  how  to regain  control  after  running a 
    program  with execl or execv.   Since  these  routines simply 
    overlay  the new  program  on  the  old  one,  to  save the  old 
    one  requires  that  it  first  be  split  into  two copies;  one  of
    these  can  be  overlaid,  while  the  other  waits  for  the new, 
    overlaying  program  to  finish.   The  splitting  is
    done  by  a  routine  called fork.

Nowadays, fork is usually discussed first, with exec seeming to be 
included as a second class citizen (see Rago & Stevens APUE), which to 
me always seemed a little inverted. The K&R note shows exec first and 
then fork - seems logical - which is how most of K&R and most of the V6 
& V7 documentation is - too bad most of today's documentation is either 
deemed unnecessary (vis a vis the intuitiveness of the Mac/iPhone or is 
of poor quality.

Your note makes me wonder what you thought of Plan 9's mouse input, or 
what K&R thought of it, about "having" to use a mouse for input. I'm 
playing with Plan 9 on my raspberry pi 2 model b and while it seems to 
work, I find the interface constantly getting in the way of my mind and 
fingers :). You even have to use the mouse to wake the screen up! Don't 
get me wrong, I find Plan 9 to be quite interesting and parts of it  
conceptually elegant, but not the interface!

Later,

Will




-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

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

[TUHS} Running V8 ... [ really basic tools ]

[Jon Steinhart]

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

Clem Cole writes:
> On Mon, Oct 16, 2017 at 7:58 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>     This question bears on a recent thread about favorite flavors of Unix. My
>     favorite flavor is Universal Unix, namely the stuff that just works
>     everywhere. That's essentially what K&P is about.
> 
> +1 I would add, to me that's what the 'standardization' efforts were really
> about as a >>user<<.   To settle on the minimum subset needed to the get the
> job do and stop adding 'sugar' because you could.  The ISVs wanted to maximize
> (SPEC1170 et al), but to me 'Universal' was what do I really need/use every
> day.
> 
> In fact, its why I switch from EMACS to vi early in my UNIX career.   Vi and
> (ed) were everywhere (K&P style).  EMACS was not and if I found a flavor for
> that system, it was always 'different.'  I could sit down at anything from
> MS-DOS to a Cray and stuff worked well enough that I could do what I needed to
> do.  [I'm not a great fan of "vim" for that reason either BTW -- I just want
> the basics to 'be there' and 'be reliable' - do what I want without me having
> to rethink].

I have a similar and maybe even more extreme position.  When I was a manager
I placed restrictions on the tools and customizations for members of my team.
My goal was to make sure that any team member could go over to any other team
member's desk and get stuff done.  I strongly pushed vi as an editor because
it was "standard"; as Clem said every emacs seemed to be different.  I prohibited
the redefinition of the vi key bindings and also any shell aliases that replaced
standard commands.  Nothing worse for productivity than going to help out a
colleague and then discovering that they the redefined "ls" as "rm"!

Jon

Running V8 ... [ really basic tools ]

[Ian Zimmerman]

On 2017-10-16 09:39, Jon Steinhart wrote:
> 
> I have a similar and maybe even more extreme position.  When I was a
> manager I placed restrictions on the tools and customizations for
> members of my team.  My goal was to make sure that any team member
> could go over to any other team member's desk and get stuff done.  I
> strongly pushed vi as an editor because it was "standard"; as Clem
> said every emacs seemed to be different.  I prohibited the
> redefinition of the vi key bindings and also any shell aliases that
> replaced standard commands.  Nothing worse for productivity than going
> to help out a colleague and then discovering that they the redefined
> "ls" as "rm"!

As an Emacs user, obviously I disagree :P

How many keystrokes are needed to do a given edit with Emacs versus vi,
and in particular such an artificially frozen version of vi?

This is not just laziness (though as we know laziness is a virtue in
programmers).  It's a health issue with RSI.

And I disagree with restrictions on shell tools as well.  They may
have made for a uniform predictable environment on one project and one
job.  But what if an engineer moved on?  Do you really expect him to
reinvent the wheel all over again everytime?

As an example of the level of tool I mean: today I decided I had to stop
using the perl-rename program in my scripts, because different
distributions install it under different names.  It is very painful to
do this: there is no such tool in basic Unix.  Of course I can hack my
own in maybe 10-15 lines of shell code, but that is exactly the kind of
thing you would prohibit.

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

Running V8 ... [ really basic tools ]

[Jon Steinhart]

Ian Zimmerman writes:
> On 2017-10-16 09:39, Jon Steinhart wrote:
> > 
> > I have a similar and maybe even more extreme position.  When I was a
> > manager I placed restrictions on the tools and customizations for
> > members of my team.  My goal was to make sure that any team member
> > could go over to any other team member's desk and get stuff done.  I
> > strongly pushed vi as an editor because it was "standard"; as Clem
> > said every emacs seemed to be different.  I prohibited the
> > redefinition of the vi key bindings and also any shell aliases that
> > replaced standard commands.  Nothing worse for productivity than going
> > to help out a colleague and then discovering that they the redefined
> > "ls" as "rm"!
> 
> As an Emacs user, obviously I disagree :P
> 
> How many keystrokes are needed to do a given edit with Emacs versus vi,
> and in particular such an artificially frozen version of vi?
> 
> This is not just laziness (though as we know laziness is a virtue in
> programmers).  It's a health issue with RSI.
> 
> And I disagree with restrictions on shell tools as well.  They may
> have made for a uniform predictable environment on one project and one
> job.  But what if an engineer moved on?  Do you really expect him to
> reinvent the wheel all over again everytime?
> 
> As an example of the level of tool I mean: today I decided I had to stop
> using the perl-rename program in my scripts, because different
> distributions install it under different names.  It is very painful to
> do this: there is no such tool in basic Unix.  Of course I can hack my
> own in maybe 10-15 lines of shell code, but that is exactly the kind of
> thing you would prohibit.

Emacs is a lot more "stable" these days; there aren't as many versions
floating around.

No way to answer your question about keystrokes; it really depends on what
you're doing.  I would guess that it's a wash.  Of course, this depends on
your point of view.  I remember a big argument decades ago with Ed Post of
Real Programmers Don't Use Pascal fame.  He was claiming that emacs was
superior because it was "modeless".  Someone else in the car stumped him by
asking the question "Isn't holding down the meta key a mode?"  So vi may
require hitting escape, but emacs is very heavy on the shift key usage so
as I said, it's likely a wash.

I didn't prohibit people from creating their own tools and shortcuts.
I prevented them from using existing utility names for their tools and
shortcuts.  That meant that when they asked someone else in the group
to take a look at a problem that that person could actually do so instead
of causing damage.

And yes, I would prohibit you making a program called perl-rename if it
did something different than perl-rename.  I wouldn't care if it was
identical.  Not sure why you wouldn't set your path to find it wherever
it was or just make a link.

Jon

Running V8 ... [ really basic tools ]

[Ian Zimmerman]

On 2017-10-16 12:28, Jon Steinhart wrote:

> I didn't prohibit people from creating their own tools and shortcuts.
> I prevented them from using existing utility names for their tools and
> shortcuts.  That meant that when they asked someone else in the group
> to take a look at a problem that that person could actually do so
> instead of causing damage.

I see - I have misunderstood you.  No problem with this policy.

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

UNIX version 2*pi

[Don Hopkins]

UNIX version 2*pi

[Dave Horsfall]

On Tue, 17 Oct 2017, Don Hopkins wrote:

> McGill University EE UNIX lab systems administration, PDP-11 running 
> UNIX version 2*pi (>6, <7, irrational)

Sounds like the one I was maintaining at UNSW: Edition 6, with the bits of 
Edition 7 that would fit on an 11/40 and 11/60, plus local AUSAM stuff.

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

[TUHS} Running V8 ...

[Tony Finch]

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

Don Hopkins <don at DonHopkins.com> wrote:
>
> I love the OpenFirmware “L1-A Forth” built into SparcStations. It has
> the “SEE” word, that decompiles FORTH words and disassembles FORTH
> primitives. You can start with “SEE SEE”, and then recursively climb
> down and see each of the words and primitives that defines it, or
> anything else!

Nice. OpenFirmware was also used in PowerMacs and in IBM POWER systems.
I thought it was a great shame that Intel didn't adopt OpenFirmware but
instead created EFI.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet: Variable 3 or 4, becoming east or southeast 5 or 6. Moderate
or rough, occasionally slight. Occasional rain. Good, occasionally poor.

[TUHS} Running V8 ...

[Larry McVoy]

On Tue, Oct 17, 2017 at 12:47:53PM +0100, Tony Finch wrote:
> Don Hopkins <don at DonHopkins.com> wrote:
> >
> > I love the OpenFirmware ???L1-A Forth??? built into SparcStations. It has
> > the ???SEE??? word, that decompiles FORTH words and disassembles FORTH
> > primitives. You can start with ???SEE SEE???, and then recursively climb
> > down and see each of the words and primitives that defines it, or
> > anything else!
> 
> Nice. OpenFirmware was also used in PowerMacs and in IBM POWER systems.
> I thought it was a great shame that Intel didn't adopt OpenFirmware but
> instead created EFI.

You and me both.  I always thought forth was a little weird, not bad
weird, just weird.  But I had worked on a forth system before, done
some programming in it, so I could deal.

But when I met EFI I yearned for the good old forth boot proms :(

My guess is that Mitch wanted too much money for Intel to go for it,
Intel is super super cheap.

[TUHS} Running V8 ...

[Don Hopkins]

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

The OLPC XO-1 also used OpenFirmware! 

Mitch Bradley ported and extended Forthmacs to support secure auto-boot, power management, and used it for debugging the OLPC’s unique hardware and operating system. 

http://wiki.laptop.org/go/Open_Firmware <http://wiki.laptop.org/go/Open_Firmware>

>Open Firmware is the hardware-independent firmware (computer software which loads the operating system) that the XO runs.

>It was developed by Mitch Bradley at Sun Microsystems, and used in post-NuBus PowerPC-based Apple Macintosh computers (though it has been dropped with Apple's transition to Intel processors), Sun Microsystems SPARC based workstations and servers, IBM POWER systems, and PegasosPPC systems, among others. On those computers, Open Firmware fulfills the same tasks as BIOS does on PC computers.

>For example Fedora and Debian use the YaBoot BootLoader for Open Firmware.

>The Open Firmware user interface includes a FORTH-based shell interface. FORTH is a powerful high level language that is remarkably compact. A complete Forth development environment including compiler, decompiler, assembler, disassembler, source level debugger, and assembly language debugger is present in the XO boot ROM (SPI FLASH). With the Open Firmware Forth system, you can directly access all of the hardware devices on the XO, use built-in functions like selftest diagnostics and games, and even write complete applications, without needing any external tools. The bulk of Open Firmware is written in Forth, so the source level debugger can be used to debug Open Firmware itself.

http://wiki.laptop.org/go/OFW_FAQ <http://wiki.laptop.org/go/OFW_FAQ>

OpenFirmware also has its own song to the tune of the Jetson’s theme, and Mitch’s rendition is much more mellifluous than RMS singing his Free Software song:

https://web.archive.org/web/20060213143046/http://bananajr6000.apple.com/1275/misc/ofwsong.au <https://web.archive.org/web/20060213143046/http://bananajr6000.apple.com/1275/misc/ofwsong.au>  

I used the 68K and SPARC versions of Mitch’s “Forthmacs” system under SunOS. 

It had a re-targetable meta-compiler, portably supported targets targets with 16 bits, 32 bits, different byte orders, could dynamically link and call C libraries, also ran in stand-alone mode, could be burnt into ROM and run in framebuffer memory, and and which he later developed into OpenFirmware). 

I worked with Mitch as a summer intern at Sun in ’87, integrating his other pure C “CForth" system into a circuit editor called “CADrioid”. At the University of Maryland, I used Forthmacs to develop a dynamic memory allocator (which I would run diagnostics on in mmap'ed framebuffer memory as a screen saver), a FORTH extensible X10 window manager with pie menus called “piewm” (kind of like NeWS for X10 with FORTH instead of PostScript), a hypermedia brower for NeWS called “HyperTIES”, and a cellular automata machine simulator compatible with Toffoli and Margolus’s CAM6 hardware and Forth rule definitions published in their book (which I’ve since rewritten in JavaScript).

Forthmacs:
http://donhopkins.com/home/archive/forth/forthmacs-doc/ <http://donhopkins.com/home/archive/forth/forthmacs-doc/>
http://www.donhopkins.com/home/code/allocate.f.txt <http://www.donhopkins.com/home/code/allocate.f.txt>
http://www.art.net/~hopkins/Don/lang/forth.html <http://www.art.net/~hopkins/Don/lang/forth.html>

piewm:
http://www.donhopkins.com/home/code/Xlib.forth.txt <http://www.donhopkins.com/home/code/Xlib.forth.txt>
http://www.donhopkins.com/home/code/fuwm-main.forth.txt <http://www.donhopkins.com/home/code/fuwm-main.forth.txt>
http://www.donhopkins.com/home/code/hacks.forth.txt <http://www.donhopkins.com/home/code/hacks.forth.txt>

HyperTIES:
http://www.donhopkins.com/home/ties/fmt.f <http://www.donhopkins.com/home/ties/fmt.f>

CAM6:
http://www.donhopkins.com/home/code/cam.f.txt <http://www.donhopkins.com/home/code/cam.f.txt>
http://www.donhopkins.com/home/code/compile.f.txt <http://www.donhopkins.com/home/code/compile.f.txt>
http://www.donhopkins.com/home/code/rules.f.txt <http://www.donhopkins.com/home/code/rules.f.txt>
https://github.com/SimHacker/CAM6/blob/master/javascript/CAM6.js#L41 <https://github.com/SimHacker/CAM6/blob/master/javascript/CAM6.js#L41>

Here’s an old post extolling the virtues of CForth and Forthmacs, that I posted in response to a question on comp.lang.forth back in ’89.

-Don

https://groups.google.com/forum/#!msg/comp.lang.forth/cAFn_jDDu50/t8wEQeCe4pYJ <https://groups.google.com/forum/#!msg/comp.lang.forth/cAFn_jDDu50/t8wEQeCe4pYJ>

From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.lang.forth
Subject: Re: Forth for VAX, Sun
Summary: Bradley Forthware: 4444 is the number of the best!
Keywords: sun, unix, cforth
Date: 10 May 89 11:06:40 GMT
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab

In article <24... at agate.BERKELEY.EDU> w... at garnet.berkeley.edu (William Baxter) writes:

>To my inquiry about Forth systems for the VAX and Sun, I received two
>responses, both mentioning the same programs.  
>
>C Forth 83: 
>
>Runs on both VAX (VMS or Unix) and Sun, and in fact on just about every
>computer with a half decent C compiler.  The price is $50, which gets
>you C kernel source, Forth utilities source, on-line documentation, and
>a printed glossary.  It's a Forth-83 dialect with 32-bit stacks, real
>files, and several utilities.

I used a version of CForth when I was working for Mitch, summer before
last at Sun. It's a very nice Forth system, and quite portable. You
can define your own Forth primatives in C, by adding them to this big
switch statement! We linked CForth together with a schematics CAD
system (CADroid), so you could call the CADroid commands from Forth,
and then we wrote a user-friendly extension language in Forth. It
accepted postfix commands, and prompted for arguments in English. You
could interactivly define macros for laying out circuit bodies and
wiring them up, by typing commands, pointing with the mouse, selecting
from menus, pressing function keys, putting in your own prompts for
arguments, bindings macros to keys, etc. It also supported interactive
loops and conditionals. Mitch came up with a really neat unified
syntax for them:

condition? [ <stuff to do if true> ]

condition? [ <stuff to do if true> ][ <stuff to do if false> ]

count [ <stuff to do in a loop> ]

count [ <stuff to do in a loop> ][ <stuff to do if count is 0> ]

The last one (the loop-with-an-else-clause) was particularly useful
because it could be used instead of the otherwise common construct:
        
count 0= [ 
  <stuff to do if count is 0> 
][ 
  count [ <stuff to do in a loop if count isn't 0> ] 
]

The way these constructs worked interactivly (and during macro
definition) was that you started a loop by typing a count and a [, and
it would execute commands as you typed them in, the first time through
the loop, and once you typed the matching ] (they nested!), it would
re-execute the now-compiled loop count-1 more times, real fast.  The
conditional form had just the same behavior: It would either execute
what you typed as you typed it, or ignore your commands, according to
the condition (|-1| or 0).

So when we carefully consider all of these facts, we are forced
to ask ourselves the following question:  What was today's topic
again? Wait, I remember:  Bradley Forthware.

>
>Sun Forth:
>
>Runs on any Sun 2, Sun 3, or Sun 4, and also on most non-Sun 680x0 Unix
>machines.  The price is $200, which gets you the binary, source code,
>metacompiler, 200+ page printed manual, and a ton of utilities (for
>instance, it can load C object files into the Forth dictionary and
>execute the C subroutines as Forth words.  It also has a disassembler
>and both high level and assembly language debugging tools.)
>
>

Sun Forth is an excellent, rich, fast, fantastic Forth system! I've
used it for all kinds of things, on the Sun-2, the Sun-3 (68K), and
the Sun-4 (SPARC). It also runs on the Atari ST, and the Mac, I think.
(I haven't used those versions) On the Sun-2, I had a good time using
Sun Forth to figure out how to frob the CG1 color graphics card, by
printing out the cg1reg.h file, mmap'ing in the device registers, and
frobbing around with them. (I finally discovered that you could only
write to the color table during vertical retrace, when I got mad and
frustrated that my unsucessful attempts at loading the color table
were taunting me by kinda sorta working occasionaly, and I decided to
punish it by running it in an infinite loop. My color table slowly
faded into view!)

It's got a kick-ass decompiler, that pretty prints forth code and
disassembles primatives! Who needs manuals or source code? (But you
get them anyway! ;-) There are a lot of other nice features, like an
emacs-like command line editor, with history, and command completion
over your Forth vocabularies. It's very well interfaced with Unix. It
also runs stand-alone without Unix. Mitch uses it in the hardware lab
at Sun to debug decadent wayward hardware, by dropping in a Forth ROM,
talking to it through a serial port, and running it in the framebuffer
memory! [It looks real neat munching away on the screen, and it can
work even when the main memory is fried!] The list of features goes on
and on...

The ability to dynamicly load in C object files makes Sun Forth useful
for a whole lot of things you'd normally never think of (or at least
admit to thinking of) using Forth for! On the Sun-3, I linked in a
version of the X10 "uwm" window manager I had modified to do pie
menus. I could call all the window manager functions from Forth,
passing them arguments on the stack, and I could bind mouse actions
and menu selections to Forth functions. I moved the main control loop
that dispatched events into Forth, so I had a crack at the events
before passing them on to uwm. Forth could could respond to window
system events, track the mouse, pop up menus, change the cursor, move
windows around, etc... It had complete access to all the window
manager function and data structures. One thing I used this system for
was to implement an experiment that Jack Callahan designed, comparing
pie menus with linear menus. (A paper describing the experiment is in
the CHI'88 conference proceedings.) The Forthified window manager
administered the experiment by randomizing the order in which the
menus were presented, prompting the test subject to select a certain
item from each menu, and recording the menu selections made and the
time each took, etc...  The Forth system was very useful for
prototyping different mouse tracking techniques for pie menus -- it
would have been very painful to have to go through the old
edit-compile-link cycle every time I wanted to tweak something! NeWS
is an example of how useful it is to have a window manager with an
interactive extension language! (But I didn't have NeWS yet.) X window
managers are big messy programs (even in the X10 days!), but I was
able to plug X10 uwm right into Sun Forth, and start hacking away --
instant extension language! (Though uwm wasn't exactly /designed/ for
that kind of abuse!)

I've also used Sun Forth for other projects, like prototyping a
hypertext markup language interpreter (NeWS HyperTIES), and as a
Cellular Automata Machine rule compiler. I cloned Tom Tofoli's CAM
rule language in Sun Forth, and wrote a tool for computing and
displaying them in NeWS. Not anything like as fast as the real CAM
hardware [256x256 cells @ 60 frames/sec], but if you feed it the right
rules and initial conditions, and wait a while, it will make lots of
pretty patterns that take up lots of disk space.

>Both are available from:
>
>Mitch Bradley
>Bradley Forthware
>P.O. Box 4444
>Mountain View, CA 94040
>

Mitch swears the PO box number was totally coincidental!

>----
>Disclaimer:  Endorsement?  I haven't even used them.
>
>William Baxter
>
>ARPA: web@{garnet,brahms,math}.Berkeley.EDU   
>UUCP: {sun,dual,decwrl,decvax,hplabs,...}!ucbvax!garnet!web

Disclamer: Of course I'm quite biased, since I worked with Mitch for a
summer, and I just love his Forth system. But so does Mitch, or it
wouldn't have so many great features!

        -Don



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171017/7334a939/attachment-0001.html>

UNIX version 2*pi

[Ron Natalie]

One of my predecessors at JHU decided 6.06 was a nice symmetrical number and
stuck the version there through many kernel changes.   When he left, our
release numbers started forward again.

The BRL/JHU kernel was based on V6.    It had a kludge to allow more that
256 users but eventually, we widened the UID/GID to 16 bits each.   We then
added a the ability to mount either V6 or V7 file systems (we had a lot of
removable V6 FS media).

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Tuesday, October 17, 2017 2:09 AM
To: The Eunuchs Hysterical Society
Subject: Re: UNIX version 2*pi

On Tue, 17 Oct 2017, Don Hopkins wrote:

> McGill University EE UNIX lab systems administration, PDP-11 running 
> UNIX version 2*pi (>6, <7, irrational)

Sounds like the one I was maintaining at UNSW: Edition 6, with the bits of
Edition 7 that would fit on an 11/40 and 11/60, plus local AUSAM stuff.

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

UNIX version 2*pi

[Dave Horsfall]

On Tue, 17 Oct 2017, Ron Natalie wrote:

> The BRL/JHU kernel was based on V6.    It had a kludge to allow more that
> 256 users but eventually, we widened the UID/GID to 16 bits each.   We then
> added a the ability to mount either V6 or V7 file systems (we had a lot of
> removable V6 FS media).

We dropped the GID (nobody used them) and glued it onto the UID, thus 
making it 16-bit.

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

UNIX version 2*pi

[Ron Natalie]

JHU ownership was a bit more of a kludge.    If your GID was less than 200,
then everything worked the normal UNIX way.
If your GID was greater than 200, then it was also taken to be part of the
UID.   The student accounts would have a GID based on the class that they
were in.

Of course, newgrp, setuid, setgid (and their related bits) had to be changed
to avoid secuirty fun and games.    I spent a lot of time trying to break
that when I was just a student.
When I became one of the system programmers, I spent a lot of time trying to
fix those holes.

-----Original Message-----


We dropped the GID (nobody used them) and glued it onto the UID, thus making
it 16-bit.

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