RANDOMS - Miles Goodhew

This deck is essentially a "live" input example for one of our CDUG members.

·What do you mean "live" input?
	Well,  CanDo  is mostly an event-driven authoring system.  That is,
actions  occur  only  as  a result of events, if no "events" have occurred,
then the program just "waits" for one to happen.  Events are usually caused
by  Human  interaction  (user  presses  a button, user inserts a disk), but
there are exceptions ("alarm-clock" timer events, etc.).
	On  the  other  hand,  there's  another  program methodology called
"real-time",  where  a  program (more-or-less) spends no time "waiting" for
events to occur.  However, the program from time to time checks to see that
any of its input event conditions have occurred, and if so deals with them.
Otherwise the program goes off on its merry way, and does something else.

· What are their (dis)advantages
	Well,  Event-driven  programs  fit-into a multi-tasking system much
easier  than  real-time  programs  (as  event-driven  programs have no major
requirements for performance).  Real-time programs can squeeze the most out
of  a  computer  by  using  every CPU cycle available, but only as a single
task.   Event-driven  programs  can  free-up  the  CPU  to attend to busier
programs  by "waiting" for events to occur (i.e.  they will get no CPU time
until one of their events has occurred).  Real-time programs tend to employ
a method called "busy-waiting", where the program checks to see if an event
has  occurred,  if  it hasn't then the program loops-back, and tries again,
and  so-on  until the event has happened.  This approach wastes CPU-time in
multi-tasking   systems   (indeed  in  a  single-tasking  system,  this  is
effectively disposing of unwanted CPU cycles).

· So what does this program do?
	This  program  has  one button. When the user presses it, and keeps
the  button  pressed, the program will generate a series of random numbers.
When the button is released (or "rolled-off"), the program stops generating
the   numbers.    This  is  effectively  a  hybrid  between  real-time  and
event-driven  programming:   Until the user presses the button, the program
is waiting for an event.  Having pressed the button, the program drops into
a  busy-waiting  loop  that calculates the random values, and checks to see
whether the button is in an "off" state (released).  If the button is still
down,  then  the  program  loops back,  and  does it all again (calculating
randoms, etc.)

· Bugs?
	As  soon  as  the mouse pointer "rolls-off" the button (i.e.  moves
out  of  its  hit-box,  with  the  left mouse button held down), the random
numbers   stop,   and  won't  re-start  until  the  left  mouse  button  is
pressed down  again.   This happens even if the pointer rolls back onto the
button.   This  is because the button being "off" is the exit condition for
the busy-waiting loop (whereapon the program will return to the button-down
event-driven mode of operation).
	You   could   get  around  this  by  making  the  program  entirely
event-driven  (i.e.   button down and up loops), but this would be wasteful
of  CPU  time  (particularly  in  this instance, where the program would be
doing  nothing  while  waiting  for  the  button-down  event).  This can be
avoided  by  having  the  program "clocked"  by a timer event.  That is, on
each  timer event (with frequency no more than about 50-60 per second), the
program does its button-level checking, and acting upon the results.  This
allows for a reasonable user-response time, while still keeping a great deal
of CPU cycles for "OS-friendlier" programs.
	Another method is to use essentially the original program, but have
the  left mousebutton  level  as  the  exit  condition  (and  possibly  the
screen-button  level  as  a  condition for generating randoms).  This would
mean  that the effective operation is:  Having pressed the mouse-button on,
and  holding  the  pointer  over  the screen button, random numbers will be
generated,  otherwise  nothing happens.  This means that the user can press
the button, roll off, and back on again, and the behaviour is as expected.