summaryrefslogtreecommitdiffstats
path: root/gin/runner.h
Commit message (Collapse)AuthorAgeFilesLines
* Refactors parts of gin:sky@chromium.org2014-02-271-36/+15
| | | | | | | | | | | | | | | | | | | | | . 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
* [gin] Turn gin into a componentjochen@chromium.org2013-12-121-3/+4
| | | | | | | | | | | | This will allow for using gin from content and blink at the same time in a component build BUG=321631 R=abarth@chromium.org,aa@chromium.org Review URL: https://codereview.chromium.org/101583004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240425 0039d316-1c4b-4281-b951-d872f2087c98
* [gin] move context_holder to public/jochen@chromium.org2013-12-061-1/+1
| | | | | | | | | | | | Also, define names for the embedder data slots on v8::Context that gin embedders should use. BUG=321631 R=abarth@chromium.org Review URL: https://codereview.chromium.org/104593007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239099 0039d316-1c4b-4281-b951-d872f2087c98
* [Gin] Add documentation to explain how Gin worksabarth@chromium.org2013-11-271-0/+9
| | | | | | | | | | | | | This code is likely to evolve over time, but we've reached a stage where the basic structure is mostly in place. This CL documents this structure so that future developers will understand what we have in mind now. R=aa@chromium.org BUG=none Review URL: https://codereview.chromium.org/88913006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237485 0039d316-1c4b-4281-b951-d872f2087c98
* [Gin] Add a basic unit testing frameworkabarth@chromium.org2013-11-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Mojo] Almost connect mojo_js with hello_world_serviceabarth@chromium.org2013-11-251-2/+7
| | | | | | | | | | | | 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
* Introduce a Gin class instead of using global functions to control ginjochen@chromium.org2013-11-191-0/+1
| | | | | | | | | | | | | | | | | | 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
* Introduce gin_shellabarth@chromium.org2013-11-181-1/+12
| | | | | | | | | | | | | | | | | | | | 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
* This CL implements the Asynchronous Module Definition (AMD)abarth@chromium.org2013-11-171-17/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 introduces a lightweight bindings system for V8 called ginabarth@chromium.org2013-11-101-0/+67
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
generated by cgit v1.1 at 2024-08-05 09:46:26 +0000