post-checkout git hook for emscripten

2024-10-02 Thread 'Sam Clegg' via emscripten-discuss
If you use emscripten via git then you will be aware of the `./bootstrap` script that needs to run to perform various tasks after you checkout emscripten. There is now a post-checkout script that will do this for you, avoiding the "you need to run bootstrap" message you may have seen. To install

Re: How to rerun build-test

2024-09-09 Thread 'Sam Clegg' via emscripten-discuss
I think you need to be on the core contributor list in order re-run jobs, or toe re-run with ssh access.Please comment you your PR if you would like to help you re-run the jobs or debug the issue. cheers, sam On Mon, Sep 9, 2024 at 8:18 PM Jie Pan wrote: > Some test failed in my PR, I don't

Re: `emsdk install` vs. `emsdk activate`

2024-09-04 Thread 'Sam Clegg' via emscripten-discuss
You are correct in your assumption. The idea is that you can have more installed tools than active ones. However, sadly, for the main SDK itself we don't support side-by-side installation of versions and only one version can be installed at time (because they all live in the same "upstream" direc

Re: unsigned

2024-09-03 Thread 'Sam Clegg' via emscripten-discuss
On Tue, Sep 3, 2024 at 5:32 PM craste...@gmail.com wrote: > I mean native data types for the language. (bytecode) > uint8, uint16, uint32 and uint64 > > Currently, when C++ code that refers to them, they get promoted to the > larger, signed version, under the covers. > Wasm itself only supports

Re: unsigned

2024-09-03 Thread 'Sam Clegg' via emscripten-discuss
On Tue, Sep 3, 2024 at 4:53 PM craste...@gmail.com wrote: > Any news, rumors or plans for WASM (followed by emscripten) to support > multiple byte depth unsigned integers? Can you elaborate? What are "multiple byte depth unsigned integers"? Perhaps you are referring to variable length integer

Re: _emscripten_run_callback_on_thread causing deadlocks

2024-08-22 Thread 'Sam Clegg' via emscripten-discuss
That looks like a regression. Could you open a bug for this? Also, can you confirm that https://github.com/emscripten-core/emscripten/commit/c41f6590b1f9fcda12b2adb2d32cd352f163e717 is the culprit? i.e. reverting this fixes the issue for you? cheers, sam On Thu, Aug 22, 2024 at 6:44 AM Stephan

Re: Bundling Emscripten-generated JS with Vite

