JsxBlind 1.008: Important Bug Fix [OBSOLETE]
April 21, 2018 | JsxBlind | en
JsxBlind v.1.008 is now available and fixes a serious issue you may have encountered using the previous version. Thanks to my colleagues Davide Barranca and Justin Putney it has been found that JsxBlind's output could be corrupted when originating from a process that relies on a persistent engine…
Basically, the new version of JsxBlind fixes a memory leak that wasn't noticeable in a simple generation stage (based on the main
ExtendScript engine). But if you had a more subtle encapsulation process that both relies on a #targetengine
directive and produces multiples files, then unexpected results may arise.
Symptoms
Davide Barranca reported a few months ago—using JB 1.007:
“I have a pretty standard compile.jsx
#including your lib and targeting estoolkit#dbg
: it reads a JSX file on disk, app.compile()
the string to JSXBIN, and JsxBlind() it. The initial file is eventually overwritten. I wrote a trivial function to do so, accepting an array of path strings. No matter the order of the paths, the second jsxblinded file gives 'syntax error' when evaluated in Photoshop or ESTK. I thought I did something weird in the function, so I've unpacked the code: jsx -> jsxbin -> jsxblind
two times in a row, resetting all the string vars in between. No luck. Mind you, either of the two files are OK, if processed separately. Since I was in a hurry for a project, I've set up two separate compile.jsx
files, each one of them dealing with one jsx -> jsxblind
transformation at the time. It works flawlessly.”
Justin Putney concomitantly found that “some of (his) custom ScriptUI events don't seem to be firing after running JsxBlind.” In fact, Justin has JsxBlind integrated in ESTK as an export option, and he noticed that restarting the host app then re-exporting fixed some issues.
Explanation
I have good reason to think that the two symptoms described above have the same origin: all is about a static object whose keys weren't properly reset in the 1.007 release. So when you were restarting JsxBlind's scrambler, some symbols were already defined with older data! Which obviously led to crazy results.
In version 1.008 the memory is cleaned in a way that prevents symbol tables from causing such collisions.
Reminder: JsxBlind is a free script (and library) delivered to ExtendScript/CEP developers. Your feedback is crucial to keep it safe and robust. Thank you for pointing out any anomaly you may find!
• See also:
Using JsxBlind, API and detail;
Davide Barranca — Photoshop, etc.;
Justin Putney — Ajar Productions.