Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #35605 > unrolled thread

blocks and screens, tell your war stories

Back to article view | Back to comp.lang.forth

Contents

  blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 11:08 -0800
    Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 12:35 -1000
      Re: blocks and screens, tell your war stories empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-08 23:24 +0000
        Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 15:36 -0800
          Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 16:42 -1000
            Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 22:55 -0800
              Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:12 -1000
                Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 23:27 -0800
                  Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:41 -1000
                    Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-09 02:21 -0800
                      Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 09:21 -1000
                        Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-09 13:07 -0800
                          Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 11:46 -1000
                        Re: blocks and screens, tell your war stories empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-11 13:58 +0000
                          Re: blocks and screens, tell your war stories "Alex McDonald" <blog@rivadpm.com> - 2015-01-13 14:37 +0000
        Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 18:30 -1000
          Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 20:47 -0800
            Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 20:49 -1000
              Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-09 13:02 -0800
    Re: blocks and screens, tell your war stories a.daniel.eliason@gmail.com - 2015-01-08 14:45 -0800
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 15:50 -0800
    Re: blocks and screens, tell your war stories Doug Hoffman <glidedog@gmail.com> - 2015-01-08 22:34 -0500
      Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 17:48 -1000
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 21:13 -0800
        Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:09 -1000
      Re: blocks and screens, tell your war stories Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-09 09:34 +0100
        Re: blocks and screens, tell your war stories Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-09 12:26 +0100
    Re: blocks and screens, tell your war stories Stan Barr <plan.b@bluesomatic.org> - 2015-01-09 08:10 +0000
      Re: blocks and screens, tell your war stories JennyB <jennybrien@googlemail.com> - 2015-01-09 03:36 -0800
    Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-09 14:14 +0000
      Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-09 15:25 +0000
        Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-09 20:20 +0000
          Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-09 20:47 +0000
          Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-09 13:08 -0800
            Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-09 21:34 +0000
              Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-10 14:00 -0800
                Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-11 11:45 -0800
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-09 13:28 -0800
        Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-10 22:41 +0000
          Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-10 18:49 -0800
            Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-11 09:27 +0000
              Re: blocks and screens, tell your war stories stephen@mpeforth.com (Stephen Pelc) - 2015-01-11 11:51 +0000
      Re: blocks and screens, tell your war stories Steve Graham <jsgrahamus@yahoo.com> - 2015-01-12 14:46 -0800
        Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-13 00:30 +0000
    Re: blocks and screens, tell your war stories Wolf Wejgaard <wejgaard@gmail.com> - 2015-01-12 06:32 -0800
    Re: blocks and screens, tell your war stories rickman <gnuarm@gmail.com> - 2015-01-12 20:35 -0500
      Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-13 03:06 -0800
        Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-25 18:25 +0000
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-15 23:08 -0800
        Re: blocks and screens, tell your war stories m.a.m.hendrix@tue.nl - 2015-01-16 03:09 -0800
        Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-16 18:25 +0000
        Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-25 21:05 +0000
          Re: blocks and screens, tell your war stories Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-26 01:08 +0100
            Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-26 00:56 +0000
            Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-26 02:12 +0000
              Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-26 18:09 +0000
                Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-27 07:42 +0000
                  Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-27 01:25 -0800
                  Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-29 10:20 +0000
            Re: blocks and screens, tell your war stories anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-26 12:10 +0000
              Re: blocks and screens, tell your war stories Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-26 22:18 +0100
          Re: blocks and screens, tell your war stories Doug Hoffman <glidedog@gmail.com> - 2015-01-27 08:44 -0500
    Re: blocks and screens, tell your war stories "HAA" <someone@microsoft.com> - 2015-01-14 10:23 +1100
      Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-13 19:47 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#35605 — blocks and screens, tell your war stories

I wonder if those of you who developed Forth programs in the era of
blocks and screens could say what it was like, compared to today's Forth
environments.

What Forth system did you use?  What code editor?  What hardware?

Did you use the scheme of having a comment screen for each code screen?

What kind of planning process did you use, before you started coding?
E.g. did you write a (maybe informal) code glossary ahead of time?

Did you feel constrained by the 64 char lines, especially if you used
stack comments?  Were stack comments expected then the way they are now?

How did you debug?  Was it common for the whole machine to lock up if
your program had a bug that clobbered memory?  What did you do when that
happened?

