Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Scratch.js – Interactive JavaScript Scratchpad

hole.dev

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#51

Post by gitgud »

angleofrepose wrote: post #13

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

Well you can easily detect trivial examples like "while(1)" and "for(i=0;true;i++)". But otherwise how would know some is an infinite loop?

Put a bit more simply, to work out if a problem is unsolvable (infinitly looping) you need to evaluate the problem... By trying to solve it. Checkout the halting problem for more details.

https://en.m.wikipedia.org/wiki/Halting_problem

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#52

Post by teraflop »

gitgud wrote: post #51
angleofrepose wrote: post #13

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

Well you can easily detect trivial examples like "while(1)" and "for(i=0;true;i++)". But otherwise how would know some is an infinite loop ? Put a bit more simply, to work out if a problem is unsolvable (infinitly looping) you need to evaluate the problem... By trying to solve it. Checkout the halting problem for more details. https://en.m.wikipedia.org/wiki/Halting_problem

"Solving" infinite loops doesn't necessarily mean accurately predicting a priori whether a piece of code will terminate. It can just mean ensuring that if the code does try to run indefinitely, it doesn't have unfortunate effects such as blocking the UI thread without the possibility of being interrupted.

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#53

Post by angleofrepose »

gitgud wrote: post #51
angleofrepose wrote: post #13

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

Well you can easily detect trivial examples like "while(1)" and "for(i=0;true;i++)". But otherwise how would know some is an infinite loop ? Put a bit more simply, to work out if a problem is unsolvable (infinitly looping) you need to evaluate the problem... By trying to solve it. Checkout the halting problem for more details. https://en.m.wikipedia.org/wiki/Halting_problem

> ctrl-C functionality

OS implementations dont solve the halting problem. I agree with the sibling comment.

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#54

Post by angleofrepose »

rng_civ wrote: post #33
emmanueloga_ wrote: post #31

Earlier quoted context omitted.

https://www.stopify.org/

To add to this comment, Stopify is a JS-to-JS compiler that instruments sync JS code to make them interruptible at set points. The paper [0] can explain it better than I ever could. I work on an experimental Pyret [1] runtime that uses Stopify to instrument compiled Pyret code (plain old JS) so that we can run Pyret code on the main page thread without hanging it up. Main thread execution is important for quick/easy…

Do you see any other solutions in the same domain as Stopify? Another method that might provide a way to keep UI unblocked but still have user executable code?

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#56

Post by gitgud »

teraflop wrote: post #52
gitgud wrote: post #51

Earlier quoted context omitted.

Well you can easily detect trivial examples like "while(1)" and "for(i=0;true;i++)". But otherwise how would know some is an infinite loop ? Put a bit more simply, to work out if a problem is unsolvable (infinitly looping) you need to evaluate the problem... By trying to solve it. Checkout the halting problem for more details. https://en.m.wikipedia.org/wiki/Halting_problem

"Solving" infinite loops doesn't necessarily mean accurately predicting a priori whether a piece of code will terminate. It can just mean ensuring that if the code does try to run indefinitely, it doesn't have unfortunate effects such as blocking the UI thread without the possibility of being interrupted.

> It can just mean ensuring that if the code does try to run indefinitely, it doesn't have unfortunate effects such as blocking the UI thread without the possibility of being interrupted.

Well that can be achieved by executing the code in a background worker thread. Which doesn't affect the UI thread in browsers... no sure how it's managed but I think you could terminate it after a certain amount of time too

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#57

Post by rng_civ »

angleofrepose wrote: post #54
rng_civ wrote: post #33

Earlier quoted context omitted.

To add to this comment, Stopify is a JS-to-JS compiler that instruments sync JS code to make them interruptible at set points. The paper [0] can explain it better than I ever could. I work on an experimental Pyret [1] runtime that uses Stopify to instrument compiled Pyret code (plain old JS) so that we can run Pyret code on the main page thread without hanging it up. Main thread execution is important for quick/easy…

Do you see any other solutions in the same domain as Stopify? Another method that might provide a way to keep UI unblocked but still have user executable code?

If you need the user code to execute on the main thread, then unfortunately I am aware of none besides bundling your own tailored system.

Pyret used to use its own runtime system [0] but Stopify was created in part to replace it due to the maintenance burden and complexity of "vanilla" JS interoperability.

[0] https://www.pyret.org/docs/latest/s_running.html

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#58

Post by Lerc »

Suggestions:

  If the result is an Element (or perhaps Node) insert it into the document instead of for example "[object HTMLCanvasElement]"

  A potentially more difficult one would be automagically hoisting functions defined in the document when you hit ctrl-enter.
function factorial(n) { ...the usual... }

factorial(7);// [ctrl-enter] on just this line works

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#59

Post by kahole »

Lerc wrote: post #58

Suggestions: If the result is an Element (or perhaps Node) insert it into the document instead of for example "[object HTMLCanvasElement]" A potentially more difficult one would be automagically hoisting functions defined in the document when you hit ctrl-enter. function factorial(n) { ...the usual... } factorial(7);// [ctrl-enter] on just this line works

Great suggestions!
Post reply on HN