Keep in mind that inlining is one area area where it may matter. If you're
aggressively shrinking your size, you'll want to disable inlining when you
build the external library. I haven't checked, but it may be possible to
delay the inlining decision until you compile and link your final output,
If you're interested in checking out LZHAM, I've got that building for
emscripten here: https://github.com/hackcasual/lzham_codec
For bananabread, I saw the following results for of the models:
rw-rw-r-- 1 charles charles 385692 Sep 15 19:12 m134_hudguns.blend
-rw-rw-r-- 1 charles charles 13
ssume that's at the cost of taking longer to
> unpack.
>
> On Tue, Sep 15, 2015 at 7:17 PM, Charles Vaughn > wrote:
>
>> If you're interested in checking out LZHAM, I've got that building for
>> emscripten here: https://github.com/hackcasual/lzham_codec
&g
ield points could be made to work
without code bloat or speed impact, it would allow for streaming
decompression which would go along way to reducing the overall impact of
running the decompressor in Javascript.
On Friday, September 18, 2015 at 10:44:00 AM UTC-7, Charles Vaughn wrote:
>
> I
http://hackcasual.io/lzhamtestmin.html
That's timing on decompressing 4MB of floats from a 1.19MB input file
On Friday, September 18, 2015 at 11:02:22 AM UTC-7, Charles Vaughn wrote:
>
> I'll try to post a demo today. There's an interesting aspect to LZHAM's
> d
Any sense on compile time speedup? One of the big hits I've seen while
iterating through a bug fix is the time dominated to generate the JS. I
would imagine outputting wasm to be much faster.
On Wednesday, February 17, 2016 at 11:14:08 AM UTC-8, Alon Zakai wrote:
>
> Still too early. The spec is
Looking at a simple test example disassembly to demonstrate Emscripten, I
noticed a potential optimization opportunity.
See the gist here: https://gist.github.com/hackcasual/e0262caec12bd60b2fe1
C++ is in a comment on top, compiled with -Oz
For example, q and p are pointers allocated on the stac
other compiler flags).
> Aside from that, what version of emscripten are you using?
>
> On 24 February 2016 at 23:25, Charles Vaughn > wrote:
>
>> Looking at a simple test example disassembly to demonstrate Emscripten, I
>> noticed a potential optimization opportuni
ary 2016 at 19:51, Alon Zakai >
> wrote:
>
>> Looks like in -O3 16 bytes of stack are allocated, compared with 32 for
>> -Os and -Oz. So it looks like what you want happens in some optimization
>> modes. -Os and -Oz focus on code size, so perhaps they just don't care
Hello ANdrii,
Your code flows like this:
1. Emscripten's main is called
2. myObj is created within the scope of main
3. sendRequest is called with myObj as its parameter
4. sendRequest sets a timeout to call "sayHi" on myObj
5. main returns, destroying myObj
100ms later
6. The timeout fires, tryi
ome
understanding of how the types are
interpreted: https://gist.github.com/hackcasual/efb93d70c4c3e87cd1ee
More work needs to be done to get this into shipping shape, but I'd like to
kick of discussions now.
Thanks!
Charles Vaughn
--
You received this message because you are s
e here:
>> https://github.com/kripken/emscripten-fastcomp/compare/incoming...hackcasual:tableau-debugger-work
>>
>> I've got an initial driver (though out of sync with the format generated
>> in the current changes to JSBackend), you can see here to have some
>>
oing forward. There's also a class of work around this topic
that would be largely agnostic to the format, such as debugger UIs and
complex type visualizers. Landing something asm.js early would let that
ecosystem have time to develop, giving WebAssembly a head start.
>
> 3 is, I bel
;t be
> interpreting it.
>
> Dan
>
>
> On Wed, Mar 9, 2016 at 5:01 PM, Charles Vaughn > wrote:
>
>>
>>
>> On Wednesday, March 9, 2016 at 11:45:53 AM UTC-8, Alon Zakai wrote:
>>>
>>> For 1, I think the burden here should be on the browser d
Hi Thomas,
So that's a limitation of source maps, it only provides source code
information, not compiled type layout. I'm currently working on a PR that
can generate supplemental type layout at compile time for dumping objects
while debugging, and should have some code available for that later
I've got a PR out each for the fastcomp and base emscripten changes to
enable this system.
It should be usable, you'll need both the fastcomp and emscripten work
Fastcomp:
https://github.com/hackcasual/emscripten-fastcomp/tree/cvaughn_emdebug_work
Emscripten: https://github.com/hackcasual/emsc
On compression, I believe that the demo with the launch announcement got
around this bby loading wasmgz and memgz, so you're not alone in terms of
hacks :)
On Wednesday, March 16, 2016 at 1:46:50 PM UTC-7, Floh wrote:
>
> I have updated the Oryol samples page with WebAssembly versions built with
So I've gotten a chance to try this, but on test code it seems to enter an
infinite loop. I left it running overnight. Is there some steps I can take
to debug what's being run and why?
On Tuesday, March 8, 2016 at 9:06:48 PM UTC-8, Alon Zakai wrote:
>
> For an interpreter, there's the emterprete
Thanks, that may have been it. I'll take a look.
On Sunday, March 27, 2016 at 2:43:25 PM UTC-7, Alon Zakai wrote:
>
> Jukka just pushed a windows-specific fix for infinite-looping, so this
> might work for you now.
>
> On Wed, Mar 23, 2016 at 2:43 PM, Charles Vaughn > wro
Might be worth looking into leveraging TextEncoder/TextDecoder for browsers
that support it
On Thursday, March 31, 2016 at 3:25:47 PM UTC-7, Brion Vibber wrote:
>
> If I'm reading the code correctly, embind's marshaling code currently just
> assumes Latin-1 encoding for std::string, which is inc
I've seen cases with short numeric message exceptions when I fail to update
my .mem file.
On Monday, April 4, 2016 at 10:41:13 AM UTC-7, Alon Zakai wrote:
>
> Also, the thrown '5' should have a stack trace that you can view in the JS
> console. Might be easiest in the debugger as Christopher sug
Can you share code, or at least the output JS? there's a lot of factors
that will cause Emscripten built JS to perform poorly.
On Thursday, April 7, 2016 at 4:41:13 PM UTC-7, Gareth Morgan wrote:
>
> I am experimenting with using Emscripten generated code in my Javascript
> application. The resu
Firefox seems better
> (8ms).
>
>
>
> On Thursday, April 7, 2016 at 5:12:00 PM UTC-7, Charles Vaughn wrote:
>>
>> Can you share code, or at least the output JS? there's a lot of factors
>> that will cause Emscripten built JS to perform poorly.
>>
>> On T
Since Chrome takes a different approach to handling asm.is, you're always going
to see some pretty big variance. For general investigation, I've found the
allow-natives option to be helpful as that surfaces control over the JS
optimizer. You can see more about that here:
https://github.com/petk
First of all, let me preface this by saying the security of Emscripten
running in a modern browser is excellent, stack smashing and ROP are
totally mitigated by the fact that Emscripen runs on top of the JavaScript
VM. Emscripten, even with inline JavaScript is compatible with CSP, which
can fu
Brion does a better job than I did conveying what I was looking at. This is
about what a malicious input attack would look like on Emscripten. This
particular is interesting since it shows how, in the right circumstances,
an attacker can redirect control flow, though in a greatly restricted way
table than needed, and fill it with aborting
> stubs, and randomize the location of the actual function pointers in there.
> This would have some overhead, though.
>
> On Sun, Apr 24, 2016 at 3:33 PM, Charles Vaughn > wrote:
>
>> Brion does a better job than I did conveyin
I believe TBB includes x86 specific assembly code, so it won't work.
On Tuesday, May 10, 2016 at 10:22:48 AM UTC-7, François Ruty wrote:
>
> ok thanks I'll keep you updated when I have news, in next couple of days
>
> On Tue, May 10, 2016 at 6:43 PM, Alon Zakai > wrote:
>
>> 1. Emscripten support
So with embind it generates a wrapper if you bind a pointer. This doesn't
work with variables inside emscripten code.
In the past I've done this with casting from an int, something like
void dumpObject(uint32_t ptr) {
real_dumpObject((MyClass *)(void *)(ptr)));
}
You might also be able to use
At Tableau, we've seen issues with CMake/Ninja building multiple .js files
(test suites) and an empty cache. No bugs, but it does end up building the
same cached libraries multiple times.
On Friday, July 1, 2016 at 3:19:43 PM UTC-7, Floh wrote:
>
> I did a few test runs with the Oryol samples, 3
You can do it with something like this
uint32_t objID = ++globalID;
val someJSObject;
val::global("MyObjectTracker")[objID] = someJSObject;
EM_ASM_INT({
var objToUse = MyObjectTracker[$0];
}, objID);
On Friday, July 1, 2016 at 4:44:51 AM UTC-7, Reuben Scratton wrote:
>
> Thanks for the reply
or: undefined is not an object (evaluating
> '__emval_register') error:undefined
>
>
> I have definitely declared a global Object named MyObjectTracker in my
> javascript (in the shell file).
>
>
>
>
> On Tuesday, July 5, 2016 at 7:43:24 PM UTC+1, Charles
I'm posting a snippet I use to convert the obscure exceptions messages when
exception handling is disabled to a string value. Since this relies on
re-entering the Emscripten environment after its in a bad state, it's
possible that some exceptions can't be dumped this way, but for those that
ret
I've built my companies internal Emscripten oriented codebase with
Binaryen, resulting in an output of ~2MB. Benchmarking time spent to
compile the WebAssembly module in Chrome canary shows around 1 second.
While its not exactly the same (parse instead of compile), the script
streamer thread ti
nd wasm (which should include parsing
> and JIT) that can help.
>
>
> On Fri, Jul 29, 2016 at 8:21 AM, Charles Vaughn > wrote:
>
>> I've built my companies internal Emscripten oriented codebase with
>> Binaryen, resulting in an output of ~2MB. Benchmarking time sp
Are there benchmarks for WASM parsing speed?
On Friday, July 29, 2016 at 2:39:59 PM UTC-7, Charles Vaughn wrote:
>
> I used console.time and console.timeEnd around the wasm.instantiateModule
> call
>
> On Friday, July 29, 2016 at 1:32:51 PM UTC-7, Alon Zakai wrote:
>>
e been a common source of questions. Marked this
> down as https://github.com/kripken/emscripten/issues/4456
>
> 2016-07-12 1:05 GMT+03:00 Charles Vaughn >:
>
>> I'm posting a snippet I use to convert the obscure exceptions messages
>> when exception handling i
in your codebase.
>
> On Fri, Jul 29, 2016 at 2:53 PM, Charles Vaughn > wrote:
>
>> Are there benchmarks for WASM parsing speed?
>>
>>
>> On Friday, July 29, 2016 at 2:39:59 PM UTC-7, Charles Vaughn wrote:
>>>
>>> I used console.time and conso
Speaking generally of build processes, Emscripten will run into issues
where a build process generates a native platform executable to build an
intermediate result. If you can stop the build right before the generation
and resume it right after, you can generate your own output.
I've got to be
, August 1, 2016 at 9:17:15 AM UTC-7, Charles Vaughn wrote:
>
> Hi Alon,
>
> JS time is tricky especially in Chrome. I'll try to strip it down and get
> better numbers with D8.
>
> On Monday, August 1, 2016 at 9:13:21 AM UTC-7, Alon Zakai wrote:
>>
>>
Interesting code generated I found while investigating some size
optimizations:
function ila(a,b){a=a|0;b=b|0;mha(a,b+88|0);return}
function jla(a,b){a=a|0;b=b|0;mha(a,b+-4+88|0);return}
function kla(a,b){a=a|0;b=b|0;mha(a,b+-12+88|0);return}
>From the context, these are different levels of vtab
backend does its own thing. So this is something we should be
> optimizing in the asm.js optimizer, but somehow aren't.
>
> If you don't intend to take a look at this yourself, I'd like to, a small
> testcase showing the issue would be great.
>
> On Thu, A
WebAssembly is still not generally available on desktop, expect it to lag
behind on mobile. I suspect that the reported size savings (~30%) reduction
in wireless radio usage will dominate all but the most CPU intensive
applications.
On Tuesday, September 6, 2016 at 4:06:30 AM UTC-7, Gaurav Dewa
If you're struct is packed (or you know the padding points) and contiguous,
you can use a DataView (
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView
) to wrap a slice of the underlying buffer of the various HEAPs.
Something like:
var view = new DataV
You can also go via the HEAP objects, so
>
> event.time = HEAPF64[addr>>3];
> event.name = Pointer_stringify(HEAP32[addr+8 >> 2]);
> event.thread_id = HEAP32[addr+12 >> 2];
> event.type = HEAP8[addr + 16];
> event.core_id = HEAP8[addr + 17];
>
> 2016-09-21
I added a simple called function tracker. It works by emitting stores into
a preallocated memory segment. Since my code base makes substantial use of
duplicate function elimination, there's some hacks to allow dead functions
to still be eliminated. I'll see if I can tease that out and make the
, October 31, 2016 at 10:59:58 AM UTC-7, Charles Vaughn wrote:
>
> I added a simple called function tracker. It works by emitting stores into
> a preallocated memory segment. Since my code base makes substantial use of
> duplicate function elimination, there's some hacks to allow dea
I believe you need at least Visual Studio 2013. If you've got that
installed, make sure you're running from a VS command prompt.
On Tuesday, November 1, 2016 at 11:34:46 AM UTC-7, Mark Sibly wrote:
>
> Hi,
>
> I'm trying to to get wasm output going on windows but am having a few
> problems.
>
>
Anything that uses processor specific intrinsics won't work with Emscripten.
There is support for SSE 3 and below, but see details
here: https://kripken.github.io/emscripten-site/docs/porting/simd.html
Especially if you're not using it in a browser with built in SIMD support,
don't expect it to
using a
> visual studio developer console (and 'cl' works) and cmake still can't find
> the compilers.
>
> I suck at this stuff...
>
>
> On Wed, Nov 2, 2016 at 11:17 AM, Charles Vaughn > wrote:
>
>> I believe you need at least Visual Studio 2013.
You might also need to fuss with the build script. It's trying to build
with VS2010, but I've successfully built the more recent Emscripten trees
with VS2015.
On Tuesday, November 1, 2016 at 4:00:03 PM UTC-7, Charles Vaughn wrote:
>
> Depending on the install of VS2015, it may
gt;> HEAP64?
>>>
>>> Thanks!
>>>
>>>
>>> On Wednesday, September 21, 2016 at 5:23:48 PM UTC-4, Robert Goulet
>>> wrote:
>>>>
>>>> Thanks guys, the code works as expected now. I didn't get back as much
>>>>
Module.HEAPU8.buffer will give you the underlying buffer
var mapped_buffer = new Uint8ClampedArray(Module.HEAPU8.buffer, buffer, dim
* dim * 4)
On Friday, November 11, 2016 at 8:12:24 AM UTC-8, Philipp Gloor wrote:
>
> But what would the code look like for this? Because the variable buffer is
1) You can follow the item to track integration of WebAssembly with JSC
here: https://bugs.webkit.org/show_bug.cgi?id=146064 . asm.js works fine in
Safari (though I've run into crashes with Safari on iOS 7), it's just not
explicitly validated.
2) binaryen does it
thusly:
https://github.com/We
Try -s ALLOW_MEMORY_GROWTH=1 as a linker flag
On Wednesday, November 16, 2016 at 10:45:46 AM UTC-8, Gaurav Dewan wrote:
>
> Thanks Charles
>
> about (3) - is there any emscripten flag to generate wasm with "grow
> memory" capabilities (or is the total memory size fixed at build time) to
> reduce
Do you have example code? Using emscripten::val with strings will have a
very high overhead in terms of moving strings into and out of the
Emscripten heap. If you're just looking at exposing large homogenous arrays
of int's/floats/doubles you can use ArrayBuffer based views into the
Emscripten
This is a trick I came up with while debugging some memory corruption,
using JS
Proxies
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
you can break on arbitrary memory access.
A gist demonstrating it is
here: https://gist.github.com/hackcasual/c0b8ae2
What version of IOS? I believe iOS Safari 7 (years old at this point) would
crash with Emscripten built code.
On Friday, January 6, 2017 at 7:24:24 AM UTC-8, Brian Gavin wrote:
>
> Hello,
> I have an ASMJS app that runs well on everything but on the IPad. When I
> run it on the IPad sometimes
One of the benefits of running on top of a VM.
On Thursday, January 5, 2017 at 1:52:58 PM UTC-8, Alon Zakai wrote:
>
> Nice idea!
>
> On Thu, Jan 5, 2017 at 11:27 AM, Charles Vaughn > wrote:
>
>> This is a trick I came up with while debugging some memory corrupti
On Saturday, January 7, 2017 at 2:04:13 PM UTC-8, Brendan Bohannon wrote:
>
> I have recently been using Emscripten for building some personal projects
> as a test, but have noted some various issues.
> version = 1.35.0
>
You mention testing WASM. 1.35.0 doesn't support that. In any case try
u
>
>
>
>> slow compilation times:
>> * compiling takes a fairly long time if compared with native compilers,
>> such as MSVC or GCC.
>> * ex: when compiling a 200 kLOC program, compilation takes a decent
>> number of minutes.
>> ** program is most a basic Minecraft-style 3D engine (voxel-based).
able to generate both
ninja projects and Visual Studio ones from the same source.
On Monday, January 9, 2017 at 6:58:41 PM UTC-8, Brendan Bohannon wrote:
>
> On 1/9/2017 5:08 PM, Alon Zakai wrote:
>
>
>
> On Sun, Jan 8, 2017 at 10:03 PM, Charles Vaughn > wrote:
>
>>
Sounds like you may have run into a problem I've hit as well. We've got
some internal changes that work around this, but we were hesitant about
upstreaming them since it didn't seem to be impacting anyone else. Our
local emar looks like this, if it finds an rsp file, it then reformats the
path
I've done this with a mini AOT toy I built. In addition to that, the JS
codegen makes assumptions about legalization passes that have been run. In
particular I believe the Julia project got bit by 64bit int instructions.
You'd also definitely want to baby the relooper, if you give it very
branc
Try the --profiling-funcs flag with emcc. The output is still optimized,
but with original mangled function names. I believe Firefox will show
demangled names in its devtools.
On Thursday, February 23, 2017 at 7:37:25 AM UTC-8, Benjamin Ling wrote:
>
> I notice that during build, my output folde
I would like to see the Massive benchmark updated with WASM. The challenge
is there are a couple of ways of starting up WebAssembly, so trickier to
measure.
On Thursday, March 16, 2017 at 1:41:57 PM UTC-7, samtheel...@gmail.com
wrote:
>
> 1) I observed that Chrome Canary is faster at webassembl
If the exception being thrown is based on std::exception, this might work,
function whatEmscriptenException(ptr) {
// 8 should be the vtable offset for the what function
var fPtr = Module.HEAPU32[(Module.HEAPU32[(ptr) >> 2] + 8) >> 2];
console.info(Module.AsciiToString(Module.dynCall_i
I haven't found python's SimpleHTTPServer to have large file problems, but
it definitely has problems serving more than 1 request. If you've got
another tab open using that server it might cause that issue.
On Wednesday, March 29, 2017 at 6:41:35 PM UTC-7, Bill Yan wrote:
>
> Hi Thank you,
>
> I
Method functions are just functions that take a pointer to the object in
the first argument representing 'this', there's nothing more special about
them than that. As long as the primitive types match, it will work.
On Monday, April 10, 2017 at 1:15:27 PM UTC-7, Alon Zakai wrote:
>
> In general,
I think it's been brought up before. Your biggest timesink is going to be
the final Javascript generation since that's not actually an LLVM process.
Even the Javascript LLVM backend isn't amenable to distcc type stuff since
it's monolithic. In theory side modules would let you have a faster
dev
Keep in mind charCodeAt is returning UTF-16 values, so it's not safe to
store its return values in a byte, you'll need to store them in a 16-bit
value at minimum.
On Tuesday, May 16, 2017 at 2:28:50 PM UTC-7, Giovanni Parra wrote:
>
> They are not part of the previous character. If the previous
You can build it without DCE (just use MAIN_MODULE=1) and see what the
mangled names are. You should be able to preserve them that way. In the end
it's just functions defined in LLVM bitcode.
On Sunday, May 21, 2017 at 6:38:48 AM UTC-7, weitjong wrote:
>
> Sorry to hijack this discussion but it
The biggest difference is SFE uses helper functions, since we need to deal with
finding pointers. It would be possible to generalize DFE and add a specific
optimization to elide helpers but we haven't done that.
--
You received this message because you are subscribed to the Google Groups
"emsc
Can't you set EM_CACHE? We override it as part of our internal build to
supply a prebuilt version.
On Friday, August 25, 2017 at 11:41:47 AM UTC-7, Alon Zakai wrote:
>
> There is no current option for that. Why do you need it, what's the use
> case for the different libraries? Maybe we should ad
https://kripken.github.io/emscripten-site/docs/contributing/contributing.html#contributing
On Tuesday, August 29, 2017 at 9:27:09 AM UTC-7, JörTëm. wrote:
>
> Hello, I would like to contribute to emscripten, but I don't know where to
> start. Does anyone know how a beginner like me can start, and
Mocked up a quick PoC to test whether LLVM's ubsan would work with
Emscripten.
You can find it
here: https://gist.github.com/hackcasual/7de2f357714505061506df01923f99cd
Compile and run like so:
c:\dev>em++ testub.cc -fsanitize=signed-integer-overflow && node a.out.js
Overflow happened 2147483
You could get rid of the |0 on HEAP[x]|0 and on constant expressions
(like u=u+32|0).
You can also forward propagate the integer coercion to elide the function
preambles that coerce their parameters. An example would be taking
function pG(a,b){a=a|0;b=b|0;return $FU(a,b,1217,4169,4177)|0}
And
enabled? Are there other flags that one would have
> besides -fsanitize=signed-integer-overflow?
>
> 2017-10-18 2:07 GMT+03:00 Charles Vaughn >:
>
> > Mocked up a quick PoC to test whether LLVM's ubsan would work with
> > Emscripten.
> &g
You might be better off malloc'ing the buffer then using subarray [1] to
avoid copying back and forth.
[1]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/subarray
On Tuesday, October 24, 2017 at 6:25:27 AM UTC-7, Andrew Varga wrote:
>
> Thank you fo
Having done a bunch of work on minimizing asm.js foot print, DCE is great,
but it's only good on determining stuff known at compile time. You could
have a function like:
if (localeFormat.isLTR) {
formatTextLTR();
} else {
formatTextRTL();
}
Then if you never run in an environment using RTL,
Getting this error in Chrome 64 and Chrome Canary:
The source list for Content Security Policy directive 'default-src'
contains an invalid source: ''wasm-eval''. It will be ignored.
runtimeweb.pretty.js:1063 [Report Only] Refused to compile or instantiate
WebAssembly module because 'wasm-eval' i
s
> this a special case somehow?
>
> On Mon, Feb 5, 2018 at 1:07 PM, Charles Vaughn > wrote:
>
>> Getting this error in Chrome 64 and Chrome Canary:
>>
>> The source list for Content Security Policy directive 'default-src'
>> contains an invalid source
I will say the largest source of native vs. asm.js breaking differences
I've found have been due to initializer order. Depending on it is
undefined, but it sucks to have tests pass on the x86 build, but crash in
the asm.js one. I've got a tool that reverses the order of __ATINIT__ to
quickly ch
It would be nice if this was added using the
Performace.mark/Performance.measure API and generally turned on.
On Wednesday, February 21, 2018 at 3:47:21 PM UTC-8, Alon Zakai wrote:
>
> There are some existing hooks, like Module.onRuntimeInitialized which you
> can start a timer in. See also the
So first of all, I'd say you're not going to want to use val for anything
remotely performance sensitive. There's a lot of overhead marshalling
values back and forth.
Directly to your point, val can represent any javascript value, including
those for which comparator operators don't make sense.
During a perf investigation on the product I work on, we saw 64 take 400ms
for compiling, while 66 showed 200ms. We didn't have numbers for 63 and
just assumed it was general perf progress.
On Wednesday, March 7, 2018 at 6:48:56 AM UTC-8, jj wrote:
>
> Yikes, this sounds really bad, haven't hear
Look for a .mem file in chrome network tools or look for a long array in
the javascript file that initializes the memory. Offset 434 contains the
string "%s\0", Offset 384 contains "Hello World!\n."
On Friday, April 27, 2018 at 11:13:15 AM UTC-7, Vivek Pradhan wrote:
>
> Hey guys!
>
> I am t
I believe you are hitting undefined
behavior: https://isocpp.org/wiki/faq/ctors#static-init-order
On Monday, August 20, 2018 at 9:10:25 AM UTC-7, Юрий Катков wrote:
>
> Hi!
> I compile my C++ project to wasm using emscripten.
> This project is consist of several source files which should be linke
Looking into why EVAL_CTORs isn't helping with my project, I've come across
a limitation that seems to only exist for WASM, not asm.js. Notably some of
the initializers in my project invoke malloc (I believe by way of shared
pointer initialization). It looks like malloc invokes sbrk (which is
e
, I believe they are
> all collapsed into a single ctor anyhow, so that model would need to change
> to allow such optimization.
>
> On Mon, Aug 20, 2018 at 5:58 PM Charles Vaughn > wrote:
>
>> Looking into why EVAL_CTORs isn't helping with my project, I've come
&
REALLOC_SIZE allows a normal malloc to be done, so
> things are freeable normally, that would be better.
>
>
>
>
>
> On Tue, Aug 21, 2018 at 4:01 PM Charles Vaughn > wrote:
>
>> Thanks for that info. With that and digging in the code, I think I've got
>>
gzipped size by a little that it might be worth it for startup time,
> but I haven't measured that carefully.)
>
> On Tue, Aug 28, 2018 at 10:47 AM Charles Vaughn > wrote:
>
>> I thought about using malloc without reserving first, but as you say not
>> bein
I'd move the 2018 out of the header and into a something like a NOTICES or
COPYRIGHT file, since that also covers new and modified files.
On Friday, August 31, 2018 at 3:55:25 PM UTC-7, Sam Clegg wrote:
>
> I'm proposing that we add a short copyright header to all emscripten
> sources. This hel
You can avoid needed a user to deploy a separate JS file by using "inline
worker" techniques. You can see a good example
here: https://www.html5rocks.com/en/tutorials/workers/basics/
On Saturday, September 22, 2018 at 3:23:28 AM UTC-7, Floh wrote:
>
> Sorry for being slightly off-topic, but ma
I've got this snippet I use to decode exception pointers:
function whatEmscriptenException(ptr) {
// 8 should be the vtable offset for the what function
var fPtr = Module.HEAPU32[(Module.HEAPU32[(ptr) >> 2] + 8) >> 2];
console.info(Module.AsciiToString(Module.dynCall_ii(fPtr, ptr)));
}
Keep in mind often times mobile browsers will be more stingy with memory
(and iOS doesn't offer an option to get a rough estimate of available RAM),
as well as being more aggressive around killing your tab in the background.
On Thursday, January 31, 2019 at 7:50:58 PM UTC-8, caiiiycuk wrote:
>
>
Bloaty has experimental support for WASM: https://github.com/google/bloaty
On Wednesday, February 6, 2019 at 12:13:14 PM UTC-8, Goran Milovanovic
wrote:
>
> My output is different:
>
> ===
> func: _mesh_draw
> [binary-bytes] : 143
> [total]: 62
> [vars] : 1
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 access WASM's heap in a
serializable way. From those restrictions, we're able to use a python
server t
Looks like you're missing a linker input, do you have -lGLESv2 on your link
command?
On Monday, February 10, 2020 at 1:01:11 AM UTC-8, Tim Luther Lewis wrote:
>
> Thanks for the responses guys but unfortunately, I'm still getting
> 'anthraciteWASM.js:8995 missing function: glBlitFramebuffer'
>
>
99 matches
Mail list logo
