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

Catch top-level errors in embedded js engine #8

Open
nick-thompson opened this issue Jan 4, 2024 · 2 comments
Open

Catch top-level errors in embedded js engine #8

nick-thompson opened this issue Jan 4, 2024 · 2 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@nick-thompson
Copy link
Contributor

Similar to #7, this issue is in the spirit of making sure we're resilient against crashes and instead relay helpful information to the user to facilitate a nice dev experience.

In PluginProcessor, anywhere we try to evaluate user code in the jsContext we should try/catch to prevent uncaught errors or syntax errors from crashing the native binary. I'm thinking that the general gist should be: if we fall into that catch block for any relevant jsContext.evaluate, serialize a helpful error message and get it to the editor so the user can see the error logged in the frontend dev console.

The dispatching of those error messages will follow the pattern from this commit: e69797f, except that with this PR I think we can improve the logging: any time we try to log to the editor, we should put the message into a queue. Then, if the editor exists, drain the queue. If the editor does not exist, we leave the queue as-is, and on any subsequent createEditor call we should drain the queue once the editor is open. This way we prevent losing any messages if the editor happens to be closed at the time of the log.

@nick-thompson nick-thompson added good first issue Good for newcomers help wanted Extra attention is needed labels Jan 4, 2024
@cristianvogel
Copy link

actually, I have found this issue kind of critical for plugin development progress using Elementary. Essentially it rather spoils all the nice tooling for hotloading development, which ends up being only useful for tweaking UI or changing a few values in the DSP code here and there. It is a real pain to try and make any new kind of chains or processors, as any tiny mistake means re-building everything, which can take a couple of minutes on my machine.

@inf3rnus
Copy link

inf3rnus commented Dec 7, 2024

@cristianvogel You may have already done tthis, but if you disable the removal of the build directory with each compilation it's not as bad

#!/usr/bin/env zx

let rootDir = await path.resolve(__dirname, "..");
let buildDir = await path.join(rootDir, "native", "build", "scripted");

echo(`Root directory: ${rootDir}`);
echo(`Build directory: ${buildDir}`);

// Comment out this line (below  this comment) to allow for the compilation of JUCE modules to be cached
// await fs.remove(buildDir);
await fs.ensureDir(buildDir);

cd(buildDir);

let buildType = argv.dev ? "Debug" : "Release";
let devFlag = argv.dev ? "-DELEM_DEV_LOCALHOST=1" : "";

await $`cmake -A x64 -DCMAKE_BUILD_TYPE=${buildType} -DCMAKE_INSTALL_PREFIX=./out/ -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 ${devFlag} ../..`;
await $`cmake --build . --config ${buildType} -j 4`;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants