HP3000-L Archives

February 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Thu, 24 Feb 2000 23:53:31 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (359 lines)
Jack Bailie writes:

> After following this thread with great interest (I agree with Stan and
>  friends) I find it very difficult to believe Wirt's contention that he
isn't
>  German.  (I.e. I live with one who is always right.)

Actually, if it's of interest, my family name is Danish. I never paid much
attention to that fact until I spent the "winter of my discontent" in Thule
AFB, Greenland, at nearly the top of the world, during the winter of 1966.
Because Greenland is a Danish territory, half of the population in Thule was
Danish, the other half American. The great problem was that you couldn't tell
a Dane from an American just by looking. You especially couldn't tell anyone
apart when they were wearing their "iron suits" (exceptionally well insulated
parkas, pants and mukluks), particularly so during the six months of pitch
blackness, at 100 degrees below zero, and winds that would scoot you across
the ice out toward oblivion that was the Greenland winter. People there
looked at your nametag on your parka and choose which language they spoke to
you. Half of everyone there was named Almar, Dagmar, Ottmar, etc., so Atmar
fit right in and I was constantly spoken to in Danish.

Nonetheless, I am pleased to report that they were about as kind and gentle a
people as I've ever dealt with, thus I've never had any problem in declaring
myself since to be Danish -- although in truth, I'm probably only 1/256th
Danish by now.

But, "Sieler," that's another story. That truly is a good German name :-).

Stan has sent me about a hundred private email messages several months ago on
the paste subject, but I truly couldn't figure out what the problem was from
his emails. Most of them started out with the endearing but subtle phrase: "I
don't mean to be insulting, but are you sick or something? Or just insane?
Just fix the #$%@$% paste problem!"

Stan and I have been friends for 20 years now, so I didn't take any offense
-- although I did hear that Stan confided in others at Allegro that he
thought that he had perhaps gone too far and finally made me mad. If I did
became a little grumpy, it was only due to the sheer volume of the e-mails
and the lack of information in each one.

However, I did make the mistake of showing a couple of Stan's emails to
Vickie, who is of (very recent) Sicilian extraction -- and who has brothers
:-), one of whom is a member of a NEST (nuclear emergency search teams) team,
the guys who fly full tilt across the desert, just inches off the ground, in
fully armed helicopters in a so-far-unnecessary requirement to recover "loose
nukes". Vickie was so mad that I couldn't even talk to her about
cut-and-paste for a month. In fact, it's still a delicate subject.

Nonetheless, the next version of QCTerm will have the paste operate as Stan
wants it. "Vox populi vox Dei" applies just as forcefully to software design
as it does to politics.

On a second, semi-related topic, Shawn mentioned one form of dichotomy
associated with the development of QCTerm (the bandwidth); I've noticed
another. I have always considered this a community development project from
the very beginning -- and do sincerely appreciate all of the comments and
suggestions that we've received. But what surprised me almost from day one is
the tone of many of the emails we get. In the fifteen years of selling a
product like QueryCalc -- for many thousands of dollars -- and now with over
a thousand users, no one has every yelled at us about anything. Indeed, the
most normal conversation tends to be that someone calls up and sheepishly
says that he would like us to modify QueryCalc, and that he would be pleased
to pay for it. Most normally, we just go ahead and modify QC -- if it's a
good idea -- and not charge for it.

However, with QCTerm, we've regularly receive emails demanding (with lots of
capital letters and !!!!!!!!!'s) that we change one thing or another. Some of
these emails border on abusive. Or they're threats, the threat being if we
don't change something, they won't use it -- for as much logical water as
that holds.

At first, this behavior greatly surprised me. In the end, however, I
ultimately decided that the individual correspondents must feel that because
they have no direct financial power over our decisions, in the sense that
they aren't paying us for anything, they quite likely believed that yelling
was their only recourse in order to get us to change QCTerm in some manner.

