[m-dev.] for review: bug fix for browser output streams.

Tyson Dowd trd at cs.mu.OZ.AU
Thu Dec 17 12:12:48 AEDT 1998

On 17-Dec-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> This change (using stderr instead of stdout) broke all the
> debugger test cases.  I guess you didn't run the tests before
> committing...

No, I didn't.  Disk space has been short, and I figured it was
a non-critical area to break.  Also, I expected the compiler to be
installed relatively quickly and I could simply run the tests from
the installed compiler.

I've been meaning to fix this, but have been working on other things.

> > I agree.  That's why I went to all the trouble of putting the input
> > and output streams into the browser state instead of just hardcoding
> > them when required.
> I'm not sure that was a good idea.  After all, with your change,
> the top-level routines extract the streams from the browser
> state and put them into the io__state (using io__set_current_input
> and io__set_current_output).  The intermediate and bottom-level 
> routines don't access the stream fields of the browser state
> at all.  So it may be easier to just pass the streams as arguments,
> rather than storing them in the browser_state.

I don't see why this is a problem.  The top-level routines set
the stream that the lowel level routines will use.  You could
thread it all the way through to the low level, but eventually the
low level code just does a "io__set_current_input" anyway.

The intention is that you can add a single new predicate to set the
stream in the browser state and so change what stream everything
uses.  No other code needs to be changed.

If you thread stream arguments through, you are always running the
risk that someone is going to write code that doesn't set the streams
correctly when it does I/O.  That's why I thought was best to set it
at the top level.


More information about the developers mailing list