Compiling hangs forever about assemblyscript HOT 16 CLOSED

Some things I noticed while looking over it:

• export default isn't supported (yet)
• some functions are missing a return type annotation, mostly : void
• at least one function returns a plain object which isn't supported (yet)
• there are quite a few const variable declarations that will emit a warning because these aren't actually compile time constants, but that shouldn't be an issue to make it compile
• when using arrays, some sort of memory manager should be imported, for example import "allocator/arena";
• basic types like f32 can't be nullable (seeing a f32 | null annotations there)
• at one occasion, a i32 is assigned to a f32 variable, that needs an explicit cast

When I fix/comment out the things above, it compiles for me.

from assemblyscript.

Can you try to comment some things in your source file in order to find out where it hangs, and paste the remaining snippet? :)

from assemblyscript.

It seems to happen with the basic add example.
I'm running Arch Linux.
assembly/module.ts:

export function add(x: i32, y: i32): i32 {
    return x + y;
}

assembly/tsconfig.json:

{
    "extends": "../node_modules/assemblyscript/std/assembly.json",
    "include": [
        "./**/*.ts"
    ]
}

running command:

asc assembly/module.ts -t module.untouched.wat -b module.untouched.wasm --validate --sourceMap --measure

from assemblyscript.

Hm that's strange. Are you using the compiler from the master branch on GitHub, or the old prototype on npm?

from assemblyscript.

The master branch on GitHub - I used $ npm install --save-dev AssemblyScript/assemblyscript

from assemblyscript.

Try to rename module.untouched.wat and module.untouched.wasm to module.wat and module.wasm

from assemblyscript.

Try to rename module.untouched.wat and module.untouched.wasm to module.wat and module.wasm

Huh, does that fail sometimes?

The master branch on GitHub - I used $ npm install --save-dev AssemblyScript/assemblyscript

What's your node.js version? Does asc -v work and show exactly this? Does it also happen when you try to compile an empty .ts file, or remove some of the options?

from assemblyscript.

Huh, does that fail sometimes?

That's only a guess. May be several dots in pathname in Linux cause to problems?

from assemblyscript.

Figured it out! I'd run increase-memory-limit in the directory, & it caused the asc command to hang.
It seems that changing the first line of node_modules/.bin/asc from #!/usr/bin/env node to #!/usr/bin/env node --max-old-space-size=4096 causes asc to hang when run.
Removing the flag lets asc run normally. However, asc then runs out of memory compiling my ts module and throws FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory - how should I increase the memory limit if not with that flag?

from assemblyscript.

Try bigger value for example: --max-old-space-size=16384 and add also --optimize_for_size and --aot=false. But this strange. How many system RAM you have?

from assemblyscript.

Just tried out the flag. The smallest power of 2 value that works for me for an empty .ts file is node --max_old_space_size=64 bin/asc tests/builtins.ts. The option is actually using underscores in my setup (node v8.9, win64). Edit: Increasing it to just 128 works for me for the tests/std/math.ts test (incl. --optimize --validate --measure), which is probably the largest test we have.

from assemblyscript.

Got the argument working - I can't put it in the shebang on Linux with /usr/bin/env, but calling node --max_old_space_size=4096 node_modules/.bin/asc assembly/module.ts <etc> Runs node with the higher memory limit. Unfortunately, even with 4097mb allocated, I get an out of memory error - a different one this time:

#
# Fatal error in , line 0
# API fatal error handler returned after process out of memory
#

I've uploaded my code to a gist, so you can reproduce the high memory usage for yourself. I'm trying to translate a Java program to AssemblyScript, so it's probably a weird construct in my code that's causing the compiler to fail.
https://gist.github.com/arilotter/333cacfe16e16d27e2c125a8d788f95e

from assemblyscript.

The issue seems to be related to the kind of line ending used. My guess is that when line endings are just \n, that the code that skips over blocks or statements on errors has an infinite loop somewhere. For reference, it emits a list of errors for me with \r\n line endings.

from assemblyscript.

Your suggestions fix compiling for me, thank you!! Maybe afterwards I'll take a peek at the parsing code related to newlines :)

from assemblyscript.

@dcodeIO would you mind adding me to Slack? I've got a couple questions

from assemblyscript.

The commit above should fix this particular issue with the initial file, though the CRLF/LF issue might still be around somewhere. Feel free to reopen if it resurfaces :)

from assemblyscript.