That isn't true. The rants aren't necessary. Let me say the same thing that
I've told our commercial customers for 15 years: "Everything you tell us is
written down, and everything you tell us is greatly appreciated. While we
can't guarantee that we will ever implement your suggestion, or if we do,
where it will lie in the priority list, I can guarantee you that everything
you say will be seriously considered -- and and will be regularly
reconsidered from time to time."

In the case of Stan's complaint, another person at Allegro wrote me a private
email several days ago, explaining the problem. That was legitimately the
first time I understood what Stan was saying (although it also later became
clear in the course of the discussion that everyone here read). There are a
great many ways to use a terminal, and to be absolutely honest, I had a
completely different vision in mind than Stan's usage, more akin to the
original intended use of HP2645's.

The people who originally put the HP2645's saw the possibilities of the
terminal becoming a very complete, very "intelligent" workstation/editor with
local storage capabilities. Indeed, HP even occasionally attempted early on
to sell the HP2645 as a word-processor-like device.

Moreover, because of that obvious possiblity, and at the invitation of the
local HP office, beginning in 1976, we took the HP2645 terminal and extended
its functionality into a full-function, standalone word-processor, with the
capacity to print at high-speed, either forwards or backwards, in
multi-columned right-justified, proportionally spaced text, with math and
Greek character-based equations intermixed into the text. In the original
version, we converted the two on-board tape drives into "stringy" discs,
complete with a file name directory at the beginning of each tape. In later
versions, when floppy drives became available, we developed interface cards
and software drivers to allow the much larger capacity and much faster
floppies to replace the function of the stringy tape-based discs. The System
2000 had a cut-and-paste clipboard, which I called "blockstore". Each
function key was the equivalent of a modern icon. And yet, after all of this,
the original HP2645 terminal behavior remained unmodified.

This morning, I scanned in a copy of one of our 20-year old brochures (from
ca. 1980) and put four of its six pages up on the web. The URL is:

     http://aics-research.com/sys2000.html

[The girl in the bottom picture is Kathy Kinzer (her maiden name at the time
of the picture). Kathy was in either late high school or early college at the
time of the picture. We sold about 200 System 2000's (at approx. $30,000 each
in today's money). Kathy assembled every one of them. She's now a high-priced
lawyer in Santa Fe and not nearly as bright and funny as she was when she was
assembling the word processors, but I suspect that's merely an occupational
hazard. Indeed, the only time that I ever see sparks of her old personality
is when she's around an HP2645 :-).]

The key to this kind of terminal usage is to be able to easily and
effortlessly switch between a local editing mode (LINE MODIFY) and and an
active connection to a host. Understand that's precisely what you're doing
every day with e-mail. You type and edit your text into a local edit window
-- and then once you have it as you want it, you transmit it to the host by
pressing the "SEND" button. For most of the time, you're in local edit mode.
Only ocassionally are you interactive with the host.

To a great degree, that's what I previously had in mind for QCTerm, at least
until the last few days. The line modify key was to be central to that usage.
In the original design of QCTerm, there were to be three separate screens,
(i) a Reflection-like terminal emulator, (ii) a graphical, browser-like
interface we originally called Quick-and-Pretty, but which has now been
renamed van Gogh, and (iii) an Excel-like presentation screen for QueryCalc
(but where all calculations remain completely on the HP3000). Everyone would
get (and actually gets now) all three screens, but you wouldn't see the
QueryCalc Display unless you were an actual customer.

While a terminal emulator's behavior is relatively well set (with the
possible exception of making it an excellent code editor), the uses for van
Gogh have expanded beyond anything we originally imagined. Indeed, we will
later this year convert over most of our own tutorials into van Gogh-based
PowerPoint-like slides, complete with voice narration, so that they can be
transmitted over the internet with some ease. Moreover, we want to make the
capacity to put these kinds of slides and tutorials together to be so simple
that anyone else can do it as easily and as well, whether you are an
individual, a large or small organization.

