Re: __main_argc_argv` called before runtime initialization

[Alon Zakai]

That is very strange. Based on those link flags, you did not modify how the
application starts up, so I have no idea how it could break like that. If
it only happens in the Firefox debugger then perhaps it is a Firefox
debugger bug somehow? That seems unlikely too. But maybe try debuggers in
other browsers and other versions of Firefox (in particular I would try
Firefox Nightly).

On Sun, Apr 14, 2024 at 11:06 PM キャロウ マーク  wrote:

> When I try to load the .html  for  my compiled app under the debugger in
> Firefox I get a runtime exception:
>
> native function `__main_argc_argv` called before runtime initialization
>
> If I run without the debugger, the app runs.
>
> I am using Emscripten’s default generated .html. Here are my Emscripten
> link options:
>
> --source-map-base ./
> --exclude-file
> '${PROJECT_SOURCE_DIR}/tests/testimages/cubemap*'
> -s ALLOW_MEMORY_GROWTH=1
> -s DISABLE_EXCEPTION_CATCHING=0
> -s USE_SDL=2
> -s USE_WEBGL2=1
>
> plus a few —preload-file options for some image files.
>
> Any idea why this is happening and how to fix it?
>
> Regards
>
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/A5D9183C-ABB3-4D89-81DC-3DB38CFD6600%40callow.im
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpThe1LhSJ%3DmiVjnyBc%3DHCYF7P7V-yKac1kYZ47arrztzA%40mail.gmail.com.

Re: Are the GROWABLE_HEAP_X methods only needed for pthreads + ALLOW_MEMORY_GROWTH?

[Alon Zakai]

The Acorn optimizer runs on code that is combined with the Emscripten JS
output. That is the main JS output, including JS library support, and also
--pre/post-js and EM_ASM code, which are combined and then optimized as one
(which is good for DCE).

On Tue, Apr 2, 2024 at 8:38 AM 'Michael Hagar' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Does the acorn optimizer only run on Emscripten generated JS? In my case,
> I'm accessing Module.HEAPU8 directly from my own JS (which is not library
> JS). Based on the documentation here:
> https://emscripten.org/docs/porting/pthreads.html?highlight=growable#special-considerations
>
> If I am using PThreads and memory growth, I do need to be using the
> GROWABLE_HEAP_X methods explicitly.
>
> On Monday, August 7, 2023 at 9:47:06 AM UTC-5 Michael Hagar wrote:
>
>> Thanks! I haven't tested using the non-GROWABLE methods for heap access,
>> but that's good to know they shouldn't be needed.
>>
>> On Friday, July 7, 2023 at 7:41:51 PM UTC-5 s...@google.com wrote:
>>
>>> Yes, those methods are only used/needed/present when growable memory is
>>> combined with threads.
>>>
>>> What is more, you should not normally need to use them directly since
>>> emscripten should automatically convert all your heap accesses.  This is
>>> done using the `growableHeap` in `tools/acorn-optimizer.js`.   Are you
>>> running into cases where this is not handled automatically for you?
>>>
>>> cheers,
>>> sam
>>>
>>> On Fri, Jul 7, 2023 at 5:25 PM 'Michael Hagar' via emscripten-discuss <
>>> emscripte...@googlegroups.com> wrote:
>>>
 Do I need to use the GROWABLE_HEAP_X methods if I am only using
 ALLOW_MEMORY_GROWTH, but not pthreads?

 --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/8917e991-3f77-4e9b-99a5-ffc94c750ef3n%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/8b406c6c-cbd2-4e5d-b79c-575631c97610n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQqvuCXwf6jaWH3r0uiMfit6Utco4Jz5EFQUmMQ2%2B-fbQ%40mail.gmail.com.

Re: emscripten_GetProcAddress undefined

[Alon Zakai]

I don't know enough to answer that question, but I suggest asking it on the
PR, as the authors might not see things here on the mailing list, but will
definitely see it there:

https://github.com/emscripten-core/emscripten/pull/20802



On Sat, Dec 16, 2023 at 4:30 AM キャロウ マーク  wrote:

>
>
> On Dec 15, 2023, at 19:45, キャロウ マーク  wrote:
>
> My CI builds have suddenly started failing with wasm_ld reporting
> emscripten_GetProcAddress undefined errors. It is reporting one error for
> each call to the function rather than one overall. I have not changed
> anything in my code so I think this must be related to an update to the
> Emscripten Docker image. My builds use emscripten/emsdk:latest. It is emcc
> 3.1.51 with clang 18.0.0git. It seems unlikely this is a bug. Has there
> been a change that I need to accommodate my code to?
>
>
> I found the breaking change in the changelog:
>
> Breaking change: Using the *glGetProcAddress() family of functions now
> requires passing a linker flag -sGL_ENABLE_GET_PROC_ADDRESS. This prevents
> ports of native GL renderers from later accidentally attempting to activate
> "dormant" features if web browser implementations gain new WebGL extensions
> in the future, which *glGetProcAddress() is not able to support. (#20802)
>
> I do not understand the reason given for the change. As far as I
> understand it the issue is that Emscripten reveals all the extensions
> offered by the WebGL implementation even if they are not implemented by
> Emscripten’s {GL,ES} wrapper and thus has no address for glGetProcAddress
> to return. If this is a correct understanding, the issue should be fixed by
> Emscripten filtering the extension list so it only shows those its wrappers
> implement not by introducing breaking changes. I think the majority of GL
> applications use GetProcAddress.
>
> Regards
>
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/EA1C9222-7CAD-47E0-9CCD-5E2BE2464D52%40callow.im
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQrOooyjug0aj5a025%3D%2B1xoYKcjnBW7p5cFcFzFMBQjfA%40mail.gmail.com.

Re: What is new in emscripten in last two years?

[Alon Zakai]

The Emscripten ChangeLog.md file has information about all breaking changes
as well as other major updates:

https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md


On Mon, Dec 4, 2023 at 3:19 PM Mahesh Velankar  wrote:

> I started using emscripten in Dec 2021 and have my webpage running
> webassembly since Feb 2022 without any issues.
>
> I have visited this group after almost 2 years and will like to know what
> is that I should focus on in case I want to upgrade my installation of
> emscripten with latest version.
>
> Please point me to any such website if there is one, describing what needs
> to  update/upgrade any breaking changes etc..
>
> Thanks in advance
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/6fc21fa0-758d-4d56-9163-40e7be486466n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR25iTFxNvALC45tozNq2dW6Nnh-BKzgSc3pwAdJPfnLw%40mail.gmail.com.

Re: How to recompile system libs (like WASM) for testing

[Alon Zakai]

The simplest thing is

emcc --clear-cache

which deletes all built libraries. They are then rebuilt on demand next
time you run emcc.

More generally, you can use embuilder. embuilder --help will show the
available commands. (Note you need to use --force to rebuild an already
built library.)

On Tue, Nov 21, 2023 at 7:13 PM Andrew O'Mahony 
wrote:

> Hello,
>
> I've made some changes to the system libs (WASM) that I want to test out.
> However, I can't seem to get them to recompile both when I run the unit
> tests nor when I recompile my program that uses WASMFS.
>
> How can I recompile the system libs?
>
> Thanks,
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c23f871a-0f16-40b2-bb5f-88174690a701n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRYp5oP2K_Ck4KjTO3YvkswQNTjaHDPCYDnRyXRTH7M2w%40mail.gmail.com.

Re: Creating and editing a filesystem seperate from compilation

[Alon Zakai]

The JS file that the file packager creates depends on the emscripten
runtime code, so you do need to compile a program to use it. But perhaps
you can compile a small one. Then you just combine the JS from that with
the JS from the file packager and it should work. There are examples of
this in the test suite I believe (search for FILE_PACKAGER in tests/*).


On Wed, Jul 19, 2023 at 3:39 AM Ronny Nissengold 
wrote:

> Thanks!
> But I am not trying to compile into a project a filesystem. I already did
> that successfully using the embind flags.
> I am trying to work with a filesystem for a project separately from its
> compilation.
> Is that at all possible?
> I tried using the file_packager.py to no avail.
> It generates a .data file with the FS and the .js file I don't know what
> to do with.
>
> ב-יום שלישי, 18 ביולי 2023 בשעה 18:53:36 UTC+3, alon...@gmail.com כתב/ה:
>
>> That error might be because we do not export all functions by default.
>> Try with
>>
>> emcc -sEXPORTED_RUNTIME_METHODS=addRunDependency
>>
>> On Sun, Jul 16, 2023 at 7:22 AM Ronny Nissengold 
>> wrote:
>>
>>> Hi all,
>>> By giving the linker the --preload-file flag with the appropriate folder
>>> I was able to successfully create and access the emscripten FS from cpp as
>>> I usually would.
>>> However I would like to be able to create a FS separately from the
>>> compilation process. It just feels wrong.
>>> I was able to use the file_packager.py to create a .data and .js file.
>>> I tried running the filesystem.js before my main .js file in my custom
>>> index.html, and got an error:
>>> Module.addRunDependency is not a function
>>> Any idea what am I doing wrong? What is the best way to create and
>>> access FS in emscripten? Should I just preload in the linker?
>>> Thanks!
>>> Ronny
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/31e7e544-610b-48c4-993a-b8272037c6e1n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/aea0f159-cc08-4216-b7cc-0d78f5f0a37en%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRk6fXtFtySjeuJVQ8v3P3at517aLZiwC19sm818ghvYg%40mail.gmail.com.

Re: Creating and editing a filesystem seperate from compilation

[Alon Zakai]

That error might be because we do not export all functions by default. Try
with

emcc -sEXPORTED_RUNTIME_METHODS=addRunDependency

On Sun, Jul 16, 2023 at 7:22 AM Ronny Nissengold 
wrote:

> Hi all,
> By giving the linker the --preload-file flag with the appropriate folder I
> was able to successfully create and access the emscripten FS from cpp as I
> usually would.
> However I would like to be able to create a FS separately from the
> compilation process. It just feels wrong.
> I was able to use the file_packager.py to create a .data and .js file.
> I tried running the filesystem.js before my main .js file in my custom
> index.html, and got an error:
> Module.addRunDependency is not a function
> Any idea what am I doing wrong? What is the best way to create and access
> FS in emscripten? Should I just preload in the linker?
> Thanks!
> Ronny
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/31e7e544-610b-48c4-993a-b8272037c6e1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTNtFfjy%2BfTXo5CWdAo9zkiRuA%3DJqN2sa8GLMZ53mCzEA%40mail.gmail.com.

Re: SDL1 and SDL2

[Alon Zakai]

Thanks, good to know that this is being used. Sam already mostly convinced
me to keep SDL1 around already, so with this information I think we can
decide to keep it.

- Alon



On Fri, Jun 9, 2023 at 3:02 AM Александр Гурьянов 
wrote:

> I use SDL 1 in many project, because it's more lightweight, anyway I think
> for me it's not a problem, because I can switch to older versions of emsc.
>
> чт, 8 июн. 2023 г. в 09:41, Floh :
>
>> Are you suggesting that we could somehow use upstream GLFW?  That seems
>> unlikely since GLFW interacts so closely with input events and the
>> display.. it seems like we would need a specific emscripten of that
>> library.  Or are you suggesting we invest in a  port to emscripten in the
>> upststram GLFW repo?
>>
>> No, just deprecate the Emscripten GLFW wrapper and instead pitch the
>> HTML5 functions for WebGL context setup and input events (
>> https://emscripten.org/docs/api_reference/html5.h.html) :)
>>
>> Most existing native GLFW code is written in an "own the game loop" model
>> and would need Emscripten specific tweaks anyway, and at the same time, the
>> GLFW API isn't so big that it would be a lot of work to replace.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/b175b4bc-4662-4e6f-a35d-69ebfec1303cn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFOisuwQsPxhH7pOiaoqmFVsh9x04gGgEhAp1qKCPWquQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRFnnavKDzv49%3D1bo3SP%3Dj487iHM0ne1Mr8orBVxBDMhQ%40mail.gmail.com.

Re: SDL1 and SDL2

[Alon Zakai]

As I said at the start, it does become somewhat annoying to fully maintain
with WasmFS. We've found a way to work around some of that in

https://github.com/emscripten-core/emscripten/pull/19452

but more remains (right now I'm looking at some closure issues related to
it). It is just awkward to access the filesystem from JS in a JS-ey way
when it is written in wasm - we're going to try to make the WasmFS JS API
as good as possible, but it can't be perfect (e.g. we probably won't create
all the objects the current JS FS provides JS, like the return object of
FS.analyzePath etc.).

- Alon


On Wed, Jun 7, 2023 at 12:41 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Wed, Jun 7, 2023 at 10:29 AM Alon Zakai  wrote:
>
>> Yeah, this is tricky. I agree with Floh that our early ports of glfw etc.
>> are of limited use. Ideally they'd all be done like SDL2, that is, be in
>> upstream + use emscripten HTML5 C APIs as much as possible, to get
>> consistent input event handling etc., which is a common issue as you said,
>> Sam.
>>
>> Still, I'd like to remove SDL1 specifically because we do have an obvious
>> replacement, SDL2, which is also our best such implementation.
>>
>
> Although I'm normally in favor of removing stuff.. I'm not sure we have a
> good reason to in this case.   It doesn't cost us much to maintain does it?
>
>
>>
>> - Alon
>>
>>
>> On Wed, Jun 7, 2023 at 9:16 AM 'Sam Clegg' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 7, 2023 at 5:36 AM Floh  wrote:
>>>
>>>> I wonder whether most of those old "portability wrappers" shouldn't be
>>>> deprecated tbh (SDL2 might be special because it has "official" upstream
>>>> support now?).
>>>>
>>>> Those wrappers were very helpful in the beginning to get things
>>>> started, but for instance (as far as I noticed) Dear ImGui was running into
>>>> quite a few confusing differences recently between Emscripten's GLFW
>>>> wrapper and "native" GLFW (mainly subtle things like mouse wheel input
>>>> events behaving differently).
>>>>
>>>> When people see Emscripten's GLFW support they probably expect that it
>>>> behaves identical with the "official" GLFW, but this would mean putting a
>>>> lot of effort into the "GLFW emulation" which should better go into the
>>>> "core product" (for instance more C API wrappers for web APIs).
>>>>
>>>>
>>> Are you suggesting that we could somehow use upstream GLFW?  That seems
>>> unlikely since GLFW interacts so closely with input events and the
>>> display.. it seems like we would need a specific emscripten of that
>>> library.  Or are you suggesting we invest in a  port to emscripten in the
>>> upststram GLFW repo?
>>>
>>> I don't how that would prevent  bugs like `mouse wheel input events
>>> behaving differently` since those could still conceivably occur, even in an
>>> upstream port simply due to the what the mouse wheel events are reported by
>>> the browser, no?
>>>
>>> Anyway, just my 2ct :)
>>>>
>>>>
>>>>
>>>> On Saturday, 3 June 2023 at 06:52:20 UTC+2 alon...@gmail.com wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I wonder if we still need our SDL1 (SDL 1.2, specifically)
>>>>> implementation at this time, given that we have excellent and stable SDL2
>>>>> support?
>>>>>
>>>>> Context: SDL1 has been deprecated for many years now [1]. SDL2 is a
>>>>> decade old at this point [2], and other projects have removed SDL1 support
>>>>> (e.g. [3]). In fact, SDL is working on SDL3 now [4].
>>>>>
>>>>> Historically, I think SDL1 was Emscripten's first supported graphics
>>>>> API, and that code is quite old and quirky, as I'm noticing while I'm
>>>>> working on WasmFS. The later SDL2 port was done in a much better way (and
>>>>> WasmFS, in particular, "just works" with it, unlike SDL1). So removing the
>>>>> weird SDL1 code could help speed up our development.
>>>>>
>>>>
>>>>> Is anyone using SDL1 and unable to upgrade to SDL2 (or to glfw etc.)
>>>>> for some reason?
>>>>>
>>>>> - Alon
>>>>>
>>>>> [

Re: SDL1 and SDL2

[Alon Zakai]

Yeah, this is tricky. I agree with Floh that our early ports of glfw etc.
are of limited use. Ideally they'd all be done like SDL2, that is, be in
upstream + use emscripten HTML5 C APIs as much as possible, to get
consistent input event handling etc., which is a common issue as you said,
Sam.

Still, I'd like to remove SDL1 specifically because we do have an obvious
replacement, SDL2, which is also our best such implementation.

- Alon


On Wed, Jun 7, 2023 at 9:16 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Wed, Jun 7, 2023 at 5:36 AM Floh  wrote:
>
>> I wonder whether most of those old "portability wrappers" shouldn't be
>> deprecated tbh (SDL2 might be special because it has "official" upstream
>> support now?).
>>
>> Those wrappers were very helpful in the beginning to get things started,
>> but for instance (as far as I noticed) Dear ImGui was running into quite a
>> few confusing differences recently between Emscripten's GLFW wrapper and
>> "native" GLFW (mainly subtle things like mouse wheel input events behaving
>> differently).
>>
>> When people see Emscripten's GLFW support they probably expect that it
>> behaves identical with the "official" GLFW, but this would mean putting a
>> lot of effort into the "GLFW emulation" which should better go into the
>> "core product" (for instance more C API wrappers for web APIs).
>>
>>
> Are you suggesting that we could somehow use upstream GLFW?  That seems
> unlikely since GLFW interacts so closely with input events and the
> display.. it seems like we would need a specific emscripten of that
> library.  Or are you suggesting we invest in a  port to emscripten in the
> upststram GLFW repo?
>
> I don't how that would prevent  bugs like `mouse wheel input events
> behaving differently` since those could still conceivably occur, even in an
> upstream port simply due to the what the mouse wheel events are reported by
> the browser, no?
>
> Anyway, just my 2ct :)
>>
>>
>>
>> On Saturday, 3 June 2023 at 06:52:20 UTC+2 alon...@gmail.com wrote:
>>
>>> Hi everyone,
>>>
>>> I wonder if we still need our SDL1 (SDL 1.2, specifically)
>>> implementation at this time, given that we have excellent and stable SDL2
>>> support?
>>>
>>> Context: SDL1 has been deprecated for many years now [1]. SDL2 is a
>>> decade old at this point [2], and other projects have removed SDL1 support
>>> (e.g. [3]). In fact, SDL is working on SDL3 now [4].
>>>
>>> Historically, I think SDL1 was Emscripten's first supported graphics
>>> API, and that code is quite old and quirky, as I'm noticing while I'm
>>> working on WasmFS. The later SDL2 port was done in a much better way (and
>>> WasmFS, in particular, "just works" with it, unlike SDL1). So removing the
>>> weird SDL1 code could help speed up our development.
>>>
>>
>>> Is anyone using SDL1 and unable to upgrade to SDL2 (or to glfw etc.) for
>>> some reason?
>>>
>>> - Alon
>>>
>>> [1] https://github.com/libsdl-org/SDL-1.2
>>> [2] https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer
>>> [3]
>>> https://patchwork.kernel.org/project/qemu-devel/patch/20180808104930@redhat.com/
>>> 
>>> [4] https://discourse.libsdl.org/t/sdl-3-0/40374
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/903c41e4-19e3-4fde-9816-312f1e7da3d4n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28cyxzdtfPTYJD1rCqN3OSy-qW_Mqpf2YLc6vZ2NE6MZA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS41Y2rU6WoWRHb_4GZJ5o4PerPJnZpqbz7St_B48rjGg%40mail.gmail.com.

SDL1 and SDL2

[Alon Zakai]

Hi everyone,

I wonder if we still need our SDL1 (SDL 1.2, specifically) implementation
at this time, given that we have excellent and stable SDL2 support?

Context: SDL1 has been deprecated for many years now [1]. SDL2 is a
decade old at this point [2], and other projects have removed SDL1 support
(e.g. [3]). In fact, SDL is working on SDL3 now [4].

Historically, I think SDL1 was Emscripten's first supported graphics API,
and that code is quite old and quirky, as I'm noticing while I'm working on
WasmFS. The later SDL2 port was done in a much better way (and WasmFS, in
particular, "just works" with it, unlike SDL1). So removing the weird SDL1
code could help speed up our development.

Is anyone using SDL1 and unable to upgrade to SDL2 (or to glfw etc.) for
some reason?

- Alon

[1] https://github.com/libsdl-org/SDL-1.2
[2] https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer
[3]
https://patchwork.kernel.org/project/qemu-devel/patch/20180808104930.23133-4-berra...@redhat.com/
[4] https://discourse.libsdl.org/t/sdl-3-0/40374

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRUVR0TF5wtWD2WOqVcqvdrDj0jpAB0xvEARciX%3DYL%2BSA%40mail.gmail.com.

Re: Bump default minimum node version for generated code?

[Alon Zakai]

On Tue, Apr 18, 2023 at 9:14 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Note that there are three distinct node versions at play in the emscripten
> world.   One has already been bumped. and one we plan to bump, and one we
> don't have plans to change.
>
> 1. Min version required to run output code (this is only the default can
> can be lowered via setting):
>  10.19.0 -> 15.0.0 (PLANNED UPDATE)
> 2. Version of node we ship in emsdk:
>  14.15.5 -> 15.14.0  (ALREADY UPDATED)  (
> https://github.com/emscripten-core/emsdk/pull/829)
> 3. Min version required to run emcc itself:
>  10.19.0  (NO CHANGE PLANNED) (
> https://github.com/emscripten-core/emscripten/blob/1e7b78fe45cee0b96b64938f9742368923cd0713/tools/shared.py#L51
> )
>
> Note that for (3) we do a minimal amount of testing of emcc with this
> pinned (very old) version of node just to ensure folks can run emcc on very
> old systems.   The only reason we would ever need to bump this number would
> be if our internal usage of JS in the JS compiler required some new node or
> JS feature.
>
> Since emsdk (2) has already been updated, I'm not sure there is any reason
> to update again from 15.14.0 to 16.0.0.  I'm not sure what benefit that
> would have.
>
> For (1) I also don't see what there is to be gained from
> artificially bumping up from 15 to 16.   That would just seem to limit
> artifiically limit that places where emscripten output can run since the
> output doesn't actually depend on any features that are not available in 15.
>
>
Interesting points. On the one hand I agree with Ulhas and Jukka that it is
odd to set a default version number that isn't an LTS version, since who
would be using an older version that is not LTS? (non-LTS versions are no
longer supported after 6 months, I believe) But on the other hand moving
from 15 to 16 would only support less things as Sam says (running in 16
will work if we set 15, but not in reverse).

Is there any data on version usage? I can't seem to find any. But if the
data showed that practically no one uses anything but LTS versions then 16
might make more sense. Or, if older non-LTS versions are used sometimes
then maybe not.

- Alon


>
> On Tue, Apr 18, 2023 at 4:29 AM Jukka Jylänki  wrote:
>
>> This sounds good to me. Ulhas has a good point about the version numbers,
>> a LTS might be more desirable.
>>
>> Another thing to note is that Node 10.19 supported Windows 7, and
>> starting from Node 14.x, Windows 8.1 or higher is required. So this change
>> does mean dropping Windows 7 support. I think it is about time that happens
>> though.
>>
>
> That is interesting.  Note that emsdk updated past 10.19 a long time ago
> so in terms of running emsdk itself I guess that ship has long sailed.  The
> proposed change here would mean if you wanted to run the *output* of
> emscripten on a windows 7 machine you would need to specify
> `-sMIN_NODE_VERSION=101900`.. but it should still be runnable once you did
> that.
>
>
>> On Tue, Apr 18, 2023 at 8:36 AM Ulhas Pawar  wrote:
>>
>>> Hello!
>>> Does it make sense to bump version to even numbered node release:
>>> https://nodesource.com/blog/understanding-how-node-js-release-lines-work/
>>>
>>> Odd numbered releases are killed soon and LTS is only for even number
>>> releases.
>>>
>>> Thanks,
>>> Ulhas
>>>
>>> On Tue, Apr 18, 2023 at 7:22 AM Shlomi Fish 
>>> wrote:
>>>
>>>> hi Alon, and all
>>>>
>>>> On Mon, 17 Apr 2023 16:56:01 -0700
>>>> Alon Zakai  wrote:
>>>>
>>>> > Hi everyone,
>>>> >
>>>> > We are considering bumping the default minimum node version for
>>>> > emscripten-generated code, from 10.19 to 15.0:
>>>> >
>>>> > https://github.com/emscripten-core/emscripten/pull/19192/files
>>>> >
>>>> > The main motivation is that 10.19 is quite old at this point so most
>>>> people
>>>> > are likely using newer versions. And 15.0 supports wasm-bigint
>>>> integration,
>>>> > which would allow us to use that by default (which is nice as it
>>>> avoids
>>>> > workarounds for i64 values otherwise not being usable between wasm
>>>> and JS -
>>>> > that helps code size, speed, and compile times).
>>>> >
>>>>
>>>> I approve of the version bump.
>>>>
>>>> > sure which are the most commonly-used...
>>>> >
>>>> > - Alon
&g

Bump default minimum node version for generated code?

[Alon Zakai]

Hi everyone,

We are considering bumping the default minimum node version for
emscripten-generated code, from 10.19 to 15.0:

https://github.com/emscripten-core/emscripten/pull/19192/files

The main motivation is that 10.19 is quite old at this point so most people
are likely using newer versions. And 15.0 supports wasm-bigint integration,
which would allow us to use that by default (which is nice as it avoids
workarounds for i64 values otherwise not being usable between wasm and JS -
that helps code size, speed, and compile times).

Concretely, with this change, running

emcc test/hello_world.c

would emit a.out.js and a.out.wasm that depend on node 15.0 to run. If you
run a.out.js in an older node you'll get an error in a build with
assertions enabled.

Note that this only affects the node version - if you never run your code
in node (maybe you always run in a browser) then this won't affect you.
This is also unrelated to the node version emcc itself uses internally for
the JS compiler and optimizer etc. Note also that this would only affect
the *default* version, but it will still be possible to set a different
node minimum version, using

emcc -sMIN_NODE_VERSION=101900

That sets it to 10.19.0 (the old default). That is, this just changes the
default, but support for older node versions is still possible if you set a
flag.

Overall this seems like a useful change (as mentioned, this gets us closer
to enabling wasm-bigint by default), and with low risk. In particular, the
node website's downloads are all of newer versions - even the LTS download
is higher than 15.0 (by a significant amount - 18.16). However, this might
mean that, say, someone using the default node in their Linux distro might
run into an issue, as e.g. latest Ubuntu LTS seems to have an older version
(12.0), so I wanted to check on the mailing list what people thought. It is
nice to have emcc output "just work" in common node versions, but I'm not
sure which are the most commonly-used...

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSgZ5ebeKYK7CPzU%3DZmZMMTMJpyveepEbQSfy%3DTTL4ZqA%40mail.gmail.com.

Re: PTHREAD_POOL_SIZE questions...

[Alon Zakai]

On Tue, Apr 4, 2023 at 7:45 PM Mark Sibly  wrote:

> I'm building a 3rd party c++ lib in emscripten that uses pthreads, and I'm
> finding that I have to use -sPTHREAD_POOL_SIZE=23 for it to work, otherwise
> it hangs.
>
> I did think leaving out -sPTHREAD_POOL_SIZE (or setting it to 0) would
> create threads on demand, but I just found this on the emscripten pthreads
> docs page and suspect this is what's happening as the lib's API is just a
> single function that appears to execute synchronously:
>
> "you cannot call pthread_create and then keep running code synchronously
> that expects the worker to start running"
>
> So OK, I'll need to manually specify a pool size, but what value should I
> use? The lib bases it's thread usage on std::thread::hardware_concurrency()
> (and seems to be a bit off as I have 16 but need a pool size of 23) but I
> can't know that at link time so what should I use? I'll also need to hard
> code this as a maximum into the lib of course but that's OK. Is there a way
> to determine PTHREAD_POOL_SIZE at runtime?
>

You can specify it during startup, so you can tell it to use the browser's
thread count (which is reflected to C++ in thread::hardware_concurrency()).
See this note:

https://github.com/emscripten-core/emscripten/blob/b2f3b50b0291ed6b0e3058194b1b6db927ab4c33/src/settings.js#L1547-L1553


>
> Can I just use 256 or something crazy, or would that break on some low
> specced computers, ie: how 'heavyweight' are these WebWorkers? I'm sort of
> feeling an '8' here for some reason...
>

Each worker is a full JS context, so it does take several MB at least. It
might make sense to tell the application to use a maximum of say 8 or so,
yeah, unless it can really benefit from more...


>
> One other thing, what exactly does -sPTHREAD_POOL_SIZE_STRICT do? I'm
> finding setting it to '0' causes my app to hang if I  haven't set thread
> pool size high enough, and setting it to '2' causes an exception to be
> thrown instead.
>
> So I've just set it to '2', but am I missing something with '0'? Are there
> any other useful values? Note that there's nothing about
> -sPTHREAD_POOL_SIZE_STRICT on the emscripten pthreads docs page.
>
>
The lower-level docs have that info I believe:

https://github.com/emscripten-core/emscripten/blob/b2f3b50b0291ed6b0e3058194b1b6db927ab4c33/src/settings.js#L1557-L1572

Finally, the lib makes quite complex use of threads - there are
> std::futures and std::promises all over the place and I initally thought
> I'd never get it going in emscripten, but once I found the
> PTHREAD_POOL_SIZE fix everything just worked! This is a very impressive
> achievement for emscripten IMO!
>
>
Great! :)

Yeah, there are quite a lot of weird things with how the Web does threads,
and so we have to use a lot of hacks and things, but often a lot of code
ends up just working with one or two settings adjustments, thanks to a
great deal of work that's gone into this...

- Alon



> Bye!
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/db07f3cc-0080-4c1f-946c-d57a3fef4cd5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQUr0v27%3Dc71BMi%3D6D9R1Q9g1uREKpTXA4iTLSX-wCsKA%40mail.gmail.com.

Re: what is wrong with recent Emscripten?

[Alon Zakai]

You can use an older version by doing

emsdk install 1.38.13

In some cases you may also need to use an older emsdk for that. To do so,
you can checkout the 1.38.13 tag in the emsdk repo. If you still see
issues, try doing so in a new checkout of the emsdk perhaps.

In general, if you see issues on an upgrade from 1.38.x to later then a
huge change happened in 1.39.0, the entire LLVM backend was replaced
(fastcomp => upstream). That usually helps, but in some cases there are
regressions. 30% does seem high, however, so that might be worth looking
into.

Otherwise, any problem with upgrading can often be helped by bisecting, to
get the specific commit where you hit a problem:

https://emscripten.org/docs/contributing/developers_guide.html#bisecting

Bisecting is usually very fast once you start.

On Sun, Mar 5, 2023 at 12:04 PM juergen...@gmail.com <
juergen.wot...@gmail.com> wrote:

> I just made the mistake to update my old Emscripten 1.38.13 version (which
> had worked fine) to a recent 3.1.x version (due to one 3rd party project
> that had specifically required a respective >3.1.x version).
>
> Interestingly it seems that the executables of my existing WASM projects
> now suddenly are massively (30% ) larger when compiled with the new
> Emscripten version, e.g. 3MB instead of 2.3MB.. WTF? (same build script  -
> only change was to add "-r" option when building ".bc" libs).
>
> Worse it seems that code that worked fine before now suddenly doesn't
> anymore. (e.h.  some kind of emulator that generates chiptune music and the
> respective audio calculations now suddenly produce garbage - whereas the
> same code compiled with the 1.38.13 version  did not have this problem.)
>
> Worst of all I had kept the backup folder of my old emscripten
> installation - as an insurance against the above scenario. Only to find
> that the new install apparently messed up stuff outside of the installation
> folder and my old version no longer wants to start.. :-( Help! How can I
> rollback to my old version to escape this nightmare?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/4e59121e-0359-42c5-83d9-b1b6967b6e30n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQkBqXNMG0NAU-OHGMTXR5ObWw-tu1gHnY5J%3DSm%2BuinmA%40mail.gmail.com.

Re: Compile with Emscripten to bare V8 (no browser, no Node.js)

[Alon Zakai]

To add to that, as I mentioned on Discord, Emscripten output should just
work in plain V8, or at least the d8 shell, using the "shell" environment.
Maybe one or two minor d8 additions like a way to load a binary file would
be needed in plain V8, but that's it.

- Alon



On Wed, Feb 15, 2023 at 2:28 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Wed, Feb 15, 2023 at 2:16 PM Tudor Bosman  wrote:
>
>> Yes, I am interested in running this, we are embedding V8 to run plain JS
>> already. I'm planning to test using d8 and then port the d8 API into our
>> embedder.
>
>
> If you are already embedding v8 then I don't see that there is anything
> you should need to do.  WebAssembly should just work in your embedded v8
> environment unless you are jumping through hoops to somehow disable it.
>
>
>
>>
>> We're not using Node because of security isolation -- this is a piece of
>> a larger puzzle that includes running untrusted code.
>>
>> Thanks,
>> -Tudor.
>>
>> On Wednesday, February 15, 2023 at 1:19:25 PM UTC-8 s...@google.com
>> wrote:
>>
>>> Are you interested in running the generated wasm and JS code, or just
>>> the wasm code (in something like STANDALONE_WASM mode)?
>>>
>>> There are various options, but by far simplest is probably to use d8
>>> (the v8 command line tool normally used for testing).The easiest way to
>>> install it is via jsvu: https://github.com/GoogleChromeLabs/jsvu.  By
>>> the way you should be able to run your code under the other shells
>>> supported by jsvu too (e.g. jsc).
>>>
>>> If you want to take it to the next level you could embed v8 an your own
>>> application using the v8 embedding API:
>>> https://github.com/GoogleChromeLabs/jsvu
>>>
>>> It does beg the question though, why not just use node?
>>>
>>> cheers,
>>> sam
>>>
>>>
>>> On Wed, Feb 15, 2023 at 11:02 AM Tudor Bosman  wrote:
>>>
 So perhaps I'm crazy, but I'd like to run C code (compiled to WASM via
 Emscripten) on bare embedded V8 (without a browser, and without Node).

 This would be for (headless) server-side code, so I don't care about
 graphics / audio / GL / etc, but ideally it would be complete enough to run
 Pyodide with numpy.

 Obviously I'd have to implement some glue API (perhaps emulating part
 of the browser API would be easier than Node's). Has anyone done anything
 similar? Is there a minimal set of interfaces documented anywhere?

 There is something called headless.js in the emscripten repository
 which seems to do something in this direction, but I'm not sure how far
 along it is and what else is needed, or even if I'm on the right path.

 Thanks,
 -Tudor.

 --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/5b063948-670a-43f3-aed7-cc6ca96834b2n%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/20647156-2e3b-4446-867e-27823e2c372en%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-uZ4j6ZQhwr3-hdM_%2Bb1LwX%3DzuBb25TG4Zbgyr5zn%3DBw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpShMzDr-VTK6fh%2BPkV%2BFTVy5gFAi8bc9u8CGSxi-izUMw%40mail.gmail.com.

Re: wasm-opt -fwasm-exceptions & asyncify

[Alon Zakai]

Are you saying LLVM optimizations cause try-catch to appear? That seems odd
to me. Unless it really is simply because of inlining - in that case
[[noinline]] can help.

Otherwise I think try-catch like those, which are really just to call
std::terminate() on an exception, are added by clang in some cases, see
details here:

https://github.com/emscripten-core/emscripten/issues/9185

If nothing else works, the Binaryen pass mentioned there might be modified
to manually remove try-catches perhaps.

On Fri, Jan 27, 2023 at 2:01 AM Александр Гурьянов 
wrote:

> Checked other optimization flags, defenitly this happens befcause of -Oz.
> -O0, -O1 - works fine, I even can run Windows 95 that hardly uses
> exceptions code 拾拾拾
> -Oz, -O2 - not working (assertion "unexpected expression type")
>
> So I need somehow exclude this two functions from optimization and then I
> will have optimized code with exceptiosn that works fine with asyncify. How
> I can do this?
>
>
>
> пт, 27 янв. 2023 г. в 12:30, Александр Гурьянов :
>
>> Hi, I trying to add asyncify into project that uses exceptions
>> (dosbox-x). I know that asyncify currently does not support exceptions. My
>> idea is asyncify only "top level" functions that does not have exceptions
>> code. My current asyncify call stack is:
>>
>> js -> $runJsdos (asyncify) -> $jsdos_main (asyncify) -> $loopNoThrow ->
>> $loop -> ...
>>
>> $loop can throw exception, so  I impelemtned loopNoThrow like this:
>>
>> int loopThrownNum = -1;
>> int loopNoThrow() {
>> try {
>> return (*loop)();
>> } catch (int x) {
>> loopThrownNum = x;
>> return 0;
>> } catch (...) {
>> printf("throwing out loopNoThrow is not supported by asyncify\n");
>> abort();
>> }
>> }
>>
>> I turning the exception into ret val, and the $jsdos_main is last
>> asyncify function:
>>
>> while (true) {
>>   sleep(0);
>>   int ret = loopNoThrow();
>>   // rest logic
>> }
>>
>> To be sure that I don't use exceptions in async function, I mark them as
>> noexcept, and compile with -fno-exceptions.
>>
>> However, at link stage wasm-opt fail on assertion "unexpected expression
>> type", because in function $runJsdos there are exception handling code.
>>
>> The code of $runJsdos before wasm-opt:
>>
>> (func $runJsdos (param $0 i32) (result i32)
>>   (drop
>>(call $jsdos_main\28Config*\29
>> (local.get $0)
>>)
>>   )
>>   (call $jsdos::destroyAsyncify\28\29)
>>   (block $label$1
>>(br_if $label$1
>> (i32.eqz
>>  (local.get $0)
>> )
>>)
>>(drop
>> (call $Config::~Config\28\29
>>  (local.get $0)
>> )
>>)
>>   )
>>   (call $operator\20delete\28void*\29
>>(local.get $0)
>>   )
>>   (unreachable)
>>  )
>>
>> As you can see there is nothing related to exceptions, but AsyncifyFlow
>> reports that $runJsdos have following code:
>> (try
>>  (do
>>   (local.set $3
>>(i32.load $0
>> (i32.const 1889704)
>>)
>>   )
>>   (nop)
>>   (local.set $3
>>(call_indirect $0 (type $none_=>_i32)
>> (local.get $3)
>>)
>>   )
>>  )
>>  (catch $tag$0
>>   (local.set $0
>>(pop i32)
>>   )
>>   (nop)
>>   (nop)
>>   (nop)
>>   (global.set $__stack_pointer
>>(local.get $2)
>>   )
>>   (i32.store $0
>>(i32.const 40043732)
>>(i32.const 1052)
>>   )
>>   (i32.store $0
>>(i32.const 40043728)
>>(i32.const 0)
>>   )
>>   (nop)
>>   (call $_Unwind_CallPersonality
>>(local.get $0)
>>   )
>>   (nop)
>>   (local.set $1
>>(i32.load $0
>> (i32.const 40043736)
>>)
>>   )
>>   (nop)
>>   (nop)
>>   (local.set $0
>>(call $__cxa_begin_catch
>> (local.get $0)
>>)
>>   )
>>   (nop)
>>   (local.set $1
>>(i32.eq
>> (local.get $1)
>> (i32.const 2)
>>)
>>   )
>>   (if
>>(local.get $1)
>>(block
>> (nop)
>> (local.set $0
>>  (i32.load $0
>>   (local.get $0)
>>  )
>> )
>> (i32.store $0
>>  (i32.const 1149424)
>>  (local.get $0)
>> )
>> (call $__cxa_end_catch)
>> (unreachable)
>>)
>>   )
>>   (call $puts
>>(i32.const 5497)
>>   )
>>   (try $label$938
>>(do
>> (call $abort)
>>)
>>(catch_all
>> (nop)
>> (global.set $__stack_pointer
>>  (local.get $2)
>> )
>> (try
>>  (do
>>   (call $__cxa_end_catch)
>>  )
>>  (catch_all
>>   (nop)
>>   (global.set $__stack_pointer
>>(local.get $2)
>>   )
>>   (call $std::terminate\28\29)
>>   (unreachable)
>>  )
>> )
>> (rethrow $label$938)
>>)
>>   )
>>   (unreachable)
>>  )
>> )
>>
>> Probably this happens because of some inlining, I compile with -Oz, but I
>> am not sure. How I can avoid injection of exception handling code into this
>> functions?
>>
>> Thank you!
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: Debug info for 'this' pointer vanished from 3.1.24 to 3.1.26?

[Alon Zakai]

Bisection might be useful here, as in theory any LLVM change could cause
such a difference or a bug. It's pretty simple to bisect using the emsdk:

https://emscripten.org/docs/contributing/developers_guide.html#bisecting


On Tue, Dec 6, 2022 at 4:22 PM Gregory Propf  wrote:

> I just noticed something while debugging a program. A few days ago I
> migrated from 3.1.24 to 3.1.26. It now seems that, in Chrome at least, I
> only see the literal value of the 'this' pointer but can't see the
> components of the object. My CFLAGS are still the same: -O0 -g -std=c++17.
> For now I'm fine just setting the toolchain back to 3.1.24 but I was
> curious as to whether others had noticed this or if it's just that I need
> some additional CFLAGS settings to get that level of debug detail now.
>
> - Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/4086b3e0-d720-464e-b93f-800adbd514a3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ2S0wXeZ%2BgdauGm543s0v4Ux1%2BPLRsO0w5BgXuJ-c7DQ%40mail.gmail.com.

Re: acorn-optimizer error with -O2 or higher

[Alon Zakai]

Hmm, this doesn't sound like a known issue. You can build with EMCC_DEBUG=2
in the env, and then the temp JS files will be saved in
/tmp/emscripten_temp. Reading the last JS one around the line it has the
syntax error on might give a clue.

On Mon, Nov 28, 2022 at 10:31 AM Gregory Propf  wrote:

> Anyone know what this is about? I'm trying out various optimization
> options and discovered that if I use -O1 or -O0 the code compiles but -O2,
> -O3, -Os gives this error. It doesn't seem like DEMANGLE_SUPPORT is the
> issue since taking that out doesn't change anything. This is using 3.1.24
> on Linux. It looks like 3.1.26 is out. Would upgrading help?
>
>
> DEMANGLE_SUPPORT=1 emcc speedtest.cpp -o speedtest.o -c -O2 -std=c++17 -D
> USETF=1
> DEMANGLE_SUPPORT=1 emcc ClarityNode.cpp -o ClarityNode.o -c -O2 -std=c++17
> -D USETF=1
> DEMANGLE_SUPPORT=1 emcc Selectables.cpp -o Selectables.o -c -O2 -std=c++17
> -D USETF=1
> DEMANGLE_SUPPORT=1 emcc clarity.cpp -o clarity.o -c -O2 -std=c++17 -D
> USETF=1
> emcc -lembind --pre-js js.d/speedtest.js speedtest.o ClarityNode.o
> Selectables.o clarity.o -O2 -std=c++17 -o clarity_embind.js
>
> /home/greg/repos/clarity/emsdk/upstream/emscripten/tools/acorn-optimizer.js:1863
>   throw err;
>   ^
>
> SyntaxError: Unexpected token (61:22)
> staticSpeedtester = null;
>   ^
>
> at Parser.pp$4.raise
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:3462:15)
> at Parser.pp$9.unexpected
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:756:10)
> at Parser.pp$9.expect
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:750:28)
> at Parser.pp$5.parseMethod
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:3224:10)
> at Parser.pp$8.parseClassMethod
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:1511:37)
> at Parser.pp$8.parseClassElement
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:1469:12)
> at Parser.pp$8.parseClass
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:1387:26)
> at Parser.pp$8.parseStatement
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:902:19)
> at Parser.pp$8.parseTopLevel
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:813:23)
> at Parser.parse
> (/home/greg/repos/clarity/emsdk/upstream/emscripten/node_modules/acorn/dist/acorn.js:585:17)
> {
>   pos: 1941,
>   loc: Position { line: 61, column: 22 },
>   raisedAt: 1942
> }
> emcc: error: '/home/greg/repos/clarity/emsdk/node/14.18.2_64bit/bin/node
> /home/greg/repos/clarity/emsdk/upstream/emscripten/tools/acorn-optimizer.js
> /tmp/emscripten_temp_i786_vs2/clarity_embind.js.pp.js JSDCE
> minifyWhitespace -o
> /tmp/emscripten_temp_i786_vs2/clarity_embind.js.pp.jso1.js' failed
> (returned 1)
> make: *** [Makefile:27: speedtest-prod] Error 1
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKdUWHOskXRExLeutqdyxBZ3OffSzVAjLWaL2p%2BYa%2BETOfTnLA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQeTWfaNm38jSvKwfyR4x_a%2BHbtiELvbJrh%2BAHj3Qcrkw%40mail.gmail.com.

Re: wasm-opt is extremely slow

[Alon Zakai]

First thing, I would try -O2 and -Os. They can be much faster than -O3 and
-Oz.

Otherwise, 10-12 minutes sounds extreme even for 12MB, so this is likely
hitting an unknown bad case. If you can run a system profiler on it that
might show something useful. You can also run with BINARYEN_PASS_DEBUG=1 in
the env, which will list times of passes - perhaps one particular pass will
be slowest.

On Mon, Nov 21, 2022 at 11:19 AM Александр Гурьянов 
wrote:

> Hi, I added dosbox-x as backend for js-dos it's size is ~12Mb, wasm-opt
> requires 10-12 min to optimize it (-Oz). Do you have any advice how to
> speed up it? If I build with -O0/1 I have following error in chrome:
>
>
> ‣
> 
>
> CompileError: WebAssembly.compile(): Compiling function 
> #6485:"CPU_Core_Normal_Run()" failed: local count too large @+4790225
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVH02jeZ70pHAe%2BvTL26ScOato8r7b_UBW_V34mJvGwt_Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRWo88FyDPWU3eF%3DH_ze8owRu2EgNpptYvKmFD6FHgoVg%40mail.gmail.com.

Re: Questions regarding copyright and license of with emscripten compiled code

[Alon Zakai]

On Mon, Apr 25, 2022 at 1:51 AM 'paw' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Hello everyone,
>
> At my work, we create a tool which runs in the Web Browser but uses native
> components. These are compiled with emscripten to *asm.js* (we plan to
> transition to wasm in the future).
>
> As a company we want to provide the as correct as possible list of our
> used open source software and respect the licenses as well as the
> copyrights.
>
> Therefore we want to add the necessary information that we use the code
> which is compiled with emscripten. We do not and are currently not planning
> to ship emscripten, therefore we are at the moment only interested in the
> code emitted by emscripten. Therefore I have these questions:
>

I'll try to answer these as best I can. I am not a lawyer, to be clear, but
I am the creator of Emscripten and I am the one that chose the license for
the project back in 2010.

Before getting to specific answers, the bottom line to all of this is that
I chose the MIT license for Emscripten, and only picked
similarly-permissively-licensed projects to bundle like musl and LLVM
libraries, because my goal was for licensing to not ever be a problem for
users. So my hope is that for you, and anyone else, licensing causes no
issues.


>
>
>1. Under which license and copyright is the from emscripten generated
>code?
>
> First, note that Emscripten itself is under the MIT license,

https://github.com/emscripten-core/emscripten/blob/main/LICENSE

(and also the NCSA open source license, but that is for historical reasons
and does not matter here). When you use Emscripten to generate code, some
parts of Emscripten may appear in the generated code, like snippets of JS
library logic, etc. The MIT license says this:

"The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software."

I have never considered the generated code to contain a "substantial
portion" of Emscripten (it's just small snippets compared to all of
Emscripten, and they are modified and combined with user code during
compilation anyhow, etc.). So I have never expected people to keep a
copyright notice around, like Floh was saying. From my point of view, the
point of Emscripten is to be a tool that is as easy to use as possible, and
in particular that does not require a copyright notice in every compiler
output or any other burden. That is, the compiler has an open source
license, but when the user creates an output, I didn't want to place any
requirements on that output. For that reason I chose MIT.

>
>1. As far as I know, there are JavaScript / Browser implementations of
>libc in order to be able to execute code which uses these APIs. Under which
>license and copyright is this code? Is there a specific source code folder
>which holds this implementation so that I can focus my intention on this
>particular folder?
>
> Emscripten uses the musl libc (MIT licensed, see
https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/COPYRIGHT).
The JS side of the libc and other API support is Emscripten's JS library
logic, which was mentioned before (all that is under src/library_*.js).

>
>1. Is there a difference regarding emitting asm.js and WASM in the
>context of license and copyright? (there is obviously a technical
>difference, but I am not interested in this at the moment)
>
> As a non-lawyer I can't really say, but as the person that chose the
license, I would hope there is no difference between asm.js and wasm in
anything here... :)

>
>1. Is in the generated code anything which was copied or otherwise
>added which orignally stems from another open source software? What comes
>to my mind are things like polyfills which could be generated into the code
>in order "to make things work" etc.. (I am aware of emscripten ports and we
>specifically use FreeType, Harfbuzz and ICU. But is there more than that).
>
> Aside from the musl libc there are a few LLVM libraries used like libc++,
libc++abi, and compiler-rt. Those are necessary to build a full toolchain.
All use the LLVM standard license (Apache 2 + LLVM exception), e.g.
https://github.com/emscripten-core/emscripten/blob/main/system/lib/libcxx/LICENSE.TXT

Doing a search in src/ for copyright (and filtering out Emscripten's) I see
that the Promise polyfill has a license text (
https://github.com/emscripten-core/emscripten/blob/main/src/polyfill/promise.js)
but that is not included normally (only to polyfill for old browsers, if a
setting is set for that). It is also MIT just like Emscripten.

- Alon

Thank you very much in advance for your answers.
>
> Best regards,
>
> paw
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: Problem with EM_JS() in mixed zig/emcc project.

[Alon Zakai]

There is now this Zig issue for emscripten discussion, more details might
make sense to add there, if any,

https://github.com/ziglang/zig/issues/10836

On Tue, Feb 1, 2022 at 3:44 AM Floh  wrote:

> > Btw, did you get a chance to file a Zig ticket as you said?
>
> Haven't done that yet!
>
> On Monday, 31 January 2022 at 18:51:07 UTC+1 alon...@gmail.com wrote:
>
>> Nice, good to see pacman working!
>>
>> Btw, did you get a chance to file a Zig ticket as you said?
>>
>>
>> On Mon, Jan 31, 2022 at 1:53 AM Floh  wrote:
>>
>>> PS: the missing __stack_chk_* symbol errors I mentioned formerly are
>>> unrelated to the target triple, but instead happen when compiling via Zig
>>> in debug mode. In that case, Zig compiles the C code with clang's
>>> "-fstack-protector-strong" which requires two externally defined symbols, a
>>> guard-value and a function which is called when the stack protection
>>> triggers. When linking with emcc those symbols can't be found, so I just
>>> provided them myself in the C stub here:
>>>
>>> https://github.com/floooh/pacman.zig/blob/main/src/emscripten/entry.c
>>>
>>> On Sunday, 30 January 2022 at 17:56:32 UTC+1 Floh wrote:
>>>
 Ok, here's the result:

 https://floooh.github.io/pacman.zig/pacman.html

 Build instructions:

 https://github.com/floooh/pacman.zig#experimental-web-support

 ...and a quick explanation how it works, and what workarounds are
 currently required (and below that is the actual build function):


 https://github.com/floooh/pacman.zig/blob/549a73ecd6f5c9bfe4f8150b08e4b43f02eae331/build.zig#L44-L61

 ...disclaimer: I'm not yet very familiar with the Zig build system
 which doesn't really support injecting a different linker, but that's the
 cleanest I came up with.

 Cheers and thanks for the help :)
 -Floh.

 On Sunday, 30 January 2022 at 01:16:44 UTC+1 s...@google.com wrote:

> I'm pretty sure EMSCRIPTEN_KEEPALIVE won't have the intended behaviour
> of actually exporting symbols when compiled with non-emscripten triples.
>
> On Sat, Jan 29, 2022 at 4:08 PM Floh  wrote:
>
>> Thanks for the thorough explanation Sam! Regarding this PR:
>> https://github.com/emscripten-core/emscripten/pull/16149, as far as
>> I have seen, only the EM_JS() macros caused trouble (with a 
>> non-emscripten
>> triple), I haven't seen any linker warnings regarding 
>> EMSCRIPTEN_KEEPALIVE
>> functions (which I'm using too in the same code base).
>>
>> I'll try to bring the current workaround (use wasm32-emscripten just
>> for the C code with the EM_JS macros, and wasm32-freestanding for the Zig
>> code), into a better shape tomorrow and then will most likely write a Zig
>> ticket, I think the Zig stdlib needs a few fixes for wasm32-emscripten 
>> (if
>> just some empty stubs), so that a complete project can be compiled with
>> this triple.
>>
>> Cheers!
>> -Floh.
>>
>> On Saturday, 29 January 2022 at 20:47:24 UTC+1 s...@google.com wrote:
>>
>>> Short term fix/wrokaround is here:
>>> https://github.com/emscripten-core/emscripten/pull/16149
>>>
>>> On Sat, Jan 29, 2022 at 11:32 AM Sam Clegg  wrote:
>>>
 The undefined symbol error you are seeing here is coming from the
 post-linking phase.  The way EM_JS works is that the function is that
 function `foo` declared as external using
 `__attribute__((import_name("foo")))` and the data symbol 
 `__em_js_foo` is
 defined in the data section along with `__attribute__((used,
 visibility("default")))`.For more details on this see
 https://github.com/emscripten-core/emscripten/blob/main/system/include/emscripten/em_js.h#L23-L49
 .

 I believe the problem you are seeing stems from the different
 meaning of `__attribute__((used))` under emscripten compared to with
 triples.The problem stems from the fact that we use
 `__attribute__((used))` to implement the EMSCRIPTEN_KEEPALIVE macro, 
 which
 is defined to mean "keep this symbol alive *and* export it to JS under 
 its
 symbol name".

 If you use wasm-objdump to look at an object file containing EM_JS
 symbols you will see them marked as both "no_strip" and "exported".  
 For
 example:

 ```
   - 38: D <__em_js__noarg> segment=0 offset=0 size=36 [ exported
 no_strip binding=global vis=default ]
   - 39: D <__em_js__noarg_int> segment=0 offset=36 size=55 [
 exported no_strip binding=global vis=default ]
   - 40: D <__em_js__noarg_double> segment=0 offset=91 size=61 [
 exported no_strip binding=global vis=default ]
   - 41: D <__em_js__intarg> segment=0 offset=152 size=41 [ exported
 no_strip binding=global vis=default ]

