TECO editor help
207 views
Skip to first unread message
david richards
Mar 18, 2018, 1:27:40 PM3/18/18
to PiDP-8
I'm new to the Pipd8i system but slowly getting used to the basic operation.
I would like to be able to use a full screen editor, I see there is a version of TECO, VTEDIT.
I have not yet found any tutorial on how to use TECO even in its basic line editor form supplied.
I seem to be missing something as I cant exit or write a file.
In short, I'm stuck with EDIT until I can work out how to get started with TECO.
I have found an archive with pidp8i adventure and vtedit configured, this boots ok
and I can edit files in full screen mode with this version, but still cant save them or exit cleanly.
On a separate matter, by editing 6.script I enabled output to my VT100 terminal at boot time
'set console SERIAL=/dev/ttyUSB0;1200-7e1' was used to do for this.
Any help gratefully received.David.
Bob Smith
Mar 18, 2018, 4:59:32 PM3/18/18
to PiDP-8
There is a 50 page section on TECO in the OS/8 Hanbook of April 1974. I can send you the pdf version of it if you wish.
Rick Murphy
Mar 18, 2018, 5:16:24 PM3/18/18
to david richards, PiDP-8
To exit TECO, use "EX$$" - that will write the file you're editing then exit.
The version of TECO that you are most likely using is designed to drive a VT52 scope. If you have a compatible terminal, you can use VTEDIT.
Documentation for VTEDIT is available from https://tangentsoft.com/pidp8i/wiki?name=Using+VTEDIT
-Rick
--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/ba650053-dba6-4c9e-b5ba-db80d93e47e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
david richards
Mar 18, 2018, 5:19:25 PM3/18/18
to pid...@googlegroups.com
Thanks Bob, if you think the full manual is a suitable getting started guide then I had better read it. David.
I've found the manual online, I'm now reading it.
david richards
Mar 18, 2018, 6:01:39 PM3/18/18
to PiDP-8
It seems the smallest thing can cause great problems, who would have thought ESC was used to complete a command, doh.
David/
Rick Murphy
Mar 18, 2018, 7:17:24 PM3/18/18
to david richards, PiDP-8
Holy unspoken assumption, Batman! :)
Clearly I should have mentioned that the "$" means "Press ESCAPE". Apologies for that.
TECO's a complex language for editing buffers of text that may come from a file (or not). It's terse to the point of being completely inscrutable - just about every letter is either a command or a value.
There's a "Novice Subset" of TECO that suffices for most text editing: http://bitsavers.trailing-edge.com/pdf/dec/teco/AV-D530A-TK_TECO_Pocket_Guide_1978.pdf and look at the "back" page (which is the first on that scan.)
-Rick
--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/4dd0fbca-79f0-420b-97ff-71e76e4c6789%40googlegroups.com.
david richards
Mar 18, 2018, 7:27:29 PM3/18/18
to PiDP-8
Thanks Rick, that is just what I needed.
Now I need to work out which files I need to transfer to copy the vtedit version onto my main disk.
something for tomorrow, I'll quit whilst I'm ahead now.
Kind regards, David.
William Cattey
Mar 18, 2018, 10:16:30 PM3/18/18
to PiDP-8
I will apologize in advance for having taken VTEDIT support out of the defaults
for the most recent OS/8 distribution. I was unfamiliar with it, and had trouble getting it working
under my vt100 terminal emulator coming into the the PiDP-8/i.
So the install is disabled by default.
TECO is fully operational, and even without VTEDIT is very complex and interesting.
-Bill Cattey
Paul Birkel
Mar 19, 2018, 1:19:16 AM3/19/18
to Rick Murphy, david richards, PiDP-8
Also the TECO Reference Guide for hunt-n-peck :-}: http://bitsavers.trailing-edge.com/pdf/dec/pdp8/os8/AA-H608A-TA_os8teco_mar79.pdf
clasystems
Mar 19, 2018, 3:47:23 AM3/19/18
to PiDP-8
There are multiple versions or TECO that existed during the lifetime of OS/8. The one in the handbook has some unique INCOMPATIBLE features. I occasionally use a source-control macro that only runs on the old one that runs in 8K, takes no advantage of more memory, etc.
There is another one written using MACREL [arguably the dependency is somewhat contrived, which is the case with many programs that happen to be such] and requires at least 16K. It uses a very inefficient kludge to operate in 16K:
Basically there are several sets of code vying to be executed in field 0. When you start TECO, the one most needed for elementary operations is loaded in field 0 along with some other features that are non-movable. In field 0 and one there ae other uses that are more usual, etc.
When you reference a feature not in field 0, the one in field 0 is "swapped out" in a sense, and then the desired part is "swapped in" in a sense, only to likely revert to the norm when later some aspect of the original section in field 0 is now needed. [Or perhaps one of the others depending on feature needed at the moment].
Now hw is this done?
There is an old trick regarding XOR between two sets of strings involving the XOR operations between them and when done, they have reversed places. [It is not intuitive, it is merely true]
So, the two "swap" operations are done without a buffer [but it is very slow, but of course faster than some real disk devices depending, such as on the RX01]. If you have a few more memory fields than the 16K minimum, the swapping converges onto simple memory moves which is faster, etc.
In any case, this version of TECO is very incompatible with the 8K original and tends to be more "universal" TECO in that it is closer to the VAX/-11 TECO which is somewhat inefficient because those extensions are byte-oriented, so they are inefficiently in 24 bits with only 16 bits defined, but fortunately, there aren't too many of them. Most of the original features that were unique to the 8K version are gone, so if you use them depending on the OS/8 handbook, it won't work.
These days, most of what I do with TECO is just the basics that work in the 8K one, the 16K one, and more importantly to me the Pete Siemsen-writtten one known as TECOC that has a special implementation for MS-DOS name restrictions and another for a reasonably full implementation of Windows filenames, etc. This one is a superset of the one for the VAX and PDP-11. I write many macros for TECOC as part of my PEPS package support to do things totally unavailable on the PiDP-8 [and likely quite an effort to do the equivalent of part of my package and then there are other things that will never be available in a million years on the PiDP-8.]
I have to point out that some of my macros require a feature not available in any other TECO because it allows it to be running on a byte-count file structure yet can be cognixant of the various DEC impleentations regarding end-of-file conventions. There are a lot of sloppy implementations of things and my macro cleans pretty much all of them up to allow further processing in Windows, etc. Most of these differences in theory should be possible because there should be a close implementation of TECOC that can run there, albeit very slowly. [Note: The cleanup program is already slow even in Windows on a decently powerful PC. It would be painful to use it on an overloaded Rasberry Pi.]
In any case, I would recommend that any new work regarding TECO use Pete's version as the "gold standard" etc. It's extremely well thought out and well documented which is perhaps the best feature!
There is another one written using MACREL [arguably the dependency is somewhat contrived, which is the case with many programs that happen to be such] and requires at least 16K. It uses a very inefficient kludge to operate in 16K:
Basically there are several sets of code vying to be executed in field 0. When you start TECO, the one most needed for elementary operations is loaded in field 0 along with some other features that are non-movable. In field 0 and one there ae other uses that are more usual, etc.
When you reference a feature not in field 0, the one in field 0 is "swapped out" in a sense, and then the desired part is "swapped in" in a sense, only to likely revert to the norm when later some aspect of the original section in field 0 is now needed. [Or perhaps one of the others depending on feature needed at the moment].
Now hw is this done?
There is an old trick regarding XOR between two sets of strings involving the XOR operations between them and when done, they have reversed places. [It is not intuitive, it is merely true]
So, the two "swap" operations are done without a buffer [but it is very slow, but of course faster than some real disk devices depending, such as on the RX01]. If you have a few more memory fields than the 16K minimum, the swapping converges onto simple memory moves which is faster, etc.
In any case, this version of TECO is very incompatible with the 8K original and tends to be more "universal" TECO in that it is closer to the VAX/-11 TECO which is somewhat inefficient because those extensions are byte-oriented, so they are inefficiently in 24 bits with only 16 bits defined, but fortunately, there aren't too many of them. Most of the original features that were unique to the 8K version are gone, so if you use them depending on the OS/8 handbook, it won't work.
These days, most of what I do with TECO is just the basics that work in the 8K one, the 16K one, and more importantly to me the Pete Siemsen-writtten one known as TECOC that has a special implementation for MS-DOS name restrictions and another for a reasonably full implementation of Windows filenames, etc. This one is a superset of the one for the VAX and PDP-11. I write many macros for TECOC as part of my PEPS package support to do things totally unavailable on the PiDP-8 [and likely quite an effort to do the equivalent of part of my package and then there are other things that will never be available in a million years on the PiDP-8.]
I have to point out that some of my macros require a feature not available in any other TECO because it allows it to be running on a byte-count file structure yet can be cognixant of the various DEC impleentations regarding end-of-file conventions. There are a lot of sloppy implementations of things and my macro cleans pretty much all of them up to allow further processing in Windows, etc. Most of these differences in theory should be possible because there should be a close implementation of TECOC that can run there, albeit very slowly. [Note: The cleanup program is already slow even in Windows on a decently powerful PC. It would be painful to use it on an overloaded Rasberry Pi.]
In any case, I would recommend that any new work regarding TECO use Pete's version as the "gold standard" etc. It's extremely well thought out and well documented which is perhaps the best feature!
cjl [it does what it says and says what it does]
Neil Higgins
Mar 19, 2018, 4:54:09 AM3/19/18
to PiDP-8
So, Charles, can you tell us anything about the provenance of PDP-11 TECO? My buddy took the trouble to learn it and was very impressed. I sat with RT-11 EDIT and was happy enough.
CLASystems
Mar 19, 2018, 5:23:22 AM3/19/18
to Neil Higgins, PiDP-8
On Mon, Mar 19, 2018 at 4:54 AM, Neil Higgins <1955...@gmail.com> wrote:
So, Charles, can you tell us anything about the provenance of PDP-11 TECO? My buddy took the trouble to learn it and was very impressed. I sat with RT-11 EDIT and was happy enough.
TECO is not merely an "editor" it is a powerful language that supports even more powerful macros capable of spontaneously creating additional macros from parameters passed to macros, etc.
I never used any PDP-11 versions, and only a tiny smattering of VAX over the years. But my friend Stan Rabinowitz well known in the TECO world bothered to create a document explaining all the then-current differences. He did this as a template to implement the 16K-requiring OS/8 TECO, etc.
Eventually, Stan turned over all of the relevant info to Pete Siemsen, and you can easily locate his work online. His manual is really great and the proper amount of work done to be consistent with understanding of TECO, admittedly not something for beginners.
If RT-11 EDIT is a rip-off of OS/8 EDIT, I don't want any part of it. But then, i do write quite a bit of code, etc.
cjl
PS: the actual typing up process of creating TECO macros is an art unto itself, many can't do it; it is always very tedious and pretty much only TECO can be used to create them. Part of the problem is that you are creating that which accomplishes something analogous to what you are using to type the text in in the first place. You wind up having the context taken away from you and then resort to alternate features to put in the right characters. This is primarily because all TECO commands end with ESC except the last has to have two ESC characters. Now thing of what you have to do to type up something that when executed does what you are doing to type it in now, but it is relevant when it executes, etc.
I never used any PDP-11 versions, and only a tiny smattering of VAX over the years. But my friend Stan Rabinowitz well known in the TECO world bothered to create a document explaining all the then-current differences. He did this as a template to implement the 16K-requiring OS/8 TECO, etc.
Eventually, Stan turned over all of the relevant info to Pete Siemsen, and you can easily locate his work online. His manual is really great and the proper amount of work done to be consistent with understanding of TECO, admittedly not something for beginners.
If RT-11 EDIT is a rip-off of OS/8 EDIT, I don't want any part of it. But then, i do write quite a bit of code, etc.
cjl
PS: the actual typing up process of creating TECO macros is an art unto itself, many can't do it; it is always very tedious and pretty much only TECO can be used to create them. Part of the problem is that you are creating that which accomplishes something analogous to what you are using to type the text in in the first place. You wind up having the context taken away from you and then resort to alternate features to put in the right characters. This is primarily because all TECO commands end with ESC except the last has to have two ESC characters. Now thing of what you have to do to type up something that when executed does what you are doing to type it in now, but it is relevant when it executes, etc.
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2b9a2b7e-5f11-4a3c-9781-36883f238dd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Bill Gates, 1992
Neil Higgins
Mar 19, 2018, 6:15:06 AM3/19/18
to PiDP-8
RT-11 EDIT had escapes and double-escapes (just like the big boys) and a pretty good Macro capability, without the complexity you have described - essentially a keystroke recorder with a bit of looping and substitution thrown in. It was also “page” (buffer) oriented, and one had to be conscious of that. For years, if I had a heavy editing job to do, I would export the file to a PDP-11 and do the work in EDIT, before exporting it back to the original system. Then one day the PDP-11s went “fut”. I was bereft.
CLASystems
Mar 19, 2018, 7:05:33 AM3/19/18
to Neil Higgins, PiDP-8
RT-11 EDIT had escapes and double-escapes (just like the big boys) and a pretty good Macro capability, without the complexity you have described - essentially a keystroke recorder with a bit of looping and substitution thrown in. It was also “page” (buffer) oriented, and one had to be conscious of that. For years, if I had a heavy editing job to do, I would export the file to a PDP-11 and do the work in EDIT, before exporting it back to the original system. Then one day the PDP-11s went “fut”. I was bereft.This sounds primarily like just using TECO in the insertion mode.
A key question is this, the PDP-8 one is as bad as MS-DOS EDLIN. There are commands with faux line number parameters. But as the file grows, they are no longer relevant. You would have to list them all out and then count them on the screen to know how to apply them.
In TECO, the lines are real if you wish to use them, but typically they are not used. Most of the commands are relative to where you are in the buffer ["."] Thus, common commands to list might be -6,6T$$ which means relatively type out the six lines on either side of where you are. And that is a character position, not a line position, so it could be in the midst of one, thus 0tt might be needed to see all of one line. And many commands exist that use the same general parameter structure to do far more complex things, just stating the what and where but doing something else on them, etc.
Also, 0 is always the beginning and Z is always the end, even if the buffer is empty. Moving the pointer too far either way is usually allowed, but returns the position value as -1 to "protect" searches. One of the important Pete Seimsen extensions is an article to search for which means essentially there is nothing more to see in the conventional end-of-file (typically control-Z) sense fully knowing that since OS/8 is actually block-oriented, you need to know to not look at the junk that is there, although other commands can, etc. This is vital when reading files created reckoned in blocks with hopefully end-of-file characters on a system that only counts bytes, etc. I can close out files that are liked in both worlds that way.
In TECO, the lines are real if you wish to use them, but typically they are not used. Most of the commands are relative to where you are in the buffer ["."] Thus, common commands to list might be -6,6T$$ which means relatively type out the six lines on either side of where you are. And that is a character position, not a line position, so it could be in the midst of one, thus 0tt might be needed to see all of one line. And many commands exist that use the same general parameter structure to do far more complex things, just stating the what and where but doing something else on them, etc.
Also, 0 is always the beginning and Z is always the end, even if the buffer is empty. Moving the pointer too far either way is usually allowed, but returns the position value as -1 to "protect" searches. One of the important Pete Seimsen extensions is an article to search for which means essentially there is nothing more to see in the conventional end-of-file (typically control-Z) sense fully knowing that since OS/8 is actually block-oriented, you need to know to not look at the junk that is there, although other commands can, etc. This is vital when reading files created reckoned in blocks with hopefully end-of-file characters on a system that only counts bytes, etc. I can close out files that are liked in both worlds that way.
I also use P?S/8's line editor with real line numbers you can change, but only if you wish to. When the file is closed, they are permanent [unless opened again, changed and closed yet again].
cjl
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/b35ab0e8-c027-4dd2-a6a9-4e3783c5f75b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Bill Gates, 1992
Neil Higgins
Mar 19, 2018, 7:43:48 AM3/19/18
to PiDP-8
I suspect that the timing would be wrong, but is it possible that TECO’s advanced capabilities were modelled on LISP? I have heard that emacs is LISP, or is written in LISP, or includes LISP, or something like that .. I have read the flyleaves of books that assure me that if I learn LISP, I will understand EVERYTHING.
Warren Young
Mar 19, 2018, 8:28:12 AM3/19/18
to PiDP-8
On Sunday, March 18, 2018 at 11:27:40 AM UTC-6, david richards wrote:
On a separate matter, by editing 6.script I enabled output to my VT100 terminal at boot time'set console SERIAL=/dev/ttyUSB0;1200-7e1' was used to do for this.
Thank you for that idea! I've used it as the basis of a new "Plan A" in my guide on running a PiDP-8/I with lowered security barriers compared to the stock configuration.
This also plays into the recent discussions over the serial mod. It allows a world where you have a terminal attached to the simulator console but you must log in over SSH to give commands to the host or to the simulator itself, quite a nice tradeoff in security.
david richards
Mar 19, 2018, 8:36:36 AM3/19/18
to pid...@googlegroups.com
I have rebuilt my pidp8i using the latest sources available and configured to include the VTEDIT options.
I cannot get the full screen editor to work.
If I copy the TECO.SV binary form the image downloaded from the link in this page then it does work, as indeed it does if I run the image from the page / link.
The version in pidp8i is 22 blocks, the adventure image is 32 blocks.
So I assume the problem is that the TECO binary has something missing.
I shall compare the .TE and .IN files to see if there are any other changes in the two versions.
I may need to copy these over as well to maintain compatibility.
I dont know if other files are needed too.
Something odd happened with the new version the format needed to enter a date appears to have changed.
Yesterday I could enter '.DATE 19-03-79' but now I need to enter '19-MAR-79'
Warren Young
Mar 19, 2018, 8:54:06 AM3/19/18
to pid...@googlegroups.com
On Sunday, March 18, 2018 at 8:16:30 PM UTC-6, William Cattey wrote:
I will apologize in advance for having taken VTEDIT support out of the defaults
I don't think there's anything to apologize for. TECO is more historically relevant, and is more likely to be of interest to a broader swath of PiDP-8/I users.
But, VTEDIT is still there, and readily enabled.
Those who want to enable it on existing OS/8 media without re-generating it, this is supposed to do it:
<Ctrl-E>sim> attach dt0 /opt/pidp8i/share/media/os8/local.tu56sim> cont.COPY SYS:<DTA0:VTEDIT.*.COPY SYS:<DTA0:TECO.IN
Simply adding it to our local.tu56 file is likely to conflict with media/os8/patches/TECO*, so I think I'm going to have to defer to Bill for a fix here.
CLASystems
Mar 19, 2018, 10:09:04 AM3/19/18
to Neil Higgins, PiDP-8
On Mon, Mar 19, 2018 at 7:43 AM, Neil Higgins <1955...@gmail.com> wrote:
I suspect that the timing would be wrong, but is it possible that TECO’s advanced capabilities were modelled on LISP? I have heard that emacs is LISP, or is written in LISP, or includes LISP, or something like that .. I have read the flyleaves of books that assure me that if I learn LISP, I will understand EVERYTHING.
LISP is irrelevant to TECO, but likely something at MIT called at the time TECO was used to edit LISP things.
EMACS at some point was written in something that week called TECO using TECO macros of the day.
The problem is that TECO became an academic football outside of DEC. Thus, someone cobbles up some language features that might help implement macros to help write what passed for getting a grade and calling the result emacs.. Or said a different way, ant MIT the TECO of the week was used to implement an impractical version of an emacs of the week.
At some point earlier, we had DEC standard TECO which fleshed it out and standardized it and many useful macros were written, all for TOPS10 TECO. It even included an "old macro flag" to enable some nearly dead syntax that was flawed at your own peril but needed to support macro specifics from an even earlier time.
Most, but not all of the TOPS10 TECO is compatible with a decent subset of the newer TECO versions to which I have just spoken about. But in some of these features, the PDP-10 people would not budge, etc. But this is still over 90% compatible with the eventual VAX/11 TECO sans the 16-bit frills they added.
PDP-8 TECO came from a totally different direction. As I said, the TECO of the week mattered here, but it was from yet a different week. This one was favored by someone at MIT named Russell Ham. He wrote an operating system for the PDP-8 with the following configuration ONLY:
1) TC01/TC08 DECtape
2) Straight PDP-8 with 8K
3) EAE
The tape format and file structure is PDP-10 DECtapes. That format defines a bootable tape [for such as a KA10]. His system uses the same designated blocks to get started and some hard-wired specific file names on the same tape. This way, his personal tape could run on a certain PDP-8 he had access to as well as be brought to a TOPS10 machine with DECtape, etc.
On it was an editor named TECO, and it was quite a bit different from any other.
Without permission or authorization, this code was stolen by Rusty Whitney of OMSI and using "child labor exploitation" he got his small minion of somewhat bright young students to lift the source code and make it run on OS/8, but retained the lack of compatibility, literally lock-step with Russ Ham's version.
Eventually, this code got in to the hands of Richard Lary and Stan Rabinowitz, and evolved into the 8K TECO for OS/8 we have discussed. Some of the real original remains, but not much.
To make things a bit more confusing, Russ's operating system was named OS8 [NOT OS/8]. It apparently was not much more than some form of binary loader, above and beyond what I explained; the assembler was MACRO-8 modified to read and write from/to DECtape files. Russ never had any intention of spreading around his work, but it did happen.
In any case, OS8 would never be extensible, as it requires the PDP-10 file-structure as practiced on DECtapes. Larger PDP-10 devices never find their way to PDP-8 hardware.
EMACS at some point was written in something that week called TECO using TECO macros of the day.
The problem is that TECO became an academic football outside of DEC. Thus, someone cobbles up some language features that might help implement macros to help write what passed for getting a grade and calling the result emacs.. Or said a different way, ant MIT the TECO of the week was used to implement an impractical version of an emacs of the week.
At some point earlier, we had DEC standard TECO which fleshed it out and standardized it and many useful macros were written, all for TOPS10 TECO. It even included an "old macro flag" to enable some nearly dead syntax that was flawed at your own peril but needed to support macro specifics from an even earlier time.
Most, but not all of the TOPS10 TECO is compatible with a decent subset of the newer TECO versions to which I have just spoken about. But in some of these features, the PDP-10 people would not budge, etc. But this is still over 90% compatible with the eventual VAX/11 TECO sans the 16-bit frills they added.
PDP-8 TECO came from a totally different direction. As I said, the TECO of the week mattered here, but it was from yet a different week. This one was favored by someone at MIT named Russell Ham. He wrote an operating system for the PDP-8 with the following configuration ONLY:
1) TC01/TC08 DECtape
2) Straight PDP-8 with 8K
3) EAE
The tape format and file structure is PDP-10 DECtapes. That format defines a bootable tape [for such as a KA10]. His system uses the same designated blocks to get started and some hard-wired specific file names on the same tape. This way, his personal tape could run on a certain PDP-8 he had access to as well as be brought to a TOPS10 machine with DECtape, etc.
On it was an editor named TECO, and it was quite a bit different from any other.
Without permission or authorization, this code was stolen by Rusty Whitney of OMSI and using "child labor exploitation" he got his small minion of somewhat bright young students to lift the source code and make it run on OS/8, but retained the lack of compatibility, literally lock-step with Russ Ham's version.
Eventually, this code got in to the hands of Richard Lary and Stan Rabinowitz, and evolved into the 8K TECO for OS/8 we have discussed. Some of the real original remains, but not much.
To make things a bit more confusing, Russ's operating system was named OS8 [NOT OS/8]. It apparently was not much more than some form of binary loader, above and beyond what I explained; the assembler was MACRO-8 modified to read and write from/to DECtape files. Russ never had any intention of spreading around his work, but it did happen.
In any case, OS8 would never be extensible, as it requires the PDP-10 file-structure as practiced on DECtapes. Larger PDP-10 devices never find their way to PDP-8 hardware.
cjl
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/84e16169-831a-46d5-9288-46ab1fd9d389%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Bill Gates, 1992
Bill Cattey
Mar 19, 2018, 4:32:20 PM3/19/18
to Warren Young, PiDP-8
As has been pointed out,
the ancestry/lineage of TECO for OS/8 is a tangled web.
The TECO I installed is what shipped with the OS/8 V3D distribution DECtapes.
I did run in all the patches that were documented in DIGITAL PDP-8 Software News.
However, it makes sense that such a codeline predates VTEDIT.
I need to find out from Rick Murphy where that version of TECO came from, and
begin the process of understanding the differences.
There *IS* an updated version of TECO in the OS/8 V3F stuff that I'm working with,
but I didn't see any documentation on what the differences were.
It might be a patch.
It might be a whole code line with wholly different ancestry.
I'll start looking, and provide updates to this thread with what I learn.
Until then, it's good to know that we have a matched set of VTEDIT init files,
and TECO binary from somewhere that someone has been able to validate as working together.
-Bill
The TECO I installed is what shipped with the OS/8 V3D distribution DECtapes.
I did run in all the patches that were documented in DIGITAL PDP-8 Software News.
However, it makes sense that such a codeline predates VTEDIT.
I need to find out from Rick Murphy where that version of TECO came from, and
begin the process of understanding the differences.
There *IS* an updated version of TECO in the OS/8 V3F stuff that I'm working with,
but I didn't see any documentation on what the differences were.
It might be a patch.
It might be a whole code line with wholly different ancestry.
I'll start looking, and provide updates to this thread with what I learn.
Until then, it's good to know that we have a matched set of VTEDIT init files,
and TECO binary from somewhere that someone has been able to validate as working together.
-Bill
March 19, 2018 at 8:54 AM
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/6eb2bdc3-a228-49b2-a7cf-9905a498d7cf%40googlegroups.com.
March 18, 2018 at 10:16 PM
I will apologize in advance for having taken VTEDIT support out of the defaults
for the most recent OS/8 distribution. I was unfamiliar with it, and had trouble getting it workingunder my vt100 terminal emulator coming into the the PiDP-8/i.So the install is disabled by default.TECO is fully operational, and even without VTEDIT is very complex and interesting.-Bill Cattey
On Sunday, March 18, 2018 at 7:27:29 PM UTC-4, david richards wrote:
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/ad25ec79-a17f-4983-86c2-ab4df37249da%40googlegroups.com.
Warren Young
Mar 19, 2018, 5:00:22 PM3/19/18
to pid...@googlegroups.com
On Monday, March 19, 2018 at 2:32:20 PM UTC-6, William Cattey wrote:
There *IS* an updated version of TECO in the OS/8 V3F stuff that I'm working with,
As I understand it, a big part of the difference between our TECO and the one Rick Murphy is shipping is that it knows how to emit VT100/ANSI screen control codes, so it's rather nonstandard, from an OS/8 perspective. VTEDIT depends on this to do its thing.
Is it possible that your new mkos8 work would allow moving the implementation of --enable-os8-vtedit until after the -bin disk is copied to -patched.rk05 and also after the patch8 steps are done, so that the provided binary TECO.SV just stomps over the top of the patched stock TECO?
Warren Young
Mar 19, 2018, 5:10:00 PM3/19/18
to PiDP-8
On Monday, March 19, 2018 at 3:00:22 PM UTC-6, Warren Young wrote:
Is it possible that your new mkos8 work would allow moving the implementation of --enable-os8-vtedit until after the -bin disk is copied to -patched.rk05 and also after the patch8 steps are done, so that the provided binary TECO.SV just stomps over the top of the patched stock TECO?
Actually, I think we can do it with the current mkos8: just remove the current "if args.enable_vtedit:" stuff, then do the copy-in steps within make_patch(), skipping over the TECO*.patch8 files to save a bit of processing time. That is, we treat VTEDIT's TECO.SV as if it were a binary patch that supersedes TECO*.patch8.
It looks like this might even merge cleanly with your os8-v3f-extensions branch, as currently done. But, does it conflict with your planned scripted builds?
Rick Murphy
Mar 19, 2018, 6:51:10 PM3/19/18
to Warren Young, PiDP-8
That's correct - it's a source modification of TECO-8 V7 (i.e. the MACREL version of TECO).
I can deliver source, as I know that's the preference for your build process. Or a RK05 image with MACREL and the sources and resulting .SV file.
Or a diff from the original source and modified source.
Whatever's easy and fits within your preferred build constraints.
-Rick
On Mon, Mar 19, 2018 at 5:00 PM, Warren Young <tange...@gmail.com> wrote:
On Monday, March 19, 2018 at 2:32:20 PM UTC-6, William Cattey wrote:
There *IS* an updated version of TECO in the OS/8 V3F stuff that I'm working with,As I understand it, a big part of the difference between our TECO and the one Rick Murphy is shipping is that it knows how to emit VT100/ANSI screen control codes, so it's rather nonstandard, from an OS/8 perspective. VTEDIT depends on this to do its thing.
--Is it possible that your new mkos8 work would allow moving the implementation of --enable-os8-vtedit until after the -bin disk is copied to -patch and also after the patch8 steps are done, so that the provided binary TECO.SV just stomps over the top of the patched stock TECO?
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/eebf9b36-36a4-4d67-a009-2cb3624b8738%40googlegroups.com.
Bill Cattey
Mar 19, 2018, 10:31:41 PM3/19/18
to Rick Murphy, Warren Young, PiDP-8
I've downloaded and looked
through the rk05 image that Rick offered up.
Together with a bit of google searching, I have the following "TLDR" understanding to offer:
1. VTEDIT requires TECO-8 v7 with some additional mods that Rick has.
2. TECO-8 v7 from Rick Murphy seems to trace its lineage to DECUS 8-913, which, according to the TECO DECUS Sig newsletter "the MOBY MUNGER", issue #3, Part 1, August 1979, was offered up by Stan Rabinowitz as the PDP-8 instance of a "compatibility Level 1 of TECO" targeted for the PDP-10, PDP-11 and PDP-8. (See detail 1 below.)
3. A quick compare of front matter from the two versions, PAL-8 source of TECO v5 in OS/8 v3F and the MACREL source of TECO-8 v7 shows v7 to be a continuation of the code line from v5. (See detail 2 below.)
4. It seems definitely worthwhile to craft a "TECO-8 v7 with VTEDIT" package to install on the OS/8 rk05 packs
we distribute for the PiDP-8/i.
I'm not sure when I'll be able to do this work. I'm in the middle of a couple other projects for the OS/8
stuff: V3F, and a re-imagining of the mkos8 system for building packs.
---- Detail 1: Excerpt from "the MOBY MUNGER" ----
See: http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/teco/MobyMunger_%233part1_Aug79.pdf
The TECO SIG is actively pushing Compatibility Level 1 of TECO.
This dialect of TECO is upward compatible with what you are
familiar with and is compatible with each other. Compatibility
level 1 TECO is implemented currently via three TECOs: TECO-8
which runs under OS/8, TECO-10 which runs under TOPS-10 and
TOPS-20, and TECO-11 which runs under RT-11, RSTS/E, RSX-ll/M,
RSX-ll/D, IAS, and VMS. These versions of TECO are supported by
the TECO SIG and have been created through the SIG's efforts.
STATUS
TECO-8 V7 is now currently available from the DECUS Program Library.
Its order number is DECUS 8-913. For more information, see page 11.
TECO-11 V35 kits have been made for all PDP-11 operating systems,
but as of this writing (17-August-1979) these kits have not yet
been submitted to DECUS (although all the paperwork has been
filled out) . The kits are going through in-house field test.
Also, work is still progressing on the new TECO manual. It is
expected that TECO-11 will be available from DECUS within a
month after you receive this issue of the Moby Munger. However,
do NOT order it from DECUS until you have seen a formal announcement
of its availability. You can also call Stan Rabinowitz
[at (603) 884-5288 between 3 PM and 4 PM Eastern Time] to inquire
about availability.
TECO- 10 is still being field tested but should be ready for
mass distribution before Fall DECUS. We will have copies there.
Watch for further announcements before ordering from DECUS
[or call the above phone number] .
It is unfortunate that it is taking the implementors so much
time to formally get these products into the DECUS Program library.
Perhaps we should go back to the scheme of informal distribution
by users pending official library submission. If you would be
interested in field testing new TECOs as they come out and sending
out copies to other users who sent you media, please contact Stan
Rabinowitz. Send your name, address, phone number, hardware
configuration, and operating system.
Anyone interested in implementing Compatibility Level 1 of TECO
on some other operating system should contact Stan Rabinowitz.
We will send you more information and encouragement.
...
Page 11
NOTES FROM OS/8
The latest DEC-supported TECO for OS/8 is called OS/8 TECO V5
and is distributed as part of the OS/8 V3D extension kit.
The PDP-8 group has no plans to re-release TECO in the near
future.
The TECO SIG intends to support enhancements to OS/8 TECO.
Through the aid of Stan Rabinowitz, they have created a new
product, called TECO-8, which is now in the DECUS Program
Library. TECO-8 is based on OS/8 TECO but is written in
MACREL (rather than PAL8) and contains many new features.
Any time that DEC decides that it is willing to release and
support TECO-8, the SIG will be happy to give it to DEC.
TECO-8 version 6 was distributed informally at Spring DECUS
in New Orleans. TECO-8 V7 is now available from the DECUS
Program Library. The order number is DECUS 8-913. It is
available on two media - DECtape or floppies. The media code
for the DECtape is H30 and the media code for the two floppies
is K50. There are two floppies - a source floppy and a
binary floppy. If you have no need for the sources, you can
order just the binary floppy. Very explicitly, specify that you
want the binary floppy only and send in $25 rather than $50.
(The DECtape kit contains both sources and binaries on one tape.)
There is also a write-up (media code A2) but this is identical
to material appearing on the machine-readable media, so you
should not order it if you are ordering one of the kits.
Bug reports on OS/8 TECO V5 should continue to be submitted
to DEC in the usual manner (with copies to the TECO SIG) .
Bug reports on TECO-8 V7 should be sent to the TECO SIG
c/o DECUS. Do NOT send TECO-8 problem reports to DEC.
Probably the most important feature of TECO-8 is its window
support (written by Jim Roth) . This allows TECO to maintain
a window into the text buffer on the screen of a VT05, VT52,
or VT100 terminal (similar to the VR12 window support that
already existed) . This allows writing true video editors
in TECO and in fact, one is included in the TECO-8 kit. It
is called VTEDIT version and is compatible with VT52.TEC
which was distributed with early versions of TECO-11. It runs
on VT52's and VT100S. A picture of the VTEDIT keypad layout
occurs on page 9 of the last issue of the Moby Munger.
TECO-8 also supports expanded length MUNG command lines and
allows an alternative way to chain to TECO so that the
command line will be parsed by a TECO macro called TECO. TEC
instead of by CCL. Unfortunately, both of these features
requires corresponding support by CCL, which is not present
in the CCL distributed by DEC. Perhaps sometime in the
near future, a fix to CCL will be issued by the SIG.
The new features in TECO-8 which were not in OS/8 TECO V5
are described on the following pages.
---- Detail 2 ----
The second page of TECO.PA begins:
as does the second page of TECO.MA. The patches inventoried in TECO.PA are all present in TECO.MA.
The list of four known bugs is also present with a fifth one added.
After patch 49, common to both sources, TECO.MA inventories changes for versions 6, 602, 604, 605, 606, and 7.
Rick Murphy wrote:
Together with a bit of google searching, I have the following "TLDR" understanding to offer:
1. VTEDIT requires TECO-8 v7 with some additional mods that Rick has.
2. TECO-8 v7 from Rick Murphy seems to trace its lineage to DECUS 8-913, which, according to the TECO DECUS Sig newsletter "the MOBY MUNGER", issue #3, Part 1, August 1979, was offered up by Stan Rabinowitz as the PDP-8 instance of a "compatibility Level 1 of TECO" targeted for the PDP-10, PDP-11 and PDP-8. (See detail 1 below.)
3. A quick compare of front matter from the two versions, PAL-8 source of TECO v5 in OS/8 v3F and the MACREL source of TECO-8 v7 shows v7 to be a continuation of the code line from v5. (See detail 2 below.)
4. It seems definitely worthwhile to craft a "TECO-8 v7 with VTEDIT" package to install on the OS/8 rk05 packs
we distribute for the PiDP-8/i.
I'm not sure when I'll be able to do this work. I'm in the middle of a couple other projects for the OS/8
stuff: V3F, and a re-imagining of the mkos8 system for building packs.
---- Detail 1: Excerpt from "the MOBY MUNGER" ----
See: http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/teco/MobyMunger_%233part1_Aug79.pdf
The TECO SIG is actively pushing Compatibility Level 1 of TECO.
This dialect of TECO is upward compatible with what you are
familiar with and is compatible with each other. Compatibility
level 1 TECO is implemented currently via three TECOs: TECO-8
which runs under OS/8, TECO-10 which runs under TOPS-10 and
TOPS-20, and TECO-11 which runs under RT-11, RSTS/E, RSX-ll/M,
RSX-ll/D, IAS, and VMS. These versions of TECO are supported by
the TECO SIG and have been created through the SIG's efforts.
STATUS
TECO-8 V7 is now currently available from the DECUS Program Library.
Its order number is DECUS 8-913. For more information, see page 11.
TECO-11 V35 kits have been made for all PDP-11 operating systems,
but as of this writing (17-August-1979) these kits have not yet
been submitted to DECUS (although all the paperwork has been
filled out) . The kits are going through in-house field test.
Also, work is still progressing on the new TECO manual. It is
expected that TECO-11 will be available from DECUS within a
month after you receive this issue of the Moby Munger. However,
do NOT order it from DECUS until you have seen a formal announcement
of its availability. You can also call Stan Rabinowitz
[at (603) 884-5288 between 3 PM and 4 PM Eastern Time] to inquire
about availability.
TECO- 10 is still being field tested but should be ready for
mass distribution before Fall DECUS. We will have copies there.
Watch for further announcements before ordering from DECUS
[or call the above phone number] .
It is unfortunate that it is taking the implementors so much
time to formally get these products into the DECUS Program library.
Perhaps we should go back to the scheme of informal distribution
by users pending official library submission. If you would be
interested in field testing new TECOs as they come out and sending
out copies to other users who sent you media, please contact Stan
Rabinowitz. Send your name, address, phone number, hardware
configuration, and operating system.
Anyone interested in implementing Compatibility Level 1 of TECO
on some other operating system should contact Stan Rabinowitz.
We will send you more information and encouragement.
...
Page 11
NOTES FROM OS/8
The latest DEC-supported TECO for OS/8 is called OS/8 TECO V5
and is distributed as part of the OS/8 V3D extension kit.
The PDP-8 group has no plans to re-release TECO in the near
future.
The TECO SIG intends to support enhancements to OS/8 TECO.
Through the aid of Stan Rabinowitz, they have created a new
product, called TECO-8, which is now in the DECUS Program
Library. TECO-8 is based on OS/8 TECO but is written in
MACREL (rather than PAL8) and contains many new features.
Any time that DEC decides that it is willing to release and
support TECO-8, the SIG will be happy to give it to DEC.
TECO-8 version 6 was distributed informally at Spring DECUS
in New Orleans. TECO-8 V7 is now available from the DECUS
Program Library. The order number is DECUS 8-913. It is
available on two media - DECtape or floppies. The media code
for the DECtape is H30 and the media code for the two floppies
is K50. There are two floppies - a source floppy and a
binary floppy. If you have no need for the sources, you can
order just the binary floppy. Very explicitly, specify that you
want the binary floppy only and send in $25 rather than $50.
(The DECtape kit contains both sources and binaries on one tape.)
There is also a write-up (media code A2) but this is identical
to material appearing on the machine-readable media, so you
should not order it if you are ordering one of the kits.
Bug reports on OS/8 TECO V5 should continue to be submitted
to DEC in the usual manner (with copies to the TECO SIG) .
Bug reports on TECO-8 V7 should be sent to the TECO SIG
c/o DECUS. Do NOT send TECO-8 problem reports to DEC.
Probably the most important feature of TECO-8 is its window
support (written by Jim Roth) . This allows TECO to maintain
a window into the text buffer on the screen of a VT05, VT52,
or VT100 terminal (similar to the VR12 window support that
already existed) . This allows writing true video editors
in TECO and in fact, one is included in the TECO-8 kit. It
is called VTEDIT version and is compatible with VT52.TEC
which was distributed with early versions of TECO-11. It runs
on VT52's and VT100S. A picture of the VTEDIT keypad layout
occurs on page 9 of the last issue of the Moby Munger.
TECO-8 also supports expanded length MUNG command lines and
allows an alternative way to chain to TECO so that the
command line will be parsed by a TECO macro called TECO. TEC
instead of by CCL. Unfortunately, both of these features
requires corresponding support by CCL, which is not present
in the CCL distributed by DEC. Perhaps sometime in the
near future, a fix to CCL will be issued by the SIG.
The new features in TECO-8 which were not in OS/8 TECO V5
are described on the following pages.
---- Detail 2 ----
The second page of TECO.PA begins:
/BROUGHT TO YOU BY: RUSS HAMM, O.M.S.I.,
AND RICHARD LARY (IN THAT ORDER)
/WITH ASSISTANCE FROM MARIO DENOBILI OF THE P?S
/PATCHES INCORPORATED BY S.R. ON 5-AUGUST-75 FOR OS/8 V3C:
/1. UPDATED VERSION # TO V4
/2. INCORPORATED PATCHES #S 1 & 2 (V302 AND V303)
...
/WITH ASSISTANCE FROM MARIO DENOBILI OF THE P?S
/PATCHES INCORPORATED BY S.R. ON 5-AUGUST-75 FOR OS/8 V3C:
/1. UPDATED VERSION # TO V4
/2. INCORPORATED PATCHES #S 1 & 2 (V302 AND V303)
...
as does the second page of TECO.MA. The patches inventoried in TECO.PA are all present in TECO.MA.
The list of four known bugs is also present with a fifth one added.
/KNOWN BUGS
/1. LARGE T OR X AND ONLY 1 BLOCK LEFT IN OUT DEV
/2. ^S DOESN'T KEEP SCREEN ON (ON PDP-12)
/3. FIX BATCH INTERRACTION
/4. MAKE VT AND FF SIMULATION INDEPENDENT OF TAB
/5. ^T COMMAND (WITH ECHO ON) READS DOLLAR SIGN FOR TYPED ALTMODE
After patch 49, common to both sources, TECO.MA inventories changes for versions 6, 602, 604, 605, 606, and 7.
...
/VERSION 606 CHANGES:
/113. ADDED IF-THEN-ELSE
/VERSION 7 CHANGES:
/114. PUT AID ^S BACK IN (SAME AS *)
Rick Murphy wrote:
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAPdDV0g_iXsfPH908EP0YAAteBZ5M9gXoo%2BKTwdmPC7d6AZdZg%40mail.gmail.com.
Bill Cattey
Mar 19, 2018, 10:55:35 PM3/19/18
to Warren Young, PiDP-8
Re: possible conflicts
with scripted builds: I'm still thinking.
My @dayjob and a Chorus performance hoovered up all my spare time for the past several days.
I did take some time to read through your description of the object oriented approach to packaging.
It's very different from how I was thinking of doing things, but I'm giving myself time to understand it
and to try and benefit from the new ideas.
For that reason, I'm taking some time to meditate on the next steps for the script driven building.
I think that the thing I've been working hardest on is this:
What functionality is required to offer flexibility in device configuration?
The file copyins and dependencies are actually very simple.
What's hard is driving BUILD and SIMH configuration in a useful, comprehensible
structure that enables accommodating the horrible, incompatible, cross-dependant
device configurations.
I'm hoping to have the next level of understanding for doing this stuff before too long.
A couple small steps do occur to me:
1. The present VTEDIT config option simply can't work. The underlying TECO is no good.
2. Replacing TECO.SV with a useful one, is easily doable.
3. Conditionalizing the application of TECO patches on a TECO config parameter is doable with the current setup,
just like we did for FUTIL with MACREL.
4. The way patching and installing software will change when the script-driven system is a bit better firmed up.
I continue to keep a "level of effort timer" going to monitor "beware second system syndrome."
-Bill
-Bill
Warren Young wrote:
My @dayjob and a Chorus performance hoovered up all my spare time for the past several days.
I did take some time to read through your description of the object oriented approach to packaging.
It's very different from how I was thinking of doing things, but I'm giving myself time to understand it
and to try and benefit from the new ideas.
For that reason, I'm taking some time to meditate on the next steps for the script driven building.
I think that the thing I've been working hardest on is this:
What functionality is required to offer flexibility in device configuration?
The file copyins and dependencies are actually very simple.
What's hard is driving BUILD and SIMH configuration in a useful, comprehensible
structure that enables accommodating the horrible, incompatible, cross-dependant
device configurations.
I'm hoping to have the next level of understanding for doing this stuff before too long.
A couple small steps do occur to me:
1. The present VTEDIT config option simply can't work. The underlying TECO is no good.
2. Replacing TECO.SV with a useful one, is easily doable.
3. Conditionalizing the application of TECO patches on a TECO config parameter is doable with the current setup,
just like we did for FUTIL with MACREL.
4. The way patching and installing software will change when the script-driven system is a bit better firmed up.
I continue to keep a "level of effort timer" going to monitor "beware second system syndrome."
-Bill
-Bill
Warren Young wrote:
--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ucVmahUjPQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/00ecbd48-48d6-478a-930a-13020791ff86%40googlegroups.com.
Warren Young
Mar 19, 2018, 11:45:51 PM3/19/18
to PiDP-8
On Monday, March 19, 2018 at 8:31:41 PM UTC-6, William Cattey wrote:
Together with a bit of google searching, I have the following "TLDR" understanding to offer:
That's a lovely bit of historical sleuthing, thanks!
4. It seems definitely worthwhile to craft a "TECO-8 v7 with VTEDIT" package to install on the OS/8 rk05 packs
we distribute for the PiDP-8/i.
At this point, it is just good to know that a path exists and what the steps along it are.
I'm not sure when I'll be able to do this work. I'm in the middle of a couple other projects for the OS/8
stuff: V3F, and a re-imagining of the mkos8 system for building packs.
As always, no demands from me.
Do you want me to just file it as a feature request?
I did take some time to read through your description of the object oriented approach to packaging.
It's very different from how I was thinking of doing things, but I'm giving myself time to understand it
and to try and benefit from the new ideas.
This project is a do-ocracy: he who does the work makes the rules. I offered design ideas because you asked, but you're under no obligation to do it my way. I only get to insist on that if I'm going to do the work, and I don't see it being productive for both of us to be working towards two different package system implementations.
What's hard is driving BUILD and SIMH configuration in a useful, comprehensible
structure that enables accommodating the horrible, incompatible, cross-dependant
device configurations.
Perhaps the problem is that you've got an imperative scripting language and a bunch of imperative rules that must be followed — e.g. Can't generate RX28 boot media without building OS/8 V3F first — which invites conflicts.
Maybe a declarative approach would work better in place of the current scripting language? That is, the "script" becomes more like a Makefile, HTML, or SQL, in that each source file describes *what* the creator wants achieved without saying *how* it must be achieved. Then the language interpreter builds up the data structures to describe the initial state and works out how to get from there to the final state.
In a Makefile, the key data structure is the dependency graph. make(1) traverses the graph until all requested targets are built or a fatal error occurs.
In HTML, the data structures are the DOM for the tags and the CSS rules for the styling. The browser engine does a lot of clever work to produce a rendered web page in as little time as possible, often by putting in a lot of work up front on the data structures to save rendering and updating time later, and to resolve conflicts up front.
In SQL, the query planner and execution engine does a lot of work up front on the raw query strings and indices to produce an execution plan in as little time as possible while trying to achieve the goal of minimum I/O while reliably doing all of the requested operations.
All of these approaches require a lot of time and attention in the interpretation phase, but it's easier in the end on the script programmer, not only because mechanism is left to the interpreter, but also because there are fewer unrepresentable states. Every input is either an error or it has a definite, deterministic output.
This email, too, is declarative, describing only what, not how. ;)
Warren Young
Mar 19, 2018, 11:55:56 PM3/19/18