DARPA's $34M 1st-responder co-robots #messiah Stimulus

12.8: news.adds/robotics/
DARPA's $2M 1st-responder co-robots Challenge:
. faq and forums @ theroboticschallenge.org ...

2011.6: President Obama launches NRI:
. NRI (National Robotics Initiative) ... .

National Robotics Initiative

12.8: news.adds/robotics/NRI(National Robotics Initiative):

2011.6: President Obama launches NRI:
. the National Robotics Initiative
is funding the development of co-robots .
goals:

. the development and use of co-robots,
defined as robots that are co.workers;
ie, serving as member of in a team with employees,
or helping the physically or mentally impaired
-- in a symbiotic relationship with humans .
. supporters of co-robot development include:
National Science Foundation (NSF),
National Aeronautics and Space Administration (NASA),
National Institutes of Health (NIH),
and the U.S. Department of Agriculture (USDA).
. this program develops co-robots,
the next generation of robotics,
to advance the capability and usability
of such systems and artifacts,
and to encourage existing and new communities
to focus on innovative application areas.
It will address the entire life cycle
from fundamental research and development
to manufacturing and deployment.
. important parts of this initiative include
the establishment and infusion of robotics
in educational curricula and research
to gain a better understanding of the long term
social, behavioral and economic implications
of using co-robots across all areas of human activity .

Open Source Robotics Foundation, Inc

12.8: news.adds/robotics/Open Source Robotics Foundation, Inc
2012.4.10, 30: DRC (Robotics Challenge) Broad Agency Announcement:

GFE Simulator is expected to be provided by the
Open Source Robotics Foundation, Inc.,
and will initially be based on the ROS Gazebo simulator.
Expectations for the GFE Simulator include the following:
• Models the three-dimensional environment;
• Allows import of robot's
kinematic, dynamic, and sensor models;
• Allows robot's co.workers to
send commands over a network
(identical to those sent to a physical robot)
and receive data from the simulated robot
(similar to that received from a physical robot);
• Uses physics-based models of
inertia, actuation, contact, and environment dynamics
to simulate the robot’s motion;
• Runs in real-time on the “cloud,”
likely on Graphics Processing Units (GPUs);
• usable from the cloud
by at least 100 concurrent teams
The GFE Simulator supplier
will manage an open-source effort
where the simulator, robot models,
and environment models
are developed and improved by the supplier
as well as by contributors throughout the world.

2012.4.12: OSRF @ fbo.gov:
Sole Source Intent Notice
Open-Source Robot SImulation Software
for DARPA Robotics Challenge
Solicitation Number: DARPA-SN-12-34

The Defense Advanced Research Projects Agency,
Tactical Technology Office (TTO),
intends to award a sole source contract to the
Open Source Robotics Foundation, Inc.,
of Menlo Park, California.
For the contract, it will develop an open-source
robot simulation software system
for use by the DARPA Robotics Challenge program.
The effort will develop validated models of
robots and field environments  .
The effort will make the simulation software
available on an open-source basis,
and will host the simulation so that
participants in the DARPA Robotics Challenge program
can access it freely.
To search for innovative approaches to provide this service,
DARPA performed an informal market survey.
Of the few existing candidate open-source robot simulators,
the Open Source Robotics Foundation was deemed to be
the sole viable supplier for providing the
necessary open-source simulation software
within the specified timeframe.
The Open Source Robotics Foundation simulator, called Gazebo,
simulates many robots and sensors,
supports the ROS and Player robot control middleware,
and maintains tutorials, documentation
and an active user base.
The technology underlying Gazebo
supports many use cases
including remote operation
through a client-server architecture,
customization via a flexible plugin interface,
accurate physics simulation,
and rapid setup through intuitive
graphical and programmatic interfaces.
The proposed contract action is for
supplies or services for which the Government
intends to solicit and negotiate with
only one source under authority of FAR 6.302-1
"Only one responsible source
and no other supplies or services
will satisfy agency requirements."
As the open-source robot simulation leader,
the Open Source Robotics Foundation possesses
unique knowledge and capabilities required to
carry out the required research effort.
No other source would be capable of
satisfying the requirements
for an affordable end-to-end solution
necessary to meet the Government's needs.

2012.4.16: OSRF @ willowgarage:

The history of open source is replete with
significant moments in time,
and today Willow Garage would like to humbly submit
our own milestone -- the announcement of
the Open Source Robotics Foundation.
As Willow Garage has worked to grow and shepherd ROS
within the robotics world
our hope was that ROS would one day stand on its own.
With the announcement today of the OSR Foundation,
that day is finally here.
The mission of the OSR Foundation is "to support
the development, distribution, and adoption
of open source software for use in robotics
research, education, and product development."
The first initiative of the OSRF will be participation in
the DARPA Robotics Challenge, announced recently.
DARPA today sponsored a Proposer's Day Workshop
where more information about the Robotics Challenge
is available via Webcast.
During the Webcast, Nate Koenig from Willow Garage
gave a brief talk on the current and future state
of the open source Gazebo robot simulator,
which will be extended by the OSR Foundation
to support the DARPA Robot Challenge.

2012.4.17: Gazebo @ spectrum.ieee.org:

You're likely already familiar with the
Robot Operating System, or ROS,
in relation to Willow Garage's PR2 robots.
A few years ago, Willow Garage
integrated ROS and the PR2 into Gazebo,
a multi-robot simulator project
started at the University of Southern California
by Andrew Howard and Nate Koenig.
Willow Garage now provides financial support
for the development of Gazebo.
. ROS is now mature enough to go off and fend for itself,
and the Open Source Robotics Foundation
is the shiny new embodiment of that confidence.
DARPA isn't awarding the simulator contract to
Willow Garage or Gazebo's org,
but to a new foundation dedicated to the
full lifecycle of Robotics programming .
. here's what DARPA is expecting:
    The Open Source Robotics Foundation
    will develop an open-source
robot simulation software system
    for use by the DARPA Robotics Challenge program.
    The effort will develop validated models of robots
    (kinematics, dynamics, and sensors)
    and field environments (three-dimensional
    surfaces, solids, and material properties).
    The effort will develop physics-based models of
    inertia, actuation, contact, and environment dynamics
    to simulate the robot's motion.
    . available on an open-source basis,
    and hosted so that participants in the
    DARPA Robotics Challenge program
    can access it freely.

