from:"Александр Гурьянов"

Solved! The problem was in cmake files or project, seems that build script
was generated when emscripten was located in emsdk/emscripten/main/. Seems
newer emsdk uses emsdk/upstream/emscripten. After regenerating cmake build
script everything is fine.

пн, 5 сент. 2022 г. в 23:34, Александр Гурьянов :

> I also have following warnings:
> em++: warning: LLVM version for clang executable
> "/home/caiiiycuk/sdk/emsdk/upstream/bin/clang" appears incorrect (seeing
> "16.0", expected "15.0") [-Wversion-check]
> em++: warning: LLVM version for clang executable
> "/home/caiiiycuk/sdk/emsdk/upstream/bin/clang" appears incorrect (seeing
> "16.0", expected "15.0") [-Wversion-check]
>
> And my project didn't compile anymore:
>
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libGL-webgl2.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libGL-webgl2.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libal.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libal.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libhtml5.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libhtml5.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libstubs.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libstubs.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libnoexit.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libnoexit.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libc-optz.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libc-optz.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libdlmalloc.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libdlmalloc.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libcompiler_rt.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libc++-noexcept.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libc++-noexcept.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libc++abi-noexcept.a... (this will be cached
> in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libc++abi-noexcept.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system library:
> sysroot/lib/wasm32-emscripten/libsockets.a... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libsockets.a"
> for subsequent builds)
> cache:INFO:  - ok
> cache:INFO: generating system asset:
> sysroot/lib/wasm32-emscripten/struct_info.json... (this will be cached in
> "/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/struct_info.json"
> for subsequent builds)
> emcc: warning: unexpected binaryen version: 109 (expected 104)
> [-Wversion-check]
> emscripten:ERROR: emscript: failure to parse metadata output from
> wasm-emscripten-finalize. raw output is:
>
> Traceback (most recent call last):
>   File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emcc.py", line 3945, in
> 
> sys.exit(main(sys.argv))
>   File "/usr/lib/python3.10/contextlib.py", line 79, in inner
> return func(*args, **kwds)
>   File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emcc.py", line 3938, in
> main
> ret = run(args)
>   File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emcc.py", line 1186, in
> run
> phase_post_link(options, state, wasm_target, wasm_target, target)
>   File "/usr/lib/python3.10/contextlib

Re: unexpected binaryen version

finalize_wasm(in_wasm, out_wasm, memfile)
  File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emscripten.py", line 526,
in finalize_wasm
metadata = get_metadata_binaryen(infile, outfile, modify_wasm, args)
  File "/usr/lib/python3.10/contextlib.py", line 79, in inner
return func(*args, **kwds)
  File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emscripten.py", line 406,
in get_metadata_binaryen
metadata = load_metadata_json(stdout)
  File "/home/caiiiycuk/sdk/emsdk/emscripten/main/emscripten.py", line 856,
in load_metadata_json
metadata_json = json.loads(metadata_raw)
  File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
FAIL: Compilation failed!:
['/home/caiiiycuk/sdk/emsdk/emscripten/main/emcc', '-D_GNU_SOURCE', '-o',
'/tmp/tmpnru03hjf.js', '/tmp/tmpi3s6le5u.c', '-O0', '-Werror',
'-Wno-format', '-nostdlib',
'/home/caiiiycuk/sdk/emsdk/emscripten/main/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a',
'-sMEMORY64=0', '-sBOOTSTRAPPING_STRUCT_INFO=1',
'-sLLD_REPORT_UNDEFINED=1', '-sSTRICT', '-sSINGLE_FILE',
'-Wno-error=version-check', '-Wno-deprecated']
ninja: build stopped: subcommand failed.

emcc --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld)
3.1.20 (5d878c99921ec247d34fb26a20b5a13d60d69e93)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

emsdk commit:
commit b1bb477e38539f81f6db7a3c24be9df476ff516b (HEAD -> main, origin/main)
Author: Joel Van Eenwyk 
Date:   Tue Aug 30 07:25:39 2022 -0700