Nonetheless it is the original high-speed, elaborate, but much
simpler-than-VPlus forms mode that remains the primary design goal in van
Gogh. While most of you haven't seen any of that behavior yet, much of it is
working now and we should have it well set in concrete by mid-summer. The
goal in this mode is to make applications development on the HP3000 easy --
and to make it very difficult for a user to tell if he or she is using a
program running on a PC at his or her feet, or on an HP3000, three thousand
miles away.

Another attribute we've been actively working on is having QCTerm being
launched as a web browser's helper application. This too now works, although
we're not ready to release it. When we do, you will be able to click on a web
hyperlink (either text- or graphically-based), autolaunch QCTerm, have it
telnet into any host (HP3000 or not) anywhere in the world, sign on and
automatically launch an application, all in just a few seconds -- and then
terminate the QCTerm session & instance when the host's program quits. In
this case, the user may never realize that QCTerm is a terminal emulator,
because they will never see the terminal screen. To accomplish all of this,
all that the host that QCTerm is aiming at needs as far as communications
capabilities is telnet and anonymous FTP, and all the host's programming
language must possess is the capacity to accept input from the keyboard and
be able to write to the screen (which are obviously relatively prosaic
requirements).

QCTerm will remain free, now and forever, for your use, if you wish. Although
we're neuterizing QCTerm so that it will work on any host (that's the nature
of standards, and we might as well comply with them), the HP3000 will still
be its primary home and its preferred target.

Because we've been able to seamlessly merge van Gogh with the terminal
emulator, QCTerm now only has two "screens," the emulator and QueryCalc's
spreadsheet. However, based on the last few days' conversations, there will
now again be a third screen: a full-screen, full-function editor. I had
originally planned on putting this behavior into the terminal. Stan's
modification really won't change any plans for the terminal emulator; it's
just that it's become obvious that actually moving the editor functions out
of the emulator is the right thing to do.

Nonetheless, let me show you now, peeling back the mists of time, the ancient
sacred knowledge that was revealed to only the very few -- knowledge that has
now apparently been forgotten by the masses: the glories of the LINE MODIFY
key.

What follows is a brief demonstration of how the LINE MODIFY functionality
and BASIC were designed to intimately work together in an HP terminal. When
the HP3000 (and the HP1000) were first being assembled, everyone expected
BASIC to become the dominant language -- and HP put an enormous effort into
making the HP3000's BASIC extremely efficient and effective code. The HP2645
terminals were part of that effort. Who knew that anyone would actually
program in COBOL?

While any terminal emulator will work for most of this demonstration, QCTerm
will work for all of it. Telnet into 209.181.113.217, which is our 918DX.
Sign on as:

     :hello yourname,demo.qcterm

If you are using QCTerm, set the connection settings to "advanced telnet"
simply for increased responsivity.

At the colon prompt, type:

     :b

to get into the BASIC interpreter. Once there, type:

     >get qcobject

This code is an actual QueryCalc subprogram. There are about 200 of these
BASIC programs in QueryCalc, most of them much larger, so we're not giving
away much of the store here. There are also about 200 SPL driver routines,
each a small routine designed to extend the basic functionality of BASIC
itself.

Now press Cntl+Home twice quickly (within a quarter-second). This will home
and clear your terminal's screen. Now type:

     >list

What you'll see is 600 lines of BASIC code. BASIC is not only a compilable
interpreter, it also inherently has its own internal line-oriented editor.
When you type a line such as

     10 PRINT "Hello World"

this text will either replace the current line 10 (if one exists) or it's
inserted into the listing at the appropriate place based on the line number.

Now, the coup de gras: turn MODIFY ALL on. We'll leave it on for the
remainder of this demonstration. As has been previously mentioned, MODIFY ALL
is similar to LINE MODIFY, except that it stays on until you turn it off.
LINE MODIFY turns itself off after just one use.

In QCTerm, to set MODIFY ALL on, press F9 (system keys), then F4 (modes key),
and finally F2 (modify all). If you're using another emulator, do whatever's
necessary to turn MODIFY ALL on, as indicated by an asterix in the function
key.

