You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 2, 2024. It is now read-only.
Without modular-js, just the default JS generator and Haxe 3.4.2, the above testcase generates this code. That's all well and good, though the var Uint8Array on line 442 does something interesting. It overrides the global Uint8Array for the scope of the whole file, and doesn't set it until execution of that line. It doesn't happen to be a problem with the default JS generator.
But now, consider the output when using modular-js. The output js/html/compat/Uint8Array.js file is here. By definition, this can't work, because the var Uint8Array at the bottom. In this scope, Uint8Array is a null reference until that line executes, so the first line in the scope (Uint8Array.BYTES_PER_ELEMENT = 1) is a null reference. Not only that, declaring a var Uint8Array in this file does not effectively override the global scope (which I believe is the intent / effect of the default JS generator.)
I'm not sure what needs to change -- the modular-js generator, or this line in the compat files in the standard library. But since this issue is currently specific to modular-js, I filed it here. (BTW, @elsassph, I wanted to see what happens in haxe-modular but couldn't get it to work. After installing the npm lib and haxelib, running the testcaes I got sh: 1: haxe-plit: not found)
First, is the idea behind the compat files this: a polyfill for browsers without Uint8Array / DataView / ArrayBuffer / etc? Second, is it a good idea for the compat files to declare a var in untyped __js__, much less a var name that overrides a (browser) global?
Thoughts?
The text was updated successfully, but these errors were encountered:
Effectively modular-js needs to make this compat definition global or required where needed. HaxeJS normally expects everything to be in one anonymous scope so it works. Haxe-modular does what is needed to make the compat definition accessible.
@elsassph Got it, thanks for the info (and the tweet replies)! I currently have a workaround in my build system, but it'd be nice to have a solution built into modular-js. I'll update if I think further about this.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This issue is related to these lines of code (was this in Haxe 3.4.2) in the compat classes, perhaps these existing Haxe issues (6491, 4467), maybe these people (@nadako @andyli @elsassph @kevinresol @MatthijsKamstra) would have some ideas, and this testcase:
Without modular-js, just the default JS generator and Haxe 3.4.2, the above testcase generates this code. That's all well and good, though the var Uint8Array on line 442 does something interesting. It overrides the global
Uint8Array
for the scope of the whole file, and doesn't set it until execution of that line. It doesn't happen to be a problem with the default JS generator.But now, consider the output when using
modular-js
. The outputjs/html/compat/Uint8Array.js
file is here. By definition, this can't work, because thevar Uint8Array
at the bottom. In this scope,Uint8Array
is a null reference until that line executes, so the first line in the scope (Uint8Array.BYTES_PER_ELEMENT = 1
) is a null reference. Not only that, declaring avar Uint8Array
in this file does not effectively override the global scope (which I believe is the intent / effect of the default JS generator.)I'm not sure what needs to change -- the modular-js generator, or this line in the compat files in the standard library. But since this issue is currently specific to modular-js, I filed it here. (BTW, @elsassph, I wanted to see what happens in haxe-modular but couldn't get it to work. After installing the npm lib and haxelib, running the testcaes I got
sh: 1: haxe-plit: not found
)First, is the idea behind the compat files this: a polyfill for browsers without Uint8Array / DataView / ArrayBuffer / etc? Second, is it a good idea for the compat files to declare a var in
untyped __js__
, much less a var name that overrides a (browser) global?Thoughts?
The text was updated successfully, but these errors were encountered: