Fix for issue 1598.
Lexical scope comes before inherited names. Also, Static members
are not inherited and are not visible in subclasses.
Code in the subclass (or any other code for that matter) has to
qualify the names of these members with the class name.
We had a few tests that were wrong and only passed in the VM because
this was not implemented correctly.
Also had to fix code in frog and dartdoc.
I hope I ran enough tests. I built an all.deps tree using tools/build.py from the root directory, which brought up the frog and dartdoc issues.
Tested:
tools/test.py --compiler=dart2js --runtime=drt
tools/test.py -c none -r drt
tools/test.py -c frog -r drt
tools/test.py -r vm
Review URL: https://chromiumcodereview.appspot.com//10115005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6698 260f80e4-7a28-3924-810f-c04153c831b5
NOTE: This is a breaking change.
The onRequest callback on the HTTP server have been removed in favor
of the ability to register handlers. A handler can be either a
function or an instance of a class which implements a specific
interface. Each handler registration has a regular expression which is
matched against the request path.
There is also a default handler which can be set to handle all
requests which is not matched by any of the registered patterns. If
there is no default handler explicitly set there is a builtin one
which will just return 404 status.
Currently the method is not considered in the matching.
R=ager@google.com, ajohnsen@google.com
BUG=none
TEST=tests/standalone/src/io/HttpServerHandlerTest.dart
Review URL: https://chromiumcodereview.appspot.com//10119005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6683 260f80e4-7a28-3924-810f-c04153c831b5
Map<String, String> env = new Platform().environment();
Unfortunately, this is a bit hard to test at this point. I
will move on to implement support for providing an environment
to processes that are started. At that point we can test it
properly.
Another follow-up change will be to remove the instantiation
for Platform. I would like this to be just
Map<String, String> env = Platform.environment();
R=sgjesse@google.com
BUG=dartbug.com/752
TEST=
Review URL: https://chromiumcodereview.appspot.com//10112002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6646 260f80e4-7a28-3924-810f-c04153c831b5
The HTTP parser now recognized both HTTP/1.1 and HTTP/1.0 in
request and response headers. The only difference between the
handling of HTTP 1.1 and HTTP 1.0 is in the decection of
persistent connections. For HTTP 1.1 persistent connections are
the default and for HTTP 1.0 persistent connections are speficified
throught the "Connection: Keep-Alive" header.
Removed the getters and setters for keepAlive from all the
interfaces. They are not of much use and persistent connection
handling should be transparent. The HTTP client currently always
sends requests using HTTP 1.1 and in the reare cases where one wants the
connection to be closed after the request adding the
header "Connection: close" should work.
With this change using wget to get resources from the chat server.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//10008083
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6509 260f80e4-7a28-3924-810f-c04153c831b5
First attempt at implementing a higher-level API for processes.
Add a startNonInteractive constructor that takes a callback which
is called with the exit code and the complete stdout and stderr
when the process terminates.
Let me know what you think. This obviously needs at least tests.
Not entirely sure what I think about the interface in the first
place.
R=sgjesse@google.com
BUG=1689
TEST=
Review URL: https://chromiumcodereview.appspot.com//9863015
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6499 260f80e4-7a28-3924-810f-c04153c831b5
If any type of HTTP connection encounters an error writing additional
data is an error. However in many cases getting exceptions from writes
in this situation is inconvenient.
With this change any data written will be silently discarded after an
error have occoured. The onError will always be called and the user of
the library have the ability to stop generating output data as soon as
possible.
Currently this is default behaviour with no option for changing it.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9958059
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6089 260f80e4-7a28-3924-810f-c04153c831b5
The directory object now has error handling like the rest of the
dart:io. The added tests to some extend overlaps with some of the
tests in DirectpryTest.dart, but I found it better to have error tests
in a single place.
I removed a few type checks sitting in the C++ code for the native
functions as for file we currently don't have them. I have opened
issue 2305 regarding where to do type checks for dart:io native
functions.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9773018
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5866 260f80e4-7a28-3924-810f-c04153c831b5
Now all both sync and async methods on File and RandomAccessFile
should have correct error handling.
Changed readByte and readByteSync to return -1 instead of
reporting an error when end of file is reached. It seems to make
the most sense.
The amount of boiler-plate code in both the native functions and
native port functions in file.cc is growing. Maybe we should
consider some refactoring, e.g. with a table of the expected
argument types for each native port functions together with known
position of the FILE* argument.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9839053
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5812 260f80e4-7a28-3924-810f-c04153c831b5
The socket errors and HTTP parser errors are now handled by the
HTTP library and propagated to the related onError callback.
For HttpClient there is no onError on the HttpClient object
itself. Errors on active connections (including connection
errors) are reported on the HttpClientConnection. Errors on
connections sitting in the keep alive pool are handled by just
closing the connection and removing it from the pool. Errors on
the HttpClientConnection are also reported through the onError
callbacks on any active streams.
I am not particulair happy of the way errors are propagated to
the active streams but that can be refactored later.
Added more checks and tests to the HTTP parser.
R=ager@google.com, ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9834008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5768 260f80e4-7a28-3924-810f-c04153c831b5
regis@google.com