With modify all on, you're working in a local edit mode -- but a mode that is
still intermittently interactive with the HP3000 host. When you press either
the ENTER key or the RETURN key, the current line that your cursor is on will
be transmitted to the host.

For the first demonstration, move your terminal cursor up to the line that
says "announce a non-effective change" (line 6880) and type "(now is the
time)" at the end of the current text. Then press RETURN.

Pressing RETURN will cause the entire line to be transmitted to the HP3000,
including the line number. BASIC not only absorbs this line into its listing,
it also simultaneously syntax checks it, which is enormous productivity
advantage. Nothing gets into the actual listing unless it is minimally good
code.

To demonstrate to yourself that your change was accepted, press Cntl+Home
again twice quickly to clear the screen and then type "list" to get a new
listing. You should see your change.

Now place your cursor on line 3240 (get there anyway you wish; Home, Page Up,
and the arrow keys all work the way they do on most PC programs). Once there,
press Cntl+Insert (insert line) five or six times to open up a hole in the
listing.

Now type:

     3234 a=b
     3235 b=sqr(c)
     3236 d=a-b

with each line followed by a carriage return (there's obviously nothing
special about this code; it's merely there to demonstrate how code insertion
is done in BASIC). Now clear your screen again (Cntl+Home twice) and re-list
it. You'll see the new lines in the code, properly indented. BASIC performs
that indentation automatically.

While we could have been anywhere on the page when we typed in those lines,
it's obviously much easier to see what you're doing when you see where you're
doing it.

Now let me show you the beginnings of the full-screen editor that we were
going to put into QCTerm. Besides the notorious cut, copy, and paste keys
(Cntl+X, Cntl+C, Cntl+V), there are also these three keys:

     Cntl+F (find)
     Cntl+D (find next -- or "do it again")
     Cntl+R (replace)

With a full listing on the screen, press Cntl+F and enter the word

     invoke

in the "find what" entry.

Enter the word

     chain

in the "replace with" slot and press RETURN. QCTerm will automatically find
the first occurrence of the word "invoke" past your current cursor position.
Now press Cntl+D to find the next occurrence. Indeed, you can merely hold the
Cntl+D key down and watch it quickly find every instance of the word.

At one of these stops, press Cntl+R to replace the word "invoke" with
"chain". These are both legitimate BASIC verbs, so your line will pass syntax
check. However, doing this only replaces the text on the screen; the HP3000
hasn't seen your modified line yet. If you like what you've done, press the
RETURN key to transmit this one particular line to the HP3000. A ">" prompt
will indicate a successful transmission. Now press Cntl+D, Cntl+R and RETURN
again to modify the next instance, as often as you like, where ever you like.

You have all 600 lines of the program on the screen at one time -- and you
can see how fast the code is to modify. I've personally never seen an easier,
more useful full-screen editor -- and we got there by merely stepping back 25
years in time.

It's this flexibility that we wanted to put into QCTerm's main terminal
program, but based on the last several days conversation, I've now decided
not to take this functionality any further within the terminal itself.
Rather, what we'll do now is add a new screen that will simply -- and solely
-- be a full screen editor. Plain ASCII text, representing any sort of
non-line-oriented code (COBOL, C, PASCAL, QUIZ, etc.) will be loaded into the
editor through the invisible use of FTP. Because we will now be wholly in a
local edit mode, you will have the full use of the Cntl+X,C,V,F,D,R and
insert/delete line keys at your fingertips. Spooler files will be put at each
end of the editor's textbuffer so that a program of essentially any
imaginable length can be edited

BASIC will be the only exception to the use of this new editor. It will
continue to be edited in the manner I've shown above.

If you want to save your modified code, please save it as the filename TEST.
To do this, type

     >save test!,fast

The "fast" verb performs another level of syntax checking, insuring that your
code is structurally sound (DO's are matched with DOEND's, FOR-NEXT loops
match, etc.).

Turn your LINE MODIFY key off and type "e" to exit and "bye" to leave. All
sense of time travel has no been erased. You have returned to the "modern"
era.

Wirt Atmar

ATOM RSS1 RSS2