Open Source Robotics Foundation`sponsored projects:

. Gazebo is a 3D multi-robot simulator with dynamics.
. ROS (Robot Operating System) provides
hardware abstraction, device drivers, libraries, visualizers,
message-passing, package management, and more.
. Paradise Studios SkyX(open version) provides a
photorealistic, simple and fast sky rendering plugin
for the Ogre3D graphics engine,
compatible with Gazebo .
. Other open-source activities
that are related to the mission of OSRF
include the Arduino platform and the Make database.
. sponsors include:
# Bosch's Research and Technology Center (RTC)
has the distinction of being the only
non-university recipient of a Willow Garage PR2
as part of the PR2 Beta Program
[for hardware-testing with the ROS .]
# DARPA (Defense Advanced Research Projects Agency)
is funding the Gazebo robot simulator,
which will be used extensively in the
DARPA Robotics Challenge.
# Rethink Robotics's Baxter robot uses ROS .
# Sandia National Laboratories is
collaborating with OSRF to develop
low-cost, highly dexterous robot hands.
# Willow Garage is a Founding Contributor to OSRF.
Without Willow Garage's financial,
organizational, and moral support,
OSRF could never have become
the company that we are today.
# Yujin Robot is collaborating with OSRF,
to develop tools for authoring, and management of
multi-robot systems in production environments .

2012.7: OSRF will concentrate on Gazebo:

. we're planning to put a lot of work into
the Gazebo simulator and ROS,
significantly improving the capability
and availability of robot simulation .
. we can have greater impact by
taking a "deep dive" in one area
rather than taking shallow responsibility for everything.
Over time, we'll contribute to a broader variety of projects,
mostly drawn from the ROS ecosystem.
. a ROS certification program may be
most valuable in a domain-specific manner.
eg, imagine a way of certifying a
ROS-controlled industrial robot arm
as being compatible with an accepted
ROS interface standard
(perhaps crafted by the forthcoming
ROS Industrial Consortium .
Similarly, imagine a TurtleBot being certified
as implementing REP 119 .
. compatibility should be the focus;
certifying functionality is an entirely different topic .
. the ROS Platform development
continues to be managed by Willow Garage,
but responsibility for release management
will transition to OSRF eventually .

DRC/Roadmap > Tutorials > Main Page > Overview:

Gazebo is a multi-robot simulator for outdoor environments.
Like Stage (part of the Player project),
it is capable of simulating a population of
robots, sensors and objects,
but does so in a three-dimensional world.
It generates both realistic sensor feedback
and physically plausible interactions between objects
(it includes an accurate simulation of rigid-body physics).
Why use Gazebo?
Gazebo was originally designed to develope
algorithms for robotic platforms.
By realistically simulating robots and environments
code designed to operate a physical robot
can be executed on an artificial version.
This helps to avoid common problems
associated with hardware
such as short battery life, hardware failures,
and unexpected and dangerous behaviors.
It is also much faster to
spin up a simulation engine
than continually run code on robot,
especially when the simulation engine
can run faster than real-time.
Over the years Gazebo has also
been used for regression testing.
Scenarios designed to test algorithm functionality
have been established and passed through test rigs.
These tests can be run continually
to maintain code quality and functionality.
Numerous researchers have also used Gazebo
to develop and run experiments
solely in a simulated environment.
Controlled experimental setups
can easily be created in which subjects can
interact with robots in a realistic manner.
Additionally,
Gazebo has been used to compare algorithms
for such things as navigation
and grasping in a controlled environment.
Future:
Gazebo is under active development at Willow Garage.
We are continually fixing bugs,
and adding new features.
If you have feature requests, need help,
or have bugs to report
please refer to the support page .

gazebosim.org`features:

Gazebo is a feature rich application that is
under constant development from a large user community.
The follow lists a few of the primary features offered by Gazebo.
Dynamics Simulation
    Access multiple physics engines including ODE and Bullet.
    Direct control over physic engine parameters
    including accuracy, performance, and dynamic properties
    for each simulated model.
Advanced 3D Graphics
    Utlizing OGRE, Gazebo provides realistic
rendering of environments.
    State-of-the-art GPU shaders
generate correct lighting and shadows
    for improved realism.
Sensors
    Generate sensor information from
    laser range finders, 2D cameras, Kinect style sensors,
    contact sensors, and RFID sensors.
Robot Models
    Many robots are provided including
    PR2, Pioneer2 DX, iRobot Create, TurtleBot,
    generic robot arms and grippers.
Environments
    Access to many objects from simple shapes to terrain.
Programmatic Interfaces
    Support for ROS and Player.
    API for custom interfaces.
Plugins
    Develop custom plugins for robot model control,
    interacting with world components
    Provides direct control to all aspects of
the simulation engine including
    the phyics engine, graphics libraries,
and sensor generation
TCP/IP Communication
    Run Gazebo on remote servers
    Interface to Gazebo through
socket-based message passing
    using Google Protobufs.
Powerful Graphical Interface
    A lightweight QT based graphical interface
    provides users with direct control over
    many simulation parameters.
    View and navigate through a running simulation.
Collada Import
    Import meshes from many sources
    using Gazebo's built in Collada reader.
Active User Community
    Research institutes around the world
utilize and contribute to Gazebo.
    Community supported help
through a mailing list, and wiki.
Person simulation
    Replay human motion capture data
in a running simulation.

install on Ubuntu Linux 12.04 (precise):

Setup your computer to accept software from
packages.osrfoundation.org.
$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu
precise main" > /etc/apt/sources.list.d/ros-latest.list'
$ sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu
precise main" > /etc/apt/sources.list.d/gazebo-latest.list'
Retrieve and install the keys:
$ wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
$ wget http://packages.osrfoundation.org/gazebo.key -O - | sudo apt-key add -
Update apt-get and install Gazebo:
sudo apt-get update
sudo apt-get install gazebo

source: drc/ubuntu/pool/main/g/gazebo .

