Earlier quoted context omitted.
Can you open a socket or write to the file system with WASM ?
You can only do what the browser sandbox provides, no direct access to the underlying operating system, only to HTML/JS APIs.
Goodbye PNaCl, Hello WebAssembly
301–310 of 352 posts
Re: Goodbye PNaCl, Hello WebAssembly
#302Earlier quoted context omitted.
I don't know enough about ssh for Chrome and bash for Windows to get your point. Isn't bash for Windows (as part of WSL?) free? What is it that costs more than $5 using bash for windows but is free with ssh for Chrome? Genuinely interested, I'm on OSX mostly but I'm WSL curious.
I interpreted that as them not having access to a Windows machine and wanting to try out the experience for themselves before attempting to teach someone else.
Re: Goodbye PNaCl, Hello WebAssembly
#303Earlier quoted context omitted.
Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.
You must have been working with at least quite young people or something. My experience goes the other way. I've seen people who bought a new computer because their fans were running at max and the reason for that was that they were full with dust and dog hair.
Re: Goodbye PNaCl, Hello WebAssembly
#304Can somebody ELI 5 what is the benefit of WebAssembly vs Asm.js?
For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular memory accesses with WebAssembly on 64-bit computers. (For those interested in going past ELI5, they do this by allocating a large chunk of virtual address space, such that any out of range pointers will land somewhere in that space (WebAssembly currently only has 32-bit pointers). Some of the space is filled with memory, and the rest causes a controlled signal/exception so the engine can safely terminate the instance.)
Re: Goodbye PNaCl, Hello WebAssembly
#305Earlier quoted context omitted.
You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of…
Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaScript. So until those are a thing, it'll be extremely ugly to work with WASM Libraries in JavaScript.
Re: Goodbye PNaCl, Hello WebAssembly
#306>We will remove support for PNaCl in the first quarter of 2018 While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad
Re: Goodbye PNaCl, Hello WebAssembly
#307Earlier quoted context omitted.
Incredibly interested in the answer to that question as well. Go will not have a future in regards to web development if they don't find a solution for the GC issue in wasm. I assume (and hope) that's a bigger topic compiler-team internally as well currently.
FYI, https://go.googlesource.com/gollvm/
Re: Goodbye PNaCl, Hello WebAssembly
#308Earlier quoted context omitted.
It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?
What's not to like? Why couldn't we just create a system compatible with Java bytecode, and just replace the APIs over which it interacts withthe system (as Android has done)? That'd make it even possible to reuse old applets with just a tiny shim around them. And it'd keep compatibility with a huge environment of libraries and languages.
Because Java bytecode is not a good target for many languages, such as C and C++, for one. It lacks unsigned and value types.
> just replace the APIs over which it interacts withthe system (as Android has done)?
That still leaves a whole bunch of APIs that are duplicated.
> That'd make it even possible to reuse old applets with just a tiny shim around them.
The number of people who want to do that is far, far less than the number of people who want to compile existing C++ codebases.
> And it'd keep compatibility with a huge environment of libraries and languages.
While sacrificing compatibility with the even huger existing JS environment.
Re: Goodbye PNaCl, Hello WebAssembly
#309Earlier quoted context omitted.
Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.
You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve? I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endiann…
You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".
> You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?
1. Compiling existing C++ codebases.
2. Multiplication and division are not identical for unsigned and signed values. Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!
Re: Goodbye PNaCl, Hello WebAssembly
#310Earlier quoted context omitted.
It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?
What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important. Can't we just make DOM bindings for the JVM and reuse the huge existing library base?
Almost nobody is asking for this, compared to the huge number of people asking to compile C++ codebases.