Hi!
On 02/10/2018 01:43, sha...@infograph.com wrote:
> Hello, I am new to WebAssembly and Emscriptem.
> I am converting a large C/C++ project (hundreds of source files) to WASM.
> I see how I can compile every source file to a bitcode file:
>
> emcc -O3 hello.c -o hello.bc
> emcc -O3 foo.c -o foo.
erest/plans for a SharedArrayBuffer-based SDL2 port?
(or maybe I missed an easier solution to my port? ;))
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails
Thanks a lot for the pointers!
- Beuc
On 05/10/2018 04:24, Alon Zakai wrote:
> SharedArrayBuffer has been re-enabled in Chrome meanwhile (after
> having implemented a good solution to the underlying security issues,
> Spectre etc.). You can use JS with threads there right now, including
Yeah that's my second point basically.
Check tools/shared.py:is_wasm_only() for the flags.
(Incidentally, any chance this issue could be fixed in chrom*? ;))
On 06/10/2018 01:13, Sam Clegg wrote:
> I think the thing we really want to fix here is the fact the async
> compilation is disabled under c
5, 2018 at 4:32 PM Beuc <mailto:b...@beuc.net>> wrote:
>
> Yeah that's my second point basically.
> Check tools/shared.py:is_wasm_only() for the flags.
> (Incidentally, any chance this issue could be fixed in chrom*? ;))
>
> On 06/10/2018 01:13, Sa
Hi,
I believe we'd need to deal with LLVM_ROOT as well, since the fastcomp
version needs to be in sync with emscripten's?
- Sylvain
On 10/10/2018 02:41, Sam Clegg wrote:
> TLDR: There is a field in called EMSCRIPTEN_ROOT in the config file
> which in theory can be used by external tools to find
c.). So there is a risk of getting out
> of sync for EMSCRIPTEN_ROOT, and I think it makes sense to remove it,
> but not LLVM_ROOT, unless I'm missing something.
>
> On Wed, Oct 10, 2018 at 3:00 AM Beuc <mailto:b...@beuc.net>> wrote:
>
> Hi,
>
>
Hi,
As https://github.com/itchio/itch.io/issues/394 shows
some hosting services have tailored their HTTP server configuration to
Unity HTML5,
which decompresses .js/.wasm with a JS gzip.
This breaks
https://kripken.github.io/emscripten-site/docs/compiling/WebAssembly.html#web-server-setup
and fix
Hi,
What OpenGL context did you request?
Format 'GL_RED' requires GLES3/WebGL2 compatibility.
AFAICR SDL_ttf renders as RGBA and it's the programmer's responsibility
to upload that surface as a GL texture.
- Sylvain
(OpenGL Programming contributor ;))
On 11/11/2018 05:39, Bruce Davidson wrote:
Hi,
On Mon, Nov 12, 2018 at 03:40:32PM -0800, Alon Zakai wrote:
> You can use zee.js to gunzip in JS on the client,
>
> https://github.com/kripken/zee.js
>
> (I can upload a new build there if people want). There are also some JS
> libraries but I'm not very familiar with them, like pako and zli
On Tue, Nov 13, 2018 at 10:25:55AM +0100, b...@beuc.net wrote:
> Hi,
>
> On Mon, Nov 12, 2018 at 03:40:32PM -0800, Alon Zakai wrote:
> > You can use zee.js to gunzip in JS on the client,
> >
> > https://github.com/kripken/zee.js
> >
> > (I can upload a new build there if people want). There are
Hi,
I'm experimenting with a simple, non-async SDL2 loop in a background
thread/worker using PROXY_TO_PTHREAD=1.
I only get a:
ReferenceError: screen is not defined
straight on SDL_Init(), with or without offscreen canvas, with both
Chromium 70 and FF Nightly.
I didn't see a matching PR nor a
Hi!
On Tue, Nov 20, 2018 at 12:05:28PM -0800, 'Sam Clegg' via emscripten-discuss
wrote:
> As part of a cleanup operation and an attempt to use node modules in a
> more conventional way it is being proposed that we remove the
> checked-in node_modules directories that currently exist in emscripten
Hi,
On Tue, Nov 20, 2018 at 02:18:02PM -0800, 'Sam Clegg' via emscripten-discuss
wrote:
> On Tue, Nov 20, 2018 at 1:01 PM Sam Clegg wrote:
> > On Tue, Nov 20, 2018 at 12:24 PM wrote:
> > > On Tue, Nov 20, 2018 at 12:05:28PM -0800, 'Sam Clegg' via
> > > emscripten-discuss wrote:
> > > > As part
Hi,
My current Python+Emterpreter app (https://renpy.beuc.net/) sometimes
crashes unexpectedly, e.g. when going back to the browser tab after a
few minutes of inactivity.
I'm still trying to figure out where that comes from, but something in
the JS stack trace intrigues me:
...
emterpret
emterpr
Thanks for the feedback!
I was worried fpcast would somehow switch to non-emterpreter execution
and cause issues on stop/resume.
Beuc
On 09/12/2018 17:22, Alon Zakai wrote:
> I believe that's normal, yes. For function pointer cast emulation we
> run binaryens fpcast-emu pass. It
one (self)host or another, but the
current github concentration always had a bad sourceforge-era taste to me)
++
Beuc
On 21/12/2018 10:59, Jukka Jylänki wrote:
> Sounds good to me to migrate to an org. Btw, would that invalidate
> existing URL links to Emscripten repository, issue tracker, ta
way to support it without patching around both SDL2
and emscripten?)
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discus
Hi,
Another extension with a new image format if you're interested:
https://bellard.org/bpg/
https://bellard.org/bpg/gallery2.html
https://bellard.org/bpg/animation.html
Nice target choice for the emulator ;)
- Beuc
On 05/01/2019 22:20, Floh wrote:
> Not a question, just something int
er doesn't support running several asynchronous calls at
once, so currently you cannot use it for both your main loop and your
long function.
I'm not sure why that is, maybe you could modify emterpreter to support
several call stacks.
Cheers!
Beuc
On 08/01/2019 02:03, Raptisoft wrote:
&g
> One (non-GitHub) guy chimed in to say he thought the only way
> GitHub should act was if there was an official trademark claim.
>
How about we do just that?
- Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" gr
loading symbols from the current
binary, and now rejects it?
While it makes sense to modify FreeDink to locate GL functions
statically under Emscripten, I don't see anything related in
ChangeLog.md, so I'd like to make sure.
--
Beuc
--
You received this message because you are subscribe
Hi,
To be honest I didn't try MAIN_MODULE=1, because this is documented as
being slower, and incompatible with Emterpreter/pthreads/etc.
I'm somewhat puzzled it worked before really, I'm asking to make sure I
didn't miss something obvious.
- Beuc
On 22/01/2019 23:27, Alon
Yeah that's how I had fixed it:
https://git.savannah.gnu.org/cgit/freedink.git/commit/?id=b879f418619a8e87e0bb614e4b84ca054cb8cfe9
Glad to see we came to the same conclusion :)
- Beuc
On 23/01/2019 00:35, Alon Zakai wrote:
> Well, what I think happened is we used to have a very simpl
Hi,
Thinking back on this issue, is there some risk to call
emscripten_sleep/emscripten_sleep_with_yield from JavaScript, as you
suggested?
Emscripten can only restore C stack frames AFAIU.
Also I've opened https://github.com/emscripten-ports/SDL2/issues/70
- Beuc
On 04/01/2019 03:37,
still using
SDL_GL_GetProcAddress for the rest also solves the issue in my case.
This makes SDL_GL_GetProcAddress still work but less forgiving (with a
confusing error message).
- Beuc
On 24/01/2019 16:20, Alon Zakai wrote:
> Oh, thanks, I missed that this was for SDL_GL_GetProcAddres
I'm not sure how this should work; AFAICS dlopen works even with static
binaries under GNU/Linux.
To the least, printing out the name of the failed symbol would help
understand the context.
- Beuc
On 24/01/2019 18:54, Alon Zakai wrote:
> I see, thanks. So should we make dlopen/dlsym jus
rote:
> I agree that this seems to be a regression we should fix. Would you
> mind opening a bug?
>
> On Thu, Jan 24, 2019 at 10:51 AM Beuc wrote:
>> I'm not sure how this should work; AFAICS dlopen works even with static
>> binaries under GNU/Linux.
>> To the
mpile, or compile on a
worker thread.
I added a note at https://github.com/emscripten-core/emscripten/wiki/Linking
Is there a work-around to document (aside from moving everything to a
worker, which is not practical)?
- Beuc
--
You received this message because you are subscribed to the Google G
//github.com/emscripten-core/emscripten/blob/incoming/src/library_browser.js#L233
>
> Another option is to call loadWebAssemblyModule manually, and pass it
> loadAsync: true, like the plugin does in the above link.
>
> Thanks for helping document this!
>
> On Fri, Feb 1, 2019 at 3:22 P
What am I saying, the same .so files are not compatible between asmjs
and wasm.
- Beuc
On 02/02/2019 12:43, Beuc wrote:
>
> Thanks, I linked the doc in the wiki.
>
> One issue though: if one loads the same the same data file from an
> asmjs alternate build, this makes dlopen
race, edit my Makefile and
EMTERPRETIFY_WHITELIST, and repeat.
And I need to tell my users/contributors to do the same ;)
Is there anything I can do to avoid these dynamic function names?
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten
e, edit my Makefile and
EMTERPRETIFY_WHITELIST, and repeat.
And I need to tell my users/contributors to do the same ;)
Is there anything I can do to avoid these dynamic function names?
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-dis
Hi,
Also, infinite loops normally produce a pop-up from Chromium first,
asking the user whether to "Exit page | Wait".
In case this helps, last time I got an immediate "Aw snap!" was due to
using too much memory in the virtual filesystem (>1 GB).
Cheers!
Beuc
On 05/04
Hi,
Would you like to propose a pull request? :)
https://github.com/emscripten-core/emscripten/blob/incoming/site/source/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.rst
https://github.com/emscripten-core/emscripten/edit/incoming/site/source/docs/porting/connecting_cpp_and_jav
I'm interested :)
- Beuc
On 11/04/2019 20:15, Charles Vaughn wrote:
> At Tableau, what we've done is very similar to what Floh mentioned,
> but baked into our tooling. It's probably not for everyone, since we
> require calls into WASM be asynchronous, and Javascript a
e (rather than shoving a language choice in
their face on start-up ;)).
Provided your program is i18n'd / multi-language, of course.
For nodejs no changes.
While this environment variable is pretty standard on desktop, Alon
expressed concerned that this may be risky to start doing this now.
Hence
locale'
package without any changes.
Programs using gettext(3) would also work as-is.
LANG doesn't affect the C runtime until the program calls setlocale(3)
(cf. PR discussion).
This is about language preference detection; changing the language
in-app (sadly) cannot be solved at this leve
ues, since the browser uses IDB with the iframe
domain context
(which makes much more sense to me).
Are you aware of this?
Are there workarounds?
Should I file a bug in Chromium?
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-dis
ave some more feedback on this?
Cheers!
Beuc
On 17/06/2019 12:45, Jukka Jylänki wrote:
> If there's differing behavior between browsers, filing a bug is good
> idea. Any chance you'd be able to handwrite an IndexedDB example JS
> code that highlights the discrepancy? In general I
cookie" setting.
There doesn't seem to be a way around this but I can be mistaken.
Cheers!
Beuc
On 17/06/2019 14:53, Beuc wrote:
>
> AFAICS this has been around for years :/
> See for instance
> https://forum.unity.com/threads/how-to-check-playerprefs-has-actually-wr
Hi,
FYI the PR was accepted :)
Cheers!
Beuc
On 12/06/2019 12:06, Beuc wrote:
>
> Hi,
>
> This PR's point is improving the "standard-ness" of the Emscripten
> environment :)
> (One could easily make yet another emscripten-specific change and grab
> 'na
You can't use your system (i386) headers for an Emscripten (asmjs/wasm)
application :)
If JModelica can't be compiled without i386 headers (AFAIU), it probably
can't compiled for the asmjs/wasm target.
You'll need to improve JModelica so it supports more targets/architecture
#x27;d really need is pthreads, but I can't find ETA for when
Mozilla or Microsoft plan to bring
SharedArrayBuffer/WebAssembly-threads/etc. back.
Any info? :)
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To u
and emterpreter).
>
> Unfortunately I don't know anything specific about Microsoft or
> Mozilla's threading plans. MS's Chromium-based version of Edge will
> inherit Chrome's site-isolation feature, so they can safely ship
> threads; presumably they will leav
Hi,
On Thu, Aug 22, 2019 at 10:18:44AM -0700, 'Sam Clegg' via emscripten-discuss
wrote:
> On Thu, Aug 22, 2019 at 8:01 AM Beuc wrote:
> > I know about new-asyncify.
> > However I understood Emterpreter wasn't ported to LLVM "yet", but now it
>
Hi,
On 26/08/2019 22:09, Alon Zakai wrote:
> On Sun, Aug 25, 2019 at 2:21 PM Beuc <mailto:b...@beuc.net>> wrote:
>
> > Is there some use case you have that asyncify doesn't handle?
>
> I had answered you in the link above :)
>
> - debug capacity:
1flip",
"__pyx_pw_11pygame_sdl2_7display_6Window_13flip",
"__pyx_pf_5renpy_2gl_6gldraw_6GLDraw_28draw_screen",
"__pyx_pw_5renpy_2gl_6gldraw_6GLDraw_29draw_screen",
"__Pyx_PyObject_CallNoArg", "__pyx_pf_10emscripten_6sleep",
"__pyx_pw
'-s ASSERTIONS=1 -g', and
'-s ASYNCIFY_STACK_SIZE=65535' (just in case)
- I'm using my patch from
https://github.com/emscripten-ports/SDL2/issues/70
hence emscripten_sleep()
On Wed, Sep 04, 2019 at 04:22:17PM -0700, Alon Zakai wrote:
> On Wed, Sep 4, 2019 at 2:1
t_emu$__pyx_pw_11pygame_sdl2_7display_6Window_13flip (present
in the .wasm but not recognized as part of the whitelist). Is this expected?
Cheers!
Beuc
On 05/09/2019 02:07, Alon Zakai wrote:
>
>
> On Wed, Sep 4, 2019 at 4:45 PM Beuc <mailto:b...@beuc.net>> wrote:
>
>
Hi,
We almost never could use Emscripten without applying a few patches.
It's become increasingly difficult, not only to patch, but to convince the
developers that it's legitimate, so I thought I'd detail our use case for good
here.
So we've been using Emscripten with patches in emscripten, llv
releases on your codebase as they
>> are tagged? (Another option is to test the much more frequent
>> tip-of-tree builds, but you may see more noise there.)
>> * It would be good to discuss upstreaming long-term changes you
>> mention like that EMT_STACK_MAX one - we may not be
Hi,
I got feedback from a few gamedevs who tried to new RenPyWeb build
(with Emterpreter->Asyncify, and fastcomp->upstream):
so far it's been positive :)
I thought I'd share - great work :)
- Beuc
--
You received this message because you are subscribed to the Google Gro
HHi,
On 17/09/2019 00:18, Alon Zakai wrote:
> On Mon, Sep 16, 2019 at 6:50 AM Beuc <mailto:b...@beuc.net>> wrote:
>
> > * Are there tests in your codebase that we could run in upstream
> emscripten?
>
> Come to think of it, there's one thorough a
ng a few external libs may actually be a good release test case
for the Emscripten project ¯\_(ツ)_/¯
- Beuc
On 20/09/2019 20:06, Beuc wrote:
>
> Hi,
>
> On 17/09/2019 00:18, Alon Zakai wrote:
>> On Mon, Sep 16, 2019 at 6:50 AM Beuc > <mailto:b...@beuc.net>> wrote:
>>
pport)
https://github.com/renpy/renpyweb/tree/master/scripts (for more)
All are currently built static-only, remove --disable-shared for testing
dynamic builds.
Tarballs URLs are in https://github.com/renpy/renpyweb/blob/master/Makefile
- Beuc
On Fri, Oct 11, 2019 at 04:05:20PM -0700, Alon Zakai
nvironment?
(I wouldn't want to blindly blacklist Safari)
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+uns
While I regularly complain about unexpected/undocumented change, I think
Alon's plan is pretty careful and reasonable.
Badly named variables are a perpetual mental hassle, and triggering a
clear error message means the change won't be obscure.
Cheers!
Beuc
On 17/10/2019 17:02, Gabriel
ould also set up a bridge to other places people want, or consider
> other options.
>
> Thoughts?
AFAIK there is no usable free/open source client for Discord, offline
notifications are days-delayed, and users have to accept their ToS with
the usual abusive clauses.
- Beuc
--
You received t
Independently of the topic /per se/, I wish I didn't see herd mentality
as a decision basis in a R&D project - hurts my feelings.
Cheers!
Beuc
On 18/01/2020 01:53, Alon Zakai wrote:
> I definitely get that there are a lot of reasonable opinions on this.
> I honestly agree w
Hi Fernando,
You may want to check
https://github.com/kripken/zee.js
which exposes high-level functions of zlib through a secondary WASM module.
Cheers!
Beuc
On 12/06/2020 19:50, 'Thomas Lively' via emscripten-discuss wrote:
> WebAssembly in the browser has no notion of process
sure at what layer it would be best to
implement virtual keyboard support (besides re-implementing it in each
application).
What's your experience with mobile webapps and keyboard support?
Cheers!
Beuc
--
You received this message because you are subscribed to the Google Groups
"emscr
SDL TextInput API.
Maybe just display the HTML text input and send a single input event
with the full text line when pressing Enter...
Cheers!
Beuc
On 20/06/2020 22:35, Floh wrote:
> > What's your experience with mobile webapps and keyboard support?
>
> It massively *sucks* :D
>
lways
> creates it itself which makes my question moot.
One optimization I did for RenPyWeb was importing XMLHttpRequest's
buffer into the filesystem (FS):
https://github.com/renpy/renpy/blob/8b0d3dd4986a5a8656b3a5ad634c62bd52b1afbd/renpy/webloader.py#L64
FS.writeFile(path, new Uint8Array
64 matches
Mail list logo