Re: Emscripten SDK and WASI filesystem access

[Alon Zakai]

I see... yeah, mixing and matching object files from different toolchains
is not guaranteed to work. They need C ABI compatibility, I'm afraid.

It is a little sad to need separate runtimes, though, so I hope we can find
a way to avoid that for you. What is the specific code that would be
different between the two runtimes?

On Thu, Feb 10, 2022 at 5:23 AM yowl yowlxx  wrote:

> " (Of course, header constants *can* be an issue if you link wasm object
> files together that were built using different SDKs or even different
> versions of the same SDK.)"
>
> Yes, that is what I naively tried to do.  The CoreCLR runtime is compiled
> using emscripten's SDK, but I wanted to link it with the WASI SDK libc++ to
> get file open support.  What I'll probably have to do in the long run is
> have two CoreCLR runtimes, one for Emscripten and one for WASI SDK.
>
> On Mon, 7 Feb 2022 at 14:39, Alon Zakai  wrote:
>
>> Header constants like O_CREAT should not be a problem between wasm and
>> the host. WASI defines a very clear API between wasm and the runtime, and
>> those constants are not part of it. That is, "wasi-sdk host" is a confusing
>> way to put it: there are VMs with WASI support, but they are not tied to
>> the wasi-sdk toolchain, which is just one toolchain that emits WASI.
>>
>> (Of course, header constants *can* be an issue if you link wasm object
>> files together that were built using different SDKs or even different
>> versions of the same SDK.)
>>
>> Emscripten could add more complete WASI support, if that were useful -
>> it's just a matter of implementing the APIs. PRs would be welcome!
>>
>>
>>
>> On Sat, Feb 5, 2022 at 9:59 AM scot...@gmail.com 
>> wrote:
>>
>>> My own observations mixing Emscripten and WASI-SDK are that some
>>> constants, e.g. `O_CREAT` are different in Emscripten (0x64) to Wasi-SDK
>>> (0x1000).  Allowing emscripten to build something that would run under
>>> a wasi-sdk host, like wasmtime, is tricky - I think.
>>>
>>> On Friday, December 17, 2021 at 8:01:14 AM UTC-5 Floh wrote:
>>>
>>>> Ah alright, that toolchain file looks a lot simpler (it's under
>>>> "share/cmake" in the SDK download). I'll use that as base for my own cmake
>>>> toolchain file instead. Thanks!
>>>>
>>>> On Thursday, 16 December 2021 at 21:18:46 UTC+1 s...@google.com wrote:
>>>>
>>>>> On Thu, Dec 16, 2021 at 5:53 AM Floh  wrote:
>>>>>
>>>>>> > Unless you plan to run those tools on the web then I think wasi-sdk
>>>>>> is most likely the way to go.   How do you plan to run the binaries BTW?
>>>>>>
>>>>>> Currently I'm using wasmtime.
>>>>>>
>>>>>> I was actually successful to build my shader compiler through
>>>>>> wasi-sdk, and run it through wasmtime, the file system access worked as
>>>>>> expected.
>>>>>>
>>>>>> Installing the wasi-sdk is just downloading and unpacking somewhere
>>>>>> (e.g. no env-variables or search path updating needed), and then I 
>>>>>> created
>>>>>> a cmake toolchain file which looks a lot like my Emscripten toolchain 
>>>>>> file,
>>>>>> but with all the Emscripten-specific parts removed:
>>>>>>
>>>>>>
>>>>>> https://github.com/floooh/fips/blob/master/cmake-toolchains/wasisdk.toolchain.cmake
>>>>>>
>>>>>
>>>>> FYI wasi-sdk includes a cmake toolchain fail upstream:
>>>>> https://github.com/WebAssembly/wasi-sdk/blob/main/wasi-sdk.cmake
>>>>>
>>>>> Maybe we forgot to include it in the download?   But it should be
>>>>> usable I think.
>>>>>
>>>>>
>>>>>> The only problem (vs the Emscripten SDK) was that the wasi-sdk
>>>>>> doesn't come with pthread headers/stubs, so I had to tinker a bit with 
>>>>>> the
>>>>>> glslangValidator source code (which for some reason needs thread-local 
>>>>>> data
>>>>>> and mutexes, but then doesn't actually spawn any threads).
>>>>>>
>>>>>> The popen() calls (to run native Metal or D3D shader compiler
>>>>>> executables) simply seem to fail at runtime (which I'm already handling 
>>>>>> in
>>>>>> my code).
>>>>>>
>>>>>> All in all

Re: Rust journey

[Alon Zakai]

I understand now, thanks!

On Sun, Feb 6, 2022 at 7:49 AM Александр Гурьянов 
wrote:

> It's because I don't use glfw from rust. In my case I used c/c++ glfw +
> wgpu-native (from rust).
>
> https://github.com/gfx-rs/wgpu-native/blob/f7d731e7fd2a233d550c58ebac54cabfe416a6cb/examples/triangle/main.c
>
> So when I say sdl/glfw + wgpu-native, I mean that I will use c/c++
> sdl/glfw for windows/events and wgpu-native for graphics.
>
> сб, 5 февр. 2022 г. в 00:31, Alon Zakai :
>
>> Wow, great that you got all that working!
>>
>> I'm also interested in SDL/glfw. I was trying to get glfw working with
>> emscripten/rust and hit several problems, so I'm curious how you got it to
>> work. I filed this issue with my problems:
>>
>> https://github.com/PistonDevelopers/glfw-rs/issues/495
>>
>> https://github.com/PistonDevelopers/glfw-rs/issues/495
>>
>> On Fri, Feb 4, 2022 at 2:46 AM Александр Гурьянов 
>> wrote:
>>
>>> Did it! Also I added support for emscripten in wgpu/wgpu-native, and
>>> soon it will be possible to use it with SDL/gflw. Want to add tutorial
>>> about it.
>>>
>>> This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
>>>
>>> https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72
>>>
>>> чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com>:
>>>
>>>> Ah sorry, I see you tried and said it doesn't work even with `extern
>>>> "C"` in the issue description. That's odd, it definitely should.
>>>>
>>>> On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
>>>> wrote:
>>>>
>>>>> But it's not a bug. As I said, you just need to add "C" to your
>>>>> `extern`, because right now you're exposing it from Rust via C FFI, but
>>>>> declaring it as a C++ symbol on the other side.
>>>>>
>>>>> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
>>>>> wrote:
>>>>>
>>>>>> Filled this bug:
>>>>>> https://github.com/emscripten-core/emscripten/issues/16123
>>>>>>
>>>>>> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via
>>>>>> emscripten-discuss :
>>>>>>
>>>>>>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++
>>>>>>> side, otherwise normal mangling rules apply and it's looking up (or, 
>>>>>>> this
>>>>>>> case, declaring) a namespaced variable.
>>>>>>>
>>>>>>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>>>>>>
>>>>>>>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer
>>>>>>>> to a rust variable?  Does that address of `rv_api_1` on the C side look
>>>>>>>> correct?
>>>>>>>>
>>>>>>>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>>>>>>>> initializer function or is it simply static memory (like it would be in
>>>>>>>> C/C++)?
>>>>>>>>
>>>>>>>> Assuming it is generating a ctor then there are a couple of things
>>>>>>>> that could be going on.   Are you sure your static ctors have been run?
>>>>>>>> i.e. where is your code running?  Is it inside of main?
>>>>>>>>  Disassembling your final binary should show all static ctors being 
>>>>>>>> called
>>>>>>>> from the `__wasm_call_ctors` function.
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> sam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <
>>>>>>>> caii...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Okay, I think I almost did the same in Rust what Alon described.
>>>>>>>>> vanger-rs now compiles as static library (.a) with emscripten triple. 
>>>>>>>>> I use
>>>>>>>>> this static library to link with original C++ game. So I have *.o 
>>>>>>>>> files
>>>>>>>>> from vangers, and librusty_vangers.a (which provides rendering on 
>>&g

Re: Emscripten SDK and WASI filesystem access

[Alon Zakai]

Header constants like O_CREAT should not be a problem between wasm and the
host. WASI defines a very clear API between wasm and the runtime, and those
constants are not part of it. That is, "wasi-sdk host" is a confusing way
to put it: there are VMs with WASI support, but they are not tied to the
wasi-sdk toolchain, which is just one toolchain that emits WASI.

(Of course, header constants *can* be an issue if you link wasm object
files together that were built using different SDKs or even different
versions of the same SDK.)

Emscripten could add more complete WASI support, if that were useful - it's
just a matter of implementing the APIs. PRs would be welcome!



On Sat, Feb 5, 2022 at 9:59 AM scot...@gmail.com 
wrote:

> My own observations mixing Emscripten and WASI-SDK are that some
> constants, e.g. `O_CREAT` are different in Emscripten (0x64) to Wasi-SDK
> (0x1000).  Allowing emscripten to build something that would run under
> a wasi-sdk host, like wasmtime, is tricky - I think.
>
> On Friday, December 17, 2021 at 8:01:14 AM UTC-5 Floh wrote:
>
>> Ah alright, that toolchain file looks a lot simpler (it's under
>> "share/cmake" in the SDK download). I'll use that as base for my own cmake
>> toolchain file instead. Thanks!
>>
>> On Thursday, 16 December 2021 at 21:18:46 UTC+1 s...@google.com wrote:
>>
>>> On Thu, Dec 16, 2021 at 5:53 AM Floh  wrote:
>>>
 > Unless you plan to run those tools on the web then I think wasi-sdk
 is most likely the way to go.   How do you plan to run the binaries BTW?

 Currently I'm using wasmtime.

 I was actually successful to build my shader compiler through wasi-sdk,
 and run it through wasmtime, the file system access worked as expected.

 Installing the wasi-sdk is just downloading and unpacking somewhere
 (e.g. no env-variables or search path updating needed), and then I created
 a cmake toolchain file which looks a lot like my Emscripten toolchain file,
 but with all the Emscripten-specific parts removed:


 https://github.com/floooh/fips/blob/master/cmake-toolchains/wasisdk.toolchain.cmake

>>>
>>> FYI wasi-sdk includes a cmake toolchain fail upstream:
>>> https://github.com/WebAssembly/wasi-sdk/blob/main/wasi-sdk.cmake
>>>
>>> Maybe we forgot to include it in the download?   But it should be usable
>>> I think.
>>>
>>>
 The only problem (vs the Emscripten SDK) was that the wasi-sdk doesn't
 come with pthread headers/stubs, so I had to tinker a bit with the
 glslangValidator source code (which for some reason needs thread-local data
 and mutexes, but then doesn't actually spawn any threads).

 The popen() calls (to run native Metal or D3D shader compiler
 executables) simply seem to fail at runtime (which I'm already handling in
 my code).

 All in all pretty smooth sailing, at the moment it's just an experiment
 though, but a promising one :)


 On Tuesday, 14 December 2021 at 23:41:10 UTC+1 s...@google.com wrote:

> On Tue, Dec 14, 2021 at 9:28 AM Floh  wrote:
>
>> Oki doki, thanks for the clarification. I just wanted to check if I'm
>> missing something, using the wasi-sdk makes sense in that case.
>>
>> Maybe my use case helps a bit to prioritize "proper" WASI support a
>> bit :)
>>
>> I basically want to replace native command line tools (in my case: a
>> shader compiler built out of the the Khronos GLSL compiler, SPIRVTools 
>> and
>> SPIRVCross) with a WASI version, because right now I need to build this
>> tool in 4 variants (Windows x86_64, Linux x86_64, macOS x86_64 and macOS
>> arm64) and then "distribute" the binaries through a git repository. My 
>> plan
>> is to replace this with a single WASI binary (building on the target
>> machine is also not an option because these are complex C++ dependencies
>> which can take up to 15 minutes to build).
>>
>
> Unless you plan to run those tools on the web then I think wasi-sdk is
> most likely the way to go.   How do you plan to run the binaries BTW?
>
>
>>
>> One missing piece in the WASI API is popen() support though. The
>> shader compiler optionally needs to run the proprietaty D3D and Metal
>> shader compilers to generate shader binary blobs. Not sure yet how I'll
>> tackle that eventually, but a WASI executable which just generates shader
>> source code (not binary blobs) would be a good start nonetheless.
>>
>> Cheers!
>> -Floh.
>>
>> On Tuesday, 14 December 2021 at 17:43:10 UTC+1 s...@google.com wrote:
>>
>>> The standalone/wasi support in emscripten is very basic and doesn't
>>> have full fileystem support yet.   I would certainly recommend using
>>> wasi-sdk if you want to run something on wasmtime.
>>>
>>> If I ever get around to landing this PR then a lot more of the FS
>>> stuff might start working:

Re: Rust journey

[Alon Zakai]

Wow, great that you got all that working!

I'm also interested in SDL/glfw. I was trying to get glfw working with
emscripten/rust and hit several problems, so I'm curious how you got it to
work. I filed this issue with my problems:

https://github.com/PistonDevelopers/glfw-rs/issues/495

https://github.com/PistonDevelopers/glfw-rs/issues/495

On Fri, Feb 4, 2022 at 2:46 AM Александр Гурьянов 
wrote:

> Did it! Also I added support for emscripten in wgpu/wgpu-native, and soon
> it will be possible to use it with SDL/gflw. Want to add tutorial about it.
>
> This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
>
> https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72
>
> чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Ah sorry, I see you tried and said it doesn't work even with `extern "C"`
>> in the issue description. That's odd, it definitely should.
>>
>> On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
>> wrote:
>>
>>> But it's not a bug. As I said, you just need to add "C" to your
>>> `extern`, because right now you're exposing it from Rust via C FFI, but
>>> declaring it as a C++ symbol on the other side.
>>>
>>> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
>>> wrote:
>>>
>>>> Filled this bug:
>>>> https://github.com/emscripten-core/emscripten/issues/16123
>>>>
>>>> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
>>>> emscripten-discuss@googlegroups.com>:
>>>>
>>>>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++
>>>>> side, otherwise normal mangling rules apply and it's looking up (or, this
>>>>> case, declaring) a namespaced variable.
>>>>>
>>>>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>>>>
>>>>>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to
>>>>>> a rust variable?  Does that address of `rv_api_1` on the C side look
>>>>>> correct?
>>>>>>
>>>>>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>>>>>> initializer function or is it simply static memory (like it would be in
>>>>>> C/C++)?
>>>>>>
>>>>>> Assuming it is generating a ctor then there are a couple of things
>>>>>> that could be going on.   Are you sure your static ctors have been run?
>>>>>> i.e. where is your code running?  Is it inside of main?
>>>>>>  Disassembling your final binary should show all static ctors being 
>>>>>> called
>>>>>> from the `__wasm_call_ctors` function.
>>>>>>
>>>>>> cheers,
>>>>>> sam
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <
>>>>>> caii...@gmail.com> wrote:
>>>>>>
>>>>>>> Okay, I think I almost did the same in Rust what Alon described.
>>>>>>> vanger-rs now compiles as static library (.a) with emscripten triple. I 
>>>>>>> use
>>>>>>> this static library to link with original C++ game. So I have *.o files
>>>>>>> from vangers, and librusty_vangers.a (which provides rendering on 
>>>>>>> wgpu). I
>>>>>>> link them with emcc, and it produce wasm  without any error!
>>>>>>>
>>>>>>> Also I do the same with native build - it works fine.
>>>>>>>
>>>>>>> However, when I tries to run it fails with assertion.
>>>>>>>
>>>>>>> On RUST side I have the following code:
>>>>>>> #[no_mangle]
>>>>>>> pub static rv_api_1: i32 = 1;
>>>>>>>
>>>>>>> On C++ side I have the following code:
>>>>>>> extern int32_t rv_api_1;
>>>>>>> // ...
>>>>>>> if(rv_api_1 != 1){
>>>>>>> printf("Invalid libvangers_ffi version expected 1, actual
>>>>>>> %d\n", rv_api_1);
>>>>>>> // abort();
>>>>>>> }
>>>>>>>
>>>>>>> When I run it, I have following output:
>>>>>>> Invalid libvangers_f

Re: Problem with EM_JS() in mixed zig/emcc project.

[Alon Zakai]

Nice, good to see pacman working!

Btw, did you get a chance to file a Zig ticket as you said?


On Mon, Jan 31, 2022 at 1:53 AM Floh  wrote:

> PS: the missing __stack_chk_* symbol errors I mentioned formerly are
> unrelated to the target triple, but instead happen when compiling via Zig
> in debug mode. In that case, Zig compiles the C code with clang's
> "-fstack-protector-strong" which requires two externally defined symbols, a
> guard-value and a function which is called when the stack protection
> triggers. When linking with emcc those symbols can't be found, so I just
> provided them myself in the C stub here:
>
> https://github.com/floooh/pacman.zig/blob/main/src/emscripten/entry.c
>
> On Sunday, 30 January 2022 at 17:56:32 UTC+1 Floh wrote:
>
>> Ok, here's the result:
>>
>> https://floooh.github.io/pacman.zig/pacman.html
>>
>> Build instructions:
>>
>> https://github.com/floooh/pacman.zig#experimental-web-support
>>
>> ...and a quick explanation how it works, and what workarounds are
>> currently required (and below that is the actual build function):
>>
>>
>> https://github.com/floooh/pacman.zig/blob/549a73ecd6f5c9bfe4f8150b08e4b43f02eae331/build.zig#L44-L61
>>
>> ...disclaimer: I'm not yet very familiar with the Zig build system which
>> doesn't really support injecting a different linker, but that's the
>> cleanest I came up with.
>>
>> Cheers and thanks for the help :)
>> -Floh.
>>
>> On Sunday, 30 January 2022 at 01:16:44 UTC+1 s...@google.com wrote:
>>
>>> I'm pretty sure EMSCRIPTEN_KEEPALIVE won't have the intended behaviour
>>> of actually exporting symbols when compiled with non-emscripten triples.
>>>
>>> On Sat, Jan 29, 2022 at 4:08 PM Floh  wrote:
>>>
 Thanks for the thorough explanation Sam! Regarding this PR:
 https://github.com/emscripten-core/emscripten/pull/16149, as far as I
 have seen, only the EM_JS() macros caused trouble (with a non-emscripten
 triple), I haven't seen any linker warnings regarding EMSCRIPTEN_KEEPALIVE
 functions (which I'm using too in the same code base).

 I'll try to bring the current workaround (use wasm32-emscripten just
 for the C code with the EM_JS macros, and wasm32-freestanding for the Zig
 code), into a better shape tomorrow and then will most likely write a Zig
 ticket, I think the Zig stdlib needs a few fixes for wasm32-emscripten (if
 just some empty stubs), so that a complete project can be compiled with
 this triple.

 Cheers!
 -Floh.

 On Saturday, 29 January 2022 at 20:47:24 UTC+1 s...@google.com wrote:

> Short term fix/wrokaround is here:
> https://github.com/emscripten-core/emscripten/pull/16149
>
> On Sat, Jan 29, 2022 at 11:32 AM Sam Clegg  wrote:
>
>> The undefined symbol error you are seeing here is coming from the
>> post-linking phase.  The way EM_JS works is that the function is that
>> function `foo` declared as external using
>> `__attribute__((import_name("foo")))` and the data symbol `__em_js_foo` 
>> is
>> defined in the data section along with `__attribute__((used,
>> visibility("default")))`.For more details on this see
>> https://github.com/emscripten-core/emscripten/blob/main/system/include/emscripten/em_js.h#L23-L49
>> .
>>
>> I believe the problem you are seeing stems from the different meaning
>> of `__attribute__((used))` under emscripten compared to with triples.
>> The problem stems from the fact that we use `__attribute__((used))` to
>> implement the EMSCRIPTEN_KEEPALIVE macro, which is defined to mean "keep
>> this symbol alive *and* export it to JS under its symbol name".
>>
>> If you use wasm-objdump to look at an object file containing EM_JS
>> symbols you will see them marked as both "no_strip" and "exported".  For
>> example:
>>
>> ```
>>   - 38: D <__em_js__noarg> segment=0 offset=0 size=36 [ exported
>> no_strip binding=global vis=default ]
>>   - 39: D <__em_js__noarg_int> segment=0 offset=36 size=55 [ exported
>> no_strip binding=global vis=default ]
>>   - 40: D <__em_js__noarg_double> segment=0 offset=91 size=61 [
>> exported no_strip binding=global vis=default ]
>>   - 41: D <__em_js__intarg> segment=0 offset=152 size=41 [ exported
>> no_strip binding=global vis=default ]
>> ```
>>
>> If you compile the same source using a non-emscripten triple you will
>> see them only marked as `no_strip` which is a more traditional meaning of
>> the `used` attribute which simply tells the linker to keep them around in
>> the binary, not to export them.   Here is where the hack/difference is:
>> https://github.com/llvm/llvm-project/blob/333f5019300c6e56782374627e64da0b62ffa3bc/llvm/lib/MC/WasmObjectWriter.cpp#L1773-L1777
>>
>> There are two ways we can solve this issue I believe.
>>
>> 1. Long term solution: Stop abusing `__attribute__((used))`, and thus
>> 

Re: Problem with EM_JS() in mixed zig/emcc project.

[Alon Zakai]

Sam can confirm, but I would guess perhaps the emscripten triple is
necessary. That is, clang and/or wasm-ld might do something for EM_JS code
but only in emscripten mode.

If we can confirm that then we should definitely get a bug filed on Zig -
hopefully it would be easy to add support for the emscripten triple there
and open up a bunch of use cases...

On Sat, Jan 29, 2022 at 9:12 AM Floh  wrote:

> I'm currently tinkering with bringing one of my toy Zig projects to the
> web via
> Alon's nice gist here which uses emcc only for the linker step:
>
> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>
> ...and it *nearly* works except for code that uses EM_JS() macros.
>
> The project (https://github.com/floooh/pacman.zig) consists of some C
> code (my cross-platform 'sokol headers') which uses EM_JS() quite
> extensively (very handy for STB-style single-file libraries), and at the
> top, the "game code" is written in Zig.
>
> I'm compiling all code with Zig with the wasm32-wasi target
> (wasm32-emscripten exists, but currently doesn't seem to be supported by
> the Zig compiler), and then use emcc for linking.
>
> Long story short, it works except for the one problem that emcc cannot
> resolve any functions which have been defined with EM_JS(). If I compile
> the same library with emcc instead of Zig it works.
>
> So my question is: does emcc also do some "EM_JS() magic" when compiling
> the source code which contains EM_JS macros? Maybe I'm missing some Clang
> command line options which emcc inserts?
>
> The errors look like this:
>
> error: undefined symbol: sapp_js_add_clipboard_listener (referenced by
> top-level compiled C/C++ code)
>
> Followed by:
>
> warning: _sapp_js_add_clipboard_listener may need to be added to
> EXPORTED_FUNCTIONS if it arrives from a system library
> ...there's also a single warning about malloc:
>
> ...if I compile with "-s ERROR_ON_UNDEFINED_SYMBOLS=0", then the code
> breaks at runtime failing to resolve those EM_JS() functions, e.g.:
>
> "missing function: sapp_js_pointer_init"
>
> Compiling the same static link library with emcc, it magically works.
>
> If I look at both libraries with nm I don't see much of a difference, e.g.
> here's the relevant parts from the emcc-compiled library, every EM_JS
> symbol has an "D __em_js..." entry, and a matching "U sapp_js..." entry,
> e.g.:
>
> 185f D __em_js__sapp_js_add_beforeunload_listener
> ...
> U sapp_js_add_beforeunload_listener
> ...
>
> The Zig-compiled library has the same entries:
>
> 1841 D __em_js__sapp_js_add_beforeunload_listener
> ...
> U sapp_js_add_beforeunload_listener
> ...
>
> ...yet one library (the zig-compiled) produces linker errors for those
> symbols, and the other (emcc-compiled) works.
>
> Clearly I'm missing something. I was expecting that all the EM_JS() magic
> is in the linker (by extracting the __em_js_* Javascript source code
> strings, and then "somehow" providing the C function import). Any ideas
> what I'm missing?
>
> Thanks!
> -Floh.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/15129292-2f07-44d9-99a9-a27ac4721a0cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRi1esdNp91WFMiohMUjmxhzDF7YFqqfwpy%3DY7v-FuLHg%40mail.gmail.com.

Please test the new EVAL_CTORS

[Alon Zakai]

Hi everyone,

https://github.com/emscripten-core/emscripten/pull/16011

has landed, which "reboots" the old EVAL_CTOR option. Until now that option
has not been useful since we switched to the wasm backend, for several
reasons. But all those issues have now been fixed.

EVAL_CTORS basically tries to compile code at link time. If you have global
constructors that do pure computation, or even parts of main(), then doing
that work and then "snapshotting" the results (the state of wasm memory and
globals) into the wasm can save time during startup. It may also decrease
the wasm size, but it may also increase it depending on how many changes to
memory the code does.

More concretely, this will try to execute global constructors and main()
and it will keep going until it reaches something it can't eval, which is
typically a call to an import.

To test it, get the latest tip of tree build

emsdk install tot

and then during link try to add

-s EVAL_CTORS

Some logging will show up saying what it managed to eval, or where it
failed. If it managed to eval at least some things then you can see what
effect that has on code size and startup speed for your project.

If you try it out, let us know how it goes!

- Alon Zakai

P.S. See more details in that PR if you're curious.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRcTrORmEQOQKLOT%3DGnPBoZU6KpcBtApsk4wSegVaNF1A%40mail.gmail.com.

Re: Rust journey

[Alon Zakai]

On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
wrote:

> Let's look closer to my case. I ported C++ game Vangers to the web (
> https://www.gamepix.com/play/vangers). Vangers community did big work to
> integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
> works as follow:
> 1. Vange-rs provide c ffi interface
> 2. Vange-rs compiled with rust to static library
> 3. Vangers linked with Vanger-rs to executable
>
> Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't
> support wasm32-unknown-emscripten, I added experimental support for
> emscripten and it works. BUT, wgpu is developing to fast, so my changes
> become outdated very fast :)
>
> When I implement support for emscripten, I only disabling wasm32-unknown
> rules and uses native code paths everywhere. So, it's little bit strange,
> to work with emscripten you need to disable workarounds for wasm32.
> emscripten emulates native platform, so code that correctly uses posix
> system should work also in emscripten.
>
> Maybe there is any way to just use native static library and link it with
> emscripten? Like this:
> 1. Compile vange-rs static library (with native triple)
> 2. Compile vangers project with emscripten
> 3. Link 1+2 with emscripten
>
>
(1) would compile to x86, though, I think? We have to have wasm to link
with emscripten.


> for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32
> target, they select wrong code path (non-native).
>
>
Hmm, I don't know enough rust to know what fixing that would mean...

Overall for an emscripten port I think we would want to use a native build
as much as possible? That is, ideally you would *not* use vange-rs/WebGPU,
but one of the native rendering paths (OpenGL of some flavor? Or perhaps
they have Dawn/WebGPU support?). And you would need to tell rust to use the
emscripten triple while doing so.

That should work, in theory. If it doesn't and Rust has some issues with
how it invokes emcc to link, then the workaround could be what I mentioned
for Zig and C before: get Rust to link to a static library, and then run
emcc manually on that.

(Alternatively, in theory someone could look into supporting wasm-bindgen +
emscripten.)

- Alon


> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>
>> Thanks, good to know at least 2 people would read a post about this :)
>> I'll try to find time for it.
>>
>> About Rust, I haven't had time to look into it yet. My general hope is
>> that the same model as for C and Zig could work:
>>
>> 1. Tell Rust to use the emscripten wasm triple.
>> 2. Tell Rust to compile to object files (or a static library, basically),
>> and *not* to link them.
>> 3. The user runs emcc on those object files, linking them.
>>
>> The nice thing in this model is that C/Zig/Rust does not need to be aware
>> of emcc at all here (aside from telling LLVM to use the emscripten triple).
>> And it's easy to do this, at least in C and Zig (although there are some
>> subtle ABI questions).
>>
>> This is actually the main thing I wanted to do before writing the post -
>> ideally I'd have a Rust demo alongside C and Zig - so if someone figures
>> that out, let me know!
>>
>> - Alon
>>
>>
>> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
>> wrote:
>>
>>> +1 for blog post. Not clear how I can use it with rust, e.g. can I
>>> compile static lib with target --wasm32-unknown-unknown and then link using
>>> emscripten? The main problem with RUST is that it even can't compile with
>>> --wasm32-unknown-emscipten (because of lib dependencies that not support
>>> emscripten)
>>>
>>> чт, 13 янв. 2022 г. в 16:46, Floh :
>>>
>>>> That's a very useful gist, Alon! I think that blog post would be much
>>>> appreciated by a lot of people who like to tinker with other languages :)
>>>>
>>>> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com
>>>> wrote:
>>>>
>>>>> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>>>>>
>>>>>> Ah, language and toolchain interoperability, one of my favourite
>>>>>> topics ;)
>>>>>>
>>>>>> Zig has nearly the same problems as Rust: it allows to compile to
>>>>>> WASM, it has both a WASI and Emscripten target, with the WASI target
>>>>>> working out of the box, but I gave up on the Emscripten target because I
>>>>>> just couldn't get it to work.
>>>>>>
>>>>>
>>>>> I wrote up a demo of Zig + Emscripten here:
>>>>>
>>&g

Re: typescripten: Type-safe JavaScript interop with complex types

[Alon Zakai]

That sounds great!

- Alon

On Sat, Jan 15, 2022 at 1:03 AM Sebastian Theophil 
wrote:

>
> Am 12.01.2022 um 19:06 schrieb Alon Zakai :
>
> 
> I just have some general thoughts at this point. Curious to hear your
> ideas and other people's.
>
> Maybe a nice starting point would be to make it easier for people to
> experiment with typescripten, to get feedback. Could we add minimal
> integration on the emscripten side to allow that, just a new option perhaps
> (marked experimental), and that uses a module from npm? (Or does this need
> more things than can be packaged in npm?)
>
>
> Sounds good to me. More practical experience is certainly needed most at
> this point. I could package typescripten for npm. Practically all
> TypeScript interface files are on npm as well. Maybe it would be convenient
> to have a command line argument to specify which type definitions to pull.
>
>
> A thought I had is whether we could eventually replace embind with
> typescripten (or at least the part of embind that supports calls from C++
> to JS). That is, if the core "JS object" class in typescripten had the same
> API as embind vals do (for accessing things in a *non*-type-safe way, using
> strings). Do you think that could work? If we could replace parts of embind
> it would strengthen the case for upstreaming, I think.
>
>
> I could try that out. I think it should work. The base js object already
> aggregates emscripten::val anyway.
>
> I hope to have some time in the coming weeks to work on typescripten and
> will hopefully send a PR on GitHub.
>
> Regards
> Sebastian
>
>
> - Alon
>
>
> On Fri, Jan 7, 2022 at 6:01 AM Sebastian Theophil 
> wrote:
>
>> Hi Alon,
>>
>> thank you very much and it's great to hear that you find this
>> interesting. I would be very interested in integrating this with emscripten
>> of course. How should we start this process? There are probably a few
>> things that still need to be implemented for a good MVP, so to speak.
>>
>> Regards
>> Sebastian
>>
>> Am Do., 6. Jan. 2022 um 21:59 Uhr schrieb Alon Zakai > >:
>>
>>> Hi Sebastian,
>>>
>>> This is really nice! I watched your talk as well at CppCon (
>>> https://www.youtube.com/watch?v=CLuhogat6aY), very interesting.
>>>
>>> For a while it's seemed like we need something in this general area, so
>>> it's great to see it happen! I think this is a very good design, too (the
>>> performance issue with strings is the one concern I have, but as you say in
>>> the talk, that can be optimized - I'd use EM_JS for that probably).
>>>
>>> Did you have ideas about integrating this with upstream Emscripten? I
>>> think that might make sense to do, although maybe as part of a larger
>>> conversation on our bindings story (atm we have embind and the WebIDL
>>> binder, which already have some overlap).
>>>
>>> - Alon Zakai
>>>
>>> On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I wanted to plug my own project for some time here on the mailing list
>>>> because it also handles JavaScript - C++ interop and now wajic came up so I
>>>> thought I pitch in.
>>>>
>>>> My project https://github.com/think-cell/typescripten produces
>>>> type-safe C++ interfaces to JavaScript standard libraries or third-party
>>>> libraries. It reads TypeScript interface definition files and transforms
>>>> them into C++ shims based on emscripten.
>>>>
>>>> The resulting C++ code is often a straight-forward port from
>>>> TypeScript/JavaScript, e.g.,
>>>>
>>>> JavaScript:
>>>>
>>>> var elem = document.createElement("p")
>>>> elem.innerText = "Hello CppCon 2021"
>>>> elem.style.fontSize = "20.0"
>>>> document.body.appendChild(elem)
>>>>
>>>> C++:
>>>>
>>>> auto elem = js::document()->createElement(js::string("p"));
>>>> elem->innerText(js::string("Hello CppCon 2021"));
>>>> elem->style()->fontSize(js::string("20vh"));
>>>> js::document()->body()->appendChild(elem);
>>>>
>>>> No macros and the C++ functions return typed JavaScript objects!
>>>> Because we use the TypeScript interface definitions, the C++ code is
>>>> typechecked. Passing a number to fontSize will create a compiler error.
>>>>
>>>

Re: Rust journey

[Alon Zakai]

Thanks, good to know at least 2 people would read a post about this :) I'll
try to find time for it.

About Rust, I haven't had time to look into it yet. My general hope is that
the same model as for C and Zig could work:

1. Tell Rust to use the emscripten wasm triple.
2. Tell Rust to compile to object files (or a static library, basically),
and *not* to link them.
3. The user runs emcc on those object files, linking them.

The nice thing in this model is that C/Zig/Rust does not need to be aware
of emcc at all here (aside from telling LLVM to use the emscripten triple).
And it's easy to do this, at least in C and Zig (although there are some
subtle ABI questions).

This is actually the main thing I wanted to do before writing the post -
ideally I'd have a Rust demo alongside C and Zig - so if someone figures
that out, let me know!

- Alon


On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
wrote:

> +1 for blog post. Not clear how I can use it with rust, e.g. can I compile
> static lib with target --wasm32-unknown-unknown and then link using
> emscripten? The main problem with RUST is that it even can't compile with
> --wasm32-unknown-emscipten (because of lib dependencies that not support
> emscripten)
>
> чт, 13 янв. 2022 г. в 16:46, Floh :
>
>> That's a very useful gist, Alon! I think that blog post would be much
>> appreciated by a lot of people who like to tinker with other languages :)
>>
>> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:
>>
>>> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>>>
 Ah, language and toolchain interoperability, one of my favourite topics
 ;)

 Zig has nearly the same problems as Rust: it allows to compile to WASM,
 it has both a WASI and Emscripten target, with the WASI target working out
 of the box, but I gave up on the Emscripten target because I just couldn't
 get it to work.

>>>
>>> I wrote up a demo of Zig + Emscripten here:
>>>
>>> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>>>
>>> That uses GLES3 and Asyncify from Emscripten, so it's a small program
>>> but it uses interesting features.
>>>
>>> The gist also shows using C in the same way, where Emscripten is just
>>> the linker, not the frontend.
>>>
>>> I've been meaning to do the same with Rust and write a blogpost about
>>> all 3 but haven't found the time...
>>>
>>> - Alon
>>>
>>>
>>>

 IMHO it would be great if the Javascript shims and interop could be
 somehow split out of the Emscripten SDK into a separate, smaller
 "webapi-wasm-tools" SDK which could be better integrated with other
 language toolchains. The goal should be that other programming languages
 can benefit from the work that went into the Emscripten SDK to access web
 APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
 instead of having to duplicate this work, or requiring a separate
 installation of the whole Emscripten SDK.

 There's a very promising project https://github.com/schellingb/wajic
 by Bernhard Schelling which has the same goals and which was used to port
 Mattias Gustavsson's DOS-like library to the web:
 https://mattiasgustavsson.com/wasm/

 Anyway... just my 2 cents :)
 -Floh.
 On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:

> Hi! Just want to share my experiment with using Rust and WebAssembly.
> I tried to port Vange-rs project (rust + wgpu) to browser. I used
> emscripten and unknown platforms. Both finally works, but have lot of
> obstacles. I am very sad about support level of emscripten in Rust, hope 
> it
> will change at some day.
>
> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>
 --

>>> You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.

>>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/9e88b4b5-f110-4d90-a630-1c282a1febffn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the 

Re: Rust journey

[Alon Zakai]

On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:

> Ah, language and toolchain interoperability, one of my favourite topics ;)
>
> Zig has nearly the same problems as Rust: it allows to compile to WASM, it
> has both a WASI and Emscripten target, with the WASI target working out of
> the box, but I gave up on the Emscripten target because I just couldn't get
> it to work.
>

I wrote up a demo of Zig + Emscripten here:

https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3

That uses GLES3 and Asyncify from Emscripten, so it's a small program but
it uses interesting features.

The gist also shows using C in the same way, where Emscripten is just the
linker, not the frontend.

I've been meaning to do the same with Rust and write a blogpost about all 3
but haven't found the time...

- Alon



>
> IMHO it would be great if the Javascript shims and interop could be
> somehow split out of the Emscripten SDK into a separate, smaller
> "webapi-wasm-tools" SDK which could be better integrated with other
> language toolchains. The goal should be that other programming languages
> can benefit from the work that went into the Emscripten SDK to access web
> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
> instead of having to duplicate this work, or requiring a separate
> installation of the whole Emscripten SDK.
>
> There's a very promising project https://github.com/schellingb/wajic by
> Bernhard Schelling which has the same goals and which was used to port
> Mattias Gustavsson's DOS-like library to the web:
> https://mattiasgustavsson.com/wasm/
>
> Anyway... just my 2 cents :)
> -Floh.
> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>
>> Hi! Just want to share my experiment with using Rust and WebAssembly. I
>> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
>> and unknown platforms. Both finally works, but have lot of obstacles. I am
>> very sad about support level of emscripten in Rust, hope it will change at
>> some day.
>>
>> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRQVO9S_umhNE-0gu-E7LOz2O2HMxhNHnS9uiLFcC3GDg%40mail.gmail.com.

Re: Rust journey

[Alon Zakai]

Very interesting writeup, thanks!

It is sad that things don't work better here. The Emscripten side is
focused on C/C++ obviously and on native API support while the Rust side is
focused on either pure computation or on calling Web APIs. For something
like Vange-rs you really want native APIs + Rust, so neither side is really
enough.

I keep hoping that someone will have an important enough use case for them
to spend time on getting Emscripten+Rust working well, but so far that
hasn't come up. As more native apps get written in Rust though perhaps
eventually it will.

On Fri, Dec 24, 2021 at 6:16 AM Александр Гурьянов 
wrote:

> Hi! Just want to share my experiment with using Rust and WebAssembly. I
> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
> and unknown platforms. Both finally works, but have lot of obstacles. I am
> very sad about support level of emscripten in Rust, hope it will change at
> some day.
>
> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF2wUiuKH1%3DivMhfjuAFdtMwvHxc0YaS4V%2BGoGfBWuy6w%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSs7mNA%2B18XfW%3DndrgoVO0EeG2nESvB6C648xW7dRtf7w%40mail.gmail.com.

Re: typescripten: Type-safe JavaScript interop with complex types

[Alon Zakai]

I just have some general thoughts at this point. Curious to hear your ideas
and other people's.

Maybe a nice starting point would be to make it easier for people to
experiment with typescripten, to get feedback. Could we add minimal
integration on the emscripten side to allow that, just a new option perhaps
(marked experimental), and that uses a module from npm? (Or does this need
more things than can be packaged in npm?)

A thought I had is whether we could eventually replace embind with
typescripten (or at least the part of embind that supports calls from C++
to JS). That is, if the core "JS object" class in typescripten had the same
API as embind vals do (for accessing things in a *non*-type-safe way, using
strings). Do you think that could work? If we could replace parts of embind
it would strengthen the case for upstreaming, I think.

- Alon


On Fri, Jan 7, 2022 at 6:01 AM Sebastian Theophil 
wrote:

> Hi Alon,
>
> thank you very much and it's great to hear that you find this interesting.
> I would be very interested in integrating this with emscripten of course.
> How should we start this process? There are probably a few things that
> still need to be implemented for a good MVP, so to speak.
>
> Regards
> Sebastian
>
> Am Do., 6. Jan. 2022 um 21:59 Uhr schrieb Alon Zakai  >:
>
>> Hi Sebastian,
>>
>> This is really nice! I watched your talk as well at CppCon (
>> https://www.youtube.com/watch?v=CLuhogat6aY), very interesting.
>>
>> For a while it's seemed like we need something in this general area, so
>> it's great to see it happen! I think this is a very good design, too (the
>> performance issue with strings is the one concern I have, but as you say in
>> the talk, that can be optimized - I'd use EM_JS for that probably).
>>
>> Did you have ideas about integrating this with upstream Emscripten? I
>> think that might make sense to do, although maybe as part of a larger
>> conversation on our bindings story (atm we have embind and the WebIDL
>> binder, which already have some overlap).
>>
>> - Alon Zakai
>>
>> On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil 
>> wrote:
>>
>>> Hi,
>>>
>>> I wanted to plug my own project for some time here on the mailing list
>>> because it also handles JavaScript - C++ interop and now wajic came up so I
>>> thought I pitch in.
>>>
>>> My project https://github.com/think-cell/typescripten produces
>>> type-safe C++ interfaces to JavaScript standard libraries or third-party
>>> libraries. It reads TypeScript interface definition files and transforms
>>> them into C++ shims based on emscripten.
>>>
>>> The resulting C++ code is often a straight-forward port from
>>> TypeScript/JavaScript, e.g.,
>>>
>>> JavaScript:
>>>
>>> var elem = document.createElement("p")
>>> elem.innerText = "Hello CppCon 2021"
>>> elem.style.fontSize = "20.0"
>>> document.body.appendChild(elem)
>>>
>>> C++:
>>>
>>> auto elem = js::document()->createElement(js::string("p"));
>>> elem->innerText(js::string("Hello CppCon 2021"));
>>> elem->style()->fontSize(js::string("20vh"));
>>> js::document()->body()->appendChild(elem);
>>>
>>> No macros and the C++ functions return typed JavaScript objects! Because
>>> we use the TypeScript interface definitions, the C++ code is typechecked.
>>> Passing a number to fontSize will create a compiler error.
>>>
>>> The project is not yet meaningfully complete but it bootstraps
>>> successfully, i.e., the compiler understands the interface definition file
>>> for the TypeScript compiler and parser API that it uses itself. TypeScript
>>> generic constraints are not yet supported, for example, but should be.
>>>
>>> Maybe somebody else finds this useful. We have used it internally for a
>>> small web app already that needed to call the tableau.com JavaScript
>>> API.
>>>
>>> Regards
>>> Sebastian
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3DuddahRRPV02%3DT9TaQd2%3D3YzxqHDBAqg8%3DsWJL-Taqh4-SQ%40mail.gmail.com
>>> <https:/

Re: New LLVM 14 performance optimization

[Alon Zakai]

You can use bisection to find out exactly where a speedup came from,
basically the same as finding a regression,

https://emscripten.org/docs/contributing/developers_guide.html#bisecting

That would give you a single (and hopefully short) list of commits in a
single tool (LLVM or Binaryen, but not both).


On Tue, Jan 11, 2022 at 10:26 PM Soeren Balko  wrote:

> So I just installed the emsdk "top of tree" that comes with LLVM 14. Turns
> out that gives me some ~5% performance improvement in some workloads (HEVC
> decoding with FFmpeg, which was already hand-optimised to use WebAssembly
> SIMD intrinsics). Which is great - if only I knew where that's coming
> from...
>
> Specifically, what is not clear to me is the following:
>
> (1) Is the new load hoisting optimization automatically performed as part
> of LLVM/s LICM pass? That's probably more a question to the LLVM peeps and
> I assume that that's a "yes".
> (2) Does the "licm" pass in Binaryen's wasm-opt use LLVM's "licm" pass?
> (3) Does emcc -O3 already include wasm-opt's "licm" pass? I added -s
> BINARYEN_EXTRA_PASSES=licm, but that didn't seem to have an effect.
>
> I tried directly invoking LLVM's LICM optimisation by passing -mllvm -licm
> to emcc, but that makes emcc error out. Interestingly, -mllvm
> -enable-loop-versioning-licm does work, but seems to be an entirely
> different optimization altogether.
>
> Sadly, the interplay of emcc, clang, wasm-opt, and LLVM's opt utility
> isn't all too clear when it comes to non-standard clang/LLVM features...
>
> Soeren
>
> On Wednesday, December 8, 2021 at 3:25:48 AM UTC+10 alon...@gmail.com
> wrote:
>
>> Looks like that patch landed Dec 2, so it is already in the latest tip of
>> tree build of emscripten, which people can try with
>>
>> emsdk install tot
>>
>>
>>
>> On Tue, Dec 7, 2021 at 5:52 AM 'Thomas Lively' via emscripten-discuss <
>> emscripte...@googlegroups.com> wrote:
>>
>>> Yes, from the description in that article I would expect that
>>> optimization to apply to the Wasm target as well.
>>>
>>> Thomas
>>>
>>> On Mon, Dec 6, 2021 at 20:04 Soeren Balko  wrote:
>>>
 Saw this today:  LLVM Clang 14 Lands An "Amazing" Performance
 Optimization - Phoronix
 

 Looks like a fairly substantial gain for some workloads. Will this also
 apply to the WebAssembly target?


 --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/243b4dc8-4305-4af5-9e9d-dff8c0e84c4bn%40googlegroups.com
 
 .

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXyXLJ6-db5tUrgQzmN5QPsV0S0%3DbPub-TZA1BgrjWnjw%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f9b4c9a7-92aa-4b3c-b092-8c794693b626n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ6yZk3bCDNdjgjaA%2BNV0srD-Ai7cvn7FjPFNPJqVE4Wg%40mail.gmail.com.

Re: typescripten: Type-safe JavaScript interop with complex types

[Alon Zakai]

Hi Sebastian,

This is really nice! I watched your talk as well at CppCon (
https://www.youtube.com/watch?v=CLuhogat6aY), very interesting.

For a while it's seemed like we need something in this general area, so
it's great to see it happen! I think this is a very good design, too (the
performance issue with strings is the one concern I have, but as you say in
the talk, that can be optimized - I'd use EM_JS for that probably).

Did you have ideas about integrating this with upstream Emscripten? I think
that might make sense to do, although maybe as part of a larger
conversation on our bindings story (atm we have embind and the WebIDL
binder, which already have some overlap).

- Alon Zakai

On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil 
wrote:

> Hi,
>
> I wanted to plug my own project for some time here on the mailing list
> because it also handles JavaScript - C++ interop and now wajic came up so I
> thought I pitch in.
>
> My project https://github.com/think-cell/typescripten produces type-safe
> C++ interfaces to JavaScript standard libraries or third-party libraries.
> It reads TypeScript interface definition files and transforms them into C++
> shims based on emscripten.
>
> The resulting C++ code is often a straight-forward port from
> TypeScript/JavaScript, e.g.,
>
> JavaScript:
>
> var elem = document.createElement("p")
> elem.innerText = "Hello CppCon 2021"
> elem.style.fontSize = "20.0"
> document.body.appendChild(elem)
>
> C++:
>
> auto elem = js::document()->createElement(js::string("p"));
> elem->innerText(js::string("Hello CppCon 2021"));
> elem->style()->fontSize(js::string("20vh"));
> js::document()->body()->appendChild(elem);
>
> No macros and the C++ functions return typed JavaScript objects! Because
> we use the TypeScript interface definitions, the C++ code is typechecked.
> Passing a number to fontSize will create a compiler error.
>
> The project is not yet meaningfully complete but it bootstraps
> successfully, i.e., the compiler understands the interface definition file
> for the TypeScript compiler and parser API that it uses itself. TypeScript
> generic constraints are not yet supported, for example, but should be.
>
> Maybe somebody else finds this useful. We have used it internally for a
> small web app already that needed to call the tableau.com JavaScript API.
>
> Regards
> Sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3DuddahRRPV02%3DT9TaQd2%3D3YzxqHDBAqg8%3DsWJL-Taqh4-SQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3DuddahRRPV02%3DT9TaQd2%3D3YzxqHDBAqg8%3DsWJL-Taqh4-SQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSo_RuoctMU1TZObpugbtxS%3DgqrU-41typx2LuDKKMkWw%40mail.gmail.com.

Re: New LLVM 14 performance optimization

[Alon Zakai]

Looks like that patch landed Dec 2, so it is already in the latest tip of
tree build of emscripten, which people can try with

emsdk install tot



On Tue, Dec 7, 2021 at 5:52 AM 'Thomas Lively' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Yes, from the description in that article I would expect that optimization
> to apply to the Wasm target as well.
>
> Thomas
>
> On Mon, Dec 6, 2021 at 20:04 Soeren Balko  wrote:
>
>> Saw this today:  LLVM Clang 14 Lands An "Amazing" Performance
>> Optimization - Phoronix
>> 
>>
>> Looks like a fairly substantial gain for some workloads. Will this also
>> apply to the WebAssembly target?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/243b4dc8-4305-4af5-9e9d-dff8c0e84c4bn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXyXLJ6-db5tUrgQzmN5QPsV0S0%3DbPub-TZA1BgrjWnjw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ3DSer5FUd1L3wzbgkrtamN2%3DsK8dZ-AUVoOO0%3DScYqQ%40mail.gmail.com.

Re: EMSDK's version of Node.js?

[Alon Zakai]

Node docs say that version uses v8 9.4.146.19,

https://nodejs.org/en/download/releases/

I believe SIMD was enabled by default in Chromium 91,

https://developer.chrome.com/blog/new-in-chrome-91/

which would mean V8 9.1.* would be enough. So that should be new enough.
But it would be good to verify.

On Tue, Oct 26, 2021 at 12:43 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> On Tue, Oct 26, 2021 at 12:39 PM Alon Zakai  wrote:
>
>> Separately, however, does 16.13.0 have a new-enough SIMD for you?
>>
>
> Good question. Let me check. (What does it claim?)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnve%3DO_3znVw4bjrxpR4%2BjZX2wmx6M52tbw5rsajh2myRYw%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnve%3DO_3znVw4bjrxpR4%2BjZX2wmx6M52tbw5rsajh2myRYw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTPW8kRNvX1aWUq44XtSei0ndTKW52RGhdf1mpaZKp2oA%40mail.gmail.com.

Re: EMSDK's version of Node.js?

[Alon Zakai]

I think our general policy here has been to use the Node that we assume
most people are using anyhow (which seems safest for testing and everything
else). That generally means Node LTS, since it's what the node download
page directs people to, although we've debated that in the past.

It looks like current LTS is 16.13.0, so there has been a release of a new
LTS since our 14.*, and we should probably upgrade?

Separately, however, does 16.13.0 have a new-enough SIMD for you?


On Tue, Oct 26, 2021 at 12:18 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Is EMSDK planning on including a version of Node that is more up-to-date?
>
> emsdk 2.0.32 includes node v14.15.5, which doesn't seem to be up to date
> with (e.g.) the final wasm-simd128 spec.
>
> It would simplify life for me a lot if I could rely on the current EMSDK
> install to provide a reasonably up-to-date runtime for wasm, rather than
> having to install one separately.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnve-a1BU3YpxAwkGV9_pYNx%2BY63QuiGHcS6YC8odAVH1KA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSeD3GmWzaTFPd_Y6%3DQiUuHPozgsEX23HKMF8qCBRsmVQ%40mail.gmail.com.

Re: Asyncify and emscripten updates

[Alon Zakai]

In general, I'm afraid there isn't an automatic and safe way to do this. If
LLVM optimizations change (between -O3 and -Oz, or after an LLVM update
with the same opts) then inlining might cause the call stacks to look
different. If less is inlined, you'd need more functions in your list, if
you use the only-list.

But the risk here might be small in practice, at least in my experience. If
you make a single list for the union of -O3 and -Oz then it should work for
both, and it is very rare that LLVM changes enough to cause problems.

- Alon




On Tue, Aug 24, 2021 at 9:28 PM Александр Гурьянов 
wrote:

> Hi, everyone. I have well tuned list of asyncify functions for my js-dos
> project. If I understand correctly this function list is valid only for
> specific version of emscripten and optimizations flags. I compile project
> with -Oz flag, and if I change it to -O3 the asyncfiy list will be
> incomplete.
>
> So, Am I need somehow maintain lists for Oz and O3 separately? This is
> first problem, but not so important I can use only Oz flag.
>
> BUT, now I thinking how to update emscripten version. Is it true that
> updating emscripten to next version can require also rebuilding asyncify
> list? Can I do it safely somehow?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHXHQw4Lt7HpAyg9pSDZ2iEU95VEhwzhr2%3DWMXnaKCxWw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTrNF2p%2Bae1VHhb0s397WSM5L4XA%3D1qv1JuOiATGrztDg%40mail.gmail.com.

Re: Handling binary data outside of Emscripten?

[Alon Zakai]

I think you can define Module['stdout'], see this test:

https://github.com/emscripten-core/emscripten/blob/7e538a419c3649f3a540a57beab347aa8f6c6271/tests/test_core.py#L4895-L4926

That function should receive the character code of each byte written. So
you could construct the binary data from that.

(But it would be more efficient to write to a file, and get the entire file
at once as an array, usually.)

- Alon


On Thu, Aug 12, 2021 at 10:24 AM robert.a...@gmail.com <
robert.aboukha...@gmail.com> wrote:

> Hello, I'm compiling a C++ tool that outputs binary to stdout and I'm
> running into a similar issue but in the browser. I'm curious whether
> there's now a way to support this without modifying the code by any chance?
> Thank you!
>
>
> On Friday, November 8, 2013 at 3:28:09 PM UTC-8 Alon Zakai wrote:
>
>> Simplest option is to write to a file, not to stdout or stderr. For
>> stdout and stderr, we might be missing some binary stream support in node,
>> you might be the first person to try that...
>>
>> - Alon
>>
>>
>>
>> On Thu, Nov 7, 2013 at 12:42 PM, Daniel Baulig  wrote:
>>
>>> Sorry for reviving an old thread but I'm running into a very similar
>>> issue right now (found this while searching for a possible solution).
>>>
>>> I'm having a small C program that outputs binary data to stdout using
>>> fwrite. I usually invoke it like prog >outfile. It will also output some
>>> debugging data to stderr. This works flawless when compiled using gcc, but
>>> failed when compiled with emcc and run with node. The output to stderr will
>>> occasinally be corrupted. This only happens with the next output to stderr
>>> after a fwrite call. Also, the data output to stdout is corrupted and is
>>> not the same as the data written by the gcc compiled version. I randomly
>>> checked the data in the buffer before it is written to stdout by writing
>>> some bytes to stderr using fprintf(stderr, "%x%x\t") and all the bytes i've
>>> checked in the buffer are the same for the gcc and the emcc version of the
>>> binary. So the corruption must happen after calling fwrite inside the emcc
>>> stdio implementation. I tried putting the stdout stream into binary mode
>>> with freopen(NULL, "wb", stdout); before writing binary data to it, but
>>> that didn't help either.
>>> Anyone any suggestions?
>>>
>>> - Daniel
>>>
>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/aaa95dab-0be9-439e-9b14-7b426f94d24dn%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/aaa95dab-0be9-439e-9b14-7b426f94d24dn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS7xZp_XMCaJaL1u7o__DDSrMMb6BjcfzGhR%2B%2BYirgLiA%40mail.gmail.com.

Re: TextDecoderWrapper doesn't always work

[Alon Zakai]

Very strange. In that case, what is the type of data.buffer?

The main SharedArrayBuffer is always created in the main thread during
startup. Later growth does not create a new SAB in another thread, it just
grows it, and it updates the views in each thread
using updateGlobalBufferAndViews. Regardless, the buffer of those views
must always be an SAB - if somehow it is just an AB, that would be a
serious browser bug (which is possible, of course).

On Mon, Jul 5, 2021 at 6:21 PM Dan C  wrote:

> Hi everyone,
>
> In TextDecoderWrapper.decode
> ,
>  we
> currently have a checking whether the input buffer is an SharedArrayBuffer.
> After heap size is increased from INITIAL_MEMORY, "data.buffer instanceof
> SharedArrayBuffer" can evaluate to false when data is a view of the
> SharedArrayBuffer of the heap. I suspect this is because the new
> SharedArrayBuffer was created in a different thread.
>
> Thanks,
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c78e913e-7a0b-4fe3-9573-6e0300c5c2afn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRc6S0WyutSscZREJbxXX%2BU6FhA-ZWeOJmVrepkJCeO1w%40mail.gmail.com.

Re: Call C++ function from Javascript - I need example that Actually works

[Alon Zakai]

To use cwrap(), you must export it. See

https://emscripten.org/docs/api_reference/preamble.js.html?highlight=cwrap

You can also run an example from the tutorial, which I verified now,

https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=cwrap#interacting-with-an-api-written-in-c-c-from-nodejs

It does have one typo which I'll fix now, the require should be of
"api_example.js".

On Fri, Jul 2, 2021 at 11:25 AM Gary Stuart  wrote:

> Hi,
>
> I am trying to use emscripten on Windows 10.
> I have an existing Javascript client application that works.
> I want to connect in c++ code, and be able to call those c++ functions
> when needed.
> I have spent 1.5 days and can't even make a simple example work.
>
> I am using emcc version: 2.0.25 (Online the latest version seems to be
> 2.0.21???)
> I am using Chrome
>
> My example:
> function factorial()
> {
> console.log("MT:F")
> Module.onRuntimeInitialized = _ => {
> console.log("A")
>
> const  factorialCpp = Module.cwrap('factorial', 'number', ['number']);
> console.log(factorialCpp)
> var result = factorialCpp(10);
> console.log(result)
> };
> console.log("MT:F-E")
> }
>
> When I call this function, I get only the "MT:F" and "MT:F-E", and no
> errors in browser console.
>
> My compile line:
> emcc -O3 -s WASM=1 -s EXPORTED_RUNTIME_METHODS='["cwrap"]' -s
> EXPORTED_FUNCTIONS="['_factorial']" factorial.cpp factorial-service.cpp -o
> factorial.js
>
> If optimization is -O0, it complains about the cwrap export
>
> I have also tried:
> function factorial2()
> {
> Module['onRuntimeInitialized'] = onRuntimeInitializedFactorial;
> const factorialCpp = Module.cwrap('factorial', 'number', ['number']);
>
> function onRuntimeInitializedFactorial()
> {
> console.log("MT:F")
> console.log("A")
> var result = factorialCpp(10);
> console.log(result)
> console.log("MT:F-E")
> }
> }
>
> and:
> function factorial3()
> {
> var factorialCpp = Module.cwrap("factorial", "number", ["number"]);
> var result = factorialCpp(10);
> }
>
> Both produce an error: Uncaught TypeError: Module.cwrap is not a function
>
> I have found over 20 examples, that say just do this or that, but nothing
> works.
> Maybe my environment has a config issue?
>
> I would appreciate any any guidance on this.
> Thanks,
> Gary
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/56840ae5-46b1-458d-b30f-27ee5433fd39n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ21Yoyvy_xzrLkBTWmvEQoyVWc0fG3kAMmgx%3DmrhxE9g%40mail.gmail.com.

Re: Performance comparison of WASM and NaCl

[Alon Zakai]

Many things could cause such a difference, including that PNaCl uses LLVM
on the client (which sometimes beats web VMs), the use of SIMD (which must
be enabled explicitly in wasm, but I believe not in PNaCl - you may be
getting autovectorizing), presence of exceptions and setjmp (currently much
slower in wasm, but wasm will fix that soon), etc.

If this difference is important, you can investigate it using profiling
traces and inspection of particularly hot functions, etc. If you can share
the wasm benchmark we can take a look and see if there is anything obvious.

On Tue, May 4, 2021 at 6:27 AM Amol Wagh  wrote:

>
> Hello All,
>
> We have a chrome extension written in C++ and Javascript. Recently,
> changes are done to make use of WebAssembly module instead of NaCl module.
> However, performance of WebAssembly found to be slower, on an avg by 30%
> and despite using `-O3`, than the NaCl's performance.
> Emscripten compiler, v2.0.7, is used to prepare the .wasm. Whereas for
> .nexe, the C++ code is compiled using `pnacl-clang++` compiler. Later
> `pnacl-transalte` is used to generate the .nexe file. (x86_64 arch).
>
> OS and Compiler details are as follows.
> NaCl SDK having `Pepper 50`
> Emscripten SDK version 2.0.7
> Ubuntu 18.04.5 LTS
> Chrome version 88.0.4324.182 (64-bit)
> Processor : Intel® Core™ i5-5200U CPU @ 2.20GHz × 4
>
> My concern is -
> Right now, Emscripten only supports building 32 bit .wasm. Whereas, .nexe
> is 64 bit. Are the two executable right candidates for the performance
> comparison?
> There might be differences at several places.
> e.g. As mentioned in the design spec
> 
> of WebAssembly, `long double` are software-emulated.
> Note that, I can build 32 bit nexe. However, can't use it in 64 bit
> Chrome. Following error occurs in that case.
> NaCl module load failed: ELF file for wrong architecture.
>
> Regards,.
> Amol
>
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/d8e66f42-10b9-4af0-9ba8-01424720a1b2n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ9Rq1vYnJVRkpo1RBobSDitCsiw1b%3D%2BsWf7ajWFOt_Yg%40mail.gmail.com.

Re: regenerate wasm.js from preamble.js

[Alon Zakai]

There is an experimental --post-link option to create a JS file for a given
linked wasm file. However it isn't aware of SPLIT_MODULE so I am not sure
if it will work here.

On Tue, Apr 20, 2021 at 2:45 AM Александр Гурьянов 
wrote:

> Hi. I am trying to use SPLIT_MODULE with Unity. However unity shipped with
> old emscripten that does not know how to deal with SPLIT_MODULE. I
> successfully spitted wasm file with wasm-split, but I can't run it because
> .js file can't load it.
>
> Is it possible to regenerate .js file for given wasm, wasm.deferred file?
> Or if it is not possible, what I should define for correct work of
> SPLIT_MODULE? Currently I even can't start main module, had this error:
>
>
> index.js:1 3943ms |  ERR! RangeError: offset is out of bounds
> at Int8Array.set ()
> at mergeMemory (eval at value (
> http://localhost:3000/dev/web/debug/gamepix-loader.js:6586:98),
> :1059:17)
> at receiveInstance (eval at value (
> http://localhost:3000/dev/web/debug/gamepix-loader.js:6586:98),
> :1120:33)
> at http://localhost:3000/dev/web/debug/gamepix-loader.js:6743:119
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHu%2B5srLKjuitYZLhtpbiFg6RdSjLytNcg6XwzDk3Wf%2Bw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRL2w5gdbB5-LLi9xSvTeThPdOANub5uwodx2MNovjs-g%40mail.gmail.com.

Re: wasm-ld: error: --shared-memory is disallowed by .... because it was not compiled with 'atomics' or 'bulk-memory' features.

[Alon Zakai]

-pthreads with an "s" is a typo, I think? clang ignores it:

clang-13: warning: argument unused during compilation: '-pthreads'
[-Wunused-command-line-argument]

But -pthread (no "s") is identical to -s USE_PTHREADS.

Jasmeet, I think you need to debug your makefile. COMMON_CFLAGS may not
reach the compile command. It may help to build one source file with
EMCC_DEBUG=1 in the env to print out what compile command is run.

On Sat, Apr 10, 2021 at 9:14 AM Jim Lloyd  wrote:

> Note that
> -pthreads
> is not the same as
> -s USE_PTHREADS
> ​I believe you need both options.
> On Apr 10 2021, at 7:07 am, Jasmeet Kaur  wrote:
>
>> hi,
>> i updated the makefile:
>> CC = emcc
>> COMMON_CFLAGS += -Wall -pthread
>>
>> COMMON_CXXFLAGS += -I$(ROOT)/gui/ -I$(ROOT)/gui/GL/ -DNO_OPENGL -pthread
>>
>> But this doesnt seem to work. How do i pass the flag during compile time
>> for Driver.o?
>>
>>
>> On Thursday, April 8, 2021 at 5:51:51 PM UTC-4 jim@gmail.com wrote:
>>
>>> My code has "-s: USE_PTHREADS" for both compile and link options. My
>>> CMake uses this snippet:
>>> ​
>>>
>>> if
>>> (TARGET_WASM)
>>> add_compile_options
>>> (
>>> "SHELL:-s USE_PTHREADS"
>>> )
>>> add_link_options(
>>> "SHELL:-s USE_PTHREADS"
>>> )
>>> endif
>>> ()
>>> ​
>>> ​
>>> ​
>>> On Apr 8 2021, at 2:45 pm, 'Thomas Lively' via emscripten-discuss <
>>> emscripte...@googlegroups.com> wrote:
>>>
 That's the link command, since Driver.o is one of the inputs. You need
 to pass -pthread at compile time, where Driver.o is created, as well.

 On Thu, Apr 8, 2021 at 1:26 PM Jasmeet Kaur  wrote:

> I am using -pthread flag : (makefile)
> COMMON_LNFLAGS += -Lapps/libs -Ldemos/libs -L/usr/X11R6/lib64
> -L/usr/X11R6/lib -pthread
>
> and here is the compilation output :
> *emcc  -o ../../../../html/debug/snakebird.js
> ../../../../objs_html/snakebird.js/debug/apps/snakebird/Driver.o
> -lenvironments -lmapalgorithms -lalgorithms -lgraphalgorithms -lgraph
> -lutils -lguihtml -lgui -lSTUB -L../../../../html/debug -Lapps/libs
> -Ldemos/libs -L/usr/X11R6/lib64 -L/usr/X11R6/lib -pthread -g -s
> EXPORTED_FUNCTIONS="['_InitHOG', '_InitHOGArg', '_DoFrame', '_MouseEvent',
> '_HitKey', '_SetCanvasSize']" -s EXTRA_EXPORTED_RUNTIME_METHODS=["cwrap"]*
> *Live child 0x5633c6243c40 (../../../../html/debug/snakebird.js) PID
> 22723*
> *wasm-ld: error: --shared-memory is disallowed by
> ../../../../objs_html/snakebird.js/debug/apps/snakebird/Driver.o because 
> it
> was not compiled with 'atomics' or 'bulk-memory' features.*
>
> Is this not correct?
>
> On Thursday, April 8, 2021 at 4:17:10 PM UTC-4 tli...@google.com
> wrote:
>
>> The object file specified in the error message was not compiled with
>> -pthread, so atomic operations and thread-local data (if any) in its 
>> source
>> were transformed to non-atomic operations and non-thread-local data. That
>> transformation makes it unsafe to link that object into multi-threaded
>> programs, so wasm-ld fails with that error message. The fix is to use
>> -pthread when compiling that object.
>>
>> On Thu, Apr 8, 2021 at 1:11 PM Jasmeet Kaur 
>> wrote:
>>
>>> Hi,
>>> I am trying to use emscripton for a project. When I compile,  I get
>>> this error :
>>> wasm-ld: error: --shared-memory is disallowed by  because it was
>>> not compiled with 'atomics' or 'bulk-memory' features.
>>> Can someone point me as to how to resolve this? And also explain as
>>> to why is this happening?
>>> Environment info;
>>> *emcc (Emscripten gcc/clang-like replacement + linker emulating GNU
>>> ld) 2.0.16*
>>> *clang version 13.0.0
>>> (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project
>>> ad8010e598d9aa3747c34ce28aa2ba6de1650bd4)*
>>> *Target: wasm32-unknown-emscripten*
>>> *Thread model: posix*
>>>
>>> Thank you!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/a9d08d47-9808-4205-bb71-e9990aa19cf7n%40googlegroups.com
>>> 
>>> .
>>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-disc...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: Extremely slow startup time in Node environment

[Alon Zakai]

IMaybe node 12 did not yet have baseline compiler support for wasm. That
could explain the 30 seconds delay, as it fully optimizes all the code
before it runs. Asyncify can generate bigger code, which makes this worse.

A newer node may not have the problem, and should run the baseline compiler
by default, like on the web. You can force a newer node to use the
optimizing compiler with --liftoff --no-wasm-tier-up and that should be
slow once more, as a test to verify this is the issue.

On Sun, Feb 28, 2021 at 7:59 PM Александр Гурьянов 
wrote:

> I found something, this huge loading time only happens in -s ASYNCIFY=1
> and only if I add CPU_Core_Normal_Run to ASYNCIFY_WHITELIST, i think it
> happens
> because of function size.
>
> -s ASYNCIFY=1 +CPU_Core_Normal_Run
> Runtime initialized after 32175.474978000857 ms
> *(32 sec)*
> func: CPU_Core_Normal_Run\28\29
>  [binary-bytes] : 245307 (*239kb*)
>  [total]: 114037
>  [vars] : 22
>  Binary : 15203
>  Block  : 8136
>  Break  : 4471
>  Call   : 1250
>  CallIndirect   : 1120
>  Const  : 20921
>  Drop   : 1693
>  GlobalGet  : 7836
>  GlobalSet  : 2
>  If : 
>  Load   : 7368
>  LocalGet   : 17195
>  LocalSet   : 13046
>  Loop   : 6
>  Return : 1
>  Select : 1908
>  Store  : 3193
>  Switch : 48
>  Unary  : 3968
>  Unreachable: 6
>
> -s ASYNCIFY=1 -CPU_Core_Normal_Run
> Runtime initialized after 689.4367050006986 ms
> *(0.6 sec)*
> func: CPU_Core_Normal_Run\28\29
>  [binary-bytes] : 157675  (*153k*)
>  [total]: 64879
>  [vars] : 14
>  Binary : 10832
>  Block  : 3166
>  Break  : 2815
>  Call   : 1250
>  CallIndirect   : 1120
>  Const  : 13764
>  Drop   : 37
>  GlobalGet  : 1
>  GlobalSet  : 2
>  If : 1803
>  Load   : 7342
>  LocalGet   : 11878
>  LocalSet   : 7304
>  Loop   : 6
>  Select : 54
>  Store  : 3171
>  Switch : 48
>  Unary  : 281
>  Unreachable: 5
>
> Is it possible to do something automatically? Maybe split this function to
> chunks?
>
>
> пн, 8 февр. 2021 г. в 16:40, Александр Гурьянов :
>
>> Hi. I created a test program to estimate performance of my program. I
>> am trying to use it both in browser and node environment. Test program
>> works fine in both environments. However startups in node took up to
>> 30 sec, while in browser it starts instantly. I don’t understand why.
>>
>> I use an release build with -s ASYNCIFY = 1, my node.js script:
>>
>>
>> ```
>> const { performance } = require('perf_hooks');
>> const dhry2 = require("./dhry2.js");
>>
>> const startedAt = performance.now();
>> const Module = {
>> log: console.log,
>> performance,
>> onRuntimeInitialized: () => {
>>console.log("Runtime initialized after", performance.now() -
>> startedAt, "ms");
>>Module.callMain([]);
>> },
>> };
>>
>> dhry2(Module);
>> ```
>>
>> And for browser:
>> ```
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Start
>> 
>> 
>> 
>>  var stdout = document.getElementById("stdout");
>>
>>  function start() {
>>  WDHRY2({
>>  log: function(message) {
>>  },
>>  print: function(message) {
>>  if (message.startsWith("dhry2")) {
>>  console.log(message);
>>  stdout.innerHTML = stdout.innerHTML + "
"
>> + message;
>>  }
>>  },
>>  }).then(function(m) {
>>  m.callMain([]);
>>  });
>>  };
>> 
>> 
>> 
>> ```
>>
>> Node.js version starts in 30 sec, while browser versions starts
>> immediately. Node hangs after leaving instantiateArrayBuffer and
>> before entering receiveInstantiatedSource.
>> I think it doing something, but I don't understand what. I profiled
>> node but results is no obvious:
>>
>> ```
>> Statistical profiling result from isolate-0x36df400-1353021-v8.log,
>> (28109 ticks, 0 unaccounted, 0 excluded).
>>
>>  [Shared libraries]:
>>ticks  total  nonlib   name
>>  440.2%
>> /home/caiiiycuk/sdk/emsdk/node/12.18.1_64bit/bin/node
>>   50.0%  /usr/lib/x86_64-linux-gnu/libc-2.31.so
>>   10.0%  /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
>>
>>  [JavaScript]:
>>ticks  total  nonlib   name
>>   10.0%0.0%  Function: *wasm-function[2219]
>>
>>  [C++]:
>>ticks  total  nonlib   name
>>   27974   99.5%   99.7%  __pthread_cond_wait
>>  350.1%0.1%
>>
>> node::native_module::NativeModuleEnv::CompileFunction(v8::FunctionCallbackInfo
>> const&)
>> ...
>>  [Summary]:
>>ticks  total  nonlib   name
>>   10.0%0.0%  JavaScript
>>   28058   99.8%  100.0%  C++
>> ...
>> [C++ entry points]:

Re: HEAP* not accessible anymore through Module object

[Alon Zakai]

I'm not sure what's going on here. Perhaps it's due to using MODULARIZE + a
custom instantiateWasm. Is that needed? Removing it may fix things. I think
that may be related because in Modularize mode you should do something like

Module().then(..)

and you get the actual Module object, with .HEAP8 etc. on it, in the
Promise. But in your custom instantiateWasm I'm not sure where that  would
happen.

If that's not it, a simple way to find out specifically where this
regressed is to bisect on tot builds,
https://emscripten.org/docs/contributing/developers_guide.html#bisecting



On Tue, Feb 16, 2021 at 5:51 PM Александр Гурьянов 
wrote:

> I think I was unclear, I mean that I trying to access HEAP variables from
> outside of Module.
> Anyway I have a test case. It instantiate simple wasm module and print all
> Module keys that started from HEAP.
> It prints them both from inside Module and from outside. "inside" case
> works all times, but "outside" case works only until 2.0.10.
> Need to run `./test.sh`
>
>
> https://drive.google.com/file/d/1Yudusi2wQsWqG4ItAaFEx4hsAbY92WLe/view?usp=sharing
>
> Output for 2.0.9:
> ```
> + rm -rf ./build
> + mkdir ./build
> + em++ v1.cpp -s INVOKE_RUN=0 -s WASM=1 -s MODULARIZE=1 -s SAFE_HEAP=0 -s
> ASSERTIONS=1 -s 'EXPORTED_FUNCTIONS=["_main","_malloc","_free"]' -O0
> --emit-symbol-map -o build/v1.js
> + node v1-test.js
> == FROM OUTSIDE ==
> HEAP8
> HEAP16
> HEAP32
> HEAPU8
> HEAPU16
> HEAPU32
> HEAPF32
> HEAPF64
> == FROM INSIDE ==
> HEAP8
> HEAP16
> HEAP32
> HEAPU8
> HEAPU16
> HEAPU32
> HEAPF32
> HEAPF64
> ```
>
> Output for 2.0.10+:
> ```
> + rm -rf ./build
> + mkdir ./build
> + em++ v1.cpp -s INVOKE_RUN=0 -s WASM=1 -s MODULARIZE=1 -s SAFE_HEAP=0 -s
> ASSERTIONS=1 -s 'EXPORTED_FUNCTIONS=["_main","_malloc","_free"]' -O0
> --emit-symbol-map -o build/v1.js
> + node v1-test.js
> == FROM OUTSIDE ==
> == FROM INSIDE ==
> HEAP8
> HEAP16
> HEAP32
> HEAPU8
> HEAPU16
> HEAPU32
> HEAPF32
> HEAPF64
> ```
>
> ср, 17 февр. 2021 г. в 00:27, Alon Zakai :
>
>> (I think this is separate from minification. We minify wasm imports and
>> exports, but the HEAP* views are handled entirely in JS.)
>>
>> On Tue, Feb 16, 2021 at 9:06 AM Floh  wrote:
>>
>>> Just a wild guess: maybe the name has been mangled by the minification
>>> pass, while in previous emscripten versions it might have been "protected"
>>> from minification?
>>>
>>> I've seen similar problem in the past where Module.func_name() stopped
>>> working in newer emscripten versions (especially with stuff like ccall
>>>
>>> FWIW I'm using HEAP* as global variable (not Module.HEAP*) and that
>>> still seems to work, for instance:
>>>
>>>
>>> https://github.com/floooh/sokol/blob/c8023ab515822005d74c36b3a77656315a5ce1be/sokol_audio.h#L1493-L1498
>>>
>>> Cheers,
>>> -Floh.
>>> On Tuesday, 16 February 2021 at 10:20:53 UTC+1 caiiiycuk wrote:
>>>
>>>> Hi. I faced issue that my js code stop working from 2.0.10. It uses
>>>> Module.HEAP* variables to access wasm memory. However from 2.0.10 Module
>>>> does not contains this variables anymore. Is it expected behavior, how I
>>>> can reexport them?
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/ef21bd22-4ed4-440c-b573-bc1186468daan%40googlegroups.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/ef21bd22-4ed4-440c-b573-bc1186468daan%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRodoU9gK_oTU2yUiga_7f4FtVO%3DzZSbGzXZufZ5sRFhA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRodoU9gK_oTU2yUiga_7f4FtVO%3DzZSbGzXZufZ5sRFhA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
&g

Re: HEAP* not accessible anymore through Module object

[Alon Zakai]

(I think this is separate from minification. We minify wasm imports and
exports, but the HEAP* views are handled entirely in JS.)

On Tue, Feb 16, 2021 at 9:06 AM Floh  wrote:

> Just a wild guess: maybe the name has been mangled by the minification
> pass, while in previous emscripten versions it might have been "protected"
> from minification?
>
> I've seen similar problem in the past where Module.func_name() stopped
> working in newer emscripten versions (especially with stuff like ccall
>
> FWIW I'm using HEAP* as global variable (not Module.HEAP*) and that still
> seems to work, for instance:
>
>
> https://github.com/floooh/sokol/blob/c8023ab515822005d74c36b3a77656315a5ce1be/sokol_audio.h#L1493-L1498
>
> Cheers,
> -Floh.
> On Tuesday, 16 February 2021 at 10:20:53 UTC+1 caiiiycuk wrote:
>
>> Hi. I faced issue that my js code stop working from 2.0.10. It uses
>> Module.HEAP* variables to access wasm memory. However from 2.0.10 Module
>> does not contains this variables anymore. Is it expected behavior, how I
>> can reexport them?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ef21bd22-4ed4-440c-b573-bc1186468daan%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRodoU9gK_oTU2yUiga_7f4FtVO%3DzZSbGzXZufZ5sRFhA%40mail.gmail.com.

Re: HEAP* not accessible anymore through Module object

[Alon Zakai]

Hmm, the HEAP* views are always exported,

https://github.com/emscripten-core/emscripten/blob/2e48b2debd5e984cde2cee563f4a359a9d688c46/src/preamble.js#L268-L281

I verified manually that that works in a hello world at all optimization
levels.

Do you have a testcase showing the issue?

On Tue, Feb 16, 2021 at 1:20 AM Александр Гурьянов 
wrote:

> Hi. I faced issue that my js code stop working from 2.0.10. It uses
> Module.HEAP* variables to access wasm memory. However from 2.0.10 Module
> does not contains this variables anymore. Is it expected behavior, how I
> can reexport them?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFe05FCEJ%2BW0umu52uE62f9JtykGL-z98Eqd37hYtA%2BmQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR%3DUAKhswG03pZCXqr0sLQ6ZUU8Wt3ZnQbGEK_S6-ScPQ%40mail.gmail.com.

Re: Compiling CGAL application with emscripten

[Alon Zakai]

Thanks, the docs do look a little out of date. I opened
https://github.com/emscripten-core/emscripten/pull/13417 for that now.

On Tue, Feb 2, 2021 at 11:09 PM Kunza Rizvi  wrote:

> I found the conversion to bitcode on a blog post, stackoverflow and the
> emscripten documentation (though the documentaton did not explicitly state
> CGAL in particular)
> Here are the corresponding links:
>
> https://stackoverflow.com/questions/31214387/using-emscripten-with-cmake-in-a-simple-project
>
> https://emscripten.org/docs/compiling/Building-Projects.html#using-libraries
>
> https://adamrehn.com/articles/creating-javascript-bindings-for-c-cxx-libraries-with-emscripten/
>
> I looked further into the problem and found that web assembly does not
> support rounding modes which might break most functions in CGAL. Do you
> know any work-around for this? I want to use CGAL for basic mesh-related
> computations in a hole detection and hole filling related project.
>
> On Wednesday, February 3, 2021 at 7:12:18 AM UTC+5 s...@google.com wrote:
>
>> You should be able to compile to a library just like you would on a
>> native platform.  i.e. compile each source to an object files and combine
>> them into a library using `emar`,  Then link that library into your final
>> program.
>>
>> We don't recommend using bitcode (at least not aside from LTO where it's
>> an implementation detail) these days.  Can I ask where you saw the
>> instructions to compile to bitcode?
>>
>> cheers,
>> sam
>>
>> On Tue, Feb 2, 2021 at 1:42 AM Kunza Rizvi  wrote:
>>
>>> I am trying to compile a CGAL application on the web using emscripten
>>> and web assembly. According to the emscripten documentation, external
>>> libraries must be compiled to bitcode first. I am not sure how to achieve
>>> that since CGAL has quite a large number of include files. Since I am a
>>> beginner in CGAL, I'd appreciate some help and guidance regarding the steps
>>> required for CGAL to web compilation.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/5c8d6de6-0f73-4b69-ab04-8c0d27436e51n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/d20fac1d-c8ac-4dcd-90ba-b88922541dfen%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSv%3DajMzEtLW7JgqUHryNE1VXUMprRyy-uw5LvKHdjHGw%40mail.gmail.com.

Re: Dealing with "Maximum call stack size exceeded" on fsanitize=undefined

[Alon Zakai]

Different versions of node may truncate the stack to different defaults.
But it is configurable, try

node --stack-trace-limit=1000

On Thu, Jan 21, 2021 at 2:53 PM 'Maksim Ivanov' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> @Alon: Hard to say whether it's an infinite recursion - the snippet I
> attached is all what's output. Can it be that something truncates the stack
> before printing, without leaving any trace of what was truncated?
> My other hypothesis was that some code generated by UBSan allocates huge
> variables on stack; again, I don't know how to verify that.
>
> @Thomas: Sure; I'll probably be able to do it in a couple of days, after
> minimizing the repro and removing irrelevant details from it.
>
>
> Maksim
>
>
> On Thu, Jan 21, 2021 at 11:49 PM 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> I've seen reports of infinite recursions involving
>> __ubsan_handle_dynamic_type_cache_miss before, but I've never been able to
>> reproduce them to investigate. Would you be able to share your reproducer?
>>
>> On Thu, Jan 21, 2021 at 2:24 PM Alon Zakai  wrote:
>>
>>> Does the stack trace look like it's an infinite recursion? That could be
>>> a toolchain bug.
>>>
>>>
>>> On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com> wrote:
>>>
>>>> Hello, does anyone have a tip on how to work around the "Maximum call
>>>> stack size exceeded" error when running a UBsan-sanitized Emscripten
>>>> program under Node?
>>>>
>>>> The error is:
>>>>
>>>> "RangeError: Maximum call stack size exceeded
>>>> at _emscripten_return_address (a.out.js:6788:35)
>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>> (wasm-function[8220]:0x210eb3)
>>>> at std::type_info::operator==(std::type_info const&) const
>>>> (wasm-function[938]:0x648b3)
>>>> at is_equal(std::type_info const*, std::type_info const*, bool)
>>>> (wasm-function[8154]:0x20a911)
>>>> at __dynamic_cast (wasm-function[8156]:0x20aa48)
>>>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>>>> (wasm-function[8196]:0x20f1b9)
>>>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>>>> unsigned long, unsigned long, __ubsan::ReportOptions)
>>>> (wasm-function[8221]:0x210f03)
>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>> (wasm-function[8220]:0x210ed7)
>>>> at std::type_info::operator==(std::type_info const&) const
>>>> (wasm-function[938]:0x648b3)
>>>> at is_equal(std::type_info const*, std::type_info const*, bool)
>>>> (wasm-function[8154]:0x20a911)"
>>>>
>>>> I'm not 100% sure, but it seems that the error doesn't indicate a bug
>>>> in the program, because it doesn't appear when compiling a small program
>>>> (e.g., a Googletest binary with 0 tests) and begins to appear even after
>>>> adding unused code (e.g., a bunch of disabled Googletest tests).
>>>>
>>>> I tried passing "--stack_size=8192" to Node, but this didn't help;
>>>> also, when increasing the number (e.g., to 131072) I'm starting to get a
>>>> different error:
>>>>
>>>> RuntimeError: memory access out of bounds
>>>> at __dynamic_cast (wasm-function[8156]:0x20aa0f)
>>>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>>>> (wasm-function[8196]:0x20f1b9)
>>>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>>>> unsigned long, unsigned long, __ubsan::ReportOptions)
>>>> (wasm-function[8221]:0x210f03)
>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>> (wasm-function[8220]:0x210ed7)
>>>> at std::type_info::operator==(std::type_info const&) const
>>>> (wasm-function[938]:0x648b3)
>>>> at is_equal(std::type_info const*, std::type_info const*, bool)
>>>> (wasm-function[8154]:0x20a911)
>>>> at __dynamic_cast (wasm-function[8156]:0x20aa48)
>>>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>>>> (wasm-function[8196]:0x20f1b9)
>>>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>>>> unsigned long, unsigned long, __ubsan::ReportOptions)
>>>> (wasm-function[8221]:0x210f

Re: Dealing with "Maximum call stack size exceeded" on fsanitize=undefined

[Alon Zakai]

Does the stack trace look like it's an infinite recursion? That could be a
toolchain bug.


On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Hello, does anyone have a tip on how to work around the "Maximum call
> stack size exceeded" error when running a UBsan-sanitized Emscripten
> program under Node?
>
> The error is:
>
> "RangeError: Maximum call stack size exceeded
> at _emscripten_return_address (a.out.js:6788:35)
> at __ubsan_handle_dynamic_type_cache_miss
> (wasm-function[8220]:0x210eb3)
> at std::type_info::operator==(std::type_info const&) const
> (wasm-function[938]:0x648b3)
> at is_equal(std::type_info const*, std::type_info const*, bool)
> (wasm-function[8154]:0x20a911)
> at __dynamic_cast (wasm-function[8156]:0x20aa48)
> at __ubsan::checkDynamicType(void*, void*, unsigned long)
> (wasm-function[8196]:0x20f1b9)
> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
> unsigned long, unsigned long, __ubsan::ReportOptions)
> (wasm-function[8221]:0x210f03)
> at __ubsan_handle_dynamic_type_cache_miss
> (wasm-function[8220]:0x210ed7)
> at std::type_info::operator==(std::type_info const&) const
> (wasm-function[938]:0x648b3)
> at is_equal(std::type_info const*, std::type_info const*, bool)
> (wasm-function[8154]:0x20a911)"
>
> I'm not 100% sure, but it seems that the error doesn't indicate a bug in
> the program, because it doesn't appear when compiling a small program
> (e.g., a Googletest binary with 0 tests) and begins to appear even after
> adding unused code (e.g., a bunch of disabled Googletest tests).
>
> I tried passing "--stack_size=8192" to Node, but this didn't help; also,
> when increasing the number (e.g., to 131072) I'm starting to get a
> different error:
>
> RuntimeError: memory access out of bounds
> at __dynamic_cast (wasm-function[8156]:0x20aa0f)
> at __ubsan::checkDynamicType(void*, void*, unsigned long)
> (wasm-function[8196]:0x20f1b9)
> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
> unsigned long, unsigned long, __ubsan::ReportOptions)
> (wasm-function[8221]:0x210f03)
> at __ubsan_handle_dynamic_type_cache_miss
> (wasm-function[8220]:0x210ed7)
> at std::type_info::operator==(std::type_info const&) const
> (wasm-function[938]:0x648b3)
> at is_equal(std::type_info const*, std::type_info const*, bool)
> (wasm-function[8154]:0x20a911)
> at __dynamic_cast (wasm-function[8156]:0x20aa48)
> at __ubsan::checkDynamicType(void*, void*, unsigned long)
> (wasm-function[8196]:0x20f1b9)
> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
> unsigned long, unsigned long, __ubsan::ReportOptions)
> (wasm-function[8221]:0x210f03)
> at __ubsan_handle_dynamic_type_cache_miss
> (wasm-function[8220]:0x210ed7)
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/8c9c6b8b-a4b1-427c-965c-5828f8fa8fe9n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRAZ87AKvva7HxffLjQa64rGHk%3Dp%3DxfiWjgRO6X0iZzVg%40mail.gmail.com.

