SPO erratic behavior

[GoogleCodeExporter]

The behavior of webUI/B5500SPOUnit occasionally becomes erratic:

  * Appears to allow input while output is being typed.
  * Gets into a state where input cannot be terminated. Clicking End of Message or pressing Enter appears to act like the Error button. Input Request goes out, but immediately comes back on again.

These may be separate, independent problems or symptoms of a common one. The 
sequence of events to cause this is unknown. It's possibly and 
emulator/processor problem, but is more likely in the SPO logic.

Original issue reported on code.google.com by paul.kimpel@digm.com on 24 Mar 2013 at 10:01

[GoogleCodeExporter]

In B5500SPOunit.js, function outputChar (line 211), you set "this.outTimer" but 
since outputChar is invoked via timeout, the context will be the window object. 
Should that be that.outTimer?

If in the calls to setTimeout (lines 228, 231, 235 & 240) you used "function () 
{ that.outputChar (); }" in place of "that.outputChar", as you do in function 
keyPress, then you could dispense with the "outputChar.that" property mentioned 
in the function header comment and, incidentally, allow for multiple SPO's 
which would not work with the current code.

Not clear how this could cause erratic operation.

If function keyPress your correctly use a function literal and closure variable 
that to invoke keyPressChar via a timeout. 

Original comment by hans.pu...@gmail.com on 12 Sep 2013 at 4:53

[GoogleCodeExporter]

The property spoLocalRequested is referenced only twice, once to set it false 
at line 96 and once when it is tested at line 243. 

At line 243 you should 

    this.spoState = spoRemote;
    spoLocalRequested && this.setLocal ();

In setLocal at line 147 there should be something like 

          this.spoLocalRequested = false;  // clear pending request
      }
      else if (this.spoState == this.spoOutput)
          this.spoLocalRequested = true;  // wait for output to complete
      else
          console.log ('Cannot set SPO local, state is ', this.spoState); 

Again I do not see how this would cause a problem, your current implementation 
ignores any local button presses unless the SPO is in local state. The console 
log might throw some light on the matter when the glithch happens.

The console log might provide more

Original comment by hans.pu...@gmail.com on 12 Sep 2013 at 5:19

[GoogleCodeExporter]

In function cancelInput on line 271 you have 

        if (this.spoState = this.spoInput) {

Should this not be 

        if (this.spoState == this.spoInput) {

This might well be the cause!!

Original comment by hans.pu...@gmail.com on 12 Sep 2013 at 8:48

[GoogleCodeExporter]

Thanks, Hans. I found the "=" vs. "==" issue about a week ago, but have been 
busy with a conference and traveling, so have not released that change yet. It 
is definitely part of the local-mode problem. I'll look at your other comments 
after I get home, which will not be for another week yet.

Original comment by paul.kimpel@digm.com on 13 Sep 2013 at 12:33

[GoogleCodeExporter]

Hans,

Thank you for your several insightful comments on the implementation of 
the SPO. I thought that I had the Local/Remote behavior working at one 
point, and now can't find where I broke it. In any case, I have reworked 
the SPO implementation in a few significant ways:

  * The window and font size have been reduced to take up less space on
    the screen.
  * The messy "f.that" properties have been eliminated and, where
    appropriate, replaced with closures.
  * All of the timeouts are now handled by a new mechanism,
    setCallback(), which I originally developed to replace the
    setImmediate() shim and combine that functionality with
    setTimeout(), but which also allows me to specify the object context
    to be used with the callback function. This also eliminated some of
    the usage of "that".
  * The use of spoLocalRequested has been fixed. You were on the right
    track with your suggestions, but the detection of the local-pending
    state needed to be put in the Local button's click handler. I also
    removed the dependency of the setLocal() method on working only of
    the state was Remote.

It is not clear if of these changes have eliminated all of the erratic 
SPO behavior, but it seems much more stable now than before. These 
changes are queued up for version 0.13, which I hope to push out at the 
end of this weekend. The fix for the "=" vs. "==" problem had been made 
earlier this month and will be included with these changes.

Paul Kimpel

Original comment by paul.kimpel@digm.com on 28 Sep 2013 at 7:00

[GoogleCodeExporter]

The problem persists in releases 0.13 and 0.14, and appears to be triggered by 
clicking the ERROR button during input, or by pressing ESC (which is supposed 
to have the same effect).

Original comment by paul.kimpel@digm.com on 6 Oct 2013 at 5:51

• Changed state: Started

[GoogleCodeExporter]

The rewrite of SPO input handling for release 1.00 appears to have resolved 
these issues, but I will leave the issue open until we get some experience on 
this releasein the field.

Original comment by paul.kimpel@digm.com on 29 Sep 2014 at 3:01

[pkimpel]

Not having seen any of the former SPO problems in over a year, I am closing this issue as resolved.