In general, a test which gets its input piped in is not really interacting with a terminal like it normally would. Thus, letting it think it has the same terminal as the environment is incorrect. More specifically, hphpd uses Readline, which inspects the TERM env var and based on that and a stunning array of other options will attempt to initialize the terminal with extra control characters on first use. It would be tough to try to control for all of the different options and ensure they're all the same, and honestly testing Readline is not the objective of our tests anyway. Thus, I'm forcing TERM to 'dumb' when a test has input to ensure a) a simple terminal which requires no control characters and b) consistency no matter what environment is present when the tests are run.
It seems that on some machine configurations the readline library has the bad idea of spewing some control characters to stdout. This causes failures in any test that is reading from the command line, which currently only happens in debugger tests. Possibly this behavior shows up on the continuous build machines, so we'll make the expected output provide for this variation, just in case.
The debugger client now accepts feedback from the the debugger server about whether a breakpoint can be hit, absent further loads of files, classes or functions.
Small stepping, which is stepping over sub-expressions (kinda), worked but was a little goofy. The mode was set on the client, passed over with control flow commands, placed on the execution context, then retrieved from there and used by those same flow commands. Removed the execution context part of it, since it was useless, and factored grabbing the offsets into the flow cmds where they belong instead of doing it all the time.
The run cmd also had some notion of small stepping, but you'll note it was never sent over the wire. Nuked that, since it never mattered anyway.
Mike Magruder