How did development time for a Forth program compare to writing
something similar in BASIC, for the problems BASIC could handle?  I know
that Forth could do a lot of things that were essentially impossible in
BASIC, but I'm not asking about those.

[toc] | [next] | [standalone]

#35609

On 1/8/15 9:08 AM, Paul Rubin wrote:
> I wonder if those of you who developed Forth programs in the era of
> blocks and screens could say what it was like, compared to today's Forth
> environments.
>
> What Forth system did you use?  What code editor?  What hardware?

Well, when I first started (1972) it was just Forth. When Chuck and I 
started FORTH, Inc. in 1973, we developed our first product, miniFORTH 
(for Minicomputers). It was block-based, and ran fully native on a 
variety of minicomputers. Disk block #s were a function of their 
physical track/sector address, so there was no directory. These systems 
were incredibly robust, as conventional OS-based systems were prone to 
get their directories trashed (which still happens today, though 
thankfully more rarely). They were also incredibly fast.

We had a block editor with an extensive command set, much more powerful 
than the one described in Starting Forth.

In the early 80's we developed polyFORTH, which had the same basic 
characteristics as miniFORTH but a lot more capabilities, things we had 
developed over time, including the graphics package, a more 
sophisticated database, a GUI, and other tools. We developed SwiftForth 
and SwiftX in the 90's, as Windows platforms. Linux and OSX versions 
came several years ago.

> Did you use the scheme of having a comment screen for each code screen?

Yes. Chuck invented that strategy. We organized source in "triads", 3 
blocks that fit on a printed page, and tried to keep topics (disk drive, 
double-precision math, etc.) to one or more triads, rather than having 
topics mixed up. The printing utility printed a triad of code with its 
matching triad of "shadow blocks" on a page, with the shadows next to 
the corresponding code block. The printing utility could print an "index 
page" (the first line of each of 60 blocks). So, the first line of each 
block identified its contents, and it was easy to find things. Larger 
scale organization was based on units of 60 blocks (basic Forth, data 
base management, graphics package, metacompiler, etc.)

Interactively, you could LOCATE a definition, after which Q would toggle 
back and forth between the code block and its shadow.

> What kind of planning process did you use, before you started coding?
> E.g. did you write a (maybe informal) code glossary ahead of time?

We identified major components of the application and what support 
facilities it would need. We tried to write top-level definitions, with 
stubs for things to be developed. We also worked on drivers & math 
functions, so it was a combination of top-down design and bottom-up 
development and testing. When I was working with Chuck, I usually did 
the database and user interface, while Chuck did drivers, math, and 
other technical things.

> Did you feel constrained by the 64 char lines, especially if you used
> stack comments?  Were stack comments expected then the way they are now?

Not constrained at all. Lines are equally important in file-based 
source, after all. And, yes, always stack comments! They're really 
essential. They go in the definitions; usage info goes in the shadow blocks.

> How did you debug?  Was it common for the whole machine to lock up if
> your program had a bug that clobbered memory?  What did you do when that
> happened?

The same way we debug now. For debugging application code, I load the 
app and try the function I'm working on. If I get an error message, I 
type successive words in the definition in question, watching what's on 
the stack, until I see what's going wrong.

Yes, it crashes sometimes (not often), but with a native Forth (or even 
a DOS Forth) it only takes a few seconds to reboot. Windows is a lot 
worse in that regard! The most common cause of a crash is a stack 
runaway, so if that happens I immediately focus on stuff going on inside 
a loop.

