gnu@hoptoad.uucp (John Gilmore) (05/26/89)
I have a lot of trouble in reading existing PostScript applications
for NeWS (such as the demos). Much of my trouble is an ongoing
uncertainty about exactly what environment each chunk of code
runs in.
For example, some code runs in the "mainline" of the application,
some in event handler processes, some inside "send"s, etc. I find
that I have no easy way to predict what process something runs in,
and/or what is on its dictionary stack when it runs.
I am groping my way toward a discipline that would make applications
more readable and understandable. The first step is to have most
significant actions occur in the mainline code, by sending events
from event handlers back to the mainline code. This eliminates
a lot of race conditions and scope problems.
A second step that I'm thinking about is to textually structure a
NeWS application such that ALL the code that runs in a given process
context is adjecent in the source file. The only interactions done
across process boundaries would be done by passing NAMES across
the boundary -- not chunks of code.
I haven't tried this out yet. Any comments on the topic in general,
or on my specific ideas?
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.warw@cgch.UUCP (Anthony R. Wuersch) (05/30/89)
John Gilmore brings up two issues, directory stacks and lightweight
process management. Also the general problem of reading NeWS code.
I've started reading the 1.1 NeWS libraries lately. My suggestions
are based on what I've had to scribble in the columns of my code
printout.
* Empty the operand stack as early and as often as possible.
Let 'eat-two' == { pop pop } . Then
arg arg eat-two
arg arg eat-two
is easier for me to read than
arg arg arg arg eat-two ... eat-two .
Emptying the operand stack is like executing a statement; I'm
just asking for the simplest statements.
* Use a distillery application. Don't flow analyze and optimize by
hand. Distilling seems to me the way to handle naming problems.
Use the names you want. Let distillation wipeout the names you
don't need at runtime.
It's unfortunate for we readers that undistilled NeWS names cost
so much.
* It looks like there are three kinds of directory stacks:
- *environments* are stable and contain lots of procedure defs
added on the fly
- *class instances* are instantiations of abstract data types,
i.e., collections of data and procedures which are replicated
from a class [ some named dictionary ]
- *local bindings* are scratch directories which a distillery program
could put on the stack [ *we* do that now with PostScript, but one
can dream ]
Environments should have names. Class instances and local bindings
should cite the environment [and/or class instances] they need in
a side comment.
* Use class instances instead of processes to store data.
* Create new lightweight processes *only* to catch events.
Maybe there are further *practical* uses for lightweight processes
[ I'm open to suggestions ], but I wonder what. I'd rather reload
a class instance event handler than spawn anew.
Toni