[m-dev.] for review: bug fix for browser output streams.
fjh at cs.mu.OZ.AU
Thu Dec 17 10:28:00 AEDT 1998
On 13-Dec-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 13-Dec-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 07-Dec-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > Fix a bug in the debugger -- the term printing wasn't working after
> > > you had changed the output stream -- output would be sent to the
> > > program's output stream instead of the debugger's output stream.
> > That change looks OK. But I think the default stream for the browser
> > output should be stdout, not stderr, for consistency with the
> > rest of output from the internal debugger, which (apart from error
> > messages) currently goes to stdout.
> I thought they were stderr. Must have mis-read it.
This change (using stderr instead of stdout) broke all the
debugger test cases. I guess you didn't run the tests before
> > But I also have a comment about the longer-term evolution of this code.
> > Ideally, `mdb' should have options for doing all the I/O on a different
> > xterm or tty. These would be passed to the Mercury runtime,
> > which would in turn pass them on to the browser.
> > So there should be a version of `browse__init_state' which takes
> > an input stream and an output stream as arguments.
> 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.
Fergus Henderson <fjh at cs.mu.oz.au> | "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh> | but source code lives forever"
PGP: finger fjh at 220.127.116.11 | -- leaked Microsoft memo.
More information about the developers