When working with hardware, there's an exploratory phase that involves 
writing to I/O ports to see that they behave as expected (with custom 
hardware, they sometimes don't!). Forth lets you do that interactively, 
which is very helpful.

> How did development time for a Forth program compare to writing
> something similar in BASIC, for the problems BASIC could handle?  I know
> that Forth could do a lot of things that were essentially impossible in
> BASIC, but I'm not asking about those.

Well, I never programmed in BASIC (or C for that matter). I have used 
Fortran and assembler a lot, and some Algol variants. I find development 
to be vastly faster and easier with Forth than any of them. My 
colleagues who have programmed in C say that Forth is at least 4x faster 
to get results.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35612

In comp.lang.forth, Elizabeth D. Rather wrote:

> The printing utility printed a triad of code with its 
> matching triad of "shadow blocks" on a page, with the shadows next to 
> the corresponding code block. The printing utility could print an "index 
> page" (the first line of each of 60 blocks).

So the print-out was done on the rule "code-shadow, code-shadow" - and how
was the layout of the blocks? The same "interleaved" way - or, for example,
set of code blocks (like 1, 2, 3...) and offset to corresponding set of
shadow blocks (e.g. 101, 102, 103..)?
-- 
"Yes, this is the bad end you've come to, and two and two is - as it always
was..." - began Trurl, but just then the machine made a faint, barely audible
croaking noise and said, for the last time: "SEVEN".

[toc] | [prev] | [next] | [standalone]

#35613

empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com>
writes:
> So the print-out was done on the rule "code-shadow, code-shadow" - and how
> was the layout of the blocks? 

I was wondering that too.  I've seen printout from old line printers,
that used 14" wide paper, for 60 lines of 132 columns.  So I imagine
that the code and shadow blocks were printed side by side, 64 columns
each plus a little bit of vertical separation, plus some horizontal
separation between the blocks.

Elizabeth, did you actually use printouts very much?  What kind of
terminals or consoles did you use when writing code?  No punch cards I
hope ;-).

[toc] | [prev] | [next] | [standalone]

#35622

On 1/8/15 1:36 PM, Paul Rubin wrote:
> empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com>
> writes:
>> So the print-out was done on the rule "code-shadow, code-shadow" - and how
>> was the layout of the blocks?
>
> I was wondering that too.  I've seen printout from old line printers,
> that used 14" wide paper, for 60 lines of 132 columns.  So I imagine
> that the code and shadow blocks were printed side by side, 64 columns
> each plus a little bit of vertical separation, plus some horizontal
> separation between the blocks.
>
> Elizabeth, did you actually use printouts very much?  What kind of
> terminals or consoles did you use when writing code?  No punch cards I
> hope ;-).

We used printed listings extensively, until into the 90's, because we 
were programming on the customer's computer, and needed to take listings 
home to study in the evenings and after the project, for customer 
support and archival purposes. Until the advent of the PC and 
standard-format floppy disks there was no common media for carrying code 
around.

