LLTP, but VSCode now has WASM DWARF debugging support, and I just confirmed
that it works for Emscripten's node.js output.
First install this VSCode extension:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging
...then...
emcc hello.c -o hello.js -g
...open
Are you suggesting that we could somehow use upstream GLFW? That seems
unlikely since GLFW interacts so closely with input events and the
display.. it seems like we would need a specific emscripten of that
library. Or are you suggesting we invest in a port to emscripten in the
upststram
I wonder whether most of those old "portability wrappers" shouldn't be
deprecated tbh (SDL2 might be special because it has "official" upstream
support now?).
Those wrappers were very helpful in the beginning to get things started,
but for instance (as far as I noticed) Dear ImGui was running
Probably for esoteric reasons where no actual 'runtime dereference'
happens, like sizeof(*p).
Apparently, the size of void is 1 :)
https://www.godbolt.org/z/nWdo9YxTf
On Tuesday, 30 May 2023 at 18:24:43 UTC+2 Steven Johnson wrote:
> ...how was that ever legal (or useful) in the first place?
>
My guess is that websocket_client_sync_ssl.cpp is implementing a websocket
client on top of 'raw' SSL and TCP (which is what's needed to talk to a
websocket server from a native application, but is pointless in the
browser).
Browsers already contain such a websocket client in form of the
respect Alon and the whole Emscripten team
for paying proper attention to such "unimportant details"!
Cheers!
-Floh.
On Monday, 27 February 2023 at 03:46:15 UTC+1 mark...@gmail.com wrote:
> Hi,
>
> You haven't mentioned what you actually want to achieve in emscripten so
> i
How likely is it even to succeed with building and running libcurl for a
WASM target? Has anything substantially changed since this ticket was
written: https://github.com/emscripten-core/emscripten/issues/4642?
...e.g. AFAIK libcurl largely depends on native APIs that are either not
available
ah nvm, I should read the whole thread carefully before responding :D
On Friday, 20 January 2023 at 10:15:15 UTC+1 Floh wrote:
> Clang and GCC have a builtin __SIZE_MAX__ macro which resolves to 32-bit
> or 64-bit ~0. MSVC doesn't though.
>
> But maybe this would make sense?
>
Clang and GCC have a builtin __SIZE_MAX__ macro which resolves to 32-bit or
64-bit ~0. MSVC doesn't though.
But maybe this would make sense?
#if defined(__SIZE_MAX__)
#define WGPU_WHOLE_SIZE (__SIZE_MAX__)
#else
...
#endif
On Friday, 20 January 2023 at 02:12:27 UTC+1 kai...@google.com wrote:
>
ng
> is that setting the reservation to e.g. a hundred megabytes of address
> range should be possible, and it is only committed over if any local stack
> frame actually needs it.
>
> On Wed, Jan 18, 2023 at 1:02 PM Floh wrote:
>
>> > Most native OSes auto-grow the stack in n
> Most native OSes auto-grow the stack in native code.
AFAIK "most" excludes Windows though right? As far as I remember Windows
gives me a hard crash if I'm overflowing the stack size determined in the
linker invocation.
On Tuesday, 17 January 2023 at 12:13:25 UTC+1 jj wrote:
> Most native
PPS: closure linker setting is actually "--closure 1".
On Wednesday, 18 January 2023 at 11:40:34 UTC+1 Floh wrote:
> PS: if you don't allocate/free with very high frequency, also consider
> switching to the minimal Emscripten allocator with "-s MALLOC='emmalloc'"
&g
PS: if you don't allocate/free with very high frequency, also consider
switching to the minimal Emscripten allocator with "-s MALLOC='emmalloc'"
On Wednesday, 18 January 2023 at 11:36:26 UTC+1 Floh wrote:
> Are you building will all optimization options turned to 11? Usually
Are you building will all optimization options turned to 11? Usually
Emscripten is very good at aggressive dead code elimination, both on the
WASM and JS side. Some things to check in the build settings to minimize
build size (I'm not 100% sure how many of those are still needed versus
having
Aplologies for the drive-by comment, I don't have a solution for the
exception handling question, but that error message caught my eye. If
you're already on emsdk 3.1.27 (with the default stack size reduced to 64
KBytes) you would get that exact same error in debug mode when a stack
overflow
7 PM Sam Clegg wrote:
>>
>>> emscripten_stack_get_current is also designed to be super fast (its
>>> basically just a single `global.get` instruction).
>>>
>>> On Wed, Oct 12, 2022 at 6:26 PM Sam Clegg wrote:
>>>
>>>>
>>
If you are using cmake to setup your build then it works like on any other
platform, for instance to declare a static link library:
https://github.com/floooh/cimgui-sokol-starterkit/blob/d87dfedb9c70958983c1c66e470757f796f183b0/CMakeLists.txt#L12-L21
...and then to link this library to an
weird for somebody reading the code, but works for me :)
On Wednesday, 19 October 2022 at 12:43:58 UTC+2 Floh wrote:
> Hrmpf, I feel that I'm very close to the solution by formatting the
> Closure hints like this:
>
> \x2F\x2A\x2A @suppress {missingProperties} \x2A\x2F
>
> ...which sn
a bit with this, but not a big deal if I can't find a solution.
On Wednesday, 19 October 2022 at 12:27:55 UTC+2 Floh wrote:
> Hmm... but this would not work inside EM_JS() right? Because the C
> preprocessor already removes the comments before Closure even sees the code?
>
> I've tried all sorts of
'
warnings in the C compiler, and then still didn't arrive at the Closure
compiler :)
On Wednesday, 19 October 2022 at 00:51:10 UTC+2 s...@google.com wrote:
> On Tue, Oct 18, 2022 at 2:00 AM Floh wrote:
>
>> Enabling -Wclosure as part of -Wall, and using -Wno-closure to suppress
>&
. But this isn't important enough to justify an awkward
workaround in Emscripten...
I think I will keep the closure warnings actived when compiling in debug
mode, but for release mode, use -Wno-closure to suppress them.
Cheers!
-Floh.
On Monday, 17 October 2022 at 19:11:56 UTC+2 s...@google.com wrote
PS: I forgot an
"But this doesn't work"
after
I googled around and found out that Closure takes type hints like this:
var u8_array = new Uint8Array(/** @type {!ArrayBuffer} */(req.response));
:)
On Saturday, 15 October 2022 at 18:28:20 UTC+2 Floh wrote:
> I'm getting a l
);
I googled around and found out that Closure takes type hints like this:
var u8_array = new Uint8Array(/** @type {!ArrayBuffer} */(req.response));
Any ideas how to best deal with this?
Cheers,
-Floh.
--
You received this message because you are subscribed to the Google Groups
> in sokol_app.h: EM_JS_DEPS(sokol_audio, "$withStackSave");
> in sokol_audio.h: EM_JS_DEPS(sokol_app, "$withStackSave");
...erm, obvious typos, but you know what I mean :D
On Saturday, 15 October 2022 at 18:12:51 UTC+2 Floh wrote:
> The new EM_JS_DEPS() macro wo
(sokol_audio, sokol_app) don't have any association with
any lib those headers might be compiled into.
It seems to work though, so I'm no complaining, just wondering what those
tags are there for :)
On Wednesday, 14 September 2022 at 21:00:41 UTC+2 Floh wrote:
> You are my hero :)
>
> On
for architecture arm64:
"_memfd_create", referenced from:
_main in test-26b3ed.o
ld: symbol(s) not found for architecture arm64
Cheers,
-Floh.
On Friday, 14 October 2022 at 23:39:55 UTC+2 s...@google.com wrote:
> Emscripten doesn't yet support the memfd_create API. If you need to
s...@google.com wrote:
> On Tue, Oct 11, 2022 at 12:13 AM Floh wrote:
>
>> My C code is still quite stack heavy, because a lot of my code
>> essentially uses the stack as per-frame arena allocator ;) But I guess as
>> long as there's a compiler/linker option to set the
In case there's no change for background threads (e.g., created via
>> pthreads), it'll be useful to mention it somewhere.
>>
>> On Thursday, May 27, 2021 at 2:01:11 PM UTC+2 jj wrote:
>>
>>> ke 19. toukok. 2021 klo 11.27 Floh (flo...@gmail.com) kirjoi
typo: "Emscripten's TCP API" should better be "Emscripten socket API".
On Monday, 10 October 2022 at 13:22:14 UTC+2 Floh wrote:
> I might be wrong but I don't think that's possible. First, you can't
> expose a TCP-compatible socket in browsers (Emscripten's TCP API
I might be wrong but I don't think that's possible. First, you can't expose
a TCP-compatible socket in browsers (Emscripten's TCP API is an emulation
wrapper over WebSockets, which are not protocol-compatible with 'raw' TCP).
WebSocket in the browser can only implement a client interface (e.g.
> ...and I would strongly prefer not to have a bundled node at all.
Hmm, I have the opposite opinion tbh, Node *should* be bundled, but
shouldn't be added to the path (so that the bundled version doesn't collide
with any globally installed version), and the Emscripten SDK shouldn't
Ok, I just confirmed that the
PR https://github.com/emscripten-core/emscripten/pull/17866 fixes the
original issue with the spine-c runtime. Many thanks!
On Wednesday, 7 September 2022 at 10:46:45 UTC+2 Floh wrote:
> Ok, ticket is here:
>
> https://github.com/emscripten-core/emscript
You are my hero :)
On Wednesday, 14 September 2022 at 20:40:35 UTC+2 s...@google.com wrote:
> Looks promising: https://github.com/emscripten-core/emscripten/pull/17854
>
> This depends on a small llvm linker change but otherwise seems to work
> fine!
>
> On Tue, Sep 13, 20
ckSave', 'allocateUTF8OnStack', 'UTF8ToString')
Cheers!
-Floh.
On Tuesday, 13 September 2022 at 15:34:15 UTC+2 s...@google.com wrote:
> On Sat, Sep 10, 2022 at 10:36 AM Floh wrote:
>
>> PS: also I just noticed that allocateUTF8OnStack is on your list of
>> 'legacy functions', but call
ke presets.
This still would only provide support for building though, not debugging.
But with cmake-presets it should be easy to switch between an Emscripten
build config and a native build config (where the native build config could
be used for debugging).
Cheers!
-Floh.
On Sunday, 11 Sept
hrough compiler options?).
It would be nice to have a guaranteed set of these low level C interop
functions btw (like this withStackSave, allocateUTF8OnStack stuff).
Cheers!
-Floh.
On Tuesday, 6 September 2022 at 19:35:05 UTC+2 Shlomi Fish wrote:
> On Tue, 6 Sep 2022 09:06:27 -0700
> "'Sam Clegg
Yes, you can web-host like a regular static webpage. The Emscripten
compiler usually outputs three files: one .html, one .js and one .wasm. The
.html file is basically your index.html which is loaded when visiting the
URL. The .js and .wasm files are then loaded by the .html file, the only
ect_files = True` on
> `libmalloc` in `tools/system_libs.spy`.. which means it (like compiler-rt
> et al) will be compiled as normal object files and not take part in LTO.
>
> I am curious why this doesn't happen for dlmalloc too though..
>
> cheers,
> sam
>
> On Tue,
pointer
3. ...and emmalloc is used instead of the vanilla allocator
4. ...and -flto must be enabled
...if any of this is missing, it works :D
Should I write an Emscripten ticket too?
On Tuesday, 6 September 2022 at 18:43:52 UTC+2 Floh wrote:
> Part of the mystery can be solved because clang repla
>>
>> Does the link time error tell you why calloc is being pulled in? (The JS
>> compiler linker errors should do this but they often just say "top level
>> C/C++").
>>
>> On Sat, Sep 3, 2022 at 6:03 AM Floh wrote:
>>
>>> I just
pointer to malloc() would lead to a linker error about missing calloc() -
and only when using emmalloc.
Cheers!
On Sunday, 4 September 2022 at 15:40:12 UTC+2 Floh wrote:
> Followup: could this somehow be related to function pointers to C runtime
> functions? E.g. spine-c memory allocations
/spine-c/include/spine/extension.h#L69-L91).
...which works for me ATM, but it would still be good to get to the bottom
of this issue.
On Saturday, 3 September 2022 at 17:03:59 UTC+2 Floh wrote:
> Ok, it gets weirder:
>
> If I add the -sEXPORTED_FUNCTIONS=_calloc, the sample link
s suck TBH ;)
On Saturday, 3 September 2022 at 16:44:41 UTC+2 Floh wrote:
> PPPS: building with "-sEXPORTED_FUNCTIONS=_calloc" also works, but I don't
> understand why I need this only for this one specific sample, for a problem
> triggered by a library that doesn't even call
the reason, lol).
Cheers!
On Saturday, 3 September 2022 at 16:26:07 UTC+2 Floh wrote:
> Another information tidbit:
>
> Adding a calloc() call in any of the other (very similar) samples always
> works without problems (e.g. I don't need to add calloc to
> EXPORTED_FUNCTIONS as ad
, but I don't understand how any potential problems in
emmalloc would be triggered by the presence or absence of a random third
party library that doesn't even call into calloc...
On Saturday, 3 September 2022 at 15:54:37 UTC+2 Floh wrote:
> Ok, it works if I change one thing: setting the -O f
(e.g. the Spine runtime has
CALLOC macros all over the place, but this resolves to a call to a helper
function with malloc+memset.
On Saturday, 3 September 2022 at 15:21:18 UTC+2 Floh wrote:
> PPS: ...looks like I can only go back to SDK version 3.0.0 on ARM Macs,
> and the problem a
PPS: ...looks like I can only go back to SDK version 3.0.0 on ARM Macs, and
the problem already existed in that version.
On Saturday, 3 September 2022 at 15:16:42 UTC+2 Floh wrote:
> PS: this is the wasm-ld cmdline:
>
> em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/w
PS: this is the wasm-ld cmdline:
em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o
/Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.wasm
sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj
sapp/CMakeFiles/spine-sapp.dir/spine
complains
about an unresolved 'calloc' call. Adding detailed output
via LLD_REPORT_UNDEFINED=1 I get tons of:
wasm-ld: error:
/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libemmalloc.a(emmalloc.o):
undefined symbol: calloc
... how does
their underlying web APIs have been a lot more
flexible and useful than the API wrappers which tried to emulate 'native
platforms APIs' (like OpenAL, GLFW, SDL etc...).
Cheers and thanks for putting your work on github instead of keeping it
inhouse :)
-Floh.
On Wednesday, 24 August 2022 at 12:51:04 UTC+2 jj
to the Chrome debugger also for WASM code that would be the icing on the
cake, but I couldn't get this to work for plain Javascript ;)
On Thursday, 25 August 2022 at 14:14:09 UTC+2 Floh wrote:
> It should definitely work on Vanilla Chrome, but setting everything up can
> be a bit finicky:
>
&g
Is this in any way related to the EM_JS() magic?
In any case, I'm using EM_JS() quite a lot in my code and everything still
appears to working after updating to 3.1.15.
Cheers!
-Floh
On Tuesday, 5 July 2022 at 18:28:12 UTC+2 s...@google.com wrote:
> 3.1.15 was released last w
It's almost too simple for a standalone example. First follow the getting
Electron Quick Start guide
(https://www.electronjs.org/docs/latest/tutorial/quick-start) until you
get to the point where an "npm start" gives you an Electron window with the
"Hello World" message.
Next you need the
This looks to me like the MSVC compiler is used for compilation, not the
Emscripten compiler wrapper (emcc)
Are you aware of the emcmake wrapper tool, and the cmake toolchain file in
the Emscripten SDK? Those can help with building cmake projects in
Emscripten, however I doubt that those would
The Socket API in Emscripten is a wrapper around WebSockets, not POSIX
sockets. From the source code side it looks and behaves roughly like a
non-blocking POSIX socket, but the underlying protocol is WebSocket, and
incompatible to TCP or UDP, meaning you can't connect to a native TCP or
UDP
I'm neither part of the Emscripten team or a lawyer, so take my answers
with a huge grain of salt.
>
>1. Under which license and copyright is the from emscripten generated
>code?
>
> Emscripten doesn't matter in this case, only the license of the source
code that's compiled.
>
>1.
ion, more details might
> make sense to add there, if any,
>
> https://github.com/ziglang/zig/issues/10836
>
> On Tue, Feb 1, 2022 at 3:44 AM Floh wrote:
>
>> > Btw, did you get a chance to file a Zig ticket as you said?
>>
>> Haven't done that yet!
>>
>
se the slider and need to grab it again.
On Tuesday, 8 February 2022 at 17:20:59 UTC+1 caiiiycuk wrote:
> I use "leave" event as workaround. When "pressed" pointer leaves canvas it
> automatically became unpressed. It works fine in most cases for me.
>
> вт, 8
oops typos:
> setCapture()/releaseCapture() event pair
...this should be "function pair". Don't know why I got that wrong *twice*
:)
On Tuesday, 8 February 2022 at 14:28:30 UTC+1 Floh wrote:
> First...I don't mean pointer-lock (which works fine), but instead the
>
D
I guess that emscripten/html5.h needs a new set of event functions for
pointer events
(https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events), instead
of regular mouse events?
Thanks!
-Floh.
--
You received this message because you are subscribed to the Google Groups
"emscripten
n 31, 2022 at 1:53 AM Floh wrote:
>
>> PS: the missing __stack_chk_* symbol errors I mentioned formerly are
>> unrelated to the target triple, but instead happen when compiling via Zig
>> in debug mode. In that case, Zig compiles the C code with clang's
>> "-f
, a
guard-value and a function which is called when the stack protection
triggers. When linking with emcc those symbols can't be found, so I just
provided them myself in the C stub here:
https://github.com/floooh/pacman.zig/blob/main/src/emscripten/entry.c
On Sunday, 30 January 2022 at 17:56:32
:)
-Floh.
On Sunday, 30 January 2022 at 01:16:44 UTC+1 s...@google.com wrote:
> I'm pretty sure EMSCRIPTEN_KEEPALIVE won't have the intended behaviour of
> actually exporting symbols when compiled with non-emscripten triples.
>
> On Sat, Jan 29, 2022 at 4:08 PM Floh wrote:
a few fixes for wasm32-emscripten (if
just some empty stubs), so that a complete project can be compiled with
this triple.
Cheers!
-Floh.
On Saturday, 29 January 2022 at 20:47:24 UTC+1 s...@google.com wrote:
> Short term fix/wrokaround is here:
> https://github.com/emscripten-core/emscripte
to use wasm32-freestanding with the C code, then wasm-ld
complained about some missing stack-check functions (don't have the exact
symbol at hand currently).
...I think I have enough to build a little 'proof-of-concept', even though
it's a bit hacky :)
Thanks!
-Floh.
On Saturday, 29 January 2022
January 2022 at 18:12:42 UTC+1 Floh wrote:
> I'm currently tinkering with bringing one of my toy Zig projects to the
> web via
> Alon's nice gist here which uses emcc only for the linker step:
>
> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>
> ...and it
EM_JS() magic
is in the linker (by extracting the __em_js_* Javascript source code
strings, and then "somehow" providing the C function import). Any ideas
what I'm missing?
Thanks!
-Floh.
--
You received this message because you are subscribed to the Google Groups
"emscripten-di
That's a very useful gist, Alon! I think that blog post would be much
appreciated by a lot of people who like to tinker with other languages :)
On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:
> On Sat, Dec 25, 2021 at 6:02 AM Floh wrote:
>
>> Ah, language a
anyway ;)
I'll actually need to look into the Fetch API if this somehow fixes the
compressed vs uncompressed offset/size problem (I would be surprised if it
did though).
Cheers!
-Floh.
On Saturday, 8 January 2022 at 14:40:45 UTC+1 jiao...@gmail.com wrote:
> Great work, very inspired.
> I
which loads data via Range requests is here
(this uses https://github.com/phoboslab/pl_mpeg/blob/master/pl_mpeg.h to
decode the MPEG stream):
https://floooh.github.io/sokol-html5/plmpeg-sapp.html
Cheers!
-Floh.
On Friday, 7 January 2022 at 13:07:44 UTC+1 jiao...@gmail.com wrote:
> Hi,
>
The autotools command line has the "-O2" optimization flag, which the cmake
command line is missing.
Try running emcmake like this (to enable optimizations favouring size over
performance:
emcmake cmake -DCMAKE_BUILD_TYPE=MinSizeRel ..
...or this to enable optimizations favouring performance
mising project https://github.com/schellingb/wajic by
Bernhard Schelling which has the same goals and which was used to port
Mattias Gustavsson's DOS-like library to the
web: https://mattiasgustavsson.com/wasm/
Anyway... just my 2 cents :)
-Floh.
On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycu
Ah alright, that toolchain file looks a lot simpler (it's under
"share/cmake" in the SDK download). I'll use that as base for my own cmake
toolchain file instead. Thanks!
On Thursday, 16 December 2021 at 21:18:46 UTC+1 s...@google.com wrote:
> On Thu, Dec 16, 2021 at 5:53 A
ugh, but a promising one :)
On Tuesday, 14 December 2021 at 23:41:10 UTC+1 s...@google.com wrote:
> On Tue, Dec 14, 2021 at 9:28 AM Floh wrote:
>
>> Oki doki, thanks for the clarification. I just wanted to check if I'm
>> missing something, using the wasi-sdk makes sense in that cas
the proprietaty D3D and Metal shader
compilers to generate shader binary blobs. Not sure yet how I'll tackle
that eventually, but a WASI executable which just generates shader source
code (not binary blobs) would be a good start nonetheless.
Cheers!
-Floh.
On Tuesday, 14 December 2021
I'm currently tinkering with Emscripten's WASI output and can't get
filesystem access to work. In short, everything compiles, but then when
running via:
wasmtime --dir . bla.wasm
...all filesystem operations fail.
When compiling with the clang included in the wasi-sdk it works as
expected.
to compile with -g so
that Emscripten doesn't do any minification or name mangling, that way the
callstack in the exception messages is readable (functions have their
expected names instead of being minified). IME usually that's enough to
figure out what's going wrong.
Cheers,
-Floh.
On Monday, 1
..
configure: cmake "-GUnix Makefiles" ..
-DCMAKE_TOOLCHAIN_FILE=/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake
-DCMAKE_CROSSCOMPILING_EMULATOR=/Users/floh/projects/fips-sdks/emsdk/node/14.15.5_64bit/bin/node
-- Configuring done
-- Generating
setup you could try
building my Pacman clone here:
https://github.com/floooh/pacman.c#build-and-run-wasmhtml-version-via-emscripten
If this also fails, the problem could be in your setup (however this is a
plain C project, which is a much easier case than a C++ project using the
C++ stdlib).
Che
Ah nvm, now it's working all of the sudden
(with --js-flags="--experimental-wasm-return_call"). Not seeing any
performance improvements, but I guess that's to be expected from plain C
code without recursions :)
On Wednesday, 1 December 2021 at 18:50:03 UTC+1 Floh wrote:
&
Apologies for jumping in. I tried compiling my home computer emulator code
with -mtail-call to see if it makes a difference, but I have a hard time
starting Chrome (or Chrome Dev) into a mode where it accepts the new
instructions. On the console I get:
~~~
Uncaught (in promise) RuntimeError:
Btw Sam, with your last two PRs my sokol samples now build and run fine
using the emsdk tot version.
Thanks for the quick fixes :)
On Friday, 12 November 2021 at 16:48:40 UTC+1 s...@google.com wrote:
> On Fri, Nov 12, 2021 at 4:10 AM Floh wrote:
>
>> Ah... that was simply t
Ah... that was simply the optimizer resolving the math code into a constant
expression. Reproduction test cases incoming :)
On Friday, 12 November 2021 at 13:02:26 UTC+1 Floh wrote:
> I started a github issue here:
> https://github.com/emscripten-core/emscripten/issues
.
On Friday, 12 November 2021 at 12:23:09 UTC+1 Floh wrote:
> > I suspect LTO is the culprit here.
>
> That's indeed the issue. Building without LTO works. I'll try to come up
> with a minimal reproducer, create a github ticket and then see if I can get
> your PR working with my local
1 s...@google.com wrote:
> I think this should fix your issue:
> https://github.com/emscripten-core/emscripten/pull/15497
>
> On Thu, Nov 11, 2021 at 1:44 PM Sam Clegg wrote:
>
>>
>>
>> On Thu, Nov 11, 2021 at 4:46 AM Floh wrote:
>>
>>> These are th
+1 Floh wrote:
> PS: my other WASM projects appear to work fine (the home computer
> emulators here: https://floooh.github.io/tiny8bit/, and the Z80 and 6502
> netlist simulations: https://floooh.github.io/visualz80remix/,
> https://floooh.github.io/visual6502remix/).
>
&g
Floh wrote:
> I'm getting the following linker errors in my sokol-samples project:
>
> 5x:
> wasm-ld: error:
> /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp2f_data.o): undefined
> symbol: __exp2f_data
>
> 8x:
> wasm-ld: error:
> /...cache/sysroot/li
: __exp_data
Full wasm-ld command line:
em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o
/Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.wasm
sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj libs/sokol/libsokol.a
fips
Despite the name, WASM files are binary data. If you want to see the
disassembly, either look at the WASM files in browser devtools under the
"Sources" tab, or use the wasm2wat tool from the WABT
toolkit: https://github.com/WebAssembly/wabt
On Thursday, 4 November 2021 at 18:22:11 UTC+1
issue by compiling with
> optimization flag -O3.
>
> I will check out that link though, it might help me in the future.
>
> Thanks!
>
> On Tuesday, November 2, 2021 at 6:05:15 AM UTC-5 Floh wrote:
>
>> > However, I get a different (unrelated) error now which is that the
ory debugging, this is
probably a good starting point:
https://web.dev/webassembly-memory-debugging/
On Tuesday, 2 November 2021 at 12:00:26 UTC+1 Floh wrote:
> Ah dang, yeah totally makes sense. I guess that's one of those pitfalls in
> C that are so obvious that one gets bl
t might be too big for the browser to download.
> I did set ALLOW_MEMORY_GROWTH=1 but that didn't seem to prevent the issue.
> If anyone can help me out with that too please let me know. Thanks.
>
> On Monday, November 1, 2021 at 9:20:16 AM UTC-5 Floh wrote:
>
>> PS: if you jus
++, but since I prefer plain old C these
days, most of the sample code is written in C (and the few C++ samples -
mainly the Dear ImGui stuff - doesn't use the STL).
On Monday, 1 November 2021 at 15:16:29 UTC+1 Floh wrote:
> I'm also able to reproduce the problem on macOS with Chrome and Saf
I'm also able to reproduce the problem on macOS with Chrome and Safari, but
no idea either what's going wrong there.
However, I suspect it's not the use of std::string, but that iostream is
the culprit, because if I replace std::cout with printf but keep
std::string, it works (replacing cout
Do you want to avoid reverse engineering, or just block unlicensed users
from running the WASM?
The first is pretty much impossible if the code runs on the client, the
second could be implemented with a client/server login handshake. But in
any case, all code running on the client should be
You can handle emscripten specific options inside an if-block which check
that CMAKE_SYSTEM_NAME is "Emscripten". For example see here at the start
and towards the end of the CMakeLists.txt file:
https://github.com/floooh/pacman.c/blob/main/CMakeLists.txt
On Friday, 29 October 2021 at 01:44:48
AFAIK you can look for commits by github user kainino0x to keep track of
WebGPU updates in the Emscripten SDK, for instance there was a commit just
yesterday: https://github.com/emscripten-core/emscripten/pull/15063
Cheers,
-Floh.
On Friday, 24 September 2021 at 22:51:47 UTC+2 rode
Hmm, looking at that path .../opencv, it looks to me like the error isn't
Emscripten tutorial related, but caused by the OpenCV build scripts.
Easiest solution should be to install Ninja through Scoop:
First install scoop as described at the end of this page:
https://scoop.sh/
Then run 'scoop
d.c
>
> (base) raphy@pc:~/emsdk$ node a.out.js
> hello, world!
>
>
> I wanted to install emscripten 2.0.1 version because I would like to try
> to use cpython:
>
> https://github.com/dgym/cpython-emscripten#prerequesits
> "Emscripten is also required for the cr
the simple
setup sequence outlined in my previous post (clone, install, activate,
source). You should never have to edit any emscripten config files or
install additional Ubuntu packages. The Emscripten SDK is completely
self-contained.
On Wednesday, 28 July 2021 at 09:43:11 UTC+2 Floh wrote:
>
1 - 100 of 658 matches
Mail list logo
