scripts interferences

[robyx]

Hi all,

I have one request for an update on how the Javascript runtime that executes the scripts is managed in PixInsight. Actually, as I figured out, the JS engine is instantiated once and shared across the scripts for the whole PixInsight session. This means that if I run a script that adds a prototype function to an array

Array.prototype.mySort = function() {...}

this function will be created once and then it will be available to every following script that I can run during the same session. Unfortunately, since re-assigning this variable again raises an error, the good practice is to properly do a pre-check like

// assign the function only if it has not already existing
if (!Array.prototype.mySort)
    Array.prototype.mySort = function() {...}

This has a HUGE drawback:  some scripts may the same function but with a slightly (or totally?) different implementation, this means that there is an inter-dependency between the scripts such that running a script could make a following script to fail.

My request is to reset the JS engine at each script launch or, if this has drawbacks, find a solution to restore a common clean starting state of the JS Engine at script launch-time to remove this kind of state-dependent interdependencies between scripts.

Regards,
Robyx

[Andres.Pozo]

My request is to reset the JS engine at each script launch or, if this has drawbacks, find a solution to restore a common clean starting state of the JS Engine at script launch-time to remove this kind of state-dependent interdependencies between scripts.

Resetting the JS engine would invalidate the cache in the catalogs used by ImageSolver, AnnotateImage and some other scripts.

Just don't add methods to the builtin classes. IMHO this is asking for trouble...

[mschuster]

To avoid conflicts I suppose you could append a random number, eg mySort71169912919651627503.

A different situation occurs when you want a script to run on an older version of PI that lacks a particular function, eg like the one below. Maybe the solution is not to do this, just don't support older versions.

Code: [Select]

if (!Control.prototype.scaledResource) {
   Control.prototype.scaledResource = function(r) {
      return r;
   };
}


[Juan Conejero]

I agree completely with Mike's proposal: don't support old versions, e.g. versions < 1.8.7. This should allow us to remove all replacements of standard runtime properties and functions, which would avoid potential conflicts.

In the current architecture of PixInsight, the JavaScript runtime must be unique and common to all running scripts. For example, this is essential to implement the bridge between the C++ and JavaScript development frameworks, which is now being used by several tools, and will be used by more tools in the future.

[robyx]

I see, then I guess I'll refactor the code of WBPP to clean up the extensions of the built-in classes and move every extension in an Utilities class eventually instantiated at runtime.

Thanks a lot
Robyx

[Juan Conejero]

Yes, this is the best option IMO. Most of the routines in WeightedBatchPreprocessing-helper.js should be transformed into independent routines, or even better, methods of a new object. For example, instead of:

if ( !String.prototype.cleanFilterName )
   String.prototype.cleanFilterName = function()
   {
      return this.replace( /[^a-zA-Z0-9\+\-_]/g, '_' ).replace( /_+/g, '_' );
   };


we could have a static method:

function WBPPUtils()
{
   ...
}

WBPPUtils.prototype = new Object;

WBPPUtils.cleanFilterName = function( filterName )
{
   return filterName.replace( /[^a-zA-Z0-9\+\-_]/g, '_' ).replace( /_+/g, '_' );
};


Less convenient to use, and requires a lot of refactoring, but much safer and more productive in the long term.

[Andres.Pozo]

Juan, do you have any plans for the support of Javascript ES6?

[mschuster]

Juan, do you have any plans for the support of Javascript ES6?

Does this support inlining (eg Matrix.at() to improve performance)?

Does this allow proper GC of objects with large backing allocation (eg Matrix)?

[Juan Conejero]

Hi Andrés,

Juan, do you have any plans for the support of Javascript ES6?

Absolutely yes. My intention is to migrate the entire JavaScript runtime to the V8 engine. Unfortunately, Mozilla is constantly changing SpiderMonkey's public API in radical ways with each new release. Updating the engine to a new version of SM means rewriting basically the entire PJSR component of the PixInsight core application (about 200,000 lines of source code). They basically have little interest in making their engine usable outside Firefox. This does not happen with V8, which will allow us to have a stable JS engine that I can update as frequently as needed.

The only problem with this is... a LOT of work. Basically, the entire PJSR has to be redesigned and reimplemented to work with V8. Unfortunately, this is something that I cannot afford at present, since we have very important priorities and there are new tools that must be working as soon as possible. As soon as I have a 'window' of time to invest in this, count with it.

[Juan Conejero]

Juan, do you have any plans for the support of Javascript ES6?

Does this support inlining (eg Matrix.at() to improve performance)?

Does this allow proper GC of objects with large backing allocation (eg Matrix)?

V8 provides smarter ways to inform the engine about the amount of memory actually consumed by objects with native data, so we can expect an improvement here. The extent of this improvement is something that I can't predict now, but it should be significant.

As for Matrix and Vector performance, the only solution is to write pure JavaScript implementations of these objects. This is something I want to implement as soon as possible. The current bottleneck of these objects is in their need to call native routines for elementary tasks such as reading/writing matrix and vector elements. On one hand, native calls stop JIT optimizations. On the other hand, the time required to store and retrieve function call parameters to/from the stack is orders of magnitude longer than the time required to write/read a matrix element. With pure JS implementations, these objects will be as fast as Array for example.