Just came accross this good presentation:
http://www.youtube.com/watch?v=gfCtbGiHcg0
A question poped into my head: where could I find rust stickers ?
-
Gaetan
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the end what
the official stance should be. There is no valid reason other than lack of
manpower and / or language
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
2014/1/14 Gaetan gae...@xeberon.net
Just came accross this good presentation:
http://www.youtube.com/watch?v=gfCtbGiHcg0
A question poped into my head: where could I find rust stickers ?
I was wondering the same thing! I love stickers and I definitely want a
Rust sticker :D
--
Flavio
If you organize a Rust meetup near you and email Brian Anderson or one
of the other core Rust developers who work for Mozilla, I suspect they
would be happy to send you a batch of stickers to hand out. That's one
way, anyway :-)
Cheers,
Tim
On Tue, Jan 14, 2014 at 9:53 AM, Flaper87
Have you considered selling the stickers through something like
DevSwag.com? I'm sure Yehuda can get you connected ;)
On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier catamorph...@gmail.comwrote:
If you organize a Rust meetup near you and email Brian Anderson or one
of the other core Rust
On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson bander...@mozilla.comwrote:
Let's add `SyncChan` which is a bounded multi-producer single-consumer
queue backed by a ring buffer. This supports `send`, which blocks by
default, and `try_send` which returns an enum representing whether the send
Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system for
this proposal, right? I started staring at that and it's pretty subtle
(though I may have been looking at it wrong)
1) do rust tuples actually map to the llvm simd vector types?
2) so this would
On Tue, Jan 14, 2014 at 5:56 AM, comex com...@gmail.com wrote:
On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller trop...@bluewin.ch wrote:
intl1,u1 + intl2,u2 = intl1+l2,u1+u2
...
If the result does not fit into an int the compiler throws an error.
To resolve an error, you can:
-
On 14/01/14 01:50, Palmer Cox wrote:
On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller trop...@bluewin.ch
mailto:trop...@bluewin.ch wrote:
Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Do you know what undefined behavior is? It doesn't mean unspecified.
to further elaborate, from the perspective of translating the syntax to
llvm ir,
the proposal seem to correspond to
shuffleVector(aV,aV,maskVectorLiteral), while the llvm instruction allows
shuffleVector(aV,bV,maskVectorLiteral), and you need the latter to express
stuff like the _mm256_shuffle_pd
On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system
for this proposal, right? I started staring at that and it's pretty subtle
(though I may have been looking at
On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
wich...@vitalitystudios.com wrote:
They do with #[simd]. Though I think it would be worth considering whether
all tuples of a single primitive type should be automatically considered
#[simd] and be lowered to a LLVM vector type. In fact one way
good points all!
why not have the 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
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 01:50, Palmer Cox wrote:
On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller
trop...@bluewin.ch
mailto:trop...@bluewin.ch wrote:
Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Do you know what undefined
Already too much I guess.
Gaetan gae...@xeberon.net wrote:
rust need llvm, make, wget, bash script, python, autotools... it's just
a
matter of choice of which external tool you accept to rely on
-
Gaetan
2014/1/14 George Makrydakis irrequie...@gmail.com
Lack of manpower. Correct. As
Take a look at
http://static.rust-lang.org/doc/master/rust.html#lvalues-rvalues-and-temporaries
or http://en.wikipedia.org/wiki/Value_(computer_science)
On Tue, Jan 14, 2014 at 2:14 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
good points all!
why not have the operation just be
Then, as we discuss on the replies to this, shouldn't there be a task force
dealing with the matter for what it concerns Rust? Personal preferences lead to
conflicts; reaching a consensus requires a wider set of options discussed
inproper setting and community audience.
So far, there is little
comex com...@gmail.com wrote:
On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller trop...@bluewin.ch wrote:
intl1,u1 + intl2,u2 = intl1+l2,u1+u2
...
If the result does not fit into an int the compiler throws an error.
To resolve an error, you can:
- annotate the operands with appropriate bounds
On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
wich...@vitalitystudios.com wrote:
They do with #[simd]. Though I think it would be worth considering
whether
all tuples of a single primitive type should be
good point, SIMD vectors are values where you can't take pointers /
addresses (except when suitable cpu dependent intrinsics are available that
load a value from a memory and do an operation and optionally store it
again )
On Tue, Jan 14, 2014 at 3:09 PM, Daniel Micay danielmi...@gmail.com
On Tue, Jan 14, 2014 at 3:16 PM, Tobias Müller trop...@bluewin.ch wrote:
Lee Braiden leebr...@gmail.com wrote:
On 14/01/14 01:50, Palmer Cox wrote:
On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller
trop...@bluewin.ch
mailto:trop...@bluewin.ch wrote:
Daniel Micay danielmi...@gmail.com
ummm, the whole point of SIMD vector values is they work in register. Sure,
sometimes the register allocator may spill to stack, but while an *ARRAY*
of values of type T can have notion of an address, a SIMD Vector of T
(likely f64/f32/int32/int64) doesn't really have the same idea..
On Tue, Jan
On 14/01/14 17:25, Patrick Walton wrote:
On 1/14/14 1:29 AM, comex wrote:
On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
irrequie...@gmail.com wrote:
Again, note that this rather long thread is about discussing in the
end what
the official stance should be. There is no valid reason other
I just want to point out that there has already been implementations of
swizzling/shuffling,
(https://github.com/jensnockert/rust/commit/d3709e3e7426fc41666e971b35cb683e0de15a79)
the issue back then was just syntax.
If people can agree on a syntax, implementation should be really simple, just
That would be a good start. But are you advocating that it should be third
party tools thatcshould be given guidelines on how to comply? What would be
their incentive to do so? Or should this be used as a basis for creating a
prototype deploying duch information... which would inevitably ask
On 14/01/14 20:51, George Makrydakis wrote:
That would be a good start. But are you advocating that it should be
third party tools thatcshould be given guidelines on how to comply?
What would be their incentive to do so? Or should this be used as a
basis for creating a prototype deploying
this looks like POM :)
I always dreamt of writing a proper build system with such high level
structure, deal with project dependencies, but that is way more complex
than that.
if a project in rust start with this matter, I volunteer to participate to
it.
-
Gaetan
2014/1/14 Lee Braiden
Another point is that we don't really need a massively complicated
build system right now, as far as I know.
I don't know rust well yet, but it's a two-line script to load this data
(excluding comments). Another few lines to figure out whether to build
a library or an executable, another few
Gaetan,
I agree, it's important to think of use cases up-front, and I've tried
to do that below, too. If you can add any necessary features or ideas,
please do. And if Rustics reach consensus that this is the preferred
approach, then we should definitely formalise the decision process about
i read the ninja documentation, and this integrates well with cmake, and do
the majority of the graph stuff required to compile file. i kind of like
it. and i wonder why rust-pkg cannot be extended, for simple project to
generate ninja files...
-
Gaetan
2014/1/15 Lee Braiden
On 15 Jan 2014, at 9:35 am, Eric Reed ecr...@cs.washington.edu wrote:
I'm skeptical about combining Chan and SharedChan. Maintaining that
distinction is useful for expressing the programmer's intent and would
certainly make any analysis that cared to distinguish between single and
multiple
Tell me how many you need (if you want a lot then maybe mention why) and
a shipping address.
On 01/14/2014 05:30 PM, Brian Anderson wrote:
People that need Rust stickers can send me an email off-list.
On 01/14/2014 03:45 PM, Christopher Meiklejohn wrote:
Who do we contact if we're running a
This sounds very promising. Like Gaetan, I believe that a central
package database is a critical piece of infrastructure for the Rust
community. I haven't made any effort in this direction yet because our
packaging tool isn't ready, but I fully encourage people to work on
this. The rust issue
How would that make us lose stack allocated return values?
On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote:
Good point. Make `Chan` a trait with implementers `UniqueChan` and
`SharedChan`?
I suppose the main downside of that solution is that you lose stack
allocated
You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`.
Well, unless DST fixes this. I assume this is the same reason we
return specific instances of iterators instead of an Iteratable trait
object.
jack.
On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu wrote:
fn fooT: Trait() - T
On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt j...@metajack.im wrote:
You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`.
Well, unless DST fixes this. I assume this is the same reason we
return specific instances of iterators instead of an Iteratable
As a follow up, what situation would arise where you'd have to actually
return a Chan trait object?
Constructors are going to return the concrete type UniqueChan/SharedChan.
Functions acting on channels can just use generics, which will allow
returning.
On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed
I was working under the assumption that we'd add UniqueChan - SharedChan
promotion back. I assumed that would be possible since a unified Chan would
be doing it internally.
Does an auto-promoting Chan really do that much for reducing cognitive
load?
The only thing the programmer can skip
39 matches
Mail list logo
