Re: .tmp0 output file

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

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

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

OK, this change is happening now. The emsdk version of node has been updated from v16 to v18. If you see an that look like `node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)`, that means the version of linux you are running on is no longer supported by

Re: Embind 3.1.60 broke my binding.

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 releasing a

Re: Embind 3.1.60 broke my binding.

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

Dropping support for Ubuntu/Bionic by upgrading to nodejs v18

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:

Re: WASM memory access from JS

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: > > > > To acc

Re: WASM memory access from JS

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

Re: Question about source-map-base

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

Is anyone using the Regal port?

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

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

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 >> similar issu

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

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, 2024 at 12:36 PM 'Sam Clegg' via em

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

;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

Re: __main_argc_argv` called before runtime initialization

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 next to th

Re: __main_argc_argv` called before runtime initialization

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

Re: __main_argc_argv` called before runtime initialization

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

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

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

Re: glBufferSubData & sTRACE_WEBGL_CALLS

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, 2024 at 11:27 AM 'Dieter

Re: glBufferSubData & sTRACE_WEBGL_CALLS

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

Re: emscripten_GetProcAddress undefined

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:

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

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

Increasing the minimum supported node version to v16.20

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

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

Re: Header files not found : error thrown by emscripten

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

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

e good > 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 `bootstrap` script

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

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`

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

emsdk downloads switching from bz2 to xz compression

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

Re: Pthread.init question

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

Re: INCOMING_MODULE_JS_API and PThread.*

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

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

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

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

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

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:

Re: Multiple inheritance

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

Re: Strategies to debug memory alignment issues

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

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

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

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

Re: PROXY_TO_THREAD question

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

Re: PROXY_TO_THREAD question

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.

Re: https requests from within a wasm compiled code

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

Re: Error compilinig project depending on protobuf

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

Re: Wasm crashing on iPhone

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

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

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

Re: emcmake find_library MATH

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

Re: Emscripten exe data size?

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

Re: Emscripten Architecture for emitting Wasm

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

Re: Emscripten Architecture for emitting Wasm

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

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

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

Re: SDL1 and SDL2

cause 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, Jun 7, 2023 at 12:41 PM 'Sam Cleg

Re: SDL1 and SDL2

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

Re: SDL1 and SDL2

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

Re: Emscripten Architecture for emitting Wasm

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

Re: Segmentation faults in wasm workers

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

Re: Emscripten Architecture for emitting Wasm

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

Re: Segmentation faults in wasm workers

l, 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(segmentation fault)". >>&

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

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

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

Re: Segmentation faults in wasm workers

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

Re: Segmentation faults in wasm workers

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

Re: Segmentation faults in wasm workers

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

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

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

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

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

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

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

Re: Bump default minimum node version for generated code?

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

Re: Asm.js or Javascript source output

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

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

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

Re: Support for externref

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

Re: Support for externref

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

Re: Support for externref

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:

Re: Doesn't compile after updating to 3.1.31

t 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): >> >>> >>> >>> On Fri, Feb

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

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

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

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:

Re: Combining wasms

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

Re: Doesn't compile after updating to 3.1.31

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őpont: 2023. febr. 9., Cs, 18:31): > >> >> >>

Re: How to reinit wasm?

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 that I know > of). > &g

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

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 9 Feb 202

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

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

Re: How to reinit wasm?

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

Re: Doesn't compile after updating to 3.1.31

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

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

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

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

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 <

Re: Linux aarch64 binaries for SDK lag several versions behind

On Wed, Jan 18, 2023 at 7:14 PM Brion Vibber wrote: > On Tue, Jan 17, 2023 at 2:48 PM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> >>> The build script that build all the pre-built binaries is here: >>> https

Re: WGPU_WHOLE_SIZE warning

It looks like WGPU_WHOLE_SIZE is designed to be used WGPUBindGroupEntry where size is 64-bit, but wgpuBufferMapAsync uses size_t for size (which is either 32-bit ot 64-bit depending on the architecture). I'm not sure if this is intended behaviour or not. Perhaps its a bug? cc'ing Kai who will

Re: WGPU_WHOLE_SIZE warning

Can you share the full warning message (I only see the "note" part)? And the context in which you are using the macro? cheers, sam On Wed, Jan 18, 2023 at 12:48 PM Mark Sibly wrote: > Hi, > > I'm getting the following warning when building an emscripten project that > uses webgpu: > >

Re: Linux aarch64 binaries for SDK lag several versions behind

On Tue, Jan 17, 2023 at 2:38 PM Brion Vibber wrote: > On Tue, Jan 17, 2023 at 2:21 PM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> The main builder run on chromium infrastructure here: >> https://ci.chromium.org/p/emscrip

