XojoScript context problem

I haven’t done a lot with XojoScript, so every time I try to do something with it, I end up with a lot of problems. I’ve distilled my latest problem down to 3 lines of code and a one line XojoScript:

Context = self Source = " myArray=array(0,1,2,3,4) " isCompiled = Precompile(OptimizationLevels.High)
The above code is in an Initialize method in the XojoScript subclass.
myArray is an integer array property of the XojoScript subclass. When I run the above Initialize code, compilation fails and the error code is:
Error 11, Undefined operator
And the error position is at the first character of the line of code:

myArray = array(0,1,2,3,4,5) ^ Error 11, Undefined operator.
Is this a context problem? What am I doing wrong?
If I insert the line “redim myArray(-1)” before the assignment statement, there’s no error there, and the error still occurs on the assignment statement line.

You’re going to need a method on the context to set a property… something like:

Public Sub SetArray(value() as integer) MyArray = value End Sub

Thanks. That worked great. I think I’m slowly getting the hand of XojoScripts.

I was afraid that I might have to transfer the arrays one element at a time. I think part of the reason why I get confused transferring data in and out of XojoScripts is that I can directly access simple data type properties, and I couldn’t understand why I wasn’t able to directly access an array.

So then, is it correct to say that to access any object type of data, even if it’s in the XojoScript’s context, it’s necessary to use a method in that context, but simple variable properties in the context can be accessed directly?

Well… it’s not so black and white as that. As far as transferring data to/from the context, yes only simple data types can be used, BUT you can create your own classes in XojoScript which interact with classes in the context. For instance, you could create a Date class, all in code, which syncs to a Date class in the context.

Okay thanks. That’s probably not anything that I need to worry about in the immediate future. I use XojoScript for speed improvement in math intensive calculations. So, I’m mainly concerned with transferring arrays of doubles back and forth.

Have you tried compiling your app as 64-bit with Optimization set to Moderate or Aggressive?

Yes. I’ve found that for one particular number crunching application, a 64-bit build gives a 4x speed improvement over the 32-bit (no XojoScript) build. However, a 32-bit build using XojoScript gave a 10x speed improvement over the base 32-bit build. So XojoScript running in 32-bit is still 2.5x faster than 64-bit. These are all MacOS builds, and all were set to aggressive optimization, where applicable. I haven’t gotten the same speed improvement in all of my applications, but for some of them, the use of XojoScript gives an impressive speed improvement. I’m looking forward to seeing how 64-bit XojoScript performs.

XojoScript must be using different optimisation flags compared to built applications. An embedded script shouldn’t be able to run faster than the application hosting it. Is there any way you can provide an example of this to Xojo?

Well, for one thing there are no optimization tags when building a 32 bit application, but since XojoScript uses the LLVM compiler, it can be set to aggressive. Here’s a simple example:

#pragma DisableBackgroundTasks #pragma DisableBoundsChecking #pragma StackOverflowChecking false dim z As Double = 0 for i as int64 =0 to 100000000 z=z+sqrt(i) next return z
Running this both as a standard routine and a XojoScript routine in a 32 bit built application gives these results:

Calculation Result: 6.666667e+11, Regular Code Time: 7.0870sec. Calculation Result: 6.666667e+11, XojoScript Time: 2.6943sec.
So, there is definitely a speed increase using XojoScript.

Now, when the same thing is run as a 64 bit application (XojoScript deleted), this is the result:

Calculation Result: 6.666667e+11, Regular Code Time: 0.5687sec.

So, in this case, the 64 bit version is much faster than both regular code and XojoScript in the 32 bit build. However, I’ve found that in some cases, as I mentioned above, the 32 bit XojoScript will outperform 64 bit regular code. So far, I haven’t figured out which things are much more efficient in XojoScript.