See ViaTests/ArrayIndex.via test 11.5 (commented out before fix)

We have to fix the test or make it a manual one. The following was output in a recent CI failure run.

UInt8  counter size: 'false'.
    Ticks different: 'false'.

Much is already consolidated, but some parsing routines differ only in the Nesting Tokens (){}[]<>

Right now the slack channel dedicated to CI updates is showing everything but the results of the CI :-/

While submitting a set of commits for the http palette I started receiving the following error while the test suite ran:

RangeError: Maximum call stack size exceeded
    at tt (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:79054)
    at st (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:74524)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85190)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
    at Ft (/home/travis/build/rajsite/VireoSDK/dist/vireo.js:7:85838)
make: *** [testjs] Error 7

See build results or attached 1.firstoccurence.txt

The error occurred during execution of the Vireo VTR-based test suite using the node.js runner. The strange thing is that none of the commits had code that should be exercise by the VTR-based test suite. Only the karma test suite runs HTTP based tests.

As an aside it is also strange that the test resulted in a false positive and did not fail. As Travis reports The command "make testjs" exited with 0.

Enabling test names allows one to see that the change is resulting in failures for JS tests that are undergoing their second run. See build result or attached 2.withtestnames.txt

Disabling the test that appears to fail does not seem to prevent the failure but instead delay how long until the Maximum call stack exceeded error occurs.

I was able to bisect the changes down to applying changes to HTTPClient.cpp on top of incoming at the time but I was not able to identify a specific subportion of the file resulting in the failure.

It was observed that changing the optimization level to -O2 prevented the same failure (as well as -g4 and -O1). However, PhantomJS starts to get errors at this time. See build result or attached 3.withopt2flag.txt.

The PhantomJS failures seem to be independent of this set of changes as changing the flag to -g4 on incoming at the time also shows failures. See build result or attached 4.incomingwithg4.txt

However after some changes were submitted to incoming, no test failures continued to occur when trying to integrate my changes. We have seen this behavior once before and the same thing (some new commits going in) also prevented the failures from continuing to occur.

The following discussion on the emscripten mailing list make me believe the problem is possibly related to optimization passes resulting in functions with lots of local variables which is causing available stack space to be consumed too quickly: https://groups.google.com/forum/#!topic/emscripten-discuss/qHnUyzF1eAY

Unfortunately we have not retrieved the files that are generated on Travis or have been able to reproduce the behavior locally to try and reproduce the behavior.

As additional changes went in and the code is no longer in a state that causes failures I'm closing this issue.

See ViaTests/InplaceArrayInsertSubset.via test 9.5 (commented out before fix)

The ReadNameToken and JSON parsing code both deal with
key-value pairs. Looks like this can be a bit more consolidated.

Looks like some less noisy reporters exist, worth a shot: https://github.com/jaapz/karma-failed-reporter

http://stackoverflow.com/questions/18121197/karma-runner-console-output-only-failed-tests

Tried dots at one point 01ae063

but didn't seem to help. maybe because of concurrency? Can try one browser at a time instead and dots might behave better...

Provide a means to access value type properties statically:

Println(myVi.Locals.x.$IsFlat)
true

Right now we have 2 formats for organizing tests represented in the repository

1. Tests organized by folder
   test-it/
   test-it/Blacklist
   test-it/x
   test-it/ManualTests

2. Tests organized by test-it/testList.json configuration

