Congratulations, Aaron! Very exciting!
> And "LVars" sounds familiar... was that something that Lindsey Kuper was
> working on?
Yep. In addition to the POPL paper that Aaron linked to, you can find
everything LVars at http://www.cs.indiana.edu/~lkuper/, or on my blog
under http://composition.a
Brian Anderson writes:
> Hi.
Hi,
> I've been convinced recently that Rust is missing crucial
> documentation of a particular nature: using Rust in practice. I would
> like to have such a standalone guide, and these are some ideas about
> what should be in it.
>
> This is a guide that runs throu
I think this sounds good overall.
However, I don't think we can completely kill the tutorial: I think
we still need a "Getting Started with Rust" document that is an
expanded version of the tutorial section of the same name, and an
abbreviated version of the rest of the tutorial. I imagine this
Hi.
I've been convinced recently that Rust is missing crucial documentation
of a particular nature: using Rust in practice. I would like to have
such a standalone guide, and these are some ideas about what should be
in it.
This is a guide that runs through creating an entire Rust project fro
On Mon, Apr 21, 2014 at 8:24 AM, Patrick Walton wrote:
>
>
> Because `&` is taken to destructure references, we needed another keyword
> to take a reference. Hence, `ref`.
>
> Patrick
>
> Is that explanation of ref given anywhere in the rust-lang tutorial? I
feel like it would have been incredibly
Yes, LVars are part of Lindsey Kuper's PhD thesis work. We had a paper
together on them in this year's POPL:
http://www.mpi-sws.org/~turon/lvish.pdf
Lindsey did the original LVars design, and then we worked together to extend it
to a fuller library implementation called "LVish"; I got to do
Thanks for the welcome. I've been watching Rust from the academic sidelines
with excitement, and I feel very lucky to become part of such a great team!
Aaron
On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson wrote:
> Hey there, Rusticators,
>
> Grand news! Starting today Aaron Turon is joining t
Welcome Aaron! And "LVars" sounds familiar... was that something that
Lindsey Kuper was working on?
On Mon, Apr 21, 2014 at 5:18 PM, Alex Crichton wrote:
> Welcome Aaron! I'm so excited to have you with us!
>
> On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson
> wrote:
> > Hey there, Rusticators
Welcome Aaron! I'm so excited to have you with us!
On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson wrote:
> Hey there, Rusticators,
>
> Grand news! Starting today Aaron Turon is joining the Rust team. Aaron did
> his PhD thesis on concurrency at Northeastern University, where he published
> widel
Hey there, Rusticators,
Grand news! Starting today Aaron Turon is joining the Rust team. Aaron
did his PhD thesis on concurrency at Northeastern University, where he
published widely-noted papers on 'reagents' and 'LVars'. He will be
focusing on making Rust's standard libraries the best they c
> Refcounting is, of course, unsuitable for objects with circular links and I’m
> going to have plenty of them.
You may be interested in the downgrade() method on Rc/Arc along with
the Weak pointers (they allow cycles, but also allow for destruction).
> So I’m thinking about adding per-task aren
Good !
I’m planning to use Rust for some high-performant low-latency server-side code.
It’ll need some complicated data structures for each request, so I’m thinking
about using RC boxes for them. Refcounting is, of course, unsuitable for
objects with circular links and I’m going to have plent
Hey all,
exercism.io is a site where you can try to solve short programming
problems, and then get feedback on your solution from others.
A few people have done some great work to get examples going in Rust,
and now that 0.10 is out, we want to try to ship it. Would anyone mind
checking out the P
Hm, it seems to have precautions to stop mrc from materializing on Thumb1.
I guess I need to take a better look into what's going wrong on my side.
I'll see what I can do with that.
On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton wrote:
> The split stack patches for ARM were recently upstreamed,
Just realised that the following seems to work :
struct Cls<'a> {
vec : &'a ~[~int]
}
impl<'a> Index for Cls<'a> {
fn index(&self,i:&uint)->&'a ~int {
&(self.vec[*i])
}
}
fn main(){}
On Wed, Apr 16, 2014 at 6:23 AM, Artella Coding <
artella.cod...@googlemail.com> wrote:
>
Cool thanks. I had skimmed through the sections you cited, but the problem
was that in my version I was trying to clone by creating a new copy of x as
follows :
impl<'a,T: Clone> Clone for Cls<'a,T> {
fn clone(&self) -> Cls<'a, T> {
Cls{ x: & (*self.x).clone() }
}
}
and I was gett
The split stack patches for ARM were recently upstreamed, and they
were modified when being upstreamed as well. Primarily the location of
the split stack is no longer at a magic address for thumb, but rather
it uses the same instruction as ARM (some thumb processors do indeed
have the coprocessor).
> How do I manually implement "clone()" for Structs/Enums with lifetime
> parameters (e.g. for struct below)?
>
> ---
> struct Cls<'a,T> {
> x:&'a T
> }
impl<'a, T: Clone> Clone for Cls<'a, T> {
fn clone(&self) -> Cls<'a, T> {
Cls
How do I manually implement "clone()" for Structs/Enums with lifetime
parameters (e.g. for struct below)? I could not even work out how to get
the compiler to automatically implement "clone()". That is :
---
struct Cls<'a,T> {
x:&'a T
}
fn ma
On 4/21/14 7:59 AM, José Armando García Sancio wrote:
On a similar note, why did Rust decide to use the keyword "ref" when
"borrowing" in those cases and the keyword "&" when borrowing in
function arguments? Is the semantic different?
`&` in a pattern is the opposite of a reference: it *de*refe
On a similar note, why did Rust decide to use the keyword "ref" when
"borrowing" in those cases and the keyword "&" when borrowing in function
arguments? Is the semantic different?
Feel free to RTFM with a link if it has already been documented.
Thanks,
Jose
On Apr 21, 2014 4:10 AM, "Léo Testard"
Starting recently (no more than two weeks), rustc is generating a broken
prologue for arm. Here's the sample assembly:
0x0f44 <+0>: push {r4, r5}
=> 0x0f46 <+2>: mrc 15, 0, r4, cr13, cr0, {3}
0x0f4a <+6>: mov r5, sp
0x0f4c <+8>: b.n 0xa78
0x0f4e <+10>: ands r4, r0
That confirmed it's tonight!
Third of his name.
Planing:
18:00 -> 19:30: Lunch and informal meeting.
19:30 -> 23:00: Workshops for different levels.
Reps Page: https://reps.mozilla.org/e/meetup-rust-paris-03/
Inscription and attendees:
https://etherpad.mozilla.org/remo-meetup-rust-paris-03
Imp
Awesome that worked! Thanks.
On Mon, Apr 21, 2014 at 12:07 PM, Magnus Holm wrote:
> I'm guessing matching with a reference will help:
>
> mpl Clone for Coll {
> fn clone (&self) -> Coll {
> match *self {
> A(x,ref y) => A(x,y.clone()),
> B(x,ref y) => B(x,y.c
Le 21 avr. 2014 à 12:57, Artella Coding a écrit
:
>
> Suppose I have the enum :
>
> enum Coll {
> A(f64,T),
> B(f64,T)
> }
>
> I know that the compiler can automatically derive the Clone trait for the
> above. However I would like to manually implement it and was unsuccessful in
>
I'm guessing matching with a reference will help:
mpl Clone for Coll {
fn clone (&self) -> Coll {
match *self {
A(x,ref y) => A(x,y.clone()),
B(x,ref y) => B(x,y.clone())
}
}
}
(Haven't tried it though)
// Magnus Holm
On Mon, Apr 21, 2014 at 12:5
Suppose I have the enum :
enum Coll {
A(f64,T),
B(f64,T)
}
I know that the compiler can automatically derive the Clone trait for the
above. However I would like to manually implement it and was unsuccessful
in my attempt. I tried the following :
enum Coll {
A(f64,T),
B(f64,T)
}
27 matches
Mail list logo
