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

feat(xsnap): Add Node.js shell #2169

Closed
wants to merge 5 commits into from
Closed

feat(xsnap): Add Node.js shell #2169

wants to merge 5 commits into from

Conversation

kriskowal
Copy link
Member

This change adds a Node.js wrapper for controlling an xsnap subprocess. The package’s postinstall hook builds the debug and release binaries and is platform-agnostic (that is, it might even work on Windows), rather than locating a system level dependency.

For purposes of demonstrating the controller, there is an example REPL called src/xsrepl.js that is capable of taking and resuming from snapshots.

Prompted by @warner to do better than having an in-XS onMessage hook, I made the API for sending and receiving syscalls symmetric. The XS code may call sysCall or be called with answerSysCall. The Node.js side may have an answerSysCall implementation and dispatches to XS with an async sysCall method. Both accept binary data and may return binary data.

kriskowal and others added 5 commits January 7, 2021 21:57
Co-authored-by: Dan Connolly <dckc@madmode.com>
Co-authored-by: Michael Kellner <mkellner@moddable.tech>
Co-authored-by: Moddable Open Source <32498429+Moddable-OpenSource@users.noreply
* @param {'ignore' | 'inherit'} [options.stdout]
* @param {'ignore' | 'inherit'} [options.stderr]
*/
export function xsnap(options) {
Copy link
Member

Choose a reason for hiding this comment

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

Let's please have the caller supply spawn, following ocap discipline.

See also #2160 (comment) .

Copy link
Member

Choose a reason for hiding this comment

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

looks like getOsType is ambient too.

Perhaps not a hill I'd die on, but perhaps make platform an optional arg and add a "// Note well: AMBIENT AUTHORITY is used for convenience" comment about computing the default.

I also much prefer that module level const is only used for things that are design-time const, not things that can change at runtime. So I would prefer that getOsType were only called if the caller doesn't supply platform.

@kriskowal
Copy link
Member Author

Smashing this into #2168

@kriskowal kriskowal closed this Jan 8, 2021
@dckc dckc mentioned this pull request Jan 8, 2021
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.

2 participants