Re: Linux aarch64 binaries for SDK lag several versions behind

On Tue, Jan 17, 2023 at 2:08 PM Brion Vibber wrote: > On Tue, Jan 17, 2023 at 1:49 PM 'Sam Clegg' via emscripten-discuss < > emscripten-discuss@googlegroups.com> wrote: > >> Thinking about this just now I did think of one way to take myself out of >> the loop each u

Re: Linux aarch64 binaries for SDK lag several versions behind

Thinking about this just now I did think of one way to take myself out of the loop each update: We could have emsdk point directly at amazon S3 bucket for the arm64 binaries.. then it would just be a question of someone creating a PR to emsdk for each release (any interested party such as

Re: Linux aarch64 binaries for SDK lag several versions behind

I agree it would be nice to make this more automatic but we haven't found an easy way to do this yet. Currently the process is that the arm64 binaries get built somewhere in the amazon cloud (thanks Michael for setting this up) and then that sends an email to me when it's done. I then have to

Re: Wasm with GLFW + OpenGL

On Mon, Jan 16, 2023 at 7:42 AM Ulhas Pawar wrote: > Hello, > Need your help understaning how JS code is generated. > > In my project, I am using Emscripten to generate WASM. For window > management, I amny way I can get rid of this code? Some compilation options > using GLFW window. Application

Re: Debugging "Pthread <...> completed its main entry point with an `unwind`"

This isn't an error per-say, and so perhaps we shouldn't be reporting it outside of debug builds. All it means is that your thread unwound its stack with the runtime still alive. This can happen if you call `exit_with_live_runtime`, or if you schedule some async work using asyncify. Are you

Re: SQL

On Fri, Jan 6, 2023 at 7:47 AM Алексей Снегирёв wrote: > Hello I am learning web assembly and want to create and setup a database. > Could you please advise me a good tutorial about this and what base to use. > I am going to use sqLight3. I want to store strings and images in a > database.

Re: Misc compiler/threading questions

On Wed, Dec 28, 2022 at 12:20 AM Mark Sibly wrote: > Hi, > > I'm writing a little compiler that targets webassembly, but there are a > few things I don't quite understand that someone can hopefully help me with: > > * Is it true that wasm 'globals' are automatically 'thread local'? This > seems

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

Hi Damon This sounds really great. When you say "Wasm Snapshot" are you talking about some tool that you wrote yourself or some existing tool such as wizer? Would you be interested in contributing this tool to emscripten, or perhaps some documentation on how to go about doing this? cheers, sam

Re: Accessing external JS code from WASM

Is JsCheatPanel the name of the `--js-library` function? And is JsLibCheatPanel the name of the external JS function? Have you loaded `JsLibCheatPanel` in the global scope somehow? If you are using devtools can you see if `JsLibCheatPanel` exists? If not, you need to arrange for that library

Re: Storing WASM system state

at 1:58 PM Steve Dekorte wrote: > > For my use case, I only want to use HTML/JS to start WASM and hand it a > canvas and events. Things like i/o contexts would have to be reconstructed > if possible. Is there anything else? > > On Dec 17, 2022, at 1:40 PM, 'Sam Clegg' via

Re: Storing WASM system state

Neat! That might work for the linear memory, but as I said in an earlier reply there is more to the state of a running module than just its memory. On Sat, Dec 17, 2022 at 10:40 AM Steve Dekorte wrote: > > Just for fun, I tried asking ChatGPT: > > [[Please write some Javascript code which

Re: Storing WASM system state

On Fri, Dec 16, 2022 at 1:29 PM Steve Dekorte wrote: > > I've ported an interpreter for scripting language to WASM using emscripten > and gotten a REPL working for it in a web page. I'm interested in the > possibility of making a Smalltalk/LISP like development environment with > it. There would

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

On Fri, Dec 16, 2022 at 1:21 AM Gregory Propf wrote: > I just checked with version 3.1.28 and there's no 'this' pointer there > either. I also tried 3.1.25 and it looks like 24 --> 25 is the point where > the pointer died so to speak. So right now, 3.1.24 is the latest I can use. > I'm using

Re: Reducing the default stack size in emscripten

On Fri, Dec 16, 2022 at 2:46 PM Steve Dekorte wrote: > > How about adding an API like: > > Emscripten_extendStackIfNeeded(callback), which could be inserted anywhere > stack depth might be an issue and would launch another coroutine if the > stack was almost used up, swap to it, and swap back on

  1   2   3   4   5   >