Normally in Javascript, if you reference the "magic" arguments variable from inside a function, it will contain all of the arguments passed to the function. In the Chrome developer tools (on Linux) though, that doesn't happen; if you:
Add a debugger statement to some function that doesn't have any declared arguments
Do something to trigger that function with an argument
When Chrome pauses on the debugger line, check arguments from the console.
You'll see that arguments is empty. Now, this can be fixed easily enough by just declaring arguments on the function; in other words, if you do:
function(a,b,c) {
debugger;
}
instead of:
function() {
debugger;
}
arguments will have the arguments (or at least the first three).
However, that really shouldn't be necessary, which leads me to my question: is there any setting I can change, or is there anything else I can do to fix this behavior and just make Chrome put EVERY passed-in argument in to arguments, not just the declared ones?
This recently has been redone in V8 JavaScript engine. Soon it will make its way into Chrome codebase, which eventually will get into stable release (possibly 28...* ?).
Related
When working on a SolidJS project you might start seeing the following warning message in your JS console:
computations created outside a `createRoot` or `render` will never be disposed
There are some information available on this in SolidJS' Github repository issues. But after reading them I was still not quite sure what this was all about and whether my code was really doing something wrong.
I managed to track down where it came from and find a fix for it based on the documentation. So I'm providing the explanation and the solution for those Googling this warning message.
In essence this is a warning about a possibility of a memory leak due to a reactive computation being created without the proper context which would dispose of it when no longer needed.
A proper context is created a couple of different ways. Here are the ones I know about:
By using the render function.
By using the createRoot function. Under the hood render uses this.
By using the createContext function.
The first is by far the most common way, because each app has at least one render function call to get the whole show started.
So what makes the code go "out of context"?
Probably the most common way is via async calls. The context creation with its dependency tree happens only when the synchronous portion of the code finishes running. This includes all the export default function in your modules and the main app function.
But code that runs at a later time because of a setTimeout or by being in an async function will be outside of this context and any reactive computations created will not be tracked and might stick around without being garbage collected.
An example
Let's say you have a data input screen and have a Save button on it that makes an API call to your server to save the data. And you want to provide a feedback to the user whether the operation succeeded or not, with a nice HTML formatted message.
[msg,setMsg] = createSignal(<></>)
async function saveForm(){
...
setMsg(<p>Saving your data.<i>Please stand by...</i></p>)
const result=await callApi('updateUser',formData)
if(result.ok){
setMsg(<p>Your changes were <b>successfully</b> saved!</p> )
} else {
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{result.error}</pre> )
}
}
...
<div>
...
<button onClick={saveForm} >Save</button>
{msg()}
</div>
This will produce the above mentioned warning when the API call returns an error, but not the other times. Why?
The reason for this is that SolidJS considers the code inserts inside JSX to be reactive, ie: need to be watched and re-evaluated. So inserting the error message from the API call creates a reactive computation.
The solution
I found the solution at the very end of the SolidJS doc. It's a special JSX modifier: /*#once*/
It can be used at the beginning of a curly brace expression and it tells the SolidJS compiler to explicitly not to make this a reactive expression. In other words: it will evaluated once and only once when the DOM nodes are created from the JSX.
In the above example here's how to use it:
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{/*#once*/ result.error}</pre> )
After this there will be no more warning messages :)
In my case, I had an input and when that input changed I re-created an SVG drawing. Because the SVG creation was an expensive operation, I added a debounce in the createEffect function which ran when the input changed. debounce is a technique to defer the processing until the input stops changing for at least X amount of time. It involved running the SVG generation code inside the setTimeout function, thus being outside of the main context. Using the /*#once*/ modifier everywhere where I inserted an expression in the generated JSX has fixed the problem.
Warning: as the reference types proposal isn't complete yet, this code will not run without toggling flags or setting in order to enable executing experimental code.
If you are on Google Chrome or a Chromium browser, you will need to enable the following flag:
chrome://flags/#enable-experimental-webassembly-features
I had set up a simple handwritten Wasm module for personal use. I could've easily written it in JavaScript, but it was easier and made more sense to use Wasm, and since it was a simple, personal script, I wouldn't care if other people couldn't run it.
I had compiled it using wabt's wat2wasm.
The Wasm module was intended to be fed the entire globalThis object to import from.
From there, it took four TypedArray constructors: Uint8Array, Uint16Array, Uint32Array, and BigUint64Array.
Take note: no code was executed prior to the Wasm, thus there cannot be any interference.
Later, I had realized that that the Wasm wasn't working as intended at all, my math was correct, but the variables were wrong.
I had narrowed my problem down to just this:
;; global -> global variable
(import "globalThis" "Uint8Array" (global $Uint8Array externref))
(import "globalThis" "Uint16Array" (global $Uint16Array externref))
(import "globalThis" "Uint32Array" (global $Uint32Array externref))
(import "globalThis" "BigUint64Array" (global $BigUint64Array externref))
;; func -> function
(import "console" "log" (func $console::log (param externref)))
(start $_start)
(func $_start
global.get $Uint8Array
call $console::log
global.get $Uint16Array
call $console::log
global.get $Uint32Array
call $console::log
global.get $BigUint64Array
call $console::log
)
This Wasm was instantiated like so:
WebAssembly.instantiateStreaming(
fetch(
"test.wasm", {
mode : "same-origin",
credentials : "omit",
cache : "no-store",
redirect : "error",
referrer : "no-referrer"
}
), globalThis
).catch( console.error );
The interesting problem is that the logs all say the same thing: Uint8Array.
I was dumbfounded. This has to be literally impossible. The JavaScript file itself was not cached, the WebAssembly was being fetched with "no-cache," the web page itself wasn't cached.
Then I thought, because I was using XHTML, maybe it didn't happen in HTML files. It did there too.
I tried converting the Wasm file to a TypedArray and just using WebAssembly.instantiate, suddenly, it worked flawlessly.
At this point the server must be serving the wrong file, because the further I go, the more this seems like nonsense.
I almost want to say that this is a Chromium browser or V8 runtime error, but I need to narrow it down a bit more before I blindly attempt to present this as a bug.
I have set up two different versions of the same code, on Repl.it, and on CodeSandBox.io, so that hopefully someone can try running it themself, to confirm the bug, and maybe attempt to debug where I went wrong.
(Could this be a problem with Repl.it's server?)
This was a compiler bug fixed by Chromium in
https://chromium-review.googlesource.com/c/v8/v8/+/2551100.
This was the response that I had gotten from one of the developers:
This is indeed a timing issue that has been fixed in https://chromium-review.googlesource.com/c/v8/v8/+/2551100. The problem happens when there are only imported globals, and compilation of the WebAssembly functions finishes before the stream actually finishes. In this case, the offset calculation happens after the compiler uses the offsets, and therefore produces incorrect code.
A workaround is to define one global that is not imported, as this causes the offset calculation to happen earlier.
Seems like sending a small module that only imports globals instead of functions was breaking the code.
Their code had a threading race condition between the stream and the compiler.
I use the code
clc;
clear;
getd();
a=1;
b=myFunction();
, where myFunction is defined by
function b=myFunction()
b=a+1;
endfunction
. For some strange reason, this works just fine in Scilab. I believe myFunction simply inherits a from the main function. This is in contrast with for instance Matlab, where a needs to be an input argument of myFunction in order to use it.
I want functions in Scilab to only work with local variables and variables given as input, like in Matlab. So that in this case a is not inherited from the main function.
How can I achieve this?
This works fine in Scilab because in case a function uses an undefined variable the interpreter search it in the calling scope. Although it seems strange, this is how it works and I think this behavior cannot be changed without modifying the source code as #NormalHuman said.
In your example your code is working because you have the "a" variable is defined in the calling scope, but if you execute the function in another situation it could fail. In my opinion a function defined in this way has a defect in its code.
I am using a lot Scilab and I don't see this as a real problem, but I agree with you that this behavior is quite strange and it should not exist.
However, if you are worried of developing incorrectly a function that works well while you are writing the code due to a variable defined in calling scope, the solution for that is to create some unit tests and execute them in a clean interpreter.
You can avoid this by choosing distinct names for variables you wish to be local.
Like putting a myFunction_ in front of all the local variable names. In your example, you would rename a into myFunction_a.
Unfortunately, I don't know if it would be possible to write a script that would do the work for you in case you have large matlab scripts.
On javascript Object i am invoking
obj.requestFileSystem(LOCAL,5*1024*1024) . This method is implemented in PlainNAPI Plugin , now i have to pass one success callback to this function as follows......
obj.requestFileSystem(LOCAL,5*1024*1024,initFS); // initFS is a function in javascript that is an argument to the success callback .
In NPAPI it is an object when the requestFileSystem is completed then initFS function in javascript should be called. How to return from NPAPI plugin to javascript and to execute initFS function.
function initFS(fs) {
alert('Inside the initFS');
alert(fs.root.getFullPath);
}
Please don't tell me what you're actually doing with this plugin, since it sounds like it's something akin to giving people access to things from a web browser that could easily be abused by someone else.
Basically a function is just an NPObject when it gets to your function inside NPRuntime; to call the function you just do a NPN_InvokeDefault on that NPObject.
Note that you must be on the main thread in order to call nearly all NPN_ functions.
EDIT: So if you have to do the callback from a different thread then your easiest solution is to use NPN_PluginThreadAsyncCall; basically you create an object to hold the data you need and call PluginThreadAsyncCall with that pointer as the void* parameter and it will get passed to the function you specify.
Make sure that A) the pointer will still be valid, and B) your function is able to free that memory after it runs. From the callback function you can call NPN_InvokeDefault safely.
Not that NPN_PluginThreadAsyncCall doesn't seem to work on Safari 5.1 anymore. If you need that support or if what I've explained doesn't make sense you might want to consider using FireBreath to build your plugin; it does all of this for you.
In a plug-in I am using NPN_Evaluate() to execute some Javascript. How can I detect wether the Javascript raises an exception? Basically I want to execute any piece of Javascript and get the result from it or detect if it raised an exception.
I tried wrapping my Javascript code like this:
try {
// Injected Javascript code here
}
catch (exc) {
exc;
}
That way the result from NPN_Evaluate() will be an NPObject* containing a property "message" with the exception message if something goes wrong. But how can I know that it is an exception? It might as well be a result from the injected Javascript code.
Am I approaching this the wrong way? Can I detect an exception without catching it in Javascript and returning the exception as the result?
Personally I've never been a fan of using NPN_Evaluate; If I needed to do something that couldn't be done using other methods (NPN_Invoke, NPN_GetProperty, etc) I'd use NPN_Evaluate to inject a javascript function into the DOM and then call it using NPN_Invoke; then if it returns false you know it failed. There isn't any really good exception handling across that bridge, unfortunately, but the return value of true or false will tell you if it succeeded -- I suspect this holds true even for just using NPN_Evaluate.
Remember that anything declared global in javascript is a property of the window; thus, if you inject "function foo(bar) { alert(bar); }" with NPN_Evaluate you can use NPN_GetValue to get the Window NPObject and then call GetProperty("foo") to get the foo function. You can then call InvokeDefault on that bar method to call it, passing in whatever value you want for bar as a parameter.