11 Commits

Author SHA1 Message Date
Eric Seidel
c78cea7e54 Allow multiple dart <script> tags in .sky files
This does several things:
1.  Teaches sky about asynchronous script execution. Previously once all imports
were loaded and the script text was available, we executed a script and assumed
it completed synchronously.  We left the parser loop to do so, but that was fine
as the next chunk from the background thread would resume the parser.  In this
change scripts now load and execute separately.  The "load" step may trigger
further dart import loads which may cause the execution to happen asynchronously
which required teaching both the DartController and the HTMLScriptRunner to
take callbacks to allow HTMLDocumentParser to know to continue parsing after
the Dart script has resolved its imports and executed.

This required re-working some of how the parser executes scripts and I
re-purposed isWaitingForScripts to include "is the parser blocked" where
as before it was limited only to "does the treebuilder have a script", even
though the imports system may have had pending scripts as well.

I made HTMLScriptRunner live only as long as the script it was executing
since it only contained per-script state at this point.

2.  Fixed an error reporting bug whereby we would not show errors when "init"
failed to execute, only "main".  This required using the dart_mirrors_api.h
which required adding an include path to the core build. :(

3.  Made it possible for a single sky file to contain multiple dart <script>
tags.  Each <script> is a separate library and executes as
soon as </script> is seen.  main or init is called for each.  This required
mangling "urls" for these script blocks since Dart unique's libraries by urls.
Before this change it may have been possible to do <import 'foo.sky'> and then
<script>import 'foo.sky'</script> and have it work!?

R=abarth@chromium.org
BUG=

Review URL: https://codereview.chromium.org/938623005
2015-02-20 11:08:28 -08:00
Adam Barth
f2d2e80e59 Merge the Sky Engine changes from the SkyDart branch
This CL flips the switch to make Sky use Dart.

TBR=eseidel@chromium.org
BUG=454613

Review URL: https://codereview.chromium.org/922893002
2015-02-12 15:06:03 -08:00
Elliott Sprehn
30c38af903 module.exports should default to an empty object.
Per the spec in modules.md the exports property should default to an
empty object. We lazy allocate it so that modules that just replace it
don't create the empty object and then throw it away.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/872043003
2015-01-26 11:38:04 -08:00
Adam Barth
da75d15a1b Merge HTMLDocument into Document
HTMLDocument is the same as Document. We can merge them.

R=eseidel@google.com

Review URL: https://codereview.chromium.org/871383002
2015-01-25 23:48:53 -08:00
Eric Seidel
295f920116 Fix sky include guards to match Chromium style
I wrote a script to do this which is attached
to the bug.

TBR=abarth@chromium.org
BUG=435361

Review URL: https://codereview.chromium.org/736373003
2014-11-21 02:48:38 -08:00
Eric Seidel
e0fd75b5ab Make absolute and sort all Sky headers
This caused us to lose our gn check certification. :(

Turns out gn check was just ignoring all the header
paths it didn't understand and so gn check passing
for sky wasn't meaning much.  I tried to straighten
out some of the mess in this CL, but its going to take
several more rounds of massaging before gn check
passes again.  On the bright side (almost) all of
our headers are absolute now.  Turns out my script
(attached to the bug) didn't notice ../ includes
but I'll fix that in the next patch.

R=abarth@chromium.org
BUG=435361

Review URL: https://codereview.chromium.org/746023002
2014-11-20 17:42:05 -08:00
Eric Seidel
55b5bc485d Sort headers
Fix (most) generated includes to have gen/ in their path.

This makes it easier to tell where files exist on disk.

Unfortunately I had to leave the old include path
in engine/BUILD.gn to support all the v8 includes
which were too many to deal with in this patch.

It's a little nasty to have the raw build directory
in our include path, but it produces nicer paths.

R=abarth@chromium.org
2014-11-19 12:33:42 -08:00
Adam Barth
5192329f25 Script-based imports should basically work
This CL adds the beginning of a new module loading system that matches the
conceptual module in the spec. I've writed it up to the import API on
AbstractModule. In a future CL, I'll replace the old module loading system with
this one.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/720903002
2014-11-12 13:29:14 -08:00
Adam Barth
fcaf863c07 AbstractModule should accept a PassRefPtr
The AbstractModule is taking a reference to the Document. It should take a
PassRefPtr so that it can accept a floating reference.

R=esprehn@chromium.org, eseidel@chromium.org

Review URL: https://codereview.chromium.org/715833002
2014-11-11 16:04:02 -08:00
Adam Barth
b71fee9e48 Move exports from Document to Module
This CL moves the |exports| from Document to the new |Module| interface,
matching the spec. Also, the |module| object available to scripts is now really
an instance of |Module|.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/703593003
2014-11-10 15:34:25 -08:00
Adam Barth
bdf6f5c3e6 Add Module and Application interfaces
These interfaces are currently unused by the engine, but they are
constructable.  See apis.md for details.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/697873007
2014-11-10 14:16:56 -08:00