External strings refer to character data in memory located outside of
the managed heap. This memory is considered to be owned by the
embedding application. To help with the management of external
memory, the virtual machine allows the embedding application to
register for a "death notice" when an external string object is
garbage collected. A death notice takes the form of a callback
invoked by the garbage collector with the address of the external
memory. Death notices will be implemented in the garbage collector by
future commit.
Review URL: http://codereview.chromium.org//8383029
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1679 260f80e4-7a28-3924-810f-c04153c831b5
Change the default value of --silent_warnings from true to false, so that
warnings are visible when legacy factory syntax is used.
In order to facilitate transition of libraries and user programs, legacy factory
syntax is still supported by 2 workarounds, but warnings are printed.
The first workaround allows the factory clause to omit the type
parameter list, which otherwise has to match exactly with the list of
type parameters in the factory class declaration.
The second workaround allows a factory method to omit the type
parameter list. In that case, the type parameter list of the enclosing
class is used instead.
Workarounds will be removed to enforce correct factory syntax at a later time.
Review URL: http://codereview.chromium.org//8585004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1595 260f80e4-7a28-3924-810f-c04153c831b5
Create handle objects for stdin/stdout/stderr. For Mac OS and
Linus the file descriptor numbers are used but on Windows the
handles are wrapped in an object.
The system handles for stdin/stdout/stderr on Windows does not
support overlapped IO. To mittigate this the write calls are
performed synchronously and the read calls are preformed in a
thread which posts the result through the completion potr where
it is handled as if it originated from overlapped IO through the
completion port. For now each call to read starts a new thread.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8574002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1533 260f80e4-7a28-3924-810f-c04153c831b5
When using stdout/stderr it is no longer necessary to explicitly
close the streams for the program to terminate. The automatic
close is handled by always closing the associated receive port
for write only streams when not waiting for any events. If a
close or error handler is installed for stdout/stderr these will
still keep the program alive.
For stdin better handling of the difference between sockets and
pipes have been immplemented. As a special case for stdin when
reading from a terminal the a POLLIN signal with 0 available
bytes is treated as end-of-file. This will trigger when pressing
ctrl-d in a terminal as POLLHUP is not set in that situation.
R=ager@google.com
BUG=
TEST=
Review URL: http://codereview.chromium.org//8533005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1507 260f80e4-7a28-3924-810f-c04153c831b5
Print out first 5 elements of an array object, rather than
just 'Array'. This helps in particular in disassembled
method and stub calls which now print the content of the
IC cache and ArgumentsDescriptor arrays. E.g.:
0x7404a5 ff7508 push [ebp+0x8]
0x7404a8 ff750c push [ebp+0xc]
0x7404ab b9012f7000 mov ecx,0x702f01 Array[bitAndFromInteger, 1, null, null]
0x7404b0 bafd050003 mov edx,0x30005fd Array[2, 2, null]
0x7404b5 e8b6fcffff call 0x740170 [stub: InlineCache]
0x7404ba 83c408 add esp,0x8
Review URL: http://codereview.chromium.org//8491061
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1493 260f80e4-7a28-3924-810f-c04153c831b5
--
Terminology change: invalid handles are now called error handles.
Unhandled exceptions used to be a kind of valid handle. Now they are
a kind of error handle.
For the Dart_Invoke* functions, this means that the standard
error-checking blob drops from two tests to one test and is
harder to mess up.
Many other Dart api functions (Dart_ToString, for example) previously
dealt with unhandled exceptions by turning them into terse error
messages. Now these functions preserve information about the
exceptions and generate better error messages.
Changed Dart_HandleMessage to return success/failure. It seemed to fit.
--
Details:
Dart_IsValid becomes Dart_IsError (negated sense).
Dart_GetError now knows how to print a stack trace semi-nicely.
Dart_ExceptionOccurred -> Dart_IsUnhandledException.
Renamed ApiFailure class to ApiError to fit better.
ApiError now has a "data" pointer that points to either an error
message string or to an unhandled exception object.
Documentation changes aplenty.
Review URL: http://codereview.chromium.org//8501034
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1470 260f80e4-7a28-3924-810f-c04153c831b5
This means that you will continue to have crashes in Debug mode, but you will be able to "run" in Release mode. Best solution is to get rid of generic types in Link until factories and generic types have been fully implemented. Until then we do not know what can happen when running in release mode.
Still trying to figure out how to test frog and leg correctly.
Review URL: http://codereview.chromium.org//8540013
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1469 260f80e4-7a28-3924-810f-c04153c831b5
cshapiro@google.com