Re: failure in compiling hello_world.cpp

[Alon Zakai]

Interesting...

I'm not sure we can ignore CPATH, as in principle someone might use it
intentionally, and put a path to valid emscripten contents there.

On the other hand if this is common on some OSes then it does seem like
something we should do something about, even if only warn.

On Wed, Nov 25, 2020 at 10:51 AM Floh  wrote:

> Oh interesting and TIL, I didn't know that CPATH thing. Maybe emcc should
> somehow ignore CPATH, it sounds like it could happen to more people, and
> it's a very obscure sort of problem.
>
> On Wednesday, 25 November 2020 at 19:15:03 UTC+1 efrem...@gmail.com wrote:
>
>> That's it! `env | grep CommandLineTools` showed me
>> `CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include`. I
>> then ran `export CPATH=''`, and then I compiled hello_world.c without any
>> problems. Apparently I was setting the CPATH environment variable in my
>> .zprofile.
>>
>>
>> Thanks so much everyone!
>>
>> Efrem Braun
>>
>>
>> On Wed, Nov 25, 2020 at 12:55 PM Floh  wrote:
>>
>>> Complete shot in the dark, but does this show anything:
>>>
>>> env | grep CommandLineTools
>>>
>>> ...basically checking if that include path shows up in any environment
>>> variable...
>>>
>>> On Wednesday, 25 November 2020 at 18:46:15 UTC+1 Floh wrote:
>>>
 Yeah, the first include here is the problem (/Library/Developer/...).
 The question is how this is getting in there...

 #include "..." search starts here:
 #include <...> search starts here:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Users/edbraun/software/emsdk/upstream/emscripten/system/include/SDL
 /Users/edbraun/software/emsdk/upstream/emscripten/system/include/compat

 I don't know if clang/emcc has any hidden feature to get header search
 paths from anywhere else than the command line (like an environment
 variable maybe?), I tried googling for that but haven't found anything.




 On Wednesday, 25 November 2020 at 18:28:26 UTC+1 efrem...@gmail.com
 wrote:

