| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
. Runner no longer extends ContextHolder. It will still have a
ContextHolder, but not own it. This enables a couple of
things:
. Runner no longer need own a v8::Context.
. Runner can be lazily created after the ContextHolder.
. Runner becomes a (mostly) pure virtual interface. This enables an
implementation to execute through blink rather than v8 directly.
. What was Runner is now DefaultRunner (and
DefaultRunnerDelegate). I'm not a fan of these names, if you have
better ideas let me know. Maybe DirectRunner?
BUG=none
TEST=none
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/179803007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253732 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
Various further rework of bindings stuff to facilitate.
Review URL: https://codereview.chromium.org/120043008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242284 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
Right now I am just translating as directly as possible from the C spinning cube demo -- once it all works I will circle back through and refine the JavaScript.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/114883003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242230 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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This CL connects mojo_js with hello_world_service. After this
CL, the JavaScript and C++ implementations have reached
parity.
BUG=317398
Review URL: https://codereview.chromium.org/82953004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237018 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Gin class holds and controls a v8::Isolate. The isolate is not
entered by default, i.e. before you can use gin for a given Gin
instance, you need to enter the isolate first, e.g. by using a
v8::Isolate::Scope.
This has the advantage that we don't rely on the deprecate default
isolate, and also support having multiple isolates in one process.
BUG=317398
R=abarth@chromium.org
TEST=gin_unittests and mojo_js_bindings_unittests pass
Review URL: https://codereview.chromium.org/76353002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236029 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL completes the manual implementation of sample_service.js and tests it
using sample_test.js, which exactly mirrors the testing of sample_service.cc by
sample_service.cc.
(I've also moved sample_service.js into mojo/public/bindings/sample/mojom to
better mirror the C++ implementation.)
BUG=317398
Review URL: https://codereview.chromium.org/68323004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@235917 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL adds a simple shell program for Gin to make edit/test/debug cycle
faster. The shell excutes a list of scripts from the command line and loads any
requested AMD modules relative to the current working directory.
This CL will also let us remove the ugly code in
https://codereview.chromium.org/69843003/diff/240001/mojo/public/bindings/js/test/run_js_tests.cc
because we now know how to file modules via the file system. Eventually for
Mojo, we'll want to use a net_module_provider (instead of the
file_module_provider included in this CL) to load additional AMD modules off
the network.
BUG=317398
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/74753002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@235750 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
|
