mess, even after
much effort on my part to remove uses of glibc only functions). In fact, it
is this reason libuv is disabled for PNaCl.
Richard Diamond
On Thu, Jul 31, 2014 at 7:23 PM, Brian Anderson
wrote:
> Neat!
>
> I'm particularly interested that you've ported Rust
arts of the Pepper API are located here
<https://github.com/DiamondLovesYou/rust-ppapi> (also a WIP).
A simple "Hello, world!" is located here
<https://github.com/DiamondLovesYou/rust-pnacl-hello-world>.
Regards,
Richard Diamond
___
On Thu, Jan 16, 2014 at 5:33 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> doesn't the opencl notation in the 16x case require 16^16 orders to be
> supported (even if its implicit in the parser support?)
> That said, if it can be engineered in sane way, sure, that'd be neat, how
> do
However, if you were just referring to being able to access individual
elements by an index, yeah, that's a bruise from tuple usage and sadly not
yet fixable by generics.
Richard Diamond
On Thu, Jan 16, 2014 at 4:02 AM, Liigo Zhuang wrote:
> let tuple = (1.0f32, 2.0f32, 3.0f32, 4.0f32)
On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay wrote:
> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
> wrote:
> >
> > They do with #[simd]. Though I think it would be worth considering
> whether
> > all tuples of a single primitive type should be automatically co
operation just be
> shuffleSimdVector(a,b,masktuple) ?
> seems a bit more human friendly than a mix of @ and <- and ->
>
> I'm a bit confused about the l/rvalue remark, could you explain more?
>
>
> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond <
> wich.
ic
> In it's full generality would be lovely, it's a much more friendly
> operation that people can use to get started with doing simd in a somewhat
> user friendly way.
>
> point being: I support there being better shuffle simd support / simd
> support period :), though h
Basically the idea here is to support shuffling for SIMD types in a way
that can be easily lowered to IR (LLVM's shufflevector requires the mask be
a vector of constants, so an intrinsic function is out of the question),
however I image this sugar could extend to tuples with multiple types.
Some e
