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

Implement "eager evaluation" in the REPL #20977

Closed
benjamingr opened this issue May 26, 2018 · 24 comments
Closed

Implement "eager evaluation" in the REPL #20977

benjamingr opened this issue May 26, 2018 · 24 comments
Labels
discuss Issues opened for discussions and feedbacks. feature request Issues that request new features to be added to Node.js. repl Issues and PRs related to the REPL subsystem.

Comments

@benjamingr
Copy link
Member

benjamingr commented May 26, 2018

Hi, V8 has a basic way to detect side-effects and they use it for eager evaluation in the devtools.

It would be cool to allow for similar behaviour in our REPL. For clarity, here is the image of Chrome 68's behaviour:

image

(Image copyright (CC BY 3.0) Google Developer blog "What's New In DevTools (Chrome 68)" by Kayce Basques @kaycebasques )

@nodejs/repl

@benjamingr benjamingr added repl Issues and PRs related to the REPL subsystem. discuss Issues opened for discussions and feedbacks. feature request Issues that request new features to be added to Node.js. labels May 26, 2018
@BridgeAR
Copy link
Member

I like the idea.

@BridgeAR
Copy link
Member

The implementation might not be easy to prevent side effects though. Do you know how these are prevented in Chrome?

@benjamingr
Copy link
Member Author

@BridgeAR they use the function I linked to above in SharedFunctionInfo::SideEffectState BuiltinGetSideEffectState and time the evaluation out after 500ms

@devsnek
Copy link
Member

devsnek commented May 26, 2018

as a sidenote we would need to start properly marking our natively defined functions on whether they have side effects or not.

@benjamingr
Copy link
Member Author

@devsnek

as a sidenote we would need to start properly marking our natively defined functions on whether they have side effects or not.

IIUC only as progressive enhancement - things that weren't tagged would not eager-evaluate and the users would get the same UX they do today.

@hashseed
Copy link
Member

hashseed commented May 28, 2018

The implementation might not be easy to prevent side effects though. Do you know how these are prevented in Chrome?

V8 defines whitelists for bytecodes and builtins. During side-effect free mode, if we execute bytecode or builtins that are not whitelisted, we abort. For a greylist of bytecodes and builtins, we only allow operations on objects that have been created during side-effect free mode, to ensure that these changes do not escape.

Bindings defined through the V8 API are generally not whitelisted unless explicitly marked as such.

@hashseed
Copy link
Member

Note that side-effect free mode is only accessible through the DevTools protocol right now, through Runtime.evaluate and Debugger.evaluateOnCallFrame.

@benjamingr
Copy link
Member Author

@hashseed would it be possible to expose it in a way where Node.js can use side effect free mode?

I think this could be really cool to have in our REPL

@hashseed
Copy link
Member

You mean as option to v8::Script::Run? I'd be open to that. Then again Runtime.evaluate essentially just does that.

@benjamingr
Copy link
Member Author

Seeing @jdalton recently joined @nodjes/repl - he didn't get the ping about this before (I think?).

Regarding v8::Script::Run - sure - I'm not familiar with Runtime.evaluate or if we can even use inspector functions in the REPL (even if we run an inspector in the background).

@addaleax
Copy link
Member

@benjamingr We currently use inspector functions in the REPL when they’re available for accessing pseudo-global-scope let and const variables, so that might be the easier route to go (and doesn’t require explicit V8 support being added in the C++ API)

@hashseed
Copy link
Member

I prefer the route through inspector because it already exists and has coverage via Chrome Devtools.

TimothyGu added a commit to TimothyGu/node that referenced this issue Jun 22, 2018
TimothyGu added a commit that referenced this issue Jun 26, 2018
PR-URL: #21458
Refs: #20977
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this issue Jul 14, 2018
PR-URL: #21458
Refs: #20977
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@BridgeAR
Copy link
Member

@rubys is this something you might be interested in?

@devsnek
Copy link
Member

