Add basic standalone debugger test

Add basic standalone debugger test

Tests the wire protocol API to the VM debugger engine. This is a first,
basic test. Additional functionality will be added later to check the
expected value of variables, list libraries, scripts, breakpoints etc.
Committed: https://code.google.com/p/dart/source/detail?r=16327

[hausner, 2012-12-17 19:02:17]

Mads, if you could please look at the code in debug_lib.dart and tell me whether
my use of the io library is reasonable. I know that the fixed port number is not
scaleable. We can talk offline about alternatives.

[Mads Ager (google), 2012-12-18 06:38:50]

LGTM for the dart:io part.

https://codereview.chromium.org/11576053/diff/3001/tests/standalone/debugger/...
File tests/standalone/debugger/debug_lib.dart (right):

https://codereview.chromium.org/11576053/diff/3001/tests/standalone/debugger/...
tests/standalone/debugger/debug_lib.dart:79: int nexting = 0;
nesting

https://codereview.chromium.org/11576053/diff/3001/tests/standalone/debugger/...
tests/standalone/debugger/debug_lib.dart:117: if (node is Map) {
Identation a bit off here.

https://codereview.chromium.org/11576053/diff/3001/tests/standalone/debugger/...
tests/standalone/debugger/debug_lib.dart:165: if (!matchMaps(template, msg))
debugger.error("message does not match $template");
There are a few long lines in this file.

https://codereview.chromium.org/11576053/diff/3001/tests/standalone/debugger/...
tests/standalone/debugger/debug_lib.dart:509: process.stdin.close();
You should drain stdout and stderr here as well to make sure that dart:io closes
the pipes:

process.stdout.onData = process.stdout.read;
process.stderr.onData = process.stderr.read;

In this case it probably doesn't matter much since this script will terminate
and close everything and a couple of pipe leaks will not matter.

[siva, 2012-12-19 18:28:58]

LGTM

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
File tests/standalone/debugger/basic_debugger_test.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/basic_debugger_test.dart:37: SetBreakpoint(8),  // Set
breakpoint a line 15, in function bar.
Set breakpoint at line 15.....

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
File tests/standalone/debugger/debug_lib.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:44: } else {
assert(msgLen < buffer.length);

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:54: // as JSON. If it is invalid, a
later JSON.parse() will fail.
Maybe you should add to the comment that this function returns 0 if only a
partial JSON meesage has been received in the buffer so far.

https://chromiumcodereview.appspot.com/11576053/diff/7001/tests/standalone/de...
File tests/standalone/debugger/debug_lib.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/7001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:52: // The object value must start with
'{' and continues to the
and continue to the

https://chromiumcodereview.appspot.com/11576053/diff/7001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:204: for (int i = 0; i <
functionNames.length; i++) {
You seem to use var for all local variables always so why
not for (var i = 0.....) {

https://chromiumcodereview.appspot.com/11576053/diff/7001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:400: // form the last command has been
received and processed.
from

https://chromiumcodereview.appspot.com/11576053/diff/7001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:431: sendNextCommand();
I am wondering if you would need to drain all the messages that are in the
buffer before sending down the next command.

[hausner, 2012-12-19 22:01:51]

Will check updated test in with a subsequent CL.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
File tests/standalone/debugger/basic_debugger_test.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/basic_debugger_test.dart:37: SetBreakpoint(8),  // Set
breakpoint a line 15, in function bar.
On 2012/12/19 18:28:58, siva wrote:
> Set breakpoint at line 15.....
Good catch. The test passed anyway, basically terminating too soon. Added check
to make sure we see all expected debugger events before the shutdown event.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
File tests/standalone/debugger/debug_lib.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:44: } else {
On 2012/12/19 18:28:58, siva wrote:
> assert(msgLen < buffer.length);

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:54: // as JSON. If it is invalid, a
later JSON.parse() will fail.
On 2012/12/19 18:28:58, siva wrote:
> Maybe you should add to the comment that this function returns 0 if only a
> partial JSON meesage has been received in the buffer so far.

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:54: // as JSON. If it is invalid, a
later JSON.parse() will fail.
On 2012/12/19 18:28:58, siva wrote:
> Maybe you should add to the comment that this function returns 0 if only a
> partial JSON meesage has been received in the buffer so far.

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:79: int nexting = 0;
On 2012/12/18 06:38:50, Mads Ager wrote:
> nesting

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:117: if (node is Map) {
On 2012/12/18 06:38:50, Mads Ager wrote:
> Identation a bit off here.

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:165: if (!matchMaps(template, msg))
debugger.error("message does not match $template");
On 2012/12/18 06:38:50, Mads Ager wrote:
> There are a few long lines in this file.

Done.

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:509: process.stdin.close();
On 2012/12/18 06:38:50, Mads Ager wrote:
> You should drain stdout and stderr here as well to make sure that dart:io
closes
> the pipes:
> 
> process.stdout.onData = process.stdout.read;
> process.stderr.onData = process.stderr.read;
> 
> In this case it probably doesn't matter much since this script will terminate
> and close everything and a couple of pipe leaks will not matter.

Done. But is this really the right thing to do since I connect a
StringInputStream to stdout and stderr in the Debugger() constructor...

[Mads Ager (google), 2012-12-20 07:40:51]

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
File tests/standalone/debugger/debug_lib.dart (right):

https://chromiumcodereview.appspot.com/11576053/diff/3001/tests/standalone/de...
tests/standalone/debugger/debug_lib.dart:509: process.stdin.close();
On 2012/12/19 22:01:51, hausner wrote:
> On 2012/12/18 06:38:50, Mads Ager wrote:
> > You should drain stdout and stderr here as well to make sure that dart:io
> closes
> > the pipes:
> > 
> > process.stdout.onData = process.stdout.read;
> > process.stderr.onData = process.stderr.read;
> > 
> > In this case it probably doesn't matter much since this script will
terminate
> > and close everything and a couple of pipe leaks will not matter.
> 
> Done. But is this really the right thing to do since I connect a
> StringInputStream to stdout and stderr in the Debugger() constructor...

Urgh, I missed that. No, in that case you shouldn't do anything here. There is
no harm in doing it since the debugger constructor will overwrite the handlers
before you enter the event loop again but it does look weird. Sorry about that!
:-)