Node output does not match RunJs

[palgramming]

I think the attached image show what is happening Node output the console log statements properly but same code duplicates the array after it is reversed and does not print it before being reversed .... Any help and explanation would be helpful

[lukehaas]

@palgramming thanks for raising this, looks like this is a bug that was introduced recently in version 1.13
I'll aim to release a fix as soon as I can.

[palgramming]

well I am glad I was helpful and not just a idiot .... Also it seems like when the program first launches one has access to the settings menu but once you run a program the first time the settings menu will no longer open. I have verified this on a windows 10 64 bit machine with the version you mentioned 1.13.1.0

Even with Bugs thanks for your program

[lukehaas]

@palgramming thanks again, I've now released version 1.14.0 that includes a number of updates and a fix for the original issue you saw.

Regarding the settings menu, I've checked through various scenarios on Windows 10 and I've not been able to recreate that issue. Please let me know if you're still seeing it on 1.14.0.

[palgramming]

ok well the first issue is solved but the setting menu issue is still happening

1 open RunJS > file > settings and the preferences menu opens then close it
2. console.log("Hello, World") on line 1 and run it and repeat step 1 everything fine
3. put console.log("Hello, World") on line 2 and run it and repeat step 1 and the preferences menu does not open

so I closed runJS and then did this like 3 times and same thing happened once more than one code statement is executed the then got the same results. Put both console.logs on same line with semi-colons and they output correct but then settings will not open

close program and all is good again

hope this helps ... Thanks for you hard work on this

[selrond]

@lukehaas not sure if related - I'll open a new issue if not - but here's another weird case:

when in fact, React is a JavaScript framework should be visible as an output as well, as Node.js correctly outputs:

[lukehaas]

@selrond this is unrelated. If there is an error in the code, RunJS will display the error and nothing else.
I'd be happy to reconsider this behaviour if you see it as an issue.

[selrond]

@selrond this is unrelated. If there is an error in the code, RunJS will display the error and nothing else.
I'd be happy to reconsider this behaviour if you see it as an issue.

Thanks for the reply.
I think the behavior you've described as intentional, is confusing at best.

Given that JS has a compilation phase, and execution phase - current RunJs behavior is implicitly suggesting, that the error is compile-time – (nothing else is run, only error is visible) – instead of execution-time (runtime) – which ReferenceError is.

Considering that RunJs is being used for teaching a lot (@getify uses it for instance), this confusion might manifest itself even more (certainly did for me).

I think having the "standard" output behavior is essential for a tool like this.

[lukehaas]

@selrond some very good points. I will work towards this for the next release.

The reasoning for the current behaviour was for the aim of providing more helpful errors that potentially relate to features of RunJS. For example, if you try and use a NPM package that hasn't yet been installed RunJS will give you the option to install it with the error message:

I was aiming to also expand Babel related errors to provide easy ways to toggle a Babel plugin if it wasn't already enabled etc.

[getify]

I too have been bitten by this, even recently. Very common debugging process is to put a console.log statement right before a line of code you suspect is throwing an exception. Was quite confused why it did not show the console message. Then realized I had to comment out the throwing line and insert a return instead, to see my output.

I would recommend maybe a compromise here, where the console always shows messages that happened during runtime, but then a little banner at the top of the code frame could highlight (with color!) the uncaught exception, and would be expandable to show the stack trace.

In that same banner could be the prompt you suggest to be able that install a missing dependency, or toggle a feature, or whatever. That would be quite useful!

[lukehaas]

@getify great suggestion. Will aim to have some improvements in this area soon.

[lukehaas]

The latest release - 1.15.1 addresses the issues around error messages:

@selrond @getify thank you both for your input on this.