similar to: WebAssembly Opus Decoder

Thanks Timothy. Media Source Extensions were much easier and high-level than using WebAssembly with the Web Audio API. Unfortunately, MSE does not support MIME "audio/ogg" and I had to put my OpusFiles into a WebM container file. What could we do to get MSE support for Ogg Opus files? I created this issue if it helps: https://github.com/w3c/media-source/issues/245. Would be happy to

Chris McGowan wrote: > All thoughts and contributions are welcome, and I'm planning to add a > seeking feature using HTTP range requests: > https://github.com/AnthumChris/opus-stream-decoder/issues/1 You may also be interested in <https://github.com/brion/ogv.js/> (if you're not already aware of it). There might be some useful collaboration possible. > ~140-220K Wasm

Hello. Excuse me. Why CMakeLists.txt from llvm-3.9.1.src does not contain WebAssembly target? So, it is like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ X86 XCore ) but not like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ Webassembly X86

Okay, so where should I send questions for WebAssembly? Is it this mailing list or a different one? I want to ask about how to compile WebAssembly modules with Clang directly, without Emscripten, for situations like what I have currently where I have a problem with generating WebAssembly and/or JavaScript glue code (I have a problem with the gen_struct_info stuff; I asked on the Emscripten

Sean Silva <chisophugis at gmail.com> writes: > On Mon, Jul 3, 2017 at 11:12 AM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Sam Clegg via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >> >> Can you elaborate on semantically what the linker is actually doing for >> >> wasm? >> > >> >

> > This seems interesting, I have a few questions: > > > Has the ISA been finalized yet or is it still a work in progress? Will > there be a fixed number of registers? > The design document has a high-level idea of the ISA, or rather of the AST we're thinking of going with: https://github.com/WebAssembly/design/blob/master/AstSemantics.md The final encoding isn't

Dan Gohman <sunfish at mozilla.com> writes: >> Sorry, I meant why that didn't work with ELF (or what else didn't). >> > > The standard executable WebAssembly format does not use ELF, for numerous > reasons, most visibly that ELF is designed for sparse decoding -- headers > contain offsets to arbitrary points in the file, while WebAssembly's format > is

Hello all, WebAssembly [0] its a new virtual ISA being designed to efficiently run compiled code in web browsers and other things, starting with C/C++, and eventually many other languages [1]. WebAssembly distinguishes itself from other virtual ISAs with optimizations to reduce download size and decode time, strong portability and predictability invariants (for example, the base has no undefined

Hi All, WebAssembly has been around for a while now, it's still being actively worked on and used. I think it's long past time we make it a normal target so that it gets tested on a regular basis. (Most recent random breakage is https://reviews.llvm.org/rL342576 which fails make check with web assembly enabled). Any objections? I'll probably do this next week unless someone raises a

Has anyone attempted to compile R (probably without any OS bindings) to WebAssembly / Emscripten? If so, how far did you get? (would be crazy awesome if you could get all the way to a ggplot bitmap output). If not, is this a waste of time or is there some daylight to doing this? [[alternative HTML version deleted]]

Hi Dan, Sure. That said I think people are just doing it anyhow :) On Wed, Sep 19, 2018 at 3:59 PM Dan Gohman <sunfish at mozilla.com> wrote: > Hi Eric, > > We've been waiting until we stabilize various key interfaces, including > the builtin functions, the C ABI, and the .o file format., as we'd like to > avoid having users using packaged versions of LLVM producing

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My

On Mon, Jul 10, 2017 at 4:13 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry for the belated response. I was on vacation last week. A couple of > thoughts on this patch and the story of webassembly linking. And I'm about to be on (mostly) vacation for next 3 weeks :) > > - This patch adds a wasm support as yet another major architecture besides >

Can you link to docs about the wasm object format? (both relocatable and executable) Also, traditional object file linkers are primarily concerned with concatenating binary blobs with small amount of patching of said binary blobs based on computed virtual (memory) addresses. Or perhaps to put it another way, what traditional object file linkers do is construct program images meant to be mapped

As I recall, the major blocker is that R links against a number of other things (notably BLAS, pcre, etc) so while technically possible (?) I suppose, the universe of things you'd have to compile over and then get working is much larger than just the R internals. I think most people who consider this (including me years ago, as well as the poster of Gabor's message to rdevel) hit that

Hi Sam, First, I want to know the symbol resolution semantics. I can imagine that that is set in stone yet, but just that you guys are still discussing what would be the best semantics or file format for the linkable wasm object file. I think by knowing more about the format and semantics, we can give you guys valuable feedback, as we've been actively working on the linker for a few years

Apple's clang in Xcode 5.1 (as for building with the iOS 7.1 SDK) throws an error about the (gcc-specific?) -fforce-addr option being unknown, which clang now thinks is evil and should abort compilation. It looks like this also hits OS X 10.9 builds, as I see there's a patch for theora in MacPorts for this issue: https://trac.macports.org/ticket/42934 Attached is a quick-fix patch to

Hi all, First off, apologies if this list is not the correct place for this message. Although we have used Xapian with our email services for a long time (over 10 years) we haven't had the opportunity to contribute or participate in the Xapian community until now. We might therefore not be entirely familiar with acceptable protocol here, but we thought others might be interested in a new

This was some time ago: https://stat.ethz.ch/pipermail/r-devel/2013-May/066724.html So probably not hopeless, but I would think it is a lot of work. Gabor On Wed, Feb 20, 2019 at 8:17 AM Todd Wilder <wildert at gmail.com> wrote: > > Has anyone attempted to compile R (probably without any OS bindings) to > WebAssembly / Emscripten? If so, how far did you get? (would be crazy >

Current LLVM crashes (assertion in debug) when emitting debug info in a wasm file. While I realize there's no definitive info on what/how debug info will look when that gets decided on, crashing is probably not the thing it should do. Attached is a patch that makes llvm emit mostly valid dwarf debug info; while there's no debugger that can currently understand this, I think it's a