Currently browser tests are configured by having karma serve test-it/*.via and jasmine disables specific tests in testSuite.js. This follows the conventions of karma and jasmine but it could be reconfigured to do either method proposed above.

Any preference for folder-based vs list-based configuration?

Example target is the Dominoe Pi based on OpenWRT

Some 32bit math needed to be 64bit math, can cause target time to become negative. Fix in incoming branch, validation underway.

While adding the Call Chain to errors returned on HTTP calls, we identified that the code would be cleaner if we have a generic mechanism to save state for asynchronous calls. Is this case we were interested in knowing if the JavaScript side generated an error regardless if there was already an error on the wire.

Three possible approaches to solve this:

1. Currently the HTTP definitions used an occurrence that doesn't need to be provided by users of the call, we can follow the same approach to add additional data.

2. Ocurrence has an extra subtype, that can be used to save generic information. Maybe having an occurrence definition based on a template.

3. Have an ocurrency hierarchy where you can inherit for the base class and then add additional information to your child and use that one instead.

Should work much like the the one in node.

Add Enqueue Dequeue with times out and queue size.

Current CI Status

Linting / Static Analysis:

• JS with eslint
• CPP with CppLint
• CPP with clang-tidy
• CPP with Valgrind - Should now available in trusty containers: travis-ci/apt-package-safelist#3640
• Markdown spellcheck

Builds:

• Linux Desktop
• Windows Desktop
• Emscripten asm.js
• Emscripten wasm

Test Environment:

• Linux Desktop with test-it/test.js
• Windows Desktop with test-it/test.js
• Emscripten Desktop Node with test-it/test.js
• Emscripten Browser PhantomJS with karma
• Emscripten Browser Firefox with karma
• Emscripten Browser Chromium / Chrome with karma
• Emscripten Browser IE with karma
• Emscripten Browser Edge with karma
  Current infrastructure blocked on AppVeyor only supporting Windows Server and Windows Server not including Edge
  Can possible use sauce labs or browser stack instead
• Emscripten Browser iOS Safari

Documentation:

• Doxygen: We currently rely on 1.8+ features (markdown support). Precise has 1.7.6.1. Trusty has 1.8.6. Other alternative is switch to sudo builds. travis-ci/apt-source-safelist#40. Might be worth testing Trusty: travis-ci/travis-ci#5355 (comment)
• Vireo Playground

Coverage
Coveralls does not provide support for merging multiple reports but CodeCov does.

• Linux Desktop
• Windows Desktop
• Emscripten Desktop Node
• Emscripten Browser PhantomJS
• Emscripten Browser Firefox
• Emscripten Browser Chromium / Chrome
• Emscripten Browser IE
• Emscripten Browser Edge
• Emscripten Browser iOS

See TODO in NumericString.cpp.

Type errors in code generated from generic methods don't refer the correct line number in the VIA source. ( they list 0)

Copy(x y) // where x doesn't match y's type.

The usage type kUsageTypeStatic, the "s" type of param block element never was finished. It would help address allocation of occurrence objects for asynchronous functions that need to suspend an instruction so exec can return to the caller.

The tweaked version of CppLint is already in the repo, use that one.

Host context should be able to limit amount of memory allocated during execution of VIA file.

Currently TravisCI runs the same before_deploy step before every deploy.

We should either move before_deploy to scripts, add flags around before_deploy, or verify / make before_deploy idempotent

Associated Travis issue: travis-ci/travis-ci#2570 (comment)

• Static allocated string in EggShell_DataReadString and EggShell_DataWriteString is likely causing aborts() when Vireo is rebooted or re-run using a new user shell. #275 and possibly #163

• readJSON and Flatten / Unflatten from JSON should always return valid, safe UTF-8 strings. #366

• readJSON API should encode 64-bit integers as strings to improve interoperability. #364

• C-based runner to test ReadValueString and WriteValueString #254

• EggShell_WriteValueString tests for 2D arrays that cause the Array to grow do not behave correctly. #365

• Test more around +0 vs -0 behaviors. #367

run loadVia(with_some_invalid_script)
it returns a non-zero status

Call executeSlices anyway

Things will happen. Unexpected console output as the via tries to run anyway, etc.

From the js api point of view it would be preferable if it failed. The entry point we are using is for REPL like behavior so this may be expected, have not thought it through.

Maybe executeSlices should fail if the last call to loadVia was a failure?

At the moment we are using a new Vireo instance for every test in a karma spec.

Ideally we could use the same vireo instance and just perform a reboot and loadVia between tests.

When the http tests are modified to use a single instance like in the following example branch: rajsite@6cc892c#diff-3f40dfffc8c2df601f713d108805601f

We get the output error from the commit, reproduced as follows (using debug level -g4)
out.txt

With the following stack trace

Firefox 49.0.0 (Windows 7 0.0.0) ERROR
  uncaught exception: abort(5) at jsStackTrace@dist/vireo.js:1148:13
  stackTrace@dist/vireo.js:1165:22
  abort@dist/vireo.js:127869:44
  nullFunc_ii@dist/vireo.js:6181:464
  b5@dist/vireo.js:126969:13
  __ZN5Vireo14TypedArrayCore16ResizeDimensionsEiPib [Vireo::TypedArrayCore::ResizeDimensions(int, int*, bool)]@dist/vireo.js:94684:9
  __ZN5Vireo14TypedArrayCore8Resize1DEi [Vireo::TypedArrayCore::Resize1D(int)]@dist/vireo.js:6570:8
  _EggShell_ReadValueString@dist/vireo.js:17078:4
  applyVireoEmscriptenModule/asm._EggShell_ReadValueString@dist/vireo.js:127542:8
  ccallFunc@dist/vireo.js:458:15
  cwrap/<@dist/vireo.js:482:14
  assignEggShell/publicAPI.eggShell.readJSON@source/io/module_eggShell.js:114:20
  assignEggShell/</publicAPI.eggShell[methodName]@source/io/module_eggShell.js:178:27
  createVIPathParser/<@test-it/karma/utilities/testHelpers.vireoRunner.js:83:31
  @test-it/karma/http/httpget.js:141:20
  runExecuteSlicesAsync@test-it/karma/utilities/testHelpers.vireoRunner.js:73:21

Talking to @sanmut it seems like a possible culprit is the static variable in CEntryPoint.cpp in the EggShell_ReadValueString function: https://github.com/rajsite/VireoSDK/blob/6cc892c615f1d88ea02fb69d5074b46ae2f793a0/source/core/CEntryPoints.cpp#L176

But we have not investigated it too much further.

While creating a new Vireo instance between tests is not a big deal while the HTTP test suite is small, as it grows it will become a more noticeable test performance hit

When running the MandelbrotInline.via test on windows (at least in vireo.js) the test fails. The test has the following outputs:

Expected:

"................................................................................\n................................................................................\n................................................................................\n...........................................................##...................\n.........................................................######.................\n.......................................................########.................\n.........................................................######.................\n......................................................########.##...#...........\n..............................................###...#################...........\n..............................................########################..###.....\n..............................................############################......\n...........................................##############################.......\n............................................##############################......\n.........................................####################################...\n................................#.........##################################....\n...........................##.#####.#.....##################################....\n...........................###########...####################################...\n.........................##############.####################################....\n.........................###################################################....\n.....................#####################################################......\n.#######################################################################........\n.....................#####################################################......\n.........................###################################################....\n.........................##############.####################################....\n...........................###########...####################################...\n...........................##.#####.#.....##################################....\n................................#.........##################################....\n.........................................####################################...\n............................................##############################......\n...........................................##############################.......\n..............................................############################......\n..............................................########################..###.....\n..............................................###...#################...........\n......................................................########.##...#...........\n.........................................................######.................\n.......................................................########.................\n.........................................................######.................\n...........................................................##...................\n................................................................................\n................................................................................\n"

Actual:

"................................................................................\r................................................................................\r................................................................................\r...........................................................##...................\r.........................................................######.................\r.......................................................########.................\r.........................................................######.................\r......................................................########.##...#...........\r..............................................###...#################...........\r..............................................########################..###.....\r..............................................############################......\r...........................................##############################.......\r............................................##############################......\r.........................................####################################...\r................................#.........##################################....\r...........................##.#####.#.....##################################....\r...........................###########...####################################...\r.........................##############.####################################....\r.........................###################################################....\r.....................#####################################################......\r.#######################################################################........\r.....................#####################################################......\r.........................###################################################....\r.........................##############.####################################....\r...........................###########...####################################...\r...........................##.#####.#.....##################################....\r................................#.........##################################....\r.........................................####################################...\r............................................##############################......\r...........................................##############################.......\r..............................................############################......\r..............................................########################..###.....\r..............................................###...#################...........\r......................................................########.##...#...........\r.........................................................######.................\r.......................................................########.................\r.........................................................######.................\r...........................................................##...................\r................................................................................\r................................................................................\r"

I believe the culprit is that MandelbrotInline.via is using a literal string that has a line ending.

It does not look like VireoSDK has a .gitattributes configured so file line endings for files on windows end up being \r\n while on mac/linux they appear as \n. It looks like on windows this multicharacter string \r\n is assigned to a Utf8Char and truncated to just \r.

Fixing the test can be done by either changing the template literal to just the string "\n" or adding a .gitattributes file and normalizing line endings one way or another.

However this behavior in Vireo seems a little subtle. I think a better approach is to follow the JS template literal approach and treat all line terminators as \n.

Tools for working with big/little endian differenced. The was spurred on by running Vireo on the Dominoe Pi which is big endian.

Transitioning between user JavaScript and Emscripten generated JS take long enough to cause significant slowdown (100x)

A property on TypedArrayCore that can hold on to an Error stream for an object.

The parsing of "(", ")", and basic tokens along with error checking is common in many TDCodec VIA functions, make some private methods for them.

As currently written the HTTP palette requires all inputs to be specified and does not align with the optional / required inputs of the VI counterparts.

The required input restrictions on the HTTP palette should be loosened with appropriate unwired input detection added where necessary

Making a meta issue to leave some notes about string communication in and out of Vireo

For writing strings into Vireo (ie http client writes the response bodies into Vireo's memory):

Data_WriteString in CEntryPoints is used by the module_eggShell.js

Data_WriteString is using emscripten ccall

with params 'number' 'number' 'string' 'number'

ccall passes numbers on the stack simply

ccall allocates and copies strings on the stack using stringToUTF8

stringToUTF8 calls stringToUTF8Array

stringToUTF8Array copies values from the JS string but

1. assumes the js string has valid surrogate pairs
   as such it does no validation so both leading (0xD800..0xDBFF) and trailing (0xDC00..0xDFFF) surrogates are treated as a leading surrogate
   and a surrogate pair at the end of the string will run off and use NaN as the second part of the pair

2. seems to allow null (\0) characters by not stopping early

3. null terminates the string (eventhough the string may contain nulls)

Data_WriteString uses a StringRef which is a String which is an array of UTF8Char which is a uint8_t

So Data_WriteString is expecting a number of utf8 bytes for length (excluding null terminator) but the above characteristics mean the js string length is !== the utf8 bytes length

So Data_WriteString should instead use lengthBytesUTF8 internally to get the length

And now it does:

For writing tests it will help to directly use constants. (e.g. MoveTo(20.0 40.3))

Add is currently over loaded by proving AddInt32, AddDouble etc. Allow the overloads to have the same name.

There are several stale branches that we can clean-up and settings we can toggle to prevent some issues. Here are the current branches and recommendations:

The following branches show that they are zero commits ahead of incoming. Since they have no new work they seem safe to delete:

• public
• dynamic-allocations
• generics
• queue_experiments
• static_link

The following have some commits in them. I think we should tag these to preserve the commits and delete the branches (http://stackoverflow.com/questions/1307114/how-can-i-archive-git-branches)

• micro_inwork
• StaticLink2

The following are currently very important, we should enable branch protections (https://help.github.com/articles/about-protected-branches/) for them:

• master

The master branch is currently not being utilized. We should investigate needed configuration changes to move to master as the primary branch:

• Perform fast forward merge of incoming to master
• Changing github default branch
• Verify Travis configured
• Verify npm configuration
• Update badges in README
• Delete incoming

This was an intermittent crash triggered by the test ScanFormat.via/ Note 4 %s format codes
but 3 arguments.

Printf ("---test scan String------ (%s) \n" input21 )
StringScan(input21 remaining "%s%s %s%s" 0 passed v1 v2 v3)

The TM method GetSubElementAddressFromPath drills down an identifier path to determine the effective address of a value. During code synthesis this method will not traverse path elements that can result in a dynamic target address. For example, the address of an array element can change if the array is resized. However methods used at runtime run time to read/write using identifier paths should allow dynamic paths. Add this functionality.

Currently only the JS test suite test the ReadValueString and WriteValueString entry points. We should have a C-based runner that exercises those functions as well.

Part of that work should include refactoring the following tests so that the expected JSON results can be shared in both a JS and C api test suite.

It would be good if we can extract these tests to make them easier to validate in more environments. Right now they expected results are hard coded in JS.

More discussion here:
#252 (review)

There seems to be a bug in LICENSE.txt that stems from Section 3a (https://github.com/ni/VireoSDK/blob/incoming/LICENSE.txt#L18-L19) that prevents us from running Vireo.

This issue might also affect young learners seeking jobs in our profession.

This issue manifests on all platforms.

Perhaps boilerplate MIT license could resolve this issue?

Promising platform, Vireo!

Date::getLocaletimeZone() needs to be extended on Windows to be able to set the timezoneoffset based on whether DST is in effect at a given/passed-in time, rather than the current time.

This support has already been added for Linux/Mac/JS

Provide a means to dynamically load modules used by require statements so Vireo.js is not just one large block.

QueueRef_Obtain checks whether the error pointer is null (to see whether the error cluster is being indeed passed and not marked as a wildcard). However, UnflattenFromJSON does not do the same check but distinguishes whether error cluster is being passed or not by checking the number of arguments. This is error prone and makes codegen difficult to handle situations differently. When error cluster is passed as wild card to UnflattenFromJSON, this is in fact not null -- which is confusing. We should fix this to follow the pattern of QueueRef_Obtain.

If a cluster is flat then block operations are used for Initialization Copying and Clearing. However if it is not flat then the operations defer to each sub type to do the work. This can be improved by doing the block operation and then only calling the non flat sub types as necessary. For example, if a cluster of twenty fields is flat except for one string the init will block clear the fields then call Init for the string field.

Currently the function used for reading strings from Vireo's memory assumes a valid UTF-8 format:

As Vireo / LabVIEW strings are often treated as byte arrays the possibility for invalid UTF-8 string encodings is high.

I incorrectly believed that the string corruption from assuming valid code points would not cause internal errors: #281 (comment)

However I ended up finding a case where this does result in an error. For the LabVIEW string \127 when it is read as JSON the string is encoded as "\127"

The algorithm causes the string to results in "\crazystuff causing the closing quote to be lost in corruption and resulting in invalid JSON. So while no error occurs in Vireos space, when the string is parsed in JS land an exception is thrown because it is invalid JSON.

Some discussion on Wikipedia: https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences

The wiki article describes "popular" replacement options:

1. Use the unicode replacement character
2. Use the low byte of the invalid code point range U+DC80-U+DCFF
3. Use code points U+0080–U+00FF with the same value as the byte
4. The Unicode code point for the character represented by the byte in CP1252

Some thoughts on the options:

1. After reading through the other popular options I think this will be the clearest. It makes it very easy to identify corrupt bytes and the number of corrupt bytes. It is also semantically appropriate. The replacement character is intended to replace unknown, unrecognized, or unrepresentable characters.

2. Does not work because we are going from UTF-8 to UTF-16 and the invalid code point range is utilized for UTF-16 surrogate pairs

3. This was my first thought at implementation but it results in a lot of collisions. ie if the user did intend to use codepoints U+0080-U+00FF in correctly formatted UTF-8 they would be indistinguishable from invalid bytes mapped to that range.

   I think it's also possible to miss the corruption because there are valid and not too uncommon symbols in the range.

   As the string functions are used to read values from Vireo memory for controls and indicators, if the user (vireo integrator) believes invalid UTF-8 strings / arbitrary byte arrays may be present they should not try to read strings as JSON strings but as JSON arrays of numbers or using another API function. The benefit of readJSON on a string type is to aid in conversion from UTF-8 encoded strings to UTF-16 encoded strings.

   Edit: So turns out Windows-1252 and Unicode are intentionally matching from U+0080-U+00FF

4. Running in Browser environment Unicode environment so not relevant

First pass for on all Classes, Methods

Some callers will have a file name that comes from String or SubString so requiring a null terminated string is not good.

The core of TDViaParser::ParseREPL is a holdover from the bootstrapping of vireo.

Static allocated string in EggShell_DataReadString and EggShell_DataWriteString is likely causing aborts() when Vireo is rebooted or re-run using a new user shell.

Possibly relevant source locations:
Location where static string allocation occurs in scope of type manager reference?
Location where type manager reference is passed on call
Location where type manager is deleted on reboot

In the following example the first visit to endpoint eightball is successful and the second visit results in an abort.

This does not effect the vtr suite because it relies only on console io and not readJSON and writeJSON.
The karma test suite has had this issue before and the workaround is to create a new instance of the vireo runtime for every test.

In the express app creating a new runtime for every request slows response time by about 100ms (from 60ms sharing instances and just rebooting to 160ms creating a whole new instance)

// server.js
// calls a web vi using the vireo runtime
// this example assumes the vi runs once per http request
// as such vireo is rebooted for every request

// init project
var express = require('express');
var app = express();
var fs = require('fs');

// load library to measure response time (optional)
var responseTime = require('response-time');
app.use(responseTime());

// load the Vireo Constructor Function
var Vireo = require('vireo');

// create a new Vireo instance
var vireo = new Vireo();

// register some logging functions (only used for debugging)
vireo.eggShell.setPrintFunction(console.log);
vireo.eggShell.setPrintErrorFunction(console.error);

// load the via source code
var via = fs.readFileSync('eightball.via.txt', "utf8");
var viName = 'Main%2Egviweb';

// http://expressjs.com/en/starter/static-files.html
app.use(express.static('public'));

// http://expressjs.com/en/starter/basic-routing.html
app.get("/", function (request, response) {
  response.sendFile(__dirname + '/views/index.html');
});

app.get("/eightball", function (request, response) {
  // reboot load the via code into the runtime
  vireo.eggShell.reboot();
  vireo.eggShell.loadVia(via);
  
  // take the input parameter of the query string and write it to the Input control
  var input = JSON.stringify(request.query.input);
  vireo.eggShell.writeJSON(viName, 'dataItem_Input', input);
  
  // run the via code and allow it to complete asynchronously
  (function runExecuteSlicesAsync() {
    var output;
    var status = vireo.eggShell.executeSlices(1000);
    
    if (status > 0) {
      setImmediate(runExecuteSlicesAsync);
    } else {
      output = JSON.parse(vireo.eggShell.readJSON(viName, 'dataItem_Output'));
      response.send(output);
    }
  }());
});
  
// listen for requests :)
var listener = app.listen(process.env.PORT, function () {
  console.log('Your app is listening on port ' + listener.address().port);
});

The via code

// Autogenerated Vireo assembly file
// Generated on 03/31/2017 11:57:28
define (g0 dv(a(.String *) ('It is certain' 'It is decidedly so' 'Without a doubt' 'Yes definitely' 'You may rely on it' 'As I see it, yes' 'Most likely' 'Outlook good' 'Yes' 'Signs point to yes' 'Reply hazy try again' 'Ask again later' 'Better not tell you now' 'Cannot predict now' 'Concentrate and ask again' 'Don\'t count on it' 'My reply is no' 'My sources say no' 'Outlook not so good' 'Very doubtful')))
//---------------------------------------------------
//VI Definition: Main.gviweb
define (Main%2Egviweb dv(.VirtualInstrument (
    Locals: c(   // Data Space1
        e(.Int32 local1)
        e(.Int32 local2)
        e(.Double local3)
        e(.Double local4)
        e(.Double local5)
        e(.Int32 local6)
        e(.String local7)
        e(dv(.String '')dataItem_Output)
        e(dv(.String '')dataItem_Input)
        e(.Double local10)
    )
        clump(1
        ArrayLength(g0 local1 )
        Decrement(local1 local2 )
        Convert(local2 local3)
        Random(local4 )
        Mul(local4 local3 local5)
        Convert(local5 local6)
        ArrayIndex(g0 local7 local6 )
        Copy(local7 dataItem_Output)
/* Clump Ended. */    )
)))
enqueue (Main%2Egviweb)
//Finished!! :D

