jfbastien

6 ms·

1.
by jfbastien 2y ago
Dang, will fix when I get home! Thanks Nick, and hi!
2.
by jfbastien 2y ago
10 years ago, a coworker had a really hard time root-causing a bug. I shoulder-debugged it by noticing the bit patterns: it was a miscompile of LLVM itself by GCC, where GCC was using an x87 fldl/fstpl move for a union { double; int64;
3.
by jfbastien 2y ago
Typo, I fixed it in the new draft: https://isocpp.org/files/papers/D3477R1.html
4.
by jfbastien 2y ago
I added a mention of TI's hardware in my latest draft: https://isocpp.org/files/papers/D3477R1.html
5.
by jfbastien 2y ago
As mentioned by others, we've dropped trigraph and deprecated rand (and offer an alternative). I also have: * p2809 Trivial infinite loops are not Undefined Behavior * p1152 Deprecating volatile * p0907 Signed Integers are Two's C
6.
by jfbastien 2y ago
Yes, I'm trying to figure out which are still relevant and whether they target a modern C++, or intend to. I've been asking for a few years and haven't gotten positive answers. The only one that been brought up is TI, I added
7.
by jfbastien 2y ago
Hi! Thanks for the interest on my proposal. I have an updated draft based on feedback I've received so far: https://isocpp.org/files/papers/D3477R1.html
8.
by jfbastien 2y ago
Hi! I'm JF. I half-jokingly threatened to do IEEE float in 2018 https://youtu.be/JhUxIVf1qok?si=QxZN_fIU2Th8vhxv&t=3250 I wouldn't want to lose the Linux humor tho!
9.
by jfbastien 3y ago
Having it in .rodata is much nice than having it in .text
10.
by jfbastien 3y ago
No, I’m a blade runner character.
11.
by jfbastien 3y ago
You sound like fun at parties :p I’m glad you liked the oration and technical content though!
12.
by jfbastien 3y ago
This is the way ;)
13.
by jfbastien 3y ago
I will do prompt injection in the next talk, just for you
14.
by jfbastien 3y ago
Good thing this was covered in the talk
15.
by jfbastien 3y ago
I’m glad you appreciated me saying exactly this in the talk
16.
by jfbastien 9y ago
That is entirely incorrect for the WebAssembly CG and WG.
17.
by jfbastien 9y ago
I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those sysc
18.
by jfbastien 9y ago
Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/mast
19.
by jfbastien 9y ago
Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community&
20.
by jfbastien 9y ago
A few ways that come to mind: 1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I
21.
by jfbastien 9y ago
> What's the reasonable thing to do when a grow-memory instruction returns -1? A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you s
22.
by jfbastien 9y ago
Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.
23.
by jfbastien 9y ago
In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then
24.
by jfbastien 9y ago
Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeat... It now links to here: https://github.com/WebAssembly/design/issue
25.
by jfbastien 9y ago
You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an i
26.
by jfbastien 9y ago
This is pure nonsense. WebAssembly is no more obscure than asm.js or minified JavaScript. "Binary" versus Unicode-enabled minified and transformed "source" is the same thing. You can get text out of WebAssembly as well a
27.
by jfbastien 9y ago
Correct, shared memory and atomics are likely the first big post-MVP feature: https://github.com/WebAssembly/threads/blob/master/proposals...
28.
by jfbastien 9y ago
Source map is totally optional! It provides zero help in understanding asm.js or minified JS. I see what you're saying about binaries being opaque blobs, but I just don't see how that's different from asm.js or minified JS. K
29.
by jfbastien 9y ago
WebAssembly is as Turing-complete as JavaScript is, and has fewer APIs. The only API it has JS doesn't really is grow_memory, and even that can kinda be done with ArrayBuffer. I'm not sure what you think makes it the harbinger of
30.
by jfbastien 9y ago
FWIW I trust that the numbers were good when the Google and Mozilla folks gathered them, but I had nothing to do with numbers! In particular, I haven't looked into validation. JSC doesn't treat asm.js any differently than JavaScri

More ›