S
spinoza1111
I want the GUI of the spinoza system to not piss me off with the
usual
type of progress reporting one sees: the flashy, colorful, and
utterly
uninformative gizmos that go back and forth and round and round until
who knows when.
Therefore, the following C Sharp .Net code constitutes a theory of
progress reporting.
I claim that any fixed-count (limit available at run time before the
start) for loop can be monitored by considering it as the attempt to
accomplish a TASK, the accomplishment of which involves only the
processing of zero, one or more ENTITIES with an ENTITY COUNT. The
actual user (the person running the program) needs to see at what
rate
processing runs.
Each time through the loop, we are at a specific ENTITY NUMBER.
Progress and velocity can then be modeled visually by means of a
histogram such that:
histogramDimension/maxHistogramDimension = entityNumber/
entityCount
Solving for histogramDimension each time the "progress" handler runs:
histogramDimension = entityNumber/EntityCount *
maxHistogramDimension
The visual histogram can be anything from a widening, lengthening
"progress bar" to a bunny running down a field.
This can be done syncronously with the caveat that if it's done in
the
same thread (or even if not on a single processor "multiprocessing"
system) as actual work, it slows work down. In doing progress
reporting, one is trying to compensate for the expense in physical
time with some sort of magic show that speeds up the psychological
time experienced by the user.
Think of it as the airline video you get in front of your seat even
back in steerage. Watching the wastes of Central Asia pass beneath
one
actually speeds up a Hong Kong to Paris flight because you can
actually see the Caspian come beneath you.
Of course, not all loops are fixed in number. For example, a program
such as Google's Picasa, which seems to want to search my hard drives
for images, is presumably walking a tree. A histogram model needs to
know the number of nodes in the tree at startup, and for large trees,
this might mean walking the tree to count before walking the tree to
do work. That's ridiculous. Here, you'd want to see a tree "grow"
even
though this would not show you how far you were to the end.
But even in cases of while and unknown-count for, it's user abuse to
show spinners and flashers that don't let the user know when the
process is done.
The following C Sharp delegates define my model. Comments welcome:
flamers may flame and be damned to you. Quertyuiop, you do not belong
in this discussion.
public delegate void progressStartEventDelegate
(object objTaskDoer,
thread objThread,
string strTaskName,
string strTask,
string strEntity,
int intEntityCount)
The progressStartEvent occurs just before a loop.
The objTaskDoer is the object performing the task.
The objThread is the thread in which the task is being performed.
The strTaskName is used by all progress delegates to identify a
specific task.
The strTask is a task description used only in this delegate.
The strEntity names the entity being processed.
intEntityCount will contain the total number of entities to be
processed.
The GUI is here responsible for keeping some information, probably in
a Lifo stack.
public delegate void progressEventDelegate
(object objTaskDoer,
string strTaskName,
int intEntityNumber)
The progressEventDelegate is called just after or just before one
entity is processed.
The objTaskDoer will be the object performing the task.
strTaskName should be the task name: it will be the same as the
strTaskName sent by the progressStartEventDelegate.
intEntityNumber will be the sequence number (from 1) of the current
entity.
public delegate void progressEndEventDelegate
(object objTaskDoer,
string strTaskName)
The progressEndEventDelegate is called at the normal end of a task.
The objTaskDoer will be the object performing the task.
strTaskName will be the task name as in the progressStartEvent.
public delegate void progressFailEventDelegate
(object objTaskDoer,
string strTaskName,
string strFailMessage)
The progressFailEventDelegate will be called when the task fails.
The objTaskDoer will be the object performing the task.
strTaskName will be the task name.
strFailMessage should be the reason for failure.
Of course, this could be much more elaborate. A "progress" object
could be defined. The problem is that it then seems nice to weight
this object down with all sorts of crap, such as a Tag of type object
for communicating more status information.
Now, I claim that this model is sufficiently simple and general based
on Kant: Kant believed that all experience of necessity is time-
ordered on one dimension such that for any two points in the time as
experienced by one or more knowers, the "less than" or "greater than"
operators can be meaningfully used.
If we're trying to reduce psychological stress, then all users live in
Kant time.
Multiple concurrent processes can be an array of histograms (and
multiple users watching the process can
lay bets on the winner if they be sporting gentlemen).
When the entityCount is not known, an estimate can be made, perhaps
saving persistent state so that previous runs of the software give
the
following runs an idea of the count.
usual
type of progress reporting one sees: the flashy, colorful, and
utterly
uninformative gizmos that go back and forth and round and round until
who knows when.
Therefore, the following C Sharp .Net code constitutes a theory of
progress reporting.
I claim that any fixed-count (limit available at run time before the
start) for loop can be monitored by considering it as the attempt to
accomplish a TASK, the accomplishment of which involves only the
processing of zero, one or more ENTITIES with an ENTITY COUNT. The
actual user (the person running the program) needs to see at what
rate
processing runs.
Each time through the loop, we are at a specific ENTITY NUMBER.
Progress and velocity can then be modeled visually by means of a
histogram such that:
histogramDimension/maxHistogramDimension = entityNumber/
entityCount
Solving for histogramDimension each time the "progress" handler runs:
histogramDimension = entityNumber/EntityCount *
maxHistogramDimension
The visual histogram can be anything from a widening, lengthening
"progress bar" to a bunny running down a field.
This can be done syncronously with the caveat that if it's done in
the
same thread (or even if not on a single processor "multiprocessing"
system) as actual work, it slows work down. In doing progress
reporting, one is trying to compensate for the expense in physical
time with some sort of magic show that speeds up the psychological
time experienced by the user.
Think of it as the airline video you get in front of your seat even
back in steerage. Watching the wastes of Central Asia pass beneath
one
actually speeds up a Hong Kong to Paris flight because you can
actually see the Caspian come beneath you.
Of course, not all loops are fixed in number. For example, a program
such as Google's Picasa, which seems to want to search my hard drives
for images, is presumably walking a tree. A histogram model needs to
know the number of nodes in the tree at startup, and for large trees,
this might mean walking the tree to count before walking the tree to
do work. That's ridiculous. Here, you'd want to see a tree "grow"
even
though this would not show you how far you were to the end.
But even in cases of while and unknown-count for, it's user abuse to
show spinners and flashers that don't let the user know when the
process is done.
The following C Sharp delegates define my model. Comments welcome:
flamers may flame and be damned to you. Quertyuiop, you do not belong
in this discussion.
public delegate void progressStartEventDelegate
(object objTaskDoer,
thread objThread,
string strTaskName,
string strTask,
string strEntity,
int intEntityCount)
The progressStartEvent occurs just before a loop.
The objTaskDoer is the object performing the task.
The objThread is the thread in which the task is being performed.
The strTaskName is used by all progress delegates to identify a
specific task.
The strTask is a task description used only in this delegate.
The strEntity names the entity being processed.
intEntityCount will contain the total number of entities to be
processed.
The GUI is here responsible for keeping some information, probably in
a Lifo stack.
public delegate void progressEventDelegate
(object objTaskDoer,
string strTaskName,
int intEntityNumber)
The progressEventDelegate is called just after or just before one
entity is processed.
The objTaskDoer will be the object performing the task.
strTaskName should be the task name: it will be the same as the
strTaskName sent by the progressStartEventDelegate.
intEntityNumber will be the sequence number (from 1) of the current
entity.
public delegate void progressEndEventDelegate
(object objTaskDoer,
string strTaskName)
The progressEndEventDelegate is called at the normal end of a task.
The objTaskDoer will be the object performing the task.
strTaskName will be the task name as in the progressStartEvent.
public delegate void progressFailEventDelegate
(object objTaskDoer,
string strTaskName,
string strFailMessage)
The progressFailEventDelegate will be called when the task fails.
The objTaskDoer will be the object performing the task.
strTaskName will be the task name.
strFailMessage should be the reason for failure.
Of course, this could be much more elaborate. A "progress" object
could be defined. The problem is that it then seems nice to weight
this object down with all sorts of crap, such as a Tag of type object
for communicating more status information.
Now, I claim that this model is sufficiently simple and general based
on Kant: Kant believed that all experience of necessity is time-
ordered on one dimension such that for any two points in the time as
experienced by one or more knowers, the "less than" or "greater than"
operators can be meaningfully used.
If we're trying to reduce psychological stress, then all users live in
Kant time.
Multiple concurrent processes can be an array of histograms (and
multiple users watching the process can
lay bets on the winner if they be sporting gentlemen).
When the entityCount is not known, an estimate can be made, perhaps
saving persistent state so that previous runs of the software give
the
following runs an idea of the count.