devsnek commented Aug 17, 2018

fwiw https://github.com/nodejs/repl has this support already.

@jdalton
Copy link
Member

jdalton commented Aug 17, 2018

@devsnek Would you please post links to the relevant commits or code.

@devsnek
Copy link
Member

devsnek commented Aug 17, 2018

@jdalton https://github.com/nodejs/repl/blob/e06c75c8788c90b056c85d743cebea087d0cc98c/src/repl.js#L125-L202

@rubys
Copy link
Member

rubys commented Aug 17, 2018

@devsnek what's the status/plans for https://github.com/nodejs/repl ? I see that my "multiline/recoverable" changes are stalled: nodejs/repl#16 . I'm interested in helping. I'm particularly interested in #19570

@devsnek
Copy link
Member

devsnek commented Aug 17, 2018

@rubys its moving, albeit slowly 😄. i haven't really done anything with it since node started aborting on Runtime.evaluate (#22157)

i'm currently rebasing some local code for vm which will enable #19570, then this weekend i'll try to get around to the repl prs but the aborting does make it difficult to properly test...

@rubys if you join the @nodejs/repl team you should get write access to nodejs/repl and be able to commit and do prs and whatnot. the more the merrier :)

@antsmartian
Copy link
Contributor

Worth noting that when we deal with large objects, actually node-repl gets stuck. See : nodejs/repl#9

@alexkozy
Copy link
Member

I believe that node in master branch should not abort any more 😄
b1e2612

@Trott
Copy link
Member

Trott commented Nov 29, 2018

@devsnek Are you still working on this? If not, should we mark it as stalled and/or help wanted?

@cactysman
Copy link
Contributor

Any updates on this? 🤔

@devsnek
Copy link
Member

devsnek commented Mar 25, 2019

usable repl is here: https://github.com/nodejs/repl

i don't really have a plan for merging it into core right now, but someone else is always welcome to take that up.

@antsmartian
Copy link
Contributor

@metaa There was a attempt and a open PR here: #22875. I will try to close this when I get free time.

BridgeAR added a commit to BridgeAR/node that referenced this issue Dec 8, 2019
This adds input previews by using the inspectors eager evaluation
functionality.
It is implemented as additional line that is not counted towards
the actual input. In case no colors are supported, it will be visible
as comment. Otherwise it's grey.
It will be triggered on any line change. It is heavily tested against
edge cases and adheres to "dumb" terminals (previews are deactived
in that case).

Fixes: nodejs#20977
targos pushed a commit that referenced this issue Dec 10, 2019
This adds input previews by using the inspectors eager evaluation
functionality.
It is implemented as additional line that is not counted towards
the actual input. In case no colors are supported, it will be visible
as comment. Otherwise it's grey.
It will be triggered on any line change. It is heavily tested against
edge cases and adheres to "dumb" terminals (previews are deactived
in that case).

PR-URL: #30811
Fixes: #20977
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
targos pushed a commit to targos/node that referenced this issue Apr 25, 2020
This adds input previews by using the inspectors eager evaluation
functionality.
It is implemented as additional line that is not counted towards
the actual input. In case no colors are supported, it will be visible
as comment. Otherwise it's grey.
It will be triggered on any line change. It is heavily tested against
edge cases and adheres to "dumb" terminals (previews are deactived
in that case).

PR-URL: nodejs#30811
Fixes: nodejs#20977
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
targos pushed a commit that referenced this issue Apr 28, 2020
This adds input previews by using the inspectors eager evaluation
functionality.
It is implemented as additional line that is not counted towards
the actual input. In case no colors are supported, it will be visible
as comment. Otherwise it's grey.
It will be triggered on any line change. It is heavily tested against
edge cases and adheres to "dumb" terminals (previews are deactived
in that case).

PR-URL: #30811
Fixes: #20977
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks. feature request Issues that request new features to be added to Node.js. repl Issues and PRs related to the REPL subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.