output

//Allocations    3, AQCount    82, ShareTypes 0 (ES Delete end)
1:05 AM
5
1:05 AM
5
1:05 AM
abort(5) at Error
1:05 AM
    at jsStackTrace (/app/node_modules/vireo/dist/vireo.js:1:16679)
1:05 AM
    at stackTrace (/app/node_modules/vireo/dist/vireo.js:1:16862)
1:05 AM
    at abort (/app/node_modules/vireo/dist/vireo.js:17:7679)
1:05 AM
    at Array.CK (/app/node_modules/vireo/dist/vireo.js:10:81651)
1:05 AM
    at OB (/app/node_modules/vireo/dist/vireo.js:6:23654)
1:05 AM
    at hd (/app/node_modules/vireo/dist/vireo.js:9:48893)
1:05 AM
    at ccallFunc (/app/node_modules/vireo/dist/vireo.js:1:9506)
1:05 AM
    at /app/node_modules/vireo/dist/vireo.js:1:9812
1:05 AM
    at Object.Module.eggShell.readJSON.publicAPI.eggShell.readJSON [as readJSON] (/app/node_modules/vireo/source/io/module_eggShell.js:125:20)
1:05 AM
Jump to
at runExecuteSlicesAsync (/app/server.js:54:42)
1:05 AM
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.

Types and Values are more cleanly unified now. dot Prefixes are deprecated.

DEFINE_VIREO_TYPE(BinOpInt32, "p(i(.Int32 x) i(.Int32 y) o(.Int32 result))")

turns to:

DEFINE_VIREO_TYPE(BinOpInt32, "p(i(Int32 x) i(Int32 y) o(Int32 result))")

Since sizeof(void*) is 4 on emscripten doubles can be misaligned.