Blocks have to be printed in sequence, and so do shadow blocks. We 
printed them portrait on 8-1/2x11 paper and kept them in a binder. We 
could get the entire OS and a typical application in a single half-inch 
binder (really gnarly applications required a 1" binder). We taught the 
printing utility to print all the blocks and then turned the paper over 
and printed the shadows on the reverse side, so when we put them in the 
binders the shadows were on the facing page. Later when printers had 
enough resolution, we printed the blocks & shadows side-by-side on the page.

As for terminals: in the early 70's, terminals were teletypes! We got a 
Tektronix graphics terminal and a 24x80 CRT terminal in 1973, but 
continued to encounter TTYs at customer sites for some years. Happily, 
we never had to use punch cards, but we did use punched paper tape for a 
few years until floppy disks came out.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35635

"Elizabeth D. Rather" <erather@forth.com> writes:
> As for terminals: in the early 70's, terminals were teletypes! We got
> a Tektronix graphics terminal and a 24x80 CRT terminal in 1973,

Did you still uses 16x64 screens when coding on the 24x80 terminal?
Blocks of 2k could have worked pretty nicely for 24x80=1920.

Did 16x64 get in the way very much?  I notice a fair number of my Forth
lines are > 64 chars, and the stack comments partly account for that.

[toc] | [prev] | [next] | [standalone]

#35637

On 1/8/15 8:55 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> As for terminals: in the early 70's, terminals were teletypes! We got
>> a Tektronix graphics terminal and a 24x80 CRT terminal in 1973,
>
> Did you still uses 16x64 screens when coding on the 24x80 terminal?
> Blocks of 2k could have worked pretty nicely for 24x80=1920.
>
> Did 16x64 get in the way very much?  I notice a fair number of my Forth
> lines are > 64 chars, and the stack comments partly account for that.

On those terminals, we could see the block of source we were working 
with on the screen, and have a region of separately scrolling lines 
below it for interactive testing of that code. And, of course, we had 
line numbers to the left of the block, so we used at least 70 chars of 
width for the block display.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35639

"Elizabeth D. Rather" <erather@forth.com> writes:
>> Did you still uses 16x64 screens when coding on the 24x80 terminal? ...
> On those terminals, we could see the block of source we were working
> with on the screen, and have a region of separately scrolling lines
> below it for interactive testing of that code.

Aha, that partly answers my other question, about "fancy coding
environments".  I use gforth under Emacs and it seems invaluable to have
the code on the screen while you're testing it.  With Emacs I use a code
editing window and a gforth interaction window, and with MS Windows you
can do similar things.  Emacs has a command to send the current
paragraph or buffer from the edit window to the Forth window and I guess
you may have had something similar.

I was expecting 16x64 screens arose because that was how many characters
that fit on the screens of older computers.  If you were using 24 line
screens with 7 or 8 lines for Forth interaction, that would help a lot.

Was the Saudi airport project done with 16x64 screens on 24x80
terminals?  Was it done with blocks rather than files?  How much code
was there?

[toc] | [prev] | [next] | [standalone]

#35641

On 1/8/15 9:27 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> Did you still uses 16x64 screens when coding on the 24x80 terminal? ...
>> On those terminals, we could see the block of source we were working
>> with on the screen, and have a region of separately scrolling lines
>> below it for interactive testing of that code.
>
> Aha, that partly answers my other question, about "fancy coding
> environments".  I use gforth under Emacs and it seems invaluable to have
> the code on the screen while you're testing it.  With Emacs I use a code
> editing window and a gforth interaction window, and with MS Windows you
> can do similar things.  Emacs has a command to send the current
> paragraph or buffer from the edit window to the Forth window and I guess
> you may have had something similar.

Well, in the block-oriented Forths the editor was part of the system, so 
nothing was sent anywhere. In modern systems, one can use the 
programmer's editor of choice. SwiftForth can launch a linked editor 
pointed at the line in the file of interest, but the editor doesn't need 
to send SwiftForth anything.

> I was expecting 16x64 screens arose because that was how many characters
> that fit on the screens of older computers.  If you were using 24 line
> screens with 7 or 8 lines for Forth interaction, that would help a lot.

The dimensions were chosen because that's the most convenient 
representation of 1024 characters, which is the block size. Things like 
line numbers are outside the block, of course.

> Was the Saudi airport project done with 16x64 screens on 24x80
> terminals?  Was it done with blocks rather than files?  How much code
> was there?

Yes, it was all block-oriented. I'm afraid I don't remember how many 
blocks there were in total. All the source was kept on the disks of the 
PDP-11's, and most of the editing was done there, too, via the network. 
Most of the x86's didn't have terminals.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35646

For me, the most inconvenient aspect of blocks is running out of space.

For example, I need to change, or insert a definition on block 60, which means lines spilling off the end of the block, however, I can't move those lines onto block 61, because it's already full.

That's when you end up writing utilities to move blocks up or down by one, in order to insert blank blocks.

It's by far the worst aspect of blocks. Aside from that, I don't have an issue with them.

The most convenient aspect? They're just a large array on a disk, so they're very convenient for storing data (in any format: binary or ASCII etc). That is really nice. So simple to load data into memory quickly via BLOCK.

[toc] | [prev] | [next] | [standalone]

#35662

On 1/9/15 12:21 AM, Mark Wills wrote:
> For me, the most inconvenient aspect of blocks is running out of space.
>
> For example, I need to change, or insert a definition on block 60, which means lines spilling off the end of the block, however, I can't move those lines onto block 61, because it's already full.
>
> That's when you end up writing utilities to move blocks up or down by one, in order to insert blank blocks.
>
> It's by far the worst aspect of blocks. Aside from that, I don't have an issue with them.

Yes, I'd have to agree with that. The line length is not an issue, but 
the 16 lines can be. All I can say is, with experience you get better at 
judging whether a task you're attacking is a one-block, 3-block, or 
longer one, and if you feel it's a multi-block problem you decide what 
parts to put in which blocks. Then you leave a lot of spare lines (I try 
to leave half the block empty at first).

As a matter of practice, we don't move things by 1 block very often, 
because we're trying to maintain a clear triad organization. Some topics 
end up taking only one block of a triad, and we leave the rest.

> The most convenient aspect? They're just a large array on a disk, so they're very convenient for storing data (in any format: binary or ASCII etc). That is really nice. So simple to load data into memory quickly via BLOCK.
>

Indeed. Blocks are perfect for data storage. Our database system was 
based on blocks.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35668

"Elizabeth D. Rather" <erather@forth.com> writes:
> As a matter of practice, we don't move things by 1 block very often,
> because we're trying to maintain a clear triad organization. Some
> topics end up taking only one block of a triad, and we leave the rest.

That is written in the present tense: does Forth Inc. still use block
editing on some systems?  I believe the GreenArrays system uses them,
which I actually find pretty cool.

[toc] | [prev] | [next] | [standalone]

#35675

On 1/9/15 11:07 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> As a matter of practice, we don't move things by 1 block very often,
>> because we're trying to maintain a clear triad organization. Some
>> topics end up taking only one block of a triad, and we leave the rest.
>
> That is written in the present tense: does Forth Inc. still use block
> editing on some systems?  I believe the GreenArrays system uses them,
> which I actually find pretty cool.
>

My mistake, we rarely see blocks any more (mostly when maintaining past 
applications). Yes, Greenarrays licenses polyFORTH from us. I don't 
think their system has all the bells and whistles (database, graphics, 
etc.) that polyFORTH had, but the architecture would be the same.

There was an intermediate stage that I should mention, though: from the 
early to mid-80's when we ran polyFORTH under DOS on PCs we kept blocks 
in DOS files.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35714

In comp.lang.forth, Elizabeth D. Rather wrote:

> Yes, I'd have to agree with that. The line length is not an issue, but 
> the 16 lines can be.

Andy Valencia addressed this issue sane way in his ForthOS:

#v+
Unlike most POSIX-oid Forth systems, ForthOS is still block based, and still
uses shadow screens for commenting source code. However, to reflect the
relentless march of technology, ForthOS blocks are now 4096 bytes instead of
1024, with a source screen size of 2000 bytes (80 columns by 25 lines). The
source code "shadow" screen is therefore on the same block, in the next 2000
bytes of the screen. The last 96 bytes of a source block are reserved for
the ForthOS filesystem.
#v-

http://www.forthos.org/fs.html

It looks sensible; contemporary HDDs use physical block length of 4096 bytes.
-- 
"Yes, this is the bad end you've come to, and two and two is - as it always
was..." - began Trurl, but just then the machine made a faint, barely audible
croaking noise and said, for the last time: "SEVEN".

[toc] | [prev] | [next] | [standalone]

#35783

on 11/01/2015 13:58:39, empty-buffers wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
> 
>> Yes, I'd have to agree with that. The line length is not an issue, but
>> the 16 lines can be.
> 
> Andy Valencia addressed this issue sane way in his ForthOS:
> 
> #v+
> Unlike most POSIX-oid Forth systems, ForthOS is still block based, and
> still uses shadow screens for commenting source code. However, to
> reflect the relentless march of technology, ForthOS blocks are now
> 4096 bytes instead of 1024, with a source screen size of 2000 bytes
> (80 columns by 25 lines). The source code "shadow" screen is therefore
> on the same block, in the next 2000 bytes of the screen. The last 96
> bytes of a source block are reserved for the ForthOS filesystem.
> #v-
> 
> http://www.forthos.org/fs.html
> 
> It looks sensible; contemporary HDDs use physical block length of 4096
> bytes.

That's very recent and a tiny fraction of the market. The sectors on
disks (most; there have always been specialised exceptions) are still 512
bytes. AF drives are 4KB, but it takes BIOS and OS support to use them
natively; most advertise themselves as 512 bytes in emulation mode. There
are very few AF drives that expose their 4KB capability, and even fewer
systems that support them. 99% of the world is still on a 512 byte
sector.

[toc] | [prev] | [next] | [standalone]

#35630

On 1/8/15 1:24 PM, empty-buffers wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
>
>> The printing utility printed a triad of code with its
>> matching triad of "shadow blocks" on a page, with the shadows next to
>> the corresponding code block. The printing utility could print an "index
>> page" (the first line of each of 60 blocks).
>
> So the print-out was done on the rule "code-shadow, code-shadow" - and how
> was the layout of the blocks? The same "interleaved" way - or, for example,
> set of code blocks (like 1, 2, 3...) and offset to corresponding set of
> shadow blocks (e.g. 101, 102, 103..)?

Yes, the numbering was offset by a fixed amount, usually 600. If that 
offset began to be too small, we'd factor out the system from the 
application. The offset was built into the editor and printing utility.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35631

"Elizabeth D. Rather" <erather@forth.com> writes:
> Yes, the numbering was offset by a fixed amount, usually 600. If that
> offset began to be too small, we'd factor out the system from the
> application. The offset was built into the editor and printing
> utility.

Did you ever have to move code or data blocks around and renumber them,
and update all the references in places where they were loaded?  Did
that happen often?  Was it a big hassle or just minor?

[toc] | [prev] | [next] | [standalone]

#35634

On 1/8/15 6:47 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Yes, the numbering was offset by a fixed amount, usually 600. If that
>> offset began to be too small, we'd factor out the system from the
>> application. The offset was built into the editor and printing
>> utility.
>
> Did you ever have to move code or data blocks around and renumber them,
> and update all the references in places where they were loaded?  Did
> that happen often?  Was it a big hassle or just minor?
>

In the first place, we organized "load blocks" to load whatever 
constituted a major part of the system or application, so loading wasn't 
scattered all over the place. We deplored the FIG practice of using --> 
to load sequences of blocks. We did have:

( Description) n1 n2 THRU

to load a range of blocks for a documented purpose. This supported 
excellent source management. If it became necessary to move blocks, as 
it occasionally did, there was only one other place that needed to 
change. Even for a fairly large application you could see the whole 
sequence by looking in only a few places.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#35667

On Thursday, January 8, 2015 at 11:49:50 PM UTC-7, Elizabeth D. Rather wrote:
> On 1/8/15 6:47 PM, Paul Rubin wrote:
> > "Elizabeth D. Rather" <erather@forth.com> writes:
> >> Yes, the numbering was offset by a fixed amount, usually 600. If that
> >> offset began to be too small, we'd factor out the system from the
> >> application. The offset was built into the editor and printing
> >> utility.
> >
> > Did you ever have to move code or data blocks around and renumber them,
> > and update all the references in places where they were loaded?  Did
> > that happen often?  Was it a big hassle or just minor?
> >
> 
> In the first place, we organized "load blocks" to load whatever 
> constituted a major part of the system or application, so loading wasn't 
> scattered all over the place. We deplored the FIG practice of using --> 
> to load sequences of blocks. We did have:
> 
> ( Description) n1 n2 THRU
> 
> to load a range of blocks for a documented purpose. This supported 
> excellent source management. If it became necessary to move blocks, as 
> it occasionally did, there was only one other place that needed to 
> change. Even for a fairly large application you could see the whole 
> sequence by looking in only a few places.

This is essentially what I did --- I had a "load screen" with a lot of THRU commands, and I didn't use --> at all.

One problem, as Mark Wills mentioned, was that the programmer had to guess ahead of time how many screens were needed for each part of the program. This wasn't much of a problem though --- it is easy to write a utility to move a chunk of screens to another place (I think UR/Forth came with that utility, although I may have written it myself; I can't remember) --- so long as the only place where screen numbers are referenced is the load screen, there is no need to search the program for references to fix.

