Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSRT module api #1254

Merged
merged 9 commits into from
Jul 14, 2016
Merged

JSRT module api #1254

merged 9 commits into from
Jul 14, 2016

Conversation

Yongqu
Copy link
Contributor

@Yongqu Yongqu commented Jul 8, 2016

Add module support in chakracore by adding related JSRT APIs. This set of
APIs are in chakracore.dll only, not in chakra.dll as we are using different binding
for edge browser. The host is responsible for asynchronously fetch dependent modules
and handle error conditions.

The overall loading sequences:

   host                                chakacore.dll
1. Load top level script
2.                             ---->   JsInitializeModuleRecord // for root module
3.                             ---->   JsParseModuleSource      // parse root module
4. FetchImportedModuleCallback <----                            // optional for imported module
5.                             ----->  JsInitializeModuleRecord // for nested module
6. load additional script
7.                             ----->  JsParseModuleSource      // for nested module
8. NotifyModuleReadyCallback   <-----
9.                             ----->  JsModuleEvaluation       // for root module

step 4 to step 7 could be happening in a loop, and step 5 should happen asynchronously
like in a Promise. Step 9 will also evaluate all the nested modules.

Port some existing test cases to ch. We need to support test262 hook in later checkin.

Add module support in chakracore by adding related JSRT APIs. This set of
APIs are in chakracore.dll only, not in chakra.dll as we are using different binding
for edge browser. The host is responsible for asynchronously fetch dependent modules
and handle error conditions.

The overall loading sequences:
   host                                chakacore.dll
1. Load top level script
2.                             ---->   JsInitializeModuleRecord // for root module
3.                             ---->   JsParseModuleSource      // parse root module
4. FetchImportedModuleCallback <----                            // optional for imported module
5.                             ----->  JsInitializeModuleRecord // for nested module
6. load additional script
7.                             ----->  JsParseModuleSource      // for nested module
8. NotifyModuleReadyCallback   <-----
9.                             ----->  JsModuleEvaluation       // for root module

step 4 to step 7 could be happening in a loop, and step 5 should happen asynchronously
like in a Promise. Step 9 will also evaluate all the nested modules.

Port some existing test cases to ch. We need to support test262 hook in later checkin.
@Yongqu
Copy link
Contributor Author

Yongqu commented Jul 8, 2016

@boingoing can you take a look?

JsParseModuleSource
JsModuleEvaluation
JsSetModuleHostInfo
JsGetModuleHostInfo
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should consider adding nativetests for these sets of api. nativetests should be the place for adding negative tests to validate the various inputs for these APIs which ch.exe is not supposed to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point; will leave out of this change though.

Copy link
Contributor

@dilijev dilijev Jul 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this issue to track this #1269

/// </remarks>
/// <param name="referencingModule">The referencingModule as in HostResolveImportedModule (15.2.1.17). nullptr if this is the top level module.</param>
/// <param name="normalizedSpecifier">The host normalized specifier. This is the key to a unique ModuleRecord.</param>
/// <param name="specifierLength">The length of normalizedSpecifier.</param>
Copy link
Contributor

@dilijev dilijev Jul 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no parameter named specifierLength #Resolved

Yongqu and others added 4 commits July 8, 2016 21:27
Disable module tests in linux for now while I figure out why the import entries
don't get resolved correctly in ch.
@@ -25,6 +25,9 @@

#define ENABLE_TEST_HOOKS 1
#include "CommonDefines.h"
#include <map>

#include <map>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like is included twice here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah merge resolution error. Will fix it with the Linux static build failure. #Resolved

@Yongqu
Copy link
Contributor Author

Yongqu commented Jul 14, 2016

@boingoing any additional feedback?

@dilijev
Copy link
Contributor

dilijev commented Jul 14, 2016

LGTM

@chakrabot chakrabot merged commit baca8a4 into chakra-core:master Jul 14, 2016
chakrabot pushed a commit that referenced this pull request Jul 14, 2016
Merge pull request #1254 from Yongqu:bugfix

Add module support in chakracore by adding related JSRT APIs. This set of
APIs are in chakracore.dll only, not in chakra.dll as we are using different binding
for edge browser. The host is responsible for asynchronously fetch dependent modules
and handle error conditions.

The overall loading sequences:

```
   host                                chakacore.dll
1. Load top level script
2.                             ---->   JsInitializeModuleRecord // for root module
3.                             ---->   JsParseModuleSource      // parse root module
4. FetchImportedModuleCallback <----                            // optional for imported module
5.                             ----->  JsInitializeModuleRecord // for nested module
6. load additional script
7.                             ----->  JsParseModuleSource      // for nested module
8. NotifyModuleReadyCallback   <-----
9.                             ----->  JsModuleEvaluation       // for root module
```

step 4 to step 7 could be happening in a loop, and step 5 should happen asynchronously
like in a Promise. Step 9 will also evaluate all the nested modules.

Port some existing test cases to ch. We need to support test262 hook in later checkin.
@JohnMasen
Copy link

hi,
I'm working on a library which porting the chakracore to dotnetcore (Chakracore.NET on Github). I have trouble porting the module support part.
here's the question:
what does "1. Load top level script " mean? I'm using JsRunScript to execute the script. does the "Load" means "serialize the script"? I can barely read the C++ source code as I have no C++ experience. loading module is the last piece of my library, can any one help?

@obastemur
Copy link
Collaborator

@JohnMasen I’m afraid the message you have sent here is going to be lost. Can you please open an issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants