QUESTION TO CHATGTP
I am running code, as generated by emscripten, under Photoshop.
The emscripten generates a ’name’.js file. Within that file is the following code (console output statements added by myself). …
*** START CODE SEGMENT
// / should be present at the end if scriptDirectory is not empty
var scriptDirectory = ‘’;
function locateFile(path) {
console.log(path);
if (Module[‘locateFile’]) {
console.log(path);
console.log(scriptDirectory);
return Module[‘locateFile’](path, scriptDirectory);
}
console.log(scriptDirectory + path);
return scriptDirectory + path;
}
*** END CODE SEGMENT
Now if I run code from a very small simple C++ program (TestPlugin.cpp) I get the following output from the Adobe UXP Developer Tools debugger.
VM15 TestPlugin.js:83 TestPlugin.wasm
VM15 TestPlugin.js:89 TestPlugin.wasm
TestPlugin.js:83 TestPlugin.wasm
TestPlugin.js:89: TestPlugin.wasm
and the code runs successfully.
If I run the code for a bigger more complex C++ program (ARcore.cpp) I get the following output from the Adobe UXP Developer Tools debugger.
ARcore.js:83 ARcore.wasm
ARcore.js:89 ARcore.wasm
ARcore.js:83 ARcore.wasm
ARcore.js:89 ARcore.wasm
ARcore.js:529 still waiting on run dependencies:
ARcore.js:531 dependency: wasm-instantiate
ARcore.js:534 (end of list)
ARcore.js:529 still waiting on run dependencies:
ARcore.js:531 dependency: wasm-instantiate
ARcore.js:534 (end of list)
Here the wasm fails to initiate, where in the first example it did.
It seems to me that the main difference here is that in the first instance VM15 is invoked but not in the second instance. How can I overcome this?
RESPONSE FROM CHATGTP:
The behavior you’re seeing could be due to differences in how the UXP environment is handling the module loading, specifically the WebAssembly instantiation. Here are some areas to investigate and potential steps to debug this issue:
- Review the LocateFile Function’s Return
Confirm that locateFile() is returning the correct path to the .wasm file. Since scriptDirectory is empty, it’s possible that locateFile() might not be resolving correctly for ARcore.js.
Try hardcoding the path to the .wasm file in locateFile() temporarily to verify if the loading issue is related to an incorrect path.
- Check the Module Loading Order
Adobe’s UXP environment can sometimes run JavaScript in different execution contexts (like VM15 in your simpler example). It’s possible that ARcore.js is loaded differently, impacting the module instantiation order.
Confirm if Module[‘locateFile’] is set and resolving correctly in both cases by checking if Module properties differ between TestPlugin.js and ARcore.js.
- Enable Synchronous Compilation
Sometimes, asynchronous WebAssembly compilation in larger files can cause issues. Try forcing synchronous compilation with WebAssembly.instantiate() or by setting Module.instantiateWasm to handle instantiation synchronously.
Check the UXP Developer Tools console for any clues related to async handling that may indicate wasm-instantiate is pending longer than expected.
- Experiment with VM Context
To mimic the behavior of VM15 with the more complex ARcore.js, try wrapping your code in an immediately-invoked function expression (IIFE) to see if that affects how it’s run in UXP’s execution context. This can sometimes help if the environment requires isolation.
OBSERVATION:
I am not entirely sure at present that I understand the response but maybe it will become clearer if I work on it.