What were "shadow blocks"?
Richard Owlett
"shadow blocks". What were they? How were they used? Where can I go to
read up on them?
My application has nothing to do with Forth. Something I once read is
trying to rise to surface in connection with a documentation problem I'm
working on. I'm going on the theory if I read about enough different
ways of doing documentation I'll have an AHHSOOOO moment (I can hope
can't I ;)
Thanks
Elizabeth D Rather
Early Forths ran native on minicomputers. They managed disk in
1024-byte blocks, with a block address being a static function of the
head/track/sector location on disk (typically, a block was 2 or more
sectors). Blocks were used both for data and for source. Even after
Forths began running under OSs such as MS-DOS, blocks were retained for
compatibility with native Forths. On these systems blocks resided in OS
files.
In the late 70's Chuck Moore (then working at FORTH, Inc.) invented a
documentation scheme in which each block of source had an associated
block for documentation. Printing utilities could print them
side-by-side, and at a terminal you could toggle back and forth with a
single keystroke. It was very convenient and successful, and was used at
FORTH, Inc. (as well as other places) until the late 90's.
Hope this helps.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
jch
Shadow blocks are typically 1,024 bytes of text that document Forth
source code. Frank Sargent's Pygmy v1.4 and 1.5+ implement shadow
blocks. A hot key switches between source code and its associated
shadow block. I find it very useful. Any program written using Pygmy
can be built with shadow blocks.
--
Regards / JCH
m_l...@yahoo.com
> I vaguely recall a documentation scheme which used something called
> "shadow blocks". What were they? How were they used? Where can I go to
> read up on them?
>
> My application has nothing to do with Forth.
Now, in addition to what Elizabeth and jch wrote:
In old Forths, jumping to and from a shadow screen was, depending
on the block number, just addition or subtraction of a hard-coded
constant. (If after addition block number gets greater than the
number of blocks, it's clear that you had to subtract instead.
Maybe, someone used XOR to toggle a bit.)
In about 2000, I have made some experiments trying to combine
the features of a text block and a file.
(1024=16x64 blocks coerced a very good modularity.)
I subdivided a text file into logical blocks of arbitrary size.
\ =========================================
BLOCK: auxiliary-stuff
: foo ... ;
: bar ... ;
\ ========================================
BLOCK: i/o-stuff
0 VALUE the-file
: ?io abort" i/o error" ;
: read the-file READ-FILE ?io ;
...
The \ ============= comment was highlighted in the editor, and
so was the BLOCK: line. I used the FAR Manager's build-in editor
with the Colorer plug-in (and IIRC Colorer was not the latest
version because the latest version was too complex).
I could disable some blocks by adding - in front of BLOCK:
\ ========================================
-BLOCK: i/o-stuff
0 VALUE the-file
: ?io abort" i/o error" ;
: read the-file READ-FILE ?io ;
...
Of course, -BLOCK: also was a Forth word.
In principle, it was possible to have shadow blocks of the same
structure.
FAR Manager allows writing plug-ins, so... but I did not want to
write
FAR plug-ins, and I did not want to be so much dependent on FAR.
But there was no universal way to position text in another text
editor window to a location logically related to this location.
The Javadoc/Doxygen approach is to have comments and data in the
same place. This is not really good, at first, docs take too
much place on the screen (but that's of course not so big a problem
if the functions occupy 2 screens and the IDE provides a
function-list view), and at second, the problems begin if you
want bilingual comments (again not a problem if everyone is forced
to use English or Bad English).
Nevertheless, the fact that the Java/C++ solution is to have docs
and code in the same place shows that the problem hasn't
been solved in these communities.
One more approach was invented at coldforth.teegra.net (you probably
still can find a mirror).
The Forth source is html. You have a Forth parser that loads
the code from html, ignoring other stuff; if you view the code in
a browser, you read it as html.
Probably you can automatically (with a script on demand?) convert
the source into html, and have anchors so that you would be able
to synchronize the code view and the document view.
You will have an http server on some port and a web interface.
And editable HTML is WIKI, so you will probably borrow something
WIKIish.
For the final release, you may prefer to have a directory
of HTML docs instead, so that offline browsing would be possible.
wget -r -k http://127.0.0.1:8090/myproject/
would help, but the command looks really funny
astrobe
I'm on this, too, but in connection with Forth.
I've build in my system a help tool based on blocks, but in separate
block files (I allow multiple blockfiles as Pygmy does); but I've also
docs in HTML format.
Documenting a Forth system is a vaaast topic. Because it's not only an
application, a library, or a language: it's all that and the
implementor has to document it all, and the documentation may target
total CS newbies and Forth experts.
I drew the conclusion that all this should be in one place. HTML is
one option, but from my perspective it should be integrated to the
system, so I'm going for putting all in my block-based help tool.
Which is quite a challenge because of the 1024 characters limit. But
that inforces structure and appropriate verbosity. I also concluded
that documentation is like software: one has to really think about it
to avoid duplication, find a good structure, and test it a lot:
documentation "bugs" (wrong and/or out of date data) are likely to
lose the user's time and worse, it's confidence in the whole system.
As a corollary I also concluded like Chuck Moore that code and
documentation should be separated, in other words, code should have
very few comments. But the I'm a bit puzzled that colorforth still, it
seems, have shadow blocks; it is somewhat in contradiction with his
POV. But I've not yet looked into them to see what's in them.
Amicalement,
Astrobe
Bruce McFarling
> In principle, it was possible to have shadow blocks of the same
> structure.
> FAR Manager allows writing plug-ins, so... but I did not want to
> write FAR plug-ins, and I did not want to be so much dependent
> on FAR.
> But there was no universal way to position text in another text
> editor window to a location logically related to this location.
The most straightforward approach is, of course, to intersperse the
code section and the doc section, and the hotkey simply toggles
between the doc sections being visible and the code sections being
visible.
That could be done with a block comment word like ==[
==[ Section title ]======[ brm2007.08.28.20.07 ]==
= Note that everything after ==[ until the first "\"
= comment line with the "\" in the first column is
= passed over. All of this would vanish with the
= code hotkey
\ this is the start of code ... of course, the first
\ line can be discarded by ==[ because it is a \ comment
\ all of this would vanish with the doc hotkey
: foo ( u1 n1 -- flag ) bar NIP 0= ;
...............
of course, the editor would show the ==[ line in both modes, and there
would be PageUp and PageDn actions to jump to the next or previous
section.
Richard Owlett
Thank you. That was pretty much as I had remembered it. It must be
something else from the same time period that is triggering associations.
werty
Tranparency means , ya dont gotta work , keep notes , just to make it
work .
Files and Folders are poison , the opposite of transparency .
They are dead , leave them alone .
Bill Gates made $$ ,denying us the ability to link files .
Linus only gave us SoftLinks . Its all bogus .
New Forth is all in one O.S. on ARM only , it has no Files ,
Folders ,
no ASCII , no English , No KeyBoard , no work at all !
It analyses all, compresses , writes to an area , with links ,
DONE !
Richard Owlett
> Tranparency means , ya dont gotta work , keep notes , just to make it
> work .
> [OP snips garbage];
Anybody going to suggest werty even LOOKED AT my post, let alone *READ it* ?
Trey Boudreau
I'd almost forgotten it existed. Do yourself a favor and do the same.
-- Trey
Richard Owlett
Actually I'm the eternal optimist.
there may even be hope for ....
John Passaniti
> Actually I'm the eternal optimist.
> there may even be hope for ....
Give up.
When werty writes something that's comprehensible, he's describing two
things that already exist. First is the notion of object databases
storing information in terms of relationships to other objects (modulo
whatever one wants to call an object). Second is the idea of a visual
programming language, possibly based on data-flow concepts to get away
from a strictly procedural view of programming.
And that's being generous. If there is anything of value in werty's
messages, he is clearly not the one to express it. It could be he has a
problem with English, or it could be organic brain dysfunction. Hard to
say for sure, and even harder to care.
At best, werty sees his role as promoting futuristic concepts and hopes
that someone will run with his vague ideas and actually implement
something worthwhile. It's much the same as with Arthur T. Murray.
He's expecting people to take his ideas, work out the hard problems
embedded in them, and come up with something interesting or useful.
Both are in the business of creating memes that (they hope) cause others
to do the actual work.
werty has finally given his name-- Thomas Lloyd Scott. That's probably
a pseudonym, but it's a fine search term for Google and will provide
additional amusement for anyone wanting to follow him elsewhere.
Jerry Avins
...
> werty has finally given his name-- Thomas Lloyd Scott. That's probably
> a pseudonym, but it's a fine search term for Google and will provide
> additional amusement for anyone wanting to follow him elsewhere.
You might start here: http://en.wikiversity.org/wiki/ARM_Assembly_Language
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Charlie Springer
(in article <13d4djt...@news.supernews.com>):
> I vaguely recall a documentation scheme which used something called
> "shadow blocks". What were they? How were they used? Where can I go to
> read up on them?
They were the beginning of the end.
-- Charlie Springer