*******************************************
* Bugs reported to 4/11/96 - Version 0.22 *
*******************************************

  An MC28 student reported the bug that the error dialog in SLIME can't
  be made to go away (not even by clicking OK, let alone by using the
  window manager's go-away feature).

Fixed by addition of ErrorDialog class in GUI.java.

******************************************
* Bugs reported to 9/22/96 - Version 0.2 *
******************************************

   Both the directory and the file name must be retrieved from the 
   FileDialog class.

Fixed.  The two can simply be concatenated together. - MGG

But not in all cases-- possible AWT problem:
>The filename bug is as fixed as I can get it.  As far as I've been able to 
>verify, the code I wrote works correctly if the user selects the file by 
>
>        - double-clicking on the filename
>        - clicking on the filename and then on "Open", or
>        - leaving the entire path in the "Selection" field when typing in 
>          a filename.
>
>What *doesn't* work is changing to the desired directory and replacing the 
>"Selection" field with a relative filename.  The FileDialog doesn't return 
>all the necessary information in this case; that is, the "Selection" field is 
>interpreted as relative to the working directory, not to the directory 
>the user changed to.
>
>Mark

   Slime isn't counting the halt instruction (i.e., incrementing the
   counter when it executes the halt). -max

Changed.  Now repeatedly "running" the same halt instruction counts it 
each time.  (Or is this desired behavior?) - MGG


******************************************
* Bugs reported to 9/19/96 - Version 0.1 *
******************************************

   Jumping to address 0 shouldn't be an exception, I don't think.  Unlike
   in SPIM, the user program is loaded at 0, so a jump to 0 can be a
   perfectly legitimate jump to the first instruction.

Fixed, changed > to >= in MachineState.jump -- MGG

   Why does the MachineThread busy wait, using yield?  Shouldn't it do
   wait() and have the procedures that change running to true do a
   notify()? Performance didn't seem too bad when you demoed it, but why
   ask for trouble on machines with wimpier schedulers or whatever?

Fixed, changed yield() to wait() in MachineThread.run, added notify() to 
MachineThread.stepExecution and MachineThread.startExecution().  (See 
also next bug.) -- MGG

   There is a race condition in MachineThread that can have particularly
   startling consequences, namely if someone presses the "step" button as
   the previous "step" is nearing completion, and it just happens to land
   between the running = false and stepping = false in the conditional at
   the end of run(), then you could wind up with the following
   interleaving:

   GUI thread               Machine thread
   ==========               ==============
   running = false
			    stepping = true
			    running = true
   stepping = false

   which leaves the machine in the continuous run mode, even though it
   was previously doing a step and was now supposed to do one more step!

Fixed, added synchronized keywords to MachineThread start, stop, step 
functions.   Added other synchronized functions to end the step and wait 
for next instruction.
[This allows the GUI to still function while waiting 
for console input; if the run() method was synchronized, the user
could create deadlock.] -- MGG

   Why doesn't allocate-registers include register 0 in the pool of
   registers it will allocate? (Or did I misread that?)

I thought it might be a good idea to always have a "zero" register around, 
as some machines do.  However, since I haven't actually implemented this, 
(and the instruction set doesn't really require  zeros 
for anything but moves from one register to another), so the start of the 
register allocation pool is now 0. -- MGG

   It looks like the parser's search for allocate-registers lines will
   match lines in which the string "allocate-registers " appears at the
   tail end of a label name, like

   li 0, label-at-which-I-allocate-registers  ; for example

Well, don't *do* that.  
OK, the new rule is: "allocate-registers " must either be (1) at the at 
the start of a line, or (2) preceded by only whitespace [no labels]. -- MGG

   ParseWord doesn't allow negative immediates, contrary to my expectations.

ParseWord now checks if first char of the argument is a "-" and second is 
a digit.  [May want to allow + as well?] -- MGG

   Assuming that were fixed, then ParseReg would fail to catch negative
   register numbers.

Fixed by giving same error for "result < 0". -- MGG

   I'm not sure whether the handling of an empty string in ParseWord is
   reasonable -- is there some syntactically invalid input that would
   lead to this "internal error" being flagged when it is really just a
   syntax error?  My intuition says yes, but I didn't check carefully.

StringTokenizer should never return an empty string, so I can depend 
on having 1 character.  The recently introduced checking for negative 
numbers accesses charAt(1), but this is protected by a check for 
length > 1.  Thus, the exception should never be called. -- MGG

   Why is there no message when an attempt is made to enter a
   syntactically bogus number into the PC, unlike with the registers?

There is now.  [Also, the value in the PC or register will now remain 
unchanged for bogus numbers.]

   There is a race condition in the reset button, in that it doesn't wait
   for execution to actually stop before resetting the state.

   Ditto for the load button -- it asks the machine to stop, but doesn't
   wait until it really stops before loading new code.

This gets fixed by MachineThread.stopAndWait.  The fix could lead to 
deadlock with the Console class, so stop, reset, and load all cancel 
console input.  (Which is better behavior, anyway.)  -- MGG

   There is also a nasty race between setting a register or the PC from
   the GUI and the running machine doing so -- nasty in that it isn't
   just a matter of it being non-deterministic who "wins" (which would be
   unavoidable, unless you disabled the GUI while the machine was
   running), but rather in that each can "half win" -- one thread might
   win the race for the value stored internally in the state while the
   other thread won the race for the value displayed externally in the
   text field, so that the display didn't match reality any more --
   that's what I mean by a "nasty race", and it should be avoided.

Fixed by synchronization of MachineState.setPC and 
MachineState.setRegister. -- MGG

   Another thing I didn't understand (and users might not) is why setting
   the PC clears the exception flag -- will users understand that this is
   the way to clear an exception condition (without doing a full reset)?

An addition to the UI is probably called for here, although I think changing 
the PC should still clear the exception. -- MGG