Add double-quotes to allow spaces in path (#1097)

пн, 5 сент. 2022 г. в 20:24, 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

>
>
> On Mon, Sep 5, 2022 at 6:28 AM Александр Гурьянов 
> wrote:
>
>> the output of wasm-opt --version:
>>
>> ./upstream/bin/wasm-opt --version
>> wasm-opt version 109 (version_109-27-gb69d3a8fa)
>>
>> пн, 5 сент. 2022 г. в 16:19, Александр Гурьянов :
>>
>>> Hi. I use emsdk, and after updating to 3.1.20 I have following warnings:
>>>
>>> emcc: warning: unexpected binaryen version: 109 (expected 104)
>>> [-Wversion-check]
>>> emcc: warning: unexpected binaryen version: 109 (expected 104)
>>> [-Wversion-check]
>>> em++: warning: unexpected binaryen version: 109 (expected 104)
>>> [-Wversion-check]
>>>
>>
> This expected version looks wrong.  It should be expecting 109 if you are
> using 3.1.20.
>
> Can you run `which emcc` and `emcc --version` to see why the wrong version
> seems to be being used?
>
> cheers,
> sam
>
>
>>
>>> What does it mean? I used following commands
>>>
>>> ./emsdk install latest
>>> ./emsdk activate latest
>>> source emsdk_env.sh
>>>
>>> ./emcc ...
>>>
>>> I tried clear caches with --clear-cache, but warning still there...
>>>
>> --
>> 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%3DVEw37Qzzik%2BmpvRrK9HQnZiaDZRcRC2DsLX7HtUkoAW-A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEw37Qzzik%2BmpvRrK9HQnZiaDZRcRC2DsLX7HtUkoAW-A%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/CAL_va2_J9OL0ZrM-wfE1oSUDiA2Mr0S6jLQ%2BcXKk2sfE0XEenA%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_J9OL0ZrM-wfE1oSUDiA2Mr0S6jLQ%2BcXKk2sfE0XEenA%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/CAKOm%3DVHNwAJ3jvo4AXB4R4DrUpP_810J6eMQ3q_ymkJAKQuFbA%40mail.gmail.com.

Re: unexpected binaryen version

the output of wasm-opt --version:

./upstream/bin/wasm-opt --version
wasm-opt version 109 (version_109-27-gb69d3a8fa)

пн, 5 сент. 2022 г. в 16:19, Александр Гурьянов :

> Hi. I use emsdk, and after updating to 3.1.20 I have following warnings:
>
> emcc: warning: unexpected binaryen version: 109 (expected 104)
> [-Wversion-check]
> emcc: warning: unexpected binaryen version: 109 (expected 104)
> [-Wversion-check]
> em++: warning: unexpected binaryen version: 109 (expected 104)
> [-Wversion-check]
>
> What does it mean? I used following commands
>
> ./emsdk install latest
> ./emsdk activate latest
> source emsdk_env.sh
>
> ./emcc ...
>
> I tried clear caches with --clear-cache, but warning still there...
>

-- 
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%3DVEw37Qzzik%2BmpvRrK9HQnZiaDZRcRC2DsLX7HtUkoAW-A%40mail.gmail.com.

unexpected binaryen version

Hi. I use emsdk, and after updating to 3.1.20 I have following warnings:

emcc: warning: unexpected binaryen version: 109 (expected 104)
[-Wversion-check]
emcc: warning: unexpected binaryen version: 109 (expected 104)
[-Wversion-check]
em++: warning: unexpected binaryen version: 109 (expected 104)
[-Wversion-check]

What does it mean? I used following commands

./emsdk install latest
./emsdk activate latest
source emsdk_env.sh

./emcc ...

I tried clear caches with --clear-cache, but warning still there...

-- 
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%3DVGe%3DdUYSOLK%2Bo49uMttp4-cOwZ4-nEA7KeyMTwnMwwp8Q%40mail.gmail.com.

Re: WasmFS for jsdos

2022-08-02 Thread Александр Гурьянов

Clear. I remembered another feature that great to have. Will be great if FS
could make a snapshot of opened files, and restore descriptors on next load.

I experimented with snapshotting jsdos. When the user clicks on snapshot,
then on next asyncify pause jsdos do  dump of wasm memory to file. On next
page load on same asyncify pause jsdos replaces wasm memory with memory
from snapshot and resumes.

This work fine until the game need to use fs layer, because opened file
descriptors became invalid. So, it will be great if new fs layer can
restore them somehow.

Чт, 28 июля 2022 г. в 03:45, 'Thomas Lively' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> Thanks for the great writeup!
>
> >  WasmFS will notify jsdos layer that some file is changed (write/delete
> etc), so I can schedule update of *second* archive in cloud.
>
> Once the core WasmFS system is stable and documented, I hope it will be
> straightforward to create a custom virtual backend (i.e. a backend that
> forwards work to another backend) to fire notifications on file
> modifications.
>
> > At the end of extraction you will consume the same amount of memory as
> the original game size (e.g. 600Mb for CDROM games). ***Unacceptable for
> mobiles***.
>
> This should be possible to fix with WasmFS by streaming files into WasmFS
> persistent backends like the OPFS backend or a future IndexedDB backend.
> These backends will never store entire files in memory, unlike IDBFS in the
> current system. That streaming should be able to use the browser's built-in
> decompression schemes as well.
>
> > I can switch from zip archives to any "bundle/asset" file format* introduced
> by WasmFS*
>
> I don't think we have plans to introduce a new data bundle format native
> to WasmFS, but you can implement your own however you'd like.
>
> >  Initially I can download some metafile that contain information about
> the whole FS. When the dosbox tries to access some file, I will...
>
> This sounds like it could be implemented as a read-only backend that
> fetches data from the network combined with a layering virtual backend that
> reads missing data from the network backend and writes modifications to a
> second backend.
>
> Overall your planned changes sound like a good match for WasmFS. The core
> WasmFS backend API is still in flux, but once it is stabilized, we could
> certainly use help documenting it, providing utilities to make it easy to
> write new backends from C, C++, or JS, and writing general-purpose virtual
> backends for caching, layering, notifying on changes, etc.
>
> On Wed, Jul 27, 2022 at 10:17 AM Александр Гурьянов 
> wrote:
>
>> I know that WasmFS is in active development, and I want to switch jsdos
>> to WasmFS.
>> So, I want to share my use case and if needed help with development.
>>
>> jsdos is based on dosbox and it uses POSIX syscalls to access the file
>> system.
>>
>> *dosbox* has the following scenarios accessing files:
>> * directly accessing files in FS (read/write)
>> * mounting iso/cue images (CDROM support) (only read)
>>
>> *jsdos layer* has additional features:
>> * storing FS changes in cloud or idbs
>> * FS compression (currently I use zip)
>>
>> jsdos works with zip archives to populate the filesystem. The emulated
>> program has 2 zip archives:
>> ***first*** - is a initial game file system
>> ***second*** - contains changed files.
>> Before dosbox actually starts, these two "FS archives" are merged into
>> actual FS.
>>
>> Merge implementation is very simple:
>> 1. Extract *first* archive ***and store modification time of files in
>> hashtable***.
>> 2. Extract *second* archive and *overwrite* files
>>
>> When jsdos is exited (closed by user) it iterates over FS and checks if
>> some file have newer
>> modification time. If so, this file is added to brand new ***second***
>> archive.
>>
>> The ***second*** archive can be stored in idbfs, or in cloud.
>>
>> *This solution has practical problems:*
>> *1*. zip is slow when extracting files. Not dramatically, but it will be
>> much better to use native decoder of the browser (gzip/brotli).
>> *2*. I can say zip compression rate ***is good enough*** for most games.
>> But you* can't extract *big games on mobiles. It results in OOM. To
>> extract you need to download the whole archive (*1st copy*), put it into
>> WASM memory (*2st copy*) and keep it while it is extracting.
>> *3*. At the end of extraction you will consume the same amount of memory
>> as the original game size (e.g. 600Mb for CDROM games). ***Unacceptable
>> for mob

WasmFS for jsdos

2022-07-27 Thread Александр Гурьянов

I know that WasmFS is in active development, and I want to switch jsdos to
WasmFS.
So, I want to share my use case and if needed help with development.

jsdos is based on dosbox and it uses POSIX syscalls to access the file
system.

*dosbox* has the following scenarios accessing files:
* directly accessing files in FS (read/write)
* mounting iso/cue images (CDROM support) (only read)

*jsdos layer* has additional features:
* storing FS changes in cloud or idbs
* FS compression (currently I use zip)

jsdos works with zip archives to populate the filesystem. The emulated
program has 2 zip archives:
***first*** - is a initial game file system
***second*** - contains changed files.
Before dosbox actually starts, these two "FS archives" are merged into
actual FS.

Merge implementation is very simple:
1. Extract *first* archive ***and store modification time of files in
hashtable***.
2. Extract *second* archive and *overwrite* files

When jsdos is exited (closed by user) it iterates over FS and checks if
some file have newer
modification time. If so, this file is added to brand new ***second***
archive.

The ***second*** archive can be stored in idbfs, or in cloud.

*This solution has practical problems:*
*1*. zip is slow when extracting files. Not dramatically, but it will be
much better to use native decoder of the browser (gzip/brotli).
*2*. I can say zip compression rate ***is good enough*** for most games.
But you* can't extract *big games on mobiles. It results in OOM. To extract
you need to download the whole archive (*1st copy*), put it into WASM
memory (*2st copy*) and keep it while it is extracting.
*3*. At the end of extraction you will consume the same amount of memory as
the original game size (e.g. 600Mb for CDROM games). ***Unacceptable for
mobiles***.
*4*. There is no option in emscripten FS to notify jsdos when some file is
changed, because of that storing changes is triggered manually when the
user closes the jsdos window. BUT, most users just ***closes the browser
tab and lost all progress.***
*5*. The ***second*** archive can't handle deletion of files. If some file
is deleted it will be there on the next run. It's because there is no
marker in the zip to signal that some file needs to be deleted. However,
for jsdos this happens very rarely and can be ignored.

*WasmFS ideas:*
*1*. WasmFS will notify jsdos layer that some file is changed (write/delete
etc), so I can schedule update of *second* archive in cloud.
*2*. I can switch from zip archives to any "bundle/asset" file format*
introduced by WasmFS*. Initially I can download some metafile that contain
information about the whole FS. When the dosbox tries to access some file,
I will:

* stop execution with asyncify
* lookup in meta which FS block need to be downloaded
* download it (with progress indication)
* mount it
* resume execution

I imagine that we can use gzip/brotli *browser decoder* here.
I think this flow is more or less generic and can be implemented on the
WasmFS side, so from jsdos side I only need to build an asyncify white list.

*3*. Replacement for iso/cue. I can fix dosbox to understand WasmFS file
format form (2) to download only needed blocks.

*With switching to WasmFS I want to achieve three key features:*
* Minimize download size of full-CD games/programs (like RedAlert, Full
Throttle, Win95)
* Minimize memory consumption to work on mobiles
* Effectively store changes in cloud

If you have any question, or need my help, feel free to ask.

--
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%3DVHwC_W%2BkScuLm0U0m4UF4vCJ6ZUzF7D1F4AJZosrKx1kQ%40mail.gmail.com.

Re: -s ASYNCIFY=1 and -g

2022-07-18 Thread Александр Гурьянов

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


пт, 15 июл. 2022 г. в 11:06, 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> Looks like a bug to me.  Do you know which was the last version of
> emscripten where this worked for you?   Perhaps you could try bisecting (
> https://emscripten.org/docs/contributing/developers_guide.html#bisecting),
> and maybe open an issue?
>
> cheers,
> sam
>
> On Thu, Jul 14, 2022 at 7:57 PM Александр Гурьянов 
> wrote:
>
>> Hi. I recently updated to latest emscripten for Dune2. It uses
>> ASYNCIFY=1, but now when I compile project normally I have a lot of message
>> like:
>>
>> warning: Asyncify onlylist contained a non-existing function name:
>> GameOptions_Save (GameOptions_Save)
>> warning: Asyncify onlylist contained a non-existing function name:
>> Game_Init (Game_Init)
>> warning: Asyncify onlylist contained a non-existing function name:
>> Game_LoadScenario (Game_LoadScenario)
>> ...
>>
>> Almost every function that I have in asyncify list generate this warning.
>> And of course when I run the game in browser id didn't work. But if I add
>> -g to compile command
>> this warnings goes away and game works. *I don't understand is it
>> intended behavior or not?*
>>
>> The worst thing if remove -g and set ASSERTIONS=1, I see the "unreachable
>> executed" error but I can't understand the function name because it
>> obfuscated. I am very
>> confused how I should build asyncify list for *non -g* mode?
>>
>> --
>> 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%3DVH9%3D5UgJ4x9wRRtn8w69R3UVH3ZfQ-DJZH825vWNV5UrQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVH9%3D5UgJ4x9wRRtn8w69R3UVH3ZfQ-DJZH825vWNV5UrQ%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/CAL_va28WJwRJG%3DXo6Lam%3D6mnkKFRoeU%3DNih8TWYCWC56KGGLaQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28WJwRJG%3DXo6Lam%3D6mnkKFRoeU%3DNih8TWYCWC56KGGLaQ%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/CAKOm%3DVE3%2B0sBfCoEprNAh4%2B%3DBFEFXLHk0L9nZdzjOvQTGZe%2Bww%40mail.gmail.com.

-s ASYNCIFY=1 and -g

2022-07-14 Thread Александр Гурьянов

Hi. I recently updated to latest emscripten for Dune2. It uses ASYNCIFY=1,
but now when I compile project normally I have a lot of message like:

warning: Asyncify onlylist contained a non-existing function name:
GameOptions_Save (GameOptions_Save)
warning: Asyncify onlylist contained a non-existing function name:
Game_Init (Game_Init)
warning: Asyncify onlylist contained a non-existing function name:
Game_LoadScenario (Game_LoadScenario)
...

Almost every function that I have in asyncify list generate this warning.
And of course when I run the game in browser id didn't work. But if I add
-g to compile command
this warnings goes away and game works. *I don't understand is it intended
behavior or not?*

The worst thing if remove -g and set ASSERTIONS=1, I see the "unreachable
executed" error but I can't understand the function name because it
obfuscated. I am very
confused how I should build asyncify list for *non -g* mode?

-- 
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%3DVH9%3D5UgJ4x9wRRtn8w69R3UVH3ZfQ-DJZH825vWNV5UrQ%40mail.gmail.com.

Re: Using shared memory (-s IMPORTED_MEMORY=1)

2022-03-08 Thread Александр Гурьянов

I found error in my build system, so now everything works fine. 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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVH6uJZhWxF5huJxUtJzVkXfe3JXvxu6%3DF68OFL2B58yeg%40mail.gmail.com.

Re: Using shared memory (-s IMPORTED_MEMORY=1)

It compiles with flags -sSHARED_MEMORY=1 -sUSE_PTHREADS=1, but it didn't
start in worker:

wdosbox.js:6935 Uncaught (in promise) LinkError: WebAssembly.instantiate():
Import #46 module="env" function="emscripten_unwind_to_js_event_loop"
error: function import requires a callable

I checked there is no such function on info.env, maybe it's incompatible
with -s ASYNCIFY=1?

сб, 5 мар. 2022 г. в 13:06, Александр Гурьянов :

> I tried set SHARED_MEMORY=1 both for compile and linking, but now I have
> this error from linker:
> wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was
> not compiled with 'atomics' or 'bulk-memory' features
>
> Seems that I need to set PTHREADS anyway. I don't want use PTHREADS
> because I don't know how it affects performance of wasm, can it slowdown
> the overall performance?
>
>
> сб, 5 мар. 2022 г. в 03:27, 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Also note that you probably do want to use atomic operations to read and
>> write to the shared memory, even if you're using JS on one thread and Wasm
>> on another. If you don't use atomics, there's no guarantee that the values
>> written on one thread will actually become visible on the other thread when
>> you expect them to.
>>
>> On Fri, Mar 4, 2022 at 11:49 AM 'Sam Clegg' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>> Historically the `-pthead` flag (or `-s USE_PTHREADS`) is the way to get
>>> shared memory.   Is there some reason you have not wanted to use that
>>> flag?  (is it code size
>>> of the resulting JS.. if so we are working on reducing that).
>>>
>>> As it happens we just today landed a new `-s SHARED_MEMORY` flag I think
>>> gives you exactly what you want without the overhead of the pthread JS
>>> library code: https://github.com/emscripten-core/emscripten/pull/16419.
>>>
>>> cheers,
>>> sam
>>>
>>> On Fri, Mar 4, 2022 at 10:29 AM Александр Гурьянов 
>>> wrote:
>>>
>>>> https://github.com/WebAssembly/binaryen/pull/4525
>>>>
>>>>
>>>> пт, 4 мар. 2022 г. в 15:43, Александр Гурьянов :
>>>>
>>>>> Hi, I want to use shared memory for my WebAssembly module. It's needed
>>>>> for js-dos. Currently emulation works in worker and frame updates are send
>>>>> using postMessage. I want to use SharedArrayBuffer to avoid 
>>>>> copying/sending
>>>>> big rgba data.
>>>>>
>>>>> I dont' need to use pthread or threading, I just want to share memory
>>>>> between worker and main process. How I can say emscripten to generate
>>>>> "shared" memory imort.
>>>>>
>>>>> I found similar question here:
>>>>> https://github.com/emscripten-core/emscripten/issues/12098
>>>>> As suggested I tried wasm2wat and then wat2wasm, but it not working
>>>>> for me. Looks like it affects  -s INVOKE_RUN=0, because after wasm2wat my
>>>>> module immediately starts and I can't provide own memory.
>>>>>
>>>>> Without wasm2wat I have this error:
>>>>>
>>>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>>>> memory, declared = *0*, imported = *1*
>>>>>
>>>>> After wasm2wat this:
>>>>>
>>>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>>>> memory, declared = *1*, imported = *0*
>>>>>
>>>>> Can we add some pass to binaryen for turning non-shared memory into
>>>>> shared?
>>>>>
>>>> --
>>>> 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%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>>

Re: Using shared memory (-s IMPORTED_MEMORY=1)

I tried set SHARED_MEMORY=1 both for compile and linking, but now I have
this error from linker:
wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was not
compiled with 'atomics' or 'bulk-memory' features

Seems that I need to set PTHREADS anyway. I don't want use PTHREADS because
I don't know how it affects performance of wasm, can it slowdown the
overall performance?


сб, 5 мар. 2022 г. в 03:27, 'Thomas Lively' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> Also note that you probably do want to use atomic operations to read and
> write to the shared memory, even if you're using JS on one thread and Wasm
> on another. If you don't use atomics, there's no guarantee that the values
> written on one thread will actually become visible on the other thread when
> you expect them to.
>
> On Fri, Mar 4, 2022 at 11:49 AM 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Historically the `-pthead` flag (or `-s USE_PTHREADS`) is the way to get
>> shared memory.   Is there some reason you have not wanted to use that
>> flag?  (is it code size
>> of the resulting JS.. if so we are working on reducing that).
>>
>> As it happens we just today landed a new `-s SHARED_MEMORY` flag I think
>> gives you exactly what you want without the overhead of the pthread JS
>> library code: https://github.com/emscripten-core/emscripten/pull/16419.
>>
>> cheers,
>> sam
>>
>> On Fri, Mar 4, 2022 at 10:29 AM Александр Гурьянов 
>> wrote:
>>
>>> https://github.com/WebAssembly/binaryen/pull/4525
>>>
>>>
>>> пт, 4 мар. 2022 г. в 15:43, Александр Гурьянов :
>>>
>>>> Hi, I want to use shared memory for my WebAssembly module. It's needed
>>>> for js-dos. Currently emulation works in worker and frame updates are send
>>>> using postMessage. I want to use SharedArrayBuffer to avoid copying/sending
>>>> big rgba data.
>>>>
>>>> I dont' need to use pthread or threading, I just want to share memory
>>>> between worker and main process. How I can say emscripten to generate
>>>> "shared" memory imort.
>>>>
>>>> I found similar question here:
>>>> https://github.com/emscripten-core/emscripten/issues/12098
>>>> As suggested I tried wasm2wat and then wat2wasm, but it not working for
>>>> me. Looks like it affects  -s INVOKE_RUN=0, because after wasm2wat my
>>>> module immediately starts and I can't provide own memory.
>>>>
>>>> Without wasm2wat I have this error:
>>>>
>>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>>> memory, declared = *0*, imported = *1*
>>>>
>>>> After wasm2wat this:
>>>>
>>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>>> memory, declared = *1*, imported = *0*
>>>>
>>>> Can we add some pass to binaryen for turning non-shared memory into
>>>> shared?
>>>>
>>> --
>>> 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%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%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/CAL_va2_UWBhM-2yOG_6aUDPa_%3DX%3DmDJOxaC00Bo8CbQa6cDbYw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_UWBhM-2yOG_6aUDPa_%3DX%3DmDJOxaC00Bo8CbQa6cDbYw%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/CAJZD_EWNu%3Di0%3DACiKbuPyTOUAckT1SDceosApBvJj6VCo8-WYQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWNu%3Di0%3DACiKbuPyTOUAckT1SDceosApBvJj6VCo8-WYQ%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/CAKOm%3DVFgLTrfXrMBjSyUy_eczWoaAF2L4zWQKPPAr3uizNWt1g%40mail.gmail.com.

Re: Using shared memory (-s IMPORTED_MEMORY=1)

https://github.com/WebAssembly/binaryen/pull/4525


пт, 4 мар. 2022 г. в 15:43, Александр Гурьянов :

> Hi, I want to use shared memory for my WebAssembly module. It's needed for
> js-dos. Currently emulation works in worker and frame updates are send
> using postMessage. I want to use SharedArrayBuffer to avoid copying/sending
> big rgba data.
>
> I dont' need to use pthread or threading, I just want to share memory
> between worker and main process. How I can say emscripten to generate
> "shared" memory imort.
>
> I found similar question here:
> https://github.com/emscripten-core/emscripten/issues/12098
> As suggested I tried wasm2wat and then wat2wasm, but it not working for
> me. Looks like it affects  -s INVOKE_RUN=0, because after wasm2wat my
> module immediately starts and I can't provide own memory.
>
> Without wasm2wat I have this error:
>
> LinkError: WebAssembly.instantiate(): mismatch in shared state of memory,
> declared = *0*, imported = *1*
>
> After wasm2wat this:
>
> LinkError: WebAssembly.instantiate(): mismatch in shared state of memory,
> declared = *1*, imported = *0*
>
> Can we add some pass to binaryen for turning non-shared memory into shared?
>

-- 
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%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%40mail.gmail.com.

Using shared memory (-s IMPORTED_MEMORY=1)

Hi, I want to use shared memory for my WebAssembly module. It's needed for
js-dos. Currently emulation works in worker and frame updates are send
using postMessage. I want to use SharedArrayBuffer to avoid copying/sending
big rgba data.

I dont' need to use pthread or threading, I just want to share memory
between worker and main process. How I can say emscripten to generate
"shared" memory imort.

I found similar question here:
https://github.com/emscripten-core/emscripten/issues/12098
As suggested I tried wasm2wat and then wat2wasm, but it not working for me.
Looks like it affects  -s INVOKE_RUN=0, because after wasm2wat my module
immediately starts and I can't provide own memory.

Without wasm2wat I have this error:

LinkError: WebAssembly.instantiate(): mismatch in shared state of memory,
declared = *0*, imported = *1*

After wasm2wat this:

LinkError: WebAssembly.instantiate(): mismatch in shared state of memory,
declared = *1*, imported = *0*

Can we add some pass to binaryen for turning non-shared memory into shared?

-- 
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%3DVFj%3D%3DNiy1r-Y7YFgAdbGs%2BS-rYgr3dTnyi%2BJEcagb3u%2Bw%40mail.gmail.com.

Re: std::isnan, std::isinf not working

2022-03-01 Thread Александр Гурьянов

Okay I found the answer it's a result of using optimization flags -Oz
--ffast-math. If you remove one of it - works correctly. Also behavior is
exactly same in clang++, so I think there is no error from emscripten.
My last test case:

#include 
#include 
#include 

int main(int argc, char **argv) {
  float val = std::numeric_limits::quiet_NaN();

  printf("val '%.2f', isnan:%s\n", val,
 std::isnan(val) ? "yes" : "no");

  return 0;
}



ср, 2 мар. 2022 г. в 08:46, Александр Гурьянов :

> I tried to do this but in empty project it works correctly. I converted
> the float to int32_t like this:
>
> int32_t* val = (int32_t) 
> printf("%d\n", *val);
>
> and the number was 2143289344, I created testcase:
>
> #include 
> #include 
>
> int main(int argc, char** argv) {
> int32_t nan = 2143289344;
> float* val = (float *) 
>
> printf("val '%.2f', isnan:%s, isinf:%s\n", *val,
>std::isnan(*val) ? "yes" : "no",
>std::isinf(*val) ? "yes" : "no");
>
> return 0;
> }
>
> but it works correctly:
>
> val 'nan', isnan: yes, isinf: no
>
> Moreover in native build of project there is no NAN in problem place, it
> appears only in emscripten build. So, probably error happens somewhere
> else... Trying to understand.
>
> ср, 2 мар. 2022 г. в 00:18, 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Perhaps if you print the actual bitpattern at the point of failure you
>> can use that to create a repro case?   Without a repro case I think this
>> will be hard to make progress on.  Once you have a repro please open an bug
>> report on github.
>>
>> chers,
>> sam
>>
>>
>> On Tue, Mar 1, 2022 at 8:38 AM Александр Гурьянов 
>> wrote:
>>
>>> Hi,  I faced problem that std::isnan return false for NAN. I added this
>>> debug printf to my project:
>>>
>>> printf("res %.2f %s %s\n", res,
>>>std::isnan(res) ? "isnan" : "notnan",
>>>std::isinf(res) ? "isinf" : "notinf");
>>>
>>> and when res is NAN, output is following:
>>>
>>> res nan notnan notinf
>>>
>>> I tried to make a simple test case, but in test case it works fine. So,
>>> I think this is a sort of UB, but I run project with valgrind - no errors.
>>> I tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
>>>
>>> Any suggestions what it can be?
>>>
>>> --
>>> 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%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%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/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%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/CAKOm%3DVGtzeNfAFWq%2BqOvH%2BTszifn2n0tP3xQ%3DTZUEZwe2BaqNw%40mail.gmail.com.

Re: std::isnan, std::isinf not working

2022-03-01 Thread Александр Гурьянов

I tried to do this but in empty project it works correctly. I converted the
float to int32_t like this:

int32_t* val = (int32_t) 
printf("%d\n", *val);

and the number was 2143289344, I created testcase:

#include 
#include 

int main(int argc, char** argv) {
int32_t nan = 2143289344;
float* val = (float *) 

printf("val '%.2f', isnan:%s, isinf:%s\n", *val,
   std::isnan(*val) ? "yes" : "no",
   std::isinf(*val) ? "yes" : "no");

return 0;
}

but it works correctly:

val 'nan', isnan: yes, isinf: no

Moreover in native build of project there is no NAN in problem place, it
appears only in emscripten build. So, probably error happens somewhere
else... Trying to understand.

ср, 2 мар. 2022 г. в 00:18, 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> Perhaps if you print the actual bitpattern at the point of failure you can
> use that to create a repro case?   Without a repro case I think this will
> be hard to make progress on.  Once you have a repro please open an bug
> report on github.
>
> chers,
> sam
>
>
> On Tue, Mar 1, 2022 at 8:38 AM Александр Гурьянов 
> wrote:
>
>> Hi,  I faced problem that std::isnan return false for NAN. I added this
>> debug printf to my project:
>>
>> printf("res %.2f %s %s\n", res,
>>std::isnan(res) ? "isnan" : "notnan",
>>std::isinf(res) ? "isinf" : "notinf");
>>
>> and when res is NAN, output is following:
>>
>> res nan notnan notinf
>>
>> I tried to make a simple test case, but in test case it works fine. So, I
>> think this is a sort of UB, but I run project with valgrind - no errors. I
>> tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.
>>
>> Any suggestions what it can be?
>>
>> --
>> 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%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%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/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_hYHdYk7oercuCm4jHmhfo0tiZqoUM2O%3DTiONbpGsqZg%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/CAKOm%3DVGQm2Xg_u6OEL0h0denGWdL7pmJTYSK%2BysvAbvwhT_fYQ%40mail.gmail.com.

std::isnan, std::isinf not working

2022-03-01 Thread Александр Гурьянов

Hi,  I faced problem that std::isnan return false for NAN. I added this
debug printf to my project:

printf("res %.2f %s %s\n", res,
   std::isnan(res) ? "isnan" : "notnan",
   std::isinf(res) ? "isinf" : "notinf");

and when res is NAN, output is following:

res nan notnan notinf

I tried to make a simple test case, but in test case it works fine. So, I
think this is a sort of UB, but I run project with valgrind - no errors. I
tried -s ASSERTIONS=1 -s SAFE_HEAP=2, also no errors.

Any suggestions what it can be?

-- 
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%3DVHMsym8-XQXp7fb5xz7kaG_fV-M19aj-kUzbdAEbxG7Yg%40mail.gmail.com.

Re: Any ideas how to capture the mouse with emscripten/html5.h functions?

2022-02-08 Thread Александр Гурьянов

I use "leave" event as workaround. When "pressed" pointer leaves canvas it
automatically became unpressed. It works fine in most cases for me.

вт, 8 февр. 2022 г. в 20:29, Floh :

> oops typos:
>
> > setCapture()/releaseCapture() event pair
>
> ...this should be "function pair". Don't know why I got that wrong *twice*
> :)
>
> On Tuesday, 8 February 2022 at 14:28:30 UTC+1 Floh wrote:
>
>> First...I don't mean pointer-lock (which works fine), but instead the
>> setCapture() (old) or setPointerCapture() (new) functionality.
>>
>> For example, if I drag a Dear ImGui window and the mouse pointer goes out
>> of the browser window, mouse events are no longer reported. Releasing the
>> mouse button outside the window means that the ImGui window now sticks to
>> the mouse button when the mouse is moved back inside, because the
>> application still thinks the mouse button is pressed.
>>
>> In the olden times, there was a setCapture()/releaseCapture() event pair,
>> which doesn't work in Chrome.
>>
>> In modern times, there's a new
>> setPointerCapture()/releasePointerCapture() event pair, but this requires a
>> 'pointerId' parameter, which isn't part of the regular mouse events, but of
>> the derived 'pointer events'.
>>
>> Long story short, has anybody managed to hack this somehow with the
>> emscripten_*() functions? I tinkered around with calling an EM_JS()
>> function from within the mouse button event handlers, which then calls
>> setPointerCapture/releasePointerCapture, but that isn't successful because
>> those functions want an actual, active "pointerId" object, not just some
>> random number :D
>>
>> I guess that emscripten/html5.h needs a new set of event functions for
>> pointer events (
>> https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events),
>> instead of regular mouse events?
>>
>> 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/6f17bf5e-5c08-4e8b-996c-437d62d0fa1fn%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%3DVHYxqtkUTRQnSRytJGQNxU%3DH1T-Do7FwQ6OhkamJfcQXQ%40mail.gmail.com.

Re: Rust journey

2022-02-06 Thread Александр Гурьянов

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 
>>>>>>>> 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_mang

Re: Rust journey

2022-02-04 Thread Александр Гурьянов

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 Александр Гурьянов 
>>>>> 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_ffi version expected 1, actual 0
>>>>>>
>>>>>> For me it looks like static initializer from RUST didn't run. Because
>>>>>> if I comment the abort(); seems integration works fine. Native build 
>>>>>> works
>>>>>> correctly...
>>>>>> Do you have any idea why so?
>>>>>>
>>>>>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
>>>>>>> caii...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Let's look closer to my case. I ported C++

Re: Rust journey

2022-01-26 Thread Александр Гурьянов

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 Александр Гурьянов 
>> 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_ffi version expected 1, actual 0
>>>
>>> For me it looks like static initializer from RUST didn't run. Because if
>>> I comment the abort(); seems integration works fine. Native build works
>>> correctly...
>>> Do you have any idea why so?
>>>
>>> ср, 19 янв. 2022 г. в 00:36, 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 selec

Re: Rust journey

2022-01-26 Thread Александр Гурьянов

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_ffi version expected 1, actual 0

For me it looks like static initializer from RUST didn't run. Because if I
comment the abort(); seems integration works fine. Native build works
correctly...
Do you have any idea why so?

ср, 19 янв. 2022 г. в 00:36, 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

Re: Rust journey

2022-01-14 Thread Александр Гурьянов

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

for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32
target, they select wrong code path (non-native).

пт, 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:
>>>>
>>>> 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

Re: Rust journey

2022-01-13 Thread Александр Гурьянов

+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 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%3DVFgNcSPR-KFe35yg%2BU9NXFpG7U_Y5G0APbkZRf5UM2%2B8w%40mail.gmail.com.

Rust journey

2021-12-24 Thread Александр Гурьянов

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.

Asyncify and emscripten updates

2021-08-24 Thread Александр Гурьянов

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.

wasm-split to multiple modules

2021-04-21 Thread Александр Гурьянов

Hi.I have a custom optimization layer that helps me to decrease wasm binary
size. It is a sort of PGO optimization, I have a statistic about each
function in wasm - how many times it called. Then I remove functions with
zero invocations from wasm and generate js version of same function to
invoke if it suddenly needed (1 js file - 1 removed function). This
optimization works very good except it uses js which is slow and big.

Now I want to generate small wasm modules (<4Kb) instead of js versions. I
thought that wasm-split can help, but I realized that it generates a big
module that can't be load in synchronous way. Moreover there is another
problem, it replaces all placeholders with actual implementation on
instantiation. But, I don't want to replace placeholders because they
continue to track call stats (this is minor problem, I know workaround for
it).

Is there some way to force wasm-split to generate multiple modules (1 per
function). Something like this:

  std::unique_ptr fn1 =
ModuleSplitting::splitFunctions(wasm, );
  std::unique_ptr fn2 =
ModuleSplitting::splitFunctions(wasm, );

...

  ModuleWriter writer;
  writer.setBinary(options.emitBinary);
  writer.setDebugInfo(options.passOptions.debugInfo);
  writer.write(wasm, options.primaryOutput);
  writer.write(*fn1, wasmFn1);
  writer.write(*fn2, wasmFn2);

Or if it's not possible, what do you think is it doable and how hard is it?

-- 
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%3DVGzr8Wr_MR4733AkKnkkyoq2ainU6kzsS9dOkVuXki7NQ%40mail.gmail.com.

Re: regenerate wasm.js from preamble.js

2021-04-21 Thread Александр Гурьянов

I did it. However I realized that it is not what I actually want, I will
write a new topic.

ср, 21 апр. 2021 г. в 09:05, Александр Гурьянов :

> Yeah pushing emscripten of Unity to new version is a best solution either,
> but I think it's impossible. They didn't change emscripten version for many
> years, they use 1.38.11. I don't know why, maybe there is some internal
> problem, but seems it's not into their priority. They  still use js2wasm to
> generate WebAssembly.
>
> I tried to update it manually by replacing emscripten, and hook into build
> scripts, however they also uses *.bc files to link into binary. As answered
> before, it's not possible to use *.bc files from older version of
> emscripten with newer emscripten.
>
> So, I see back porting wasm-split is only solution, btw I hope it will not
> be super hard. I did similar stuff with js split. I use wasm file from
> unity and split out some functions into js, now I just want to improve my
> technology with wasm-split.
>
>
>
> ср, 21 апр. 2021 г. в 00:31, 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> SPLIT_MODULE is currently experimental, with limited testing.   Trying to
>> backport it to an older version of emscripten, while not impossible, is
>> likely to result in many challenges, and is not really a use case that we
>> want to have to support.   It might just work.. but you will likely need to
>> get down in the weeds to fix any issues that come up.   Your energy may be
>> better spent trying to push unity to upgrade the version of emscripten they
>> support.
>>
>> cheers,
>> sam
>>
>> 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
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHu%2B5srLKjuitYZLhtpbiFg6RdSjLytNcg6XwzDk3Wf%2Bw%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/CAL_va29o-%2Bu__%2BjOephiNmCKCXD8XxPrhgYuL%3DBEmwn8bYMHHg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29o-%2Bu__%2BjOephiNmCKCXD8XxPrhgYuL%3DBEmwn8bYMHHg%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/CAKOm%3DVFgBh%2BnriFcmT71tqsc-ooEPeBWzAnZavckM7gwCOo8bQ%40mail.gmail.com.

Re: regenerate wasm.js from preamble.js

2021-04-20 Thread Александр Гурьянов

Yeah pushing emscripten of Unity to new version is a best solution either,
but I think it's impossible. They didn't change emscripten version for many
years, they use 1.38.11. I don't know why, maybe there is some internal
problem, but seems it's not into their priority. They  still use js2wasm to
generate WebAssembly.

I tried to update it manually by replacing emscripten, and hook into build
scripts, however they also uses *.bc files to link into binary. As answered
before, it's not possible to use *.bc files from older version of
emscripten with newer emscripten.

So, I see back porting wasm-split is only solution, btw I hope it will not
be super hard. I did similar stuff with js split. I use wasm file from
unity and split out some functions into js, now I just want to improve my
technology with wasm-split.



ср, 21 апр. 2021 г. в 00:31, 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> SPLIT_MODULE is currently experimental, with limited testing.   Trying to
> backport it to an older version of emscripten, while not impossible, is
> likely to result in many challenges, and is not really a use case that we
> want to have to support.   It might just work.. but you will likely need to
> get down in the weeds to fix any issues that come up.   Your energy may be
> better spent trying to push unity to upgrade the version of emscripten they
> support.
>
> cheers,
> sam
>
> 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
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHu%2B5srLKjuitYZLhtpbiFg6RdSjLytNcg6XwzDk3Wf%2Bw%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/CAL_va29o-%2Bu__%2BjOephiNmCKCXD8XxPrhgYuL%3DBEmwn8bYMHHg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29o-%2Bu__%2BjOephiNmCKCXD8XxPrhgYuL%3DBEmwn8bYMHHg%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/CAKOm%3DVGrYHRt2A3dWw2wKdDuQK2VecMAv7a5MVrJ02w-%2BYEf9w%40mail.gmail.com.

regenerate wasm.js from preamble.js

2021-04-20 Thread Александр Гурьянов

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.

Re: Extremely slow startup time in Node environment

2021-03-01 Thread Александр Гурьянов

*node --liftoff --no-wasm-tier-up  dhry2_node.js*
Runtime initialized after 49.4109835826 ms

вт, 2 мар. 2021 г. в 09:11, Александр Гурьянов :

> Yeah...
> ~/Загрузки/node-v14.16.0-linux-x64/bin/*node  dhry2_node.js*
> Runtime initialized after 16328.0365122 ms
> dhry2: 1 181.949037 31.280845
> dhry2: 2 353.980880 32.157215
> dhry2: 4 720.280341 31.607247
> dhry2: 8 1366.479560 33.320774
> dhry2: 16 2578.543112 35.316188
> dhry2: 32 5049.154954 36.07
>
> ~/Загрузки/node-v14.16.0-linux-x64/bin/*node --liftoff --no-wasm-tier-up
>  dhry2_node.js*
> dhry2: 1 236.612041 24.054227
> dhry2: 2 500.253110 22.754560
> dhry2: 4 900.747170 25.274660
> dhry2: 8 1808.096051 25.182377
> dhry2: 16 3842.752959 23.697676
>
>
> вт, 2 мар. 2021 г. в 02:43, 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");

Re: Extremely slow startup time in Node environment

2021-03-01 Thread Александр Гурьянов

Yeah...
~/Загрузки/node-v14.16.0-linux-x64/bin/*node  dhry2_node.js*
Runtime initialized after 16328.0365122 ms
dhry2: 1 181.949037 31.280845
dhry2: 2 353.980880 32.157215
dhry2: 4 720.280341 31.607247
dhry2: 8 1366.479560 33.320774
dhry2: 16 2578.543112 35.316188
dhry2: 32 5049.154954 36.07

~/Загрузки/node-v14.16.0-linux-x64/bin/*node --liftoff --no-wasm-tier-up
 dhry2_node.js*
dhry2: 1 236.612041 24.054227
dhry2: 2 500.253110 22.754560
dhry2: 4 900.747170 25.274660
dhry2: 8 1808.096051 25.182377
dhry2: 16 3842.752959 23.697676


вт, 2 мар. 2021 г. в 02:43, 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) {

if (!this) is allowed?

2021-02-24 Thread Александр Гурьянов

Hi, I have a big code base that uses this pattern:

```

int String::intValue() const {
if (!this) {
return 0;
}

   // ...
}

int count = dict->stringForKey("count")->intValue();

```

If *dict->stringForKey* returns *nullptr* then wasm is crashed, but native
works fine.
This code also worked fine with old versions of emscipten.

I understand that this is ugly pattern, but I am curious if it can work as
before?

-- 
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%3DVF2kSJEthLuvS7afsPFprxehG%3DXJxppdHxMA6a8rvUyAw%40mail.gmail.com.

Re: HEAP* not accessible anymore through Module object

2021-02-17 Thread Александр Гурьянов

First bad commit is
https://github.com/emscripten-core/emscripten/commit/c2462cdb9495ed0aa398491e1a3091dbd34c742e
I used suggested -s IMPORTED_MEMORY=1 and it works fine now.

I need custom wasm instantiate function, because I need to inject some
environment that used at runtime initialization step. It's important to get
reference to HEAP before any wasm code is begin executing. Because of this
Module().then() can't work for me.

чт, 18 февр. 2021 г. в 03:07, 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/

Re: HEAP* not accessible anymore through Module object

2021-02-16 Thread Александр Гурьянов

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
>> 
>> .
>>
> --
> 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
> 
> .
>

-- 
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%3DVGfsUdji1Zx5UpKrLR0gbwqD3L3fOLTycnCVCGTOQfahw%40mail.gmail.com.

HEAP* not accessible anymore through Module object

2021-02-16 Thread Александр Гурьянов

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.

Re: "Downloading" data in the filesystem

2021-01-05 Thread Александр Гурьянов

Hi I have the implementation for zip/unzip in js-dos. I used libzip,
you can check it here:
https://github.com/caiiiycuk/js-dos/tree/emulators/native/libzip


WASM module exports 2 functions in js:
* zip_to_fs(data, len) - zip archive will be extracted into emscripten FS
* zip_from_fs() -  emscripten FS will be packed back to zip (compression is -9)

Alternatively you can use zip.js, it works totally fine and its pure js.
https://gildas-lormeau.github.io/zip.js/

вт, 5 янв. 2021 г. в 19:50, Floh :
>
> I have implemented very simple versions of this functionality (no zip 
> compression, and no emscripten filesystem API, which I think doesn't help 
> much for this stuff) in some of my WASM apps and demos.
>
> This one can load and save ASM text files via the HTML5 file dialog interface 
> (look under the "File" menu):
>
> https://floooh.github.io/visual6502remix/
>
> And here's a demo to load data via drag and drop:
>
> https://floooh.github.io/sokol-html5/droptest-sapp.html
>
> Unfortunately this kind of stuff isn't doable via emscripten APIs alone, 
> you'll have to use a mix of C and Javascript (mostly Javascript), and move 
> the data in and out of the WASM heap.
>
> The core of the drag'n'drop code is here:
>
> https://github.com/floooh/sokol/blob/5894182dddc2e0fd6531e5a2deb5d9cf7662ea2a/sokol_app.h#L3907-L3978
>
> Basically the "usual" HTML5 drag'n'drop event handlers as embedded 
> Javascript, listening for dropped-events, and copying the "payload" into the 
> WASM heap. Due to the asynchronous nature of Javascript APIs this is a quite 
> confusing mess of calling back and forth between the JS and C side 
> unfortunately.
>
> The code to load and save data via the file dialog is here:
>
> https://github.com/floooh/v6502r/blob/d7f113e0d3e0bcb2fb283acab9a86c257c5d4ca7/src/util.c#L28-L94
>
> ...but this stuff is even more confusing and only makes sense after you know 
> how the Javascript APIs work (TBH looking at this stuff after a year I have 
> no idea anymore how it actually works, I only remember that I had a lot of 
> trouble getting it to work across all browsers, and that I had to use 
> outdated and deprecated techniques to get cross-browser compatibility (at 
> least for the "download data to the user machine" stuff).
>
> https://github.com/floooh/v6502r/blob/d7f113e0d3e0bcb2fb283acab9a86c257c5d4ca7/src/util.c#L28-L94
>
> This is a great example of how convoluted and overall terrible web 
> development is, what's a single call in a "native" operating system is 
> usually a jenga tower of hacks and outdated APIs in the web world (...and 
> don't get me started on clipboard support) :/
>
> But I hope this still helps a bit!
> On Saturday, 2 January 2021 at 02:03:24 UTC+1 rapt...@gmail.com wrote:
>>
>> Hi all,
>> My emscripten project is an entertainment app that allows the user to create 
>> things in an editor.  I'm storing the data using the filesystem API, and it 
>> all works fine.  But I want to provide some additional functionality.
>>
>> I would like to let the user click a button, zip up all their data, and 
>> offer it for download (so they can make backups in case of clearing browser 
>> data, etc.  Similarly, I'd like to provide a reverse process where they can 
>> drop a zip onto the browser and take control of it with emscripten so that I 
>> can unzip it and put it into the filesystem.
>>
>> Is this possible?  And if so, can anyone give me a direction to look in for 
>> implementing it?  When I try to google it, there is so much noise that I 
>> can't find any answers.
>>
>> 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/838c6f50-e115-463f-8688-2de901992ce6n%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%3DVHAaboWUOAkuZo1qG%3DmL0epZMtjL-A_rwSyTW61-vMO2Q%40mail.gmail.com.

Re: 2.0.3 getMemory is undefined

2020-09-14 Thread Александр Гурьянов

Okay) This is very stupid, I created test case and was so close to
create issue, but I found a reason.
It's because I have this:
-s EXTRA_EXPORTED_RUNTIME_METHODS=\"['getMemory', ...
Actually it's never used and when I removed it all tests were passed.

Thanks!

пн, 14 сент. 2020 г. в 22:05, 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 
>  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.
>

Re: 2.0.3 getMemory is undefined

2020-09-13 Thread Александр Гурьянов

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.

2.0.3 getMemory is undefined

2020-09-13 Thread Александр Гурьянов

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.

Re: PSA: emsdk non-embedded mode is going away

2020-06-24 Thread Александр Гурьянов

+1

чт, 25 июн. 2020 г. в 04:04, 'Sam Clegg' via emscripten-discuss
:
>
> See https://github.com/emscripten-core/emsdk/pull/510
>
> The while ago we switch emsdk to use an embedded config file by default.  
> This means it won't write to your $HOME directory but store the config inside 
> emsdk itself.
>
> I had included an --no-embeded flag to fall back to the old behaviour but at
> this point would like to remove it.   Is anyone relying on this mode (i.e. Is 
> anyone using this flag?).
>
> cheere,
> sam
>
>
>
> --
> 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_va287XzCeuBstrZ71E0As7wuAu%3D9_S0_%2BJ-Z%3Ddjk%2BFpsGrA%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%3DVEwoghddLOg-vfvuKRZV1iJzMCca-pj4KhAjrSLpv8vTA%40mail.gmail.com.

Re: Does -s ERROR_ON_UNDEFINED_SYMBOLS=0 actually works

2020-04-28 Thread Александр Гурьянов

I think yes. For me it's very useful, sometimes it easier to remove
some sources from project then trying to compile them for web.

ср, 29 апр. 2020 г. в 03:56, 'Sam Clegg' via emscripten-discuss
:
>
>
>
> On Sun, Apr 26, 2020 at 8:55 PM Александр Гурьянов  
> wrote:
>>
>> This program is a game, that contains game itself and builtin level
>> editor. They are tight coupled using raw pointers. Game was designed
>> in way that in release mode editor is not accessible, it only
>> available in debug build. But it was using pointers, so for compiler
>> release and debug build is same on source code level. But it's true
>> that in release build editor is never called. So, for minify wasm size
>> I doesn't include editor sources in final build.
>>
>
> So do you think it would make sense to set the address of any 
> link-time-undefined data symbols to zero in this case?  It seems like the 
> only option.
>
>
>
>>
>> --
>> 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%3DVHmemJV39_y5iFBdzwMkiME7fvMacr559cx5kegBJzKdg%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_va29zsF%2B_9tKcKB__TiWdTndMvwTqXFPHQ3RpNLBtRX1weQ%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%3DVEE_63z35eqYkHpg4iZVchVwv8wKZG_RqEJZDQfjBQ-%3DQ%40mail.gmail.com.

Re: Does -s ERROR_ON_UNDEFINED_SYMBOLS=0 actually works

2020-04-26 Thread Александр Гурьянов

This program is a game, that contains game itself and builtin level
editor. They are tight coupled using raw pointers. Game was designed
in way that in release mode editor is not accessible, it only
available in debug build. But it was using pointers, so for compiler
release and debug build is same on source code level. But it's true
that in release build editor is never called. So, for minify wasm size
I doesn't include editor sources in final build.

-- 
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%3DVHmemJV39_y5iFBdzwMkiME7fvMacr559cx5kegBJzKdg%40mail.gmail.com.

Re: Does -s ERROR_ON_UNDEFINED_SYMBOLS=0 actually works

2020-04-26 Thread Александр Гурьянов

*I can't compile it, even with -s ERROR_ON_UNDEFINED_SYMBOLS=0

пн, 27 апр. 2020 г. в 10:15, Александр Гурьянов :
>
> Hi. I have old project that was compiled with fastcomp. Now I updated
> it to upstream, but I have error on link stage.
> ```
> wasm-ld: error: CMakeFiles/bin-obj.dir/AppDelegate.cpp.o: undefined
> symbol: typeinfo for EditorScene
> wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
> symbol: vtable for IAPPlatformDummy
> wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
> symbol: typeinfo for OnlineLevelListScene
> wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
> symbol: typeinfo for CommunityScene
> wasm-ld: error: CMakeFiles/bin-obj.dir/Scenes/SocialLayer.cpp.o:
> undefined symbol: typeinfo for OnlineLevelListLayer
> ...
> wasm-ld: error: too many errors emitted, stopping now (use
> -error-limit=0 to see all errors)
> shared:ERROR: '/home/caiiiycuk/sdk/emsdk/upstream/bin/wasm-ld
> @/tmp/emscripten_ricuunpu.rsp' failed (1)
> ```
>
> This project have a lot of undefined symbols, and it's ok. For native
> I can successfully compile it with
> ```
> set(CMAKE_EXE_LINKER_FLAGS "-Wl,--unresolved-symbols=ignore-all")
> ```
>
> And it works fine. For web I used fastcomp with -s
> ERROR_ON_UNDEFINED_SYMBOLS=0 and it works fine.
> But now, I can compile it, event with -s ERROR_ON_UNDEFINED_SYMBOLS=0

-- 
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%3DVGPWSd7%2ByPVAhBMB3rh8Y1P3vGHRvAx7ey6aG6R_Nob0Q%40mail.gmail.com.

Does -s ERROR_ON_UNDEFINED_SYMBOLS=0 actually works

2020-04-26 Thread Александр Гурьянов

Hi. I have old project that was compiled with fastcomp. Now I updated
it to upstream, but I have error on link stage.
```
wasm-ld: error: CMakeFiles/bin-obj.dir/AppDelegate.cpp.o: undefined
symbol: typeinfo for EditorScene
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: vtable for IAPPlatformDummy
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: typeinfo for OnlineLevelListScene
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: typeinfo for CommunityScene
wasm-ld: error: CMakeFiles/bin-obj.dir/Scenes/SocialLayer.cpp.o:
undefined symbol: typeinfo for OnlineLevelListLayer
...
wasm-ld: error: too many errors emitted, stopping now (use
-error-limit=0 to see all errors)
shared:ERROR: '/home/caiiiycuk/sdk/emsdk/upstream/bin/wasm-ld
@/tmp/emscripten_ricuunpu.rsp' failed (1)
```

This project have a lot of undefined symbols, and it's ok. For native
I can successfully compile it with
```
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--unresolved-symbols=ignore-all")
```

And it works fine. For web I used fastcomp with -s
ERROR_ON_UNDEFINED_SYMBOLS=0 and it works fine.
But now, I can compile it, event with -s ERROR_ON_UNDEFINED_SYMBOLS=0

--
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%3DVHOofQU2iBi_kS1X3sypW-TrK9bOqTbGDrHp8Mc6VW%2B%2Bg%40mail.gmail.com.

Module.HEAPU8.slice vs Module.HEAPU8.subarray

2020-04-20 Thread Александр Гурьянов

Hi. I am doing worker backed for js-dos project, and now it pass all
tests that was made for default backend too. But I found inexplicable
behaviour. Worker process periodically sends updates for canvas. This
is code that I used:

```
Module.sendMessage = function (name, props) {
postMessage({
 name,
 props
});
};

...

#ifdef EMSCRIPTEN
EM_ASM(({
Module.frame_update_lines = [];
}));

for (uint32_t i = 0; i < count; ++i) {
uint32_t start = lines[i * 3];
uint32_t count = lines[i * 3 + 1];
uint32_t offset = lines[i * 3 + 2];
EM_ASM(({
Module.frame_update_lines.push({
start: $0,
heapu8: Module.HEAPU8.subarray($1, $1 + $2)
});
}), start, (char*) rgba + offset, sizeof(uint32_t) *
count * frameWidth);
}

EM_ASM(({
if (Module.frame_update_lines.length > 0) {
Module.sendMessage("ws-update-lines",
Module.frame_update_lines);
}
delete Module.frame_update_lines;
}));
#endif
```

So, message is array of rgba data that need to be drawn on canvas.
It's sort of dirty rects that need be updated.

When I run it results are terrible, both in Chrome and FF fps is near
11-12 FPS, when for non-worker version it is 55-60.

I tried a lot, and problem place as expected is sendMessage, lot of
time is spent here. BUT, by chance I tried to replace
Module.HEAPU8.subarray with Module.HEAPU8.slice and magic is happened.
With Module.HEAPU8.slice FPS for worker is 55-60 both in Chrome and
FF.

It's very good news for me, but I don't understand why I have this
performance boost. I thought that subarray should be faster then
slice, because as said it works on the same ArrayBuffer when slice is
copying it.

Why slice is faster then subarray?

-- 
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%3DVES80yNV-mePExaQGrY-TRWe-c2%3DY89TMEOrdOj%3DFq-9w%40mail.gmail.com.

Re: Module.then & await issue

2020-04-15 Thread Александр Гурьянов

Wow seems a hot topic:) I was so shocked and forget to google it) btw I
solved the problem like this
https://github.com/emscripten-core/emscripten/issues/5820#issuecomment-353605456

I think is worth to add it in documentation as workaround. Cause problem
still there from 2017.

Btw, it was fun to solve this problem without help, so mind blowing.

ср, 15 апр. 2020 г. в 23:57, Alon Zakai :

> May be related to https://github.com/emscripten-core/emscripten/pull/10697
> , see discussion and ongoing work there.
>
> On Wed, Apr 15, 2020 at 1:41 AM Александр Гурьянов 
> wrote:
>
>> Hi. I using `-s MODULARIZE=1` for my module, inside modern async/await
>> environment. I think that design of Module.then is not good. As said
>> Module.then is promise like function, but it returns it self at the
>> end. So this promise will never ends in await case. I spent a lot of
>> time to find why all browsers hangs with my code.
>>
>> Problem can be described as follow:
>> ```
>>  const Module = {}; // const Module = MyCode();
>>  Module.then = function(cb) { // declared in postamble.js
>>  cb(Module);
>>  return Module; // problem place
>>  };
>>  // How I want to use it
>>  const module = await new Promise((resolve) =>
>> Module.then(resolve));
>>  // here we have intialized module
>> ```
>>
>> If you paste this code in browser it will hang, because await is never
>> finished. Module.then will return promise-like object forever, so
>> browser will call `then` forever.
>>
>> My suggestion is to remove `return Module` at the end of `then`, or
>> rename `then` method to avoid name clashing with Promise. At least we
>> need to change documentation, and notice that problem exists.
>>
>> --
>> 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%3DVF8pmdYAdMQD5XpdyOmW%2B7-xZHtbpk7SyzG2uXm3fv0QQ%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/CAEX4NpTBDZkiKBB0wVJac6zbOdChyxJfYCWQTfJMsNqYFb21Ag%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTBDZkiKBB0wVJac6zbOdChyxJfYCWQTfJMsNqYFb21Ag%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/CAKOm%3DVGQCSQFP3Y6R6YRv81AMQdX%2B%2B5SLU77bBFfDUTp7hrUTA%40mail.gmail.com.

Module.then & await issue

2020-04-15 Thread Александр Гурьянов

Hi. I using `-s MODULARIZE=1` for my module, inside modern async/await
environment. I think that design of Module.then is not good. As said
Module.then is promise like function, but it returns it self at the
end. So this promise will never ends in await case. I spent a lot of
time to find why all browsers hangs with my code.

Problem can be described as follow:
```
 const Module = {}; // const Module = MyCode();
 Module.then = function(cb) { // declared in postamble.js
 cb(Module);
 return Module; // problem place
 };
 // How I want to use it
 const module = await new Promise((resolve) =>
Module.then(resolve));
 // here we have intialized module
```

If you paste this code in browser it will hang, because await is never
finished. Module.then will return promise-like object forever, so
browser will call `then` forever.

My suggestion is to remove `return Module` at the end of `then`, or
rename `then` method to avoid name clashing with Promise. At least we
need to change documentation, and notice that problem exists.

-- 
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%3DVF8pmdYAdMQD5XpdyOmW%2B7-xZHtbpk7SyzG2uXm3fv0QQ%40mail.gmail.com.

Re: Performance question

2020-01-17 Thread Александр Гурьянов

Alon, thanks for clarification.

Floh, very interesting!

> What are you using the asyncify changes for? Just for "slicing up" the 
> execution loop into frames, or also for other things?

I am using it just for slicing, to prevent browser freeze. I think
that emulation flow of js-dos is very similar:

- emulation and rendering happens inside infinite loop. Function of
this loop can call it self recursively, this is reason why it's not
easy to use emscripten frame callback instead of asyncify. So this
loop is paused by asyncify each 16ms (1 frame), and then resumes
execution with post message call. setTimeout is not so effective (min
interval is 4ms). This execution flow have simmilar performance that
emulation through emscripten frame callback.

- inside each frame js-dos tries to emulate N instructions. This N is
defined config or can be calculated automatically based on host
performance. Of course real count of emulated instructions is clamped
to fit 16 ms interval. In "auto" mode, js-dos used simple algorithm to
compare how many instructions is executed and increase of decrease N
dynamically.

- emulation updates SDL pixel buffer, that rendered to canvas. updates
is smart, only changed parts are updated (not sure that it's have
effect on emscripten sdl implementation, guess all canvas is updated
each time)

- sound emulation is made by sdl mixer callback, again it's memory
buffer that updated each frame, and pushed to emscripten sdl
implementations (which used AudioNode). this is not very good,
sometimes sound can lag.

- mouse and keyboard input are made through emscripten sdl impelementation.

Actually, I really want to drop SDL and replace it with something
ligther like your sokol abstraction. Not sure that it will give better
performance, but I think code will be much easier to understand. To do
this I plan to add messages abstraction, to have chance to switch to
workers/WASI env if needed.

I also have no idea how to increse performance more. Original dos box
have "dynamic core" that recompiles program to host CPU (x86), but it
used a lot of assembler code, that can't be compiled with WebAssembly,
and I don't understand it very well yet. Maybe there is some way to
make "dynamic core" for WebAssembly.

Also, do you think that future SMID support can increase performance
of emulator? All emulated cpu instructions are emulated one by one, so
looks SMID is also useless.




пт, 17 янв. 2020 г. в 00:35, Alon Zakai :
>
> About WASI, it doesn't have graphics/audio/mouse input etc. APIs yet, so it's 
> probably too early to port something like DOSBox? Unless you create a custom 
> embedding, but that would be a lot of work.
>
> About performance, unless iOS supports some form of native WASI VM in a 
> special way, I think you'd need to ship your own VM in your app. And I 
> believe they prevent JIT compilation in such a case, so it would be slower 
> compared to the browser (unless there is a working solution for AOT 
> compilation perhaps? I'm not aware of a robust one yet).
>
> On Wed, Jan 15, 2020 at 5:22 AM Александр Гурьянов  
> wrote:
>>
>> Hi guys. I working on next version of js-dos, and I have some ideas
>> where to go. I have couple questions to see which way is better.
>>
>> Currently, js-dos is a WebAssembly binary (+asyncify changes) that
>> does emulation in 16ms frames, and stops with emscripten_sleep for
>> processing user input. So typical work flow is:
>>
>> 16ms emulation|  | 16ms emulation | > input> | etc.
>>
>> Typically  is empty, and performance is limited by browser
>> performance, and browser scheduler that stops emulation with
>> emscripten_sleep.
>>
>> My first question is:
>> 1. "Can I have any performance boost if I move emulation core inside worker?"
>>
>> From my point of view it's not sens, because even in worker I should
>> stop emulations every 16ms to process messages and send updates to
>> page. Even If I do not account frames data (320x200 32bpp image), I
>> think performance will be same as in regular integration. Am I wrong?
>>
>> My second questing:
>> 2. "Is WASI perfromance is better than default WebView WebAsssembly
>> core?" (android/ios)
>>
>> One of my target is provide js-dos also on mobiles (android/ios) and I
>> think I can do it as is, or also I can do it with WASI. I think with
>> WASI clients can integrate js-dos in more ways, but what about
>> performance? Is it more preformant to use WASI instead of browser on
>> mobiles, or they are same?
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emai

Performance question

2020-01-15 Thread Александр Гурьянов

Hi guys. I working on next version of js-dos, and I have some ideas
where to go. I have couple questions to see which way is better.

Currently, js-dos is a WebAssembly binary (+asyncify changes) that
does emulation in 16ms frames, and stops with emscripten_sleep for
processing user input. So typical work flow is:

16ms emulation| | 16ms emulation | | etc.

Typically is empty, and performance is limited by browser
performance, and browser scheduler that stops emulation with
emscripten_sleep.

My first question is:
1. "Can I have any performance boost if I move emulation core inside worker?"

>From my point of view it's not sens, because even in worker I should
stop emulations every 16ms to process messages and send updates to
page. Even If I do not account frames data (320x200 32bpp image), I
think performance will be same as in regular integration. Am I wrong?

My second questing:
2. "Is WASI perfromance is better than default WebView WebAsssembly
core?" (android/ios)

One of my target is provide js-dos also on mobiles (android/ios) and I
think I can do it as is, or also I can do it with WASI. I think with
WASI clients can integrate js-dos in more ways, but what about
performance? Is it more preformant to use WASI instead of browser on
mobiles, or they are same?

--
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%3DVFLTVLCiF6QnQWe7tg666Q8ni1jXb3yUbAYcT38ED7Sow%40mail.gmail.com.

asyncify: increasing performance of JS-DOS on 25%

2019-12-18 Thread Александр Гурьянов

Hi. I used asyncifiy in default version of JS-DOS. However I found way
how to increase performance of  it on 25%. While dosbox is doing
emulation it uses one loop that works forever:

while (1) {
  static lastSleep = GetTicks();
  if (GetTicks() - lastSleep > 16) {
emscripten_sleep(0);
lastSleep = GetTicks();
  }
  PIC_RunQueue();
}

16 is a period of continuous emulation (== 60 FPS).

BUT, this implementation is not so effective as it can be.
Implementation of emscripten_sleep is based on setTimeout function. As
known minimum timeout delay is near ~4ms. So real execution flow is
follow:

| 16ms emulation | 4 ms idle | 16ms emulation | 4ms idle | 

4ms is 25%. I checked it in profilers of Chrome and Firefox, and as
expected I see idle self time  ~ 20-25%.

This 4m ms idle can be removed if we switch implementation from
setTimeout to postMessage. I tried it, and results are very good I see
improvement of Dhrystone 2 test on 60% (sic!),  and also profilers
reports about 1-2% idle time.

This is very good, but have some questions:

1. Is any chance to change implementation of emscripten_sleep to
post/recive message (in case when sleep time  <4ms)?
2. Even though it works, I don't like fact that I am checking
emulation period in c++, I want to do in this way:

while (1) {
  syncSleep();
  PIC_RunQueue();
}
//...
EM_JS(void, syncSleep, (), {
  if (Date.now() - Module.last_sync_time <= 16) {
  return;
  }

  return Asyncify.handleSleep(function(wakeUp) {
  // post/recive impl
  });
});

BUT, looks like it's not possible to not call Asyncify.handleSleep in
ASYNCIFY_IMPORT function. If I return 0/undfeinied from it execution
always terminate with message "Unreachable executed...". Is there are
any workaround for this?

3. Can you explain how asyncify handle recursion. Looks it not valid
case for asyncify. DOSBOX can run emulation loop inside emulation
loop, like this:

void loop() {
  while(1) {
syncSleep();
// <...>
printf("int21 handler\n");
loop();
  }
}

For this case browser hangs. I added console.log into syncSleep
function, and typical log is:
syncSleep (1593)
int21 handler called
// no any syncSleep anymore

I think maybe in case of recursion call stack is overwritten or
something similar, what do you think?
Cause I don't understand why log stops.

-- 
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%3DVFaCX1Y--QjVP1Rxqs3TTf7ETZ-%2B%3DmHqZ_UyRDVbkqJ6g%40mail.gmail.com.

Re: ASM.JS status for upstream backend

2019-11-17 Thread Александр Гурьянов

> Hopefully that "out of execution memory" issue can and will be addressed in 
> safari.  Do you know why you might be seeing this?

This happens when wasm binary is bigger then some threshold, like
>5Mb. Depends on iPhone version. This never happens with dosbox,
because it's size  <3Mb, but regularly with some other projects (for
example any Unity project).

> Are you instantiating a lot of module?

No, only one.

--
Found that my measuring system is incorrect. I will fix it asap, and
return with results soon.

сб, 16 нояб. 2019 г. в 00:49, 'Sam Clegg' via emscripten-discuss
:
>
> On Thu, Nov 14, 2019 at 6:58 PM Александр Гурьянов  
> wrote:
> >
> > > i.e. is asm.js really faster than wasm2js on that platforms where you 
> > > *need* to run JS?
> > If browser didn't support asm.js then plain js have same performance
> > level. But for sure, if browser support asm.js, then asm.js have much
> > much better performance.
> > Regarding to you question, I understand your point, but as js-dos
> > maintainer I should provide must optimized version for each
> > environment (e.g. wasm, asm.js).
> >
> > Form real use case, I only used asm.js for fallbacking ios safari,
> > because sometimes it can't start wasm version with "out of execution
> > memory" error (not js-dos case).
> >
>
> And do you see a noticeable difference in performance between plain JS
> and asm.js on iOS safari?   i.e. do iOS safari continue to support and
> optimize "use asm"?
>
> Hopefully that "out of execution memory" issue can and will be
> addressed in safari.  Do you know why you might be seeing this?  Do
> you have a lot of code?  Are you instantiating a lot of module?
>
> > memory
> > Anyway, my feedback is that wasm+asynicify version is most performant
> > and stable version, that should be used most time.
> > I don't know why but it even more faster then wasm no async version.
>
> That seems amazing/strange.  How are you measuring performance?  I
> wouldn't be surprised if you saw increased responsiveness.
>
>
> >
> > пт, 15 нояб. 2019 г. в 08:44, 'Sam Clegg' via emscripten-discuss
> > :
> > >
> > > On Sat, Nov 2, 2019 at 10:22 PM Александр Гурьянов  
> > > wrote:
> > > >
> > > > I totaly agree with this approach. I used js just to support Internet
> > > > Explorer, so it's not very important. I will provide asm.js for nosync
> > > > and emterp version, and play js for asyncify even if it's slower.
> > > >
> > >
> > > Are there versions of IE that have asm.js acceleration but no wasm
> > > support?  i.e. is asm.js really faster than wasm2js on that platforms
> > > where you *need* to run JS?
> > >
> > >
> > > > вс, 3 нояб. 2019 г. в 00:10, Alon Zakai :
> > > > >
> > > > > I don't have plans to work on asm.js for the upstream backend. (If 
> > > > > someone else is, though, I'm not opposed to patches.)
> > > > >
> > > > > The key issues are that almost all browsers have wasm anyhow so the 
> > > > > JS build matters less and less, and that an increasing number of wasm 
> > > > > features can't work in asm.js anyhow. So asm.js would only help a 
> > > > > small and decreasing number of old browsers, and in a decreasing 
> > > > > subset of wasm.
> > > > >
> > > > > Where do you currently use the JS version of js-dos?
> > > > >
> > > > > You can still use fastcomp, but we've removed Asyncify there as 
> > > > > Emterpreter has worked there for a long time, and upstream Asyncify 
> > > > > is now stable as well. But an older fastcomp version (1.38.40 or 
> > > > > older) still has it.
> > > > >
> > > > > - Alon
> > > > >
> > > > >
> > > > > On Sat, Nov 2, 2019 at 8:52 AM Александр Гурьянов 
> > > > >  wrote:
> > > > >>
> > > > >> Hi, from docs:
> > > > >> ```
> > > > >> WASM=0 behaves differently in the two backends. In fastcomp we emit
> > > > >> asm.js, while in upstream we emit JS (since not all wasm constructs
> > > > >> can be expressed in asm.js). Also, the JS support implements the same
> > > > >> external WebAssembly.* API, so in particular startup will be async
> > > > >> just like wasm by default, and you can control that with
> > > > >> WASM_ASYNC_COMPILATION

Re: ASM.JS status for upstream backend

2019-11-14 Thread Александр Гурьянов

> i.e. is asm.js really faster than wasm2js on that platforms where you *need* 
> to run JS?
If browser didn't support asm.js then plain js have same performance
level. But for sure, if browser support asm.js, then asm.js have much
much better performance.
Regarding to you question, I understand your point, but as js-dos
maintainer I should provide must optimized version for each
environment (e.g. wasm, asm.js).

Form real use case, I only used asm.js for fallbacking ios safari,
because sometimes it can't start wasm version with "out of execution
memory" error (not js-dos case).

Anyway, my feedback is that wasm+asynicify version is most performant
and stable version, that should be used most time.
I don't know why but it even more faster then wasm no async version.

пт, 15 нояб. 2019 г. в 08:44, 'Sam Clegg' via emscripten-discuss
:
>
> On Sat, Nov 2, 2019 at 10:22 PM Александр Гурьянов  
> wrote:
> >
> > I totaly agree with this approach. I used js just to support Internet
> > Explorer, so it's not very important. I will provide asm.js for nosync
> > and emterp version, and play js for asyncify even if it's slower.
> >
>
> Are there versions of IE that have asm.js acceleration but no wasm
> support?  i.e. is asm.js really faster than wasm2js on that platforms
> where you *need* to run JS?
>
>
> > вс, 3 нояб. 2019 г. в 00:10, Alon Zakai :
> > >
> > > I don't have plans to work on asm.js for the upstream backend. (If 
> > > someone else is, though, I'm not opposed to patches.)
> > >
> > > The key issues are that almost all browsers have wasm anyhow so the JS 
> > > build matters less and less, and that an increasing number of wasm 
> > > features can't work in asm.js anyhow. So asm.js would only help a small 
> > > and decreasing number of old browsers, and in a decreasing subset of wasm.
> > >
> > > Where do you currently use the JS version of js-dos?
> > >
> > > You can still use fastcomp, but we've removed Asyncify there as 
> > > Emterpreter has worked there for a long time, and upstream Asyncify is 
> > > now stable as well. But an older fastcomp version (1.38.40 or older) 
> > > still has it.
> > >
> > > - Alon
> > >
> > >
> > > On Sat, Nov 2, 2019 at 8:52 AM Александр Гурьянов  
> > > wrote:
> > >>
> > >> Hi, from docs:
> > >> ```
> > >> WASM=0 behaves differently in the two backends. In fastcomp we emit
> > >> asm.js, while in upstream we emit JS (since not all wasm constructs
> > >> can be expressed in asm.js). Also, the JS support implements the same
> > >> external WebAssembly.* API, so in particular startup will be async
> > >> just like wasm by default, and you can control that with
> > >> WASM_ASYNC_COMPILATION (even though WASM=0).
> > >> ```
> > >> Do you have plan to add support for ASM.JS in non-fastcomp backend? I
> > >> received feedback that js version of js-dos is much slower then asm.js
> > >> version of it.
> > >>
> > >> I have 3 version of js-dos now:
> > >> * asyncify
> > >> * emterp
> > >> * nosync
> > >>
> > >> So for nosync & emterp version I can compile ASM.JS with fastcomp. Can
> > >> I also compile asyncify version with fastcomp to asm.js?
> > >>
> > >> --
> > >> 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%3DVGGbZvypXnN2HUDSXi%2Bi2j_fhK2SSGuG2xpE1u%2Bud_c8g%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/CAEX4NpTkJX4jCF%2Bi_0j6Bc-vg3T55XvZcaM5oKFiUxK3dcX3HQ%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

Re: ASM.JS status for upstream backend

2019-11-02 Thread Александр Гурьянов

I totaly agree with this approach. I used js just to support Internet
Explorer, so it's not very important. I will provide asm.js for nosync
and emterp version, and play js for asyncify even if it's slower.

вс, 3 нояб. 2019 г. в 00:10, Alon Zakai :
>
> I don't have plans to work on asm.js for the upstream backend. (If someone 
> else is, though, I'm not opposed to patches.)
>
> The key issues are that almost all browsers have wasm anyhow so the JS build 
> matters less and less, and that an increasing number of wasm features can't 
> work in asm.js anyhow. So asm.js would only help a small and decreasing 
> number of old browsers, and in a decreasing subset of wasm.
>
> Where do you currently use the JS version of js-dos?
>
> You can still use fastcomp, but we've removed Asyncify there as Emterpreter 
> has worked there for a long time, and upstream Asyncify is now stable as 
> well. But an older fastcomp version (1.38.40 or older) still has it.
>
> - Alon
>
>
> On Sat, Nov 2, 2019 at 8:52 AM Александр Гурьянов  wrote:
>>
>> Hi, from docs:
>> ```
>> WASM=0 behaves differently in the two backends. In fastcomp we emit
>> asm.js, while in upstream we emit JS (since not all wasm constructs
>> can be expressed in asm.js). Also, the JS support implements the same
>> external WebAssembly.* API, so in particular startup will be async
>> just like wasm by default, and you can control that with
>> WASM_ASYNC_COMPILATION (even though WASM=0).
>> ```
>> Do you have plan to add support for ASM.JS in non-fastcomp backend? I
>> received feedback that js version of js-dos is much slower then asm.js
>> version of it.
>>
>> I have 3 version of js-dos now:
>> * asyncify
>> * emterp
>> * nosync
>>
>> So for nosync & emterp version I can compile ASM.JS with fastcomp. Can
>> I also compile asyncify version with fastcomp to asm.js?
>>
>> --
>> 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%3DVGGbZvypXnN2HUDSXi%2Bi2j_fhK2SSGuG2xpE1u%2Bud_c8g%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/CAEX4NpTkJX4jCF%2Bi_0j6Bc-vg3T55XvZcaM5oKFiUxK3dcX3HQ%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%3DVGhSreNwV0BecTQcUGfwUQ6i-t%3D-JWJPDpsN-C9KtvksQ%40mail.gmail.com.

ASM.JS status for upstream backend

2019-11-02 Thread Александр Гурьянов

Hi, from docs:
```
WASM=0 behaves differently in the two backends. In fastcomp we emit
asm.js, while in upstream we emit JS (since not all wasm constructs
can be expressed in asm.js). Also, the JS support implements the same
external WebAssembly.* API, so in particular startup will be async
just like wasm by default, and you can control that with
WASM_ASYNC_COMPILATION (even though WASM=0).
```
Do you have plan to add support for ASM.JS in non-fastcomp backend? I
received feedback that js version of js-dos is much slower then asm.js
version of it.

I have 3 version of js-dos now:
* asyncify
* emterp
* nosync

So for nosync & emterp version I can compile ASM.JS with fastcomp. Can
I also compile asyncify version with fastcomp to asm.js?

-- 
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%3DVGGbZvypXnN2HUDSXi%2Bi2j_fhK2SSGuG2xpE1u%2Bud_c8g%40mail.gmail.com.

Re: undefined symbol: __wasi_fd_* on latest-fastcomp

2019-10-29 Thread Александр Гурьянов

Yeah --clear-cache helped me. Thanks!

ср, 30 окт. 2019 г. в 02:31, Alon Zakai :
>
> Is it possible there is an object file or library built with an older version 
> of the compiler?
>
> emcc --clear-cache to rebuild system libs may also help, if the upgrade 
> didn't rebuild them.
>
>
> On Tue, Oct 29, 2019 at 11:05 AM caiiiycuk  wrote:
>>
>> Hi! Recently I updated dosbox to compile both on fastcomp+emterpreter and 
>> upstream+asyncify. upstream+asyncify version is default now, but I want to 
>> have option to use fastcomp+empterpreter. Now when I try to build fastcomp 
>> version I have this errors:
>> warning: undefined symbol: __wasi_fd_close
>> warning: undefined symbol: __wasi_fd_fdstat_get
>> warning: undefined symbol: __wasi_fd_read
>> warning: undefined symbol: __wasi_fd_seek
>> warning: undefined symbol: __wasi_fd_write
>>
>> And typical stack of error:
>> abort js-dos.js line 1 > eval:8
>> ___wasi_fd_write js-dos.js line 1 > eval:8
>> ___stdio_write js-dos.js line 1 > WebAssembly.compile:1029969
>> ___fwritex js-dos.js line 1 > WebAssembly.compile:706919
>> _fwrite js-dos.js line 1 > WebAssembly.compile:75144
>> _extract_zip js-dos.js line 1 > WebAssembly.compile:992635
>> _extract_zip js-dos.js line 1 > eval:8
>> success js-dos-fs.ts:76
>> onReadyStateChange js-dos-xhr.ts:102
>> onreadystatechange js-dos-xhr.ts:80
>>
>> where extract_zip is function to extract zip files based on C file api 
>> (fopen, fclose, fread).
>>
>> I missed something?
>> 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/fce49bf1-21c9-4d26-a030-9e2f813890eb%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/CAEX4NpTO%2BF9w6eSMaEyvbbkwrKaQbxsN82GmxKjU7FV14mME4w%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%3DVGqFvNkL0qy7RFOG4jH8OxWtfNJozi%3DNTTO3feT38q-tA%40mail.gmail.com.

Re: Pointer lock api does not work (html5.h)

2019-10-21 Thread Александр Гурьянов

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

пн, 21 окт. 2019 г. в 09:35, Александр Гурьянов :
>
> Hi. Inside js-dos project I have long living bug about mouse locking
> that didn't work. Yesterday I tried to fix it again, and I faced
> problem that emscripten pointer lock api does not work as expected.
>
> I  used api in this way:
>
> 1) set callbacks:
> // register no-op callbacks for defered events
> emscripten_set_mousedown_callback("#canvas", NULL, false, [](int
> eventType, const EmscriptenMouseEvent *mouseEvent, void *userData) {
> return 0;
> });
>
> auto pointerLockChangeSet =
> emscripten_set_pointerlockchange_callback("#canvas", NULL, false,
> [](int eventType, const EmscriptenPointerlockChangeEvent
> *pointerlockChangeEvent, void *userData) -> EM_BOOL {
> printf("Received pointer lock change event\n");
> return true;
> }) == EMSCRIPTEN_RESULT_SUCCESS;
> printf("Pointerlock callback set\n");
>
> 2) ask for current pointer lock state:
> EmscriptenPointerlockChangeEvent lastChangeEvent;
> auto haveLockInfo =
> emscripten_get_pointerlock_status() ==
> EMSCRIPTEN_RESULT_SUCCESS;
> // use lastChangeEvent;
>
> 3) request for lock:
> auto lockRequested = emscripten_request_pointerlock("#canvas",
> true) == EMSCRIPTEN_RESULT_DEFERRED;
>
> Step 3) always return EMSCRIPTEN_RESULT_DEFERRED as expected and then
> browser lock mouse
> Step 2) always works correct,  every time when I asked for last state
> of pointer lock then I recieve correct value (true when locked and
> false when not).
> In Step 1) pointerlockchange callback is set fine (I received
> EMSCRIPTEN_RESULT_SUCCESS), but callback it self is never called. So I
> need to ask about current status (step 2) periodically to get changes.
>
> --
> emcc (Emscripten gcc/clang-like replacement) 1.39.0 (commit
> e047fe4c1ecfae6ba471ca43f2f630b79516706b)
> https://github.com/caiiiycuk/js-dos/issues/63

-- 
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%3DVGSqHzLYv1TObys-qSSs5V2oE4KrgyaCcAb4TNOZ5hdTg%40mail.gmail.com.

Pointer lock api does not work (html5.h)

2019-10-20 Thread Александр Гурьянов

Hi. Inside js-dos project I have long living bug about mouse locking
that didn't work. Yesterday I tried to fix it again, and I faced
problem that emscripten pointer lock api does not work as expected.

I  used api in this way:

1) set callbacks:
// register no-op callbacks for defered events
emscripten_set_mousedown_callback("#canvas", NULL, false, [](int
eventType, const EmscriptenMouseEvent *mouseEvent, void *userData) {
return 0;
});

auto pointerLockChangeSet =
emscripten_set_pointerlockchange_callback("#canvas", NULL, false,
[](int eventType, const EmscriptenPointerlockChangeEvent
*pointerlockChangeEvent, void *userData) -> EM_BOOL {
printf("Received pointer lock change event\n");
return true;
}) == EMSCRIPTEN_RESULT_SUCCESS;
printf("Pointerlock callback set\n");

2) ask for current pointer lock state:
EmscriptenPointerlockChangeEvent lastChangeEvent;
auto haveLockInfo =
emscripten_get_pointerlock_status() ==
EMSCRIPTEN_RESULT_SUCCESS;
// use lastChangeEvent;

3) request for lock:
auto lockRequested = emscripten_request_pointerlock("#canvas",
true) == EMSCRIPTEN_RESULT_DEFERRED;

Step 3) always return EMSCRIPTEN_RESULT_DEFERRED as expected and then
browser lock mouse
Step 2) always works correct,  every time when I asked for last state
of pointer lock then I recieve correct value (true when locked and
false when not).
In Step 1) pointerlockchange callback is set fine (I received
EMSCRIPTEN_RESULT_SUCCESS), but callback it self is never called. So I
need to ask about current status (step 2) periodically to get changes.

--
emcc (Emscripten gcc/clang-like replacement) 1.39.0 (commit
e047fe4c1ecfae6ba471ca43f2f630b79516706b)
https://github.com/caiiiycuk/js-dos/issues/63

-- 
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%3DVFactEBzECFkWPy-YM%3Dv6yG1j9sTMSJFia65rANpCDwZw%40mail.gmail.com.

Re: Safari mobile support?

2019-10-12 Thread Александр Гурьянов

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

сб, 12 окт. 2019 г. в 15:32, Beuc :
>
> Hi,
>
> It seems that Safari/Safari mobile is supporting WebAssembly but with
> limitations, which make it harder to tell the user whether they can play
> the game or not, so they get cryptic errors instead.
>
> I eventually got a few proper traces from a Safari Mobile user (I don't
> own apple hardware):
>
> For https://renpy.beuc.net/play/?game=the_question.zip:
>   wasm instantiation failed!
>   Error: Out of executable memory in function at index 15855
> (even with freeing memory / restarting the browser)
>
> For the lighter https://www.beuc.net/python-emscripten/demo/
>   exception thrown: RangeError: Maximum call stack size exceeded.,
>   .wasm-function[705]@[wasm code]
>   ... [76 other wasm-function's]
>   .wasm-function[5481]@[wasm code]
>   wasm-stub@[wasm code]
>   Gb@[native code]
>   https://www.beuc.net/python-emscripten/demo/index.js:1:182840
>   callMain@https://www.beuc.net/python-emscripten/demo/index.js:1:187051
>   doRun@https://www.beuc.net/python-emscripten/demo/index.js:1:187638
>   https://www.beuc.net/python-emscripten/demo/index.js:1:187790
>
> This is the only browser where this happens.
>
> Do you have similar issues with Safari?
> Is there a way to properly detect such limited WebAssembly environment?
> (I wouldn't want to blindly blacklist Safari)
>
> Cheers!
> Beuc
>
> --
> 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/615b9d0a-ccfa-ae67-5902-1e0b68c4c46c%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/CAKOm%3DVFT2MRxx9q7av_GQ4UXu8Mf%2B7R7r%2BfkJBS%3DOjTo05KdBg%40mail.gmail.com.

Oz and symbols

2019-07-30 Thread Александр Гурьянов

HI. I used wasm-opt manually to optimize wasm binary. On last step I
used Oz to finalize optimizations. My problem is that after Oz
function indexes is changed and I can't get symbols map to restore
function names. How I can map new function indexes to old one (from
symbols file).

In other words:
1) I have bin.wasm from emscripten with symbols file. E.g. for one function:
export __GLOBAL__sub_I_Runtime_BaseClasses_0_cpp (func $3425) - 3809

2) I do some buisness releated optimizations (with wasm-opt) that
didn't change function indexes, after this, I still have
export __GLOBAL__sub_I_Runtime_BaseClasses_0_cpp (func $3425) - 3809

3) Next I finalize build with wasm-opt -Oz, after it indexes was
changed (I think because of dead code elimination), and I have
export "__GLOBAL__sub_I_Runtime_BaseClasses_0_cpp" (func $1637) - 1997

I need some flag for Oz, that told generates mapping for new indexes,
like $1637: $3425 then I can restore original function names. I think
some flag or option to do it should be already there, because
emscripten do this in some way. What is the best way to build this
mappings?

-- 
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%3DVGv21Ffn%2Bxc4Fs59t9pBpmMqfa6p2F%2B0p1CmF-O2JjvOQ%40mail.gmail.com.

Re: -s ASYNCIFY, dosbox

2019-07-23 Thread Александр Гурьянов

Yes this links will be live as long as needed.

> Otherwise I looked into the code, and most of the itime is spent inside a 
> single huge function that asyncify has modified. Perhaps the main interpreter 
> loop? It's hard to see more optimization opportunities there.
Yes I think you right, it's dosbox main loop (__ZL11Normal_Loopv).

> Btw, did you use the whitelist or blacklist there - which would be better?
I used white list
https://github.com/caiiiycuk/js-dos/blob/6.22/js-dos-cpp/emterpretify.txt

ср, 24 июл. 2019 г. в 01:26, Alon Zakai :
>
> Thanks, great testcase!
>
> Are those links going to remain up? I'll file a chromium bug if so, as I also 
> see the chrome performance on asyncify as slower than I'd expect.
>
> Otherwise I looked into the code, and most of the itime is spent inside a 
> single huge function that asyncify has modified. Perhaps the main interpreter 
> loop? It's hard to see more optimization opportunities there. I think that 
> means we need a whitelist like in emterpreter. Btw, did you use the whitelist 
> or blacklist there - which would be better?
>
> - Alon
>
>
> On Mon, Jul 22, 2019 at 10:03 PM Александр Гурьянов  
> wrote:
>>
>> wdosbox.wasm.js - is wasm binary
>> wdosbox.js.symbols - symbols
>>
>> вт, 23 июл. 2019 г. в 12:03, Александр Гурьянов :
>> >
>> > I am sorry guys, my estimation of sizes/preformance was wrong.
>> >
>> > Ubuntu 19.04 / Chrome 72.0.3626.121
>> >
>> > O3:
>> > DEFAULT  2.0Mb 60 FPS   / 22 FPS
>> > EMTERPRETIFY  2.2Mb 60 FPS   / 40 - 50 FPS
>> > ASYNCIFY3.0Mb 44-55 FPS  / 11 - 44 FPS
>> >
>> > Oz:
>> > DEFAULT  1.8Mb 55-60 FPS  / 22 FPS
>> > EMTERPRETIFY  2.1Mb 55-60 FPS  / 22 - 47 FPS
>> > ASYNCIFY2.8Mb 50-60 FPS  / 13 - 35 FPS
>> >
>> > NOTES:
>> > - First fps number is for single dosbox instance on page 
>> > (index.html?game=0)
>> > - Second fps number is for 9 dosbox instances on page (index.html)
>> > - Default version used emscripten_set_main_loop, I think low fps for 9
>> > instances is because stats.js can't calculate it correctly, cause
>> > everything work very smooth in Default mode.
>> > - In FF every version works near 60 FPS, but game expirence is not
>> > same (need to find better metric then FPS)
>> >
>> > From my point of view, ASYNCIFY is slower on ~10 FPS I tried to do
>> > basic profiling but didn't find any spikes. I think this slowness is
>> > related to bigger file size. Hope, option like EMTERPRETIFY_WHITELIST
>> > can solve this problem.
>> > ASYNCIFY have dramatic slow down (against emterpreter {in chrome?})
>> > when you run multiple instance of same app on single page (maybe there
>> > is some synchronization or inside chrome).
>> >
>> > I swithced to emterpreter, becaue for now it's better. You can try
>> > this test here:
>> > ASYNCIFY:
>> > http://js-dos.com/6.22/64k/index-upstream.html?game=0 (1 game)
>> > http://js-dos.com/6.22/64k/index-upstream.html
>> > EMTERPRETIFY:
>> > http://js-dos.com/6.22/64k/index-fastcomp.html?game=0 (1 game)
>> > http://js-dos.com/6.22/64k/index-fastcomp.html
>> >
>> > Also you can download binaries here:
>> > https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-fastcomp
>> > https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-upstream
>> >
>> > Where
>> >
>> > пн, 22 июл. 2019 г. в 18:15, Александр Гурьянов :
>> > >
>> > > Even digger works very poor here http://js-dos.com/ (in chrome). I
>> > > just changed emscripten_sleep_with_yield with emscripten_sleep and
>> > > that's all. Don't know why Chrome goes crazy.
>> > >
>> > > пн, 22 июл. 2019 г. в 18:04, Александр Гурьянов :
>> > > >
>> > > > Just updated js-dos to latest upsteram, now you can compare 
>> > > > performance:
>> > > > http://js-dos.com/6.22/64k/index.html - for Asyncify
>> > > > http://js-dos.com/6.22/64k/index-fastcomp.html - for Emterpreter
>> > > >
>> > > > In FF performance is same, but in Chrome asyncify version looks
>> > > > significant slowly. Please give a try.
>> > > >
>> > > > пт, 19 июл. 2019 г. в 20:43, Alon Zakai :
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, Jul 18, 2019 at 11:52 PM Александ

Re: -s ASYNCIFY, dosbox

wdosbox.wasm.js - is wasm binary
wdosbox.js.symbols - symbols

вт, 23 июл. 2019 г. в 12:03, Александр Гурьянов :
>
> I am sorry guys, my estimation of sizes/preformance was wrong.
>
> Ubuntu 19.04 / Chrome 72.0.3626.121
>
> O3:
> DEFAULT  2.0Mb 60 FPS   / 22 FPS
> EMTERPRETIFY  2.2Mb 60 FPS   / 40 - 50 FPS
> ASYNCIFY3.0Mb 44-55 FPS  / 11 - 44 FPS
>
> Oz:
> DEFAULT  1.8Mb 55-60 FPS  / 22 FPS
> EMTERPRETIFY  2.1Mb 55-60 FPS  / 22 - 47 FPS
> ASYNCIFY2.8Mb 50-60 FPS  / 13 - 35 FPS
>
> NOTES:
> - First fps number is for single dosbox instance on page (index.html?game=0)
> - Second fps number is for 9 dosbox instances on page (index.html)
> - Default version used emscripten_set_main_loop, I think low fps for 9
> instances is because stats.js can't calculate it correctly, cause
> everything work very smooth in Default mode.
> - In FF every version works near 60 FPS, but game expirence is not
> same (need to find better metric then FPS)
>
> From my point of view, ASYNCIFY is slower on ~10 FPS I tried to do
> basic profiling but didn't find any spikes. I think this slowness is
> related to bigger file size. Hope, option like EMTERPRETIFY_WHITELIST
> can solve this problem.
> ASYNCIFY have dramatic slow down (against emterpreter {in chrome?})
> when you run multiple instance of same app on single page (maybe there
> is some synchronization or inside chrome).
>
> I swithced to emterpreter, becaue for now it's better. You can try
> this test here:
> ASYNCIFY:
> http://js-dos.com/6.22/64k/index-upstream.html?game=0 (1 game)
> http://js-dos.com/6.22/64k/index-upstream.html
> EMTERPRETIFY:
> http://js-dos.com/6.22/64k/index-fastcomp.html?game=0 (1 game)
> http://js-dos.com/6.22/64k/index-fastcomp.html
>
> Also you can download binaries here:
> https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-fastcomp
> https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-upstream
>
> Where
>
> пн, 22 июл. 2019 г. в 18:15, Александр Гурьянов :
> >
> > Even digger works very poor here http://js-dos.com/ (in chrome). I
> > just changed emscripten_sleep_with_yield with emscripten_sleep and
> > that's all. Don't know why Chrome goes crazy.
> >
> > пн, 22 июл. 2019 г. в 18:04, Александр Гурьянов :
> > >
> > > Just updated js-dos to latest upsteram, now you can compare performance:
> > > http://js-dos.com/6.22/64k/index.html - for Asyncify
> > > http://js-dos.com/6.22/64k/index-fastcomp.html - for Emterpreter
> > >
> > > In FF performance is same, but in Chrome asyncify version looks
> > > significant slowly. Please give a try.
> > >
> > > пт, 19 июл. 2019 г. в 20:43, Alon Zakai :
> > > >
> > > >
> > > >
> > > > On Thu, Jul 18, 2019 at 11:52 PM Александр Гурьянов 
> > > >  wrote:
> > > >>
> > > >> Works like a charm! Even file size is smaller on 300Kb (2.8Mb instead
> > > >> of 3.1Mb)
> > > >
> > > >
> > > > Great!
> > > >
> > > >> - Is Asyncify have simmilar conecpt of normal state like emterpreter
> > > >> (EmterpreterAsync.state === 0)?
> > > >
> > > >
> > > > Yes, there is Asyncify.state, and 0 means "normal" there too.
> > > >
> > > >> - Is EMTERPRETIFY_WHITELIST (list of functions that neet to be
> > > >> emterpret) can be useful for Asyncify? I tried -s
> > > >> ASYNCIFY_IGNORE_INDIRECT output size is 1,8M, but didn't work
> > > >>
> > > >
> > > > We are considering that, see
> > > >
> > > > https://github.com/WebAssembly/binaryen/issues/2218
> > > >
> > > > But the overhead tends to be fairly small, and I hope we can optimize 
> > > > it more without adding manual lists.
> > > >
> > > > Sounds like you see a 55% code size increase - I'm also curious what is 
> > > > the slowdown, if you can measure that?
> > > >
> > > > - Alon
> > > >
> > > >> чт, 18 июл. 2019 г. в 23:28, Alon Zakai :
> > > >> >
> > > >> > You may need to do "emsdk update" instead of "emsdk update-tags", 
> > > >> > depending on if you get the emsdk using git or not.
> > > >> >
> > > >> > Latest version should be 1.38.39.
> > > >> >
> > > >> > About those errors - yes, the APIs for old

Re: -s ASYNCIFY, dosbox

I am sorry guys, my estimation of sizes/preformance was wrong.

Ubuntu 19.04 / Chrome 72.0.3626.121

O3:
DEFAULT  2.0Mb 60 FPS   / 22 FPS
EMTERPRETIFY  2.2Mb 60 FPS   / 40 - 50 FPS
ASYNCIFY3.0Mb 44-55 FPS  / 11 - 44 FPS

Oz:
DEFAULT  1.8Mb 55-60 FPS  / 22 FPS
EMTERPRETIFY  2.1Mb 55-60 FPS  / 22 - 47 FPS
ASYNCIFY2.8Mb 50-60 FPS  / 13 - 35 FPS

NOTES:
- First fps number is for single dosbox instance on page (index.html?game=0)
- Second fps number is for 9 dosbox instances on page (index.html)
- Default version used emscripten_set_main_loop, I think low fps for 9
instances is because stats.js can't calculate it correctly, cause
everything work very smooth in Default mode.
- In FF every version works near 60 FPS, but game expirence is not
same (need to find better metric then FPS)

>From my point of view, ASYNCIFY is slower on ~10 FPS I tried to do
basic profiling but didn't find any spikes. I think this slowness is
related to bigger file size. Hope, option like EMTERPRETIFY_WHITELIST
can solve this problem.
ASYNCIFY have dramatic slow down (against emterpreter {in chrome?})
when you run multiple instance of same app on single page (maybe there
is some synchronization or inside chrome).

I swithced to emterpreter, becaue for now it's better. You can try
this test here:
ASYNCIFY:
http://js-dos.com/6.22/64k/index-upstream.html?game=0 (1 game)
http://js-dos.com/6.22/64k/index-upstream.html
EMTERPRETIFY:
http://js-dos.com/6.22/64k/index-fastcomp.html?game=0 (1 game)
http://js-dos.com/6.22/64k/index-fastcomp.html

Also you can download binaries here:
https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-fastcomp
https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-upstream

Where

пн, 22 июл. 2019 г. в 18:15, Александр Гурьянов :
>
> Even digger works very poor here http://js-dos.com/ (in chrome). I
> just changed emscripten_sleep_with_yield with emscripten_sleep and
> that's all. Don't know why Chrome goes crazy.
>
> пн, 22 июл. 2019 г. в 18:04, Александр Гурьянов :
> >
> > Just updated js-dos to latest upsteram, now you can compare performance:
> > http://js-dos.com/6.22/64k/index.html - for Asyncify
> > http://js-dos.com/6.22/64k/index-fastcomp.html - for Emterpreter
> >
> > In FF performance is same, but in Chrome asyncify version looks
> > significant slowly. Please give a try.
> >
> > пт, 19 июл. 2019 г. в 20:43, Alon Zakai :
> > >
> > >
> > >
> > > On Thu, Jul 18, 2019 at 11:52 PM Александр Гурьянов  
> > > wrote:
> > >>
> > >> Works like a charm! Even file size is smaller on 300Kb (2.8Mb instead
> > >> of 3.1Mb)
> > >
> > >
> > > Great!
> > >
> > >> - Is Asyncify have simmilar conecpt of normal state like emterpreter
> > >> (EmterpreterAsync.state === 0)?
> > >
> > >
> > > Yes, there is Asyncify.state, and 0 means "normal" there too.
> > >
> > >> - Is EMTERPRETIFY_WHITELIST (list of functions that neet to be
> > >> emterpret) can be useful for Asyncify? I tried -s
> > >> ASYNCIFY_IGNORE_INDIRECT output size is 1,8M, but didn't work
> > >>
> > >
> > > We are considering that, see
> > >
> > > https://github.com/WebAssembly/binaryen/issues/2218
> > >
> > > But the overhead tends to be fairly small, and I hope we can optimize it 
> > > more without adding manual lists.
> > >
> > > Sounds like you see a 55% code size increase - I'm also curious what is 
> > > the slowdown, if you can measure that?
> > >
> > > - Alon
> > >
> > >> чт, 18 июл. 2019 г. в 23:28, Alon Zakai :
> > >> >
> > >> > You may need to do "emsdk update" instead of "emsdk update-tags", 
> > >> > depending on if you get the emsdk using git or not.
> > >> >
> > >> > Latest version should be 1.38.39.
> > >> >
> > >> > About those errors - yes, the APIs for old Asyncify, Emterpreter, and 
> > >> > new Asyncify are not identical. Emterpreter has the "yield" concept, 
> > >> > which is not needed in Asyncify (so as you said, just call 
> > >> > emscripten_sleep instead of _with_yield). Module.setAsync is an 
> > >> > internal API of old Asyncify - if you have custom JS code using it, 
> > >> > you need to update it to the new Asyncify's API (see notes on 
> > >> > handleSleep in the blogpost: 
> > >> > https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html ).
> >

Re: -s ASYNCIFY, dosbox

Even digger works very poor here http://js-dos.com/ (in chrome). I
just changed emscripten_sleep_with_yield with emscripten_sleep and
that's all. Don't know why Chrome goes crazy.

пн, 22 июл. 2019 г. в 18:04, Александр Гурьянов :
>
> Just updated js-dos to latest upsteram, now you can compare performance:
> http://js-dos.com/6.22/64k/index.html - for Asyncify
> http://js-dos.com/6.22/64k/index-fastcomp.html - for Emterpreter
>
> In FF performance is same, but in Chrome asyncify version looks
> significant slowly. Please give a try.
>
> пт, 19 июл. 2019 г. в 20:43, Alon Zakai :
> >
> >
> >
> > On Thu, Jul 18, 2019 at 11:52 PM Александр Гурьянов  
> > wrote:
> >>
> >> Works like a charm! Even file size is smaller on 300Kb (2.8Mb instead
> >> of 3.1Mb)
> >
> >
> > Great!
> >
> >> - Is Asyncify have simmilar conecpt of normal state like emterpreter
> >> (EmterpreterAsync.state === 0)?
> >
> >
> > Yes, there is Asyncify.state, and 0 means "normal" there too.
> >
> >> - Is EMTERPRETIFY_WHITELIST (list of functions that neet to be
> >> emterpret) can be useful for Asyncify? I tried -s
> >> ASYNCIFY_IGNORE_INDIRECT output size is 1,8M, but didn't work
> >>
> >
> > We are considering that, see
> >
> > https://github.com/WebAssembly/binaryen/issues/2218
> >
> > But the overhead tends to be fairly small, and I hope we can optimize it 
> > more without adding manual lists.
> >
> > Sounds like you see a 55% code size increase - I'm also curious what is the 
> > slowdown, if you can measure that?
> >
> > - Alon
> >
> >> чт, 18 июл. 2019 г. в 23:28, Alon Zakai :
> >> >
> >> > You may need to do "emsdk update" instead of "emsdk update-tags", 
> >> > depending on if you get the emsdk using git or not.
> >> >
> >> > Latest version should be 1.38.39.
> >> >
> >> > About those errors - yes, the APIs for old Asyncify, Emterpreter, and 
> >> > new Asyncify are not identical. Emterpreter has the "yield" concept, 
> >> > which is not needed in Asyncify (so as you said, just call 
> >> > emscripten_sleep instead of _with_yield). Module.setAsync is an internal 
> >> > API of old Asyncify - if you have custom JS code using it, you need to 
> >> > update it to the new Asyncify's API (see notes on handleSleep in the 
> >> > blogpost: https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html ).
> >> >
> >> > On Thu, Jul 18, 2019 at 1:01 AM Александр Гурьянов  
> >> > wrote:
> >> >>
> >> >> I am not sure that I used latest emscripten (through emsdk), don't
> >> >> know how to check.
> >> >>
> >> >> emcc (Emscripten gcc/clang-like replacement) 1.38.37 (commit
> >> >> d33f7a29002a2463a7956cd53a559b97a52f9560)
> >> >> Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
> >> >> This is free and open source software under the MIT license.
> >> >> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> >> >> PARTICULAR PURPOSE.
> >> >>
> >> >> My debug log didn't contain wasm-opt --asyncify which should be I think.
> >> >>
> >> >> Btw, I used this to update emscripten:
> >> >> emsdk update-tags && emsdk install latest-upstream && emsdk activate
> >> >> -embedded latest-upstream
> >> >>
> >> >> чт, 18 июл. 2019 г. в 14:52, Александр Гурьянов :
> >> >> >
> >> >> > After replacing emscripten_sleep_with_yield on emscripten_sleep I have
> >> >> > new error:
> >> >> >
> >> >> > exception thrown: TypeError: Module.setAsync is not a
> >> >> > function,_emscripten_sleep@http://127.0.0.1:8080/js-dos.js line 1 >
> >> >> > eval:8:182429
> >> >> > GUI_StartUp(Section*)@http://127.0.0.1:8080/js-dos.js line 1 >
> >> >> > WebAssembly.compile:wasm-function[3244]:0x11dccf
> >> >> > Section::ExecuteInit(bool)@http://127.0.0.1:8080/js-dos.js line 1 >
> >> >> > WebAssembly.compile:wasm-function[1025]:0x64869
> >> >> > Config::Init()@http://127.0.0.1:8080/js-dos.js line 1 >
> >> >> > WebAssembly.compile:wasm-function[3634]:0x1339dd
> >> >> > main@http://127.0.0.1:8080/js-dos.js line 1 >
>

Re: -s ASYNCIFY, dosbox