| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Review URL: https://codereview.chromium.org/107113005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239204 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
BUG=
Review URL: https://codereview.chromium.org/93813002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237867 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
R=mkwst@chromium.org
TBR=abarth@chromium.org
BUG=324225
Review URL: https://codereview.chromium.org/94413002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237750 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
BUG=
Review URL: https://codereview.chromium.org/89723002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237492 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were using JavaScript bindings to gtest to unit test JavaScript
code in Gin and Mojo. The gtest bindings were very basic and not very
idiomatic.
This CL introduces a simple AMD module call "expect" to help us write more
idiomatic unit tests. The API for "expect" is based on the popular Jasmine unit
testing framework for node.js. I investigated just importing one of Node's many
unit testing frameworks, but they all try to do too much (e.g., drive the
entire test harness via Node's file system interface).
The "expect" modules doesn't try to drive the testing process. We just let
gtest handle that. Instead, "expect" just provides a simple language in which
to write test assertions. We'll likely evolve our testing strategy over time,
but hopefully this CL is an improvement over the primitive gtest bindings.
R=jochen@chromium.org
TBR=joth@chromium.org
BUG=none
Review URL: https://codereview.chromium.org/85223002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237145 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, I tried to make the JavaScript bindings for the core Mojo APIs a
literal translation of the C APIs, but that makes MojoReadMessage a bit awkward
because C needs to worry much more about buffer allocation than JavaScript. In
building towards using the hello_world_service, I found that it was much easier
to push the MojoReadMessage pattern from connector.cc into C++ and make the
JavaScript API a bit more idiomatic by just returning an ArrayBuffer for the
message and an Array of handles.
BUG=317398
Review URL: https://codereview.chromium.org/83143002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236999 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
API, which we plan to use for JavaScript in Mojo. We don't
yet implement every feature in the AMD spec
<https://github.com/amdjs/amdjs-api/wiki/AMD>, but we
implement the basic framework, which will let us get started
writing and testing JavaScript modules in Mojo.
The two other leading choices for a modules system are
CommonJS and ES6 modules. We decided not to use CommonJS,
despite its popularity, because it implies the ability to
load modules synchronously. That works well in server
environments like node.js, but it won't work well for Mojo
where modules might be loaded across a network.
I would really like to have used ES6 modules, but the spec
isn't finalized yet and V8 doesn't yet implement them. It's
likely that we'll replace this AMD module system with ES6
modules once ES6 modules are ready.
Structurally, I've implemented AMD in the ModuleRegistry
class in a new "modules" directory in Gin. Nothing else in
Gin (except the tests) depends on ModuleRegistry, which
means folks are free to use Gin without AMD. At the Mojo
layer, I've added a dependency on AMD.
BUG=317398
Review URL: https://codereview.chromium.org/62333018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@235543 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL contains the beginnings of JavaScript bindings for the core Mojo
system. The approach in this CL is to bind as close to the "metal" as possible
so as to self-host as much as possiblem in the VM. I've tried to avoid
retaining any state on the C++ side of the bindings, but I didn't quite succeed
because V8 requires embedders to retain state in order to access the memory
that backs ArrayBuffers.
In this CL, I've added some basic bindings for the symbols exported by core.h.
Specifically, I've created bindings for CreateMessagePipe, Close, Wait,
WaitMany, WriteMessage, and ReadMessage.
R=aa@chromium.org, darin@chromium.org
BUG=317398
Review URL: https://codereview.chromium.org/59153005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234347 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
Unlike the extensions V8 bindings, gin is based on ObjectTemplates rather than
on evaluating script. Unlike the Blink V8 bindings, gin isn't tightly coupled to
Blink. In fact, gin's only link-time dependency is V8. We plan to use gin to build
the V8 bindings for Mojo (see https://codereview.chromium.org/59153005/ for
an example of how they will be used).
In the long term, gin could serve as a basis for both the Blink and the extension
system bindings, but we don't have any immediate plans to pursue that use of
this code.
This code is largely inspired by a lightweight bindings system designed by
Aaron Boodman.
Review URL: https://codereview.chromium.org/67763002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234160 0039d316-1c4b-4281-b951-d872f2087c98
|