2024-07-15 Thread 'Sam Clegg' via emscripten-discuss
This does sound like a vite bundling issue. I dont know of anything in emscripten that is specific to vite (i honestly don't really know what vite is). I suggest you bring this up with the vite folks and then if there is anything specific that we can do on the emscripten side to make things bett

Re: Bundling Emscripten-generated JS with Vite

2024-07-15 Thread 'Sam Clegg' via emscripten-discuss
Hi Zach, Are you saying there is code in the emscripten-generated maze_builder.js that is using the DOM without first checking the API exists? Which code is that can you point it? Where does `index-Bw7omusj.js` come from? Is that the compiled version of your main.tsx? What does "bundling the D

Re: What is the correct way to have multiple audio processors streaming samples to the output buffer?

2024-07-10 Thread 'Sam Clegg' via emscripten-discuss
You can add `-g` or `--profiling-funcs` to your build to get a symbols in your stack traces. Once you have that, it might be worth opening a bug for this. cheers, sam On Wed, Jul 10, 2024 at 4:23 PM Patrick Collins wrote: > It seems that this the callstack sometimes has at > WasmAudioWorkletPr

Re: Identification of malloc and free

2024-07-09 Thread 'Sam Clegg' via emscripten-discuss
On Tue, Jul 9, 2024 at 2:28 AM NgulaDE wrote: > Thank you so much for the answer. > Does dlmalloc and emmalloc still use sbrk and emscripten_resize_heap if > -sABORTTING_MALLOC is disabled? Because I need an approach that does not > depend on any emscripten options or flags and that still detects

Re: Optimization takes a long time!!

2024-07-08 Thread 'Sam Clegg' via emscripten-discuss
It seems that what is slow here is the `--asyncify` pass in wasm-opt. IIUC that pass will be slower or faster depending on how much of your program need to be asyncified. If you are using embind with asyncify I don't think you can avoid the need to asyncify calls to _emval_await so I'm not sure w

Re: Identification of malloc and free

2024-07-08 Thread 'Sam Clegg' via emscripten-discuss
Hi Ngula, In emscripten the allocators such as dlmalloc and emmalloc use `sbrk()` when they run out of memory. `sbrk()` then calls `emscripten_resize_heap`, which by default will abort with an error message here: https://github.com/emscripten-core/emscripten/blob/b3c25673f53974ff1f30df43701dc63a

Re: First app with WebSockets

2024-07-07 Thread 'Sam Clegg' via emscripten-discuss
Regarding the missing malloc export, I uploaded a fix here: https://github.com/emscripten-core/emscripten/pull/22198 cheers, sam On Sat, Jul 6, 2024 at 7:20 PM Ivan Enzhaev <8observ...@gmail.com> wrote: > I have solved it! > ```cmake > if(CMAKE_SYSTEM_NAME MATCHES Emscripten) > set(CMAKE_EXE

Re: Optimization takes a long time!!

2024-07-05 Thread &#x27;Sam Clegg' via emscripten-discuss
You can run your link command with `EMPROFILE=2` set in the environment and emscripten will print a breakdown of the various link steps. If you want even more details you can use `EMPROFILE=1` to produce a trace that can be rendered as html. See https://emscripten.org/docs/optimizing/Profiling-To

Re: [RuntimeError: unreachable] Retrieving from async function in C++

2024-07-03 Thread &#x27;Sam Clegg' via emscripten-discuss
If you build with `-g` (or just `--profiling-funcs`) when you should see symbol names in your backtrace which might help you figure out what is going on. You might also want to drop the `-O3` when debugging too. BTW, we have `emscripten_console_log` and `emscripten_console_error` functions so you

Re: SIDE_MODULE causes "imported function does not match the expected type"

2024-06-29 Thread &#x27;Sam Clegg' via emscripten-discuss
ies for the dull question. > > Best, > Andrea > > On Sat, 29 Jun 2024, 23:54 'Sam Clegg' via emscripten-discuss, < > emscripten-discuss@googlegroups.com> wrote: > >> Hi Andrea, glad to hear you have things compiling at least. >> >> A couple of

Re: SIDE_MODULE causes "imported function does not match the expected type"

2024-06-29 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi Andrea, glad to hear you have things compiling at least. A couple of pieces of advice to get started. 1. If possible can you simply use static linking? It would simplify things greatly and reduce code size.Unless you program is very much based on around the idea of dlopen/dlsym I would

Re: .tmp0 output file

2024-06-17 Thread &#x27;Sam Clegg' via emscripten-discuss
I have no idea what phase of the linker might be creating that file. One possible way to figure it out would be build with `EMCC_DEBUG=1` and then search the log for `.tmp0`. Could you give that a try? cheers, sam On Fri, Jun 14, 2024 at 10:45 AM Grayson Clark wrote: > Of note, tup creates a

Re: .tmp0 output file

2024-06-10 Thread &#x27;Sam Clegg' via emscripten-discuss
I'm not sure what this `tmp0` file might be. I don't think we generate any files with names like that. Where are you seeing that file being created? Emscripten should only write temp files to the temp directory (e.g. `/tmp`). cheers, sam On Mon, Jun 10, 2024 at 3:00 PM Grayson Clark wrote:

Re: Aliases for items in EMSCRIPTEN_BINDINGS (Re: embind questions)

2024-06-02 Thread &#x27;Sam Clegg' via emscripten-discuss
Better to set your `onRuntimeInitialized` in pre-js since that works even for projects that use `-sWASM_ASYNC_COMPILATION=0` On Sat, Jun 1, 2024 at 7:07 PM キャロウ マーク wrote: > > > On Jun 1, 2024, at 17:40, キャロウ マーク wrote: > > > I’ve tried creating a .js file with the following and using it with >

Re: Dropping support for Ubuntu/Bionic by upgrading to nodejs v18

2024-05-28 Thread &#x27;Sam Clegg' via emscripten-discuss
since node has officially declined to continue to support older linux versions. cheers, sam On Tue, May 21, 2024 at 4:03 PM Sam Clegg wrote: > Hi all, > > In emsdk we currently support running on distributions as old as > Ubuntu/Bionic 18.04. However, we are attempting to upgra

Re: Embind 3.1.60 broke my binding.

2024-05-23 Thread &#x27;Sam Clegg' via emscripten-discuss
On Wed, May 22, 2024 at 10:03 PM キャロウ マーク wrote: > > > On May 22, 2024, at 23:47, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > > On Tue, May 21, 2024 at 11:30 PM キャロウ マーク wrote: > >> When on the verge of re

Re: Embind 3.1.60 broke my binding.

2024-05-22 Thread &#x27;Sam Clegg' via emscripten-discuss
On Tue, May 21, 2024 at 11:30 PM キャロウ マーク wrote: > When on the verge of releasing a major chunk of work, having a new version > of the compiler throw up 4 errors is extremely, extremely disappointing. > The disappointment is compounded by being unable to find any documentation > describing the ef

Dropping support for Ubuntu/Bionic by upgrading to nodejs v18

2024-05-21 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi all, In emsdk we currently support running on distributions as old as Ubuntu/Bionic 18.04. However, we are attempting to upgrade the version of node we ship/use from v16 to v18, Node dropped support for Ubuntu/Bionic with v18, so we are now proposing to do that same. See: https://github.com

Re: WASM memory access from JS

2024-05-21 Thread &#x27;Sam Clegg' via emscripten-discuss
On Tue, May 21, 2024 at 11:18 AM 'Felipe Gasper' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > > > > On May 21, 2024, at 1:52 PM, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > &

Re: WASM memory access from JS

2024-05-21 Thread &#x27;Sam Clegg' via emscripten-discuss
To access the wasmMemory from the outside you should be able to do `-sEXPORTED_RUNTIME_METHODS=wasmMemory` and then access it via `Module.wasmMemory`. You can also use the `.buffer` property of any of the HEAPXX exports if you export any of those? BTW, I'm curious about the "The safest approach i

Re: Question about source-map-base

2024-05-06 Thread &#x27;Sam Clegg' via emscripten-discuss
Seems like a bug related to absolute files paths in source maps, maybe specific to windows. Can you open a bug, ideally with a simple source map (smaller the better) attached? cheers, sam On Mon, May 6, 2024 at 6:49 AM 'Dieter Weidenbrück (dweidenbrueck)' via emscripten-discuss wrote: > Hi al

Is anyone using the Regal port?

2024-05-05 Thread &#x27;Sam Clegg' via emscripten-discuss
This project seems long dead so I am proposing that we remove the native emscripten port: https://github.com/emscripten-core/emscripten/pull/21893. Is anyone out there still using this and depending on the emscripten port? cheers, sam -- You received this message because you are subscribed to t

Re: PSA: Emscripten will no longer generate a separate worker.js file in pthreads mode.

2024-04-25 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Apr 25, 2024 at 12:14 PM Brooke Vibber wrote: > On Thu, Apr 25, 2024, 10:34 AM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> Glad you figured it out. We do have two other folks how are having >> si

Re: PSA: Emscripten will no longer generate a separate worker.js file in pthreads mode.

2024-04-25 Thread &#x27;Sam Clegg' via emscripten-discuss
through to the worker loader and it would just 404 out with a bad path. >> >> Once I get a chance to test in more detail it's probably something >> sensible, but it didn't work as just a drop-in upgrade vs 3.1.57. >> >> -- brooke >> >> On Tue, Apr 16

PSA: Emscripten will no longer generate a separate worker.js file in pthreads mode.

2024-04-16 Thread &#x27;Sam Clegg' via emscripten-discuss
;TLDR; If you build/deploy pthread-based programs you no longer need to worry about that extra `.worker.js` file. I'm hoping to land this change today which is fairly large internal change to the pthread workers are bootstapped: https://github.com/emscripten-core/emscripten/pull/21701 The main ex

Re: __main_argc_argv` called before runtime initialization

2024-04-16 Thread &#x27;Sam Clegg' via emscripten-discuss
aps?Do you hit that before the error you see? On Tue, Apr 16, 2024 at 2:02 AM キャロウ マーク wrote: > > > On Apr 16, 2024, at 12:39, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > > > Can you click on the little red arrow

Re: __main_argc_argv` called before runtime initialization

2024-04-15 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Apr 15, 2024 at 8:32 PM キャロウ マーク wrote: > > > > On Apr 16, 2024, at 5:15, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > > > > When you have the debugger attached and you hit that error/assertion, > wh

Re: __main_argc_argv` called before runtime initialization

2024-04-15 Thread &#x27;Sam Clegg' via emscripten-discuss
When you have the debugger attached and you hit that error/assertion, what does the stack trace look like? On Mon, Apr 15, 2024 at 1:00 PM Alon Zakai wrote: > That is very strange. Based on those link flags, you did not modify how > the application starts up, so I have no idea how it could break

[RFC] Changes to how "modularization" works in emscripten

2024-04-01 Thread &#x27;Sam Clegg' via emscripten-discuss
A few of us on the core emscripten team have been tossing around ideas about how to improve/modernize the modularization of emscripten-generated code. I've created a google doc with comments open to anyone. Please f

Re: glBufferSubData & sTRACE_WEBGL_CALLS

2024-02-21 Thread &#x27;Sam Clegg' via emscripten-discuss
Fix is up at https://github.com/emscripten-core/emscripten/pull/21389 On Wed, Feb 21, 2024 at 12:31 PM Sam Clegg wrote: > This looks like an issue with `hookGLFunction` in `library_webgl.js`. > Would you mind opening a bug? > > cheers, > sam > > On Wed, Feb 21, 202

Re: glBufferSubData & sTRACE_WEBGL_CALLS

2024-02-21 Thread &#x27;Sam Clegg' via emscripten-discuss
This looks like an issue with `hookGLFunction` in `library_webgl.js`. Would you mind opening a bug? cheers, sam On Wed, Feb 21, 2024 at 11:27 AM 'Dieter Weidenbrück (dweidenbrueck)' via emscripten-discuss wrote: > Hi, > > it looks like there may be an issue with glBufferSubData tracing. > Take

Re: emscripten_GetProcAddress undefined

2023-12-18 Thread &#x27;Sam Clegg' via emscripten-discuss
IIRC the logic for remove this support by default is layed out in the PR description for https://github.com/emscripten-core/emscripten/pull/20802. ;TLDR; Since some 6 years apo, our best practices document has advocated users against using *glGetProcAddress() functions when targeting the web: http

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

2023-11-29 Thread &#x27;Sam Clegg' via emscripten-discuss
I'm considering removing the public facing `-sSHARED_MEMORY` flag: https://github.com/emscripten-core/emscripten/issues/20803 The upshot would be that users who want shared memory would need to choose to use either wasm workers or pthreads. The use cases for shared memory but without either w

Increasing the minimum supported node version to v16.20

2023-10-27 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi all, I'm in the process of bumping the minimum supported node version for the emscripten compiler. This means anyone wanting to run the compiler itself would need to have at least node v16.20 installed. See https://github.com/emscripten-core/emscripten/pull/20551. Note that this matches the

Re: Python to wasm conversion

2023-10-23 Thread &#x27;Sam Clegg' via emscripten-discuss
There may be tools out there that can directly convert python to wasm but I don't know of them, and emscripten certainly cannot do that. If you want to run python code on a WebAssembly VM you can use Pyodide, which is essentially CPython compiled using emscripten. If you are having trouble buildi

Re: Header files not found : error thrown by emscripten

2023-10-23 Thread &#x27;Sam Clegg' via emscripten-discuss
Can you share the specific errors you are seeing? In general emscripten supports all/most POSIX headers but does *not* support linux-specific headers. i.e. if your library compiles on macOS and linux it should also compile with emscripten. cheers, sam On Fri, Oct 20, 2023 at 8:44 AM MONISHA wr

Re: New top level `bootstrap` script for emscripten developers (git users)

2023-10-19 Thread &#x27;Sam Clegg' via emscripten-discuss
t; for that to run the bootstrap as well) > > On Tue, Oct 10, 2023 at 8:44 PM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> If you work on emscripten, or use emscripten via a git checkout, we now >> have a new `boo

New top level `bootstrap` script for emscripten developers (git users)

2023-10-10 Thread &#x27;Sam Clegg' via emscripten-discuss
If you work on emscripten, or use emscripten via a git checkout, we now have a new `bootstrap` script at the top level which performs various post-checkout tasks. https://github.com/emscripten-core/emscripten/pull/19736 It doesn't do too much today but I hope to extend it in the future. If you

New `--start-at` flag to test runner to complement the existing `--failfast`

2023-10-06 Thread &#x27;Sam Clegg' via emscripten-discuss
If you work on emscripten and you are trying to find and fix all failing tests related to your current branch, these two flags can be useful together: 1. Run the test suite with `--failfast -j1`. This will run the whole suite one test at a time. 2. When the first failure occurs you can stop and f

emsdk downloads switching from bz2 to xz compression

2023-09-21 Thread &#x27;Sam Clegg' via emscripten-discuss
This change affects macOS and Linux users of emsdk. Windows users will continue to download zip archives. Making this switch reduces download times and massively speeds up extraction times. Hopefully this change will be completely transparent to most folks but we thought it worth mentioning here

Re: Pthread.init question

2023-09-15 Thread &#x27;Sam Clegg' via emscripten-discuss
Looks like a bug. Would you mind opening an issue on the emscripten tracker? I don't think we do a lot of testing with wasm workers and pthreads combined like that so it's perhaps not surprising. cheers, sam On Fri, Sep 15, 2023 at 4:19 AM 'Dieter Weidenbrück (dweidenbrueck)' via emscripten-di

Re: INCOMING_MODULE_JS_API and PThread.*

2023-09-08 Thread &#x27;Sam Clegg' via emscripten-discuss
The `INCOMING_MODULE_JS_API` setting is designed to properties that you set on the module before its started. Its not for exporting things. That is what the `-sEXPORTED_FUNCTIONS` settings is for. So you can do `-sEXPORTED_FUNCTIONS=$Pthread` but the members of that object will still be mangled

Re: A call to std::rethrow_exception prints Abort() error

2023-08-22 Thread &#x27;Sam Clegg' via emscripten-discuss
On Tue, Aug 22, 2023 at 1:56 AM 'Mike Lischke' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > > Taking a quick look at rethrow_exception, it looks like it calls > `terminate` if the `ptr` is NULL: > > > https://github.com/emscripten-core/emscripten/blob/097290ded2746c6ba703

Re: A call to std::rethrow_exception prints Abort() error

2023-08-21 Thread &#x27;Sam Clegg' via emscripten-discuss
Taking a quick look at rethrow_exception, it looks like it calls `terminate` if the `ptr` is NULL: https://github.com/emscripten-core/emscripten/blob/097290ded2746c6ba703d556fd53b23e5aef760a/system/lib/libcxx/src/support/runtime/exception_pointer_cxxabi.ipp#L66-L71 Can you trace the value of the

Re: A call to std::rethrow_exception prints Abort() error

2023-08-20 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi Mike, Can you share the link flags you are are using for your project?We know this works in at least some cases because we have a test for it: See: https://github.com/emscripten-core/emscripten/blob/main/test/core/test_exceptions_primary.cpp and: https://github.com/emscripten-core/emscr

Re: Multiple inheritance

2023-08-14 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Aug 14, 2023 at 2:40 AM 'Mike Lischke' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > One possible workaround is to use the derived class in the bindings, where > one of its base classes is required. That even works without changing the > underlying C++ library code

Re: Strategies to debug memory alignment issues

2023-08-11 Thread &#x27;Sam Clegg' via emscripten-discuss
On Fri, Aug 11, 2023 at 2:19 AM 'Mike Lischke' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > > How did the issue present itself before you enabled UBSAN? (Are you sure > its the same issue?) > > > It's pretty much the same: > > RuntimeError: memory access out of bounds >

Re: Strategies to debug memory alignment issues

2023-08-10 Thread &#x27;Sam Clegg' via emscripten-discuss
How did the issue present itself before you enabled UBSAN? (Are you sure its the same issue?) Is there some way you could make/share a minimal repro case? cheers, sam On Wed, Aug 9, 2023 at 7:13 AM 'Mike Lischke' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > Hi all,

Re: How does using malloc, then memory growth work?

2023-08-07 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Aug 7, 2023 at 7:52 AM 'Michael Hagar' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > It's mentioned in the docs here: > https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=memory_growth#access-memory-from-javascrip

Re: PROXY_TO_THREAD question

2023-07-31 Thread &#x27;Sam Clegg' via emscripten-discuss
On Sun, Jul 30, 2023 at 1:55 PM 'Dieter Weidenbrück' via emscripten-discuss wrote: > Thanks, Sam. > So PROXY_TO_PTHREAD makes sense only if I run some kind of loop inside > main rather than waiting for events from the JS Side. > Yes, this option is mostly designed for the case where you have a l

Re: PROXY_TO_THREAD question

2023-07-30 Thread &#x27;Sam Clegg' via emscripten-discuss
This is the expected behaviour of `-sPROXY_TO_PTHREAD`. All this option does is proxy the main entry point of your program (main). Any other events that arrive on the main thread (e.g. DOM events) would be run the main browser thread unless you proxy them over to another thread yourself. cheer

Re: https requests from within a wasm compiled code

2023-07-30 Thread &#x27;Sam Clegg' via emscripten-discuss
This is possible with emscipten by calling out to JS to do that actual network requests. Emscriptan has a couple of different builtin APIs for this (see fetch.h and wget.h which are documented https://emscripten.org/docs/api_reference/fetch.html and https://emscripten.org/docs/api_reference/emscr

Re: Error compilinig project depending on protobuf

2023-07-25 Thread &#x27;Sam Clegg' via emscripten-discuss
I believe `protoc` is a program that runs on your host machine for compiling `.proto` files into `.cc` files.When cross compiling (as with emscripten) you need to ensure that that program is built using the host compiler and not that target compiler. I'm not sure how well protobuf is setup fo

Re: Wasm crashing on iPhone

2023-07-25 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Jul 24, 2023 at 1:52 AM Ulhas Pawar wrote: > Hello All! > I am using Emscripten to build Wasm for my application. > I am facing weird issue on iPhones where wasm crashes. Post crash, > browser tab is reloaded. > > My current setup is on 2.0.15. > Is there some reason you are using this o

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

2023-07-07 Thread &#x27;Sam Clegg' via emscripten-discuss
Yes, those methods are only used/needed/present when growable memory is combined with threads. What is more, you should not normally need to use them directly since emscripten should automatically convert all your heap accesses. This is done using the `growableHeap` in `tools/acorn-optimizer.js`.

Re: emcmake find_library MATH

2023-07-05 Thread &#x27;Sam Clegg' via emscripten-discuss
Emscripten uses musl libc, which doesn't have a separate math library (its just part of `-lc`).I'm not sure setting `MATH` to `NOTFOUND` is the desired behaviour in this case but it seems reasonable.What happens if you try building your project on a musl-based linux distro such as alpine li

Re: Emscripten exe data size?

2023-06-29 Thread &#x27;Sam Clegg' via emscripten-discuss
If you want a static region of memory that you can use for your own purposes, one way to achieve that would be to build with `-sGLOBAL_BASE=10mb` .. that will offset the emscripten stack and heap leaving you the first 10mb of memory to do with what you will. BTW, you might want to check out the wa

Re: Emscripten Architecture for emitting Wasm

2023-06-27 Thread &#x27;Sam Clegg' via emscripten-discuss
On Tue, Jun 27, 2023 at 9:55 AM René N. wrote: > Kind of. In the first diagram I tried to show what happens in "Clang+LLVM" > which is shown in the *first box* (named "Clang+LLVM") in the second > diagram. Does it show something incorrectly? That sounds right, yes. That is what I meant by "I a

Re: Emscripten Architecture for emitting Wasm

2023-06-26 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Jun 26, 2023 at 5:05 AM René N. wrote: > Hi Sam, > please excuse my late response. Thank you for all your answers! This > helped me so much. > > From all those information you gave me, I tried to make a diagram to > summarize the process of Emscripten while creating C->Wasm. See the pictu

Re: Clang driver: can target wasm32 but can’t look up symbols?

2023-06-08 Thread &#x27;Sam Clegg' via emscripten-discuss
When you build for non-wasm platforms are you JIT'ing non-wasm code? This looks like a codegen issue that only affects the wasm backend. The error in question occurs if a code section contains more than one function symbol. In the wasm backend we expect every function to get its own section (i.

Re: SDL1 and SDL2

2023-06-07 Thread &#x27;Sam Clegg' via emscripten-discuss
ng SDL1. But removing it simply because it uses the existing API seems wrong. As it stands it is providing us with a good test case for the type of FS API usage that might be out in the wild and its actually useful to wasmfs development to have that. > - Alon > > > On Wed

Re: SDL1 and SDL2

2023-06-07 Thread &#x27;Sam Clegg' via emscripten-discuss
x27;m not sure we have a good reason to in this case. It doesn't cost us much to maintain does it? > > - Alon > > > On Wed, Jun 7, 2023 at 9:16 AM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> >>

Re: SDL1 and SDL2

2023-06-07 Thread &#x27;Sam Clegg' via emscripten-discuss
On Wed, Jun 7, 2023 at 5:36 AM Floh wrote: > I wonder whether most of those old "portability wrappers" shouldn't be > deprecated tbh (SDL2 might be special because it has "official" upstream > support now?). > > Those wrappers were very helpful in the beginning to get things started, > but for in

Re: Emscripten Architecture for emitting Wasm

2023-06-04 Thread &#x27;Sam Clegg' via emscripten-discuss
On Fri, Jun 2, 2023 at 11:40 PM René N. wrote: > Thank you for answering Sam! Very glad to get a feedback this quick. > > So if I understand it correctly, emcc is doing the whole C -> Wasm Binary > since it's the driver of the whole toolchain, right? > I think I am irritated because emcc is calle

Re: Segmentation faults in wasm workers

2023-06-04 Thread &#x27;Sam Clegg' via emscripten-discuss
On Sat, Jun 3, 2023 at 9:11 AM 'Dieter Weidenbrück' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > All, > I think I have found the problem and a workaround. First, I got everything > working using pthreads without problems. However, I wasn't too impressed > with the time sa

Re: Emscripten Architecture for emitting Wasm

2023-06-02 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi René, Great questions. It sounds like you have a pretty good understanding of the various phases. I will reiterate your list, filling in a few details for you. At the high level emcc is the compiler driver, rather than the compiler itself. gcc and clang both take this roll too, and under t

Re: Segmentation faults in wasm workers

2023-05-30 Thread &#x27;Sam Clegg' via emscripten-discuss
e alignment as well, to use that as a heuristic to figure out if >>>>> the ptr was stomped on and was garbled. >>>>> >>>>> The wasm-based SAFE_HEAP feature does not provide any of above, but >>>>> only prints that "Aborted(segmentatio

Re: how to use the lib based fortran in c++?

2023-05-30 Thread &#x27;Sam Clegg' via emscripten-discuss
On Sun, May 28, 2023 at 4:53 AM hannong cheng wrote: > > wasm-ld: error: unknown file type: /usr/local/lib/libmylapack.a(dgeev.o) > It's likely that the entire /usr/local/lib/libmylapack.a library is built for the host system and therefore cannot be linked into a wasm binary. You would need to

Re: I can compile C++ to .so , but cannot compile it to wasm

2023-05-26 Thread &#x27;Sam Clegg' via emscripten-discuss
On Fri, May 26, 2023 at 3:19 PM hannong cheng wrote: > -->Is the source file you are compiling particularly large? > thanks, Yes, it is about 3.3MB. and about 110,000 lines, mainly produced > by another tool. and it only computes and output the results without any > display function > It sounds

Re: Segmentation faults in wasm workers

2023-05-26 Thread &#x27;Sam Clegg' via emscripten-discuss
Can I ask why you chose not to use pthreads to start with? I'd like to understand better why folks would choose wasm workers over pthreads. On Fri, May 26, 2023 at 3:25 AM 'Dieter Weidenbrück' via emscripten-discuss wrote: > Hi Sam, > IIRC, when I started with Emscripten a while ago the program

Re: Segmentation faults in wasm workers

2023-05-25 Thread &#x27;Sam Clegg' via emscripten-discuss
Is there some reason you added `-sABORTING_MALLOC=0`.. that looks a little suspicious, since it means the program can continue after malloc fails.. which mean that any callsite that doesn't check the return value of malloc can lead to segfaults. If you remove that setting does the behaviour chang

Re: Segmentation faults in wasm workers

2023-05-25 Thread &#x27;Sam Clegg' via emscripten-discuss
Firstly, if you are allocating 1.8Gb you are likely pushing up against browser limits. Are you specifying a MAXIMUM_MEMORY of larger than 2GB? Secondly, it looks like you are using wasm workers, which are still relatively new. Do you have a version of your code that uses pthreads instead? It mi

Re: I can compile C++ to .so , but cannot compile it to wasm

2023-05-23 Thread &#x27;Sam Clegg' via emscripten-discuss
It looks like the compiler process was killed via SIGKILL. Any idea why that might be? This can happen if some external process kills the compiler or, if think, if the kernel runs out of memory. Is the source file you are compiling particularly large? cheers, sam On Tue, May 23, 2023 at 7:12

Re: Emscripten getting element points (?) into C++.

2023-05-13 Thread &#x27;Sam Clegg' via emscripten-discuss
The main thing to remember in this kind of endeavor is that C++ code can only reason about numeric types. So whenever you are detailing with JS object, such as DOM elements, you need to refer to them via some kind of index in the table that your (or somebody) maintains on the JS side. Direct DOM a

Re: Emscripten getting element points (?) into C++.

2023-05-12 Thread &#x27;Sam Clegg' via emscripten-discuss
Your code looks like it will correctly create the element but you cannot return a JS object to native code like that. You can only return basic types like numbers unless you use some kind of higher level binding system such as embind. See https://emscripten.org/docs/porting/connecting_cpp_and_jav

Re: Bump default minimum node version for generated code?

2023-04-18 Thread &#x27;Sam Clegg' via emscripten-discuss
Note that there are three distinct node versions at play in the emscripten world. One has already been bumped. and one we plan to bump, and one we don't have plans to change. 1. Min version required to run output code (this is only the default can can be lowered via setting): 10.19.0 -> 15.

Re: Asm.js or Javascript source output

2023-03-27 Thread &#x27;Sam Clegg' via emscripten-discuss
Yes, that is correct. `-sWASM=0` is the setting that disables WebAssembly output and gives you pure JavaScript. As Shlomi says, its no longer pure asm.js, just normal JavaScript. However, that shouldn't matter because legacy browsers/runtimes that don't support wasm most likely don't support the

Re: Support for externref

2023-03-24 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Mar 23, 2023 at 6:50 PM Thaina Yu wrote: > I am not sure how limited it is but there are many situation that we just > need a value to pass object from one function to another immediately in the > same flow > > By the way, which the handle would be returned as EM_ASM_INT or EM_ASM_PTR > ?

Re: Support for externref

2023-03-23 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Mar 23, 2023 at 10:12 AM Thaina Yu wrote: > I don't actually know which things unity would use to hold the value of > externref, just guessing it would be IntPtr. But by anything it require > that emscripten can officially define externref first anyway > The problem is that externref can

Re: Support for externref

2023-03-23 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Mar 23, 2023 at 9:51 AM Thaina Yu wrote: > I am actually using emscripten from unity and I mainly use C# code from > unity side. But there are tons of 3rd party library and SDK that written > with assumption that we will only use JavaScript. It then need us to > construct javascript objec

Re: Support for externref

2023-03-23 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Mar 23, 2023 at 9:20 AM Thaina Yu wrote: > Thank you very much. Are there any public discussion or roadmap to > add EM_ASM_REF into emscripten? > You are the first person that I know of to suggest it. Be aware that using externref directly in C/C++ is very limited, even after the recent

Re: Support for externref

2023-03-23 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Mar 23, 2023 at 6:52 AM Thaina Yu wrote: > Do we have anyway to write hand-written assembly code along with > emscripten? And is it possible to return that externref from wasm code into > emscripten world? Here is the example how to use externref in assembly: https://github.com/emscript

Re: Doesn't compile after updating to 3.1.31

2023-02-22 Thread &#x27;Sam Clegg' via emscripten-discuss
++2a and it worked. Now I have >> to make a CMake for this and it worked with the mentioned compiler but the >> 3.1.31 it's not.. >> >> 'Sam Clegg' via emscripten-discuss >> ezt írta (időpont: 2023. febr. 10., P, 17:18): >> >>> >>>

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

2023-02-15 Thread &#x27;Sam Clegg' via emscripten-discuss
On Wed, Feb 15, 2023 at 2:16 PM Tudor Bosman wrote: > Yes, I am interested in running this, we are embedding V8 to run plain JS > already. I'm planning to test using d8 and then port the d8 API into our > embedder. If you are already embedding v8 then I don't see that there is anything you shou

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

2023-02-15 Thread &#x27;Sam Clegg' via emscripten-discuss
Are you interested in running the generated wasm and JS code, or just the wasm code (in something like STANDALONE_WASM mode)? There are various options, but by far simplest is probably to use d8 (the v8 command line tool normally used for testing).The easiest way to install it is via jsvu: htt

Re: Combining wasms

2023-02-13 Thread &#x27;Sam Clegg' via emscripten-discuss
On Mon, Feb 13, 2023 at 9:53 PM craste...@gmail.com wrote: > That is unfortunate. I suppose I could do something like this: (since I > build the thirdparty wasm with their included build script) > > - setup my bar build script to just output bar.o instead of bar.wasm. > - change/edit their "foo"

Re: Doesn't compile after updating to 3.1.31

2023-02-10 Thread &#x27;Sam Clegg' via emscripten-discuss
try going back to your working configuration and adding a #error to `fallback_impl.hpp`)? I imagine some kind of change to libc++ could have triggered this but there is probably some local change to your project that will fix it. 'Sam Clegg' via emscripten-discuss > ezt írta (időpo

Re: How to reinit wasm?

2023-02-09 Thread &#x27;Sam Clegg' via emscripten-discuss
t solution, but should work. > > Kind regards, > Ilya Kantor > > On 9 Feb 2023, at 20:30, 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > > Hi Ilya, > > Emscripten doesn't have any way to do that today (at least not

Re: Async calls - what is the "main thread"?

2023-02-09 Thread &#x27;Sam Clegg' via emscripten-discuss
ssible to do though, and its up to you to split up your main loop. This is true both with and without threads. There is more information on this here: https://emscripten.org/docs/porting/emscripten-runtime-environment.html#browser-main-loop > > Kind regards, > Ilya Kantor > > On

Re: Async calls - what is the "main thread"?

2023-02-09 Thread &#x27;Sam Clegg' via emscripten-discuss
The term "main thread" can be ambiguous and confusing I'm afraid. In emscripten we disambiguate we have two concepts of `main` thread. 1. The main *browser* thread (i.e. not a worker) 2. The main emscripten *runtime* thread (the thread where the emscripten module get first loaded). Normally on t

Re: How to reinit wasm?

2023-02-09 Thread &#x27;Sam Clegg' via emscripten-discuss
Hi Ilya, Emscripten doesn't have any way to do that today (at least not that I know of). Your best bet is probably to use `-sMODULARIZE` and then construct a new instance for each time you want to call `main`. i.e `new MyModule()` each time. cheers, sam On Thu, Feb 9, 2023 at 11:18 AM Ilya Ka

Re: Doesn't compile after updating to 3.1.31

2023-02-09 Thread &#x27;Sam Clegg' via emscripten-discuss
On Thu, Feb 9, 2023 at 7:27 AM Tibor Kovács wrote: > Hi all, > > I have several problems with the 3.1.31 compiler. I made a CMake for a > project and with the 3.1.13 it compiled properly. Now I updated to 3.1.31 > and it doesn't work anymore. I try to compile it in Debug mode with the > next DEBU

Re: Wasm Snapshot really works, reducing startup time by 20-50%

2023-01-29 Thread &#x27;Sam Clegg' via emscripten-discuss
On Sat, Jan 28, 2023 at 11:43 PM Damon Lei wrote: > Hi, > We tested the WasmSnapshot solution in the production environment. > 1. Tested with more than 500,000 users, no user feedback has been found so > far > 2. It takes 2 seconds to optimize the startup time. Before optimization, > the game sta

Re: [threading] variable has incomplete type 'em_queued_call' (aka 'struct em_queued_call')

2023-01-23 Thread &#x27;Sam Clegg' via emscripten-discuss
I think the solution is to use the `emscripten_sync_run_in_main_runtime_thread` family of functions. I've opened a PR to remove the (as you point out, currently unusable/broken) `emscripten_sync_run_in_main_thread` family. On Mon, Jan 23, 2023 at 8:14 AM 'Thomas Lively' via emscripten-discuss < e

  1   2   3   4   5   >