seems to speak c++/boost:
Create a model plugin that subscribes to a ROS topic:
#include
#include
...
namespace gazebo {     
  class ROSModelPlugin : public ModelPlugin   { ... .

-- LOOK C++ !!!
. this may be why DARPA said
Gazebo is only a tentative choice;
they might have plans to translate all this work
over to some better programming language
supporting the new systems in the pipeline
that feature improved massive concurrency
based on very energy-efficient chips ... .

darpa's new project is UHPC 2010:

(Ubiquitous High Performance Computing)
The UHPC program seeks to develop
the architectures and technologies
that will provide the underpinnings,
framework and approaches
for improving power consumption, cyber resiliency,
and programmer productivity,
while delivering a thousand-fold increase
in processing capabilities.
2012.6.25: UHPC details:
. DARPA, in 2010, selected four "performers"
to develop prototype systems for its UHPC program:
Intel, NVIDIA, MIT, and Sandia National Laboratory.
. NVIDIA is teaming with Cray [designer of Chapel.lang],
Oak Ridge National Laboratory and others
to design its ExtremeScale prototype.
NVIDIA was not previously seen as
the cutting-edge of supercomputing,
[but GPU's are apparently the future
of massive concurrency ].
. Intel's 2010 revival of Larrabee,
as the Many Integrated Core (MIC) processor,
may be of use in its UHPC designs .
. Intel's prior concurrency tools include Ct language,
Threading Building Blocks, and Parallel Studio .
The first UHPC prototype systems
are slated to be completed in 2018.
. single-cabinet UHPC systems will need to deliver
a petaflop of High Performance Linpack (HPL)
and achieve an energy efficiency of at least
50 gigaflops/watt (100 times more efficient
than today's supercomputers.)
. the programmer should be able to implicitly
implement parallelism (without using MPI
or any other communication-based mechanism).
In addition, the operating system for these machines
has to be "self-aware,"
such that it can dynamically manage performance,
dependability and system resources.

open robotics university

12.8: news.adds/robotics/openroboticsuniversity:
co.g'+#Open Robotics University:

11:10 AM
*Can anyone in this community [g'+ ubuntu] write C++ or Java code that will be
robust and stable enough for an
advanced robotics platform?*
Please visit our website
Open Robotics University
(world's first tuition-free
engineering degree-granting university)
to view the specification for
DARPA Robotics Challenge
and National Robotics Initiative Robots
that we are working on.
Since we are open-source university,
any individual can join our build team.
The winning prize for the competition is
$2,000,000.00.
*Please review the specification for ORU-DRD
to start generating discussion on our
“Open-Source Robotics” community page .
*  Here is a link to DARPA page.
Also see a link to Kawada Industries based in Japan.

We have been in talk with Kawada to provide us the
HRP-3 Promet MK-II platform for our research
to build our own version to meet DARPA goals.
I think we can win the $2, 000000.00 prize.
*Proposed Specification of ORU-DRR Robot:* 
* The robot’s joints axes, electric devices, gear unit and power unit
should be liquid and dust proof.
*The robot should be about 6ft tall and weighs about 160 pounds.
* The inner frame should be aluminum
and the outer body wrap in fire resistance composite. 
* Multi-finger hands for effective handling of tools.
*   Integrate smooth gait generation and slip detection technology
to enable robot to walk on low-friction surface.
 *Sophisticated whole body movement to be realized by
 AIST-developed “generalized ZMP” technology.
 * 42 Degrees of freedom – Head: 2 axes (pitch and yam);
 Arm: 7 axes (shoulder: 3, elbow: 1, wrist: 3) X 2;
 Hand: 6 axes x2; Waist 2 axes (pitch and yaw); Leg 6 axes x2.
 * Vision sensor: 4-lens stereo camera system for autonomous control;
 4-lens stereo camera for remote control; scanning range finder.
 * Control system: Distributed control system;
 Network: Can (Controller Area Network – Mbps).

Open Robotics University

. the first tuition-free engineering
degree-granting institution.
All of our university operations
from student admission
to teaching and learning processes
are powered by Google+
Our university is based in the USA;
and currently seeking accreditation
from accreditation agencies in the US.
Our Goal:
get technically oriented individuals,
who due to their socio-economic status
don't have funds to study robotics engineering;
learn to design and build robust, intelligent robots
for a university robotics engineering degree.
Students: Our students are located in
forty five cities in twenty six countries
-- pre-university through doctorate degrees.
President, Dr. Osato Osemwengie,
Dr. Osemwengie Lives in
Dublin, Ohio, United States.
with Mark Leon of
NASA Robotics Alliance Project
He served as FIRST robotics coach
and mentor to three teams.
He was a presenter at the 2008 Atlanta, Georgia
FIRST Robotics World Championship.
He has completed
four masters and a doctorate degree.
His experience, while attempting to
complete fifth and six masters degree
in software engineering and
electrical engineering respectively,
influenced him to open
The Open Robotics  University.
He strongly believe that future engineers
should not be subjected to outdated text books
and high cost tuition in this digital age.
Any dedicated individual
can receive high quality education
via social media infrastructure such Google+.
Open Robotics University
applied to participate in
National Robotics Initiative.

Our DARPA Challenge Robotics Platform!!
Open Robotics University applied to participate in
tracks C and D of the DARPA Robotics Challenge.
DARPA’s goal is to accelerate the development of robots
that are robust enough to be used for
disaster response operations in hazardous environment.
The robot should also be
intelligent enough to navigate around
doors, chairs, manipulate vehicles,
power tools and recognize levers and valves.
To meet this goal we have adopted
Kawada industries’ HRP-3 MK-II Robotics platform
for research to build our robot ORU-DRR Robot.
Since we are an open-source university,
talented individuals that are not members of our faculty
or not enrolled as a student in our university
worldwide can join our Open Robotics University team
to design software and robot for the competition
(Check out the proposed specification of ORU-DRR below) .

National Robotics Initiative:
The goal is to “accelerate the development
and use of robots in the United States
that work beside, or cooperatively with people”.
To meet this goal we have adopted
Kawada industries’ HRP-4 Robotics platform
for research to build our robot ORU-NRI Robot
(Open Robotics University
National Robotics Initiative Robot).

OpenRov robotics plaform:
. openrov.com is to conduct research
and build world-class oceanic robots
to explore the world's oceans
similar to work done by liquidr.com robotics.

mis.adds/openroboticsuniversity/Responsibility Project:

openroboticsuniversity`
Make a Difference Robotics Projects
These type of projects as Deitel claims, in his book
"C++ How To Program" 2012,
are "meant to increase awareness and discussion
of important issues the world is facing.
We hope you'll approach them with your own
values, politics, and beliefs".
see more Science & Technology projects
from the The Responsibility Project
. Welcome to The Responsibility Project,
a place to think about—and discuss—
what it means to do the right thing.

--. that isn't a list of interesting projects;
it's a blog for lecturing to teens .
. and, speaking of Doing The Right Thing,
why are we still using c++ ?

dream theory's tech perfection plan

12.8: adds/relig/dream theory's tech perfection plan:
. welcome to my wealth4all religion .
. you don't even have to believe in it to be saved by it,
but if everyone did believe,
it would save a lot of grief .
. the universe's god has no way of
not choosing bad experiences
(all that's left for the god to do
is making sure the bad comes first
and that some good experiences
are in power to keep civilization alive
during this boot camp of evolution);
but we've already seen
every sort of pain and inequality,
so, any time now,
we certainly could move on to
experiencing pure wealth4all .
. the emotional pains the god gives us
are put there just to provoke the wars
that promote evolution of the technology
that ensures eternal survival beyond sun death;
but, if everyone were to realize
god needs tech not war,
then we could simply volunteer
to put more money into tech .
. of course that would mean less money for
the popular entertaining games such as:
my family is bigger than your family ...
so, it's not a belief without costs;
but non-believers are welcomed to be
dragged through war:
wealth4all is optional
until tech is perfected .
. it's not like god is punishing us for
being uncooperative with the needed
Tech Perfection Plan
but if you did believe that,
the obvious data certainly could
support that view;
however, at this point in the
universe's experience distribution
war is no longer needed for
pinning the pains to the beginning;
but, war is still a backup plan
in case we don't feel it necessary to
divert population expansion funds
towards the Tech Perfection Plan .
. wealth4all: I'm a believer .

concurrency both expressed and automated

8.23: adda/co/finding inherent concurrency automatically:
. how can we analyze a program in order to find
what parts of it can be done concurrently?
. at each step there are implicit inputs and outputs
for step#1, do I know its outputs?
for step#2 do I know its inputs?
(also, when step#1 makes calls,
do any of those calls modify any space that might be
needed by anything step#2 calls? ).
. if step#2's inputs don't intersect step#1's outputs,
then you can do both at the same time .
. to know these things, calls have to be
functional so that program space is obvious .

. when calls have multiple parameters,
the order of their evaluation is random;
which should be tantamount to saying
that parameters in the same tuple
can be run concurrently (co-runnable) .
. this also applies to all tuples that are at
the same level of an expression tree:
eg, in h( f(a,b), g(c,d) ), a,b,c,d are co.runnable .

. a low-level way to compare
subprogramming with coprogramming,
is that while any call could be seen as
a new {process, cpu} activation,
in subprogramming, after making a call,
it agrees to stop working until that call is done .

. often we can find that a group of operations
are all handled by the same type mgt, [11.17:
-- in fact, that is the definition of "(operation):
a subprogram that is outputting
the same type that it's inputting -- ]
so even though they are nested
you can send the whle thing in one call,
and, in that case,
the type mgt will know what's co.runnable .

8.23: todo.adda/co/review parasail's design:
. the parasail lang was able to parallelize implicitly a lot .
(see also comments of this page).

adda/co/explicit concurrency control:

. the abstraction to use for explicit concurrency control
is having a particular cpu called like a function:
cpu#n(subprogram, inputs, outputs)
-- the inputs are a copy of everthing sent to it .
-- outputs are addresses to put results in .

. how is go.lang outputting?
when go.lang says go f(x)
they expect f to either call an outputter
or have x be an outputting channel .

. instead of saying cpu#n(...)
just say co f(x, out), or y`= co f(x) .

8.24: adda/co/syntax:
. there are 2 forms of the function co
according to whether co is synchronous or asynch:
# co(f,g,h) -- co with multiple arguments --
expects spawn and wait .
# co f -- co with just one argument --
just launches f asynchronously .

8.31: co.self/dream/adda/co:
. the dream was something about
"(ways of doing backup for concurrency or ...)
"( ... and now that we can do that,
we can do this ...) [dream recall is too fuzzy].

rationales for go.lang's surprises

8.22: news.adda/go/assertions are no way to panic:
Why does Go not have assertions?

[ assertions allow you to say
crash if this condition doesn't hold true
because something is wrong
and the program will need debugging .]
. assertions are undeniably convenient
to avoid thinking about proper
error handling and reporting;
but, servers should not crash from non-fatal errors;
and, errors should be direct and to the point,
saving the programmer from interpreting a
large crash trace .
Precise errors are particularly important
when the programmer seeing the errors
is not familiar with the code.

no exceptions? well, panic is just as useful:

. func panic(interface{})
func recover() interface{} .
. these built-in functions assist in reporting and handling
run-time panics and program-defined error conditions.
. When a function F calls panic,
normal execution of F stops immediately.
Any functions whose execution was
deferred by the invocation of F
are run in the usual way,
and then F returns to its caller.
To the caller,
F then behaves like a call to panic,
terminating its own execution
and running deferred functions.
This continues until all functions in the goroutine
have ceased execution, in reverse order.
At that point, the program is terminated
and the error condition is reported,
including the value of the argument to panic.
This termination sequence is called panicking.
panic(42); panic("unreachable");
panic(Error("cannot parse")).
. The recover function allows a program to
manage behavior of a panicking goroutine.
Executing a recover call inside a deferred function
stops the panicking sequence by
restoring normal execution,
and retrieves the error value passed to the call of panic.
If recover is called outside the deferred function
it will not stop a panicking sequence.
In this case, or when the goroutine is not panicking,
recover returns nil.

go vs python from the trenches 2012

8.22: news.adda/go vs python from the trenches 2012:
Graham King:

Would I be happy working with Go as my
main language? Yes, I would.
It’s a joy to work with,
and I got productive very fast.
Am I using it instead of Python
for all my new projects?
No, There are two reasons for that.
Firstly, it’s a very young language,
so library availability is limited
(for example, I need curses).
Second, well, Python is just so amazing.
[but] I see the benefit of static typing.

If I was still doing Java, or (heaven forbid) C++,
I would invest heavily in Go.
It was designed to replace them, and it does that well.
Go’s sweet spot is building servers.
(it makes concurrency safer and easier)

Other claimed benefits of Go over Python
are that it’s faster, and it’s “better at scale”.
For some things I’ve done
Python has been faster .
[and] The biggest difference [in speed]
is probably [just] in how well I write the code.
[also] nothing I do is CPU bound.
The “better at scale” argument doesn’t really apply
to building web apps with Django.
We scale by adding servers,
and [Django supports programming-in-the-large
with small self-contained ‘apps’ ]

Steven (March 6, 2012 at 23:22)

You can get pretty close to a REPL
[an interactive Read-Eval-Print Loop]
with goplay, [a web-based go compiler]
-- instead of interpreting, it compiles
[ go was designed for very fast compiling .]
Go is possible to daemonize.
You could use a sync.WaitGroup
to make main wait for any number of goroutines to exit .
But more directly, you can do the same thing by
adding this to the top of your program:
defer runtime.Goexit()

write CPython extensions with Go:

. goPy with gccgo .
Once the libraries and command-line tool are installed,
the "gopy" command-line tool
is generating the necessary C interface code;
and, then using gccgo will compile the code
into an extension module.

walk and chew gum #Python

8.22: news.adda/python/co/walk and chew gum:
summary:
Google discourages Python for new projects?
[they encourage go.lang;
Python is said to need more resources?
I'm sure the problem is backwards compatibility .
. in the paper where they talked about Unladen Swallow
they mentioned wanting to remove the GIL
(the global interpreter lock for thread safety)
and this really surprised me coming from google staff,
because Python's project lead (another google staff)
has argued convincingly
that due to the language itself, [11.17:
ie, by being designed for interfacing C
(Jython and IronPython have no GIL)]
removing the GIL from CPython was impractical .
[11.17: at PyCon 2012, he adds:

Threading is for parallel IO.
Multiprocessing is for parallel computation.
The GIL does not hinder any of that.
... just because process creation in Windows
used to be slow as a dog, ...]

. Python has that old-style OOP,
which doesn't do much for encapsulation,
and therefore doesn't do much for thread safety
except to single-thread the interpreter .
. if you want something much like python
that also has good concurrency,
then google has given it to us in go.lang;
but, perhaps what he meant to say
is that it's like Intel's CISC architecture:
that was fundamentally slower than RISC;
but they virtualized it:
the machine instructions are converted
to RISC microcode .
. that's what big money could do for Python:
automatically find the inherent concurrency
and translate it to a threaded virtual machine .[11.17:
... but still interface flawlessly with
all C code on all platforms?
I'm no longer confident about that .]

[11.17: web:
. to overcome GIL limitation,
the parallel python SMP module;
runs python code in parallel
on both multicores and multiprocessors .
Doug Hellmann 2007 reviews it:

. you need install your code only once:
the code and data are both auto'distributed
from the central server to the worker nodes .
Jobs are started asynchronously,
and run in parallel on an available node.
The callable object that is
returned when the job is submitted
blocks until the response is ready,
so response sets can be computed
asynchronously, then merged synchronously.
Load distribution is transparent,
making it excellent for clustered environments.
Whereas Parallel Python is designed around
a “push” style distribution model,
the Processing package is set up to
create producer/consumer-style systems
where worker processes pull jobs from a queue .
Since the Processing package is almost a
drop-in replacement for the
standard library’s threading module,
many of your existing multi-threaded applications
can be converted to use processes
simply by changing a few import statements .

. see wiki.python.org/moin/Concurrency/
for the latest on Pythonic concurrency .]

8.22: news:

allowed characters in identifiers

8.22: adda/lexicon/allowed characters in identifiers:
. if the allowed characters in an identifier
could include the dot,
then there could be confusion in places,
as to whether the dot was declaring a var:
eg, what if you have the name x.F.int,
and then -- forgetting you did that --
decided later to define F.type ?
. now x.F is ambiguous:
are you declaring x to be F.type?
or are you referring to x.F.int ?
. therefore, the allowed identifiers are
first character is a letter
or the character (_);
and, subsequent characters are alphanums
or the characters (') (_) (-);
anthing else gets put in a box:
eg, [x.F].int; .

class var's declaration syntax

adda/type/class var's declaration syntax:
8.21:
. how does the class var get declared?
how about just like it's called?
. if it's for the instance then we're
writing definitions for self implicitely,
but if there's a class var,
we write as if the var's name is "(type) ...
8.22:
. just as self's public vars are given as
just one tuple definition,
so too the public class vars are like so:
.< ... , type.(x.t), ... > -- a single public class var;
.< ..., .( x,y: t), ... > -- multiple public ivars;
. we could have also written that as:
.< ..., self.( x,y: t), ... >
. parentheses are required in a tuple syntax
even for the singleton? sure:
why have special cases confusing the reader?
in all cases of dotted naming, we are using a tuple,
which in all cases is represented by a parenthetical .
. how does this seem consistent
when generally x = (x) elsewhere?
it's consistent with other typedef syntax;
eg, in f().t the parentheses are required
in order to tell us that this is a function;
ie, any time we see f, we'll be expecting that
any next non-terminal found after f,
will be f's argument;
conversely, without the explicit paren's,
we'd expect f was not accepting args .

arrays are records are tuples

8.19: adda/dstr/array and record syntax as modes of access:
if ( x.y ) and ( x#y ) are both valid
regardless of whether x is defined as an array or record;
this ignores an idiom where
arrays represent lists of items,
while records represent items with named parts;
. well, my way lets you do it both ways,
but it should be admitted that the writer's freedom
is inevitably the reader's headache .

adda/dstr/array vs record precedence:
. if you have x#y.z
does it mean x#(y.z) or x#(y).z ?
my first impression is that y.z is the tightest binding;
ie, it means x#(y.z);
also, (x#(y) = x#y) only when y is an atom,
and you could argue that y.z is not an atom:
it's a sort of address-addition operation; [11.16:
but, of course, that would be a stretch!
it's more intuitively seen as a style of atom naming .
. finally, consider how functions and arrays
should be similar;
( f x.y ) should be seen as a variant of
( a# x.y ); therefore, the parsing is ( a#(x.y) ). ]
. x.y#z is unambiguous: x has component y,
which is an array taking parameter z;
ie, it's parsed as ( (x.y)#z ).

8.20: adda/dstr/arrays are a species of record.type:
. an array is generating a list of component names,
and then declaring them all to be the same type .
. records are a generalization of this,
where a generated list of components
can have a variety of types .
. in fact, fully-oop arrays are actually records;
because, they often have a variety of types .
. arrays are parameterized types,
and records can be parameterized too
. here's a syntax for allowing a record
to describe parts of itself the way arrays do:
reca(n.int).type: ( a.t1, b.t2, #(0..n).t3 );
x.reca(3)
-- now x = (a:..., b:..., 0:..., 1:..., 2:..., 3:... ).

Ada's core attributes

8.20: web.adda/ada/predefined attributes:
. what are Ada's reserved attributes?
here they are renamed for clarification
(these are just the most basic ones;
there are many more for floats, etc):
type'base  -- the unconstrained subtype;
enum in type'first .. type'last,
A'range(N) =  A'first(n) .. A'last(n) -- array's nth dimension;
type'value(enumcode number or image string);
type'image(value) is a string;
type'code(value) -- the integer representing the value (aka pos);
type'codebitsize -- obj's fixed size (when packed);
rec.component'codebitoffset;
type'imagesize -- #characters(for largest expression);
type'++(value) -- successor;
type'--(value) -- predecessor .

model-view and composite tech

[thought I blogged this 9.2, but found as draft;
then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:

"( Potel questioned the need for the MVC's Controller;
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.).

. after reading that, I wrote this:

. I didn't get mvc either, and promptly redefined it:
subrograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .]

benefits of unique context operator

8.19: adda/lexicon/benefits of unique context operator:
[8.20: intro
. in 2012.4, this "(::) was presented as a context operator
but it didn't give a specific reason:

"( confusing having syntax"(type`value)
when (`) already has a specific meaning: (x`f); ). ]

. even more than confusing,
it's name`space limiting:
if you have the syntax ( type`attribute ),
along with ( type`method ),
then the type authors are limited in
what they can name their methods
because it could clash with type attributes; [8.20:
eg, for enums there is an attribute named first;
eg, for bible.type: {last, first},
bible`first = last; -- this type's first value is "(last);
but if the context operation uses the same symbol,
then ( bible`first ) could mean either
the first value of the bible enumeration,
or the bible value named "(first).
. by having a separate context operator (eg, ::),
we can say ( bible`first = bible::last ).]

8.19: 11.15 .. 16: review the syntax:

obj.type(select a variant of this type)
-- declares obj to be of this type;
obj`= value -- object initialization;
type::value -- fully-qualified enumeration value;

obj.component -- public ivar;
type::.component -- public ivar's default initial value;
obj#(component expression) -- public ivar;
type::#(expr) -- public ivar's default initial value;

type.component -- public class var;
type#(component expression) -- public class var;

obj`body/local -- private ivars;
type`body/local -- private class vars;

obj`message(...);  -- instance message call;
obj`message`body -- instance message's body;
type::`message`body -- instance message's body;
type::`message -- instance message uninstantiated
( practically the same as type::`message`body );
type`attribute -- class message call;
function(obj) -- call to function of instance
(may or may not belong to an obj's type's interface);
type::subprogram -- full-qualified subprogram call;

type::function`body -- access function's body;
type`body/subprogram -- private class subprogram call;
obj`body/subprogram -- private instance subprogram call;
obj(expr) -- obj callable? apply('obj, expr);
function obj -- call with this obj

. notice there are separate namespaces for
{ value and function names
, .components
, `messages }; because,
components are found only after a dot,
and messages only after a backquote;
whereas, the namespace for value
is shared by that for functions;
otherwise, the parser would have problems:
both values and functions start with a name
but only functions expect the next lexel
to be the argument of that function:
# function x -> apply function to x;
# value x -> syntax error
( unless x is a binary operator
or value is numeric and x is a dimension ).
. therefore, for each unqualified name
it must be typed unambiguously as
either a function or a value, not both .

11.15: mis:
"(review the syntax:

type::value -- fully-qualified instance value
type::`message -- access message's body
type::function(...) -- access function's body
obj`body/local -- private ivars;
type`body/local -- private class vars;
type`attribute -- class message call;
...

) . sometimes it is using (type::x) to mean eval x,
but other times don't eval?
and then this:
type`body/local -- private class vars;
?
. the body of the function is within
the body of the type:
type`body/function
and the way to refer to the function uneval'd,
is to ask for the function's body:
type`body/function`body .
. but if the function is also visible from the interface
we could also write:
type::function`body .

11.16: clarification:
"( review the syntax:

type.component -- public class var;
obj.component -- public ivar;
type::.component -- public ivar's default initial value

) . an interface definition has syntax for
both class and instance public vars,
and these are accessed similarly,
being dotted with their respective objects:
obj.component -- public instance var;
type.component -- public class var .
. if you hadn't defined an instance yet,
and still wanted to refer to an instance's component,
that would be done with the type's context operator:
type::.component;
and, since there was no instance involved,
the only meaning it could logically have
is being the component's default initial value .

task.type's syntax and semantics

adda/co:
8.16: syntax:
. when an object is given a message,
it is the object's type mgt that applies a method;
and, these type mgr's are tasks (co.programs);
but how do we get the obj's themselves
to be tasks? (ie, running code on a separate thread).

read-only and write-only params

8.14: adda/cstr/function/syntax/read-only and write-only params:
 if a parameter gets a pointer, (eg, /.int)
then it can be modifying both the pointer and the int,
so, shouldn't we have a syntax for expressing
what the algorithm intends to do with both?
. so, we still need a syntax for what is read-only .
. if a parameter expects a read-only,
then we can give it a modifiable
while expecting that it won't modify it .
. how about syntax for write-only?
maybe we should use (.typemark^) for that?
[11.11:
. the latest idea obviates a read-only syntax:
(inout param's)`f(x) -- in that example,
the x param is in-mode only (read-only)
that includes both the pointer and its target .
. notice that if the input is shared by any co.programs,
then we need to lock it as read-only or copy it,
unless we expect it to rely on the interactive value .]

API-GUI equivalence

8.7: adda/api-gui equivalence:
intro:
. every aspect of a subprogram's gui
should be mapping to some feature of
the subprogram's interface (API);
so how is the API specifying
an array of menus with submenus?
sometimes there is menu-izing naturally formed by
an app inheriting from a service type,
like the file menu is,
for apps that use the file system .
. a datatype's operations are going under the Edit.menu;
because, that's the general term for the current datatype .
. a View.menu would belong to the human's agent
that was providing various ways to
format the display of data; [11.11:
but, a subprogram's API might have multiple views too .]

signaling in gui systems

8.12: adda/cstr/signals/signaling in gui systems:
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
gui-optimized signals,
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .

substitution principle

8.21: adda/oop/type/substitution principle:
. when a parameter is type rectangle,
then it can be assigned any rectangle
including a square;
because, a square is rectangular .
. classic oop has had a problem with that,
so, how do we sort out our subtypes
from this jumble of subclass confusion?
[11.9:
. the solution I've come up with
is known as Changing The Language:
ie, rather than assume a type.tag is constant;
we assert that related types
are expected to have a common surtype;
eg, for a var constrained to Number.type,
it will have a constant surtype.tag;
but, it will also have a modifiable subtype.tag,
that can vary within {N,Z,Q,R,C}
(unsigned, int, quotient, real, complex).
. a var constraint can be a subtype too:
eg, for a var constrained to Real,
it can only vary in {N,Z,Q,R};
ie, the subtypes whose domains are
subsets of Real's domain .
. and, as usual for non-oop,
if a var is constrained to a definite type, such as float32,
then both the surtype and subtype
are going to be constant
(hence the obj will be untagged);
but, since the surtype is Number,
and float32 is understood to be a subtype of Real,
you can ask for (float32 + int)
and multi-dispatching will still work .]
. in order to be a subtype of rectangle,
an object that is tagged as being a square
has got to be re-taggable as non-square
in the event that the rectangle interface
asks it to modify itself;
ie, a type that inherits from rectangle
and then adds the constraint
that it be a square too -- forever --
has decided to nix support for type compatability,
which contradicts the idea of inheritance .
. to be a subtype (ie, support type compatability)
the inheritance needs to work like this:
my subtype named square
has the properties of the inherited rectangle
but includes the constraint width = height .
. if you ask me to break that constraint,
then I'll re-type.tag myself as a rectangle
(rectangular but not square).
[11.9: corrollary:
. if a var is constrained to be a square,
then the only rectangle it can be assigned to
is an unmodifiable one;
being assigned to a modifiable rectangle,
could potentially violate the type constraint,
and should result in a compile-time warning .
. this isn't a fatal error though;
because, the user could expect that
squares will grow in only a square way,
-- as would be the case for doublemy(rectangle) --
or the user may want to handle the exception
by trying another algorithm;
therefore, the warning should remind the users,
that they appear to be depending on
either having exceptions handle
the type.constraint.error,
or having the rectangle operation
not violate a square's subtype.constraint .]

obj'c categories and Ada's hierarchical pkg

8.14: adda/oop/obj'c categories and ada hierarchical libs:
reviewing:
2012-01-31 Objective-C Categories
1.20: adda/type/obj'c categories:
. Apple is using the obj'c Category for MVC separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package without any methods for
drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one type can exist
yet with  relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns

todo:
. isn't that use of categories needed only because
the designers were assuming certain requirements
that are demanded only by the current oop model?

. if your string wants to express gui-specific tricks
such as appearing in a particular font,
or being arranged so as to follow a curve,
that need should be served by the use of a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 different classes !)
--
. a main point of the book"design patterns

was to critique oop's use of subclassing;
and, that criticism might apply equally well
to this use of categories;
but, generally, categories do have a good purpose:
they allow separate compilation of class extensions
without having to recompile the original interface
which might then require a recompile of
all the clients of that interface .

. this reminds of Ada's hierarchical libraries,
in Ada you can reuse oldlib's module
with the syntax:
package oldlib.additionalmethods
(by including oldlib's name like that
within your new package's name,
your new package includes the binaries of oldlib ).
. now current clients of oldlib
still don't have additional methods,
but, future clients of oldlib.additionalmethods
will have access to both modules
with that one import .
. obj'c categories by contrast,
allow you to add the same new modules
but this addition will also be affecting
current clients!
-- the category's method has access only to
the target's interface, not its internals;
so, a category can't fix every bug;
yet it can create bugs because it can
override system methods .

. I have 2 competing ideas on this:
# we should be able to describe in adda
any idea of any other language;
vs,
# we should not be supporting the use of ideas
that are either complicating or insecure .

here's how the the Category idea might be impl'd:
. when a datataype agrees to be modified by categories;
then at run-time, the type mgt is a modifiable object
and, it provides a dictionary
where you can see if it supports a message .
. it can dynamically add entries to this dictionary
(allowing it to support new messages),
and it can change method addresses
(allowing it to update the methods of old messages).
[10.8:
. now all we need is an uncomplicated way to
decide which types are so modifiable .
. perhaps a type wishing to participate
could declare one of its components to be
a dictionary with a standard name
(perhaps SEL, in honor of Obj'C);
then anytime a message is unrecognized,
the run-time would check SEL for the method .
11.8: correction:
. in order to work like an obj'c category,
it has to check SEL all the time,
not just when a message is unrecognized,
in case one of its methods got overridden .]

PLY(Python-based Lex-Yacc) and pyCparser

8.20: web.adda/dev.py/ply
11.2: PLY compared with ANTLR:

There are several reasons to use ANTLR
over one of the Python parsers
like PLY and PyParsing.
The GUI interface is very nice,
it has a sophisticated understanding of
how to define a grammar,
it's top-down approach means the
generated code is easier to understand,
tree-grammers simplify some otherwise
tedious parts of writing parsers,
and it supports multiple output languages:
its builds parsers best in C, C# and Java;
but also has some support for generating Python .

ANTLR is written in Java;

Unlike the standard yacc/lex combination,
it combines both lexing and parsing rules
into the same specification document,
and adds tree transformation rules
for manipulating the AST.

. so, if you prefer python tools over Java, PLY ahead!

self's id

8.11: adda/oop/self's id:
7.28: intro:
. the expression tree being sent to number's type mgt
contains ptrs to the symbol table nodes;
and, those nodes include type tags .
. the symbol table is constant,
being part of the function's template;
the code points to symbol table nodes,
and then those nodes point to the stack,
or have immediate data if constant .
8.11:
. how does an object know its own id?
an expression tree sent to a type mgt
has a context (process, act'rec)
that tells it who the caller is,
and all the obj references in the expr'tree
are relative to that context .
. messaging an obj means calling its type mgt,
and then that type mgt is calling the methods
which then have access to the current context
as a global just like in assembly language
where programs have access to a current
stack pointer and program counter .

infratypes of surtypes, phyla of taxa

8.13: adda/oop/rethinking terminology:
. I have terminology for biop (binary operations) oop
arranged as supertypes existing as
one of fixed number of subtypes;
eg, Number is a supertype because it manages the
binary interactions between the following types
which are therefore called subtypes of number:
integer, real, decimal, rational, irrational, complex .
. classic oop hasn't played well with biop's:
being objected-oriented has meant that
(obj+x) had to be expressed as (obj.+(x))
and then obj's type, say int, needed to have
(+)-operations for each possible numeric type
(int, real, rational, irrational, complex);
what we needed was multi-dispatching:
where (obj+ x) gets sent to the supertype,
which finds the right subtype to handle it .

. the notion of subtype
can also include range limits .
. there are naturally limits imposed by
the numeric types that machines provide,
such as what can fit in multiple of bytes;
eg, int8, int16, int32, float32 .
. within my theory of oop,
these might be called infratypes,
for reminding of the term infrastructure .
[10.5:
. infratype is a relative term:
regardless of whether it's a cpu type,
or a type you reused from a library,
an infratype of T.type is any type that has been
reused for implementing T .
10.7:
. I'm realizing that infratypes
should be supported by the type.tag
(simply because we should support
space-efficient numerics,
and we do that, then we need to know
which infratype we're using in
(8, 16, 32, extendible);
therefore,
what I've been calling subtypes
(in the biop oop context)
can instead be called ideal infratypes
(in contrast to optimized infratypes);
likewise,
what I've been calling the supertype
can instead be the opposite of infratype:
that seems to be the word: surtype .
-- also some extra checking just now
shows that the idea I'm trying to convey,
is the same as that found in the words:
{surname, surface} -- the outermost part .]

[10.5: 10.7:
. in contrast to the ideal infratypes
that are designed by mathematicians,
the optimized infratypes are chosen by the
intersection of what types the platform provides
and what is of use by the
constrained versions of the ideal infratypes .

. there is a relationship between
subtypes and infratypes:
. within a polymorphic type,
infratypes are the type's possible forms (morphs);
whereas an value whose type is a subtype of T,
can be used anywhere a T-typed obj is permitted;
but the reverse is not true:
if you have a variable obj whose type is a subtype of T,
it cannot be used anywhere a T-typed obj is permitted;
rather the replacing obj must be able to handle
every value and every operation
that could be handled by the obj' it's replacing .

. a surtype has a finite set of ideal infratypes,
ie, types distinguished by having differences in
either the allowed set of operations,
or the data format of the current state .
. within each ideal infratype,
we then have a possibly infinite number of
additional subtypes
according to constraints on
value attributes, eg, on the value's range,
or the scientific format's number of digits,
or on the number of fraction digits .]

safe pointer details consider concurrency

8.4: adda/dstr/safe pointers/
space-efficiently pointing to both static type info and obj:
. we need to point at the symbol table index
not the obj itself, because,
only the symbol table index has the type tag
in the case when the type is static .
. as for space-efficiently doing this
at first I was worried about the
huge length of full paths
(process#, act'rec#, symbol table index);
but, [8.3:
just like urls have versions,
{fullpath(absolute), filename(relative addressing)},
pointers too should be available as
both long and short versions:
the full path is
(process#, act'rec#, symbol table index)
but if you are in the same act'rec,
you'd use a shorter version of the pointer:]

. if you are in the same activation record,
then the pointer is a mere 16bits:
(we assume here that a pointer needs a 3bit type tag,
and that the max# of symbols is 2^13 .

[8.21: 3bits?
. locally we need no tag at all,
because we just assume everthing is local;
otherwise, if it's a general pointer,
it will have the general type.tag arrangement
which usually means a static supertype,
and a dynamic on-board subtype,
which in the case of pointer needs 2 bits
for these 4 cases:
( internet address,
, local to system
, local to process
, local to act'rec ) .]

8.26: processID irrelevant:
. do we need to track the processID?
. any obj' we'd want to point at
is located within some act'rec;
so, isn't the act'recID enough?
8.28: 8.26:
. the act'rec obj' could have a subtype.tag
so that the same act'rec supertype
could represent all sorts of objects
like subprograms, coprograms, type mgt obj's, etc .
10.6:
. the main place to for finding out
how the current act'rec is related to a process
is by asking the task mgt who is
using this act'rec ID as a node index
into a tree of processes and their act'recs .

8.28: processID irrelevant despite pointers:
. when using pointers, the process ID matters;
because, we can give a pointer for assignments?
but that's not the problem of our pointer:
it has only to locate a target,
and it's up to exec to do the right thing .
. any time an assignment takes place
the target must be either a global obj,
(these are essentially act'recs because
they're made thread-safe by msg-taking functions)
or the owner had to have ordered the assignment
(that means either the owner is suspended for a subroutine
or the target is locked for a promised assign by an async).

8.26: processID fundamental?:
. we'd like to keep pointer sizes small,
so if we could know that an act'rec would
stay local to a particular process,
then we could possibly divide the number of act'recs
by the number of processes .
. we could say that each process has its own heap;
and, just as each act'rec has few symbol nodes,
a process has few act'recs,
so this is another form of subheap
the process subheap vs an actrec subheap .
8.28:
. unfortunately, given the use of recursion,
the number of act'recs per process can still be
arbitrarily large, so this would do nothing for
the size of an act'rec ID .
. the situation where process is fundamental
would be in systems with unprotected vars;
because, then process is a unit of thread safety:
anything can access any var within the process,
and then the process has only one thread .
. what we could have instead,
is a system where encapsulation and locks
are the basis of thread-safe computing:
. anything accessing a var must instead
ask that var's type mgt to do the accessing,
and then the type mgt has only one thread .
. a var lock gives sole ownership of a var
to another thread .
. in that sort of system,
a process is nothing more than an act'rec
that is run concurrently vs sequentially .