The big problem is that you can't put a code-library (like my novice package) in a separate file --- there is nothing like INCLUDE that allows outside source-files to be used. The result is that, you have to cut-and-paste any general-purpose code into your application program's source-file. If this is done for several application programs, then it is unclear if every cut-and-pasted version of the general-purpose code is the same, or if some of them have been modified --- so, when you cut-and-paste your general-purpose code from some old program, you don't know if you have the original version or not, and you don't know what it does, so you have to relearn the whole thing again every time.

The chronic problem with Forth, starting in the 1970s and continuing up to the present, is a failure to support code-libraries containing general-purpose code --- this is why Forth is not used in commercial applications --- employers don't have the time or the money to allow their programmers to write every program from scratch every time, and cut-and-paste from old programs is a grossly error-prone practice.

At Testra, I started writing MFX using screens (MFX was written in UR/Forth, that had a very good screen editor). After some time my coworker complained to the boss about this, pointing out that it was company practice to use seq files --- I was told to switch over, and so I did --- I used MultiEdit (written by John Perona, a previous employee of Testra) for the seq files.

[toc] | [prev] | [next] | [standalone]

#35611

I suggest this book: http://thinking-forth.sourceforge.net/

As a matter of fact I recommend this book for anyone programming in ANY language.  There is a lot of good - VERY GOOD - guidance in there that is not necessarily tied to FORTH.

You will find your questions are answered in great detail, including interviews of FORTH programming team leaders, who explain their design process.

A best practice layout of code screens/blocks for non-trivial applications is discussed.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web