Re: Clang will soon disallow dereferencing void* pointers in C++

['Steven Johnson' via emscripten-discuss]

...how was that ever legal (or useful) in the first place?

On Thu, May 25, 2023 at 10:48 AM 'Derek Schuff' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> tl;dr: if you're currently using the -Wno-void-ptr-dereference flag,
> you'll need to fix your code to stop dereferencing void pointers in C++
>
> Hello emscripten users,
> Dereferencing a void* pointer is invalid in C++ but until recently Clang
> allowed it (by disabling the default warning-as-error). A change
>  recently landed in clang that will
> remove the option to do this, so I wanted to give you all as early of a
> warning as possible that you may need to fix your code (hopefully not; if
> you're not using -Wno-void-ptr-dereference you should be fine). I expect
> this change to eventually roll into an emscripten release in the next few
> weeks.
> Thanks!
> -Derek
>
> --
> 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/CAAEAhveRENM0o-ov%3DUT_yF16KboOGwhiLubhFx7HtWNb%3Dg8mrQ%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/CAM%3Ddnvc-j1zZCd6-UYMOzVHHARFLaX8iLOO5W3VZUR0NOvuK0g%40mail.gmail.com.

Setting emcc options via emcmake?

['Steven Johnson' via emscripten-discuss]

If I am using emcmake to build an existing CMake-based executable, what's
the right / best way to set emcc options? (e.g. -s ASSERTIONS=1 -s
ENVIRONMENT=node)?

Random googling hasn't found a definitive answer. Some hits suggest that I
can use target_compile_options() and/or target_link_opions() in my CMake
build files to set these, but it would be nice if I could (also) just
specify them on the command line (for cases where the CMake files aren't
yet modified to be smart).

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

Re: EMSDK's version of Node.js?

['Steven Johnson' via emscripten-discuss]

Yep, it looks good enough for what I need. SGTM.

On Tue, Oct 26, 2021 at 3:19 PM Alon Zakai  wrote:

> Node docs say that version uses v8 9.4.146.19,
>
> https://nodejs.org/en/download/releases/
>
> I believe SIMD was enabled by default in Chromium 91,
>
> https://developer.chrome.com/blog/new-in-chrome-91/
>
> which would mean V8 9.1.* would be enough. So that should be new enough.
> But it would be good to verify.
>
> On Tue, Oct 26, 2021 at 12:43 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> On Tue, Oct 26, 2021 at 12:39 PM Alon Zakai  wrote:
>>
>>> Separately, however, does 16.13.0 have a new-enough SIMD for you?
>>>
>>
>> Good question. Let me check. (What does it claim?)
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnve%3DO_3znVw4bjrxpR4%2BjZX2wmx6M52tbw5rsajh2myRYw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnve%3DO_3znVw4bjrxpR4%2BjZX2wmx6M52tbw5rsajh2myRYw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTPW8kRNvX1aWUq44XtSei0ndTKW52RGhdf1mpaZKp2oA%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTPW8kRNvX1aWUq44XtSei0ndTKW52RGhdf1mpaZKp2oA%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/CAM%3DdnvcYn%3DVyrYk4CTE9XezNfsy5KTnzQ9BqZ1xyJ5kY6MV2Hw%40mail.gmail.com.

Re: EMSDK's version of Node.js?

['Steven Johnson' via emscripten-discuss]

On Tue, Oct 26, 2021 at 12:39 PM Alon Zakai  wrote:

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

Good question. Let me check. (What does it claim?)

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

EMSDK's version of Node.js?

['Steven Johnson' via emscripten-discuss]

Is EMSDK planning on including a version of Node that is more up-to-date?

emsdk 2.0.32 includes node v14.15.5, which doesn't seem to be up to date
with (e.g.) the final wasm-simd128 spec.

It would simplify life for me a lot if I could rely on the current EMSDK
install to provide a reasonably up-to-date runtime for wasm, rather than
having to install one separately.

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

Re: 'standalone' wasm w/o wasi?

['Steven Johnson' via emscripten-discuss]

Ah, got it. So presumably I just have a call to fdwrite hidden somewhere in
my code I need to purge. Thanks.

On Fri, Jul 24, 2020 at 12:50 PM Alon Zakai  wrote:

> Standalone mode will require WASI if it does things like logging. Wasm by
> itself doesn't have an API for that, so we need *something*, and we try to
> use standard APIs as much as possible (see
> https://v8.dev/blog/emscripten-standalone-wasm#let's-unify-as-much-as-possible
> ).
>
> That is, if you see "fd_write" being required, that means logging is done
> in the wasm module, so to run in wasm-interp we'd need an API to do that,
> and WASI is the most standard API for that, so we use it.
>
> If a program does *not* do any logging, then no fd_write will be imported.
> So WASI is not a general requirement when in standalone mode.
>
> There's nothing special about WASI here. Standalone mode tries not to use
> external APIs as much as possible - it does what it can inside the wasm.
> When it does need to use an API, it will import it. That can in theory be
> any API emscripten supports, not just WASI, it depends on the APIs your
> code needs - for example if you use a GL method like glBufferData it will
> import that (and a custom runtime can then decide to add support for that
> API, say in a game engine that wants GL-doing plugins).
>
>
>
>
> On Fri, Jul 24, 2020 at 12:39 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> TL;DR: does STANDALONE_WASM=1 imply WASI-required?
>>
>> I've been building my wasm code with STANDALONE_WASM=1. This runs in d8
>> just fine (though it still requires the .js wrapper to launch), and also in
>> wasm-interp, but only if I build WASI support into wasm-interp (otherwise
>> I'll fail with things like `invalid import
>> "wasi_snapshot_preview1.fd_write"`).
>>
>> The comments in Emscripten's settings.js regarding STANDALONE_WASM don't
>> seem entirely clear on this front. My assumption at the moment is
>> that STANDALONE_WASM=0 means "You will almost certainly require JS and
>> WASM" (which is fine), but STANDALONE_WASM=1 apparently means "You might
>> require JS and/or WASI in addition to WASM".
>>
>> (The motivation here is that I'd like to use wabt's wasm-interp in a
>> configuration without WASI, but it's not clear to me whether there is a set
>> of flags for Emscripten that will reliably produce standalone wasm that
>> requires neither WASI nor other JS-specific imports from "env".)
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3DdnvfwXFpSG0N%2BfG-Us02bSFASTFeLS_9JewN8S4G5ijreYQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3DdnvfwXFpSG0N%2BfG-Us02bSFASTFeLS_9JewN8S4G5ijreYQ%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/CAEX4NpRftpJOqhkVbZqvBJZCWM8yGT340kiukcchaeVu9m9Jtg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRftpJOqhkVbZqvBJZCWM8yGT340kiukcchaeVu9m9Jtg%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/CAM%3DdnvexZnR8J00M7db8kV1sy02THgEvzCrUJCyShPjwMDAKFQ%40mail.gmail.com.

'standalone' wasm w/o wasi?

['Steven Johnson' via emscripten-discuss]

TL;DR: does STANDALONE_WASM=1 imply WASI-required?

I've been building my wasm code with STANDALONE_WASM=1. This runs in d8
just fine (though it still requires the .js wrapper to launch), and also in
wasm-interp, but only if I build WASI support into wasm-interp (otherwise
I'll fail with things like `invalid import
"wasi_snapshot_preview1.fd_write"`).

The comments in Emscripten's settings.js regarding STANDALONE_WASM don't
seem entirely clear on this front. My assumption at the moment is
that STANDALONE_WASM=0 means "You will almost certainly require JS and
WASM" (which is fine), but STANDALONE_WASM=1 apparently means "You might
require JS and/or WASI in addition to WASM".

(The motivation here is that I'd like to use wabt's wasm-interp in a
configuration without WASI, but it's not clear to me whether there is a set
of flags for Emscripten that will reliably produce standalone wasm that
requires neither WASI nor other JS-specific imports from "env".)

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

Current EMSDK Node version out of date?

['Steven Johnson' via emscripten-discuss]

AFAICT, the current EMSDK (1.39.19) uses the finalized opcodes for the
simd128 feature set, but the version of Node that is included in the
EMSDK does not. This makes for amusing runtime errors if you try to
compile wasm and test via Node.

- If this is in fact the case (and not a stupid config error on my
part), may I suggest that the EMSDK release notes point this out?
(Maybe most folks aren't relying on Node for wasm-testing purposes,
but it's handy and seems like it would be in sync, since it's
included...)

- Is there any ETA for when a stable version of Node with final
wasm-simd support will be available?

- If there is no ETA, are there other fast (non-browser) command-line
wasm implementations that would be suitable for testing (ie up to date
with the final spec)? (WABT's wasm-interp tool would be great but is
too slow for some of my purposes)

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

Re: "Output contains some very large functions"

['Steven Johnson' via emscripten-discuss]

Bah -- nevermind, apparently I had misconfigured my EMCC flags to use
`-s WASM=2`. Sorry for the noise.

On Thu, Jul 9, 2020 at 12:51 PM Steven Johnson  wrote:
>
> I consistently get this warning for some of my code when I compile
> with Emscripten -- from looking at the source, it appears that it
> can't be disabled, and that it is hardcoded to assume that "very
> large" means "more than 3000 lines".
>
> In this case, the "very large" code it refers to is machine-generated
> code from the Halide compiler, which does indeed sometimes emit
> "large" code blocks.
>
> Can someone expand on what the nature of this warning really implies,
> and whether there is a way I can silence 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/CAM%3DdnvcMUtPzb5f6r%2BMGyng8EYkppDXsrh_REdmh15B6ZtnZ1Q%40mail.gmail.com.

"Output contains some very large functions"

['Steven Johnson' via emscripten-discuss]

I consistently get this warning for some of my code when I compile
with Emscripten -- from looking at the source, it appears that it
can't be disabled, and that it is hardcoded to assume that "very
large" means "more than 3000 lines".

In this case, the "very large" code it refers to is machine-generated
code from the Halide compiler, which does indeed sometimes emit
"large" code blocks.

Can someone expand on what the nature of this warning really implies,
and whether there is a way I can silence 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/CAM%3DdnvdUrHLCKTudYaEcr4K-C%2BcyJLgdB_U%3DkOsUJ-q%3D-M1EEQ%40mail.gmail.com.

Re: Mixing emcc and 'host' toolchains in CMake?

['Steven Johnson' via emscripten-discuss]

On Wed, Jul 8, 2020 at 10:26 PM Shachar Langbeheim  wrote:
> In our project we have a single cmake project, with multiple targets - 
> backend & tests executables are built with clang, wasm with emscripten. It 
> works ok - not perfect, because we still need to add a lot of if statements 
> to handle the different files that belong in different executables, and the 
> different compilation and linking flags for each target, but it works.

Interesting, I didn't think that was possible, at least not with the
standard CMake commands. Do you just use `add_custom_command` to drive
command-line tools directly, rather than (e.g.) `add_library()` and
friends?

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

Mixing emcc and 'host' toolchains in CMake?

['Steven Johnson' via emscripten-discuss]

(This question is more CMake-related than Emscripten-related, but I suspect
someone else on this list may have encountered it, so thought I'd ask
here...)

TL;DR: Has anyone attempted to use both the Emscripten toolchain and the
'host' toolchain (eg gcc, clang) in the same CMake project?

Some of the tooling in this project (e.g. our crosscompiler tool that
produces .wasm) really needs to be compiled natively, while other parts
(e.g. the test suite) needs to be compiled via Emscripten. IIUC, CMake has
a pretty hard distinction of "one toolchain per language per project,
period" (unlike, say, Blaze/Bazel, which makes this distinction easy).

There are various ways to work around this (CMake's ExternalProject,
splitting our project into multiple CMake projects, etc) but they all have
nontrivial drawbacks, so I thought I'd check to see if anyone has found an
approach that is simpler to implement and maintain.

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

Re: Using python literals for EM_CONFIG/--em-config

['Steven Johnson' via emscripten-discuss]

It will be next week at the earliest -- I am currently elbow-deep in work
on the Halide build/test setup (and, as it turns out, the emcc testing
hasn't been enabled for our public repo recently, so it might have broken
for other reasons).

On Thu, May 21, 2020 at 8:59 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Wed, May 20, 2020 at 6:55 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> I did not know that. That sounds like a much better approach anyway :-)
>>
>
> I'll hold off changing any of this until you can make your change
> downstream.  Can you let me know when have converted?
>
> cheers,
> sam
>
>
>> On Wed, May 20, 2020 at 5:21 PM 'Sam Clegg' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>>
>>>
>>> On Wed, May 20, 2020 at 2:12 PM 'Steven Johnson' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com> wrote:
>>>
>>>> Halide uses the EM_CONFIG variable in its build script.
>>>>
>>>> The reason for this is that we need to ensure that LLVM_ROOT points to
>>>> the specific version of LLVM being used by the rest of Halide. (Having
>>>> these out of sync can cause amusingly bad things to happen.) We slurp in
>>>> the default ~/.emscripten config file and make an altered version (with
>>>> LLVM_ROOT pointing to the LLVM we are using), so that we can always build
>>>> with the 'correct' version (ie the one that the rest of Halide is using).
>>>>
>>>> Requiring that ~/.emscripten be edited is problematic as Halide
>>>> supports multiple versions of LLVM at any one time (currently, v9, v10, and
>>>> v11/trunk), so this file would need to edited in lockstep with other things
>>>> in Halide to keep things in step.
>>>>
>>>
>>> Thanks for the heads up steven!
>>>
>>> We had another report of someone using it, so I reverted the warning for
>>> now.
>>>
>>> I'm hoping we can move both of you in different direction over time.
>>>  For example, did you know that you can set the LLVM_ROOT using the
>>> `EM_LLVM_ROOT` environment variable?  This seems more targeted and easier
>>> for you.  Any variable that you can set from the config file can also be
>>> set via the environment in the form of `EM_`.
>>>
>>> cheers,
>>> sam
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 19, 2020 at 11:46 AM 'Sam Clegg' via emscripten-discuss <
>>>> emscripten-discuss@googlegroups.com> wrote:
>>>>
>>>>> emscripten has a feature where you can avoid using a config file
>>>>> completely and instead pass a python literal in the EM_CONFIG
>>>>> environment variable or `--em-config` command line.
>>>>>
>>>>> e.g.  `emcc --em-config="`
>>>>>
>>>>> As part of routine cleanup I'm hoping to be able to remove this
>>>>> feature and allow the code to depend on the existence of  a config
>>>>> file on disk.
>>>>>
>>>>> I'm not imagining there are any users of this feature, and we can
>>>>> make it into warning a few releases to confirm this.
>>>>>
>>>>> Does anyone know of any users of this feature?
>>>>>
>>>>> cheers,
>>>>> 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_va28seE50BNe4BKJ4cFzoQNNZPE6xbFFwDvXQSdWfiF2WAA%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28seE50BNe4BKJ4cFzoQNNZPE6xbFFwDvXQSdWfiF2WAA%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+unsubsc

Re: Using python literals for EM_CONFIG/--em-config

['Steven Johnson' via emscripten-discuss]

I did not know that. That sounds like a much better approach anyway :-)

On Wed, May 20, 2020 at 5:21 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

>
>
> On Wed, May 20, 2020 at 2:12 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Halide uses the EM_CONFIG variable in its build script.
>>
>> The reason for this is that we need to ensure that LLVM_ROOT points to
>> the specific version of LLVM being used by the rest of Halide. (Having
>> these out of sync can cause amusingly bad things to happen.) We slurp in
>> the default ~/.emscripten config file and make an altered version (with
>> LLVM_ROOT pointing to the LLVM we are using), so that we can always build
>> with the 'correct' version (ie the one that the rest of Halide is using).
>>
>> Requiring that ~/.emscripten be edited is problematic as Halide supports
>> multiple versions of LLVM at any one time (currently, v9, v10, and
>> v11/trunk), so this file would need to edited in lockstep with other things
>> in Halide to keep things in step.
>>
>
> Thanks for the heads up steven!
>
> We had another report of someone using it, so I reverted the warning for
> now.
>
> I'm hoping we can move both of you in different direction over time.   For
> example, did you know that you can set the LLVM_ROOT using the
> `EM_LLVM_ROOT` environment variable?  This seems more targeted and easier
> for you.  Any variable that you can set from the config file can also be
> set via the environment in the form of `EM_`.
>
> cheers,
> sam
>
>
>>
>>
>>
>>
>> On Tue, May 19, 2020 at 11:46 AM 'Sam Clegg' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>> emscripten has a feature where you can avoid using a config file
>>> completely and instead pass a python literal in the EM_CONFIG
>>> environment variable or `--em-config` command line.
>>>
>>> e.g.  `emcc --em-config="`
>>>
>>> As part of routine cleanup I'm hoping to be able to remove this
>>> feature and allow the code to depend on the existence of  a config
>>> file on disk.
>>>
>>> I'm not imagining there are any users of this feature, and we can
>>> make it into warning a few releases to confirm this.
>>>
>>> Does anyone know of any users of this feature?
>>>
>>> cheers,
>>> 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_va28seE50BNe4BKJ4cFzoQNNZPE6xbFFwDvXQSdWfiF2WAA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28seE50BNe4BKJ4cFzoQNNZPE6xbFFwDvXQSdWfiF2WAA%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/CAM%3DdnveGTKtEqGWue_qyUMjdyLdGXZbXEm8m4fhPjreRgd4tGQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3DdnveGTKtEqGWue_qyUMjdyLdGXZbXEm8m4fhPjreRgd4tGQ%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_va29xtsd5emac0nfmvUys84xaBdx-xMes515U1sATFPJe1w%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29xtsd5emac0nfmvUys84xaBdx-xMes515U1sATFPJe1w%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/CAM%3Ddnvf79x%3DXt_CLym76VCoTeJBmpu0pw9%2BWWR0CH6ixTcjptg%40mail.gmail.com.

Re: Using python literals for EM_CONFIG/--em-config

['Steven Johnson' via emscripten-discuss]

Halide uses the EM_CONFIG variable in its build script.

The reason for this is that we need to ensure that LLVM_ROOT points to the
specific version of LLVM being used by the rest of Halide. (Having these
out of sync can cause amusingly bad things to happen.) We slurp in the
default ~/.emscripten config file and make an altered version (with
LLVM_ROOT pointing to the LLVM we are using), so that we can always build
with the 'correct' version (ie the one that the rest of Halide is using).

Requiring that ~/.emscripten be edited is problematic as Halide supports
multiple versions of LLVM at any one time (currently, v9, v10, and
v11/trunk), so this file would need to edited in lockstep with other things
in Halide to keep things in step.




On Tue, May 19, 2020 at 11:46 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> emscripten has a feature where you can avoid using a config file
> completely and instead pass a python literal in the EM_CONFIG
> environment variable or `--em-config` command line.
>
> e.g.  `emcc --em-config="`
>
> As part of routine cleanup I'm hoping to be able to remove this
> feature and allow the code to depend on the existence of  a config
> file on disk.
>
> I'm not imagining there are any users of this feature, and we can
> make it into warning a few releases to confirm this.
>
> Does anyone know of any users of this feature?
>
> cheers,
> 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_va28seE50BNe4BKJ4cFzoQNNZPE6xbFFwDvXQSdWfiF2WAA%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/CAM%3DdnveGTKtEqGWue_qyUMjdyLdGXZbXEm8m4fhPjreRgd4tGQ%40mail.gmail.com.

Re: Problem with SIMD emulation (LLVM ERROR: Unsupported integer vector type with numElems: 2, primitiveSize: 64!)

['Steven Johnson' via emscripten-discuss]

Err, maybe I'm missing something, but if developers writing for wasm have
to think about whether the target has SSEx (specifically) or Neon
(specifically) we're doing things terribly wrong. The only target they
should need to check for is whether the *wasm* engine supports
wasm-simd128, and target that; if developers need to detect for  underlying
implementation details, that should be a huge red flag. (I'd argue that
even being *able* to detect the underlying SIMD architecture from wasm-land
is a bad idea, lest people try to game their current compiler to squeak out
marginal performance improvements based on that.)


>  Developers want to be able to write page_sse.wasm and
> page_neon.wasm files and feature check to run the appropriate one
> depending on the target. (and they also want to be able to write
> page_simd.wasm that simultaneously targets both sse and neon) But
> there is some hope to introduce proper SSE* instruction sets in a
> future revision of the WebAssembly SIMD v2 or similar.
>

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

Re: Pthreads in the V8 shell

['Steven Johnson' via emscripten-discuss]

I'd be content with either one.

On Wed, Jul 10, 2019 at 10:24 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> I think its a lot more interesting to support threads in node that in
> d8.  node is widely used and has official releases.  d8 is designed as
> an internal testing tool for v8 a IIUC nothing else.
>
> On Mon, Jul 8, 2019 at 11:32 AM Alon Zakai  wrote:
> >
> > I don't think it's quite that official, as it appears undocumented. But
> I have heard that they use it internally and don't plan to change it. So
> it's on par with all of d8 basically, which is not standardized/documented,
> but still very useful.
> >
> > Another option is to try to get node Workers working. I have some wip
> stuff in the node-pthreads branch, but I ran out of time - would be great
> if someone else can look at that. Basically, the challenge is that logging
> etc. is impossible when the main thread blocks, which makes it very hard to
> debug. But it might be possible to get working. (d8's nonstandard blocking
> APIs make things easier)
> >
> > - Alon
> >
> >
> >
> > On Mon, Jul 8, 2019 at 10:05 AM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
> >>
> >> This is (potentially) great news; being able to test wasm-threads code
> via d8 (rather than a full browser interaction) would make future Halide
> support for threading much easier to support. But is this a deliberate,
> long-term commitment on the part of V8 to provide enough WebWorker support
> to support wasm threading? (We wouldn't entertain using this otherwise.)
> >>
> >> On Tue, Jul 2, 2019 at 2:02 PM Alon Zakai  wrote:
> >>>
> >>> Thanks, I didn't know the V8 shell had this!
> >>>
> >>> After asking some people, it sounds like this can indeed be useful for
> us. It isn't intended to be identical to the Web API for Workers, but it is
> not a temporary API, so we can rely on it for testing.
> >>>
> >>>  -  I think we'd need to work around any API differences like that
> .data thing, by checking if we are in "ENVIRONMENT_IS_SHELL" etc.
> >>>  - The synchronous getMessage is a special d8 extension, yeah - if
> it's useful for us then no reason not to use it (but yeah, such things are
> probably not well documented except in the source...).
> >>>
> >>> PR sounds great!
> >>>
> >>> - Alon
> >>>
> >>>
> >>> On Sat, Jun 29, 2019 at 3:48 AM Zoltan Varga  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>  It looks like recent versions of V8's JS shell support web workers,
> so it is possible to run emscripten+pthreads in this shell. This is useful
> for running test suites which
> >>>> use threads as it requires less work than running in the browser.
> >>>>
> >>>> Ran into the following problems:
> >>>> - the message received by onmessage () is not wrapped in a 'data'
> property. This might be a bug in D8.
> >>>> - the main threads onmessage () seems to be only called when control
> returns to the main loop which never seems to happen in the JS shell, so
> the 'loaded' message
> >>>>   is never received by the main thread, so startup fails. Worked
> around it by receiving the message synchronously using worker.getMessage ()
> and passing it to
> >>>>   onmessage (). Couldn't find too much documentation on getMessage
> (), is it a V8 extension ?
> >>>>
> >>>> Here is a commit with the changes:
> >>>>
> https://github.com/vargaz/emscripten/commit/99e8ab6fb5e2a46a880aebe30014f6065b1c1b35
> >>>>
> >>>> Wanted to discuss these isues before making it into a PR.
> >>>>
> >>>> Zoltan
> >>>>
> >>>>
> >>>> --
> >>>> 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/95c693a4-7d24-4e40-9bff-7ea1e960daa4%40googlegroups.com
> .
> >>>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "

Re: Pthreads in the V8 shell

['Steven Johnson' via emscripten-discuss]

This is (potentially) great news; being able to test wasm-threads code via
d8 (rather than a full browser interaction) would make future Halide
support for threading much easier to support. But is this a deliberate,
long-term commitment on the part of V8 to provide enough WebWorker support
to support wasm threading? (We wouldn't entertain using this otherwise.)

On Tue, Jul 2, 2019 at 2:02 PM Alon Zakai  wrote:

> Thanks, I didn't know the V8 shell had this!
>
> After asking some people, it sounds like this can indeed be useful for us.
> It isn't intended to be identical to the Web API for Workers, but it is not
> a temporary API, so we can rely on it for testing.
>
>  -  I think we'd need to work around any API differences like that .data
> thing, by checking if we are in "ENVIRONMENT_IS_SHELL" etc.
>  - The synchronous getMessage is a special d8 extension, yeah - if it's
> useful for us then no reason not to use it (but yeah, such things are
> probably not well documented except in the source...).
>
> PR sounds great!
>
> - Alon
>
>
> On Sat, Jun 29, 2019 at 3:48 AM Zoltan Varga  wrote:
>
>> Hi,
>>
>>  It looks like recent versions of V8's JS shell support web workers, so
>> it is possible to run emscripten+pthreads in this shell. This is useful for
>> running test suites which
>> use threads as it requires less work than running in the browser.
>>
>> Ran into the following problems:
>> - the message received by onmessage () is not wrapped in a 'data'
>> property. This might be a bug in D8.
>> - the main threads onmessage () seems to be only called when control
>> returns to the main loop which never seems to happen in the JS shell, so
>> the 'loaded' message
>>   is never received by the main thread, so startup fails. Worked around
>> it by receiving the message synchronously using worker.getMessage () and
>> passing it to
>>   onmessage (). Couldn't find too much documentation on getMessage (), is
>> it a V8 extension ?
>>
>> Here is a commit with the changes:
>>
>> https://github.com/vargaz/emscripten/commit/99e8ab6fb5e2a46a880aebe30014f6065b1c1b35
>>
>> Wanted to discuss these isues before making it into a PR.
>>
>> Zoltan
>>
>>
>> --
>> 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/95c693a4-7d24-4e40-9bff-7ea1e960daa4%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAEX4NpQukKgBZQ3eLFxH0UCNotCWQchQ7S6cgMXDLM_Tus4wwA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Emscripten / emsdk for arm64-linux hosts?

['Steven Johnson' via emscripten-discuss]

On Fri, May 31, 2019 at 5:01 PM Alon Zakai  wrote:

> We should probably give an error on other platforms.
>

Well, you do. It's just a little delayed. :-)

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

Emscripten / emsdk for arm64-linux hosts?

['Steven Johnson' via emscripten-discuss]

I want to install and run Emscripten / emsdk on an arm64-linux system for
testing (specifically, a Jetson TX2 running NVidia's Linux distro for it).
I tried the standard install route, but alas, it installs x86-64 tools (or
at least, some of them are, e.g. wasm-emscripten-finalize).

Before I attempt to pull source and build from scratch, just want to verify
that this is a known issue and that this isn't either (1) a transitory bug
or (2) me just holding it wrong.

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

Re: emscripten-ports: libjpeg?

['Steven Johnson' via emscripten-discuss]

aha, I'm using 1.38.30 -- didn't notice 1.38.31 was out.

On Tue, May 21, 2019 at 4:10 PM Alon Zakai  wrote:

> Which version is that with? Looks like the port was added in 1.38.31.
>
> On Tue, May 21, 2019 at 4:02 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> When I tried using -s USE_LIBJPEG=1 I fail with:
>>
>> shared:ERROR: Assigning a non-existent settings attribute
>> "USE_LIBJPEG"
>> shared:ERROR:  - did you mean one of USE_LIBPNG, USE_ZLIB, USE_REGAL?
>>
>>
>>
>> On Tue, May 21, 2019 at 2:51 PM Alon Zakai  wrote:
>>
>>> It is available as a port, can use it with
>>>
>>> -s USE_LIBJPEG=1
>>>
>>> The list of ports flags is in src/settings.js - maybe we should document
>>> that better? (Where did you look for it?)
>>>
>>> But there isn't an actual repo in github.com/emscripten-ports because
>>> we didn't need to fork it with any changes, upstream code is fine, and
>>> fetched from the ports code in tools/ports/libjpeg.py
>>>
>>> - Alon
>>>
>>>
>>> On Tue, May 21, 2019 at 2:36 PM 'Steven Johnson' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com> wrote:
>>>
>>>> Is libjpeg available in a ready-to-emscriptify form?( I'm a little
>>>> surprised that libjpeg isn't available in emscripten-ports.)
>>>>
>>>> Yes, I realize I could use SDL for this, but AFAIK not using the same
>>>> API as libjpeg, and I'd prefer to compile code as-is when possible.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnvd4yE1ghzho9aGwLLP8-6tBWf9Qrjryuv%3D2bxzmqV%3DF3g%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnvd4yE1ghzho9aGwLLP8-6tBWf9Qrjryuv%3D2bxzmqV%3DF3g%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> 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/CAEX4NpTnyq4y11gyO5vMjMUi9Qcj88tQgWzqb8rTvqi3ibVaBw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTnyq4y11gyO5vMjMUi9Qcj88tQgWzqb8rTvqi3ibVaBw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnveuf3tCuox1LGTTeXt-froCBv9f8Pso_vZJxK56G%2Bb7Zw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnveuf3tCuox1LGTTeXt-froCBv9f8Pso_vZJxK56G%2Bb7Zw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAEX4NpQ2r-0_Wyps%3Dd385EoMRVB3SH7o-7N_NyKoa67Jd90AqQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQ2r-0_Wyps%3Dd385EoMRVB3SH7o-7N_NyKoa67Jd90AqQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Accessing local files from C++/wasm when in Node / d8 / etc.?

['Steven Johnson' via emscripten-discuss]

Ah, I didn't know that was a thing! That sounds like the thing I most
likely want. (Underlying OS differences are less likely to matter for these
cases.)

On Tue, May 21, 2019 at 2:03 PM Alon Zakai  wrote:

> Another option is NODERAWFS. That just lets the code access the filesystem
> directly through node's APIs.
>
> The main problem there is that node filesystem commands can behave
> differently on different OSes (because of underlying OS differences,
> probably, but could also be node oddities I guess). If you avoid corner
> cases though then this mode can work well.
>
> - Alon
>
>
> On Tue, May 21, 2019 at 11:56 AM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> I have a bunch of pre-existing tests and benchmarks written in vanilla
>> C++ that load images (png, jpeg, etc) from the local filesystem as part of
>> their normal operation. I'm now cross-compiling them into wasm using
>> emscripten, and running them in a wasm-enabled shell (d8 or Node); what
>> options do I have that will minimize the amount of editing I need to do to
>> each test?
>>
>> Based on what I've read so far:
>>
>>- I could modify my Makefiles to use --embed_file when building each
>>test. Pro: the tests can work without editing the C++ source. Con: build
>>time is extremely slow; doesn't allow any test outputs or byproducts to be
>>easily written to local filesystem (e.g for debugging)
>>- If I require Node instead of d8, I could use FS.mount(NODEFS) to
>>map the local filesystem in a way that the wasm code can see. Pros:
>>actually provides file access and file output. Cons: requires adding
>>awkward boilerplate to every test I want to run in this environment;
>>requires Node rather than d8
>>
>> Are there other options I'm missing? (Fortunately, running these tests in
>> a browser environment isn't yet a requirement, though it may be eventually.)
>>
>> (A close-enough-to-ideal solution for me would be if Node allowed some
>> commandline / config setup that did the filesystem mapping automatically;
>> if such a thing exists, I haven't found it, but I am a newcomer to Node so
>> could have easily missed 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/CAM%3DdnvcJHX%3DgYipxm_gQKPcuP60n%3DVb7-fDNYn9xqmsTtORX7w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAM%3DdnvcJHX%3DgYipxm_gQKPcuP60n%3DVb7-fDNYn9xqmsTtORX7w%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAEX4NpSGiNxN45NPS-ZB%2BzZ6S3u2sTZCD8nay9evQEvnapibmg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSGiNxN45NPS-ZB%2BzZ6S3u2sTZCD8nay9evQEvnapibmg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Accessing local files from C++/wasm when in Node / d8 / etc.?

['Steven Johnson' via emscripten-discuss]

I have a bunch of pre-existing tests and benchmarks written in vanilla C++
that load images (png, jpeg, etc) from the local filesystem as part of
their normal operation. I'm now cross-compiling them into wasm using
emscripten, and running them in a wasm-enabled shell (d8 or Node); what
options do I have that will minimize the amount of editing I need to do to
each test?

Based on what I've read so far:

   - I could modify my Makefiles to use --embed_file when building each
   test. Pro: the tests can work without editing the C++ source. Con: build
   time is extremely slow; doesn't allow any test outputs or byproducts to be
   easily written to local filesystem (e.g for debugging)
   - If I require Node instead of d8, I could use FS.mount(NODEFS) to map
   the local filesystem in a way that the wasm code can see. Pros: actually
   provides file access and file output. Cons: requires adding awkward
   boilerplate to every test I want to run in this environment; requires Node
   rather than d8

Are there other options I'm missing? (Fortunately, running these tests in a
browser environment isn't yet a requirement, though it may be eventually.)

(A close-enough-to-ideal solution for me would be if Node allowed some
commandline / config setup that did the filesystem mapping automatically;
if such a thing exists, I haven't found it, but I am a newcomer to Node so
could have easily missed 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/CAM%3DdnvcJHX%3DgYipxm_gQKPcuP60n%3DVb7-fDNYn9xqmsTtORX7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: std::chrono::high_resolution_clock::now throwing exception in Safari (when ASM.JS is run in webworker)

['Steven Johnson' via emscripten-discuss]

...three years later, looks like this bug is still alive and well in 
Emscripten (I found it via compiling wasm, not asm.js).

I need something like steady_clock() to use for a simple code-benchmarking 
setup; if I can't rely on std::chrono, what's the recommended replacement?



On Monday, July 25, 2016 at 3:24:48 AM UTC-7, Gaurav Dewan wrote:
>
> Based on quick read of C++ specs (although more thorough reading of C++ 
> specs would be required), 
> (1) std::chrono::high_resolution_clock::now is declared to be 
> no-except(cannot throw exceptions). 
> (2) high_resolution_-clock may be a synonym for system_clock or 
> steady_clock
>
> When calling this function in Safari ASM.JS worker(Mac), 
> The test program is same as:
> https://github.com/kripken/emscripten/issues/2980
> It's just that this asm.js is loaded from javascript webworker.
>
> Function *__ZNSt3__16chrono12steady_clock3nowE *calls 
> *__ZNSt3__120__throw_system_errorEiPKc 
> (via *invoke_vii).
> Shouldn't emscripten fallback to Date.now() if Performance.now() is not 
> implemented ?
>
>

-- 
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/7442060b-58e6-43f8-9318-d2bd96531a29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Advice needed: testing threaded wasm code

['Steven Johnson' via emscripten-discuss]

On Tue, Apr 2, 2019 at 12:01 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> You might want to look at how the emscripten browser tests run.  See
> tests/runner.py.  I'm not sure you will fundamentally better results
> than you are seeing with emrun or with Puppeteer but its another way
> to do it. Check out the circleci config for how to make firefox and
> chrome headless for testing.
>

Emscripten doesn't use emrun for its own browser tests? Heh. What's the
code equivalent of "Physician, heal thyself"? Thanks for the tip. Will
investigate.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Advice needed: testing threaded wasm code

['Steven Johnson' via emscripten-discuss]

The Halide team (halide-lang.org) is experimenting with a WebAssembly
backend; as a newcomer to the wasm world, I'm still sorting out the
ecosystem, and need some advice.

So far, we've been running all our unit tests using d8, as it's easy
to drive from our existing bash/make command-line-oriented system...
but if I understand correctly, none of the existing shell-oriented
wasm tools support the threads feature proposal, and (apparently) none
seem likely to do so in the near future. (I'd love to be wrong about
this; if there is such a tool now or soon-ish, please let me know.)

So that probably means I need to look at a testing model that drives
an actual browser to do testing of threaded code, which is a little
complicated. (For our testing purposes, we have zero need for a full
browser environment -- everything in our tests is shell-based -- but
we'll do what we have to do.)

The main contenders for making this easy would seem to be either Emrun
or Node+Puppeteer, but after some experimentation, both have
limitations that are problems for us.

Emrun works with multiple browsers, so testing multiple wasm engines
is relatively simple. integration with Emscripten is fairly slick and
simple, capture of JS console output is flawless. But... it apparently
doesn't support Chrome in headless mode which is definitely suboptimal
for us (we'd like to be able to run units tests on various
single-board systems with very limited resources); additionally,
running multiple tests simultaneously requires work to avoid weird
glitches in the local server, which dramatically slows down test
throughput.

Node+Puppeteer, on the other hand, supports headless mode perfectly;
on the other hand, it's Chrome-only, and capturing JS console output
from Emscripten-generated code doesn't seem to work out of the box
(though I'm guessing this latter bit can be corrected with some
tweaking of output templates).

Are there other alternatives that I have overlooked? Anyone else have
suggestions or experience in this area? Thanks in advance for any
advice.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

emrun and Chrome --headless?

['Steven Johnson' via emscripten-discuss]

I'm experimenting with emrun, and I'd like to use it to run wasm in Chrome 
in headless mode, a la:

  emrun --browser chrome --timeout 30 --browser_args="--headless" 
/path/to/my/code.html

The gotcha here is that in headless mode, the JavaScript console output 
isn't captured (whereas it works fine in non-headless mode); this is a 
dealbreaker for my use case.

Is this a known bug and/or a fixable one?

-- 
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.
For more options, visit https://groups.google.com/d/optout.