> Changing the shell to bash and redoing the installation gave the same
> results, so it's not the zsh shell.
>
> It's really strange that
> `-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/inc` is being
> passed to clang, as shown by `emcc -E -v -x c /dev/null`. That does seem 
> to
> be the culprit, but I don't know why that's happening or how to change it.
>
> Efrem Braun
>
>
> On Wed, Nov 25, 2020 at 12:12 PM Efrem Braun 
> wrote:
>
>> Yes, I followed the instructions given here:
>> https://emscripten.org/docs/getting_started/downloads.html#sdk-download-and-install
>> :
>> git clone https://github.com/emscripten-core/emsdk.git
>> cd emsdk
>> ./emsdk install latest
>> ./emsdk activate latest
>> source ./emsdk_env.sh
>>
>> I just deleted the installation and tried those 5 steps again. I
>> immediately ran `emcc -E -v -x c /dev/null`, and it again showed
>> `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include` as the
>> first directory in the #include search path.
>>
>> Efrem Braun
>>
>>
>> On Wed, Nov 25, 2020 at 12:03 PM gianluca torta 
>> wrote:
>>
>>> have you run emsdk_env.sh?
>>>
>>> Gianluca
>>>
>>> On Tuesday, November 24, 2020 at 5:45:09 PM UTC+1 efrem...@gmail.com
>>> wrote:
>>>
 I installed emscripten using the standard instructions as per
 https://emscripten.org/docs/getting_started/downloads.html#installation-instructions.
 Running `emcc -v` gave me no errors, and the following message:
 ```
 (base) edbraun@gs66-lostcheme emscripten % emcc -v
 emcc (Emscripten gcc/clang-like replacement + linker emulating GNU
 ld) 2.0.9
 clang version 12.0.0
 (/opt/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project
 27e9f0f95ef7b144d008bc1cf1459dced6cb5842)
 Target: x86_64-apple-darwin19.6.0
 Thread model: posix
 InstalledDir: /Users/edbraun/software/emsdk/upstream/bin
 shared:INFO: (Emscripten: Running sanity checks)
 ```

 I then moved on to the tutorial. Running `emcc tests/hello_world.c`
 gave me errors however:
 ```
 In file included from tests/hello_world.c:8:
 In file included from
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:64:
 In file included from
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:68:

 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2:
 error: Unsupported architecture
 #error Unsupported architecture
 ^
 In file included from tests/hello_world.c:8:
 In file included from
 

Re: WASM=0 Has No Effect?

[Alon Zakai]

WASM=0 still runs the normal compilation pipeline to wasm. It just then
converts the WASM into JavaScript at the very end. (Older versions of
emscripten, that still used fastcomp, used to do things differently.)

What is actually making lld error there? What type of file is ffmpeg.bc?
(running "file ffmpeg.bc" can help) If it's LLVM bitcode, of an older
version, then it needs to be recompiled for the current version.

On Sun, Nov 22, 2020 at 8:11 AM Eric Brisco  wrote:

> Hello,
>
> I am trying to build ffmpeg using the build setup
> https://github.com/Kagami/ffmpeg.js which uses Emscripten. It is supposed
> to target JavaScript, not Web Assembly, and uses -s WASM=0 to make that
> switch. However, eventually the make script encounters this error:
>
> $ make ffmpeg-webm.js
> emcc build/ffmpeg-webm/ffmpeg.bc build/opus/dist/lib/libopus.so
> build/libvpx/dist/lib/libvpx.so \
> --post-js build/post-sync.js \
> -O3 --closure 1 --memory-init-file 0 -s WASM=0 -s
> WASM_ASYNC_COMPILATION=0 -s ASSERTIONS=0 -s EXIT_RUNTIME=1 -s
> NODEJS_CATCH_EXIT=0 -s NODEJS_CATCH_REJECTION=0 -s TOTAL_MEMORY=67108864
> -lnodefs.js -lworkerfs.js --pre-js build/pre.js -o ffmpeg-webm.js
> wasm-ld: error: unknown file type: build/ffmpeg-webm/ffmpeg.bc
> emcc: error: '/mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/bin/wasm-ld
> -o ffmpeg-webm.wasm build/ffmpeg-webm/ffmpeg.bc
> build/opus/dist/lib/libopus.so build/libvpx/dist/lib/libvpx.so
> -L/mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libc.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libcompiler_rt.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libc++-noexcept.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libc++abi-noexcept.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libdlmalloc.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libpthread_stub.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libc_rt_wasm.a
> /mnt/c/Users/erisco/Documents/cpp/emsdk/upstream/emscripten/cache/wasm/libsockets.a
> -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj
> -mllvm -disable-lsr --allow-undefined --import-memory --strip-debug
> --export-table --export main --export stackSave --export stackRestore
> --export stackAlloc --export __wasm_call_ctors --export fflush --export
> __errno_location --export malloc --export free --export setThrew --export
> realloc --export testSetjmp --export saveSetjmp -z stack-size=5242880
> --initial-memory=67108864 --no-entry --max-memory=67108864
> --global-base=1024' failed (1)
> Makefile:233: recipe for target 'ffmpeg-webm.js' failed
> make: *** [ffmpeg-webm.js] Error 1
>
> It seems as though -s WASM=0 is having no effect because I would not
> expect wasm-ld to be called at all, and definitely not on ffmpeg.bc (which
> is a JavaScript file).
>
> Anyone have some advice for this?
>
> Thanks,
> Eric
>
> P.S. I also have this issue open on the ffmpeg.js tracker, as perhaps it
> is a problem with the build script:
> https://github.com/Kagami/ffmpeg.js/issues/148
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f47027af-5c39-4730-befc-93ea9c13a797n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSXybuQwUp9o98CiLCqGiVp8jHjKsk-q_9ObWDjKPCdMg%40mail.gmail.com.

Re: Use specific LLVM version

[Alon Zakai]

There is discussion about this in

https://github.com/emscripten-core/emscripten/issues/11362#issuecomment-707357663

(see that and later comments in the issue).

On Thu, Nov 5, 2020 at 3:13 AM Yugesh Kothari 
wrote:

> Hi,
>
> How can I use emsdk with a specific version of LLVM that is not top of the
> tree?
> Using the system installed llvm is what I would ideally want to do, but if
> not I can always build from source.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/31bc6d1d-77d7-4c1f-93d0-cfeb2471f133n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ6Dk5opfvnLuY8HyXisqiqZZcr-TgcAZugLb6p0igY2A%40mail.gmail.com.

Re: Feature request: SharedArrayBuffer-backed heap without generating a multi-threaded build

[Alon Zakai]

> As a hacky workaround, you could always provide your own memory by
setting `Module['wasmMemory']` before loading the generated JS and then set
the memory flag to shared using `wasm-dis + edit + wasm-as`. Obviously not
ideal but maybe good for experimenting.

I don't think that will work now that the Memory is not imported anymore in
a normal build. You'd need to also mod the wasm to import the memory, and
change the JS a little as well.

But I agree building with pthreads enabled, but not actually using any
pthreads APIs, seems like a good solution here. There may be a minor code
size cost, is the only downside I can think of.

On Tue, Oct 27, 2020 at 6:19 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> This certainly seems like a reasonable setup.
>
> My first reaction would be why not just build with `USE_PTHREADS=1`?
>  This is the canonical way to tell emscripten to use shared memory.   If
> you don't actually start any threads I'm not sure what costs it has.  What
> "extra complexity of the WebAssembly threading model" are you referring to
> here?
>
> If there are indeed significant costs to running single threaded programs
> built with `USE_PTHREADS=1` then we can look into adding a separate option
> for using shared memory, but I think it will be tricky to persuade the
> linker wasm-ld to accept both shared memory, and object files build for
> non-shared memory.
>
> As a hacky workaround, you could always provide your own memory by setting
> `Module['wasmMemory']` before loading the generated JS and then set the
> memory flag to shared using `wasm-dis + edit + wasm-as`. Obviously not
> ideal but maybe good for experimenting.
>
> cheers,
> sam
>
> On Tue, Oct 27, 2020 at 12:27 AM Soeren Balko 
> wrote:
>
>> I've been running into an issue with Emscripten, where I cannot use a
>> shared WebAssembly.Memory (ie., backed by a SharedArrayBuffer) in a
>> single-threaded build. The rationale for this is to be able to use the
>> Emscripten heap as a shared state with other workers / the UI thread.
>> Specifically, it would allow us to directly copy data to the heap in other
>> threads, avoiding to copy data.
>>
>> Our scenario looks like this:
>> (1) We run a (single-threaded) WebAssembly module in a worker in a
>> long-running synchronous call;
>> (2) From within the synchronous call stack, the wasm module calls into JS
>> to dispatch some work to the UI thread;
>> (3) We currently COPY the data from the WebAssembly.Memory heap to a
>> separate SharedArrayBuffer, which we then postMessage to the main thread.
>> (4) The worker then uses a wait/notify pattern to block the Emscripten
>> call stack until the UI thread has passed back a result on the
>> SharedArrayBuffer
>> (5) The UI thread can meanwhile perform some asynchronous work (eg.,
>> IndexedDB, etc.) and store the response in the SharedArrayBuffer, then
>> notify the waiting worker.
>> (6) The waiting worker then has to COPY the result from the
>> SharedArrayBuffer back onto the Emscripten heap and return.
>>
>> In effect, we're performing two (expensive) copies. If the Emscripten
>> heap was using a SharedArrayBuffer, we could trivially share that with the
>> UI thread and merely pass offsets on the heap around.
>>
>> So in summary, are there any plans to supporting an SAB-backed
>> WebAssembly.Memory for scenarios like these? I understand that a
>> multi-threaded build could accomplish this. However, the extra complexity
>> of the WebAssembly threading model (especially when running the WebAssembly
>> module inside a worker) is not really acceptable in this case.
>>
>> Soeren
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/283659cd-4e07-4913-a185-e4e9495f8d12n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_82PfYNs7%3DFHXfobPDQKt23Rg6nx3AhkhrFfbiJzTVoQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: Future of asm.js support

[Alon Zakai]

We plan to support non-wasm output for a very long time - it's useful for
multiple reasons, including that it can run in old browsers like IE11.

Building with -s WASM=0 is how to do that. Note that it's not asm.js - it
is JavaScript that is similar to asm.js, but not identical (as wasm gains
more features, they become impractical to compile to asm.js which was
pretty strict).


On Fri, Oct 16, 2020 at 4:10 PM キャロウ マーク  wrote:

> I have just received a request to one of my projects to support compiling
> to asm.js ("as a fallback for use cases where WebAssembly isn't
> available, for example, if a user is required to use Internet Explorer
> 11”). Currently the project’s CMake set up only supports compiling to wasm.
> How much longer will Emscripten continue to support asm.js builds? If there
> isn’t much future then it is probably not worth adding support in my
> project.
>
> Regards
>
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/2B155F7C-DE2B-437E-8606-15B4222B1B42%40callow.im
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTYg9oaiCW1aWae9Ri-Td4yWbwJW9bMNa2MJrL-RJfS-g%40mail.gmail.com.

Re: CI requires connecting account to check results

[Alon Zakai]

I received a response that this is a known issue in CircleCI's new UI, and
that they are working on it.

This may be a little annoying in the meantime. If anyone opens a PR and has
trouble viewing CI runs, let me know.

- Alon



On Wed, Oct 7, 2020 at 11:24 AM Alon Zakai  wrote:

> I agree this is definitely annoying and unexpected - it should be easy for
> someone submitting a PR to see build results. I opened a support ticket now.
>
> Thanks for reporting this Sylvain!
>
> - Alon
>
>
>
> On Tue, Oct 6, 2020 at 11:26 PM Sylvain Beucler  wrote:
>
>> Hi,
>>
>> I'd say contact your CI provider and tell them that their recent
>> unannounced policy changes hinders contribution to your project.
>>
>> Cheers!
>> Sylvain
>>
>> On 07/10/2020 03:47, 'Sam Clegg' via emscripten-discuss wrote:
>> > On Tue, Oct 6, 2020 at 1:33 PM Sylvain Beucler > > <mailto:b...@beuc.net>> wrote:
>> >
>> > Hi,
>> >
>> > I don't use circleci outside of a limited outsider access in
>> emscripten
>> > so I can't help further than this. This is easily verifiable by
>> opening
>> > the link in a private browser window.
>> >
>> >
>> > Right, its just clear if there is anything we can or should do about it.
>> >
>> > Do you have a concrete suggestion?
>> >
>> > It doesn't seem to be related to emscripten specifically but rather the
>> > circleci itself.
>> >
>> > cheers,
>> >
>> > On 06/10/2020 22:13, 'Sam Clegg' via emscripten-discuss wrote:
>> > > I believe you are the first to mention this.
>> > >
>> > > Did this change recently?  Maybe search circleci forums
>> > discussions for
>> > > background?   If you discover this is something configurable on
>> the
>> > > emscripten end please let is know and we can adjust the
>> > relevant settings.
>> > >
>> > > cheers,
>> > > sam
>> > >
>> > >
>> > > On Tue, Oct 6, 2020 at 9:55 AM Sylvain Beucler > > <mailto:b...@beuc.net>
>> > > <mailto:b...@beuc.net <mailto:b...@beuc.net>>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I noticed that CircleCI now redirects me to a login / connect
>> your
>> > > github account when I want to access an emscripten build log,
>> e.g.
>> > > https://circleci.com/gh/emscripten-core/emscripten/363781
>> > >
>> > > (actually it starts displaying the log, then redirects me
>> anyway)
>> > >
>> > > The login page mentions "We ask for read/write access to make
>> your
>> > > experience seamless on CircleCI" which is not engaging.
>> > >
>> > > Is this known?
>> > >
>> > > Cheers!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/6e763435-21de-c578-7b2f-321474a9f7e6%40beuc.net
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQn6RM3rneHm1ANVAyvrEim3Z%2B2ODyGFSwj%2Bur7oGcBbg%40mail.gmail.com.

Re: CI requires connecting account to check results

[Alon Zakai]

I agree this is definitely annoying and unexpected - it should be easy for
someone submitting a PR to see build results. I opened a support ticket now.

Thanks for reporting this Sylvain!

- Alon



On Tue, Oct 6, 2020 at 11:26 PM Sylvain Beucler  wrote:

> Hi,
>
> I'd say contact your CI provider and tell them that their recent
> unannounced policy changes hinders contribution to your project.
>
> Cheers!
> Sylvain
>
> On 07/10/2020 03:47, 'Sam Clegg' via emscripten-discuss wrote:
> > On Tue, Oct 6, 2020 at 1:33 PM Sylvain Beucler  > > wrote:
> >
> > Hi,
> >
> > I don't use circleci outside of a limited outsider access in
> emscripten
> > so I can't help further than this. This is easily verifiable by
> opening
> > the link in a private browser window.
> >
> >
> > Right, its just clear if there is anything we can or should do about it.
> >
> > Do you have a concrete suggestion?
> >
> > It doesn't seem to be related to emscripten specifically but rather the
> > circleci itself.
> >
> > cheers,
> >
> > On 06/10/2020 22:13, 'Sam Clegg' via emscripten-discuss wrote:
> > > I believe you are the first to mention this.
> > >
> > > Did this change recently?  Maybe search circleci forums
> > discussions for
> > > background?   If you discover this is something configurable on the
> > > emscripten end please let is know and we can adjust the
> > relevant settings.
> > >
> > > cheers,
> > > sam
> > >
> > >
> > > On Tue, Oct 6, 2020 at 9:55 AM Sylvain Beucler  > 
> > > >> wrote:
> > >
> > > Hi,
> > >
> > > I noticed that CircleCI now redirects me to a login / connect
> your
> > > github account when I want to access an emscripten build log,
> e.g.
> > > https://circleci.com/gh/emscripten-core/emscripten/363781
> > >
> > > (actually it starts displaying the log, then redirects me
> anyway)
> > >
> > > The login page mentions "We ask for read/write access to make
> your
> > > experience seamless on CircleCI" which is not engaging.
> > >
> > > Is this known?
> > >
> > > Cheers!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/6e763435-21de-c578-7b2f-321474a9f7e6%40beuc.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTDC1DU%2Byebc92YS%3Duoh0gcEoPTY7YKU5SCY%3D_zejV31A%40mail.gmail.com.

Re: MAXIMUM_MEMORY supporting values based on browser

[Alon Zakai]

If you build with MAXIMUM_MEMORY=-1 that means "no specified limit". In
that case I think each browser should allow growth as much as it possibly
can.

(see src/settings.js for MAXIMUM_MEMORY for more details, including why
the default is 2GB and not -1, but basically, -1 has some minor code size
downsides)

On Thu, Oct 1, 2020 at 6:25 AM Brian Gavin  wrote:

> Now that Firefox supports wasm pthreads.   I would like to avoid having to
> make 2 versions of our WASM module.   Chrome supports a max memory of ~4GB
> and Firefox ~2GB.   Is there a way for me to have a different value for
> MAXIMUM_MEMORY based on the browser.   I am using it with pthreads and
> memory growth turned on.
>
> Thanks
> Brian Gavin
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/2bd79de4-65bc-445b-8dac-e8bd8bb6c802n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR07C03sh%2BCAo0WLTjWMU5JJuQHX1DUrJsqUBEpbN7T%3Dw%40mail.gmail.com.

Re: 2.0.3 getMemory is undefined

[Alon Zakai]

You can add this:

function getMemory() {
  abort(new Error().stack);
}

and then when it is called it will halt with a stack trace. That can help
figure out what is calling it. (Make sure to build with --profiling so the
stack trace is clear.)


On Mon, Sep 14, 2020 at 7:53 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Can you give steps to reproduce?   Perhaps you can open an issue in the
> bug tracker?
>
> Can you tell which JS function is referencing `getMemory`?It should
> be removed from the codebase (except if `-s MAIN_MODULE`  is used).
>
> cheers,
> sam
>
>
> On Sun, Sep 13, 2020 at 8:24 PM Александр Гурьянов 
> wrote:
>
>> Sorry I don't understand what I should do. This error happens on a
>> regular codebase without something special (just libzip and extraction
>> code). I use emsdk, emcmake, cmake and make to compile it. I don't
>> call getMemory or dynamicAlloc from my side, I mean how can I call
>> them before instantiation is finished? There is some pattern in C/C++
>> code that results in this behaviour?
>>
>> P. S. 2.0.2 works fine.
>>
>> пн, 14 сент. 2020 г. в 10:16, 'Sam Clegg' via emscripten-discuss
>> :
>> >
>> > These functions were removed since we managed to remove all our
>> allocations that occurred before startup.
>> >
>> > This is/was an important thing for us to do as it allows wasm-ld (the
>> static linker) to fully determine memory layout and specifically heap
>> location without the need for post-link modifications to the wasm binary.
>> >
>> > You should be able simply call `_malloc` instead, or move your
>> allocation in a C/C++ global?   These are the two approaches that we used
>> to remove all or our internal usage of dynamicAlloc.
>> >
>> > cheers,
>> > sam
>> >
>> > On Sun, Sep 13, 2020 at 8:04 PM Александр Гурьянов 
>> wrote:
>> >>
>> >> Hi. Just updated emscripten to 2.0.3, everything builds fine but now I
>> >> have error on module instantiation:
>> >>
>> >> ReferenceError: getMemory is not defined
>> >>
>> >> I checked the generated code of Module, and it have:
>> >>
>> >> Module["getMemory"] = getMemory;
>> >>
>> >> but getMemory itself never defined, for example in previous version it
>> was:
>> >>
>> >> function getMemory(size) {
>> >> if (!runtimeInitialized) return dynamicAlloc(size);
>> >> return _malloc(size)
>> >> }
>> >> Also dynamicAlloc is not there.
>> >>
>> >> There are some new compiler flags?
>> >> Thanks
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVG-dBKPFWGowBuV7Ah%3DA1TLR1koBPBmJhNAY3cd4TcM0Q%40mail.gmail.com
>> .
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-1kXWHTVq4XCSzpJMvFhjEae45j3sG7JvM%2BBbUCQtUBA%40mail.gmail.com
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF5o2iDfMa-qcBp53PA-z_NuMqMnyakuDFGWnUV1DzMiw%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2__y6Bd4M-oR6VpskT%3DGdAqTcp8O1WKnf4hY6itRHz_mQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpT636rWjiPVqRFEe5punQHS_fieKYZsN_7bGE7yFr7wXQ%40mail.gmail.com.

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi 
wrote:

> That's interesting to know that ALLOW_MEMORY_GROWTH already works with
> PThreads. I will try to do some tests and see how that goes.
>
> Could you tell if there is any performance impact on writing strings
> (using Module._malloc()) or binary data to the heap, with
> ALLOW_MEMORY_GROWTH on PThreads. Also I am assuming there is no/very less
> impact of going from JS to C++ via ccall or embind. Please correct me if I
> am wrong.
>
>
Writing data from JS to memory can be slower, including writing strings.
But hopefully not by much. Nothing else should be affected.


> Also upon enabling ALLOW_MEMORY_GROWTH on our project, there are lots of
> warning being thrown up in the console. Is there any switch that I could
> use to disable this warning?
>
> root:WARNING: USE_PTHREADS + ALLOW_MEMORY_GROWTH may run non-wasm code
> slowly, see https://github.com/WebAssembly/design/issues/1271
>
>
We could add a flag to allow disabling that warning. I think it could
use diagnostics.warning() in emcc.py instead of just printing it
unconditionally. A PR would be welcome, or an issue.


> Thanks,
> Prashanth
> On Friday, August 28, 2020 at 10:15:38 PM UTC+5:30 alon...@gmail.com
> wrote:
>
>> On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi 
>> wrote:
>>
>>> Thanks for the information Alon! That is exactly the information I
>>> wanted. Your theory of deferred memory usage pattern might be the reason
>>> for browsers reporting used memory differently.
>>>
>>> It is unfortunate that we will not be able to use PThreads in our main
>>> Wasm because of this limitation, as we have lot of JS running alongside
>>> Wasm. Any rough timeline on when we can expect ALLOW_MEMORY_GROWTH to work
>>> with PTHREADS?
>>>
>>
>> It already works, but memory access from JS is somewhat slower. In most
>> cases you won't notice that, though - unless you've already tested and see
>> overhead? If so that could be useful to mention to the standards bodies
>> that are considering a spec change that could improve this, it could
>> increase the priority.
>>
>> - Alon
>>
>>
>>> Also about checking the memory usage in devtools, I am using Chrome's
>>> task manager as well as Activity Monitor (both on Mac) to check the
>>> webpage's memory footprint. At both the places, the 2GB reserved memory is
>>> not getting reflected. Maybe I am missing on checking other relevant
>>> fields. But that should be fine, as I got the required information from you.
>>>
>>> Appreciate the help Alon!
>>>
>>> Thanks,
>>> Prashanth Nethi
>>>
>>> On Friday, August 28, 2020 at 12:23:24 AM UTC+5:30 alon...@gmail.com
>>> wrote:
>>>
 On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
 wrote:

> My bad Alon! I will try to elaborate the scenario.I am trying to
> understand the implications of switching off ALLOW_MEMORY_GROWTH in our
> project. (which would be the case if we want  PTHREADS enabled).
>
> The question is around, what if we set INITIAL_VALUE value to max
> value (2GB).  Does that mean when WASM is instantiated with
> INITIAL_VALUE=2048MB, 2GB is reserved right upfront, even if not required
> right away? If yes, does that mean this will reduce the usable JS heap 
> size
> (by 2GB), right from the beginning?
>

 Yes, exactly. An initial value of X means X is allocated right from the
 start. Yes, this reduces available memory for other things, which can have
 downsides.


> When I instantiate WASM (in my test app) with an INITIAL_VALUE=2000MB
> and check for the memory that specific webpage is taking, I see that page
> does not take 2GB but a lot lesser.
>

 How are you measuring that?

 It's possible the browser allocates that memory via calloc() or such,
 and maybe the OS doesn't actually use any physical memory until those pages
 are touched, though. So maybe only virtual memory is used initially. (But
 even that can cause problems on 32 bit due to address space limits.)

 Measuring via browser devtools should report the full 2GB is used
 immediately.


> It is when I start acquiring more memory, the memory usage goes up
> until it hits the 2GB limit. Surprisingly this is the same behaviour I see
> with  ALLOW_MEMORY_GROWTH =1, USE_PTHREADS=0 (i.e. with PThreads 
> disabled).
> So trying to understand the dynamics and come up with the recommendation 
> on
> whether to enable or not enable PTHREADS in our app. FYI. The app has the
> requirement to load on various browsers and devices, with Chrome and
> Chromebook being our majority targets.
>
>
> Regards,
> Prashanth Nethi
>
> On Thursday, August 27, 2020 at 10:07:55 PM UTC+5:30 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
>> wrote:
>>
>>> Thanks Alon! That explains it! Yeah I should have thought a little

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi 
wrote:

> Thanks for the information Alon! That is exactly the information I wanted.
> Your theory of deferred memory usage pattern might be the reason for
> browsers reporting used memory differently.
>
> It is unfortunate that we will not be able to use PThreads in our main
> Wasm because of this limitation, as we have lot of JS running alongside
> Wasm. Any rough timeline on when we can expect ALLOW_MEMORY_GROWTH to work
> with PTHREADS?
>

It already works, but memory access from JS is somewhat slower. In most
cases you won't notice that, though - unless you've already tested and see
overhead? If so that could be useful to mention to the standards bodies
that are considering a spec change that could improve this, it could
increase the priority.

- Alon


> Also about checking the memory usage in devtools, I am using Chrome's task
> manager as well as Activity Monitor (both on Mac) to check the webpage's
> memory footprint. At both the places, the 2GB reserved memory is not
> getting reflected. Maybe I am missing on checking other relevant fields.
> But that should be fine, as I got the required information from you.
>
> Appreciate the help Alon!
>
> Thanks,
> Prashanth Nethi
>
> On Friday, August 28, 2020 at 12:23:24 AM UTC+5:30 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
>> wrote:
>>
>>> My bad Alon! I will try to elaborate the scenario.I am trying to
>>> understand the implications of switching off ALLOW_MEMORY_GROWTH in our
>>> project. (which would be the case if we want  PTHREADS enabled).
>>>
>>> The question is around, what if we set INITIAL_VALUE value to max value
>>> (2GB).  Does that mean when WASM is instantiated with INITIAL_VALUE=2048MB,
>>> 2GB is reserved right upfront, even if not required right away? If yes,
>>> does that mean this will reduce the usable JS heap size (by 2GB), right
>>> from the beginning?
>>>
>>
>> Yes, exactly. An initial value of X means X is allocated right from the
>> start. Yes, this reduces available memory for other things, which can have
>> downsides.
>>
>>
>>> When I instantiate WASM (in my test app) with an INITIAL_VALUE=2000MB
>>> and check for the memory that specific webpage is taking, I see that page
>>> does not take 2GB but a lot lesser.
>>>
>>
>> How are you measuring that?
>>
>> It's possible the browser allocates that memory via calloc() or such, and
>> maybe the OS doesn't actually use any physical memory until those pages are
>> touched, though. So maybe only virtual memory is used initially. (But even
>> that can cause problems on 32 bit due to address space limits.)
>>
>> Measuring via browser devtools should report the full 2GB is used
>> immediately.
>>
>>
>>> It is when I start acquiring more memory, the memory usage goes up until
>>> it hits the 2GB limit. Surprisingly this is the same behaviour I see with
>>> ALLOW_MEMORY_GROWTH =1, USE_PTHREADS=0 (i.e. with PThreads disabled). So
>>> trying to understand the dynamics and come up with the recommendation on
>>> whether to enable or not enable PTHREADS in our app. FYI. The app has the
>>> requirement to load on various browsers and devices, with Chrome and
>>> Chromebook being our majority targets.
>>>
>>>
>>> Regards,
>>> Prashanth Nethi
>>>
>>> On Thursday, August 27, 2020 at 10:07:55 PM UTC+5:30 alon...@gmail.com
>>> wrote:
>>>
 On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
 wrote:

> Thanks Alon! That explains it! Yeah I should have thought a little
> deeper.
>
> I am just posting my follow up question in case you did not get a
> chance to look at it.
>
> One follow up question. May be a dumb one. What could be the potential
> problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that 
> when
> the Wasm is instantiated, the overall memory that the Chrome tab was 
> taking
> was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. 
> Is
> it that, we will not be able to instantiate WASM on low end devices if
> built with ALLOW_MEMORY_GROWTH=0?
>
>
 I'm not sure what you're asking here?

 In general, not having memory growth enabled means that memory can't
 grow. So if you need more than the initial value, the program will hit a
 problem. I don't think there's anything special to pthreads in that case.
 (The reverse, having growth *enabled*, does have downsides for pthreads as
 the JS use of memory becomes somewhat slower.)

 Regards,
> Prashanth Nethi
>
> On Thursday, August 27, 2020 at 2:37:07 AM UTC+5:30 alon...@gmail.com
> wrote:
>
>> My guess is that's because of the behavior of std::vector and how it
>> resizes. Over those appends it will malloc and free repeatedly and that 
>> may
>> cause fragmentation that prevents a final larger size, which must be a
>> single contiguous region. The second version allocates 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
wrote:

> My bad Alon! I will try to elaborate the scenario.I am trying to
> understand the implications of switching off ALLOW_MEMORY_GROWTH in our
> project. (which would be the case if we want  PTHREADS enabled).
>
> The question is around, what if we set INITIAL_VALUE value to max value
> (2GB).  Does that mean when WASM is instantiated with INITIAL_VALUE=2048MB,
> 2GB is reserved right upfront, even if not required right away? If yes,
> does that mean this will reduce the usable JS heap size (by 2GB), right
> from the beginning?
>

Yes, exactly. An initial value of X means X is allocated right from the
start. Yes, this reduces available memory for other things, which can have
downsides.


> When I instantiate WASM (in my test app) with an INITIAL_VALUE=2000MB and
> check for the memory that specific webpage is taking, I see that page does
> not take 2GB but a lot lesser.
>

How are you measuring that?

It's possible the browser allocates that memory via calloc() or such, and
maybe the OS doesn't actually use any physical memory until those pages are
touched, though. So maybe only virtual memory is used initially. (But even
that can cause problems on 32 bit due to address space limits.)

Measuring via browser devtools should report the full 2GB is used
immediately.


> It is when I start acquiring more memory, the memory usage goes up until
> it hits the 2GB limit. Surprisingly this is the same behaviour I see with
> ALLOW_MEMORY_GROWTH =1, USE_PTHREADS=0 (i.e. with PThreads disabled). So
> trying to understand the dynamics and come up with the recommendation on
> whether to enable or not enable PTHREADS in our app. FYI. The app has the
> requirement to load on various browsers and devices, with Chrome and
> Chromebook being our majority targets.
>
>
> Regards,
> Prashanth Nethi
>
> On Thursday, August 27, 2020 at 10:07:55 PM UTC+5:30 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
>> wrote:
>>
>>> Thanks Alon! That explains it! Yeah I should have thought a little
>>> deeper.
>>>
>>> I am just posting my follow up question in case you did not get a chance
>>> to look at it.
>>>
>>> One follow up question. May be a dumb one. What could be the potential
>>> problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that when
>>> the Wasm is instantiated, the overall memory that the Chrome tab was taking
>>> was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. Is
>>> it that, we will not be able to instantiate WASM on low end devices if
>>> built with ALLOW_MEMORY_GROWTH=0?
>>>
>>>
>> I'm not sure what you're asking here?
>>
>> In general, not having memory growth enabled means that memory can't
>> grow. So if you need more than the initial value, the program will hit a
>> problem. I don't think there's anything special to pthreads in that case.
>> (The reverse, having growth *enabled*, does have downsides for pthreads as
>> the JS use of memory becomes somewhat slower.)
>>
>> Regards,
>>> Prashanth Nethi
>>>
>>> On Thursday, August 27, 2020 at 2:37:07 AM UTC+5:30 alon...@gmail.com
>>> wrote:
>>>
 My guess is that's because of the behavior of std::vector and how it
 resizes. Over those appends it will malloc and free repeatedly and that may
 cause fragmentation that prevents a final larger size, which must be a
 single contiguous region. The second version allocates many smaller ones,
 not a single contiguous region.

 - Alon


 On Tue, Aug 25, 2020 at 11:24 PM Prashanth Nethi 
 wrote:

> Thanks Alon! So here is something very weird. I could get the memory
> usage go all the way to 2GB when I changed my testing code. This was my
> original test code. So basically I was just adding elements to std::vector
> infinitely.
>
> class TestClass{
>  private:
>   int t = 0;
> };
>
> struct Data {
>  int t;
>  TestClass obj;
> };
>
> typedef std::vector Vec;
>
> Vec someVec;
>
> using namespace std;
>
> int main() {
>  printf("hello, world!\n");
>
>  while(1){
>   Data data;
>   someVec.push_back(data);
>  }
>
>  return 0;
> }
>
> With this code, the WASM memory was going all the way to 1GB.
>
> But when I changed the code to this, where I am writing some value
> after acquiring memory, then I am able to see the memory usage go all the
> way up to 2 GB. Could this be a bug? I am on emscripten 2.0.
>
>
> int main() {
>   printf("hello, world!\n");
>   char *p = nullptr;
>   int byteSize = 50 * 1024 * 1024;
>   while(1){
> p = new char(byteSize);
> p[byteSize] = 20;
>   }
>   return 0;
> }
>
> Also It is very encouraging to see that 4GB is considered for PThreads
> as well! Thanks.
>
> One follow up question. May be a dumb one. What 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
wrote:

> Thanks Alon! That explains it! Yeah I should have thought a little deeper.
>
> I am just posting my follow up question in case you did not get a chance
> to look at it.
>
> One follow up question. May be a dumb one. What could be the potential
> problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that when
> the Wasm is instantiated, the overall memory that the Chrome tab was taking
> was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. Is
> it that, we will not be able to instantiate WASM on low end devices if
> built with ALLOW_MEMORY_GROWTH=0?
>
>
I'm not sure what you're asking here?

In general, not having memory growth enabled means that memory can't grow.
So if you need more than the initial value, the program will hit a problem.
I don't think there's anything special to pthreads in that case. (The
reverse, having growth *enabled*, does have downsides for pthreads as the
JS use of memory becomes somewhat slower.)

Regards,
> Prashanth Nethi
>
> On Thursday, August 27, 2020 at 2:37:07 AM UTC+5:30 alon...@gmail.com
> wrote:
>
>> My guess is that's because of the behavior of std::vector and how it
>> resizes. Over those appends it will malloc and free repeatedly and that may
>> cause fragmentation that prevents a final larger size, which must be a
>> single contiguous region. The second version allocates many smaller ones,
>> not a single contiguous region.
>>
>> - Alon
>>
>>
>> On Tue, Aug 25, 2020 at 11:24 PM Prashanth Nethi 
>> wrote:
>>
>>> Thanks Alon! So here is something very weird. I could get the memory
>>> usage go all the way to 2GB when I changed my testing code. This was my
>>> original test code. So basically I was just adding elements to std::vector
>>> infinitely.
>>>
>>> class TestClass{
>>>  private:
>>>   int t = 0;
>>> };
>>>
>>> struct Data {
>>>  int t;
>>>  TestClass obj;
>>> };
>>>
>>> typedef std::vector Vec;
>>>
>>> Vec someVec;
>>>
>>> using namespace std;
>>>
>>> int main() {
>>>  printf("hello, world!\n");
>>>
>>>  while(1){
>>>   Data data;
>>>   someVec.push_back(data);
>>>  }
>>>
>>>  return 0;
>>> }
>>>
>>> With this code, the WASM memory was going all the way to 1GB.
>>>
>>> But when I changed the code to this, where I am writing some value after
>>> acquiring memory, then I am able to see the memory usage go all the way up
>>> to 2 GB. Could this be a bug? I am on emscripten 2.0.
>>>
>>>
>>> int main() {
>>>   printf("hello, world!\n");
>>>   char *p = nullptr;
>>>   int byteSize = 50 * 1024 * 1024;
>>>   while(1){
>>> p = new char(byteSize);
>>> p[byteSize] = 20;
>>>   }
>>>   return 0;
>>> }
>>>
>>> Also It is very encouraging to see that 4GB is considered for PThreads
>>> as well! Thanks.
>>>
>>> One follow up question. May be a dumb one. What could be the potential
>>> problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that when
>>> the Wasm is instantiated, the overall memory that the Chrome tab was taking
>>> was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. Is
>>> it that, we will not be able to instantiate WASM on low end devices if
>>> built with ALLOW_MEMORY_GROWTH=0?
>>>
>>> Greatly appreciate your help Alon!
>>>
>>> Thanks,
>>> Prashanth Nethi
>>>
>>> On Saturday, August 22, 2020 at 1:50:57 AM UTC+5:30 alon...@gmail.com
>>> wrote:
>>>
 I think you can do any number up to 2GB, including 2GB - 64Kb. So the
 limit isn't 1GB, unless you see that on some specific browser? Could be a
 bug.

 It should soon be possible to do up to 4GB for the initial memory
 (without growth), thanks to a spec change,
 https://github.com/WebAssembly/spec/pull/1174

 On Thu, Aug 20, 2020 at 8:10 AM Prashanth Nethi 
 wrote:

> Hi,
>
> I am currently building WASM with the following flags, to enable
> PThreads in Wasm.
> -s USING_PTHREADS=1 -s INITIAL_MEMORY=1999MB -s MAXIMUM_MEMORY=2GB.
>
> This works wonderfully for our use cases! In fact we are able to get
> 2x performance in some cases!
>
> When I checked the max memory that the Wasm could use, with PThreads
> enabled, it got capped at 1 GB. I am seeing that when the WASM is built
> with ALLOW_MEMORY_GROWTH, the Wasm can use upto 2GB. I know that
> ALLOW_MEMORY_GROWTH with USE_PTHREADS is discouraged so can't look at that
> as a possible solution.
>
> Is there anyway I can get Wasm to use 2GB (or even potentially 4GB in
> the future) with PThreads enabled? Is it that I am missing using some
> configuration options?
>
> I am really hoping there is a way to increase the WASM cap to 2GB, as
> using PThreads, solves our use cases in a big way.
>
> Thanks,
> Prashanth Nethi
>
> --
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop 

Re: how to disable binaryen in .emscripten config file

[Alon Zakai]

There isn't an option for that. You might try to modify emcc.py to make it
not call binaryen. I think that could work - but you'd get a much less
optimized wasm, which on a project of that size could be a problem.

It's probably best to build binaryen manually - it's much simpler and
smaller than building fastcomp or any LLVM fork. Just cmake, make should
work.

On Wed, Aug 26, 2020 at 8:11 AM r0l...@freemail.hu 
wrote:

>
> Hi All,
>
> I'm trying to crosscompile qt5 (5.15) with emscripten and they require
> emscripten 1.39.8 with fastcomp backend. However, that version cannot be
> built from source (which is a pity since prebuilt linux binary won't work
> on my NetBSD box). So I built fastcomp manually and pointed LLVM_ROOT to
> it. It works fine until qt stops during crosscompiling and I can see from
> the config.log that it's missing stuff from binaryen (like wasm-opt) which
> I guess is due to the fact that it compiles with WASM=1. Indeed, in the
> .emscripten config file BINARYEN_ROOT is also set since 1.39.8 is not
> fastcomp specific.
>
> So is it possible to set an environment variable in .emscripten that
> disables binaryen and results as if my emscripten installation has only
> fastcomp backend?
>
> Thanks,
> r0ller
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ad6b5d54-8a6c-4a0e-a8df-321d19c5a33an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRJ6ZpA-TEje8SUXXYSY1bJ-_M88mpFsLb%2BA-bzccVupg%40mail.gmail.com.

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

My guess is that's because of the behavior of std::vector and how it
resizes. Over those appends it will malloc and free repeatedly and that may
cause fragmentation that prevents a final larger size, which must be a
single contiguous region. The second version allocates many smaller ones,
not a single contiguous region.

- Alon


On Tue, Aug 25, 2020 at 11:24 PM Prashanth Nethi 
wrote:

> Thanks Alon! So here is something very weird. I could get the memory usage
> go all the way to 2GB when I changed my testing code. This was my original
> test code. So basically I was just adding elements to std::vector
> infinitely.
>
> class TestClass{
>  private:
>   int t = 0;
> };
>
> struct Data {
>  int t;
>  TestClass obj;
> };
>
> typedef std::vector Vec;
>
> Vec someVec;
>
> using namespace std;
>
> int main() {
>  printf("hello, world!\n");
>
>  while(1){
>   Data data;
>   someVec.push_back(data);
>  }
>
>  return 0;
> }
>
> With this code, the WASM memory was going all the way to 1GB.
>
> But when I changed the code to this, where I am writing some value after
> acquiring memory, then I am able to see the memory usage go all the way up
> to 2 GB. Could this be a bug? I am on emscripten 2.0.
>
>
> int main() {
>   printf("hello, world!\n");
>   char *p = nullptr;
>   int byteSize = 50 * 1024 * 1024;
>   while(1){
> p = new char(byteSize);
> p[byteSize] = 20;
>   }
>   return 0;
> }
>
> Also It is very encouraging to see that 4GB is considered for PThreads as
> well! Thanks.
>
> One follow up question. May be a dumb one. What could be the potential
> problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that when
> the Wasm is instantiated, the overall memory that the Chrome tab was taking
> was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. Is
> it that, we will not be able to instantiate WASM on low end devices if
> built with ALLOW_MEMORY_GROWTH=0?
>
> Greatly appreciate your help Alon!
>
> Thanks,
> Prashanth Nethi
>
> On Saturday, August 22, 2020 at 1:50:57 AM UTC+5:30 alon...@gmail.com
> wrote:
>
>> I think you can do any number up to 2GB, including 2GB - 64Kb. So the
>> limit isn't 1GB, unless you see that on some specific browser? Could be a
>> bug.
>>
>> It should soon be possible to do up to 4GB for the initial memory
>> (without growth), thanks to a spec change,
>> https://github.com/WebAssembly/spec/pull/1174
>>
>> On Thu, Aug 20, 2020 at 8:10 AM Prashanth Nethi 
>> wrote:
>>
>>> Hi,
>>>
>>> I am currently building WASM with the following flags, to enable
>>> PThreads in Wasm.
>>> -s USING_PTHREADS=1 -s INITIAL_MEMORY=1999MB -s MAXIMUM_MEMORY=2GB.
>>>
>>> This works wonderfully for our use cases! In fact we are able to get 2x
>>> performance in some cases!
>>>
>>> When I checked the max memory that the Wasm could use, with PThreads
>>> enabled, it got capped at 1 GB. I am seeing that when the WASM is built
>>> with ALLOW_MEMORY_GROWTH, the Wasm can use upto 2GB. I know that
>>> ALLOW_MEMORY_GROWTH with USE_PTHREADS is discouraged so can't look at that
>>> as a possible solution.
>>>
>>> Is there anyway I can get Wasm to use 2GB (or even potentially 4GB in
>>> the future) with PThreads enabled? Is it that I am missing using some
>>> configuration options?
>>>
>>> I am really hoping there is a way to increase the WASM cap to 2GB, as
>>> using PThreads, solves our use cases in a big way.
>>>
>>> Thanks,
>>> Prashanth Nethi
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/730a6796-5b14-4a9e-a1d8-298415c67cd1n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSZx34yEBhiFv2P2syhoNKqnZo713ROhFMH8qa6G_8gHQ%40mail.gmail.com.

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

I think you can do any number up to 2GB, including 2GB - 64Kb. So the limit
isn't 1GB, unless you see that on some specific browser? Could be a bug.

It should soon be possible to do up to 4GB for the initial memory (without
growth), thanks to a spec change,
https://github.com/WebAssembly/spec/pull/1174

On Thu, Aug 20, 2020 at 8:10 AM Prashanth Nethi 
wrote:

> Hi,
>
> I am currently building WASM with the following flags, to enable PThreads
> in Wasm.
> -s USING_PTHREADS=1 -s INITIAL_MEMORY=1999MB -s MAXIMUM_MEMORY=2GB.
>
> This works wonderfully for our use cases! In fact we are able to get 2x
> performance in some cases!
>
> When I checked the max memory that the Wasm could use, with PThreads
> enabled, it got capped at 1 GB. I am seeing that when the WASM is built
> with ALLOW_MEMORY_GROWTH, the Wasm can use upto 2GB. I know that
> ALLOW_MEMORY_GROWTH with USE_PTHREADS is discouraged so can't look at that
> as a possible solution.
>
> Is there anyway I can get Wasm to use 2GB (or even potentially 4GB in the
> future) with PThreads enabled? Is it that I am missing using some
> configuration options?
>
> I am really hoping there is a way to increase the WASM cap to 2GB, as
> using PThreads, solves our use cases in a big way.
>
> Thanks,
> Prashanth Nethi
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/730a6796-5b14-4a9e-a1d8-298415c67cd1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTsvoiK%2ByUJCbr%3DKCDk7RMSg2YoakhLoiDB%2B2NF2Y0LBg%40mail.gmail.com.

Re: Tip: Starting from recent emcc / Emscripten Module() now returns a Promise

[Alon Zakai]

I believe this is from 1.39.16, the changelog entry (
https://github.com/emscripten-core/emscripten/blob/master/ChangeLog.md#13916-05152020)
says


Change the factory function created by using the MODULARIZE build option to
return a Promise instead of the module instance. That is, beforehand

  Module()

would return an instance (which was perhaps not ready yet if startup was
async). In the new model, that returns a Promise which you can do .then or
await on to get notified when the instance is ready, and the callback
receives the instance. Note that both before and after this change doing
Module() creates and runs an instance, so the only change is the return
value from that call. This fixes some long-standing bugs with that option
which have been reported multiple times, but is a breaking change - sorry
about that. To reduce the risk of confusing breakage, in a build with
ASSERTIONS we will show a clear warning on common errors. For more, see
detailed examples for the current usage in src/settings.js on MODULARIZE.
(#10697)


Thanks Shlomi, good to mention this here as it might help others (I don't
think we mentioned it in the mailing list before).

- Alon


On Fri, Aug 21, 2020 at 5:24 AM Shlomi Fish  wrote:

> Hi all!
>
> I'm documenting a recent change in the semantics of Emscripten and emcc
> (starting from 1.39.x and also seems to affect 2.0.x): Module() now
> returns a
> promise and one should for example do:
>
> Module().then((result) => {
> real_module = result;
> })
>
> E.g like in
>
> https://github.com/shlomif/fc-solve/commit/dcdb924262860eb8d023402400fa1e8cd9dce6c2
> :
>
> diff --git a/fc-solve/site/wml/src/ts/web-fc-solve-tests.ts
> b/fc-solve/site/wml/src/ts/web-fc-solve-tests.ts index f3082e52f..d510bc4fa
> 100644 --- a/fc-solve/site/wml/src/ts/web-fc-solve-tests.ts
> +++ b/fc-solve/site/wml/src/ts/web-fc-solve-tests.ts
> @@ -494,7 +494,12 @@ export function test_js_fc_solve_class(qunit: QUnit,
> my_callback: () => void) { // var _my_mod = Module({});
>  const _my_mod = [null];
>  _my_mod[0] = Module()({
> -onRuntimeInitialized: my_func(qunit, _my_mod, my_callback),
> +onRuntimeInitialized: () => {
> +_my_mod[0].then((result) => {
> +_my_mod[0] = result;
> +return my_func(qunit, _my_mod, my_callback)();
> +});
> +},
>  });
>  return;
>  }
>
> (my code has a little weirdness of using "Module()()" instead of
> "Module()" -
> you can ignore that).
>
> For more about js promises, see:
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
>
> --
>
> Shlomi Fish   https://www.shlomifish.org/
> Perl Elems to Avoid - https://perl-begin.org/tutorials/bad-elements/
>
> There was one Napoleon, one George Washington, and one me!
> — Big Boy Caprice in
>https://en.wikiquote.org/wiki/Dick_Tracy_%281990_film%29
>
> Please reply to list if it's a mailing list post - https://shlom.in/reply
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/20200821152439.0cb14ca2%40telaviv1.shlomifish.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQmF-%2Bjc-6ihfJGgesRHg6mF7mP1zyqp-z1M44YeNa0gg%40mail.gmail.com.

Re: 2.0.0!

[Alon Zakai]

Thanks!

On Fri, Aug 21, 2020 at 6:09 AM robert.a...@gmail.com <
robert.aboukha...@gmail.com> wrote:

> Congrats to the team on the 2.0 release! And thank you for this awesome
> tool, don't know what we would do without it :)
>
>
> On Friday, August 21, 2020 at 5:14:41 AM UTC-7 Shlomi Fish wrote:
>
>> On Wed, 19 Aug 2020 08:25:26 -0700
>> Alon Zakai  wrote:
>>
>> > Hi everyone,
>> >
>> > Last week we released Emscripten 2.0.0. That's a big milestone as it's
>> the
>> > first version to not support the old fastcomp backend anymore,
>> >
>> > https://github.com/emscripten-core/emscripten/issues/11319
>> >
>> > You can still use it by using an older version (the last to support
>> > fastcomp is 1.40.1), but the new upstream backend is better in every
>> way!
>> > And it's been the default version when you install "latest" etc. for
>> quite
>> > a while now.
>> >
>>
>> Thanks, Alon [and all] for this release and other work on emscripten. I
>> got it
>> to work for https://fc-solve.shlomifish.org/js-fc-solve/text/
>> eventually.
>>
>> > This is also the first version to not support Python 2.*, and only
>> support
>> > 3.*
>> >
>> > Both of those don't have immediate benefits, but they are letting us do
>> a
>> > lot of cleanups and simplifications. See
>> >
>> > https://github.com/emscripten-core/emscripten/issues/11860
>> >
>> > We've already improved code quality quite a bit in just a week, and
>> there's
>> > a lot more to come. These simplifications will speed up development.
>> They
>> > will also unblock some things that were tricky to do while we supported
>> two
>> > backends, such as some link time improvements and better debugging
>> support
>> > - specifically we aim to do less during -O0 links, both for speed and
>> to
>> > properly preserve DWARF info (for example, one of the first parts of
>> that
>> > is in https://github.com/WebAssembly/binaryen/pull/3044).
>> >
>> > - Alon
>> >
>>
>>
>>
>> --
>>
>> Shlomi Fish https://www.shlomifish.org/
>> https://is.gd/i5eMQd - Emma Watson’s Interview for a Software Dev Job
>>
>> Chuck Norris was the 1,000,000,000th viewer of the Gangnam Style video on
>> YouTube. Summer Glau was the preceding 100 million views.
>> — https://www.shlomifish.org/humour/bits/facts/Summer-Glau/
>>
>> Please reply to list if it's a mailing list post - https://shlom.in/reply
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/da2b7c08-ac50-4cd4-86c9-46d9a13df38dn%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/da2b7c08-ac50-4cd4-86c9-46d9a13df38dn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQvsH92xWDCavWTyxbzgj9qN2yMCnxiVXjOW4javdqo0A%40mail.gmail.com.

2.0.0!

[Alon Zakai]

Hi everyone,

Last week we released Emscripten 2.0.0. That's a big milestone as it's the
first version to not support the old fastcomp backend anymore,

https://github.com/emscripten-core/emscripten/issues/11319

You can still use it by using an older version (the last to support
fastcomp is 1.40.1), but the new upstream backend is better in every way!
And it's been the default version when you install "latest" etc. for quite
a while now.

This is also the first version to not support Python 2.*, and only support
3.*

Both of those don't have immediate benefits, but they are letting us do a
lot of cleanups and simplifications. See

https://github.com/emscripten-core/emscripten/issues/11860

We've already improved code quality quite a bit in just a week, and there's
a lot more to come. These simplifications will speed up development. They
will also unblock some things that were tricky to do while we supported two
backends, such as some link time improvements and better debugging support
- specifically we aim to do less during -O0 links, both for speed and to
properly preserve DWARF info (for example, one of the first parts of that
is in https://github.com/WebAssembly/binaryen/pull/3044).

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSGZOqRrgY11A38pPf6r2U2aQxzFKLZ6-qYoC_iYjU9%2Bg%40mail.gmail.com.

Re: SharedArray support in Firefox

[Alon Zakai]

What is the error?

If it's COOP/COEP-related, then you need to set up your webserver properly,

https://web.dev/coop-coep/

Here is how the test suite does it:

https://github.com/emscripten-core/emscripten/blob/a85b3038738e8f027cf4acad6e272e8c3321ce3f/tests/runner.py#L1370

On Fri, Aug 7, 2020 at 9:36 AM Larry Kosher  wrote:

> Hello.
> It seems that the support has been reenabled in Firefox for
> SharedArrayBuffer:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBufferHowever
> my project still throws an error when I try to run it in the latest Mozilla
> browser. Is there a workaround?
> Best regards,
> Larry
> --
> Hiisi.
> Registered Linux User #487982. Be counted at: https://linuxcounter.net/
> --
> Spandex is a privilege, not a right.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAPZcXwZK0O9tW%2BWaPOLThXWReCD8NgOnRGMxSpUKT-f6mxUWBw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSkz4vB0bSi0A8mQWGYRM2X03cLnKh7rMX%2BYARGe%2BE1zw%40mail.gmail.com.

Re: emscripten_request_pointerlock() regression?

[Alon Zakai]

We don't have CI tests for pointerlock, so it's possible something
regressed. It would be great if someone has time to look into puppeteer or
another test framework that supports that.

I'd suggest bisecting to find when that happened. If it regressed, we
should add a test to `tests/test_interactive.py` which we at least run
manually now and then.

On Thu, Jul 30, 2020 at 12:54 PM Floh  wrote:

> Hi,
>
> is anybody using the emscripten pointerlock functions and noticed any
> problems that pointer lock doesn't activate when
> emscripten_request_pointerlock() is called from within a mouse button event
> handler? I definitely had this working in old SDK versions (2 years ago or
> so, for instance see here:
> https://floooh.github.io/oryol-samples/wasm/BulletPhysicsBasic.html), but
> with the current SDK version it looks like I always get a
> EMSCRIPTEN_RESULT_FAILED_NOT_DEFERRED result even though I'm sure I'm
> calling it from within an event handler type which doesn't require deferred
> execution (specifically: on left mouse button down).
>
> I'm requesting pointer-lock like this:
>
> emscripten_request_pointerlock(canvas_name, false);
>
> I'm now working around the problem by not calling
> emscripten_request_pointerlock() and emscripten_exit_pointerlock() but
> instead use my own EM_JS() functions, this appears to work fine (called
> from the same place where I called the emscripten API functions).
>
> The pointerlockchange_callback works fine though.
>
> Cheers,
> -Floh.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/fbe7df6d-7cef-4a5f-9b91-da70bcb58b0an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS8K2fXnsFANbuRa9M1_hq1JJp6mzR1qOEbOrzxwr9taA%40mail.gmail.com.

Re: New undefined errors with emcc 1.40

[Alon Zakai]

I think this is

https://github.com/emscripten-core/emscripten/issues/11771

Sorry about this regression - please use the previous release until we tag
a new one with a fix.


On Fri, Jul 31, 2020 at 1:50 PM キャロウ マーク  wrote:

> When compiling my project with emcc 1.40 we get the following errors that
> did not appear with 1.39.5;
>
> > emcc --version
> emcc (Emscripten gcc/clang-like replacement) 1.40.0 
> (634dfe9c7837119d3970c4145984b8f517e3e1ca)
>
> > cmake --build build-web-release --config Release
> [54/54] Linking CXX executable libktx.js
> FAILED: libktx.js
> error: undefined symbol: _tempFixedLengthArray (referenced by 
> emscripten_glInvalidateFramebuffer__deps: ['_tempFixedLengthArray'], 
> referenced by top-level compiled C/C++ code)
> warning: Link with `-s LLD_REPORT_UNDEFINED` to get more information on 
> undefined symbols
> warning: To disable errors for undefined symbols use `-s 
> ERROR_ON_UNDEFINED_SYMBOLS=0`
> warning: __tempFixedLengthArray may need to be added to EXPORTED_FUNCTIONS if 
> it arrives from a system library
> error: undefined symbol: _heapObjectForWebGLType (referenced by 
> emscripten_glTexImage3D__deps: 
> ['_heapObjectForWebGLType','_heapAccessShiftForWebGLHeap'], referenced by 
> top-level compiled C/C++ code)
> warning: __heapObjectForWebGLType may need to be added to EXPORTED_FUNCTIONS 
> if it arrives from a system library
> error: undefined symbol: _heapAccessShiftForWebGLHeap (referenced by 
> emscripten_glTexImage3D__deps: 
> ['_heapObjectForWebGLType','_heapAccessShiftForWebGLHeap'], referenced by 
> top-level compiled C/C++ code)
> warning: __heapAccessShiftForWebGLHeap may need to be added to 
> EXPORTED_FUNCTIONS if it arrives from a system library
> Error: Aborting compilation due to previous errors
>
>
> Was something changed in the GL ES emulation?
>
> Why would it have worked before without adding these things to
> EXPORTED_FUNCTIONS?
>
> Regards
>
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/4C3D2F01-76C6-4251-A837-58E854EED8EB%40callow.im
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQaG9_x0eTe6ULcmSEzdBB3n7VCkbgNnV_8TTLxG9FXwg%40mail.gmail.com.

Re: 'standalone' wasm w/o wasi?

[Alon Zakai]

Standalone mode will require WASI if it does things like logging. Wasm by
itself doesn't have an API for that, so we need *something*, and we try to
use standard APIs as much as possible (see
https://v8.dev/blog/emscripten-standalone-wasm#let's-unify-as-much-as-possible
).

That is, if you see "fd_write" being required, that means logging is done
in the wasm module, so to run in wasm-interp we'd need an API to do that,
and WASI is the most standard API for that, so we use it.

If a program does *not* do any logging, then no fd_write will be imported.
So WASI is not a general requirement when in standalone mode.

There's nothing special about WASI here. Standalone mode tries not to use
external APIs as much as possible - it does what it can inside the wasm.
When it does need to use an API, it will import it. That can in theory be
any API emscripten supports, not just WASI, it depends on the APIs your
code needs - for example if you use a GL method like glBufferData it will
import that (and a custom runtime can then decide to add support for that
API, say in a game engine that wants GL-doing plugins).




On Fri, Jul 24, 2020 at 12:39 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> TL;DR: does STANDALONE_WASM=1 imply WASI-required?
>
> I've been building my wasm code with STANDALONE_WASM=1. This runs in d8
> just fine (though it still requires the .js wrapper to launch), and also in
> wasm-interp, but only if I build WASI support into wasm-interp (otherwise
> I'll fail with things like `invalid import
> "wasi_snapshot_preview1.fd_write"`).
>
> The comments in Emscripten's settings.js regarding STANDALONE_WASM don't
> seem entirely clear on this front. My assumption at the moment is
> that STANDALONE_WASM=0 means "You will almost certainly require JS and
> WASM" (which is fine), but STANDALONE_WASM=1 apparently means "You might
> require JS and/or WASI in addition to WASM".
>
> (The motivation here is that I'd like to use wabt's wasm-interp in a
> configuration without WASI, but it's not clear to me whether there is a set
> of flags for Emscripten that will reliably produce standalone wasm that
> requires neither WASI nor other JS-specific imports from "env".)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3DdnvfwXFpSG0N%2BfG-Us02bSFASTFeLS_9JewN8S4G5ijreYQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRftpJOqhkVbZqvBJZCWM8yGT340kiukcchaeVu9m9Jtg%40mail.gmail.com.

Re: Threading from a Web Worker

[Alon Zakai]

Interesting, so this can use pthreads from the main thread ok, but not when
starting from a pthread?

That is a less-tested use case, so it's possible you've run into a bug.
Building with -s PTHREADS_DEBUG may help with extra logging. But it may be
best to try to reduce this to a small testcase, as it may need to be
debugged in depth.

On Thu, Jul 23, 2020 at 7:46 AM Segmentation Fault Error <
segmentation.fault.er...@gmail.com> wrote:

> Hello everyone,
>
>
>
> I have been using for a while emscripten to compile a large library. Since
> its operations take long time, I moved the module to a web worker, where I
> can call functions without blocking the UI. And it has worked fantastic so
> far!
>
>
>
> To further improve performance, I then enabled pthreads in the toolchain.
> I noticed then that the execution got stuck. Somehow this issue does not
> occur if the module is executed on the main UI thread, instead of the web
> worker.
>
>
>
> I have left a link below, to the demo code on how to reproduce the issue:
> a function that launches a thread, that launches several threads. It
> happens that this second level never gets executed if the function was
> called from a web worker.
>
>
>
> Maybe I am missing something here, any idea?
>
>
>
> Regards,
>
> SFE
>
> Link:
> https://drive.google.com/file/d/1EtkdRBN1Y8QpsRE19BH5AePAD3VLAV6U/view?usp=sharing
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/141a16e4-647e-484c-b36a-8db45addaec8o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTp2Zjoc_OfVO9z2Sq4x1mGDh8PenYO7EJdT%3DOeAv12sA%40mail.gmail.com.

Re: Running a headless googletest with XHR in a browser

[Alon Zakai]

This is a good question, and I'm curious to see what people suggest, but I
see you posted the same question both here and on github - let's please
continue the discussion there, so that the conversation isn't split between
two places,

https://github.com/emscripten-core/emscripten/issues/11700

In general I think it's best not to post duplicates to multiple places
simultaneously. It can be confusing if two separate discussions start up
and people need to remember what was said in which. It also makes searching
for similar issues harder in the future. Also many people are subscribed to
both places and they get duplicate notifications.

On Wed, Jul 22, 2020 at 7:58 PM Jörn Guy Süß  wrote:

> We are building a C++ in-browser project and want to use googletest and
> ctest for our CI loop to test functionality that requires XHR and
> Emscripten's -fetch library. In the emscripten code base we find:
> emscripten/tests/fetch/example_stream_async_xhr.cpp
>
> We have changed this code and linked it as a test with GTest framework
> main harness. This gives us a test binary. We can get it to run
> with emrun and print the GTest test report to stdout if we link with with
> the -emrun linker flag
> 
> .
>
> We are aware of the Emscripten test runner
>  
> but
> do not know how to combine it with ctest.
>
> We have two questions:
>
>1. How do you run a test interactively using emrun in a *headless*
> browser.
>2. How do you configure emrun so *the browser exits after the test
>exits*.
>
> We can provide the test code, but this question is not about the code, but
> about the configuration of a headless test runtime when a browser is
> required.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/d149c45d-f106-4367-b14c-d06bf54aae23n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRxzEsOBMB%3DBG1cR%2B8s0Wc-0XdORH2Lb4x0QX3kRxW8bg%40mail.gmail.com.

Re: ENV not working with MODULARIZE=1, even trying workarounds

[Alon Zakai]

I believe we have tests for this, so one option is to look there (grepping
for `getenv()` in tests/, etc.).

But it is possible there is a bug here. So also worth doing is trying to
make a small testcase showing where preRun fails to work as you expect.
That might either show a bug, or help understand what you're doing
differently than the test suite.

I think there is indeed a "window" of time - first ENV needs to exist at
all, as some JS creates it. That happens when the JS is evaluated. Then
when the program starts to run and we execute main(), one of the global
constructors will I believe copy the ENV data from JS into memory that C
can access. That is done once. And a preRun should occur exactly in between
those, as it's defined as running after the JS is evaluated (it has to, as
the JS has to be evaluated for anything to happen) and before running the
compiled code.



On Sun, Jul 19, 2020 at 2:26 PM Hostile Fork  wrote:

> I noticed that getenv() stopped working for me after switching to
> MODULARIZE=1.  There is a related thread here about it:
>
> https://github.com/emscripten-core/emscripten/issues/9827
>
> It seems that snippets from that resolved it for some people, but not for
> me.  Here's what I'm seeing:
>
> * If I do not export the ENV variable, then `modularized_module.ENV` will
> be a function that tells you that you have to export ENV.  If you do that,
> then anything you put as ENV in the options object passed to your
> modularize factory function (e.g. opts.ENV.X = '1') will be overwritten
> with an empty object.
>
> * Advice from the documentation on "Interacting with Code" says "Care must
> be taken to ensure that the ENV variable has been initialised by Emscripten
> before it is modified -- using Module.preRun is a convenient way to do
> this."  We might assume this empty object is that initialized object.  Okay.
>
> * I can add things to this object with `opts.preRun = (mod) => { mod.ENV.X
> = "1"}` or in `factory(opts).then((mod) => {mod.ENV.X = "1"})`.  Neither
> method seems to have getenv() return anything but null for what is added.
>
> To try and get a better understanding, I exported _getenv() and call it
> directly from JavaScript with a stringToUTF8() of the variable.  As far as
> I can tell from stepping into the compiled wasm, it is this implementation
> from musl:
>
>
> https://github.com/emscripten-core/emscripten/blob/master/system/lib/libc/musl/src/env/getenv.c
>
> This doesn't call any functions for consulting a JavaScript object's
> state.  That is to say: it seems that the environment is captured at some
> early point, and cannot be changed except through calls to setenv().  This
> would imply that JavaScript setting of an "ENV" variable can only influence
> the environment *before* that first capture--it is not sync'd after that.
> And the documentation say it can only work *after* an object has been
> initialized.  So it's some kind of time window.
>
> I'm not sure when this moment of capture would be.  But as the thread
> suggests using preRun() as the place to set it...I gather waiting until the
> factory function gives you a completed module may be too late.
>
> That still doesn't explain why setting options on the created-for-me ENV
> object during preRun() isn't working.  I can see that the assignment
> happened, because the module I get back from the factory function has its
> ENV set to what I added.  (There are no other variables in the enviroment
> object added by the system.)
>
> Any ideas on where I might look next?  :-/
>
> --
>
> (Note: If I'm right about this "ENV is captured to the wasm heap and then
> after that point there is no interaction with JS", then it seems it would
> be good if after that point the ENV variable were turned to an erroring
> function--at least in debug builds--that says the environment is no longer
> up to date.  Perhaps the object in configuration could be moved to
> something like ENV_STALE if you wanted to know what the environment was
> before the capture.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/0d62ed76-0fe8-44e4-a35b-01dce19d359co%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTra0sEZfcZ-BHNCOoUb5z7Ge%2BkryG_bifPgY2nLFsgHw%40mail.gmail.com.

Re: Newlines from C-domain are removed (or so it seems)

[Alon Zakai]

I'd be curious if you can find a better way to solve this. The current
situation, as you described, is the best we've come up with so far, given
the limitation that console.log always adds a newline (so we need to not
send it a newline, and instead buffer until one is reached, then send the
line without that).

You can experiment with that in the JS FS layer, in src/library_fs.js, and
in a custom Module['stdout'] that it calls (see the code that calls
Module['stdout'] in that file).

On Thu, Jul 16, 2020 at 5:10 AM Bernhard Ege  wrote:

> I have now examined the issue a bit more, and the issue (for me) is that I
> don't receive any partial lines until a newline is sent.
>
> This means lines like these output nothing:
>
> printf("foo");
>
> until a printf with a \n in it arrives.
>
> This means any string I receive in javascript needs to have \n appended.
>
> This is of course one way to solve the partial lines problem, but I was
> hoping to receive all bytes printf was printing, relying on fflush(stdout)
> to force emscripten to return all buffered text right away, including
> newlines.
>
> I am using partial printed lines to show what has been started, and
> waiting for the result (can take minutes to arrive) to append to the line,
> and first then print the newline.
>
> With the current system in effect, I am just waiting for stuff to
> calculate, but I don't know what until it is done.
>
> It seems if I want to work around it, I must implement my own printf. Not
> ideal. Or possible figure out a way to hack the generated javascript file.
>
> /Bernhard
>
>
> On Thursday, 16 July 2020 04:04:16 UTC+2, Bernhard Ege wrote:
>>
>> Yes, it does that today.  But when newlines are met, they are removed
>> before the string is handed to the js app. This seems like an error. The js
>> app receiving the text cannot know if this particular string should be with
>> or without newline as the framework deletes the newline.
>>
>>
>> tor. 16. jul. 2020 02.35 skrev Alon Zakai :
>>
>>> >  It seems the printf output is made more responsive by sending data to
>>> the JS-print method every time \n (10) or 0 (string termination) is found,
>>> which is great
>>>
>>> It already does that, doesn't it? If not, can you share your patch that
>>> fixes it?
>>>
>>>
>>> On Wed, Jul 15, 2020 at 3:01 PM Bernhard Ege  wrote:
>>>
>>>> I haven't made a standalone test yet as that would require quite some
>>>> time. However, I hope with the given information, that we can see what is
>>>> going on and if there is anything to do about it. Problem is I am using
>>>> webassembly inside webworker (works jusy fine), but it can muddy the
>>>> experience and getting a clean standalone test means creating a project
>>>> from scratch. I am willing to do so if we can't make a clear case of the
>>>> information below:
>>>>
>>>> This is how I compile my C-project (just updated to latest emscripten,
>>>> problem remains):
>>>>
>>>> & emcc -s WASM=1 -s ALLOW_MEMORY_GROWTH -s
>>>> EXPORTED_FUNCTIONS="['_main','_malloc','_Iterate','_getImageData','_getBufferPtr']"
>>>> -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap", "getValue", "setValue"]' $(ls
>>>> *.c| % {$_.FullName}) $(ls Racer/*.c | % {$_.FullName}) -I. -ferror-limit=0
>>>> -o myrekrig.js
>>>>
>>>> My source is current folder and the Racer subfolder. I just want a
>>>> myrekrig.js file generated (along with the webassembly).
>>>>
>>>> I use the webassembly as a library, i.e. it doesn't exit, meaning I
>>>> call repeatedly from javascript to wasm and have wasm repeatedly output
>>>> text using printf (with and without "\n"). The printf are caught using the
>>>> override in the Module setup:
>>>>
>>>> var Module = {
>>>> print: (function() { return function(text) { console.log(text);
>>>> console.log(ascii_to_hexa(text); }; }
>>>> }
>>>>
>>>> ascii_to_hexa simply converts text to hex and is used to verify proper
>>>> operation.
>>>>
>>>> I normally push the text via the message queue to the main page that
>>>> appends the text to a textarea (which obeys newlines).
>>>>
>>>> One example of text received that in the printf is \n terminated:
>>>>
>>>>
>>>> 536c65657079416e742020202020302020202030202020302e3020202020203020202020203020202

Re: Newlines from C-domain are removed (or so it seems)

[Alon Zakai]

>  It seems the printf output is made more responsive by sending data to
the JS-print method every time \n (10) or 0 (string termination) is found,
which is great

It already does that, doesn't it? If not, can you share your patch that
fixes it?


On Wed, Jul 15, 2020 at 3:01 PM Bernhard Ege  wrote:

> I haven't made a standalone test yet as that would require quite some
> time. However, I hope with the given information, that we can see what is
> going on and if there is anything to do about it. Problem is I am using
> webassembly inside webworker (works jusy fine), but it can muddy the
> experience and getting a clean standalone test means creating a project
> from scratch. I am willing to do so if we can't make a clear case of the
> information below:
>
> This is how I compile my C-project (just updated to latest emscripten,
> problem remains):
>
> & emcc -s WASM=1 -s ALLOW_MEMORY_GROWTH -s
> EXPORTED_FUNCTIONS="['_main','_malloc','_Iterate','_getImageData','_getBufferPtr']"
> -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap", "getValue", "setValue"]' $(ls
> *.c| % {$_.FullName}) $(ls Racer/*.c | % {$_.FullName}) -I. -ferror-limit=0
> -o myrekrig.js
>
> My source is current folder and the Racer subfolder. I just want a
> myrekrig.js file generated (along with the webassembly).
>
> I use the webassembly as a library, i.e. it doesn't exit, meaning I call
> repeatedly from javascript to wasm and have wasm repeatedly output text
> using printf (with and without "\n"). The printf are caught using the
> override in the Module setup:
>
> var Module = {
> print: (function() { return function(text) { console.log(text);
> console.log(ascii_to_hexa(text); }; }
> }
>
> ascii_to_hexa simply converts text to hex and is used to verify proper
> operation.
>
> I normally push the text via the message queue to the main page that
> appends the text to a textarea (which obeys newlines).
>
> One example of text received that in the printf is \n terminated:
>
>
> 536c65657079416e742020202020302020202030202020302e30202020202030202020202030202020202030202020302e302520202020202031202020302e3025202020302e3025202020302e3025
>
> Clearly no newline present (last 2 digits, 25, is a %-sign).
>
> In the generated myrekrig.js, I find this section:
>
> printChar:function(stream, curr) {
> var buffer = SYSCALLS.buffers[stream];
> assert(buffer);
> if (curr === 0 || curr === 10) {
>   (stream === 1 ? out : err)(UTF8ArrayToString(buffer, 0));
>   buffer.length = 0;
> } else {
>   buffer.push(curr);
> }
>
> If I remove "|| curr === 10", then the output is correct, newline or no
> newline. However, this also means the output is buffered for a long time
> (or until a buffer is filler or some other event happens), delaying the
> text for a long time, which is also unwanted. The hack will also be
> overwritten on the next compilation. I am considering simply using sprintf
> and push the string from wasm to js domain manually, but I hope I don't
> have to.
>
> It seems the printf output is made more responsive by sending data to the
> JS-print method every time \n (10) or 0 (string termination) is found,
> which is great (if it preserves all characters, including \n, which it
> doesn't seem to). Could we make it operate using a smaller buffer or maybe
> using a forced flush (or a timeout, not sure that is possible)?
>
> Does the above information make sense?
>
> Thanks,
>
> Bernhard
>
> On Wednesday, 15 July 2020 23:16:56 UTC+2, Alon Zakai wrote:
>>
>> One possible noticeable difference with a normal target is that we print
>> using console.log() and other JS APIs, which can't print partial lines -
>> they always add a newline. So we buffer, and call those APIs only when we
>> reach a newline. As a result, you won't see partial lines printed until a
>> newline is reached.
>>
>> If that's not the issue here, that might be an unknown bug somehow, a
>> testcase would help.
>>
>> On Wed, Jul 15, 2020 at 4:40 AM Shlomi Fish 
>> wrote:
>>
>>> Hi!
>>>
>>> On Wed, 15 Jul 2020 02:32:24 -0700 (PDT)
>>> Bernhard Ege  wrote:
>>>
>>> > When I compile my C-code using emscripten and in C use printf and in
>>> > javascript receive the string via 'print', the newlines are removed.
>>> >
>>> > This makes it quite difficult to discern the difference between these
>>> two
>>> > printf's:
>>> >
>>> > printf("foo");
>>> > printf("foo\n");
>>> >
>>&g

Re: Newlines from C-domain are removed (or so it seems)

[Alon Zakai]

One possible noticeable difference with a normal target is that we print
using console.log() and other JS APIs, which can't print partial lines -
they always add a newline. So we buffer, and call those APIs only when we
reach a newline. As a result, you won't see partial lines printed until a
newline is reached.

If that's not the issue here, that might be an unknown bug somehow, a
testcase would help.

On Wed, Jul 15, 2020 at 4:40 AM Shlomi Fish  wrote:

> Hi!
>
> On Wed, 15 Jul 2020 02:32:24 -0700 (PDT)
> Bernhard Ege  wrote:
>
> > When I compile my C-code using emscripten and in C use printf and in
> > javascript receive the string via 'print', the newlines are removed.
> >
> > This makes it quite difficult to discern the difference between these
> two
> > printf's:
> >
> > printf("foo");
> > printf("foo\n");
> >
> > Visually, there is an important difference, though.
> >
> > Is there some flag or some way print can be told to return the newlines?
> >
>
> seems to work here:
>
> ```
> [shlomif@localhost shlomif-c-snippets]$ cat newline-printf.c
> /*
>  * License is the MIT/Expat license - http://opensource.org/licenses/MIT .
>  * ( https://en.wikipedia.org/wiki/MIT_License ).
>  */
> #include 
>
> int main(void)
> {
> printf ("Hello World!");
> printf ("(emcc)\n");
>
> return 0;
> }
> [shlomif@localhost shlomif-c-snippets]$ emcc newline-printf.c
> [shlomif@localhost shlomif-c-snippets]$ ls -lrt *.js
> -rw-r--r--. 1 shlomif shlomif 110446 Jul 15 14:36 a.out.js
> [shlomif@localhost shlomif-c-snippets]$ node a.out.js
> Hello World!(emcc)
> [shlomif@localhost shlomif-c-snippets]$
> ```
>
> Can you share a self-contained sample? See:
> https://github.com/shlomif/how-to-share-code-online (read the whole
> thing).
>
> Thanks in advance.
>
> --
>
> Shlomi Fish   https://www.shlomifish.org/
> https://github.com/sindresorhus/awesome - curated list of lists
>
> At this point, I'd like to take a moment to speak to you about the Adobe
> PSD
> format. PSD is not a good format. PSD is not even a bad format. Calling it
> such would be an insult to other bad formats, such as PCX or JPEG. No, PSD
> is
> an abysmal format.
> — https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m
>
> Please reply to list if it's a mailing list post - https://shlom.in/reply
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/20200715144004.58141cb4%40telaviv1.shlomifish.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS2bGpYQyZ3dR5fJsOdHsV46YoV6sBLmgHD%3D_Wf1PvWvg%40mail.gmail.com.

Re: Thoughts on future ARM64 support for emsdk?

[Alon Zakai]

On Thu, Jul 9, 2020 at 1:25 PM Brion Vibber  wrote:

> That's an extremely neat idea, and dividing into smaller files should help
> the compilation to run to completion in limited memory scenarios like
> virtual machines and low-end laptops. I think this would also be required
> to make use of multiple CPU cores in the C compiler; running a 6-core
> machine on only one core is going to be much slower than it should be and
> will result in a lot of wasted time for the user.
>
> It would also delay other projects' CI runs that install a fresh emsdk,
> wouldn't it? By delaying work that could be done once at build time to
> happen thousands of times, once at every installation?
>
>
Yes, this is the main downside of the wasm2c approach. It's not a true
replacement for a proper build. (But it can help rare platforms that have
no other build.)

As a developer who uses a variety of computers to work, I personally would
> appreciate the performance improvements and the energy savings of making
> one build per release per platform and distributing the appropriate ones
> for direct use with no additional compilation stage.
>
> -- brion
>
> On Thu, Jul 9, 2020, 1:14 PM Alon Zakai  wrote:
>
>> Yeah, that's an issue with wasm2c. It takes a few minutes to build
>> (optimized) wasm-opt, and clang would be much worse, and maybe fail as you
>> said.
>>
>> I don't think anyone's looked into this, but ideas include:
>>
>> * Get wasm2c to emit separate files, each containing one or more
>> functions. Then you just need a Makefile or such and can even build in
>> parallel.
>>
>> * Write a little python script that splits up the file automatically. The
>> format is pretty simple so that's easy. And the python could also run
>> gcc/clang in a process pool for you.
>>
>> - Alon
>>
>>
>>
>> On Thu, Jul 9, 2020 at 1:01 PM 'Thomas Lively' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>> How does the wasm2c build work with something as large as LLVM? I would
>>> assume that at some point the C file would get so large that the C compiler
>>> would fall over.
>>>
>>> On Thu, Jul 9, 2020 at 12:58 PM Alon Zakai  wrote:
>>>
>>>> At the risk of sounding like a broken record - I've been talking about
>>>> the next idea a lot recently ;) - I think this is something wasm2c can help
>>>> with. I just gave a talk about how:
>>>>
>>>> http://kripken.github.io/talks/2020/universal.html#/
>>>>
>>>> The idea is that we add a single additional build target, "universal
>>>> C", which compiles LLVM and Binaryen to portable C code that can then be
>>>> compiled on practically any platform. So this new "build" would be C, and
>>>> people would download those C files and run a simple command to build them
>>>> locally. After the local build you end up with a normal executable that
>>>> just works.
>>>>
>>>> There is still that build step locally, but it's the simplest build
>>>> possible - no build system is needed, no special local setup, no cmake or
>>>> configure, just run gcc or clang on a self-contained C file. That should be
>>>> trivial on ARM64 MacOS or Linux as I believe they have a system C compiler
>>>> installed by default.
>>>>
>>>> I'm not opposed to adding "proper" ARM64 builds, though - ARM64 builds
>>>> would have some benefits over wasm2c. But wasm2c builds do cover the long
>>>> tail of less-common platforms, and we can probably set them up much quicker
>>>> too. I hope to do this for Binaryen soon anyhow.
>>>>
>>>> - Alon
>>>>
>>>> On Thu, Jul 9, 2020 at 11:30 AM Brion Vibber  wrote:
>>>>
>>>>> I've been a bit of an ARM64 enthusiast of late, trying out Linux,
>>>>> Windows 10, and iOS devices that run on the ARM64/Aarch64 family of
>>>>> processors. Emscripten works fine on these machines if one cares to do 
>>>>> some
>>>>> light development work on them, but since there's no binaries built from
>>>>> CI, the standard emsdk can only install by building from source -- which
>>>>> can take hours on a middleweight portable machine.
>>>>>
>>>>> Now that Apple is switching their Mac product line to ARM64 processors
>>>>> over the next two years, it will likely become much more common next year
>>>>> for people to have ARM64-based laptop and des

Re: Thoughts on future ARM64 support for emsdk?

[Alon Zakai]

Yeah, that's an issue with wasm2c. It takes a few minutes to build
(optimized) wasm-opt, and clang would be much worse, and maybe fail as you
said.

I don't think anyone's looked into this, but ideas include:

* Get wasm2c to emit separate files, each containing one or more functions.
Then you just need a Makefile or such and can even build in parallel.

* Write a little python script that splits up the file automatically. The
format is pretty simple so that's easy. And the python could also run
gcc/clang in a process pool for you.

- Alon



On Thu, Jul 9, 2020 at 1:01 PM 'Thomas Lively' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> How does the wasm2c build work with something as large as LLVM? I would
> assume that at some point the C file would get so large that the C compiler
> would fall over.
>
> On Thu, Jul 9, 2020 at 12:58 PM Alon Zakai  wrote:
>
>> At the risk of sounding like a broken record - I've been talking about
>> the next idea a lot recently ;) - I think this is something wasm2c can help
>> with. I just gave a talk about how:
>>
>> http://kripken.github.io/talks/2020/universal.html#/
>>
>> The idea is that we add a single additional build target, "universal C",
>> which compiles LLVM and Binaryen to portable C code that can then be
>> compiled on practically any platform. So this new "build" would be C, and
>> people would download those C files and run a simple command to build them
>> locally. After the local build you end up with a normal executable that
>> just works.
>>
>> There is still that build step locally, but it's the simplest build
>> possible - no build system is needed, no special local setup, no cmake or
>> configure, just run gcc or clang on a self-contained C file. That should be
>> trivial on ARM64 MacOS or Linux as I believe they have a system C compiler
>> installed by default.
>>
>> I'm not opposed to adding "proper" ARM64 builds, though - ARM64 builds
>> would have some benefits over wasm2c. But wasm2c builds do cover the long
>> tail of less-common platforms, and we can probably set them up much quicker
>> too. I hope to do this for Binaryen soon anyhow.
>>
>> - Alon
>>
>> On Thu, Jul 9, 2020 at 11:30 AM Brion Vibber  wrote:
>>
>>> I've been a bit of an ARM64 enthusiast of late, trying out Linux,
>>> Windows 10, and iOS devices that run on the ARM64/Aarch64 family of
>>> processors. Emscripten works fine on these machines if one cares to do some
>>> light development work on them, but since there's no binaries built from
>>> CI, the standard emsdk can only install by building from source -- which
>>> can take hours on a middleweight portable machine.
>>>
>>> Now that Apple is switching their Mac product line to ARM64 processors
>>> over the next two years, it will likely become much more common next year
>>> for people to have ARM64-based laptop and desktop computers, and some of
>>> them will need to build something with emscripten in their workflows either
>>> on macOS or on a virtualized Linux in Docker etc.
>>>
>>> From what I've seen presented at WWDC, the ARM64 Macs will support
>>> emulated processes, so it may work to ship the x86_64 binaries with the
>>> caveat that they will run much slower than native builds.
>>>
>>> Virtualized Linux builds would also need native ARM64 binaries to run,
>>> or else they'd have to sit there for a couple hours compiling after every
>>> upgrade.
>>>
>>> And of course there are already Windows 10 and Linux computers available
>>> with ARM64 processes, on sale since a couple years ago and used in the wild
>>> in modest numbers.
>>>
>>> I get the impression that the biggest roadblock to explicit ARM64
>>> support in emscripten is getting it into the CI infrastructure:
>>> * Linux/ARM64 builds and testing?
>>> * macOS/ARM64 builds and testing?
>>> * Windows/ARM64 builds and testing?
>>>
>>> It's too soon to start on macOS since it's in beta, dev kits aren't
>>> shipped yet, and there's no obvious way yet to figure out how to run tests
>>> on a macOS ARM system in CI. :)
>>>
>>> And I'm less sure how important Win/ARM64 is, given you can use the
>>> Linux/ARM64 version in WSL virtualization. But some folks prefer to develop
>>> on native Windows, too.
>>>
>>> If there's any way we can start talking about Linux/ARM64 builds and
>>> testing, I would be very happy about it! I would eve

Re: Thoughts on future ARM64 support for emsdk?

[Alon Zakai]

At the risk of sounding like a broken record - I've been talking about the
next idea a lot recently ;) - I think this is something wasm2c can help
with. I just gave a talk about how:

http://kripken.github.io/talks/2020/universal.html#/

The idea is that we add a single additional build target, "universal C",
which compiles LLVM and Binaryen to portable C code that can then be
compiled on practically any platform. So this new "build" would be C, and
people would download those C files and run a simple command to build them
locally. After the local build you end up with a normal executable that
just works.

There is still that build step locally, but it's the simplest build
possible - no build system is needed, no special local setup, no cmake or
configure, just run gcc or clang on a self-contained C file. That should be
trivial on ARM64 MacOS or Linux as I believe they have a system C compiler
installed by default.

I'm not opposed to adding "proper" ARM64 builds, though - ARM64 builds
would have some benefits over wasm2c. But wasm2c builds do cover the long
tail of less-common platforms, and we can probably set them up much quicker
too. I hope to do this for Binaryen soon anyhow.

- Alon

On Thu, Jul 9, 2020 at 11:30 AM Brion Vibber  wrote:

> I've been a bit of an ARM64 enthusiast of late, trying out Linux, Windows
> 10, and iOS devices that run on the ARM64/Aarch64 family of processors.
> Emscripten works fine on these machines if one cares to do some light
> development work on them, but since there's no binaries built from CI, the
> standard emsdk can only install by building from source -- which can take
> hours on a middleweight portable machine.
>
> Now that Apple is switching their Mac product line to ARM64 processors
> over the next two years, it will likely become much more common next year
> for people to have ARM64-based laptop and desktop computers, and some of
> them will need to build something with emscripten in their workflows either
> on macOS or on a virtualized Linux in Docker etc.
>
> From what I've seen presented at WWDC, the ARM64 Macs will support
> emulated processes, so it may work to ship the x86_64 binaries with the
> caveat that they will run much slower than native builds.
>
> Virtualized Linux builds would also need native ARM64 binaries to run, or
> else they'd have to sit there for a couple hours compiling after every
> upgrade.
>
> And of course there are already Windows 10 and Linux computers available
> with ARM64 processes, on sale since a couple years ago and used in the wild
> in modest numbers.
>
> I get the impression that the biggest roadblock to explicit ARM64 support
> in emscripten is getting it into the CI infrastructure:
> * Linux/ARM64 builds and testing?
> * macOS/ARM64 builds and testing?
> * Windows/ARM64 builds and testing?
>
> It's too soon to start on macOS since it's in beta, dev kits aren't
> shipped yet, and there's no obvious way yet to figure out how to run tests
> on a macOS ARM system in CI. :)
>
> And I'm less sure how important Win/ARM64 is, given you can use the
> Linux/ARM64 version in WSL virtualization. But some folks prefer to develop
> on native Windows, too.
>
> If there's any way we can start talking about Linux/ARM64 builds and
> testing, I would be very happy about it! I would even kick in a few bucks
> for a VM or something if that would help any. ;)
>
> Thanks for your time and your consideration!
>
> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> Wikimedia Foundation
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3D3OLskq1KBtVrgKsq1PTS7eHDxyzpcBpmE8_Bfk7m6Kw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQoi1LZiw2dPjeMMy2zSf-Z8WFWjpP8K1C-gEx67O5jwg%40mail.gmail.com.

Re: Moving large data between JS & wasm with IDL binder

[Alon Zakai]

HEAP8 is one of the global variables the emscripten JS always has. It's
always present for code in a JS library, --pre-js, or other code that is
part of the main JS output (that is all optimized together).

On Wed, Jul 8, 2020 at 6:39 PM キャロウ マーク  wrote:

> Thanks Alon.
>
> > On Jul 8, 2020, at 15:59, Alon Zakai  wrote:
> >
> > Embind and the WebIDL binder are separate tools. They don't have any
> special support for mixing between them.
>
> That’s what I had concluded. Thanks for confirming. My confusion arose
> because it is not clear (to me at least) that emscripten::val is strictly
> part of embind.
>
> >
> > The WebIDL binder doesn't have direct support for copying data from JS
> into wasm. You can do it manually though, without the WebIDL binder, by
> malloc()ing some room, copying the data (all in JS, just a copy from the JS
> data into HEAP8 for example), then you can pass the malloc()ed pointer as a
> parameter to the compiled code (with the WebIDL binder, passing it as a
> void* would work, or an int).
>
> So in JS do I create a typed array view on the right place in HEAP8 and
> then copy in and out of that? How does the JS find HEAP8? I need to create
> a wrapper for the zstd decoder so I need to be as efficient as possible in
> moving the data.
>
> Regards
>
> -Mark
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/1ECB6FF7-0049-4F3B-93AB-0CDD0879A908%40callow.im
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQW%3DuafqKph1dJ7S%3DiNAp3rCDY%2B_9T8oeDh0kRtk6r%3Djg%40mail.gmail.com.

Re: Moving large data between JS & wasm with IDL binder

[Alon Zakai]

Embind and the WebIDL binder are separate tools. They don't have any
special support for mixing between them.

The WebIDL binder doesn't have direct support for copying data from JS into
wasm. You can do it manually though, without the WebIDL binder, by
malloc()ing some room, copying the data (all in JS, just a copy from the JS
data into HEAP8 for example), then you can pass the malloc()ed pointer as a
parameter to the compiled code (with the WebIDL binder, passing it as a
void* would work, or an int).

On Wed, Jul 8, 2020 at 12:34 PM キャロウ マーク  wrote:

> Can anyone here explain, or point me at an example, of how to move large
> data, e.g an image, between JS memory and wasm memory using a function
> defined with WebIDL binder?
>
> In embind for moving data from JS to wasm, I use an emscripten::val
> parameter to pass in the JS handle then emscripten::val::module_property to
> get a handle to the wasm memory on which I make a memory view to which the
> data is copied.
>
> To move data from wasm to JS I use emscripten::val::get_typed_memory_view
> to create a view onto the item in wasm memory and return the view via a
> emscripten::val.
>
> I tried to use emscripten::val with WebIDL binder but I could not get it
> to compile. There is a short section in the WebIDL docs "Pointers,
> References, Value types (Ref and Value)”, which is not very illuminating,
> but does suggest that emscripten::val is not the right way to move data
> with WebIDL binder.
>
> I’d prefer to use WebIDL binder because in order to document my previous
> embind wrappers I ended up writing what looked very much like web IDL
> because it seems the best way to tie all the pieces together.
>
> Regards
>
> -Mark
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/005C24B2-1D79-47CC-A291-D7A6B749582F%40callow.im
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTgyrmUFDs_1B0CtJyvcEAZUuk9v9Oed5H6hAeTOQ1DEQ%40mail.gmail.com.

Re: Compiler error in Emscripten v1.39.18 -no member named 'acos' in the global namespace

[Alon Zakai]

Perhaps we should rename emscripten/math.h to emscripten/em_math.h, or
something else? It seems risky to leave as it is.

On Thu, Jun 18, 2020 at 7:33 AM Brian Gavin  wrote:

> I was using 'system/include/emscripten' as an include path so I removed
> it, but I am still seeing the same errors.
>
> Brian Gavin
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/2930fc46-a938-4f17-801b-597a00e74dd8o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQFarHurwkA0%3DbmPRO%2BmBPyBU4UiTRXX3g8ndhD2iDThw%40mail.gmail.com.

Re: Planning to remove fastcomp

[Alon Zakai]

Ok, looks like 2 weeks and no concerns here, so I think we are ready to
move forward on removing fastcomp.

I'll post in that issue with the concrete next steps, please follow there
if you're interested.

On Tue, Jun 2, 2020 at 4:03 PM Alon Zakai  wrote:

> Hi everyone,
>
> As the new upstream backend has been the default for a long time, we would
> like to start planning the removal of the old fastcomp backend. See full
> details of what that means here:
>
> https://github.com/emscripten-core/emscripten/issues/11319
>
> Please let us know if there are any concerns about this.
>
> - Alon
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTp1rOGeXnFJHN3vLteC3EEOoaecttCPzyk0_S8oSXw0A%40mail.gmail.com.

Re: Webassembly.instantiate compile error

[Alon Zakai]

No, that error cannot be caused by something like TOTAL_MEMORY.

That it works fine if you disable the cache proves what the issue is:
something to do with the network. Specifically, maybe the cache has bad
data, or isn't working properly.

Another thing to try is to see what happens on multiple browsers or browser
versions (which will have different cache behaviors, but not different wasm
validation behaviors).

On Tue, Jun 9, 2020 at 2:44 PM Rohit Saini 
wrote:

> Hi Alon,
>
> But it works fine if I checked the disable cache option in chrome network
> panel. I am using worker and loading wasm from that worker. If I unchecked
> the disable cache option, then my wasm and worker script are served from
> disk cache. If issue would've been with my server, I should get an error in
> the checked disable cache case not in the unchecked one I think. Could
> something else be the issue like not setting enough TOTAL_MEMORY etc.?
>
> Regards,
> Rohit Saini
> On Tuesday, June 9, 2020 at 3:42:51 AM UTC+5:30, Rohit Saini wrote:
>>
>> Hi All,
>>
>> I am getting following error while doing
>> WebAssembly.instantiateStreaming. Can I know where all these error messages
>> are defined, so that I can know the exact reason of the issue. Or if
>> someone know about this issue.  Moreover the issue is intermittent , occurs
>> only on some machines and it sometime goes when I clear the cache.
>>
>> I am using 1.39.7 emscripten version. Wasm binary size is around 50mb.
>>
>> Regards,
>> Rohit Saini
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ffde7e6b-1694-45b8-b1d7-c9cb7cd01b97o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR_YU1TGLhJNUKadwA5QhyCrvgoDg6OQk%2B%2BTwrmENzkag%40mail.gmail.com.

Re: Webassembly.instantiate compile error

[Alon Zakai]

"expected X bytes, fell off end" means that the wasm file is truncated - it
stops too early. Perhaps only part of it was downloaded before the server
stopped for some reason. The problem is likely your webserver, or the
network connection.

Here is where V8 emits that message:
https://github.com/v8/v8/blob/4b9b23521e6fd42373ebbcb20ebe03bf445494f9/src/wasm/decoder.h#L171

On Mon, Jun 8, 2020 at 3:12 PM Rohit Saini 
wrote:

> Hi All,
>
> I am getting following error while doing WebAssembly.instantiateStreaming.
> Can I know where all these error messages are defined, so that I can know
> the exact reason of the issue. Or if someone know about this issue.
> Moreover the issue is intermittent , occurs only on some machines and it
> sometime goes when I clear the cache.
>
> I am using 1.39.7 emscripten version. Wasm binary size is around 50mb.
>
> Regards,
> Rohit Saini
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/bc6ba785-e510-41d5-816f-fe6614972cd0o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQgRX7jEWPcFtF3KrV%2BhYyC%3D5gxOahNebKAAF__%3DVyb3Q%40mail.gmail.com.

Re: SIMD broken with emsdk 1.39.16 and node 14.4.0

[Alon Zakai]

In that case, I think you may need to set MAXIMUM_MEMORY to 4GB, or to -1,
so that it is compatible with your manually-created memory.

What I think might have changed here is that emscripten now sets the
default MAXIMUM_MEMORY to 2GB. That is because not all VMs support 4GB yet,
and also since to support more than 2GB we need to increase code size a
little, so we don't want that by default.



On Fri, Jun 5, 2020 at 6:18 PM Soeren Balko  wrote:

> OK, so turns out that the issue was that we construct the
> WebAssembly.Memory outside the Emscripten-generated code and without the
> ("maximum") property set in the constructor. We do so in order to be able
> to re-use the same WebAssembly.Memory instance across multiple subsequent
> WebAssembly instances.
>
> The "maximum" property used to be optional - is it no longer?
>
> Soeren
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/a9b94bf6-97b7-49cd-9d63-92cc9f730f1co%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpT9YS%3DBkyQBDXmrDgkgGhSytoR870YYTtNrAJhv8PgySg%40mail.gmail.com.

Re: SIMD broken with emsdk 1.39.16 and node 14.4.0

[Alon Zakai]

> WebAssembly.instantiate(): memory import 51 has no maximum limit,
expected at most 4294967295

Aside from memory growth, what compiler flags are you using for
INITIAL_MEMORY and MAXIMUM_MEMORY? And are you creating the memory yourself?

But I'm not sure what causes that error: "no limit" seems compatible with
4GB. So it could be a browser or toolchain bug. Can you share your build?

> Is there some sort of compatibility table that states what emsdk is
compatible with what node.js and browser versions?

For SIMD things are still experimental so there is no guaranteed
compatibility AFAIK. In general stable features in an emsdk release should
work on stable browsers. Something like 4GB support won't work in many
browsers today, though, as it isn't stable, and for that reason it isn't on
by default in emscripten (for chrome you need 83 or newer,
https://v8.dev/blog/4gb-wasm-memory).


On Fri, Jun 5, 2020 at 12:49 AM Soeren Balko  wrote:

> Update: the "memory import has no maximum limit" issue seems unrelated to
> the SIMD includes. It appears even when omitting the -msimd128 flag. Is
> this related to the recent 4GB heap enablement?
>
>
>
> On Friday, June 5, 2020 at 5:19:22 PM UTC+10, Soeren Balko wrote:
>>
>> I am getting some weird SIMD-related errors when running an FFmpeg build
>> generated with emsdk 1.39.16 and using the ` -msimd128` compiler flag. In
>> the latest node version (14.4.0), I get this. Not even adding
>> `-fno-vectorize` fixes this issue.
>>
>> ```
>> CompileError: WebAssembly.compile(): Compiling function #68 failed:
>> i16x8.replace_lane[1] expected type i32, found s128.load128 of type s128
>> @+33864
>> ```
>>
>> Assuming that this is caused by an "old" V8 version in node 14.4.0, I
>> have turned to the latest Chrome development build, enabled the WebAssembly
>> SIMD option under chrome://flags. This time, I am getting a different error
>> that I haven't seen before:
>>
>> ```
>> WebAssembly.instantiate(): memory import 51 has no maximum limit,
>> expected at most 4294967295
>> ```
>>
>> I am compiling with the `-s ALLOW_MEMORY_GROWTH` flag, which used to work
>> fine in 1.39.11. Any suggestions what may cause these two WebAssembly
>> initialization issues? Is there some sort of compatibility table that
>> states what emsdk is compatible with what node.js and browser versions?
>>
>> Soeren
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/67aeaa6a-0a8b-489e-9f4c-027b6a81b520o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ5BGGDH_MY%3DKFZ0CTC_dpBk8aHyOkC9hNhwPEfin3BZA%40mail.gmail.com.

Re: Issue 1130

[Alon Zakai]

(I think you mean 11030, and not 1130?)

That would be great Punit!

The fetch code is in src/Fetch.js. Looking for onsuccess in that file is
probably the fastest way to find the relevant code.

To get started you might want to first create a testcase that fails, so
that you can see that it works after you fix things, and as you debug.
Adding a testcase in the test suite is the best way I think, since then
it's easy to run automatically, and you don't need to write a testcase
later for the PR (but it does take a little more work up front). To do
that, I would start by looking at testcases for the fetch API in the test
suite, by searching for FETCH=0 in tests/*.py, or by searching under tests/
for the C fetch API calls (like emscripten_fetch). Then maybe there will be
a test you can add to. (Test suite docs:
https://emscripten.org/docs/getting_started/test-suite.html )

- Alon


On Wed, Jun 3, 2020 at 10:07 PM Punit Salian  wrote:

> Hey guys, I am really interested in this project and looking to make my
> first contribution. I am looking at issue 1130 (emscripten_fetch calls
> onsuccess for url with non open port) . As a beginner to this project how
> should I start ? And what do I look for ?. Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/985facb6-69f6-4819-bb44-cd991b24ed14%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTSknjYuocW_96P%2Bt4k8jKpaRbxYdTDhjJ%2BDOj1U8uBOA%40mail.gmail.com.

Planning to remove fastcomp

[Alon Zakai]

Hi everyone,

As the new upstream backend has been the default for a long time, we would
like to start planning the removal of the old fastcomp backend. See full
details of what that means here:

https://github.com/emscripten-core/emscripten/issues/11319

Please let us know if there are any concerns about this.

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ8%2B5%2BXjJvReXQ00OBGNxgVTBtD3LdMDyJS0mMTbmbmWQ%40mail.gmail.com.

Re: COOP, COEP for wasm threads

[Alon Zakai]

This will affect all browsers eventually, as it is the agreed direction in
the standards bodies.

I'm not an expert on COOP/COEP, but I don't think you need to build the
module differently. You may need to change the webserver's responses,
though. See for example what our browser test suite does,

https://github.com/emscripten-core/emscripten/blob/20ecfa2f8101fb21a9c0f9d75e3aa2dee6468e95/tests/runner.py#L1332


On Tue, Jun 2, 2020 at 12:52 PM Dan C  wrote:

> Hi everyone,
>
> I noticed this message when loading threaded wasm with Firefox.
> *Worker.postMessage: The WebAssembly.Memory object cannot be serialized.
> The Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy HTTP
> headers will enable this in the future.*
> My understanding is that this is caused by
> https://bugzilla.mozilla.org/show_bug.cgi?id=1562663
>
> Is this problem something we expect to ever impact any other browsers or
> is it Firefox only? Would this problem be fixed in Firefox or the module
> needs to be built differently?
>
> Thanks,
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f2c12ce0-2156-4cee-bf84-790d10a4ebde%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRgjU%3DKbBM83z57HsSnn-yicrGhZrfrdXWouNisNC2%3D3w%40mail.gmail.com.

Re: FYI- - Example how to use Emscripten with Visual Studio 2019

[Alon Zakai]

Nice!

I think it would be useful to have examples like this in the main docs, or
linked from them.

Perhaps open a PR with a link to this, and we can discuss further there?

On Sat, May 30, 2020 at 7:12 AM Brian Gavin  wrote:

> Hello I have created an example of how to have Emscripten run with Visual
> Studio 2019 using CMake.   If people find it useful I may create some more
> complex examples.
>
> https://github.com/briangavin/VS_WASM_Examples
>
> Brian Gavin
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/04be8b5f-957d-4d31-9e8a-ac1b17ce9465%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR7_OsDa6u7%3D7GOsYhZndjqnB27iOmsFWph6DxFYhtrQg%40mail.gmail.com.

Re: Strange failures of Emscripten's tests

[Alon Zakai]

We don't run tests on our CI using the SpiderMonkey shell (but we do test
Firefox in the browser suite), so perhaps we need to add something in
src/shell.js for it.

Our CI shell tests mostly run in node, with a few using d8 when we test
very new wasm features not yet in node.

The current status of the tests can be seen on github where we run CI,

https://github.com/emscripten-core/emscripten/commits/master

Each commit has a green check or a red x, and clicking on those gets you to
links to see the detailed results.


On Sun, May 31, 2020 at 7:10 AM Qwerty Uiop  wrote:

> Hi,
>
> I've been trying to run Emscripten's tests locally and I've got strange
> failures.
>
> E.g. when I run
> python tests/runner.py test_unistd_io
> I get
> ...
> AssertionError: JS subprocess failed (/home/brd/soft/SpiderMonkeyShell-
> nightly-2020-05-30/js -w /tmp/emscripten_test/src.cpp.o.js): 1.  Output:
> Assertion failed: undefined
> Assertion failed: undefined
> exception thrown: RuntimeError: abort(Assertion failed: undefined) at
> jsStackTrace@/tmp/emscripten_test/src.cpp.o.js:7402:17
> ...
>
> The line 7402 of src.cpp.o.js is the first line of the function
> jsStackTrace:
> var err = new Error();
> So it looks like Error itself is undefined.
> Of course, when I run SpiderMonkey on a simple js file containing just
> that line, it works fine.
>
> I'm using the latest master revisions of Emscripten, Fastcomp and Binaryen
> as of Friday, May 29.
>
> I have the impression that something is wrong with my setup but can't
> figure out where the problem is exactly.
> Could anyone give me a clue?
>
> Also, could anyone point me to the official build server where I might see
> the current status of the tests?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/6bccd969-e9fa-4b4e-a505-6a69c0d492ba%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQkLSSyvM495BwnYfrvx3KDG2nz7Q%3DPrezRGtokFb5ywg%40mail.gmail.com.

Re: Libvpx to WASM, facing performance issues.

[Alon Zakai]

For LTO you also need to pass -flto during the compile step (and during
link, and you don't need `--llvm-lto 3` any more, which was for the old
backend).

If that's not it, I'd suggest comparing profiles between the builds to find
what is actually slower in your build.

On Sat, May 30, 2020 at 10:04 AM MEENA N SUBBIAH 
wrote:

> I am trying to compile the libvpx module to wasm.
> But I am facing huge performance issues.
>
> The wasm I build takes an average encode time of 1300+ milliseconds.
> But I found another livpx.wasm
> https://github.com/webrtc/apprtc/tree/wartc/src/web_app/wasm/libvpx which
> takes average encode time of 250+ milliseconds.
> Can anyone help me, Where am I going wrong.
>
> here are the compilation setting I use,
>
> to build *libvpx,*
>
>
> *emconfigure ../node_modules/libvpx/configure --enable-postproc
> --enable-multi-res-encoding --enable-temporal-denoising --enable-libyuv
> --size-limit=16384x16384 --enable-multithread --enable-realtime-only
> --disable-install-docs --disable-unit-tests --disable-vp9-decoder
> --disable-vp9-encoder --target=generic-gnu --extra-cxxflags="-O3 -s WASM=1
> -DWASM -I`dirname \`which emcc\``/system/lib/libcxxabi/include"*
> *emmake make*
>
> to build *libyuv,*
>
>
> *emcmake cmake -DCMAKE_BUILD_TYPE=Release ../node_modules/libyuvemmake
> make*
>
> *Final compilation,*
>
>
> *emcc -O3 -DWASM --bind -s STRICT=1 -s ALLOW_MEMORY_GROWTH=1 -s
> ASSERTIONS=0 -s NO_EXIT_RUNTIME=1 -s MALLOC=emmalloc -s MODULARIZE=1 -s
> FILESYSTEM=0 -s EXPORT_ES6=1 --std=c++11 -o ./my-module.js -x c++ -I
> ./node_modules/libvpx -I ./node_modules/libyuv/include -I build-vpx
> src/zcon_ss.cpp src/Utility/ZvpxCodecInst.cpp src/Utility/zvpx_encoder.cpp
> src/Utility/zvpx_decoder.cpp build-vpx/libvpx.a build-yuv/libyuv.a
> --no-entry --closure 0 --llvm-lto 3 -g0*
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/e47d2054-9a4a-4cc5-86f9-bf0072f55258%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS0LMQvT0JfSZGroSuNNH198V0hgfm56pDBwLPU8SWTwg%40mail.gmail.com.