Pretty much the same fix, I just used uint16_t instead.

TextDecoder I can fix, I'll just have to pull the original implementation from version history (I'll say it again: Git is awesome).  I implemented it in miniSphere *before* I implemented in Duktape, luckily.

Pretty much the same fix, I just used uint16_t instead.

TextDecoder I can fix, I'll just have to pull the original implementation from version history (I'll say it again: Git is awesome).  I implemented it in miniSphere *before* I implemented in Duktape, luckily.

Good news

Any ideas on ExecuteGame still segfaulting? Well speciifically error message saying "one or more components failed to load" but then on clicking ok it gives a segfault.

Also I absolutely love the backtrace for the script error screen now - that's new isn't it?

I'll look into that segfault, it's possible Chakra doesn't like the runtime handle being disposed and then recreated.

As for the backtrace, it was kind of out of necessity since Chakra doesn't provide .fileName and .lineNumber for errors, so I just had it print the stack.  It's mostly nice to have, although it looks terrible at low resolution since it doesn't all fit and scrolls off the screen.

@Eggbert: No luck reproducing your crash on Ubuntu (which is Debian-based).

What about a Debian VM?

Edit: I just checked and with a basic Debian installation, just the base system, git, build-essential, liballegro5-dev, and libmng-dev, I still have the same result.

Out of curiosity I tried Radnen's speed test from his Sphere-SFML testbed.  Here's a speed comparison of for loops in miniSphere 4.8.4 (Duktape 2.1.1) vs miniSphere-CC (Chakra 1.7.1):
https://github.com/Radnen/sphere-sfml/blob/master/Engine/Engine/startup/scripts/testsuite.js

Code: [Select]

mS 5 'chakra-js'
----------------

the pig:812
manual abort

traditional for: 0.04ms
For i++ in Check: 5.4ms
For i++ in Step: 4.9ms
For i++ in Body: 5.1ms
For i += 1 in Step: 4.8ms
For i += 1 in Body: 4.8ms
For i += 2 in Step: 2.2ms
For i++ in Body and Step: 3.6ms
While i++ in Step: 5.1ms
While i++ in Body: 4.5ms


mS 4.8.4
--------

@/scripts/testsuite.js:0
manual abort

traditional for: 0ms
For i++ in Check: 185.6ms
For i++ in Step: 184.6ms
For i++ in Body: 184.2ms
For i += 1 in Step: 190.1ms
For i += 1 in Body: 188.8ms
For i += 2 in Step: 94.4ms
For i++ in Body and Step: 131.9ms
While i++ in Step: 157.6ms
While i++ in Body: 158.1ms

Pretty much everything is up and running now, now I just have to get SSj working again.  I started playing with Chakra's debugger API, it's kind of clunky but gets the job done.

I thought I'd do some speed tests too, the below are high count speed tests so CC calls on its optimising JIT.

I also tried some low count ones to avoid triggering the optimising JIT; interestingly the speed of certain operations under CC swaps when the optimising JIT kicks in (such as Math.floor getting faster than |0).

Anyway Duktape doesn't measure up well at all...

I can't easily test my mapengine code in it's current form with Chakra without TextDecoder so will largely be sticking to Duktape for now but it's nice to see the speed and other features that are coming; great work.

I'll get TextDecoder back up soon; SSj is taking priority because I rely on it pretty heavily myself; being able to debug Sphere games is awesome.

Math.floor() being faster with JIT is interesting but ultimately not too surprising.  x | 0 involves at least a float->integer conversion (expensive) and possibly a bitwise OR, although that second one can be safely optimized out since it's a no-op.  If the JIT knows that Math.floor() hasn't been replaced it can compile it to a raw machine code equivalent, like the C compiler does with things like memset, etc.

Without the JIT Math.floor() becomes slower than |0 probably because it involves an actual function call.

But yeah, those results are phenomenal.  Itll be nice to have a modern Sphere with a blazing fast JS engine, that, the native ES6 support and the v2 API will finally bring the engine into the 21st century.

Stepping it up to 100,000,000 of each operation had some odd impacts, possibly impacted by GC slowing it down or something.

But hey still fun to see.

(I also tried taking it to 1,000,000,000 of each operation but it resulted in a segfault on the first one, I guess creating a 3.8gb array of floats was too much for it which TBH doesn't surprise me)

I'm getting a (slightly) less obnoxious error message now when building the chakra-js branch in Deian

Code: [Select]

minisphere: malloc.c:2883: mremap_chunk: Assertion `((size + offset) & (GLRO (dl_pagesize) - 1)) == 0' failed.
Aborted

I'll have to set up a Debian VM at some point to test.  Then  I can run it through gdb and/or valgrind to see where the crash is.

SSj is in theory not too hard to get working again--I just have to implement Duktape's debugger protocol in miniSphere.  I already have the code to encode and decode messages for it, no sense reinventing the wheel.

Yet another Dragon Ball reference sneaks in; the new communication protocol for SSj is called the "Ki protocol".
http://dragonball.wikia.com/wiki/Ki_blast

I'm basing it on the Duktape dvalue protocol, since I already have the code written and there's nothing fundamentally wrong with it that would justify a complete rewrite of SSj's communication code.  As for miniSphere, every once in a while the engine crashes while calling into a script and I'm not sure why.  The only thing I can think of is something is getting prematurely garbage-collected because of a bug in JSAL, but I haven't found anything yet.

With all the Dragon Ball references, I'm just waiting for miniSphere to become named like Spheerus or Spheron the Eternal Coding.