From vadimcn at gmail.com Sat Jun 1 00:08:47 2013 From: vadimcn at gmail.com (Vadim) Date: Sat, 1 Jun 2013 00:08:47 -0700 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: <51A9280C.6050304@mozilla.com> References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: On Fri, May 31, 2013 at 3:45 PM, Brian Anderson wrote: > > With this problem in general I think the obvious solutions amount to > taking one of two approaches: translate I/O events into pipe events; > translate pipe events into I/O events. Solving the problem efficiently for > either one is rather simpler than solving both. The example you show is > promising model that looks like it could naively be implemented by > buffering I/O into pipes. bblum and I talked about an implementation that > would work well for this approach, but it has costs. I imagine it working > like this. > > 1) The resolve_xxx function partitions the elements into pipesy types and > I/O types. > 3) For each of the I/O types it creates a new pipe, and registers a uv > event. Note that because of I/O-scheduler affinity some of these may cause > the task to migrate between threads. > 4) Now we just wait on all the pipes. > What if futures were treated as one-shot pipes with one element queue capacity, and "real" pipes were used only when there's a need for buffering? That would help to reduce per-operation costs (also see notes below about allocation). > > I think we would want to do this too for efficiency reasons. The above > outline has two major costs: the first is the extra pipes and the second is > the buffering of the I/O. For example, the synchronous read method looks > like `read(buf: &mut [u8])` where the buf is typically allocated on the > stack. In the future scenario presumably it would be more like `read() -> > Future<~[u8]>`, forcing a heap allocation, but maybe `read(buf: &mut [u8]) > -> Future<&mut [u8]>` is workable. > Not necessarily. In fact, .NET's signature of the read method is something like this: fn read(buf: &mut [u8]) -> ~Future; It returns just the read bytes count. This is perfectly fine for simple usage because caller still has a reference to the buffer. Now, if you want to send it over to another task, this is indeed a problem, however composition of future comes to the rescue. Each .NET's future has a method that allows to attach a continuation that yields a new future of the type of continuation's result: trait Future { fn continue_with(&self, cont: fn (T) -> T1) -> Future; } let buf = ~[0,..1024]; let f1 = stream.read(&buf); let f2 : Future<(~[u8],int> = f1.continue_with(|read| return (buf, read)); Now f2 contains all information needed to process received data in another task. > > 2. Each i/o operation now needs to allocate heap memory for the future > object. This has been known to create GC performance problems for .NET > web apps which process large numbers of small requests. If these can live > on the stack, though, maybe this wouldn't be a problem for Rust. > > > Haha, yep that's a concern. > I know that Rust currently doesn't currently support this, but what if futures could use a custom allocator? Then it could work like this: 1. Futures use a custom free-list allocator for performance. 2. The I/O request allocates new future object, registers uv event, then returns unique pointer to the future to its' caller. However I/O manager retains internal reference to the future, so that it can be resolved once I/O completes. 3. The future object also has a flag indicating that there's an outstanding I/O, so if caller drops the reference to it, it won't be returned to the free list until I/O completes. 4. When I/O is complete, the future get resolved and all attached continuations are run. Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Sat Jun 1 03:46:00 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 1 Jun 2013 06:46:00 -0400 Subject: [rust-dev] Question about lifetimes in type parameters In-Reply-To: <51A75B80.9080400@crsr.net> References: <51A4FC17.6090803@crsr.net> <20130529095503.GA22384@Mr-Bennet> <51A67953.7010308@crsr.net> <20130530100947.GJ3607@Mr-Bennet> <51A75B80.9080400@crsr.net> Message-ID: <20130601103900.GA6917@Mr-Bennet> OK, I finally got a chance to take a look. Indeed, this is not a bug, I just misunderstood what was going on. The problem is that the key is `&'b [u8]` but you can't supply precisely that type, because the key you are using to do th elookup has a shorter lifetime. This is true and the type checker is right to complain. What you want is to do in these situations is to use the `find_equiv` method, which demands a key that is not necessarily the *same* type as what is in the map but just one comparable to it. Unfortunately, we don't have an equivalence for two slices of unequal lifetimes right now (and we can't right one at the moment due to some limitations that I am supposed to be lifting). Annoyingly, we also don't have an equivalence from ~[u8] to &[u8], only in the reverse direction. We should fix this, but usually people have ~[u8] as the key and &[u8] as the equivalent lookup key, not the other way around. However, you can workaround this limitation using a "new type" struct. Here is a version that works. The main trick is to add a temporary type `MapKey` for which we can define the `Equiv` trait so that it can be compared to the slices that are in your table. ``` extern mod extra; use std::vec; use std::hashmap::*; use std::os; use std::str; use std::uint; use std::cmp::eq; #[deriving(IterBytes)] struct MapKey(~[u8]); impl<'self> Equiv<&'self [u8]> for MapKey { fn equiv(&self, other: & &'self [u8]) -> bool { let slice1: &[u8] = **self; let slice2: &[u8] = *other; slice1 == slice2 } } pub fn with_mmap_file_contents(filename : &str, f : &fn(v : &[u8]) -> U) -> U { fail!() } pub fn each_combination(values : &[T], r : uint, fun : &fn(combo : &[T]) -> bool) -> bool { fail!() } fn get_letters(s : &str) -> ~[u8] { let mut t = str::to_chars(s); extra::sort::quick_sort(t, |a,b| *a <= *b); return vec::from_fn(t.len(), |i| t[i] as u8); } fn line_map<'b>(buffer : &'b [u8]) -> ~HashMap<&'b [u8],&'b [u8]> { let length = buffer.len(); let mut map = ~HashMap::new(); let mut i = 0; while i < length { let mut j = i; while j < length && buffer[j] != ' ' as u8 { j += 1; } let mut k = j+1; while k < length && buffer[k] != '\n' as u8 { k += 1; } map.insert(vec::slice(buffer, i, j), vec::slice(buffer, j+1, k)); i = k + 1; } return map; } fn search<'b>(letters : &[u8], dictionary : &'b HashMap<&'b [u8],&'b [u8]>) -> ~HashSet<&'b [u8]> { let mut set = ~HashSet::new(); for uint::range(2, letters.len() + 1) |i| { let mut key = MapKey(vec::from_elem(i, 0)); // pub fn each_combination(values : &[T], r : uint, fun : &fn(combo : &[T]) -> bool) -> bool for each_combination(letters,i) |combo| { for combo.eachi |j,&ch| { key[j] = ch; } { match dictionary.find_equiv(&key) { Some(val) => { set.insert(*val); } None => { } } } } } return set; } fn main() { let args = os::args(); if args.len() < 2 { fail!(~"Usage: anagrams letters"); } let letters = get_letters(args[1]); do with_mmap_file_contents("anadict-rust.txt") |buf| { let map = line_map(buf); let set = search(letters, map); // Just count them for now... let mut count = 0; for set.each |ln| { count += 1 + vec::count(*ln, &(' ' as u8)); } println(fmt!("%?", count)); } } ``` Niko On Thu, May 30, 2013 at 09:00:32AM -0500, Tommy M. McGuire wrote: > On 05/30/2013 05:09 AM, Niko Matsakis wrote: > > On Wed, May 29, 2013 at 04:55:31PM -0500, Tommy M. McGuire wrote: > >> The problem is that I want to use a completely unrelated vector as the > >> argument to find() instead of an alias for part of the buffer or a pair > >> of indices into the buffer. > >> > >> Currently, with my quick change to incoming, the code > >> > >> let kkey : &[u8] = key; // key : ~[u8] > >> match dictionary.find(&kkey) { > >> > >> produces: > >> > >> 55:38 error: borrowed value does not live long enough > >> let kkey : &[u8] = key; > >> ^~~ > >> 67:1 note: borrowed pointer must be valid for the lifetime > >> &br_named({repr: 83, ctxt: 0}) as defined on the block at 48:0... > >> ... > >> 65:5 note: ...but borrowed value is only valid for the block at 50:46 > >> > >> The lifetime '&br_named(...)' stuff should be "'b", the lifetime > >> parameter of the function (the block at 48:0) that is associated with > >> the keys and values from the HashMap (was LinearMap) and the buffer. > > > > This seems like a bug (also, what a lousy error message! sorry.), I > > will further investigate. > > Thanks! (The error message changed when I updated incoming, so it's > something recent.) > > I'm not sure it is a bug, though. I may not be understanding lifetimes > well enough, but I think the interaction between that and generics is > problematic. In this case, there doesn't seem to be enough information > to tell the difference between find(), for which the lifetime argument > is not terribly useful, and insert(), where it would be. > > > -- > Tommy M. McGuire > mcguire at crsr.net From niko at alum.mit.edu Sat Jun 1 04:14:17 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 1 Jun 2013 07:14:17 -0400 Subject: [rust-dev] Question about lifetimes in type parameters In-Reply-To: <20130601103900.GA6917@Mr-Bennet> References: <51A4FC17.6090803@crsr.net> <20130529095503.GA22384@Mr-Bennet> <51A67953.7010308@crsr.net> <20130530100947.GJ3607@Mr-Bennet> <51A75B80.9080400@crsr.net> <20130601103900.GA6917@Mr-Bennet> Message-ID: <20130601111417.GA7891@Mr-Bennet> Ah, one thouht, you may want to be more careful with the def'n of IterBytes on MapKey to be sure that the hashcodes are the same. Niko On Sat, Jun 01, 2013 at 06:46:00AM -0400, Niko Matsakis wrote: > OK, I finally got a chance to take a look. Indeed, this is not a bug, > I just misunderstood what was going on. The problem is that the key is > `&'b [u8]` but you can't supply precisely that type, because the key > you are using to do th elookup has a shorter lifetime. This is true and > the type checker is right to complain. > > What you want is to do in these situations is to use the `find_equiv` > method, which demands a key that is not necessarily the *same* type as > what is in the map but just one comparable to it. Unfortunately, we > don't have an equivalence for two slices of unequal lifetimes right > now (and we can't right one at the moment due to some limitations that > I am supposed to be lifting). Annoyingly, we also don't have an > equivalence from ~[u8] to &[u8], only in the reverse direction. We > should fix this, but usually people have ~[u8] as the key and &[u8] as > the equivalent lookup key, not the other way around. > > However, you can workaround this limitation using a "new type" struct. > Here is a version that works. The main trick is to add a temporary > type `MapKey` for which we can define the `Equiv` trait so that it can > be compared to the slices that are in your table. > > > ``` > extern mod extra; > use std::vec; > use std::hashmap::*; > use std::os; > use std::str; > use std::uint; > use std::cmp::eq; > > #[deriving(IterBytes)] > struct MapKey(~[u8]); > impl<'self> Equiv<&'self [u8]> for MapKey { > fn equiv(&self, other: & &'self [u8]) -> bool { > let slice1: &[u8] = **self; > let slice2: &[u8] = *other; > slice1 == slice2 > } > } > > pub fn with_mmap_file_contents(filename : &str, f : &fn(v : &[u8]) -> U) -> U { > fail!() > } > > pub fn each_combination(values : &[T], r : uint, fun : &fn(combo : &[T]) -> bool) -> bool { > fail!() > } > > fn get_letters(s : &str) -> ~[u8] { > let mut t = str::to_chars(s); > extra::sort::quick_sort(t, |a,b| *a <= *b); > return vec::from_fn(t.len(), |i| t[i] as u8); > } > > fn line_map<'b>(buffer : &'b [u8]) -> ~HashMap<&'b [u8],&'b [u8]> { > let length = buffer.len(); > let mut map = ~HashMap::new(); > let mut i = 0; > while i < length { > let mut j = i; > while j < length && buffer[j] != ' ' as u8 { j += 1; } > let mut k = j+1; > while k < length && buffer[k] != '\n' as u8 { k += 1; } > map.insert(vec::slice(buffer, i, j), vec::slice(buffer, j+1, k)); > i = k + 1; > } > return map; > } > > fn search<'b>(letters : &[u8], dictionary : &'b HashMap<&'b [u8],&'b [u8]>) -> ~HashSet<&'b [u8]> > { > let mut set = ~HashSet::new(); > for uint::range(2, letters.len() + 1) |i| { > let mut key = MapKey(vec::from_elem(i, 0)); > // pub fn each_combination(values : &[T], r : uint, fun : &fn(combo : &[T]) -> bool) -> bool > for each_combination(letters,i) |combo| { > for combo.eachi |j,&ch| { key[j] = ch; } > { > match dictionary.find_equiv(&key) { > Some(val) => { > set.insert(*val); > } > None => { } > } > } > } > } > return set; > } > > fn main() { > let args = os::args(); > if args.len() < 2 { > fail!(~"Usage: anagrams letters"); > } > let letters = get_letters(args[1]); > do with_mmap_file_contents("anadict-rust.txt") |buf| { > let map = line_map(buf); > let set = search(letters, map); > // Just count them for now... > let mut count = 0; > for set.each |ln| { > count += 1 + vec::count(*ln, &(' ' as u8)); > } > println(fmt!("%?", count)); > } > } > ``` > > > Niko > > On Thu, May 30, 2013 at 09:00:32AM -0500, Tommy M. McGuire wrote: > > On 05/30/2013 05:09 AM, Niko Matsakis wrote: > > > On Wed, May 29, 2013 at 04:55:31PM -0500, Tommy M. McGuire wrote: > > >> The problem is that I want to use a completely unrelated vector as the > > >> argument to find() instead of an alias for part of the buffer or a pair > > >> of indices into the buffer. > > >> > > >> Currently, with my quick change to incoming, the code > > >> > > >> let kkey : &[u8] = key; // key : ~[u8] > > >> match dictionary.find(&kkey) { > > >> > > >> produces: > > >> > > >> 55:38 error: borrowed value does not live long enough > > >> let kkey : &[u8] = key; > > >> ^~~ > > >> 67:1 note: borrowed pointer must be valid for the lifetime > > >> &br_named({repr: 83, ctxt: 0}) as defined on the block at 48:0... > > >> ... > > >> 65:5 note: ...but borrowed value is only valid for the block at 50:46 > > >> > > >> The lifetime '&br_named(...)' stuff should be "'b", the lifetime > > >> parameter of the function (the block at 48:0) that is associated with > > >> the keys and values from the HashMap (was LinearMap) and the buffer. > > > > > > This seems like a bug (also, what a lousy error message! sorry.), I > > > will further investigate. > > > > Thanks! (The error message changed when I updated incoming, so it's > > something recent.) > > > > I'm not sure it is a bug, though. I may not be understanding lifetimes > > well enough, but I think the interaction between that and generics is > > problematic. In this case, there doesn't seem to be enough information > > to tell the difference between find(), for which the lifetime argument > > is not terribly useful, and insert(), where it would be. > > > > > > -- > > Tommy M. McGuire > > mcguire at crsr.net > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From thadguidry at gmail.com Sat Jun 1 06:43:13 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Sat, 1 Jun 2013 08:43:13 -0500 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: > > I know that Rust currently doesn't currently support this, but what if > futures could use a custom allocator? Then it could work like this: > > 1. Futures use a custom free-list allocator for performance. > 2. The I/O request allocates new future object, registers uv event, then > returns unique pointer to the future to its' caller. However I/O manager > retains internal reference to the future, so that it can be resolved once > I/O completes. > 3. The future object also has a flag indicating that there's an > outstanding I/O, so if caller drops the reference to it, it won't be > returned to the free list until I/O completes. > 4. When I/O is complete, the future get resolved and all attached > continuations are run. > > > Vadim > > Brian, Vadim described the idea fairly well there with the meat of my idea being # 2. I was just trying to describe the scenario that # 4 be able to happen only when all the registered event(s) happen (not just 1 blocking step but perhaps many blocking steps). I would not know where to start mocking something like that with Rust yet... still beginning. -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat Jun 1 07:47:40 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 1 Jun 2013 16:47:40 +0200 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: On Sat, Jun 1, 2013 at 3:43 PM, Thad Guidry wrote: > > >> I know that Rust currently doesn't currently support this, but what if >> futures could use a custom allocator? Then it could work like this: >> >> 1. Futures use a custom free-list allocator for performance. >> > I don't see why Futures could not be allocated on the stack ? Since Rust is move aware and has value types, it seems to me this should be possible. -- Matthieu > 2. The I/O request allocates new future object, registers uv event, then >> returns unique pointer to the future to its' caller. However I/O manager >> retains internal reference to the future, so that it can be resolved once >> I/O completes. >> 3. The future object also has a flag indicating that there's an >> outstanding I/O, so if caller drops the reference to it, it won't be >> returned to the free list until I/O completes. >> 4. When I/O is complete, the future get resolved and all attached >> continuations are run. >> >> >> Vadim >> >> > Brian, > > Vadim described the idea fairly well there with the meat of my idea being > # 2. I was just trying to describe the scenario that # 4 be able to happen > only when all the registered event(s) happen (not just 1 blocking step but > perhaps many blocking steps). > > I would not know where to start mocking something like that with Rust > yet... still beginning. > > -- > -Thad > http://www.freebase.com/view/en/thad_guidry > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Sat Jun 1 11:35:02 2013 From: vadimcn at gmail.com (Vadim) Date: Sat, 1 Jun 2013 11:35:02 -0700 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: On Sat, Jun 1, 2013 at 7:47 AM, Matthieu Monrocq wrote: > > 1. Futures use a custom free-list allocator for performance. >>> >> > I don't see why Futures could not be allocated on the stack ? > > Since Rust is move aware and has value types, it seems to me this should > be possible. > Because I/O manager needs to know where that future is in order to fill in the result. Perhaps it's possible to have a stack-allocated future objects that consist of just a raw pointer to a block owned by the I/O manager. But these would need to have by-move semantics in order to emulate behavior of unique pointers. I am not entirely sure how by-move vs by-copy is decided, but according to thisRust would choose by-copy. Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: From rust-dev at tomlee.co Sat Jun 1 14:21:13 2013 From: rust-dev at tomlee.co (Tom Lee) Date: Sat, 1 Jun 2013 14:21:13 -0700 Subject: [rust-dev] Traits & "mod" Message-ID: Hey folks, A work colleague is trying to pick up some Rust & we were both surprised by the following: // some_mod.rs pub trait SomeTrait { pub fn foo(&self) -> ~str; } pub struct SomeStruct { name: ~str } impl SomeTrait for SomeStruct { pub fn foo(&self) -> ~str { self.name.clone() } } impl SomeStruct { pub fn new(name: &str) -> SomeStruct { SomeStruct { name: name.to_owned() } } } // some_use.rs mod some_mod; fn main() { let inst = some_mod::SomeStruct::new("test"); println(inst.foo()); } This fails with a compile error because the compiler can't "see" some_mod::SomeTrait in the scope of some_use.rs: some_use.rs:5:4: 6:1 error: type `some_mod::SomeStruct` does not implement any method in scope named `foo` some_use.rs:5 inst.foo() some_use.rs:6 } This is fixed by adding "use some_mod::SomeTrait" at the start of some_use.rs. It's as though traits need to be in the same scope as code that expects to make use of their behaviour (where I'd expect the behaviour would be associated with the implementation for the "self" type). My question is: is this intended behaviour? If not, what's the expected behaviour & is there an outstanding issue for this? Appreciate any clarification! Cheers, Tom -- Tom Lee / http://tomlee.co / @tglee From hatahet at gmail.com Sat Jun 1 21:33:55 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sat, 1 Jun 2013 21:33:55 -0700 Subject: [rust-dev] Mutability and borrowing Message-ID: I have the following function: fn add_equal(x: &mut Complex, y: &Complex) { x.real += y.real; x.imag += y.imag; } Calling the function with the same variable being passed to both arguments (i.e. add_equal(&mut c, &c)), results in the compile error: error: cannot borrow `c` as immutable because it is also borrowed as mutable I am guessing this is to avoid aliasing issues? What is the way around this? Thanks -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhijeet.gaiha at gmail.com Sat Jun 1 21:40:46 2013 From: abhijeet.gaiha at gmail.com (Abhijeet Gaiha) Date: Sun, 2 Jun 2013 10:10:46 +0530 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: Trying to concurrently borrow a value twice is never going to work. You could write a function like "double" for such a situation. -- Abhijeet Gaiha http://about.me/abhijeet.gaiha On Sunday, 2 June 2013 at 10:03 AM, Ziad Hatahet wrote: > I have the following function: > > fn add_equal(x: &mut Complex, y: &Complex) { > x.real += y.real; > x.imag += y.imag; > } > > Calling the function with the same variable being passed to both arguments (i.e. add_equal(&mut c, &c)), results in the compile error: > > error: cannot borrow `c` as immutable because it is also borrowed as mutable > > I am guessing this is to avoid aliasing issues? What is the way around this? > > Thanks > > -- > Ziad > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org) > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Sat Jun 1 21:42:40 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat, 1 Jun 2013 21:42:40 -0700 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet wrote: > I have the following function: > > fn add_equal(x: &mut Complex, y: &Complex) { > x.real += y.real; > x.imag += y.imag; > } > > Calling the function with the same variable being passed to both arguments > (i.e. add_equal(&mut c, &c)), results in the compile error: > > error: cannot borrow `c` as immutable because it is also borrowed as mutable > > I am guessing this is to avoid aliasing issues? What is the way around this? > You can copy y instead of passing a reference to it: fn add_equal(x: &mut Complex, y: Complex) { ... Of course, that means that at the call site, you will have to write something like add_equal(&mut c, copy c). Unless you want to write a function that just takes one argument and doubles it, like Abhijeet suggested, I don't know of another way around this. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From hatahet at gmail.com Sat Jun 1 22:02:17 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sat, 1 Jun 2013 22:02:17 -0700 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: Thanks everyone. I actually thought about the two suggestions before posting. I thought there might be some common paradigm for this in the language though. So I take it that implementing a += operator overload function would not have a generic way to handle the case where the same parameter is passed on both sides? -- Ziad On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier wrote: > On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet wrote: > > I have the following function: > > > > fn add_equal(x: &mut Complex, y: &Complex) { > > x.real += y.real; > > x.imag += y.imag; > > } > > > > Calling the function with the same variable being passed to both > arguments > > (i.e. add_equal(&mut c, &c)), results in the compile error: > > > > error: cannot borrow `c` as immutable because it is also borrowed as > mutable > > > > I am guessing this is to avoid aliasing issues? What is the way around > this? > > > > You can copy y instead of passing a reference to it: > fn add_equal(x: &mut Complex, y: Complex) { ... > > Of course, that means that at the call site, you will have to write > something like add_equal(&mut c, copy c). > > Unless you want to write a function that just takes one argument and > doubles it, like Abhijeet suggested, I don't know of another way > around this. > > Cheers, > Tim > > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Not a riot, it's a rebellion." -- Boots Riley > "Attention Bros and Trolls: When I call out your spew, I'm not angry, > I'm defiant." -- Reg Braithwaite > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhijeet.gaiha at gmail.com Sat Jun 1 22:03:53 2013 From: abhijeet.gaiha at gmail.com (Abhijeet Gaiha) Date: Sun, 2 Jun 2013 10:33:53 +0530 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: The 'copy' parameter is the most generic way for the client to handle this situation. -- Abhijeet Gaiha http://about.me/abhijeet.gaiha On Sunday, 2 June 2013 at 10:32 AM, Ziad Hatahet wrote: > Thanks everyone. I actually thought about the two suggestions before posting. I thought there might be some common paradigm for this in the language though. > > So I take it that implementing a += operator overload function would not have a generic way to handle the case where the same parameter is passed on both sides? > > > -- > Ziad > > On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier wrote: > > On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet wrote: > > > I have the following function: > > > > > > fn add_equal(x: &mut Complex, y: &Complex) { > > > x.real += y.real; > > > x.imag += y.imag; > > > } > > > > > > Calling the function with the same variable being passed to both arguments > > > (i.e. add_equal(&mut c, &c)), results in the compile error: > > > > > > error: cannot borrow `c` as immutable because it is also borrowed as mutable > > > > > > I am guessing this is to avoid aliasing issues? What is the way around this? > > > > > > > You can copy y instead of passing a reference to it: > > fn add_equal(x: &mut Complex, y: Complex) { ... > > > > Of course, that means that at the call site, you will have to write > > something like add_equal(&mut c, copy c). > > > > Unless you want to write a function that just takes one argument and > > doubles it, like Abhijeet suggested, I don't know of another way > > around this. > > > > Cheers, > > Tim > > > > > > -- > > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > > "Not a riot, it's a rebellion." -- Boots Riley > > "Attention Bros and Trolls: When I call out your spew, I'm not angry, > > I'm defiant." -- Reg Braithwaite > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org) > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Sat Jun 1 22:30:35 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sat, 1 Jun 2013 22:30:35 -0700 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: True. I suppose I meant generic and memory efficient at the same time. I guess it shouldn't be too much of a hassle to implement the specialized case of this function if memory is absolutely critical. Thanks -- Ziad On Sat, Jun 1, 2013 at 10:03 PM, Abhijeet Gaiha wrote: > The 'copy' parameter is the most generic way for the client to handle this > situation. > > -- > Abhijeet Gaiha > http://about.me/abhijeet.gaiha > > On Sunday, 2 June 2013 at 10:32 AM, Ziad Hatahet wrote: > > Thanks everyone. I actually thought about the two suggestions before > posting. I thought there might be some common paradigm for this in the > language though. > > So I take it that implementing a += operator overload function would not > have a generic way to handle the case where the same parameter is passed on > both sides? > > > -- > Ziad > > > On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier wrote: > > On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet wrote: > > I have the following function: > > > > fn add_equal(x: &mut Complex, y: &Complex) { > > x.real += y.real; > > x.imag += y.imag; > > } > > > > Calling the function with the same variable being passed to both > arguments > > (i.e. add_equal(&mut c, &c)), results in the compile error: > > > > error: cannot borrow `c` as immutable because it is also borrowed as > mutable > > > > I am guessing this is to avoid aliasing issues? What is the way around > this? > > > > You can copy y instead of passing a reference to it: > fn add_equal(x: &mut Complex, y: Complex) { ... > > Of course, that means that at the call site, you will have to write > something like add_equal(&mut c, copy c). > > Unless you want to write a function that just takes one argument and > doubles it, like Abhijeet suggested, I don't know of another way > around this. > > Cheers, > Tim > > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Not a riot, it's a rebellion." -- Boots Riley > "Attention Bros and Trolls: When I call out your spew, I'm not angry, > I'm defiant." -- Reg Braithwaite > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat Jun 1 23:49:15 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 2 Jun 2013 08:49:15 +0200 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: On Sat, Jun 1, 2013 at 8:35 PM, Vadim wrote: > > On Sat, Jun 1, 2013 at 7:47 AM, Matthieu Monrocq < > matthieu.monrocq at gmail.com> wrote: > >> >> 1. Futures use a custom free-list allocator for performance. >>>> >>> >> I don't see why Futures could not be allocated on the stack ? >> >> Since Rust is move aware and has value types, it seems to me this should >> be possible. >> > > Because I/O manager needs to know where that future is in order to fill in > the result. > > Perhaps it's possible to have a stack-allocated future objects that > consist of just a raw pointer to a block owned by the I/O manager. But > these would need to have by-move semantics in order to emulate behavior of > unique pointers. I am not entirely sure how by-move vs by-copy is > decided, but according to thisRust would choose by-copy. > > Vadim > > Actually, I was more thinking of reserving space on the stack for the return value and have to IO layer write directly into that space (akin to C++'s Return Value Optimization). However I might be stumbling on ABI issues here, since it essentially means that the compiler transforms "Args... -> ~Future" into "Args..., &mut Future -> ()". -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Jun 2 06:56:29 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 2 Jun 2013 09:56:29 -0400 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: On Sun, Jun 2, 2013 at 12:33 AM, Ziad Hatahet wrote: > I have the following function: > > fn add_equal(x: &mut Complex, y: &Complex) { > x.real += y.real; > x.imag += y.imag; > } > > Calling the function with the same variable being passed to both arguments > (i.e. add_equal(&mut c, &c)), results in the compile error: > > error: cannot borrow `c` as immutable because it is also borrowed as mutable > > I am guessing this is to avoid aliasing issues? What is the way around this? > > Thanks > > -- > Ziad You can currently use `&const Complex` for the second parameter, but it may or may not be removed in the future. At the very least it will probably be renamed. An `&` pointer guarantees that the value it points to is immutable, but `&const` is allowed to alias `&mut` since the compiler restricts it much more. Ideally you would use a separate function for doubling the components of a value and adding two together. From hatahet at gmail.com Sun Jun 2 10:54:28 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sun, 2 Jun 2013 10:54:28 -0700 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: Message-ID: On Sun, Jun 2, 2013 at 6:56 AM, Daniel Micay wrote: > You can currently use `&const Complex` for the second parameter, but > it may or may not be removed in the future. At the very least it will > probably be renamed. > Excellent. Thanks all for your replies :) -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Sun Jun 2 15:35:10 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 02 Jun 2013 15:35:10 -0700 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: <51ABC89E.2070604@mozilla.com> On 06/01/2013 12:08 AM, Vadim wrote: > > On Fri, May 31, 2013 at 3:45 PM, Brian Anderson > wrote: > > > With this problem in general I think the obvious solutions amount > to taking one of two approaches: translate I/O events into pipe > events; translate pipe events into I/O events. Solving the problem > efficiently for either one is rather simpler than solving both. > The example you show is promising model that looks like it could > naively be implemented by buffering I/O into pipes. bblum and I > talked about an implementation that would work well for this > approach, but it has costs. I imagine it working like this. > > 1) The resolve_xxx function partitions the elements into pipesy > types and I/O types. > 3) For each of the I/O types it creates a new pipe, and registers > a uv event. Note that because of I/O-scheduler affinity some of > these may cause the task to migrate between threads. > 4) Now we just wait on all the pipes. > > > What if futures were treated as one-shot pipes with one element queue > capacity, and "real" pipes were used only when there's a need for > buffering? That would help to reduce per-operation costs (also see > notes below about allocation). oneshot pipes already behave this way but they do incur one allocation that is shared between both endpoints. I expect futures to be oneshot pipes with some extra promise semantics on the sender side. > > I think we would want to do this too for efficiency reasons. The > above outline has two major costs: the first is the extra pipes > and the second is the buffering of the I/O. For example, the > synchronous read method looks like `read(buf: &mut [u8])` where > the buf is typically allocated on the stack. In the future > scenario presumably it would be more like `read() -> > Future<~[u8]>`, forcing a heap allocation, but maybe `read(buf: > &mut [u8]) -> Future<&mut [u8]>` is workable. > > > Not necessarily. In fact, .NET's signature of the read method is > something like this: fn read(buf: &mut [u8]) -> ~Future; It > returns just the read bytes count. This is perfectly fine for simple > usage because caller still has a reference to the buffer. > > Now, if you want to send it over to another task, this is indeed a > problem, however composition of future comes to the rescue. Each > .NET's future has a method that allows to attach a continuation that > yields a new future of the type of continuation's result: > > trait Future > { > fn continue_with(&self, cont: fn (T) -> T1) -> Future; > } > > let buf = ~[0,..1024]; > let f1 = stream.read(&buf); > let f2 : Future<(~[u8],int> = f1.continue_with(|read| return (buf, read)); > > Now f2 contains all information needed to process received data in > another task. There is at least one problem with this formulation I think that makes it unsafe. To start with, for maximum efficiency you want buf to be on the stack, `[0,..1024]`. If one is ok with using a heap buffer then there aren't any lifetime issues. So I would want to write: // A stack buffer let buf = [0, ..1024]; // A future that tells us when the stack buffer is written let f = stream.read(&buf); But because `buf` is on the stack, it must stay valid until `f` is resolved, which would require a fairly intricate application of borrowing to guarantee. To make borrowcheck inforce this invariant you would need the returned future to contain a pointer borrowed from `buf`: let f: Future<&some_type_that_keeps_the_buf_lifetime_borrowed> = stream.read(&buf); This would prevent `buf` from going out of scope and `f` from being moved out of the `buf` region. Once you do that though the future is unsendable. To make it sendable we can possibly implement some fork/join abstraction that lets you borrow sendable types into subtasks that don't outlive the parent tasks' region (i'm working on some abstractions for simple fork/join type stuff currently). > >> 2. Each i/o operation now needs to allocate heap memory for the >> future object. This has been known to create GC performance >> problems for .NET web apps which process large numbers of small >> requests. If these can live on the stack, though, maybe this >> wouldn't be a problem for Rust. > > Haha, yep that's a concern. > > > I know that Rust currently doesn't currently support this, but what if > futures could use a custom allocator? Then it could work like this: > > 1. Futures use a custom free-list allocator for performance. > 2. The I/O request allocates new future object, registers uv event, > then returns unique pointer to the future to its' caller. However I/O > manager retains internal reference to the future, so that it can be > resolved once I/O completes. > 3. The future object also has a flag indicating that there's an > outstanding I/O, so if caller drops the reference to it, it won't be > returned to the free list until I/O completes. > 4. When I/O is complete, the future get resolved and all attached > continuations are run. > A lot of this behaviour around managing the future's allocation exists in pipes and futures will almost certainly be based on oneshot pipes. I do expect that pipes will ultimately want some control over their allocation so they can reuse buffers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Sun Jun 2 15:44:57 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 02 Jun 2013 15:44:57 -0700 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> Message-ID: <51ABCAE9.8010505@mozilla.com> On 06/01/2013 11:49 PM, Matthieu Monrocq wrote: > > > > On Sat, Jun 1, 2013 at 8:35 PM, Vadim > wrote: > > > On Sat, Jun 1, 2013 at 7:47 AM, Matthieu Monrocq > > > wrote: > > > 1. Futures use a custom free-list allocator for > performance. > > > I don't see why Futures could not be allocated on the stack ? > > Since Rust is move aware and has value types, it seems to me > this should be possible. > > > Because I/O manager needs to know where that future is in order to > fill in the result. > > Perhaps it's possible to have a stack-allocated future objects > that consist of just a raw pointer to a block owned by the I/O > manager. But these would need to have by-move semantics in order > to emulate behavior of unique pointers. I am not entirely sure > how by-move vs by-copy is decided, but according to this > > Rust would choose by-copy. > > Vadim > > > Actually, I was more thinking of reserving space on the stack for the > return value and have to IO layer write directly into that space (akin > to C++'s Return Value Optimization). > > However I might be stumbling on ABI issues here, since it essentially > means that the compiler transforms "Args... -> ~Future" into "Args..., > &mut Future -> ()". In some scenarios it could be an important optimization to let async results be written directly into the stack, but this requires further safety guarantees that the receiver can't move from the stack, as you say. That strikes me more as a fork/join style computation - which may be an appropriate solution here - but I wouldn't want to couple general-purpose futures to stack-discipline. -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Sun Jun 2 15:46:45 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 02 Jun 2013 15:46:45 -0700 Subject: [rust-dev] Scheduler and I/O work items for the summer In-Reply-To: <51ABCAE9.8010505@mozilla.com> References: <51A80DF8.3000608@mozilla.com> <51A9280C.6050304@mozilla.com> <51ABCAE9.8010505@mozilla.com> Message-ID: <51ABCB55.1060606@mozilla.com> On 06/02/2013 03:44 PM, Brian Anderson wrote: > On 06/01/2013 11:49 PM, Matthieu Monrocq wrote: >> >> >> >> On Sat, Jun 1, 2013 at 8:35 PM, Vadim > > wrote: >> >> >> On Sat, Jun 1, 2013 at 7:47 AM, Matthieu Monrocq >> > >> wrote: >> >> >> 1. Futures use a custom free-list allocator for >> performance. >> >> >> I don't see why Futures could not be allocated on the stack ? >> >> Since Rust is move aware and has value types, it seems to me >> this should be possible. >> >> >> Because I/O manager needs to know where that future is in order >> to fill in the result. >> >> Perhaps it's possible to have a stack-allocated future objects >> that consist of just a raw pointer to a block owned by the I/O >> manager. But these would need to have by-move semantics in order >> to emulate behavior of unique pointers. I am not entirely sure >> how by-move vs by-copy is decided, but according to this >> Rust >> would choose by-copy. >> >> Vadim >> >> >> Actually, I was more thinking of reserving space on the stack for the >> return value and have to IO layer write directly into that space >> (akin to C++'s Return Value Optimization). >> >> However I might be stumbling on ABI issues here, since it essentially >> means that the compiler transforms "Args... -> ~Future" into >> "Args..., &mut Future -> ()". > > In some scenarios it could be an important optimization to let async > results be written directly into the stack, but this requires further > safety guarantees that the receiver can't move from the stack, as you > say. That strikes me more as a fork/join style computation - which may > be an appropriate solution here - but I wouldn't want to couple > general-purpose futures to stack-discipline. One other note. I expect Future return values to still be written `-> Future`. The allocation they require is an internal implementation detail - they don't need an extra ~. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh4.seo at samsung.com Sun Jun 2 22:04:34 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Mon, 03 Jun 2013 05:04:34 +0000 (GMT) Subject: [rust-dev] Traits & "mod" Message-ID: <16637255.249271370235874567.JavaMail.weblogic@epv6ml10> > This is fixed by adding "use some_mod::SomeTrait" at the start of > some_use.rs. It's as though traits need to be in the same scope as > code that expects to make use of their behaviour (where I'd expect the > behaviour would be associated with the implementation for the "self" > type). > > My question is: is this intended behaviour? If not, what's the > expected behaviour & is there an outstanding issue for this? Yes, I believe this is fully intended behaviour. From pnkfelix at mozilla.com Mon Jun 3 07:00:39 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Mon, 03 Jun 2013 16:00:39 +0200 Subject: [rust-dev] Using new I/O error handling In-Reply-To: <51A9744E.80102@mozilla.com> References: <23054192.29811369989850304.JavaMail.weblogic@epv6ml13> <51A9744E.80102@mozilla.com> Message-ID: <51ACA187.9090108@mozilla.com> On 01/06/2013 06:10, Brian Anderson wrote: > On 05/31/2013 01:44 AM, Sanghyeon Seo wrote: >> Is it actually possible to use new I/O error handling at the moment? >> It seems to me that >> it is not possible to get at std::rt::io::io_error at all, because >> conditions are private and >> do not work cross-crate. >> >> https://github.com/mozilla/rust/issues/5446 >> https://github.com/mozilla/rust/issues/6009 >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > You are right that it is not possible because of those errors. I > believe that the fix for #6009 is 1cbf0a8 and has been snapshotted, so > io_error and read_error can have their /*pub*/ uncommented. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev I had thought that conditions were currently public, due to commit fe13b865. (Commit 1cbf0a8 is indeed related to all this, but it did not revert conditions to being private-by-default; that is planned for later, as described on pull request #6271) But certainly the ICE described by #5446 sounds serious. I'll poke at it (and probably take care of the rest of #6009 while I am at it). Cheers, -Felix -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.org From alexandre_mutel at live.com Mon Jun 3 05:04:53 2013 From: alexandre_mutel at live.com (Alexandre Mutel) Date: Mon, 3 Jun 2013 12:04:53 +0000 Subject: [rust-dev] Access to COM/IUnknown objects from Rust? Message-ID: Hi, I have not seen any reference about this, so sorry If I'm posting a question that got already an answer somewhere. Rust seems to provide an infrastructure for accessing exported DLL functions, but is there a mechanism to access COM/IUnknown objects? There are lots of API - under Windows - that are only accessible through COM (the whole DirectX API for example), or even the whole new WinRT API. Would it be possible to develop use traits to develop a IUnknown interface with virtual methods and cast a pointer to it easily? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Mon Jun 3 13:23:35 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 3 Jun 2013 13:23:35 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: Hey all! I think we have critical mass for a presentation or two. Would anyone be interested in giving a presentation? If so, how much time would you need to put one together? On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu wrote: > Count me in. :) > > > Kevin > > > -- > Kevin Cantu > > > On Fri, May 24, 2013 at 3:48 PM, Brian Anderson wrote: > >> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote: >> >>> Glad to help. >>> >>> So far I've heard from 10 others so far, which I think is pretty good >>> for our first one in the bay area. When do the interns start? This could be >>> a good way to introduce them into the community / convince them work on my >>> feature requests :) >>> >>> >> All the rust interns will be here by 6/10. >> >> ______________________________**_________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/**listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Mon Jun 3 14:19:08 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 03 Jun 2013 14:19:08 -0700 Subject: [rust-dev] Traits & "mod" In-Reply-To: References: Message-ID: <51AD084C.1060706@mozilla.com> On 01/06/2013 2:21 PM, Tom Lee wrote: > This is fixed by adding "use some_mod::SomeTrait" at the start of > some_use.rs. It's as though traits need to be in the same scope as > code that expects to make use of their behaviour (where I'd expect the > behaviour would be associated with the implementation for the "self" > type). No, the methods in this case are scoped to the trait. See all the traits we 'pub use' in std::prelude so that they are available as methods ubiquitously. > My question is: is this intended behaviour? If not, what's the > expected behaviour & is there an outstanding issue for this? This is intended behavior. Note that there _is_ a single inherent-to-the-type impl (set of methods) which you can use to associated methods with a type: struct Foo { ... } impl Foo { .. inherent methods } Such that anyone who can see Foo can see these methods. But that impl has to be defined in the same crate[1] as the struct itself, such that we can check that there's only one of them. For implementations of a named trait, you must have the trait in-scope in order to see the methods[2]. If you think about this in terms of colliding names and separate compilation, it makes more sense. We want to make it possible to always link together two crates A and B both compiled independently. Suppose A and B both defined different traits P and Q on some type Foo with some methods P::bar() and Q::bar(). Then someone calling (Foo::new()).bar() would be producing a link-time error due to the ambiguity between P::bar() and Q::bar(). We want such things to be caught during compilation of the client code -- where it can be resolved by making a module that does not simultaneously 'use' P and Q -- rather than at link time. -Graydon [1] Possibly the inherent impl has to be in the same module as the struct, not just the same crate. I don't remember where we drew that line. I think it's mostly equivalent either way. [2] You must also implement any trait T for a struct S in either the crate defining T or the crate defining S. This is a different but related restriction, to ensure we never have two different impls of T for S. From vadimcn at gmail.com Mon Jun 3 14:53:08 2013 From: vadimcn at gmail.com (Vadim) Date: Mon, 3 Jun 2013 14:53:08 -0700 Subject: [rust-dev] Access to COM/IUnknown objects from Rust? In-Reply-To: References: Message-ID: Rust traits are not binary-compatible with C++ vtables, so no, you cannot use them directly. I think it's possible to implement COM interop by doing some clever code generation via macros. I briefly looked into doing this a couple of months ago, but at the time it was not possible to specify calling convention on function pointers, and you can't generate COM vtables without that. Once v0.7 is out, I'll try again. Vadim On Mon, Jun 3, 2013 at 5:04 AM, Alexandre Mutel wrote: > Hi, > I have not seen any reference about this, so sorry If I'm posting a > question that got already an answer somewhere. > > Rust seems to provide an infrastructure for accessing exported DLL > functions, but is there a mechanism to access COM/IUnknown objects? There > are lots of API - under Windows - that are only accessible through COM (the > whole DirectX API for example), or even the whole new WinRT API. Would it > be possible to develop use traits to develop a IUnknown interface with > virtual methods and cast a pointer to it easily? > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smadhueagle at outlook.com Mon Jun 3 15:01:58 2013 From: smadhueagle at outlook.com (Madhu Srinivasan) Date: Mon, 3 Jun 2013 22:01:58 +0000 Subject: [rust-dev] Mutability and borrowing In-Reply-To: References: , , , , Message-ID: Going by the suggested solution of using Atomic Reference Counters (std::arc) for sharing immutable data across different tasks, I would presume that the most generic solution would be to use the arc module. You can see an example of this in action here : https://github.com/smadhueagle/rustlings/blob/master/borrow.rs Madhu From: hatahet at gmail.com Date: Sat, 1 Jun 2013 22:30:35 -0700 To: abhijeet.gaiha at gmail.com CC: rust-dev at mozilla.org Subject: Re: [rust-dev] Mutability and borrowing True. I suppose I meant generic and memory efficient at the same time. I guess it shouldn't be too much of a hassle to implement the specialized case of this function if memory is absolutely critical. Thanks -- Ziad On Sat, Jun 1, 2013 at 10:03 PM, Abhijeet Gaiha wrote: The 'copy' parameter is the most generic way for the client to handle this situation. -- Abhijeet Gaihahttp://about.me/abhijeet.gaiha On Sunday, 2 June 2013 at 10:32 AM, Ziad Hatahet wrote: Thanks everyone. I actually thought about the two suggestions before posting. I thought there might be some common paradigm for this in the language though. So I take it that implementing a += operator overload function would not have a generic way to handle the case where the same parameter is passed on both sides? -- Ziad On Sat, Jun 1, 2013 at 9:42 PM, Tim Chevalier wrote: On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet wrote: > I have the following function: > > fn add_equal(x: &mut Complex, y: &Complex) { > x.real += y.real; > x.imag += y.imag; > } > > Calling the function with the same variable being passed to both arguments > (i.e. add_equal(&mut c, &c)), results in the compile error: > > error: cannot borrow `c` as immutable because it is also borrowed as mutable > > I am guessing this is to avoid aliasing issues? What is the way around this? > You can copy y instead of passing a reference to it: fn add_equal(x: &mut Complex, y: Complex) { ... Of course, that means that at the call site, you will have to write something like add_equal(&mut c, copy c). Unless you want to write a function that just takes one argument and doubles it, like Abhijeet suggested, I don't know of another way around this. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite _______________________________________________Rust-dev mailing listRust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Jun 5 17:37:13 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 5 Jun 2013 17:37:13 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: Hey folks! I've made a reservation for 20 people at Tied House in Mountain View next Wednesday, June 12th, at 7pm: Tied House 954 Villa St, Mountain View, CA 94041 http://tiedhouse.com/ map: http://goo.gl/maps/p9dK0. It's right near Caltrain, so it should hopefully be pretty easy for people to commute to the restaurant. Please let me know if you are coming so I can grow/shrink the reservation. Finally, please bring some cash because we'll all be sharing one check, and it'll be easier to split the bill. Looking forward to meeting you all! -Erick On Mon, Jun 3, 2013 at 1:23 PM, Erick Tryzelaar wrote: > Hey all! I think we have critical mass for a presentation or two. Would > anyone be interested in giving a presentation? If so, how much time would > you need to put one together? > > > On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu wrote: > >> Count me in. :) >> >> >> Kevin >> >> >> -- >> Kevin Cantu >> >> >> On Fri, May 24, 2013 at 3:48 PM, Brian Anderson wrote: >> >>> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote: >>> >>>> Glad to help. >>>> >>>> So far I've heard from 10 others so far, which I think is pretty good >>>> for our first one in the bay area. When do the interns start? This could be >>>> a good way to introduce them into the community / convince them work on my >>>> feature requests :) >>>> >>>> >>> All the rust interns will be here by 6/10. >>> >>> ______________________________**_________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/**listinfo/rust-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbp at dbpmail.net Wed Jun 5 17:17:22 2013 From: dbp at dbpmail.net (Daniel Patterson) Date: Wed, 5 Jun 2013 20:17:22 -0400 Subject: [rust-dev] version numbers in rust source In-Reply-To: References: <20130531155709.GG3002@Mr-Bennet> Message-ID: On Fri, May 31, 2013 at 12:47 PM, John Clements wrote: > > On May 31, 2013, at 9:00 AM, Corey Richardson wrote: > >> Doesn't racket also do this with its `#lang ` construct? > > Yes. > Well, they sort of do this. They don't use version numbers, but they do entire languages. So, for example, you can write "#lang racket" code that works on 5.3.4 (the current version), but is broken on 5.3.3, and the #lang line does not change. In this sense, it fails to do what Armstrong is describing. But you're right that old, completely replaced languages, are still supported on the platform via #lang, and there isn't really any reason why the system couldn't be extended to have different #lang lines per version. ie, #lang racket/5.3, etc... (and I wouldn't be surprised if someone has already experimented with that). From banderson at mozilla.com Wed Jun 5 18:22:40 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 05 Jun 2013 18:22:40 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: <51AFE460.4010904@mozilla.com> On 06/05/2013 05:37 PM, Erick Tryzelaar wrote: > Hey folks! > > I've made a reservation for 20 people at Tied House in Mountain View > next Wednesday, June 12th, at 7pm: > > Tied House > 954 Villa St, Mountain View, CA 94041 > http://tiedhouse.com/ > map: http://goo.gl/maps/p9dK0. > > It's right near Caltrain, so it should hopefully be pretty easy for > people to commute to the restaurant. Please let me know if you are > coming so I can grow/shrink the reservation. > > Finally, please bring some cash because we'll all be sharing one > check, and it'll be easier to split the bill. > Fantastic. This is the perfect location for me. I'll look forward to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at linuxfood.net Wed Jun 5 19:00:12 2013 From: brian at linuxfood.net (Brian Smith) Date: Wed, 5 Jun 2013 19:00:12 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: <51AFE460.4010904@mozilla.com> References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> <51AFE460.4010904@mozilla.com> Message-ID: Awesome! Looking forward to it. On Jun 5, 2013 6:22 PM, "Brian Anderson" wrote: > On 06/05/2013 05:37 PM, Erick Tryzelaar wrote: > > Hey folks! > > I've made a reservation for 20 people at Tied House in Mountain View > next Wednesday, June 12th, at 7pm: > > Tied House > 954 Villa St, Mountain View, CA 94041 > http://tiedhouse.com/ > map: http://goo.gl/maps/p9dK0. > > It's right near Caltrain, so it should hopefully be pretty easy for > people to commute to the restaurant. Please let me know if you are coming > so I can grow/shrink the reservation. > > Finally, please bring some cash because we'll all be sharing one check, > and it'll be easier to split the bill. > > > Fantastic. This is the perfect location for me. I'll look forward to it. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Jun 5 21:09:29 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 00:09:29 -0400 Subject: [rust-dev] The future of iterators in Rust Message-ID: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> A quick terminology refresher, for those who aren't familiar with it: * Internal iterator: takes a closure, runs the closure until it asks to break * External iterator: state machine, advanced by the caller in a loop To a caller, external iterators provide the most functionality, because they can be used as an internal iterator. You lose the state of an internal iterator by breaking out of iterator, so generic algorithms like zip, union, intersect and merge can't be implemented for a pair of iterators. # Issues with internal iterators in Rust A few months ago, we only had internal iterators and there were no generic algorithms to use with any iterator - only with BaseIter's `each` method. Rust's internal iterators implement the protocol encoded in Rust's for statement, but it's not possible to give them all a common trait or implement generic methods or functions taking any internal iterator. As a workaround, we can write algorithms assuming internal iterators only take one argument (the closure): fn count(f: &fn(fn(T) -> bool) -> bool) -> uint The caller has to use a partial function to call these adaptors, for which we lack sugar: count(|f| uint::range(0, 10, f)) For simple functions, this is fairly reasonable once you're used to it. It quickly gets out of control though, even for a simple function like filter: filter(pred: &fn(&T) -> bool, input: &fn(&fn(T) -> bool) -> bool, output: &fn(T) -> bool) -> bool {} Sadly, `filter_ref` is also needed to work around closures behaving badly with lifetimes. An example of the problem with `fold_ref`: fn product>(iter: &fn(f: &fn(&T) -> bool) -> bool) -> T { fold_ref(One::one::(), iter, |a, x| *a = a.mul(x)) } Since `product` expects an iterator yielding `&T` (a borrowed pointer in any region), it won't work with `fold` because that requires the borrowed pointer to have the same type (and thus lifetime) for every iteration like `&'a int`. This issue with borrowed pointers was blocking me from replacing the existing algorithms reimplemented for both `str` and `vec` with the generic ones. Chaining together iteration algorithms is a common use case, but even chaining two together is confusing at first: to_vec(|g| filter(|&x| *x < 3, |f| xs.each(f), g) Another more alarming issue is that with internal iterators, the `break` and `return` statements don't always work in a `for` loop. If the iterator isn't implemented correctly, the loop will keep going. This also has borrow checking implications, because the compiler can't assume those statements actually cause flow control to leave the loop immediately. # External iterators Based on the above, you might think generic iteration algorithms in Rust are a bleak prospect. However, we already have a nice external iterator library, and they don't suffer from the above issues. All kinds of external iterators implement the following trait, whether they are a fibonacci number generator, a reverse iterator over a vector or iterator over a range in a sorted set: pub trait Iterator { /// Advance the iterator and return the next value. Return `None` when the end is reached. fn next(&mut self) -> Option; } Generic adaptors are implemented on `Iterator`, and many of them are `Iterator` implementations themselves: use std::iterator::*; fn main() { let mut it = Counter::new(0.0, 1.0) .take_while(|x| *x < 10000000.0) .transform(|x| x / 2.0) .transform(|x| x + 2.0); println(it.fold(0.0, |a, b| a + b).to_str()) } If you're curious, the optimized LLVM IR: http://ix.io/5Xl Unlike internal iterators, external iterators only run one iteration at a time, so a `for` loop designed for them would always be able to succeed with `break` and `return`. It would also be able to avoid the ugly `advance` wrapper currently required to use external iterators with `for`. // The current situation, wrapping an external iterator as an internal one // // Since the advance method is not known the be correct, borrow checking // still assumes `return` and `break` are imperfect. for xs.zip(ys).advance |x| { ... } // A hypothetical `for` loop using the `Iterator` trait for iterator |x| { ... } // It could also fall back to an `Iterable` trait and obtain an iterator for container |x| { ... } External iterators also avoid the problems with references and closures, because they simply return `T` rather than passing it to a closure. # Why not just switch to external iterators? Algorithms that can be represented easily without the call stack are as easy to write as either an internal or external iterator. However, without support for compiling a function to a state machine (C# does this for yield), traversal of a recursive data structure has to be manually translated to a procedural algorithm with an explicit stack. For complex data structures, this process can be very difficult. I'm hopeful Rust will gain support for this down the road after 1.0. If it does, there will be no reason to write immutable internal iterators. Another issue is mutability, as you can write iterators that are able to mutate containers. With internal iterators, this is easy to do with safe code. With external ones, it will `unsafe` and won't be easy to get right. # Solution? I don't have any proposal to completely solve this issue. :) I think extending the built-in `for` loop to work with external iterators should be considered, because right now the verbosity discourages using them and makes borrow checking more painful than it has to be. It could treat functions as internal iterators, and look for an `Iterator` implementation (using a `lang` item) for external ones. Python's `for` loop starts by looking for an iterator (a `__next__` method) and falls back to an iterable (an `__iter__` method) so behaviour like this isn't an alien concept. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From pwalton at mozilla.com Wed Jun 5 21:15:20 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 05 Jun 2013 21:15:20 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: <51B00CD8.4090608@mozilla.com> On 6/5/13 9:09 PM, Daniel Micay wrote: > I think extending the built-in `for` loop to work with external iterators > should be considered, because right now the verbosity discourages using them > and makes borrow checking more painful than it has to be. > > It could treat functions as internal iterators, and look for an `Iterator` > implementation (using a `lang` item) for external ones. > > Python's `for` loop starts by looking for an iterator (a `__next__` method) and > falls back to an iterable (an `__iter__` method) so behaviour like this isn't > an alien concept. This is a very well-thought out post, and I find it persuasive. The mutability issue is one I hadn't considered, and seems to make a good argument for including both in the language. There is also compilation speed to consider. I have not measured, but intuitively I would guess that external iterators are faster to compile than internal ones in codegen. This is because codegen has to create a closure only to painstakingly break it apart again in optimization via a combination of inlining, constant propagation, and scalar replacement of aggregates. Patrick From jeaye at arrownext.com Thu Jun 6 00:20:23 2013 From: jeaye at arrownext.com (Jeaye) Date: Thu, 06 Jun 2013 00:20:23 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: <51AFE460.4010904@mozilla.com> References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> <51AFE460.4010904@mozilla.com> Message-ID: <51B03837.9000304@arrownext.com> On 06/05/2013 06:22 PM, Brian Anderson wrote: > On 06/05/2013 05:37 PM, Erick Tryzelaar wrote: >> Hey folks! >> >> I've made a reservation for 20 people at Tied House in Mountain View >> next Wednesday, June 12th, at 7pm: >> This sounds pretty great; you can count me in. Jeaye -------------- next part -------------- An HTML attachment was scrubbed... URL: From kballard at gmail.com Thu Jun 6 00:23:20 2013 From: kballard at gmail.com (Kevin Ballard) Date: Thu, 6 Jun 2013 00:23:20 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> <51AFE460.4010904@mozilla.com> Message-ID: If only this weren't during WWDC. I hope we can have another meetup sometime in the near future (perhaps in SF?) that doesn't conflict with a large conference. -Kevin On Wed, Jun 5, 2013 at 7:00 PM, Brian Smith wrote: > Awesome! Looking forward to it. > > On Jun 5, 2013 6:22 PM, "Brian Anderson" wrote: >> >> On 06/05/2013 05:37 PM, Erick Tryzelaar wrote: >> >> Hey folks! >> >> I've made a reservation for 20 people at Tied House in Mountain View next >> Wednesday, June 12th, at 7pm: >> >> Tied House >> 954 Villa St, Mountain View, CA 94041 >> http://tiedhouse.com/ >> map: http://goo.gl/maps/p9dK0. >> >> It's right near Caltrain, so it should hopefully be pretty easy for people >> to commute to the restaurant. Please let me know if you are coming so I can >> grow/shrink the reservation. >> >> Finally, please bring some cash because we'll all be sharing one check, >> and it'll be easier to split the bill. >> >> >> Fantastic. This is the perfect location for me. I'll look forward to it. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From erick.tryzelaar at gmail.com Thu Jun 6 06:21:38 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 6 Jun 2013 06:21:38 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> <51AFE460.4010904@mozilla.com> Message-ID: Yeah, I realized that after I made the reservation. Unfortunately there was WWDC next week, and PLDI the week after. This is just the first of many meet ups :) The next one I organize should be early to mid July, unless someone else wants to plan another event earlier. On Thursday, June 6, 2013, Kevin Ballard wrote: > If only this weren't during WWDC. > > I hope we can have another meetup sometime in the near future (perhaps > in SF?) that doesn't conflict with a large conference. > > -Kevin > > On Wed, Jun 5, 2013 at 7:00 PM, Brian Smith > > wrote: > > Awesome! Looking forward to it. > > > > On Jun 5, 2013 6:22 PM, "Brian Anderson" > > wrote: > >> > >> On 06/05/2013 05:37 PM, Erick Tryzelaar wrote: > >> > >> Hey folks! > >> > >> I've made a reservation for 20 people at Tied House in Mountain View > next > >> Wednesday, June 12th, at 7pm: > >> > >> Tied House > >> 954 Villa St, Mountain View, CA 94041 > >> http://tiedhouse.com/ > >> map: http://goo.gl/maps/p9dK0. > >> > >> It's right near Caltrain, so it should hopefully be pretty easy for > people > >> to commute to the restaurant. Please let me know if you are coming so I > can > >> grow/shrink the reservation. > >> > >> Finally, please bring some cash because we'll all be sharing one check, > >> and it'll be easier to split the bill. > >> > >> > >> Fantastic. This is the perfect location for me. I'll look forward to it. > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Thu Jun 6 08:59:33 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Thu, 6 Jun 2013 17:59:33 +0200 Subject: [rust-dev] Adding exception handling as syntax sugar with declared exceptions In-Reply-To: References: <51951E44.2090306@mozilla.com> Message-ID: On Sat, May 18, 2013 at 2:24 PM, G?bor Lehel wrote: > > > On Thu, May 16, 2013 at 7:58 PM, Graydon Hoare wrote: > >> >> I'm sympathetic to the desire here, as with all attempts to "get >> exceptions right". Sadly I've never really seen it; I don't think anyone >> has really worked out the "right" way to work with catchable-exceptions in >> a language. >> >> -Graydon >> > > What's problematic about exceptions in C++, and what forces you to "worry > about exceptions everywhere", is that code inside a try-block and code > outside of it may share state, which the code in the try block may be in > various stages of modifying (along with allocating resources) when the > exception is thrown, potentially leaving an inconsistent state and/or > leaked resources at the point where the exception is caught. Therefore all > functions have to be very careful that any mutable state accessible to the > function is in (or reverts to) a consistent state at any point where an > exception might be thrown, and that resources aren't left dangling, because > who knows whether that mutable state might not be on the outside of a > try-block and the function on the inside of it. > > What if instead of that, the language enforced that code in try blocks > could not share any state with code outside, only allowing for data to be > transferred in at the beginning and out (whether a result or an exception) > at the end, and ensured that all resources acquired inside the try block > were destroyed after it exited, no matter how it did? That would free the > authors of individual functions from having to care about any of it, > because if an exception is passing through their code, that means that from > their perspective "the world is ending", everything they have access to > will be destroyed, so they can do whatever they want and it won't matter a > bit. > > If that sounds familiar at all, it's because I just described the > semantics of Rust's existing try()*. I still suspect that the best of all > worlds would be something with the semantics of try(), or close, and the > implementation and performance of traditional EH. Is that unrealistic? > > Am I way off base with this? An embarrassing misconception? To summarize my train of thought * Catchable exceptions can be implemented * But we don't want to, because it would force everyone to think about exception safety * That could however be avoided with appropriate restrictions * Rust's type system already gives us the tools to impose those restrictions, as evidenced by them being imposed on `try()` * Therefore it should be possible to have much of the benefit of catchable exceptions, without their drawbacks -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 09:25:38 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 12:25:38 -0400 Subject: [rust-dev] Adding exception handling as syntax sugar with declared exceptions In-Reply-To: References: <51951E44.2090306@mozilla.com> Message-ID: On Thu, Jun 6, 2013 at 11:59 AM, G?bor Lehel wrote: > > Am I way off base with this? An embarrassing misconception? To summarize my > train of thought > > * Catchable exceptions can be implemented > * But we don't want to, because it would force everyone to think about > exception safety > * That could however be avoided with appropriate restrictions > * Rust's type system already gives us the tools to impose those > restrictions, as evidenced by them being imposed on `try()` > * Therefore it should be possible to have much of the benefit of catchable > exceptions, without their drawbacks The cost of spawning a task with try over a theoretical optimized exception handling scheme will only be the small stack segment it needs to allocate (likely cached). The scheduler will switch to it immediately, and if it doesn't do I/O there won't be a switch back until it's done. I think someone will need to demonstrate a performance issue with the completed scheduler before providing a special case in the language will seem like a serious suggestion. From abhijeet.gaiha at gmail.com Thu Jun 6 09:29:37 2013 From: abhijeet.gaiha at gmail.com (Abhijeet Gaiha) Date: Thu, 6 Jun 2013 21:59:37 +0530 Subject: [rust-dev] Memory pool for C lib malloc calls Message-ID: Hi, Servo uses several c libraries through Rust wrappers. In such a situation, I'm curious as to where is the memory for malloc calls inside these libraries allocated from? This doesn't seem to fit into the standard locations viz. Task Heap, Exchange Heap and Local stack. In C programs there is a global heap, but nothing in the rust docs I've looked at so far suggests such a thing exists right now. Which leads me to this question. Thanks, Abhijeet -- http://about.me/abhijeet.gaiha -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 09:39:50 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 12:39:50 -0400 Subject: [rust-dev] Memory pool for C lib malloc calls In-Reply-To: References: Message-ID: On Thu, Jun 6, 2013 at 12:29 PM, Abhijeet Gaiha wrote: > Hi, > > Servo uses several c libraries through Rust wrappers. In such a situation, > I'm curious as to where is the memory for malloc calls inside these > libraries allocated from? This doesn't seem to fit into the standard > locations viz. Task Heap, Exchange Heap and Local stack. In C programs there > is a global heap, but nothing in the rust docs I've looked at so far > suggests such a thing exists right now. Which leads me to this question. > > Thanks, > Abhijeet The malloc/free functions are wrappers on top of sbrk and/or mmap (or similar calls on Windows) to obtain memory from the OS. All memory allocators get the memory from the same place and the process has one address space, so there isn't really a difference. In fact right now, Rust obtains all heap memory from the system's C library malloc/free (likely soon to be jemalloc instead). The local heap and exchange heap don't really exist, they're terms the documentation used as an attempt to explain how things work, but it was never really accurate. Unique pointers/vectors containing managed boxes would be on the "local heap" if we did have one. The only distinction we should make is that Owned types (soon to be renamed Send) are sendable and other types are task-local. From abhijeet.gaiha at gmail.com Thu Jun 6 09:44:23 2013 From: abhijeet.gaiha at gmail.com (Abhijeet Gaiha) Date: Thu, 6 Jun 2013 22:14:23 +0530 Subject: [rust-dev] Memory pool for C lib malloc calls In-Reply-To: References: Message-ID: This suggests that any data allocated in C libs (including statics) is basically part of a "global" address space available to all tasks in a Rust program. Is that correct? Is there as equivalent of malloc() for Rust as well? On 6 June 2013 22:09, Daniel Micay wrote: > On Thu, Jun 6, 2013 at 12:29 PM, Abhijeet Gaiha > wrote: > > Hi, > > > > Servo uses several c libraries through Rust wrappers. In such a > situation, > > I'm curious as to where is the memory for malloc calls inside these > > libraries allocated from? This doesn't seem to fit into the standard > > locations viz. Task Heap, Exchange Heap and Local stack. In C programs > there > > is a global heap, but nothing in the rust docs I've looked at so far > > suggests such a thing exists right now. Which leads me to this question. > > > > Thanks, > > Abhijeet > > The malloc/free functions are wrappers on top of sbrk and/or mmap (or > similar calls on Windows) to obtain memory from the OS. All memory > allocators get the memory from the same place and the process has one > address space, so there isn't really a difference. > > In fact right now, Rust obtains all heap memory from the system's C > library malloc/free (likely soon to be jemalloc instead). > > The local heap and exchange heap don't really exist, they're terms the > documentation used as an attempt to explain how things work, but it > was never really accurate. Unique pointers/vectors containing managed > boxes would be on the "local heap" if we did have one. > > The only distinction we should make is that Owned types (soon to be > renamed Send) are sendable and other types are task-local. > -- http://about.me/abhijeet.gaiha -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 09:49:09 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 12:49:09 -0400 Subject: [rust-dev] Memory pool for C lib malloc calls In-Reply-To: References: Message-ID: On Thu, Jun 6, 2013 at 12:44 PM, Abhijeet Gaiha wrote: > This suggests that any data allocated in C libs (including statics) is > basically part of a "global" address space available to all tasks in a Rust > program. Is that correct? > Is there as equivalent of malloc() for Rust as well? It's not available to all tasks any more than unique/managed allocations, because that would be unsafe. All memory in the process is globally accessible by unsafe code - whether it's a stack allocation or a heap allocation. Providing a safe interface for a C library involves wrapping any resources it returns with destructors, which makes the objects movable/non-implicitly-copyable like unique pointers. Copying these types has to be forbidden (as with sockets/files), produce an unrelated deep copy (like unique pointers/vectors) or they have to be task-local (via #[non_owned]) if they use reference counting. From graydon at mozilla.com Thu Jun 6 10:00:33 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 06 Jun 2013 10:00:33 -0700 Subject: [rust-dev] Adding exception handling as syntax sugar with declared exceptions In-Reply-To: References: <51951E44.2090306@mozilla.com> Message-ID: <51B0C031.9000903@mozilla.com> On 06/06/2013 8:59 AM, G?bor Lehel wrote: > Am I way off base with this? An embarrassing misconception? To summarize > my train of thought > > * Catchable exceptions can be implemented > * But we don't want to, because it would force everyone to think about > exception safety > * That could however be avoided with appropriate restrictions > * Rust's type system already gives us the tools to impose those > restrictions, as evidenced by them being imposed on `try()` > * Therefore it should be possible to have much of the benefit of > catchable exceptions, without their drawbacks No. The train of thought is that they _already are_ implemented to this level -- via task isolation[1] -- and people asking for "catchable exceptions" are (so far) actually asking for us to lift those restrictions[2], which we don't want to do. -Graydon [1] If it helps avoid wincing about the implied "cost of spawning a task" (allocating a segment, switching to it, and switching back on return) it might help to know that there are some serious discussions going on in the background about cactus stacks and the requisite scheduler hooks required to support cilk-like fork/join parallelism. [2] And/or asking to add "first class" language support for the idioms in the form of new keywords, RTTI or additional control structures. In case this is not obvious: we are trying to move as much as possible these days _out_ of the core language and into libraries and macros. This usually results in faster iteration, less fragility, fewer personnel and development/integration bottlenecks, and overall better implementations. From graydon at mozilla.com Thu Jun 6 11:25:28 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 06 Jun 2013 11:25:28 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <51B00CD8.4090608@mozilla.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> Message-ID: <51B0D418.6030909@mozilla.com> On 05/06/2013 9:15 PM, Patrick Walton wrote: > On 6/5/13 9:09 PM, Daniel Micay wrote: >> I think extending the built-in `for` loop to work with external iterators >> should be considered, because right now the verbosity discourages >> using them >> and makes borrow checking more painful than it has to be. >> >> It could treat functions as internal iterators, and look for an >> `Iterator` >> implementation (using a `lang` item) for external ones. >> >> Python's `for` loop starts by looking for an iterator (a `__next__` >> method) and >> falls back to an iterable (an `__iter__` method) so behaviour like >> this isn't >> an alien concept. > > This is a very well-thought out post, and I find it persuasive. The > mutability issue is one I hadn't considered, and seems to make a good > argument for including both in the language. Yeah. I think it's clear enough that both have their (strong) advantages; we have hashmaps and treemaps too, and both vectors and lists :) The main thing I'm concerned with is making the interfaces to user code smooth enough that neither feels markedly second-class or unusable. Extending 'for' as you suggest sounds like a good step. It might also be good to add a tutorial chapter on the matter, introducing these terms and relating them together, so users can see the relative use cases. Thanks for the ongoing work in this area! -Graydon From bill_myers at outlook.com Thu Jun 6 19:12:01 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 02:12:01 +0000 Subject: [rust-dev] Adding exception handling as syntax sugar with declared exceptions In-Reply-To: <51951E44.2090306@mozilla.com> References: , <51951E44.2090306@mozilla.com> Message-ID: > Date: Thu, 16 May 2013 10:58:28 -0700 > From: graydon at mozilla.com > To: bill_myers at outlook.com > CC: rust-dev at mozilla.org > Subject: Re: [rust-dev] Adding exception handling as syntax sugar with declared exceptions > > On 12/05/2013 8:00 PM, Bill Myers wrote: > > This is a suggestion for adding an exception system to Rust that > > satisfies these requirements: > > 1. Unwinding does NOT pass through code that is not either in a function > > that declares throwing exceptions or in a try block (instead, that > > triggers task failure) > > 2. Callers can ignore the fact that a function throws an exception, > > resulting in task failure > > 3. Callers can handle exceptions if desired, with the same syntax of > > C++, Java and C# > > > > (1) avoids the issue with C++ exception handling forcing to think about > > exception safety everywhere > > (2) avoids the issue with Java's checked exceptions forcing to > > explicitly handle or redeclare them > > (3) provides an easy-to-use exception mechanism > > Hi, sorry, I did mean to get back to this. > > I think this is ... unlikely to work out, or be something we incorporate > into our repo. For a few reasons: > > - It's very late in the design cycle to be making changes of > this scope. We're trying to stabilize. > > - It'll be a big performance hit on code paths that want to use > such exceptions. Things that look like "just function calls" > turn into quite extensive operations. We're already struggling > with the costs of a return-bool solution for unwinding on > platforms that have difficult "normal" EH (#4342). > > - Most seriously: it doesn't actually resolve (1) or (2), imo. > > (1) You'd still have to declare checked exceptions everywhere. But > worse than in java, if you failed to declare them _anywhere_ > you wouldn't get a compilation error, but a runtime failure. > This is like making C++ default to 'throw ()', which tends > to surprise everyone. Well, the idea is that exception would generally either be caught in the immediate caller or let go to task failure, with rare cases of propagation. The target use case are things like "str_to_int" functions that would throw format exceptions that would be caught by the immediate caller in case they want to handle it. > (2) You still have to write in "worry about exceptions everywhere" > style inside a try-block or function-that-rethrows. Only > get to avoid it when you're insulating yourself by the implicit > "throw ()" declaration. Yes, but you can't always avoid this anyway, since in some cases operations are truly irreversible. For instance, if you want to make three HTTP POST requests and the second fails, then the first will have gone through and cannot be reverted automatically in any way, so the logic to handle "we did something and then failed, leaving us in a half-done way" is fundamentally necessary in some case regardless of language design. A limited version of this might be implementable by macros that could automatically generate a "try_" version of a function with Result<> return type along with a version that fails. The only other approach that can improve on this is to have support for reversible execution. Basically, one would compile everything in two versions, where one of the versions keeps an undo log of memory writes. When a try block is entered, the compiler switches to the undo-log-enabled code, and when an exception is thrown, the log is played to undo everything. Hardware transactional memory like Haswell TSX can also be tried first if available. Of course, this wouldn't be able to handle external function calls and modifications of shared memory via unsafe pointers: this could be handled by having a special "unsafe" construct that passes a closure to unwind the changes. Calling irreversible functions like I/O would need to cause a transaction abort/throw an exception. Also, some things like RWARC modifications would be impossible to handle without a full STM implementation (with MVCC and so on). The biggest drawback of this is that it will double code size and compilation time. I'm not sure if it's worthwhile since it cannot work in general due to I/O, and simple cases can be handled with the syntax sugar proposed or doing the same by hand with Result return types and so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Jun 6 20:55:37 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 6 Jun 2013 23:55:37 -0400 Subject: [rust-dev] jemalloc now the default allocator Message-ID: Hello all, As of 5d2cadb, the default allocator used in the runtime on all platforms is now jemalloc. This provides significant allocation speedup on Windows and Mac, and good speedup on Linux. Additionally, memory usage should be lower and (untested) less fragmented. There are some numbers on issue #6897. This shouldn't break or otherwise negatively affect existing code (if it does, open an issue, as usual). From bill_myers at outlook.com Thu Jun 6 21:03:50 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 04:03:50 +0000 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers Message-ID: Reference counting is generally more desirable than garbage collection, since it is simple and deterministic, and avoids scanning the whole heap of the program, which causes pauses, destroys caches, prevents effective swapping and requires to tolerate increasing memory usage by a multiplicative factor to allow GC to be amortized to be linear in the number of dead objects in the general case. However, it cannot support cycles (without destroying its advantages over GC), so it is a good idea to statically prevent them to avoid leaks. Currently Rust has several types of reference-counted pointers, with different strategies to do that: - The @ and @mut pointer, which seem to allow cycles and cause them to leak until task termination, although it's sort of supposed to use a GC instead eventually or be removed. - The MutexARC type, which allows cycles but requires unsafe code - The Rc and ARC types, that avoid cycles by not allowing mutations - The RcMut and RWARC type, that avoid cycles by not allowing rc pointers in the data The issue is that none of this is optimal, since for instance it is not possible to have an RcMut where A contains an RcMut but B contains no pointers, even though it is perfectly safe to do so, and in general reference counted pointers cannot be created for some types like the A in this example. However, there seems to be a good solution: the following rule extends both the "no mutations" and "no rc pointers" cases while allowing the above, and allows creating rc pointers to any type at the expense of forbidding some mutations: *** If there is a cycle of pointers (of any kind, including raw, owned and borrowed, excluding raw pointers annotated as weak references) or enums containing at least one reference-counted pointer, forbid mutating all those pointers (even with an &mut) unless the object being assigned is the result of an expression that doesn't include pointers to previously-created objects (and thus cannot point to the pointer), or the value containing the pointer is on the stack or owned by a stack slot (and thus is not in an rc box or owned by it, and so cannot be pointed to by the assigned value) *** Here a cycle means a cyclic sequence of structure fields such that each can point to an instance of the structure of the next field in the sequence. So for instance this case would be allowed: struct A {b: Rc} struct B {a: Option>} but the A.a and B.b fields would be immutable even with &mut A or &mut B pointers, and would only be mutable if the A or B structure is on the stack or owned from the stack (and thus has no incoming rc pointers). On the other hand, this would be allowed with no restrictions since the points-to relationship of the types is acyclic: struct A {b: RcMut) struct B {c: Rc} struct C {x: u32} To implement this, one would need to extend the language with an annotation to tell the compiler that the raw pointers inside of Rc/RcMut/ARC/RWARC/etc. are to be treated as "reference-counted" pointers. The compiler can then perform the static analysis required (do an SCC decomposition of a graph containing types, enum members and pointer fields, with edges from types to contained types, enum members and pointer fields, from pointer fields to the pointed type, from traits to all possible implementing types, from enum to enum member, and then forbid modification to pointers in any SCC with at least one reference-counted pointer) There are at least two complexities: public trait pointers needs to be assumed to be able to point to anything (unless one can see the whole program), while generic types will need to be analyzed in their specialized versions, which means that some methods would be valid to call only for some values of generic type parameters, and that the analysis needs to be done from scratch globally for every module compilation. In addition to all this, weak versions of all rc pointers should be supported (to allow weak "parent" references, for instance), which would require a further annotation telling the compiler that the contained unsafe pointer is "weak" and thus does not participate in the pointer cycle analysis. Also, a keyword can be provided to allow the forbidden mutations at the cost of doing a full run-time scan of the assigned value to ensure it doesn't point to the object with the field being assigned, and failing or returning an error if the check fails (this probably needs to be explicit since it can of course be very expensive to do the scan) Some structures like mutable strong doubly-linked lists would not be allowed by this and would instead require an ad-hoc implementation with raw pointers (where the list node smart pointer will increase the reference count on both the node, and the whole list, and splicing will be O(n)). This infrastructure should be able to handle most programs without using garbage collection, except those that are interpreters of garbage-collected languages or implement interfaces that require garbage collection (e.g. AF_UNIX sockets with fd passing, where the fd can be an unix socket itself). It's also possible that there are even better approaches in the literature or other languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Thu Jun 6 21:21:41 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 6 Jun 2013 21:21:41 -0700 Subject: [rust-dev] Suggestions for small Rust programs for use in a tutorial? Message-ID: Hi all, I'm currently working on slides for a Rust tutorial, that I'm going to be presenting at Open Source Bridge in Portland in two weeks. I wanted the tutorial to be driven by examples from real code, but I've had a hard time finding examples that are both relevant, and self-contained enough to use in a talk. I specified that I expect the audience to know how to program in some language and to be at least a little bit familiar with C, so I'm assuming relatively little about their knowledge. I'm certainly not assuming that they have already looked at Rust. I'd like to have an extended example to illustrate borrowed pointers, and another (can be separate or related) to illustrate traits. I've done a fair amount of looking through Servo; Patrick's sprocketnes and fempeg projects; and the Rust standard libraries. The first three seem to make relatively little use of traits (and many of the traits that are there seem to be collections of methods rather than representing concepts that could be described more abstractly). Of course, borrowed pointers are everywhere, but it's hard for me to say what is a good, self-contained example for them. In the current draft of my talk, I'm using the Container and Map traits and the HashMap implementation from the standard library to illustrate both traits and borrowed pointers. I'm okay with keeping it that way, but I'd love to use a less textbook-y example that shows off what Rust can do. I had hoped some of the test cases under bench/ might be good for this, but many of them are written in fairly old-style Rust. Thanks in advance, and I'll certainly acknowledge in the talk anybody who points me to a good example. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From vadimcn at gmail.com Thu Jun 6 15:19:09 2013 From: vadimcn at gmail.com (Vadim) Date: Thu, 6 Jun 2013 15:19:09 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: On Wed, Jun 5, 2013 at 9:09 PM, Daniel Micay wrote: > > All kinds of external iterators implement the following trait, whether > they are > a fibonacci number generator, a reverse iterator over a vector or iterator > over > a range in a sorted set: > > pub trait Iterator { > /// Advance the iterator and return the next value. Return `None` > when the end is reached. > fn next(&mut self) -> Option; > } > Based on my experience with iterators in other languages, I would like throw in the following idea: pub trait BlockyIterator { /// Advance the iterator and return the next block of values. Return empty vector when the end is reached fn next(&mut self) -> &'self [A] } Rationale: when concrete type of the iterator is known, the next() method inlines nicely. However, when used polymorphically, every iterator advancement turns into a function call. A lot of that overhead could be shaved off, if iterators can return multiple values at a time. A "normal" Iterator can then be implemented on top of this trait. This is especially applicable to types which already store elements in an vector, most notably [T] itself. > However, without support for compiling a function to a state machine (C# > does > this for yield), traversal of a recursive data structure has to be manually > translated to a procedural algorithm with an explicit stack. For complex > data > structures, this process can be very difficult. > > I'm hopeful Rust will gain support for this down the road after 1.0. If it > does, there will be no reason to write immutable internal iterators. > This could also be implemented with co-routines. Supposedly stack switching will be separated from tasks sometime soon? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 16:13:08 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 19:13:08 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: On Thu, Jun 6, 2013 at 6:19 PM, Vadim wrote: > > Based on my experience with iterators in other languages, I would like throw > in the following idea: > > pub trait BlockyIterator { > /// Advance the iterator and return the next block of values. > Return empty vector when the end is reached > fn next(&mut self) -> &'self [A] > } > > Rationale: when concrete type of the iterator is known, the next() method > inlines nicely. However, when used polymorphically, every iterator > advancement turns into a function call. A lot of that overhead could be > shaved off, if iterators can return multiple values at a time. A "normal" > Iterator can then be implemented on top of this trait. > > This is especially applicable to types which already store elements in an > vector, most notably [T] itself. As you've mentioned, the existing Iterator trait allows you to return data in blocks if you desire (Iterator<&[T]> or Iterator<~[T]>). Essentially only vectors and vector-based deques can return a slice, so it wouldn't really be a generic trait. > This could also be implemented with co-routines. Supposedly stack > switching will be separated from tasks sometime soon? Coroutines/generators are quite cool, but they're far from free if they're implemented with context switching between code and not with a state machine - a switch involves swapping the registers and wiping out a lot of the cache. The C# solution can be as efficient as the code written by hand since it just generates a struct and a stateful iteration function, which is right in line with Rust's system's programming niche. The hard part would be implementing it, and managing to keep the borrow/move checking errors comprehensible (all your locals essentially become fields). From vadimcn at gmail.com Thu Jun 6 17:01:41 2013 From: vadimcn at gmail.com (Vadim) Date: Thu, 6 Jun 2013 17:01:41 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: On Thu, Jun 6, 2013 at 4:13 PM, Daniel Micay wrote: > On Thu, Jun 6, 2013 at 6:19 PM, Vadim wrote: > > > > Based on my experience with iterators in other languages, I would like > throw > > in the following idea: > > > > pub trait BlockyIterator { > > /// Advance the iterator and return the next block of values. > > Return empty vector when the end is reached > > fn next(&mut self) -> &'self [A] > > } > > > > Rationale: when concrete type of the iterator is known, the next() method > > inlines nicely. However, when used polymorphically, every iterator > > advancement turns into a function call. A lot of that overhead could be > > shaved off, if iterators can return multiple values at a time. A > "normal" > > Iterator can then be implemented on top of this trait. > > > > This is especially applicable to types which already store elements in an > > vector, most notably [T] itself. > > As you've mentioned, the existing Iterator trait allows you to return > data in blocks if you desire (Iterator<&[T]> or Iterator<~[T]>). > Essentially only vectors and vector-based deques can return a slice, > so it wouldn't really be a generic trait. > The iterator object itself can contain a fixed size buffer into which it copies objects before returning slice to the caller. This would work for almost any container type. Perhaps I'm confused about the amount of inlining that Rust can perform. Do you expect that iterator.next() calls will be inlined across crate boundaries? Coroutines/generators are quite cool, but they're far from free if > they're implemented with context switching between code and not with a > state machine - a switch involves swapping the registers and wiping > out a lot of the cache. > Hmm, yes, that true... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Thu Jun 6 19:22:54 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 02:22:54 +0000 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <51B0D418.6030909@mozilla.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com>, <51B00CD8.4090608@mozilla.com>, <51B0D418.6030909@mozilla.com> Message-ID: Scala has a similar design, with the following traits: - TraversableOnce: can be internally iterated once (has a foreach() method that takes a closure) - Traversable: can be internally iterated unlimited times (has a foreach() method that takes a closure) - Iterable: can be externally iterated (has an iterator() method that returns an Iterator trait) The way it works is that Iterable extends Traversable, which extends TraversableOnce, and the for loop just uses TraversableOnce, and Iterable has a default implementation of the TraversableOnce foreach() function using the iterator() function. Also, the Iterator trait itself extends TraversableOnce, implementing foreach() by mutating itself. It might be a good idea to investigate copying this design. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.sylvan at gmail.com Thu Jun 6 20:01:28 2013 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu, 6 Jun 2013 20:01:28 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers wrote: > Scala has a similar design, with the following traits: > - TraversableOnce: can be internally iterated once (has a foreach() method > that takes a closure) > - Traversable: can be internally iterated unlimited times (has a foreach() > method that takes a closure) > - Iterable: can be externally iterated (has an iterator() method that > returns an Iterator trait) > > The way it works is that Iterable extends Traversable, which extends > TraversableOnce, and the for loop just uses TraversableOnce, and Iterable > has a default implementation of the TraversableOnce foreach() function > using the iterator() function. > > Also, the Iterator trait itself extends TraversableOnce, implementing > foreach() by mutating itself. > > It might be a good idea to investigate copying this design. > I find Andrei Alexandrescu's argument about range-based iterators pretty persuasive: http://www.informit.com/articles/article.aspx?p=1407357 Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 20:16:41 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 6 Jun 2013 23:16:41 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: On Thu, Jun 6, 2013 at 11:01 PM, Sebastian Sylvan wrote: > > > On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers wrote: >> >> Scala has a similar design, with the following traits: >> - TraversableOnce: can be internally iterated once (has a foreach() method >> that takes a closure) >> - Traversable: can be internally iterated unlimited times (has a foreach() >> method that takes a closure) >> - Iterable: can be externally iterated (has an iterator() method that >> returns an Iterator trait) >> >> The way it works is that Iterable extends Traversable, which extends >> TraversableOnce, and the for loop just uses TraversableOnce, and Iterable >> has a default implementation of the TraversableOnce foreach() function using >> the iterator() function. >> >> Also, the Iterator trait itself extends TraversableOnce, implementing >> foreach() by mutating itself. >> >> It might be a good idea to investigate copying this design. > > > I find Andrei Alexandrescu's argument about range-based iterators pretty > persuasive: http://www.informit.com/articles/article.aspx?p=1407357 > > Seb Andrei usually talks about ranges in contrast with C++ iterators, so it's a bit different than comparing with the Iterator trait Rust is using. C++ iterators don't know when they've reached the end of the range, so you have to compare them with a sentinel end iterator. In that sense, Rust's iterator is a range and the `next` method is comparable to the pop method on D ranges. From danielmicay at gmail.com Thu Jun 6 21:52:03 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 7 Jun 2013 00:52:03 -0400 Subject: [rust-dev] Suggestions for small Rust programs for use in a tutorial? In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 12:21 AM, Tim Chevalier wrote: > Hi all, > > I'm currently working on slides for a Rust tutorial, that I'm going to > be presenting at Open Source Bridge in Portland in two weeks. I wanted > the tutorial to be driven by examples from real code, but I've had a > hard time finding examples that are both relevant, and self-contained > enough to use in a talk. I specified that I expect the audience to > know how to program in some language and to be at least a little bit > familiar with C, so I'm assuming relatively little about their > knowledge. I'm certainly not assuming that they have already looked at > Rust. > > I'd like to have an extended example to illustrate borrowed pointers, > and another (can be separate or related) to illustrate traits. I've > done a fair amount of looking through Servo; Patrick's sprocketnes and > fempeg projects; and the Rust standard libraries. The first three seem > to make relatively little use of traits (and many of the traits that > are there seem to be collections of methods rather than representing > concepts that could be described more abstractly). Of course, borrowed > pointers are everywhere, but it's hard for me to say what is a good, > self-contained example for them. In the current draft of my talk, I'm > using the Container and Map traits and the HashMap implementation from > the standard library to illustrate both traits and borrowed pointers. > I'm okay with keeping it that way, but I'd love to use a less > textbook-y example that shows off what Rust can do. I had hoped some > of the test cases under bench/ might be good for this, but many of > them are written in fairly old-style Rust. > > Thanks in advance, and I'll certainly acknowledge in the talk anybody > who points me to a good example. > > Cheers, > Tim The Map trait is a bit ugly because it's sorely in need of default methods to reduce the burden on implementations. I think the Iterator trait in the `std::iterator` module is a great example, because it's a simple trait and it's easy to demonstrate implementations and adaptors for it. It's also a nice way of showing off the lifetime system because with owned containers you can't invalidate the iterators. I don't think there are many other languages able to represent something like statically freezable mutable containers. From catamorphism at gmail.com Thu Jun 6 22:11:45 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 6 Jun 2013 22:11:45 -0700 Subject: [rust-dev] Suggestions for small Rust programs for use in a tutorial? In-Reply-To: References: Message-ID: Jeaye, >>Tim, Not entirely sure if these are what you want, but bjz's glfw-rs repo has some basic examples of using glfw-rs that may serve as a basic example of Rust, too. See these: https://github.com/bjz/glfw-rs/blob/master/examples/cursor.rs https://github.com/bjz/glfw-rs/blob/master/examples/window.rs https://github.com/bjz/glfw-rs/blob/master/examples/gl-struct.rs Along with the rest here: https://github.com/bjz/glfw-rs/tree/master/examples<<< Thanks for the suggestion! So far I'm not sure if these illustrate the main concepts I'm trying to get across, but they look great as potential additional extended examples. On Thu, Jun 6, 2013 at 9:52 PM, Daniel Micay wrote: > The Map trait is a bit ugly because it's sorely in need of default > methods to reduce the burden on implementations. > > I think the Iterator trait in the `std::iterator` module is a great > example, because it's a simple trait and it's easy to demonstrate > implementations and adaptors for it. It's also a nice way of showing > off the lifetime system because with owned containers you can't > invalidate the iterators. I don't think there are many other languages > able to represent something like statically freezable mutable > containers. This is a great suggestion as well. I don't know why iterators didn't occur to me as a potential example; they almost stand alongside traits and borrowed pointers as major attractions on a tour of Rust. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From danielmicay at gmail.com Thu Jun 6 22:15:02 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 7 Jun 2013 01:15:02 -0400 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 12:03 AM, Bill Myers wrote: > Reference counting is generally more desirable than garbage collection, > since it is simple and deterministic, and avoids scanning the whole heap of > the program, which causes pauses, destroys caches, prevents effective > swapping and requires to tolerate increasing memory usage by a > multiplicative factor to allow GC to be amortized to be linear in the number > of dead objects in the general case. Reference counting is faster than a good garbage collector with large, long-lived objects, but there are also many cases when it's slower. Small objects are greatly increased in size by the reference count and in Rust for mutable reference counted types, there's also the freeze state. On x86_64, a 8-byte allocation becomes 24 bytes under a minimal mutable reference counted type (value, count, freeze) and then rounded by jemalloc/tcmalloc/glibc to a 32 byte allocation. If you include weak pointers, you need a second allocation with the pointer, strong reference count and weak reference count (24 bytes, rounding to 32 bytes) and the main allocation will have the actual 8-byte object and the freeze status (so 16 bytes). If you pass around the objects by-value frequently, the reference counting will greatly outweigh the cost of garbage collection cycles. A garbage collector can compact the heap, since mutable boxes keep track of whether they are borrowed from for freezing. A good allocator like jemalloc can avoid heap fragmentation from small objects but not large ones like vectors. > However, there seems to be a good solution: the following rule extends both > the "no mutations" and "no rc pointers" cases while allowing the above, and > allows creating rc pointers to any type at the expense of forbidding some > mutations: > *** If there is a cycle of pointers (of any kind, including raw, owned and > borrowed, excluding raw pointers annotated as weak references) or enums > containing at least one reference-counted pointer, forbid mutating all those > pointers (even with an &mut) unless the object being assigned is the result > of an expression that doesn't include pointers to previously-created objects > (and thus cannot point to the pointer), or the value containing the pointer > is on the stack or owned by a stack slot (and thus is not in an rc box or > owned by it, and so cannot be pointed to by the assigned value) *** > > Here a cycle means a cyclic sequence of structure fields such that each can > point to an instance of the structure of the next field in the sequence. > > So for instance this case would be allowed: > struct A {b: Rc} > struct B {a: Option>} > > but the A.a and B.b fields would be immutable even with &mut A or &mut B > pointers, and would only be mutable if the A or B structure is on the stack > or owned from the stack (and thus has no incoming rc pointers). > > On the other hand, this would be allowed with no restrictions since the > points-to relationship of the types is acyclic: > struct A {b: RcMut) > struct B {c: Rc} > struct C {x: u32} > > To implement this, one would need to extend the language with an annotation > to tell the compiler that the raw pointers inside of Rc/RcMut/ARC/RWARC/etc. > are to be treated as "reference-counted" pointers. > > The compiler can then perform the static analysis required (do an SCC > decomposition of a graph containing types, enum members and pointer fields, > with edges from types to contained types, enum members and pointer fields, > from pointer fields to the pointed type, from traits to all possible > implementing types, from enum to enum member, and then forbid modification > to pointers in any SCC with at least one reference-counted pointer) > > There are at least two complexities: public trait pointers needs to be > assumed to be able to point to anything (unless one can see the whole > program), while generic types will need to be analyzed in their specialized > versions, which means that some methods would be valid to call only for some > values of generic type parameters, and that the analysis needs to be done > from scratch globally for every module compilation. This would be a big step away from the advantages of Rust's current trait system. Right now, if the definition of a generic function type checks, it's valid for all possible types implementing the trait bounds. There are no hidden or implicit requirements. > In addition to all this, weak versions of all rc pointers should be > supported (to allow weak "parent" references, for instance), which would > require a further annotation telling the compiler that the contained unsafe > pointer is "weak" and thus does not participate in the pointer cycle > analysis. Weak pointers involve a performance hit for using reference counting without them as covered above. Additionally, they also open up another kind of dynamic failure (dead weak pointers) avoided by using garbage collection. > Also, a keyword can be provided to allow the forbidden mutations at the cost > of doing a full run-time scan of the assigned value to ensure it doesn't > point to the object with the field being assigned, and failing or returning > an error if the check fails (this probably needs to be explicit since it can > of course be very expensive to do the scan) > > Some structures like mutable strong doubly-linked lists would not be allowed > by this and would instead require an ad-hoc implementation with raw pointers > (where the list node smart pointer will increase the reference count on both > the node, and the whole list, and splicing will be O(n)). > > This infrastructure should be able to handle most programs without using > garbage collection, except those that are interpreters of garbage-collected > languages or implement interfaces that require garbage collection (e.g. > AF_UNIX sockets with fd passing, where the fd can be an unix socket itself). > > It's also possible that there are even better approaches in the literature > or other languages. From pwalton at mozilla.com Thu Jun 6 23:21:05 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 06 Jun 2013 23:21:05 -0700 Subject: [rust-dev] jemalloc now the default allocator In-Reply-To: References: Message-ID: <51B17BD1.60506@mozilla.com> On 6/6/13 8:55 PM, Corey Richardson wrote: > Hello all, > > As of 5d2cadb, the default allocator used in the runtime on all > platforms is now jemalloc. This provides significant allocation > speedup on Windows and Mac, and good speedup on Linux. Additionally, > memory usage should be lower and (untested) less fragmented. There are > some numbers on issue #6897. > > This shouldn't break or otherwise negatively affect existing code (if > it does, open an issue, as usual). This is great work. Thanks a lot for volunteering to do it! Patrick From corey at octayn.net Fri Jun 7 04:12:24 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 07:12:24 -0400 Subject: [rust-dev] jemalloc now the default allocator In-Reply-To: <51B17BD1.60506@mozilla.com> References: <51B17BD1.60506@mozilla.com> Message-ID: On Fri, Jun 7, 2013 at 2:21 AM, Patrick Walton wrote: > This is great work. Thanks a lot for volunteering to do it! > > Patrick > It was mostly Daniel, I take no credit :) From jeaye at arrownext.com Thu Jun 6 21:31:21 2013 From: jeaye at arrownext.com (Jeaye) Date: Thu, 06 Jun 2013 21:31:21 -0700 Subject: [rust-dev] Suggestions for small Rust programs for use in a tutorial? In-Reply-To: References: Message-ID: <51B16219.2000409@arrownext.com> On 06/06/2013 09:21 PM, Tim Chevalier wrote: > Hi all, > > I'm currently working on slides for a Rust tutorial, that I'm going to > be presenting at Open Source Bridge in Portland in two weeks. > Tim, Not entirely sure if these are what you want, but bjz's glfw-rs repo has some basic examples of using glfw-rs that may serve as a basic example of Rust, too. See these: https://github.com/bjz/glfw-rs/blob/master/examples/cursor.rs https://github.com/bjz/glfw-rs/blob/master/examples/window.rs https://github.com/bjz/glfw-rs/blob/master/examples/gl-struct.rs Along with the rest here: https://github.com/bjz/glfw-rs/tree/master/examples Best wishes with your presentation. Cheers, Jeaye From sebastian.sylvan at gmail.com Thu Jun 6 21:58:58 2013 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu, 6 Jun 2013 21:58:58 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: The linked article contrasts them with the GoF-style iterators as well. The Rust Iterator trait is similar to the "one pass ranges" (and possibly forward ranges), but not double-ended ranges or random-access ranges. It's the *family* of range-based iterators that makes it flexible (e.g. allowing you to write an efficient in-place reverse without knowing the underlying data structure, using a double-ended range). See fig. 3: http://www.informit.com/content/images/art_alexandrescu3_iterators/elementLinks/alexandrescu3_fig03.jpg On Thu, Jun 6, 2013 at 8:16 PM, Daniel Micay wrote: > On Thu, Jun 6, 2013 at 11:01 PM, Sebastian Sylvan > wrote: > > > > > > On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers > wrote: > >> > >> Scala has a similar design, with the following traits: > >> - TraversableOnce: can be internally iterated once (has a foreach() > method > >> that takes a closure) > >> - Traversable: can be internally iterated unlimited times (has a > foreach() > >> method that takes a closure) > >> - Iterable: can be externally iterated (has an iterator() method that > >> returns an Iterator trait) > >> > >> The way it works is that Iterable extends Traversable, which extends > >> TraversableOnce, and the for loop just uses TraversableOnce, and > Iterable > >> has a default implementation of the TraversableOnce foreach() function > using > >> the iterator() function. > >> > >> Also, the Iterator trait itself extends TraversableOnce, implementing > >> foreach() by mutating itself. > >> > >> It might be a good idea to investigate copying this design. > > > > > > I find Andrei Alexandrescu's argument about range-based iterators pretty > > persuasive: http://www.informit.com/articles/article.aspx?p=1407357 > > > > Seb > > Andrei usually talks about ranges in contrast with C++ iterators, so > it's a bit different than comparing with the Iterator trait Rust is > using. C++ iterators don't know when they've reached the end of the > range, so you have to compare them with a sentinel end iterator. In > that sense, Rust's iterator is a range and the `next` method is > comparable to the pop method on D ranges. > -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jun 6 22:05:29 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 7 Jun 2013 01:05:29 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan wrote: > The linked article contrasts them with the GoF-style iterators as well. > > The Rust Iterator trait is similar to the "one pass ranges" (and possibly > forward ranges), but not double-ended ranges or random-access ranges. It's > the *family* of range-based iterators that makes it flexible (e.g. allowing > you to write an efficient in-place reverse without knowing the underlying > data structure, using a double-ended range). > > See fig. 3: > http://www.informit.com/content/images/art_alexandrescu3_iterators/elementLinks/alexandrescu3_fig03.jpg The extent to which you can have mutable iterators in Rust is pretty small, because of the memory safety requirement. Iterators can't open up a hole allowing multiple mutable references to the same object to be obtained, so I don't think mutable bidirectional or random access iterators are possible. Forward iterators can't ever give you an alias because they're a single pass over the container. It's an easy guarantee to provide. From rust-dev at tomlee.co Thu Jun 6 23:20:00 2013 From: rust-dev at tomlee.co (Tom Lee) Date: Thu, 6 Jun 2013 23:20:00 -0700 Subject: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm] Message-ID: Mozilla's own Tim Chevalier is giving a preview of his OSBridge talk, "Rust: A Friendly Introduction" later this month. Should you be in town the evening of June 17th, please drop by! Full details on Calagator: http://calagator.org/events/1250464376 More about Tim's talk: http://opensourcebridge.org/sessions/970 Hope to see you there! Cheers, Tom -- Tom Lee / http://tomlee.co / @tglee From corey at octayn.net Fri Jun 7 04:53:47 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 07:53:47 -0400 Subject: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm] In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 2:20 AM, Tom Lee wrote: > Mozilla's own Tim Chevalier is giving a preview of his OSBridge talk, > "Rust: A Friendly Introduction" later this month. Should you be in > town the evening of June 17th, please drop by! > Will this be recorded? From jeaye at arrownext.com Fri Jun 7 09:05:52 2013 From: jeaye at arrownext.com (Jeaye) Date: Fri, 07 Jun 2013 09:05:52 -0700 Subject: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm] In-Reply-To: References: Message-ID: <51B204E0.909@arrownext.com> On 06/07/2013 04:53 AM, Corey Richardson wrote: > Will this be recorded? > _______________________________________________ > +1 for recording it! J From y-fujii at mimosa-pudica.net Fri Jun 7 09:56:08 2013 From: y-fujii at mimosa-pudica.net (Yasuhiro Fujii) Date: Sat, 8 Jun 2013 01:56:08 +0900 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: Hi, I'm excited about Rust's iterator library based on external style. On the other hand, I was thinking about extending current "for" syntax/protocol to support returning values, which is useful for filter_map() like functions [*0]. (It might have been discussed before, but I cannot find it in rust-dev archives) Example: fn test() { let src = ~[0, 1, 2, 3, 4]; let mut sum = 0; let dst = for src.filter_map() |&x| { sum += x; if sum == 10 { break x + 1; // => (false, Some(x + 1)) } else if sum > 10 { break // => (false, None) } if x % 2 == 0 { loop // => (true, None) } else { loop x + 1; // => (true, Some(x + 1)) } } } // In extended "for", loop/break statements in the closures are // transformed with following rules: // loop => return (true , None) // loop val => return (true , Some(val)) // break => return (false, None) // break val => return (false, Some(val)) vec::filter_map() should be slightly modified from original [*1]: pure fn filter_map(v: &[T], f: fn(t: &T) -> (bool, Option)) -> ~[U] { let mut result = ~[]; for each(v) |elem| { let (cont, val) = f(elem); match val { None => { /* no-op */ } Some(result_elem) => unsafe { result.push(result_elem); } } cont || break; } result } With this extension, closure-calling "for" syntactic sugar is still useful even if Rust's iterators become external style. In Daniel Micay's example: fn main() { let mut it = Counter::new(0.0, 1.0) .take_while(|x| *x < 10000000.0) .transform(|x| x / 2.0) .transform(|x| x + 2.0); } This can be rewritten as follows (with appropriate FilterMapIterator<> implementation): fn main() { let mut it = for Counter::new(0.0, 1.0).filter_map() |&x| { if (x < 10000000.0) { x / 2.0 + 2.0 } else { break; } } } Any combination of transform/filter/skip_whike/take_while/skip/take/scan can be converted. I think this is more readable and expressive. Many languages have special syntax for manipulating iterators (Python's generator comprehension, C#'s query expression, Haskell's List monads, etc. I know they are based on very different approaches and different range of application, but for similar purposes). This extension may be seen as one of them. [*0]: Sorry for out of the topic in this thread, but I think it is also useful (and better consistency) to enable "while" statement to return value like following: let xs = ~[0, 1, 2, 4, 5]; let found_two = while i < xs.size() { if xs[i] == 2 { break true } } else { // "else" clause is executed when "while" statement is terminated // NOT by a "break" statement. (Python behaves like the same) false } [*1]: Original implementation vec::filter_map(): pure fn filter_map(v: &[T], f: fn(t: &T) -> Option) -> ~[U] { let mut result = ~[]; for each(v) |elem| { match f(elem) { None => { /* no-op */ } Some(result_elem) => unsafe { result.push(result_elem); } } } result On Thu, Jun 6, 2013 at 1:09 PM, Daniel Micay wrote: > A quick terminology refresher, for those who aren't familiar with it: > > * Internal iterator: takes a closure, runs the closure until it asks to break > * External iterator: state machine, advanced by the caller in a loop > > To a caller, external iterators provide the most functionality, because they > can be used as an internal iterator. You lose the state of an internal iterator > by breaking out of iterator, so generic algorithms like zip, union, intersect > and merge can't be implemented for a pair of iterators. > > # Issues with internal iterators in Rust > > A few months ago, we only had internal iterators and there were no generic > algorithms to use with any iterator - only with BaseIter's `each` method. > > Rust's internal iterators implement the protocol encoded in Rust's for > statement, but it's not possible to give them all a common trait or implement > generic methods or functions taking any internal iterator. > > As a workaround, we can write algorithms assuming internal iterators only take > one argument (the closure): > > fn count(f: &fn(fn(T) -> bool) -> bool) -> uint > > The caller has to use a partial function to call these adaptors, for which we > lack sugar: > > count(|f| uint::range(0, 10, f)) > > For simple functions, this is fairly reasonable once you're used to it. It > quickly gets out of control though, even for a simple function like filter: > > filter(pred: &fn(&T) -> bool, input: &fn(&fn(T) -> bool) -> bool, output: &fn(T) -> bool) -> bool {} > > Sadly, `filter_ref` is also needed to work around closures behaving badly with > lifetimes. An example of the problem with `fold_ref`: > > fn product>(iter: &fn(f: &fn(&T) -> bool) -> bool) -> T { > fold_ref(One::one::(), iter, |a, x| *a = a.mul(x)) > } > > Since `product` expects an iterator yielding `&T` (a borrowed pointer in any > region), it won't work with `fold` because that requires the borrowed pointer > to have the same type (and thus lifetime) for every iteration like `&'a int`. > > This issue with borrowed pointers was blocking me from replacing the existing > algorithms reimplemented for both `str` and `vec` with the generic ones. > > Chaining together iteration algorithms is a common use case, but even chaining > two together is confusing at first: > > to_vec(|g| filter(|&x| *x < 3, |f| xs.each(f), g) > > Another more alarming issue is that with internal iterators, the `break` and > `return` statements don't always work in a `for` loop. If the iterator isn't > implemented correctly, the loop will keep going. > > This also has borrow checking implications, because the compiler can't assume > those statements actually cause flow control to leave the loop immediately. > > # External iterators > > Based on the above, you might think generic iteration algorithms in Rust are a > bleak prospect. However, we already have a nice external iterator library, and > they don't suffer from the above issues. > > All kinds of external iterators implement the following trait, whether they are > a fibonacci number generator, a reverse iterator over a vector or iterator over > a range in a sorted set: > > pub trait Iterator { > /// Advance the iterator and return the next value. Return `None` when the end is reached. > fn next(&mut self) -> Option; > } > > Generic adaptors are implemented on `Iterator`, and many of them are `Iterator` > implementations themselves: > > use std::iterator::*; > > fn main() { > let mut it = Counter::new(0.0, 1.0) > .take_while(|x| *x < 10000000.0) > .transform(|x| x / 2.0) > .transform(|x| x + 2.0); > println(it.fold(0.0, |a, b| a + b).to_str()) > } > > If you're curious, the optimized LLVM IR: http://ix.io/5Xl > > Unlike internal iterators, external iterators only run one iteration at a time, > so a `for` loop designed for them would always be able to succeed with `break` > and `return`. It would also be able to avoid the ugly `advance` wrapper > currently required to use external iterators with `for`. > > // The current situation, wrapping an external iterator as an internal one > // > // Since the advance method is not known the be correct, borrow checking > // still assumes `return` and `break` are imperfect. > for xs.zip(ys).advance |x| { ... } > > // A hypothetical `for` loop using the `Iterator` trait > for iterator |x| { ... } > > // It could also fall back to an `Iterable` trait and obtain an iterator > for container |x| { ... } > > External iterators also avoid the problems with references and closures, > because they simply return `T` rather than passing it to a closure. > > # Why not just switch to external iterators? > > Algorithms that can be represented easily without the call stack are as easy to > write as either an internal or external iterator. > > However, without support for compiling a function to a state machine (C# does > this for yield), traversal of a recursive data structure has to be manually > translated to a procedural algorithm with an explicit stack. For complex data > structures, this process can be very difficult. > > I'm hopeful Rust will gain support for this down the road after 1.0. If it > does, there will be no reason to write immutable internal iterators. > > Another issue is mutability, as you can write iterators that are able to mutate > containers. With internal iterators, this is easy to do with safe code. With > external ones, it will `unsafe` and won't be easy to get right. > > # Solution? > > I don't have any proposal to completely solve this issue. :) > > I think extending the built-in `for` loop to work with external iterators > should be considered, because right now the verbosity discourages using them > and makes borrow checking more painful than it has to be. > > It could treat functions as internal iterators, and look for an `Iterator` > implementation (using a `lang` item) for external ones. > > Python's `for` loop starts by looking for an iterator (a `__next__` method) and > falls back to an iterable (an `__iter__` method) so behaviour like this isn't > an alien concept. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From bill_myers at outlook.com Fri Jun 7 10:12:49 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 17:12:49 +0000 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: , Message-ID: > This would be a big step away from the advantages of Rust's current > trait system. Right now, if the definition of a generic function type > checks, it's valid for all possible types implementing the trait > bounds. There are no hidden or implicit requirements. Yes, but since Rust, like C++, instantiates generic functions at specialization time, this shouldn't be an issue. It just means that, like with C++ templates, compilation errors concerning the template code can happen at instantiation time. In general, this is unavoidable with a mutable reference counting scheme, because if you have something like this: struct A { v: T } impl A { fn set_v(&mut self, v: T) { self.v = v; } } Then you can allow to call set_v when T is u32, but not when T contains an rc pointer back to A because that could create a cycle for some values of v. The alternative is to just disallow programs that have cycles of rc pointers where at least one of them is mutable, which is less powerful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Jun 7 10:28:38 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 7 Jun 2013 13:28:38 -0400 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 1:12 PM, Bill Myers wrote: > >> This would be a big step away from the advantages of Rust's current >> trait system. Right now, if the definition of a generic function type >> checks, it's valid for all possible types implementing the trait >> bounds. There are no hidden or implicit requirements. > > Yes, but since Rust, like C++, instantiates generic functions at > specialization time, this shouldn't be an issue. It just means that, like > with C++ templates, compilation errors concerning the template code can > happen at instantiation time. The trait system is explicitly intended to avoid this issue. An error at instantiation can happen at any depth inside function calls, templated structs and default implementations for traits - it would be no different than awful template errors in C++. From fedor at indutny.com Fri Jun 7 10:35:35 2013 From: fedor at indutny.com (Fedor Indutny) Date: Fri, 7 Jun 2013 21:35:35 +0400 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: Message-ID: Reference counting is a bit dumb and always causes a lot of headache afterwards. Rust should support moving garbage collector (at least with restriction to particular "pinned" objects) such as generational incremental collector, because its fast and pretty much reliable and simplier to understand than hacky ref counting system. Cheers, Fedor. On Fri, Jun 7, 2013 at 9:28 PM, Daniel Micay wrote: > On Fri, Jun 7, 2013 at 1:12 PM, Bill Myers wrote: > > > >> This would be a big step away from the advantages of Rust's current > >> trait system. Right now, if the definition of a generic function type > >> checks, it's valid for all possible types implementing the trait > >> bounds. There are no hidden or implicit requirements. > > > > Yes, but since Rust, like C++, instantiates generic functions at > > specialization time, this shouldn't be an issue. It just means that, like > > with C++ templates, compilation errors concerning the template code can > > happen at instantiation time. > > The trait system is explicitly intended to avoid this issue. An error > at instantiation can happen at any depth inside function calls, > templated structs and default implementations for traits - it would be > no different than awful template errors in C++. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Fri Jun 7 10:49:22 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 07 Jun 2013 10:49:22 -0700 Subject: [rust-dev] jemalloc now the default allocator In-Reply-To: References: Message-ID: <51B21D22.1020306@mozilla.com> On 06/06/2013 08:55 PM, Corey Richardson wrote: > Hello all, > > As of 5d2cadb, the default allocator used in the runtime on all > platforms is now jemalloc. This provides significant allocation > speedup on Windows and Mac, and good speedup on Linux. Additionally, > memory usage should be lower and (untested) less fragmented. There are > some numbers on issue #6897. > Thanks, Corey! I've wanted to switch to jemalloc for a long time, but could never get it done. This is an important feature for multithreaded programs. From corey at octayn.net Fri Jun 7 10:57:54 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 13:57:54 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 1:56 PM, Jao-ke Chin-Le wrote: > Jed Estep and I are interns at 10gen (the mongoDB company), and we?re > excited to announce that we?ll be working on the Rust driver for mongo! > Please feel free to contact us with any questions/comments; likewise, we?ll > be in your care for Rust questions. > Very nice! Will you be in IRC? I assume you'll be targeting incoming? From jaoke.chinlee at 10gen.com Fri Jun 7 11:07:34 2013 From: jaoke.chinlee at 10gen.com (Jao-ke Chin-Le) Date: Fri, 7 Jun 2013 14:07:34 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: * Thanks for the response, Corey! We were planning on mostly using the mailing list but will pop by the IRC, yes. We?ll be developing for 0.6 -- is this what you mean by ?targeting incoming?? Also, should the Rust wiki be updated to indicate that the driver for mongo is ?in progress??* On Fri, Jun 7, 2013 at 1:57 PM, Corey Richardson wrote: > On Fri, Jun 7, 2013 at 1:56 PM, Jao-ke Chin-Le > wrote: > > Jed Estep and I are interns at 10gen (the mongoDB company), and we?re > > excited to announce that we?ll be working on the Rust driver for mongo! > > Please feel free to contact us with any questions/comments; likewise, > we?ll > > be in your care for Rust questions. > > > > Very nice! Will you be in IRC? I assume you'll be targeting incoming? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jun 7 11:09:43 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 14:09:43 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 2:07 PM, Jao-ke Chin-Le wrote: > We were planning on mostly using the mailing list but will pop by the IRC, > yes. We?ll be developing for 0.6 -- is this what you mean by ?targeting > incoming?? > No. 0.6 is already hopelessly out of date. By incoming I mean the incoming branch of the git repo, where all new development lands after passing tests. > Also, should the Rust wiki be updated to indicate that the driver for mongo > is ?in progress?? > Yes From matthieu.monrocq at gmail.com Fri Jun 7 09:10:11 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 7 Jun 2013 18:10:11 +0200 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: On Fri, Jun 7, 2013 at 7:05 AM, Daniel Micay wrote: > On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan > wrote: > > The linked article contrasts them with the GoF-style iterators as well. > > > > The Rust Iterator trait is similar to the "one pass ranges" (and possibly > > forward ranges), but not double-ended ranges or random-access ranges. > It's > > the *family* of range-based iterators that makes it flexible (e.g. > allowing > > you to write an efficient in-place reverse without knowing the underlying > > data structure, using a double-ended range). > > > > See fig. 3: > > > http://www.informit.com/content/images/art_alexandrescu3_iterators/elementLinks/alexandrescu3_fig03.jpg > > The extent to which you can have mutable iterators in Rust is pretty > small, because of the memory safety requirement. Iterators can't open > up a hole allowing multiple mutable references to the same object to > be obtained, so I don't think mutable bidirectional or random access > iterators are possible. > > Forward iterators can't ever give you an alias because they're a > single pass over the container. It's an easy guarantee to provide. > Is it ? In this case it would mean that you can only have one Forward Iterator in scope (for a given container) at once too (ie, the forward iterator borrows the container); otherwise you could have two distinct iterators pointing to the same underlying element. I certainly appreciate the ongoing debate anyway, it's great to see things being exposed to light and openly discussed. I would like to contribute with one point: partitioning. Sometimes, you would like to partition a container, or point to one of its elements. For example, in C++, you have an overload of insert which takes an iterator allowing you to point to the routine where the element you ask to insert is likely to go and thus shaving off a couple comparisons (if you are right). This requires pointing to a single element, to be contrasted with a range. Another example would be partitioning, a partition of a slice can be represented with two points: the two end-points of the slice and the point of partition. Both of those examples can be represented by ranges (or in C++ iterator) though they do not themselves imply any iteration. My point, thus, is that there might be a need for "fingers inside a container" that go beyond basic iteration. -- Matthieu > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Jun 7 09:12:58 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 7 Jun 2013 12:12:58 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: On Fri, Jun 7, 2013 at 12:10 PM, Matthieu Monrocq >> >> The extent to which you can have mutable iterators in Rust is pretty >> small, because of the memory safety requirement. Iterators can't open >> up a hole allowing multiple mutable references to the same object to >> be obtained, so I don't think mutable bidirectional or random access >> iterators are possible. >> >> Forward iterators can't ever give you an alias because they're a >> single pass over the container. It's an easy guarantee to provide. > > > Is it ? > > In this case it would mean that you can only have one Forward Iterator in > scope (for a given container) at once too (ie, the forward iterator borrows > the container); otherwise you could have two distinct iterators pointing to > the same underlying element. Yeah, the compiler will only allow you to obtain one mutable iterator at a time. You can obtain any number of immutable ones. > I certainly appreciate the ongoing debate anyway, it's great to see things > being exposed to light and openly discussed. I would like to contribute with > one point: partitioning. > > Sometimes, you would like to partition a container, or point to one of its > elements. > > For example, in C++, you have an overload of insert which takes an iterator > allowing you to point to the routine where the element you ask to insert is > likely to go and thus shaving off a couple comparisons (if you are right). > This requires pointing to a single element, to be contrasted with a range. > > Another example would be partitioning, a partition of a slice can be > represented with two points: the two end-points of the slice and the point > of partition. > > Both of those examples can be represented by ranges (or in C++ iterator) > though they do not themselves imply any iteration. My point, thus, is that > there might be a need for "fingers inside a container" that go beyond basic > iteration. > > -- Matthieu To some extent we have a special case for this with string/vector slices but it's not yet extended to containers in general. The vector module could return two *disjoint* `&mut [T]` slices because the caller is unable to extend them. From jaoke.chinlee at 10gen.com Fri Jun 7 10:56:14 2013 From: jaoke.chinlee at 10gen.com (Jao-ke Chin-Le) Date: Fri, 7 Jun 2013 13:56:14 -0400 Subject: [rust-dev] Rust driver for mongoDB Message-ID: * Greetings all, Jed Estep and I are interns at 10gen (the mongoDB company), and we?re excited to announce that we?ll be working on the Rust driver for mongo! Please feel free to contact us with any questions/comments; likewise, we?ll be in your care for Rust questions. Thank you! Jao-ke Chin-Lee* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaoke.chinlee at 10gen.com Fri Jun 7 13:02:02 2013 From: jaoke.chinlee at 10gen.com (Jao-ke Chin-Lee) Date: Fri, 7 Jun 2013 16:02:02 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: * On Fri, Jun 7, 2013 at 2:09 PM, Corey Richardson wrote: * > On Fri, Jun 7, 2013 at 2:07 PM, Jao-ke Chin-Le > wrote: > > We were planning on mostly using the mailing list but will pop by the > IRC, > > yes. We?ll be developing for 0.6 -- is this what you mean by ?targeting > > incoming?? > > > > No. 0.6 is already hopelessly out of date. By incoming I mean the > incoming branch of the git repo, where all new development lands after > passing tests. > * Ah, thank you for the heads up. In that case, yes, we will target incoming. Do you have any suggestions for building on top of such a rapidly developing system? * > > > > Also, should the Rust wiki be updated to indicate that the driver for > mongo > > is ?in progress?? > > > > Yes > *We?ve updated the wiki to note that the mo**ngoDB DB API is ?external?; a link will be added as development gets underway.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jun 7 13:09:02 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 16:09:02 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 4:02 PM, Jao-ke Chin-Lee wrote: > Ah, thank you for the heads up. In that case, yes, we will target incoming. > Do you have any suggestions for building on top of such a rapidly developing > system? > I've been thinking about this problem for a while. I think the best solution it to pick a commit and only update every week or so. That way you have a stablish base to develop against, and only a weeks worth of potential breakage, rather than having to deal with potential breakage every day. This would be complemented well by a "This Week In Rust" newsletter-type thing detailing the major improvements/changes/decisions of the week, which I will be starting up. From graydon at mozilla.com Fri Jun 7 13:15:25 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 07 Jun 2013 13:15:25 -0700 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: Message-ID: <51B23F5D.7050103@mozilla.com> On 13-06-06 09:03 PM, Bill Myers wrote: > Reference counting is generally more desirable than garbage collection, > since it is simple and deterministic, and avoids scanning the whole heap > of the program, which causes pauses, destroys caches, prevents effective > swapping and requires to tolerate increasing memory usage by a > multiplicative factor to allow GC to be amortized to be linear in the > number of dead objects in the general case. These are all the exact same arguments I have put forth for RC in the past. They are why rust has RC presently, and will continue to have _some_ RC (probably in the form of the libraries alone). Don't get me wrong, I'm not an RC-hater. But I'm presently working on a tracing GC, and will probably keep doing so. Some other things about RC that are less-desirable, that we knew and/or discovered: - It leaks cycles. If you want it to not leak cycles, you need a cycle collector which has the same properties as above, or a scheme like you're proposing. I have proposed them in the past. Every single reviewer I showed a "no cycles" variant of rust to told me it was unacceptable and they would walk away from a language that prohibited cycles in all cases. All of them. We tried limiting it within subsets of the type system rather than pervasively: it still irritated and confused everyone. - It doesn't do anything about fragmentation. Our longer-term plan for the gc involves moving to mostly-copying[1], which compacts pages other than the conservatively-scanned set. And is incremental. - It actually costs a lot. - Code size goes up by a good 30% over tracing GC. Lots of writes and branches. Lots more icache misses. Many ways of reducing this are hard to implement, have to happen at the LLVM level, are patented, or all 3. - You can't tell your codegen that pointees are constant anymore, since you're going to be writing to them. - Allocations wind up larger. At least one word extra per. More if you need to track all the allocations anyways, which you will want to if you want to be able to free them all on unwind (rather than rc-- on unwind, which costs much more) and/or if you want a cycle collector. Current rc boxes cost 4 words extra. Gc metadata can be stored much more compactly, 1-2 bits per alloc. - If you want to support weak pointers, you just added another dynamic failure mode when the pointee is missing, and slowed all pointer traversals through that edge. > However, it cannot support cycles (without destroying its advantages > over GC), so it is a good idea to statically prevent them to avoid leaks. We tried this; various strategies for it. Ownership cycles even just within subtrees of well-organized ownership trees are not a rare occurrence. They are a result both of normal patterns within common data structures, and normal levels of coupling between subsystems in large applictions. Especially web browsers. I appreciate your input and thinking on the matter, but I feel pretty confident saying we're not going to revisit this part, not going to try again to modify the type system to prohibit cycles in @-graphs at the fine-grain level you're describing. If anything, we might retire the @-sigil[2] in favour of standard library provision of explicit Gc:: and Rc:: types, with the current / known limitations. -Graydon [1] http://citeseer.uark.edu:8080/citeseerx/viewdoc/summary?doi=10.1.1.37.4037 but with software / non-mprotect write barriers [2] As Patrick proposed in http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ recently. Personally I like the sigil for its terseness; it's not clear to me anyone else does, and there are certainlyl advantages to be had in separating construction and allocation. But I think that's orthogonal. I think keeping `~Foo()` and `@Foo()` as contractions of `Uniq` and `Gc` types, and especially keeping `@Foo::new()` as a contraction of `alloc Gc Foo::new()` is a good thing. We keep `a + b` around as a contraction of `a.add(&b)` as well. From illissius at gmail.com Fri Jun 7 13:15:57 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 7 Jun 2013 22:15:57 +0200 Subject: [rust-dev] Adding exception handling as syntax sugar with declared exceptions In-Reply-To: <51B0C031.9000903@mozilla.com> References: <51951E44.2090306@mozilla.com> <51B0C031.9000903@mozilla.com> Message-ID: On Thu, Jun 6, 2013 at 7:00 PM, Graydon Hoare wrote: > On 06/06/2013 8:59 AM, G?bor Lehel wrote: > > Am I way off base with this? An embarrassing misconception? To summarize >> my train of thought >> >> * Catchable exceptions can be implemented >> * But we don't want to, because it would force everyone to think about >> exception safety >> * That could however be avoided with appropriate restrictions >> * Rust's type system already gives us the tools to impose those >> restrictions, as evidenced by them being imposed on `try()` >> * Therefore it should be possible to have much of the benefit of >> catchable exceptions, without their drawbacks >> > > No. The train of thought is that they _already are_ implemented to this > level -- via task isolation[1] -- and people asking for "catchable > exceptions" are (so far) actually asking for us to lift those > restrictions[2], which we don't want to do. > > -Graydon > > [1] If it helps avoid wincing about the implied "cost of spawning a task" > (allocating a segment, switching to it, and switching back on return) it > might help to know that there are some serious discussions going on in the > background about cactus stacks and the requisite scheduler hooks required > to support cilk-like fork/join parallelism. > Oh, okay. I wasn't aware of this sorry. What I knew was that a couple of times, when I raised the possibility of relying on `try()` for error handling, the response was that it wasn't fast enough and possibly never would be (and in one instance the idea of catchable exceptions was floated in response, suggesting that those *would* be fast enough), which is why I thought maybe it would be better (despite costlier) to give in and have a dedicated language feature, instead of only a library solution that's too slow for actual use. But obviously satisfying all the relevant use cases using only existing features is the best possible scenario! > > [2] And/or asking to add "first class" language support for the idioms in > the form of new keywords, RTTI or additional control structures. In case > this is not obvious: we are trying to move as much as possible these days > _out_ of the core language and into libraries and macros. This usually > results in faster iteration, less fragility, fewer personnel and > development/integration bottlenecks, and overall better implementations. > > -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaoke.chinlee at 10gen.com Fri Jun 7 13:19:41 2013 From: jaoke.chinlee at 10gen.com (Jao-ke Chin-Lee) Date: Fri, 7 Jun 2013 16:19:41 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: On Fri, Jun 7, 2013 at 4:09 PM, Corey Richardson wrote: > On Fri, Jun 7, 2013 at 4:02 PM, Jao-ke Chin-Lee > wrote: > > Ah, thank you for the heads up. In that case, yes, we will target > incoming. > > Do you have any suggestions for building on top of such a rapidly > developing > > system? > > > > I've been thinking about this problem for a while. I think the best > solution it to pick a commit and only update every week or so. That > way you have a stablish base to develop against, and only a weeks > worth of potential breakage, rather than having to deal with potential > breakage every day. This would be complemented well by a "This Week In > Rust" newsletter-type thing detailing the major > improvements/changes/decisions of the week, which I will be starting > up. > Sounds good. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From i at cantor.mx Fri Jun 7 13:36:03 2013 From: i at cantor.mx (Max Cantor) Date: Fri, 7 Jun 2013 13:36:03 -0700 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: Please take a look at Haskell's Persistent library. Its higher level but has an awesome DSL for defining schemas and provides radical type safety. It would be awesome to have that in Rust too. Max On Fri, Jun 7, 2013 at 1:19 PM, Jao-ke Chin-Lee wrote: > > On Fri, Jun 7, 2013 at 4:09 PM, Corey Richardson wrote: > >> On Fri, Jun 7, 2013 at 4:02 PM, Jao-ke Chin-Lee >> wrote: >> > Ah, thank you for the heads up. In that case, yes, we will target >> incoming. >> > Do you have any suggestions for building on top of such a rapidly >> developing >> > system? >> > >> >> I've been thinking about this problem for a while. I think the best >> solution it to pick a commit and only update every week or so. That >> way you have a stablish base to develop against, and only a weeks >> worth of potential breakage, rather than having to deal with potential >> breakage every day. This would be complemented well by a "This Week In >> Rust" newsletter-type thing detailing the major >> improvements/changes/decisions of the week, which I will be starting >> up. >> > > Sounds good. Thanks! > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaoke.chinlee at 10gen.com Fri Jun 7 14:10:06 2013 From: jaoke.chinlee at 10gen.com (Jao-ke Chin-Lee) Date: Fri, 7 Jun 2013 17:10:06 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: *This isn?t quite within the scope of a mongo driver (both in time and concept), but yes, it does look pretty cool.* On Fri, Jun 7, 2013 at 4:36 PM, Max Cantor wrote: > Please take a look at Haskell's Persistent library. Its higher level but > has an awesome DSL for defining schemas and provides radical type safety. > It would be awesome to have that in Rust too. > > Max > > > On Fri, Jun 7, 2013 at 1:19 PM, Jao-ke Chin-Lee wrote: > >> >> On Fri, Jun 7, 2013 at 4:09 PM, Corey Richardson wrote: >> >>> On Fri, Jun 7, 2013 at 4:02 PM, Jao-ke Chin-Lee >>> wrote: >>> > Ah, thank you for the heads up. In that case, yes, we will target >>> incoming. >>> > Do you have any suggestions for building on top of such a rapidly >>> developing >>> > system? >>> > >>> >>> I've been thinking about this problem for a while. I think the best >>> solution it to pick a commit and only update every week or so. That >>> way you have a stablish base to develop against, and only a weeks >>> worth of potential breakage, rather than having to deal with potential >>> breakage every day. This would be complemented well by a "This Week In >>> Rust" newsletter-type thing detailing the major >>> improvements/changes/decisions of the week, which I will be starting >>> up. >>> >> >> Sounds good. Thanks! >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Fri Jun 7 14:25:16 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 21:25:16 +0000 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: <51B23F5D.7050103@mozilla.com> References: , <51B23F5D.7050103@mozilla.com> Message-ID: > Every > single reviewer I showed a "no cycles" variant of rust to told me > it was unacceptable and they would walk away from a language that > prohibited cycles in all cases. All of them. We tried limiting it > within subsets of the type system rather than pervasively: it still > irritated and confused everyone. Interesting, are these versions online anywhere? > - It doesn't do anything about fragmentation. Our longer-term plan for > the gc involves moving to mostly-copying[1], which compacts pages > other than the conservatively-scanned set. And is incremental. True, in fact fragmentation might be as bad or worse as the dead objects living on in GC. > > However, it cannot support cycles (without destroying its advantages > > over GC), so it is a good idea to statically prevent them to avoid leaks. > > We tried this; various strategies for it. Ownership cycles even just > within subtrees of well-organized ownership trees are not a rare > occurrence. They are a result both of normal patterns within common data > structures, and normal levels of coupling between subsystems in large > applictions. Especially web browsers. How about, however, something like (hypotetically) rewriting the Linux kernel in Rust? (with limited amounts of unsafe code) The issue there is that a kernel needs to provide syscalls to multiple CPU concurrently running threads which manipulate shared data structures like the filesystem. Having the filesystem structures be local to a single task would destroy performance on things like filesystem-bound loads on 32-core servers, while adding global GC would make it impossible to provide soft and hard real time guarantees needed for embedded systems. So using a MutexARC/RWARC global reference counting scheme with fine grained locks like the Linux kernel in fact does (along with RCU, but let's ignore that for now) seems the only option, but it's currently not safely possible in the current Rust, due to the inability to nest those structures safely with checking. Now it's not totally clear whether full checking of reference cycles is indeed viable, but it seems the only way to achieve that, and it seems bothersome that one could not write a fast and safe real-time POSIX-implementing kernel in a language that is pretty much the only mainstream language that can hope to do so. Even excluding kernels, it seems network servers running on multi-socket machines and needing to concurrently mutate complex object graphs would have similar issues. Although for those real-time might not be so essential, so adding optional concurrent global GC (like Java has) would be an alternative (but is also quite a bit of work). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucian.branescu at gmail.com Fri Jun 7 14:30:52 2013 From: lucian.branescu at gmail.com (Lucian Branescu) Date: Fri, 7 Jun 2013 22:30:52 +0100 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: <51B23F5D.7050103@mozilla.com> References: <51B23F5D.7050103@mozilla.com> Message-ID: On Friday, 7 June 2013, Graydon Hoare wrote: > > Some other things about RC that are less-desirable, that we knew and/or > discovered: > > - It leaks cycles. If you want it to not leak cycles, you need a > cycle collector which has the same properties as above, or a scheme > like you're proposing. I have proposed them in the past. Every > single reviewer I showed a "no cycles" variant of rust to told me > it was unacceptable and they would walk away from a language that > prohibited cycles in all cases. All of them. We tried limiting it > within subsets of the type system rather than pervasively: it still > irritated and confused everyone. > > - It doesn't do anything about fragmentation. Our longer-term plan for > the gc involves moving to mostly-copying[1], which compacts pages > other than the conservatively-scanned set. And is incremental. > > - It actually costs a lot. > > - Code size goes up by a good 30% over tracing GC. Lots of writes > and branches. Lots more icache misses. Many ways of reducing this > are hard to implement, have to happen at the LLVM level, are > patented, or all 3. > > - You can't tell your codegen that pointees are constant anymore, > since you're going to be writing to them. > > - Allocations wind up larger. At least one word extra per. More > if you need to track all the allocations anyways, which you will > want to if you want to be able to free them all on unwind > (rather than rc-- on unwind, which costs much more) and/or if > you want a cycle collector. Current rc boxes cost 4 words extra. > Gc metadata can be stored much more compactly, 1-2 bits per alloc. > > - If you want to support weak pointers, you just added another > dynamic failure mode when the pointee is missing, and slowed > all pointer traversals through that edge. Another important drawback of RC is that it defeats copy-on-write on fork that at least Linux does. The difference of memory usage between RC and GC can be quite significant in workloads like forking servers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Fri Jun 7 14:40:31 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 07 Jun 2013 14:40:31 -0700 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: <51B2534F.9090503@mozilla.com> On 06/07/2013 10:56 AM, Jao-ke Chin-Le wrote: > * > > Greetings all, > > > Jed Estep and I are interns at 10gen (the mongoDB company), and we're > excited to announce that we'll be working on the Rust driver for > mongo! Please feel free to contact us with any questions/comments; > likewise, we'll be in your care for Rust questions. > > * I'm very happy to hear this! I'll echo Corey's sentiment that hanging out in IRC is the best way to stay abreast of what is going on in Rust and by far the easiest way to get help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Fri Jun 7 15:01:53 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 8 Jun 2013 10:01:53 +1200 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: <51B23F5D.7050103@mozilla.com> References: <51B23F5D.7050103@mozilla.com> Message-ID: Thanks Graydon. Restructuring your code to avoid cycles is problematic when you're implementing a platform where the spec allows users to create ownership cycles --- like, say, the Web platform. So if Rust didn't support cyclic ownership, Servo would have to implement its own GC and tracing code just like Gecko does. That's a situation we need to get away from. An interesting meta-point is that when you're implementing a platform, rather than a specific application, you have much less freedom to structure the implementation because you don't know what any given instance of your system actually does. This affects everything from the requirements on the programming language to the design of graphics APIs. Rob -- q?qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Fri Jun 7 15:43:35 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 7 Jun 2013 22:43:35 +0000 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: , <51B23F5D.7050103@mozilla.com>, Message-ID: > Restructuring your code to avoid cycles is problematic when you're implementing a platform where the spec allows users to create ownership cycles --- like, say, the Web platform. So if > Rust didn't support cyclic ownership, Servo would have to implement its own GC and tracing code just like Gecko does. That's a situation we need to get away from. Yes, my idea was to essentially extend the compiler with facilities allowing to implement RcMut and RWARC in such a way that they can be nested without creating memory leaks (subject to some restrictions, but less restrictions than the blanket inability to nest), with the goal of replacing C++ (or Java, perhaps) in high-performance multithreaded servers and kernels. That would be orthogonal to the issue of what to do with @-pointers and whether to have garbage collection (which is indeed very desirable since some programs need it). > An interesting meta-point is that when you're implementing a platform, rather than a specific application, you have much less freedom to structure the implementation because you don't > know what any given instance of your system actually does. This affects everything from the requirements on the programming language to the design of graphics APIs. Yes, although note that while task-local GC is sufficient to implement a browser with JavaScript (since JavaScript is single threaded), it would not be enough to implement an high-performance Java VM, which requires GC on memory simultaneously accessible by multiple threads. In general, it would be nice to have great support for all 4 models: sophisticated local and global reference counting, and local and global GC (as well as owned and borrowed pointers). It's probably reasonable though for Mozilla to mostly focus on the browser use case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Fri Jun 7 16:09:01 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 7 Jun 2013 19:09:01 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: Sounds very cool. AFAIK this is the first database driver ever made for Rust, so the API you come up with will probably set a precedent for all future Rust DB drivers (no pressure). Will it be open-sourced, and if so, which license? On Fri, Jun 7, 2013 at 1:56 PM, Jao-ke Chin-Le wrote: > * > > Greetings all, > > Jed Estep and I are interns at 10gen (the mongoDB company), and we?re > excited to announce that we?ll be working on the Rust driver for mongo! > Please feel free to contact us with any questions/comments; likewise, we?ll > be in your care for Rust questions. > > Thank you! > > Jao-ke Chin-Lee* > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.c.morrow at gmail.com Fri Jun 7 17:51:27 2013 From: andrew.c.morrow at gmail.com (Andrew C. Morrow) Date: Fri, 7 Jun 2013 20:51:27 -0400 Subject: [rust-dev] Rust driver for mongoDB In-Reply-To: References: Message-ID: Hi - The plan is to open source the driver when we have something that we feel offers some basic but useful level of functionality. If all goes according to plan, that should be sometime later this summer. 10gen typically licenses driver code under the Apache License 2.0. We are really excited about this project, and we are looking forward to working with the Rust community. All of us are new to the language, so we will be learning as we go. Thanks, Andrew On Fri, Jun 7, 2013 at 7:09 PM, Benjamin Striegel wrote: > Sounds very cool. AFAIK this is the first database driver ever made for > Rust, so the API you come up with will probably set a precedent for all > future Rust DB drivers (no pressure). Will it be open-sourced, and if so, > which license? > > > On Fri, Jun 7, 2013 at 1:56 PM, Jao-ke Chin-Le wrote: > >> * >> >> Greetings all, >> >> Jed Estep and I are interns at 10gen (the mongoDB company), and we?re >> excited to announce that we?ll be working on the Rust driver for mongo! >> Please feel free to contact us with any questions/comments; likewise, we?ll >> be in your care for Rust questions. >> >> Thank you! >> >> Jao-ke Chin-Lee* >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jun 7 18:56:35 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 7 Jun 2013 21:56:35 -0400 Subject: [rust-dev] This Week In Rust Message-ID: Copy of content at http://cmr.github.io/blog/2013/06/07/this-week-in-rust/ -- Hello and welcome to the first issue of *This Week In Rust*, a weekly overview of Rust and its community. I'll be covering what's cooking in incoming, meeting summaries, meetups, and anything else pertinent. Any ideas, email them to me, . The Rust interns arrived this week and have got cracking right away. Big hello to Aaron Todd, Ben Blum, and Michael Sullivan! We can look forward to work all over the place, especially in the RT and debug-info. # What's cooking in incoming? There were 30 pull requests merged this week. A scattering of doc fixes and a bunch of code cleanups and optimization work as usual. Total issue churn (excludes pull requests) this week was +6. ## Notable additions, bugfixes, and cleanups - Ben Striegel added the `as_c_str` string function as a method as part of the overall methodization covered by [6045][is6045]. - James Miller landed a much better optimization pipeline in [6881][is6881], fixing a bunch of nascent optimization problems, especially with inlining, and also fixing an earlier (huge) regression (that he introduced, admittedly). - James also fixed [6977][is6977], which allowed nonsensical expressions like `[0, ..-1]`. Whoops! - I introduced terminfo handling to `extra::term` in [6826][is6826], bringing rustc's beautiful colors to a wider audience. Unfortunately, it isn't complete yet and, most notably, does not handle `xterm-256color` correctly yet. - Daniel Micay landed jemalloc as the default allocator in the runtime, leading to nice allocation performance boosts on all platforms, as well as much improved multithreaded performance. It also has the benefit of cross-platform tuning and instrumentation. ## Breaking changes It would be silly not to mention these changes, even though they weren't strictly this week: - `libcore` was renamed to `libstd` and `libstd` was renamed to `libextra`, to better reflect their purpose. Confusingly, the code in rustc still uses the old names. Something to watch out for! - All of the module reexports were removed from the prelude, so if you use, for example, `io::foo`, `vec::foo`, etc, you will find yourself having to add a lot of extra imports. `use std::*` to regain the old behavior, more or less. - Patrick fixed the unsafe checker to safe code can no longer call unsafe methods. This week: - `pub impl` was removed by Patrick Walton as part of [6944][is6944]. What this did was have all `fn`s in a `pub impl` be `pub` by default. Now, you must explicitly specify `pub` on all `fn`s in the impl if you want them public. - Also in [6944][is6944], Patrick removed the ability to have multiple patterns appear in "let" declarations. For example: `let a = 4, b = 2;` becomes `let (a, b) = (4, 2);` - Daniel renamed the `Ptr` trait to `RawPtr` in [6913][is6913] - Daniel and Huon Wilson have been working on iterators a lot. In [6999][is6999], they start removing the `vec::each_*` functions, as the new iterator code in `std::iterator` is now mature enough for use. # Meetings There were two main meetings this week. Mostly discussion about DST, closures, and the GC. Lots of issues and details remain to be worked out, I suspoect it will still be a bit before anything final-looking comes up in a PR. See the [meeting][mtg1] [notes][mtg2] for more details. # Meetups - Erick Tryzelaar has a meetup planned in Mountain View on Wednesday, June 12, at 7pm. See the [ML thread][sanfran] for more details. - Tim Chevalier will be giving a talk titled "Rust: A Friendly Introduction" on Monday, June 17, 6-9pm in Portland. See [Calagator][rafi] for more details. # Prominent blog posts and ML threads - - - - - # Other announcements - 10gen has some interns working on a MongoDB driver for Rust, which will be very nice to have. Good luck to them! - Brendan Zabarauskas has fixed `lmath`. It now works on incoming. Yay! [is6045]: https://github.com/mozilla/rust/issues/6045 [is6881]: https://github.com/mozilla/rust/pull/6881 [is6977]: https://github.com/mozilla/rust/issues/6977 [is6826]: https://github.com/mozilla/rust/pull/6826 [is6944]: https://github.com/mozilla/rust/pull/6944 [is6913]: https://github.com/mozilla/rust/pull/6913 [mtg1]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-04 [mtg2]: https://github.com/mozilla/rust/wiki/Meeting-2013-06-07 [rafi]: http://calagator.org/events/1250464376 [sanfran]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004356.html [is6999]: https://github.com/mozilla/rust/pull/6999 From danielmicay at gmail.com Fri Jun 7 22:44:44 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 8 Jun 2013 01:44:44 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: On Thu, Jun 6, 2013 at 8:01 PM, Vadim wrote: > > The iterator object itself can contain a fixed size buffer into which it > copies objects before returning slice to the caller. This would work for > almost any container type. > > Perhaps I'm confused about the amount of inlining that Rust can perform. Do > you expect that iterator.next() calls will be inlined across crate > boundaries? It can inline between crates as long as the functions/methods are marked with `#[inline]`. This causes the compiler to output the AST into the crate and add an inline hint. Statically dispatched function calls are fast though, just not when they're going to be in an inner loop like these ones. From rust-dev at tomlee.co Sat Jun 8 01:07:13 2013 From: rust-dev at tomlee.co (Tom Lee) Date: Sat, 8 Jun 2013 01:07:13 -0700 Subject: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm] In-Reply-To: References: Message-ID: I'm told we don't have A/V equipment on-site, but if somebody else attending wants to bring along the equipment (& assuming Tim's okay with the idea) I don't see why not. In any case, his talk at OSBridge a few days later may well be recorded? Cheers, Tom On Fri, Jun 7, 2013 at 4:53 AM, Corey Richardson wrote: > On Fri, Jun 7, 2013 at 2:20 AM, Tom Lee wrote: >> Mozilla's own Tim Chevalier is giving a preview of his OSBridge talk, >> "Rust: A Friendly Introduction" later this month. Should you be in >> town the evening of June 17th, please drop by! >> > > Will this be recorded? -- Tom Lee / http://tomlee.co / @tglee From catamorphism at gmail.com Sat Jun 8 11:46:57 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat, 8 Jun 2013 11:46:57 -0700 Subject: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm] In-Reply-To: References: Message-ID: On Sat, Jun 8, 2013 at 1:07 AM, Tom Lee wrote: > I'm told we don't have A/V equipment on-site, but if somebody else > attending wants to bring along the equipment (& assuming Tim's okay > with the idea) I don't see why not. > > In any case, his talk at OSBridge a few days later may well be recorded? > Looking at previous years, it looks like at least the audio is going to be recorded. And I'll put my slides online. I guess it's fine if someone wants to record the practice talk, but for people who can't attend either, I really recommend listening to the recording of the conference talk instead -- it will doubtless benefit from feedback received during the practice talk :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From bblum at mozilla.com Fri Jun 7 18:33:12 2013 From: bblum at mozilla.com (Ben Blum) Date: Fri, 7 Jun 2013 21:33:12 -0400 Subject: [rust-dev] Proposal for effects Message-ID: <20130608013312.GA32700@vipassana.mv.mozilla.com> Hi rust-dev, I've been thinking about how an "effect system" would work in Rust, in which we could statically reason about the effects that functions can or can't have. Such a system would let you say "compiler, please make sure that failure (or some other effect, such as GC) can't occur during this function". There are some obvious benefits (banning failure in destructors, which is currently unsound) and some obvious big issues (should 'assert' be considered to fail? how do we reason about garbage-collected destructors with arbitrary effects being invoked whenever GC can happen?). I have drafted a proposal, which outlines a flexible + lightweight syntax for annotating effects, and goes into detail about the issues: https://github.com/mozilla/rust/wiki/Proposal-for-effects Please weigh in if you have opinions about: - why it would be great to have in the language (what's your use case?) - why it would be terrible to have in the language (how do you see it getting in the way of users who don't want to worry about effects? do you see any of the issues I outlined as show-stoppers?) - theoretical issues about not being able to infer, and having to require user annotations, in certain situations - how you think my proposed syntax could be better If we collectively decide that an effect system would be welcome in Rust, I'd be happy to pursue it as my summer project for the next 10 weeks. Ben From niko at alum.mit.edu Sat Jun 8 14:45:43 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 8 Jun 2013 17:45:43 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: <20130608214543.GA5989@Mr-Bennet> On Thu, Jun 06, 2013 at 12:09:29AM -0400, Daniel Micay wrote: > A quick terminology refresher, for those who aren't familiar with it: > Another issue is mutability, as you can write iterators that are able to mutate > containers. With internal iterators, this is easy to do with safe code. With > external ones, it will `unsafe` and won't be easy to get right. Something about this assertion didn't sit right with me. It took me a little bit, but I realized it's actually faily easy to do a mutable external iterator. Here is an example for a binary tree, visiting in pre-order. https://gist.github.com/nikomatsakis/5736715 Perhaps there are other cases that are harder? I'd be curious to know how the efficiency of this compares with the internal iterator case; clearly, it requires allocation where an internal iterator does not. Niko From danielmicay at gmail.com Sat Jun 8 14:56:34 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 8 Jun 2013 17:56:34 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130608214543.GA5989@Mr-Bennet> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <20130608214543.GA5989@Mr-Bennet> Message-ID: On Sat, Jun 8, 2013 at 5:45 PM, Niko Matsakis wrote: > On Thu, Jun 06, 2013 at 12:09:29AM -0400, Daniel Micay wrote: >> A quick terminology refresher, for those who aren't familiar with it: >> Another issue is mutability, as you can write iterators that are able to mutate >> containers. With internal iterators, this is easy to do with safe code. With >> external ones, it will `unsafe` and won't be easy to get right. > > Something about this assertion didn't sit right with me. It took me a > little bit, but I realized it's actually faily easy to do a mutable > external iterator. Here is an example for a binary tree, visiting in pre-order. > > https://gist.github.com/nikomatsakis/5736715 Huh, I'm surprised by how simple it is. When I tried to do it before, it was with the old borrow checker so I guess I could have just been fighting with the old bugs/limitations. > Perhaps there are other cases that are harder? I'd be curious to know > how the efficiency of this compares with the internal iterator case; > clearly, it requires allocation where an internal iterator does not. Efficiency-wise, I don't think it should be a big deal because for up to 2^32 elements it will only need a stack depth of ~32. It could be reserving the memory in advance based on the size of the tree. The recursive version will have stack overflow checks for each level of recursion so that's not much different than the vector capacity checks. From banderson at mozilla.com Sat Jun 8 15:06:40 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 08 Jun 2013 15:06:40 -0700 Subject: [rust-dev] Rust milestone metrics spreadsheet Message-ID: <51B3AAF0.5070302@mozilla.com> I've been tracking the numbers of [open] and [closed] issues on the Rust maturity [milestones] for four weeks. These milestones are currently our best gauge of progress toward language stability. I'm not sure if it will lead to anything useful, but I've made the spreadsheet public. [open]: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AlWBWplsaTZvdEExUmtpXzdQa01hbjJPRjY2LVZrLVE#gid=1 [closed]: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AlWBWplsaTZvdEExUmtpXzdQa01hbjJPRjY2LVZrLVE#gid=2 [milestones]: https://github.com/mozilla/rust/issues/milestones From danielmicay at gmail.com Sat Jun 8 15:11:23 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 8 Jun 2013 18:11:23 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <20130608214543.GA5989@Mr-Bennet> Message-ID: On Sat, Jun 8, 2013 at 5:56 PM, Daniel Micay wrote: > > Efficiency-wise, I don't think it should be a big deal because for up > to 2^32 elements it will only need a stack depth of ~32. It could be > reserving the memory in advance based on the size of the tree. The > recursive version will have stack overflow checks for each level of > recursion so that's not much different than the vector capacity > checks. (in a self-balancing binary search tree, not an unbalanced one) From niko at alum.mit.edu Sat Jun 8 18:40:10 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 8 Jun 2013 21:40:10 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <20130608214543.GA5989@Mr-Bennet> Message-ID: <20130609014010.GB5989@Mr-Bennet> On Sat, Jun 08, 2013 at 05:56:34PM -0400, Daniel Micay wrote: > Huh, I'm surprised by how simple it is. When I tried to do it before, > it was with the old borrow checker so I guess I could have just been > fighting with the old bugs/limitations. The end result looks quite nice, but I confess it took me two or three iterations to find an approach that would work. The key is to only hold on to the state you will need in the future---this is why the `next` method pops off the current node and then pushes its children. Because the current node is no longer on the stack, we can then return an `&mut` pointer to its value. For fun, I extended the approach to a post-order iterator as well: https://gist.github.com/nikomatsakis/5737243 This is somewhat trickier, but I think mostly because post-order is generally trickier than pre-order for an external iterator, since you visit the value on the way *up* and not on the way *down*. Anyway, I think the idea of "only keep those parts you have yet to visit" is clearer in the post order case: the post order state starts with options for left and right that are Some (presuming the node has children) and those options are None'd out as we proceed. > Efficiency-wise, I don't think it should be a big deal because for up > to 2^32 elements it will only need a stack depth of ~32. It could be > reserving the memory in advance based on the size of the tree. The > recursive version will have stack overflow checks for each level of > recursion so that's not much different than the vector capacity > checks. This makes sense. Also, there are advantages to using the heap over the stack. For example, the pre-order iterator only keeps 1 word per depth of the tree, whereas a stack frame is significantly larger. Niko From remifontan at yahoo.fr Sun Jun 9 03:39:28 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sun, 9 Jun 2013 22:39:28 +1200 Subject: [rust-dev] equivalent to typedef? Message-ID: Hi, I'm learning Rust and find it very interesting. My background is mostly python and C++. I'm now trying to get my head round the Rust generic system and was wondering whether there' s something equivalent to typedef in Rust? my use case is: - I have a generic 2d vector struct : struct Vec2x {x:T, y:T} - I would like to declare somethere in my code how to specialise this struct. I'm not sure yet whether it's going to be float or f64. So to avoid having to update float to f64 everywhere in the code, I was hoping I could write that: type Vec2f = Vec2x and then use Vec2f without worrying whether it's float or f64. it seems to compile compiles, but the following did not work: let v = Vec2df:new(1.0, 2.0); I must have misunderstood how to use "type". here's the full code: pub mod math { #[deriving(Eq, Clone)] struct Vec2x { x:T, y:T } impl Vec2x { pub fn new(a:T, b:T) -> Vec2x { Vec2x{x:a, y:b} } } } #[test] fn test_Vec2x() { // let v = math::Vec2x::new(1f, 2f); type Vec2f = math::Vec2x; let v2 = Vec2f::new(1f, 2f); // does not compile } cheers, R?mi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From smadhueagle at outlook.com Sun Jun 9 04:32:49 2013 From: smadhueagle at outlook.com (Madhu Srinivasan) Date: Sun, 9 Jun 2013 11:32:49 +0000 Subject: [rust-dev] Suggestions for small Rust programs for use in a tutorial? In-Reply-To: References: , , Message-ID: Guys, I'm not sure if this is what you are looking for, but I have been writing small (self-contained) examples in Rust - mostly to help me understand the language concepts. Still in very early stages, but I will be contributing more over the next few weeks. https://github.com/smadhueagle/rustlings Madhu > Date: Thu, 6 Jun 2013 22:11:45 -0700 > From: catamorphism at gmail.com > To: danielmicay at gmail.com > CC: rust-dev at mozilla.org > Subject: Re: [rust-dev] Suggestions for small Rust programs for use in a tutorial? > > Jeaye, > > >>Tim, > > Not entirely sure if these are what you want, but bjz's glfw-rs repo > has some basic examples of using glfw-rs that may serve as a basic > example of Rust, too. > > See these: > https://github.com/bjz/glfw-rs/blob/master/examples/cursor.rs > https://github.com/bjz/glfw-rs/blob/master/examples/window.rs > https://github.com/bjz/glfw-rs/blob/master/examples/gl-struct.rs > > Along with the rest here: > https://github.com/bjz/glfw-rs/tree/master/examples<<< > > Thanks for the suggestion! So far I'm not sure if these illustrate the > main concepts I'm trying to get across, but they look great as > potential additional extended examples. > > On Thu, Jun 6, 2013 at 9:52 PM, Daniel Micay wrote: > > The Map trait is a bit ugly because it's sorely in need of default > > methods to reduce the burden on implementations. > > > > I think the Iterator trait in the `std::iterator` module is a great > > example, because it's a simple trait and it's easy to demonstrate > > implementations and adaptors for it. It's also a nice way of showing > > off the lifetime system because with owned containers you can't > > invalidate the iterators. I don't think there are many other languages > > able to represent something like statically freezable mutable > > containers. > > This is a great suggestion as well. I don't know why iterators didn't > occur to me as a potential example; they almost stand alongside traits > and borrowed pointers as major attractions on a tour of Rust. > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Not a riot, it's a rebellion." -- Boots Riley > "Attention Bros and Trolls: When I call out your spew, I'm not angry, > I'm defiant." -- Reg Braithwaite > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Jun 9 08:07:10 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 09 Jun 2013 08:07:10 -0700 Subject: [rust-dev] equivalent to typedef? In-Reply-To: References: Message-ID: <51B49A1E.60709@mozilla.com> On 6/9/13 3:39 AM, R?mi Fontan wrote: > it seems to compile compiles, but the following did not work: > let v = Vec2df:new(1.0, 2.0); This feature is planned but not yet implemented. Patrick From talex5 at gmail.com Sun Jun 9 08:07:24 2013 From: talex5 at gmail.com (Thomas Leonard) Date: Sun, 9 Jun 2013 16:07:24 +0100 Subject: [rust-dev] Library hashes and binary compatibility Message-ID: Hi, I'm writing a comparison of various languages[1], including Rust. I'm not sure what to say about binary compatibility. Rust libraries include some kind of hash in their name. It seems that a binary compiled against a library can only be upgraded to a new version if the hash still matches, but I'm not sure what conditions cause it to change. I tried adding an "author" field to my library's metadata, and that changed the hash. I guess I can avoid that problem easily enough by just not adding/changing author tags. But are there other changes I might have to make to my library that would break it? Or, is it possible to remove the hashes? Thanks, [1] http://roscidus.com/blog/blog/2013/06/06/choosing-a-python-replacement-for-0install -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA From corey at octayn.net Sun Jun 9 08:30:10 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 9 Jun 2013 11:30:10 -0400 Subject: [rust-dev] Library hashes and binary compatibility In-Reply-To: References: Message-ID: On Sun, Jun 9, 2013 at 11:07 AM, Thomas Leonard wrote: > Hi, > > I'm writing a comparison of various languages[1], including Rust. I'm > not sure what to say about binary compatibility. > Rust currently has no coherent binary compatability, the ABI isn't anywhere near being defined yet. But the hash is a hash of all the metadata associated with a library (version, license, etc), afaik. I don't know the exact details. Rust isn't ready for production use, so keep that in mind in your evaluation. It's unstable, unoptimized, etc. From jeaye at arrownext.com Sun Jun 9 11:39:55 2013 From: jeaye at arrownext.com (Jeaye) Date: Sun, 09 Jun 2013 11:39:55 -0700 Subject: [rust-dev] equivalent to typedef? In-Reply-To: References: Message-ID: <51B4CBFB.9080004@arrownext.com> On 06/09/2013 03:39 AM, R?mi Fontan wrote: > Hi, > > I'm learning Rust and find it very interesting. My background is > mostly python and C++. I'm now trying to get my head round the Rust > generic system and was wondering whether there' s something equivalent > to typedef in Rust? > > my use case is: > - I have a generic 2d vector struct : struct Vec2x {x:T, y:T} > - I would like to declare somethere in my code how to specialise this > struct. I'm not sure yet whether it's going to be float or f64. So to > avoid having to update float to f64 everywhere in the code, I was > hoping I could write that: > type Vec2f = Vec2x > and then use Vec2f without worrying whether it's float or f64. > > it seems to compile compiles, but the following did not work: > let v = Vec2df:new(1.0, 2.0); > R?mi, I ran into the same problem a while back and I fixed it using macros. If you're interested in my approach (which is not the most Rustic, but it's sufficient until we get type aliases that expose static functions), feel free to checkout https://github.com/Jeaye/q3/blob/master/src/math/vec3.rs The basic premise is to put all of the vec3 code into a macro, and then, similar to C++ templates, just plug in a type (at the bottom of the file when I specify the types of vec3s I want). The drawback to this is knowing the types ahead of time that you'd like, but this isn't too much of a problem for me. Maybe you can branch from this and find a solution that best fits you. Cheers, Jeaye From dbau.pp at gmail.com Mon Jun 10 09:51:18 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Tue, 11 Jun 2013 02:51:18 +1000 Subject: [rust-dev] Vec and str iterators and (breaking) changes Message-ID: <51B60406.9000409@gmail.com> Hi, Daniel Micay and I have started doing some broad changes to the std::vec and std::str modules, which will break things. Background: the str and vec modules are/were 9000 lines of repetitive and crufty code, with a lot of internal iterators and other "helper" functions called once or twice in the whole rustc code base... all these functions make the docs huge and horrible to navigate and generally cause bloat. # Iterators With external iterators pretty much ready for prime-time[iterators], str and vec have had a makeover: almost all iteration can and should be done via the shiny new external iterators (most simply .iter() and .rev_iter() for vecs and strings, along with others, like mutable iterators and bytewise iterators), e.g. use std::iterator::IteratorUtil; ... for [1,2,3,4].iter().enumerate().advance |(i, &elem)| { println(fmt!("%u-th element is %u", i, elem)); } This looks a ugly (the `use` is required because IteratorUtil methods names conflict with other methods[use], and there is a proposal for dramatic improvement by making `for` more flexible[for]), but these iterators can dramatically reduce the number of allocations required: e.g. with external iterators there's rarely a need to .push onto a new vector to collect values for later use, since one can express transformations as a chain of method calls (and if one does need the values in a vec, a call to .collect() is all that's needed, possibly with a type annotation). On this point, most iterating functions (i.e. each_...) have been either removed or merged, since there are general iterator adaptors in std::iterator for them (and more!), accessible via the IteratorUtil trait. E.g. vec::foldl(start, vec, f) => vec.iter().fold(start, f) vec::foldr(start, vec, f) => vec.rev_iter().fold(start, |x, y| f(y, x)) str::all(string, |c| char::is_lowercase(c)) => string.iter().all(|c| char::is_lowercase(c)) str::each_split_char(string, 'c', f) => string.split_iter('c').advance(f) str::each_split(string, |c| c == 'b', f) => string.split_iter(|c: char| c == 'b').advance(f) (These last two are pending[pending pull], and, yes, that is the same method. Currently only overloaded for char and &fn(char) -> bool, but one could imagine overloading &[char] etc.) These examples don't look that inspiring, but these changes have sent me on a lightning tour of the whole code base, and it seems that there are many instances where using iterators more extensively will be easily possibly (if anyone's interested in experimenting, grepping for .iter() or .rev_iter(), or even .map() in librustc would be a starting point). # Method-isation We've been converting a large number of freestanding functions in str to methods (and a few in vec too), and *deleting* the original functions. I know Rust is not quite aiming for backward-compatibility yet, but this might be a bit too much... it gives non-obvious name resolution errors. Since we don't have #[deprecated] yet[deprecated], I'm (slightly) willing to add them back in with #[doc(hidden)], but forcing the issue by an outright removal would be extremely nice to clean up these two huge modules. In any case, most of them have been just copied into the appropriate trait, and all of these traits are in the prelude, so an error about {str,vec}::foo(bar, ...) can normally be fixed via bar.foo(...). Anyway, I'm taking the approach that adding these modules are old and need to be cleaned out, and adding things back into the modules is easy, but deleting things is hard (since, unsurprisingly, the functions get used through the compiler) and boring, but should be done as soon as possible. So far, pending that pull request, we've reduced the length of str by ~25% and vec about ~5% (I've been mainly focusing on str, Daniel has done bits and pieces on vec), with more possible. Huon Wilson [iterators]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html [use]: https://github.com/mozilla/rust/issues/5898 [for]: https://github.com/mozilla/rust/issues/6997 [deprecated]: https://github.com/mozilla/rust/issues/723 [pending pull]: https://github.com/mozilla/rust/pull/7032 r? :) From hanny.strnad at gmail.com Mon Jun 10 08:43:57 2013 From: hanny.strnad at gmail.com (Jan Strnad) Date: Mon, 10 Jun 2013 17:43:57 +0200 Subject: [rust-dev] Macros and gensym Message-ID: Hi, I'm a rust newbie and I stared to play with macros a few days ago. Right now I'm trying to develop a macro that behaves similarly to Scala's for comprehension. Draft is available at https://gist.github.com/hanny24/5749688. However, for future improvements I'm going to need a safe way to introduce a new identifier. Is there anything like LISP's gensym in rust's macros system? Is is even possible to achieve using 'macro by example'? Regards, Honza From erick.tryzelaar at gmail.com Mon Jun 10 12:45:47 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 10 Jun 2013 12:45:47 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: Is there anyone else coming to the meetup this Wednesday that hasn't told me they are coming? I've got 15 people confirmed right now, which fits nicely into my reservation for 20, but if there's a lot more that is planning on coming I'll need to up my reservation. On Wed, Jun 5, 2013 at 5:37 PM, Erick Tryzelaar wrote: > Hey folks! > > I've made a reservation for 20 people at Tied House in Mountain View next > Wednesday, June 12th, at 7pm: > > Tied House > 954 Villa St, Mountain View, CA 94041 > http://tiedhouse.com/ > map: http://goo.gl/maps/p9dK0. > > It's right near Caltrain, so it should hopefully be pretty easy for people > to commute to the restaurant. Please let me know if you are coming so I can > grow/shrink the reservation. > > Finally, please bring some cash because we'll all be sharing one check, > and it'll be easier to split the bill. > > Looking forward to meeting you all! > -Erick > > > > On Mon, Jun 3, 2013 at 1:23 PM, Erick Tryzelaar > wrote: > >> Hey all! I think we have critical mass for a presentation or two. Would >> anyone be interested in giving a presentation? If so, how much time would >> you need to put one together? >> >> >> On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu wrote: >> >>> Count me in. :) >>> >>> >>> Kevin >>> >>> >>> -- >>> Kevin Cantu >>> >>> >>> On Fri, May 24, 2013 at 3:48 PM, Brian Anderson wrote: >>> >>>> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote: >>>> >>>>> Glad to help. >>>>> >>>>> So far I've heard from 10 others so far, which I think is pretty good >>>>> for our first one in the bay area. When do the interns start? This could be >>>>> a good way to introduce them into the community / convince them work on my >>>>> feature requests :) >>>>> >>>>> >>>> All the rust interns will be here by 6/10. >>>> >>>> ______________________________**_________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/**listinfo/rust-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Jun 10 13:30:35 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 10 Jun 2013 13:30:35 -0700 Subject: [rust-dev] Vec and str iterators and (breaking) changes In-Reply-To: <51B60406.9000409@gmail.com> References: <51B60406.9000409@gmail.com> Message-ID: <51B6376B.3050502@mozilla.com> On 6/10/13 9:51 AM, Huon Wilson wrote: > We've been converting a large number of freestanding functions in str > to methods (and a few in vec too), and *deleting* the original > functions. I know Rust is not quite aiming for backward-compatibility > yet, but this might be a bit too much... it gives non-obvious name > resolution errors. Since we don't have #[deprecated] yet[deprecated], > I'm (slightly) willing to add them back in with #[doc(hidden)], but > forcing the issue by an outright removal would be extremely nice to > clean up these two huge modules. I vote for removing all freestanding functions and turning everything possible into a method. I've been meaning to do this and haven't gotten around to it yet; any help would be much appreciated! Patrick From graydon at mozilla.com Mon Jun 10 13:44:04 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 10 Jun 2013 13:44:04 -0700 Subject: [rust-dev] Vec and str iterators and (breaking) changes In-Reply-To: <51B6376B.3050502@mozilla.com> References: <51B60406.9000409@gmail.com> <51B6376B.3050502@mozilla.com> Message-ID: <51B63A94.60108@mozilla.com> On 10/06/2013 1:30 PM, Patrick Walton wrote: > I vote for removing all freestanding functions and turning everything > possible into a method. I've been meaning to do this and haven't gotten > around to it yet; any help would be much appreciated! While I agree in principle, I feel this move increases the priority of getting uniform method/function calls working. -Graydon From graydon at mozilla.com Mon Jun 10 14:15:24 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 10 Jun 2013 14:15:24 -0700 Subject: [rust-dev] Rust milestone metrics spreadsheet In-Reply-To: <51B3AAF0.5070302@mozilla.com> References: <51B3AAF0.5070302@mozilla.com> Message-ID: <51B641EC.206@mozilla.com> On 08/06/2013 3:06 PM, Brian Anderson wrote: > I've been tracking the numbers of [open] and [closed] issues on the Rust > maturity [milestones] for four weeks. These milestones are currently our > best gauge of progress toward language stability. I'm not sure if it > will lead to anything useful, but I've made the spreadsheet public. Thanks! This is helpful and encouraging. -Graydon From paul.stansifer at gmail.com Mon Jun 10 14:41:28 2013 From: paul.stansifer at gmail.com (Paul Stansifer) Date: Mon, 10 Jun 2013 17:41:28 -0400 Subject: [rust-dev] Macros and gensym In-Reply-To: References: Message-ID: `gensym` is not available in Scheme's macro-by-example facility, because it is specified to be hygienic, meaning that it automatically avoids name collisions (see http://en.wikipedia.org/wiki/Hygienic_macro ). Rust's macro system is not yet hygienic, but I believe that this is under active development. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.stansifer at gmail.com Mon Jun 10 14:43:52 2013 From: paul.stansifer at gmail.com (Paul Stansifer) Date: Mon, 10 Jun 2013 17:43:52 -0400 Subject: [rust-dev] Macros and gensym In-Reply-To: References: Message-ID: Oh, I forgot to answer the actual question! Rust doesn't have a `gensym`, either. (syntax extensions have access to a `gensym`-like facility, but syntax extensions currently must be part of the compiler) Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Jun 10 22:57:50 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 10 Jun 2013 22:57:50 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: There is a small chance that I may come, but I cannot say for sure until the last moment. From g at spork.in Mon Jun 10 23:47:43 2013 From: g at spork.in (Tim Carey-Smith) Date: Mon, 10 Jun 2013 23:47:43 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: I am in SF and would be interested in meeting up. Is there anyone coming down from SF? Thanks, Tim On Jun 10, 2013, at 12:45 PM, Erick Tryzelaar wrote: > Is there anyone else coming to the meetup this Wednesday that hasn't told > me they are coming? I've got 15 people confirmed right now, which fits > nicely into my reservation for 20, but if there's a lot more that is > planning on coming I'll need to up my reservation. > > > On Wed, Jun 5, 2013 at 5:37 PM, Erick Tryzelaar > wrote: > >> Hey folks! >> >> I've made a reservation for 20 people at Tied House in Mountain View next >> Wednesday, June 12th, at 7pm: >> >> Tied House >> 954 Villa St, Mountain View, CA 94041 >> http://tiedhouse.com/ >> map: http://goo.gl/maps/p9dK0. >> >> It's right near Caltrain, so it should hopefully be pretty easy for people >> to commute to the restaurant. Please let me know if you are coming so I can >> grow/shrink the reservation. >> >> Finally, please bring some cash because we'll all be sharing one check, >> and it'll be easier to split the bill. >> >> Looking forward to meeting you all! >> -Erick >> >> >> >> On Mon, Jun 3, 2013 at 1:23 PM, Erick Tryzelaar >> wrote: >> >>> Hey all! I think we have critical mass for a presentation or two. Would >>> anyone be interested in giving a presentation? If so, how much time would >>> you need to put one together? >>> >>> >>> On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu wrote: >>> >>>> Count me in. :) >>>> >>>> >>>> Kevin >>>> >>>> >>>> -- >>>> Kevin Cantu >>>> >>>> >>>> On Fri, May 24, 2013 at 3:48 PM, Brian Anderson wrote: >>>> >>>>> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote: >>>>> >>>>>> Glad to help. >>>>>> >>>>>> So far I've heard from 10 others so far, which I think is pretty good >>>>>> for our first one in the bay area. When do the interns start? This could be >>>>>> a good way to introduce them into the community / convince them work on my >>>>>> feature requests :) >>>>>> >>>>>> >>>>> All the rust interns will be here by 6/10. >>>>> >>>>> ______________________________**_________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/**listinfo/rust-dev >>>>> >>>> >>>> >>> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From remifontan at yahoo.fr Tue Jun 11 03:07:43 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Tue, 11 Jun 2013 22:07:43 +1200 Subject: [rust-dev] numerical traits Message-ID: Hi, I was having a look to the num module and the numerical traits. Is there some sort of Number trait in rust? I found this page about numerical traits and is described a Real trait that looks like what I need. has it been implemented in rust 0.6? https://github.com/mozilla/rust/wiki/Bikeshed-Numeric-Traits cheers, R?mi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From noamraph at gmail.com Tue Jun 11 03:28:56 2013 From: noamraph at gmail.com (Noam Yorav-Raphael) Date: Tue, 11 Jun 2013 13:28:56 +0300 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: Hello, Would you mind going into detail about when you need iterators that mutate containers? I always think of iterators as having no side effects. I ask that because if somehow you can live with only external iterators, having one type of iterators instead of two seems to me like a great simplification of the language. Thanks, Noam On 6 June 2013 07:09, Daniel Micay wrote: > A quick terminology refresher, for those who aren't familiar with it: > > * Internal iterator: takes a closure, runs the closure until it asks to > break > * External iterator: state machine, advanced by the caller in a loop > > To a caller, external iterators provide the most functionality, because > they > can be used as an internal iterator. You lose the state of an internal > iterator > by breaking out of iterator, so generic algorithms like zip, union, > intersect > and merge can't be implemented for a pair of iterators. > > # Issues with internal iterators in Rust > > A few months ago, we only had internal iterators and there were no generic > algorithms to use with any iterator - only with BaseIter's `each` method. > > Rust's internal iterators implement the protocol encoded in Rust's for > statement, but it's not possible to give them all a common trait or > implement > generic methods or functions taking any internal iterator. > > As a workaround, we can write algorithms assuming internal iterators only > take > one argument (the closure): > > fn count(f: &fn(fn(T) -> bool) -> bool) -> uint > > The caller has to use a partial function to call these adaptors, for which > we > lack sugar: > > count(|f| uint::range(0, 10, f)) > > For simple functions, this is fairly reasonable once you're used to it. It > quickly gets out of control though, even for a simple function like filter: > > filter(pred: &fn(&T) -> bool, input: &fn(&fn(T) -> bool) -> bool, > output: &fn(T) -> bool) -> bool {} > > Sadly, `filter_ref` is also needed to work around closures behaving badly > with > lifetimes. An example of the problem with `fold_ref`: > > fn product>(iter: &fn(f: &fn(&T) -> bool) -> bool) > -> T { > fold_ref(One::one::(), iter, |a, x| *a = a.mul(x)) > } > > Since `product` expects an iterator yielding `&T` (a borrowed pointer in > any > region), it won't work with `fold` because that requires the borrowed > pointer > to have the same type (and thus lifetime) for every iteration like `&'a > int`. > > This issue with borrowed pointers was blocking me from replacing the > existing > algorithms reimplemented for both `str` and `vec` with the generic ones. > > Chaining together iteration algorithms is a common use case, but even > chaining > two together is confusing at first: > > to_vec(|g| filter(|&x| *x < 3, |f| xs.each(f), g) > > Another more alarming issue is that with internal iterators, the `break` > and > `return` statements don't always work in a `for` loop. If the iterator > isn't > implemented correctly, the loop will keep going. > > This also has borrow checking implications, because the compiler can't > assume > those statements actually cause flow control to leave the loop immediately. > > # External iterators > > Based on the above, you might think generic iteration algorithms in Rust > are a > bleak prospect. However, we already have a nice external iterator library, > and > they don't suffer from the above issues. > > All kinds of external iterators implement the following trait, whether > they are > a fibonacci number generator, a reverse iterator over a vector or iterator > over > a range in a sorted set: > > pub trait Iterator { > /// Advance the iterator and return the next value. Return `None` > when the end is reached. > fn next(&mut self) -> Option; > } > > Generic adaptors are implemented on `Iterator`, and many of them are > `Iterator` > implementations themselves: > > use std::iterator::*; > > fn main() { > let mut it = Counter::new(0.0, 1.0) > .take_while(|x| *x < 10000000.0) > .transform(|x| x / 2.0) > .transform(|x| x + 2.0); > println(it.fold(0.0, |a, b| a + b).to_str()) > } > > If you're curious, the optimized LLVM IR: http://ix.io/5Xl > > Unlike internal iterators, external iterators only run one iteration at a > time, > so a `for` loop designed for them would always be able to succeed with > `break` > and `return`. It would also be able to avoid the ugly `advance` wrapper > currently required to use external iterators with `for`. > > // The current situation, wrapping an external iterator as an internal > one > // > // Since the advance method is not known the be correct, borrow > checking > // still assumes `return` and `break` are imperfect. > for xs.zip(ys).advance |x| { ... } > > // A hypothetical `for` loop using the `Iterator` trait > for iterator |x| { ... } > > // It could also fall back to an `Iterable` trait and obtain an > iterator > for container |x| { ... } > > External iterators also avoid the problems with references and closures, > because they simply return `T` rather than passing it to a closure. > > # Why not just switch to external iterators? > > Algorithms that can be represented easily without the call stack are as > easy to > write as either an internal or external iterator. > > However, without support for compiling a function to a state machine (C# > does > this for yield), traversal of a recursive data structure has to be manually > translated to a procedural algorithm with an explicit stack. For complex > data > structures, this process can be very difficult. > > I'm hopeful Rust will gain support for this down the road after 1.0. If it > does, there will be no reason to write immutable internal iterators. > > Another issue is mutability, as you can write iterators that are able to > mutate > containers. With internal iterators, this is easy to do with safe code. > With > external ones, it will `unsafe` and won't be easy to get right. > > # Solution? > > I don't have any proposal to completely solve this issue. :) > > I think extending the built-in `for` loop to work with external iterators > should be considered, because right now the verbosity discourages using > them > and makes borrow checking more painful than it has to be. > > It could treat functions as internal iterators, and look for an `Iterator` > implementation (using a `lang` item) for external ones. > > Python's `for` loop starts by looking for an iterator (a `__next__` > method) and > falls back to an iterable (an `__iter__` method) so behaviour like this > isn't > an alien concept. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Jun 11 11:44:54 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 11 Jun 2013 14:44:54 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: On Tue, Jun 11, 2013 at 6:28 AM, Noam Yorav-Raphael wrote: > Hello, > > Would you mind going into detail about when you need iterators that mutate > containers? I always think of iterators as having no side effects. > > I ask that because if somehow you can live with only external iterators, > having one type of iterators instead of two seems to me like a great > simplification of the language. > > Thanks, > Noam They provide a way to mutate the contents of any container. For a map, they are likely to only to exist for mutating the values, not the keys. In C++ and D, mutable iterators/ranges are very commonly used and we do have `&mut [T]` available already. Eventually iterators will be able to make the slice concept generic across containers. From jeaye at arrownext.com Tue Jun 11 21:32:43 2013 From: jeaye at arrownext.com (Jeaye) Date: Tue, 11 Jun 2013 21:32:43 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: <51B7F9EB.4010306@arrownext.com> On 06/10/2013 11:47 PM, Tim Carey-Smith wrote: > I am in SF and would be interested in meeting up. > Is there anyone coming down from SF? > > Thanks, > Tim > > Tim, I'll be going down from Bush & Sansome to 4th & King around 6pm. We could meet wherever. J From niko at alum.mit.edu Wed Jun 12 07:58:06 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 12 Jun 2013 10:58:06 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <51B0D418.6030909@mozilla.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> Message-ID: <20130612145806.GN5989@Mr-Bennet> After some discussion with strcat on IRC, I believe we should try to switch to external iterators. It is true that they can be somewhat harder to write, but the advantages are numerous: - Easy integration with static analyses, without need for new keywords and so forth: - Borrow checker need not be conservative against incorrectly implemented iterators, so `return &mut foo` will work. - Fold can be implemented safely without moving from an upvar: `let a = a0; for v.each |i| { a = op(a, i); }; a` (today this yields an error as `op(a, i)` moves from the upvar `a` unless you supply a Copy bound). - Various bits of code and logic are simplified by not having to transform the `for` loop closure. - Potentially faster compile times, less reliance on inlining and fewer #[inline(always)] declarations. With an inline iterator, if we don't inline, performance drops off a cliff (virtual call for every element). This is not true for an external iterator. - We can have `return` just make "early return from the innermost closure" as many people have requested. It'd be quite consistent. - Internal closures can still be implemented using `do` if truly desired. I imagine that `for || { }` would be syntactic sugar for: let mut _iterator_ = ; loop { let = match _iterator_.next() { None => break, Some(v) => v }; } or something similar, depending on the precise iterator protocol that we adopt. If `||` is omitted it would be equivalent to `|()|`. Arguably retaining the current `for` syntax suggests closures where none exist, but it seems silly to change it and invalidate all existing programs for this reason (I imagine `for in ` would be the more standard syntax). Niko On Thu, Jun 06, 2013 at 11:25:28AM -0700, Graydon Hoare wrote: > On 05/06/2013 9:15 PM, Patrick Walton wrote: > >On 6/5/13 9:09 PM, Daniel Micay wrote: > >>I think extending the built-in `for` loop to work with external iterators > >>should be considered, because right now the verbosity discourages > >>using them > >>and makes borrow checking more painful than it has to be. > >> > >>It could treat functions as internal iterators, and look for an > >>`Iterator` > >>implementation (using a `lang` item) for external ones. > >> > >>Python's `for` loop starts by looking for an iterator (a `__next__` > >>method) and > >>falls back to an iterable (an `__iter__` method) so behaviour like > >>this isn't > >>an alien concept. > > > >This is a very well-thought out post, and I find it persuasive. The > >mutability issue is one I hadn't considered, and seems to make a good > >argument for including both in the language. > > Yeah. I think it's clear enough that both have their (strong) > advantages; we have hashmaps and treemaps too, and both vectors and > lists :) > > The main thing I'm concerned with is making the interfaces to user > code smooth enough that neither feels markedly second-class or > unusable. Extending 'for' as you suggest sounds like a good step. > > It might also be good to add a tutorial chapter on the matter, > introducing these terms and relating them together, so users can see > the relative use cases. > > Thanks for the ongoing work in this area! > > -Graydon > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From amanieu at gmail.com Wed Jun 12 11:11:25 2013 From: amanieu at gmail.com (Amanieu d'Antras) Date: Wed, 12 Jun 2013 19:11:25 +0100 Subject: [rust-dev] Proposal for function objects Message-ID: Hi, I've been working on a proposal to unify Rust's closure type with traits. The idea is based on C++ function objects, which allow any object which implements the function call operator to be callable. The full proposal is at: https://github.com/mozilla/rust/wiki/Proposal-for-function-objects I would appreciate any feedback you may have. Amanieu From jack at metajack.im Wed Jun 12 11:42:43 2013 From: jack at metajack.im (Jack Moffitt) Date: Wed, 12 Jun 2013 12:42:43 -0600 Subject: [rust-dev] Proposal for function objects In-Reply-To: References: Message-ID: > I've been working on a proposal to unify Rust's closure type with > traits. The idea is based on C++ function objects, which allow any > object which implements the function call operator to be callable. This kind of stuff is one of my favorite things from Clojure. Having maps, sets, vectors, keywords, etc all implement IFn makes many things really nice. I don't know if all those conveniences would survive in rust, but if we could get a few of them, it would be quite nice. jack. From garethdanielsmith at gmail.com Wed Jun 12 13:08:24 2013 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Wed, 12 Jun 2013 21:08:24 +0100 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130612145806.GN5989@Mr-Bennet> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> <20130612145806.GN5989@Mr-Bennet> Message-ID: <51B8D538.2030509@gmail.com> On 12/06/13 15:58, Niko Matsakis wrote: > I imagine that `for || { }` would be syntactic sugar > for: > > let mut _iterator_ = ; > loop { > let = match _iterator_.next() { > None => break, > Some(v) => v > }; > > } > I think this is great. It is a more intuitive rewriting than the current for-loop (where it is not even obvious whether for-loops could be rewritten without compiler magic). > Arguably retaining the current `for` syntax suggests closures where > none exist, but it seems silly to change it and invalidate all > existing programs for this reason (I imagine `for in ` > would be the more standard syntax). I don't feel strongly but I think I would prefer `for in { ... }` because it looks different to a closure and also because it gets rid of two |. My rust code breaks every time I get the latest incoming anyway - and it is a pretty mechanical change. Gareth From hatahet at gmail.com Wed Jun 12 13:33:55 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 12 Jun 2013 13:33:55 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <51B8D538.2030509@gmail.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> <20130612145806.GN5989@Mr-Bennet> <51B8D538.2030509@gmail.com> Message-ID: On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith wrote: > My rust code breaks every time I get the latest incoming anyway - and it > is a pretty mechanical change. > > I agree. There are no guarantees that current code will not break in future versions of the language, until it stabilizes. Looking at what other new languages are facing when they start to carry over cruft, I think Rust is at an advantage here to try as much as possible to "get things right". -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronald.dahlgren at gmail.com Wed Jun 12 13:37:22 2013 From: ronald.dahlgren at gmail.com (Ronald Dahlgren) Date: Wed, 12 Jun 2013 13:37:22 -0700 Subject: [rust-dev] Refactoring getopts Message-ID: Hello all, I have been using the getopts module lately and noticed a number of ways I feel the library could be improved. I've looked at the popular / idiomatic methods for parsing POSIX style command line arguments in ~8 different languages to cherry pick what I believe to be the best and most developer friendly aspects. With that being said, I thought I'd put out some feelers and see who is currently using getopts heavily in their projects. My idea right now is to use the getopts:: groups style uniformly, and maybe add some additional sugar to it. Let me know if you have any specific pain points with the existing API, I want to make it a breeze to use! Command line args are usually encountered just after "hello world" when coming to a new language, so it is a good opportunity to showcase the languages strengths. Ron Dahlgren http://www.dahlgren.so | @ScaleItRon -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Wed Jun 12 13:58:39 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Wed, 12 Jun 2013 13:58:39 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> <20130612145806.GN5989@Mr-Bennet> <51B8D538.2030509@gmail.com> Message-ID: <51B8E0FF.2020606@mozilla.com> On 12/06/2013 1:33 PM, Ziad Hatahet wrote: > On Wed, Jun 12, 2013 at 1:08 PM, Gareth Smith > > wrote: > > My rust code breaks every time I get the latest incoming anyway - > and it is a pretty mechanical change. > > > I agree. There are no guarantees that current code will not break in > future versions of the language, until it stabilizes. Looking at what > other new languages are facing when they start to carry over cruft, I > think Rust is at an advantage here to try as much as possible to "get > things right". Eh, unclear to me. I am partial to the existing syntax (reads like do-notation, which I think we're keeping) and avoids breaking tons of code and adding a keyword. Also supports no-arg iteration like: for 1000.times { ... } which, curiously, we actually use from time to time. -Graydon From thadguidry at gmail.com Wed Jun 12 14:21:17 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Wed, 12 Jun 2013 16:21:17 -0500 Subject: [rust-dev] The future of iterators in Rust Message-ID: Let's step back a moment... to the ORIGINAL PROBLEM that was looking for a solution: " Rust's internal iterators implement the protocol encoded in Rust's for statement, but it's not possible to give them all a common trait or implement generic methods or functions taking any internal iterator. " 1. Is the above really A PROBLEM ? 2. If it is a PROBLEM, then what are the plausible solutions that solve it and keep Graydon happy ? a.) Does the solution keep dot-notation ? b.) Does the solution support no-arg iteration ? or similar ? c.) Does the solution avoid breaking tons of code ? d.) Does the solution avoid adding a keyword ? e.) Any other hard requirements ? -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Jun 12 14:51:48 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Jun 2013 17:51:48 -0400 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: References: Message-ID: On Wed, Jun 12, 2013 at 5:21 PM, Thad Guidry wrote: > Let's step back a moment... to the ORIGINAL PROBLEM that was looking for a > solution: > > " > Rust's internal iterators implement the protocol encoded in Rust's for > statement, but it's not possible to give them all a common trait or > implement > generic methods or functions taking any internal iterator. > " > > 1. Is the above really A PROBLEM ? This is only one of many problems with internal iterators in Rust. They are very slow to compile, and often perform much worse than external iterators without hacking around the problem by forcing inlining of loop bodies (the compiler does this now) and the internal iterator itself. The closure parameter doesn't play well with regions. Almost every adaptor needs a version for `T`, `&T` and `&mut T`. Attempting to break out of a loop won't succeed if the internal iterator isn't implemented correctly. This means `break` and `return` won't always work, and won't borrow check as expected. Having the `for` body as a closure can also make dealing with local variables very painful, since uses of them are now captures. It encourages using copies instead of moves. They fundamentally cannot have their state saved, so there are many algorithms that cannot be implemented at all with them like zip, merge, intersect, union, difference, etc. Finally, there's the problem you mention of lacking the ability to encode this information in a trait, so the subset of adaptors that *can* be represented have ridiculously complex signatures and are overly complex to use. > a.) Does the solution keep dot-notation ? Internal iterators don't have a way of supporting dot notation generically in Rust. External iterator adaptors chain very well together and default methods will be a really nice way to expose them. > b.) Does the solution support no-arg iteration ? or similar ? This will be supported regardless of whether we choose internal or external iterators. It seems like a great reason to keep the current for loop syntax though. > c.) Does the solution avoid breaking tons of code ? We're already halfway done migrating away from internal iterators. The breakage has already happened and there will be more. Every single for loop is going to need to be changed yet again when `for` switches to external iterators. I think now would be the perfect time to decide if the `for` syntax should be different, although I'm totally fine with the existing syntax. > d.) Does the solution avoid adding a keyword ? The existing `for` loop can be migrated to work with external iterators. It doesn't look like we'll have any internal iterator use cases in the standard library and I think the `do` statement is enough support for third party internal iterators. Our `for` loops seem like the only reason for not currently supporting `return` in nested closures, and it would be nice to relax that restriction. From hatahet at gmail.com Wed Jun 12 16:57:11 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 12 Jun 2013 16:57:11 -0700 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <51B8E0FF.2020606@mozilla.com> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> <20130612145806.GN5989@Mr-Bennet> <51B8D538.2030509@gmail.com> <51B8E0FF.2020606@mozilla.com> Message-ID: On Wed, Jun 12, 2013 at 1:58 PM, Graydon Hoare wrote: > Eh, unclear to me. I am partial to the existing syntax (reads like > do-notation, which I think we're keeping) and avoids breaking tons of code > and adding a keyword. Also supports no-arg iteration like: > I guess I wasn't specifically referring to this issue. Sorry for not being clearer :) I am not really partial to either for syntax proposals. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Jun 12 22:23:03 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 12 Jun 2013 22:23:03 -0700 Subject: [rust-dev] Any interest in a San Francisco Bay Area Rust meetup and/or hackathon? In-Reply-To: References: <519FDA2A.70007@mozilla.com> <519FEE4A.8040104@mozilla.com> Message-ID: Thanks everyone who could make it! It was great meeting you all. I'm planning on the next SF Bay Area meetup some time in July. Would anyone want to give a presentation? If so, let me know your availability and how much time you will need to put one together. On Monday, June 10, 2013, Erick Tryzelaar wrote: > Is there anyone else coming to the meetup this Wednesday that hasn't told > me they are coming? I've got 15 people confirmed right now, which fits > nicely into my reservation for 20, but if there's a lot more that is > planning on coming I'll need to up my reservation. > > > On Wed, Jun 5, 2013 at 5:37 PM, Erick Tryzelaar > > wrote: > >> Hey folks! >> >> I've made a reservation for 20 people at Tied House in Mountain View next >> Wednesday, June 12th, at 7pm: >> >> Tied House >> 954 Villa St, Mountain View, CA 94041 >> http://tiedhouse.com/ >> map: http://goo.gl/maps/p9dK0. >> >> It's right near Caltrain, so it should hopefully be pretty easy for >> people to commute to the restaurant. Please let me know if you are coming >> so I can grow/shrink the reservation. >> >> Finally, please bring some cash because we'll all be sharing one check, >> and it'll be easier to split the bill. >> >> Looking forward to meeting you all! >> -Erick >> >> >> >> On Mon, Jun 3, 2013 at 1:23 PM, Erick Tryzelaar < >> erick.tryzelaar at gmail.com > 'erick.tryzelaar at gmail.com');>> wrote: >> >>> Hey all! I think we have critical mass for a presentation or two. Would >>> anyone be interested in giving a presentation? If so, how much time would >>> you need to put one together? >>> >>> >>> On Mon, May 27, 2013 at 4:27 PM, Kevin Cantu >>> > wrote: >>> >>>> Count me in. :) >>>> >>>> >>>> Kevin >>>> >>>> >>>> -- >>>> Kevin Cantu >>>> >>>> >>>> On Fri, May 24, 2013 at 3:48 PM, Brian Anderson >>>> > wrote: >>>> >>>>> On 05/24/2013 03:31 PM, Erick Tryzelaar wrote: >>>>> >>>>>> Glad to help. >>>>>> >>>>>> So far I've heard from 10 others so far, which I think is pretty good >>>>>> for our first one in the bay area. When do the interns start? This could be >>>>>> a good way to introduce them into the community / convince them work on my >>>>>> feature requests :) >>>>>> >>>>>> >>>>> All the rust interns will be here by 6/10. >>>>> >>>>> ______________________________**_________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>> 'Rust-dev at mozilla.org');> >>>>> https://mail.mozilla.org/**listinfo/rust-dev >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asb at asbradbury.org Thu Jun 13 03:38:30 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Thu, 13 Jun 2013 11:38:30 +0100 Subject: [rust-dev] The future of iterators in Rust In-Reply-To: <20130612145806.GN5989@Mr-Bennet> References: <20130606040929.GA6212@thinktank.vlan1.phub.net.cable.rogers.com> <51B00CD8.4090608@mozilla.com> <51B0D418.6030909@mozilla.com> <20130612145806.GN5989@Mr-Bennet> Message-ID: On 12 June 2013 15:58, Niko Matsakis wrote: > - We can have `return` just make "early return from the innermost closure" > as many people have requested. It'd be quite consistent. As a recent newcomer to Rust, this would be *very* welcome. It is one area I found particularly inelegant. Alex From noamraph at gmail.com Thu Jun 13 07:17:22 2013 From: noamraph at gmail.com (Noam Yorav-Raphael) Date: Thu, 13 Jun 2013 17:17:22 +0300 Subject: [rust-dev] The 'for' syntax for iterators Message-ID: Hello, I want to point something that may be a reason for changing the 'for' syntax for external iterators: list comprehensions. I find list comprehensions (and generator expressions) in Python to be something that makes Python code much more concise, and make Python much more fun for data exploration. For example, without generator expression, I'd have to write instead of this: print mean(person.height for person in people if person.weight > 30) something like this: L = [] for person in people: if person.weight > 30: L.append(person.height) print mean(L) With rust moving to external iterators, it seems to me that adding list comprehensions is entirely possible. I'm not saying it should be done before 1.0, but it may be worthwhile to prepare for that. If the current syntax is preserved, the list comprehension should look something like this, to preserve consistency: mean(person.height for people |person| if person.weight > 30) and even mean(person.height for families |family| for family |person| if person.weight > 30) I find it much less readable than mean(person.height for family in families for person in family if person.weight > 30) My point is that the choice of syntax may have consequences for more syntax. I'd be very happy to write a script to convert from "for y |x|" to "for x in y", as I believe it would make rust significantly more easy to read and write (I believe it shouldn't be difficult given a tokenizer) One another point for switching the syntax: It may actually help the transition to external iterators. Have 'for x in y' handle only for external iterators and 'for y |x|' only internal iterators. Gradually replace all internal iterators by external ones, and when finished, remove the internal 'for' syntax from the language. I hope you'll pardon me for giving my opinion without being a developer - I just find rust really exciting, and would like it to be as perfect as it could be. Thanks for reading this, and have a great day, Noam -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Thu Jun 13 09:44:22 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 13 Jun 2013 09:44:22 -0700 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: Shouldn't we just be able to use map() and filter() routines to do the same? -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From noamraph at gmail.com Thu Jun 13 10:22:24 2013 From: noamraph at gmail.com (Noam Yorav-Raphael) Date: Thu, 13 Jun 2013 20:22:24 +0300 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: I find the code much easier to comprehend that way. Also, I don't know how you can write nested comprehensions with map and filter. Also, with map and filter you have to give names to variables both for map and for filter. Contrast: [name for name. age in zip(names, ages) if age > 30] with zip(names, ages).filter(|name, age| age > 30).map(|name, age| name) See http://en.wikipedia.org/wiki/List_comprehension - a lot of languages have list comprehensions. They're really useful. On 13 June 2013 19:44, Ziad Hatahet wrote: > Shouldn't we just be able to use map() and filter() routines to do the > same? > > -- > Ziad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Thu Jun 13 10:25:26 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 13 Jun 2013 10:25:26 -0700 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: At this point we're focusing on removing features from Rust. We're vanishingly unlikely to add list comprehensions at this point. Rust's audience is C and C++ programmers, who won't necessarily notice their absence anyway. (Personally, I almost never used list comprehensions when I programmed in Haskell -- I found using higher-order functions directly to be much more natural -- but that part is just my opinion.) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From hatahet at gmail.com Thu Jun 13 10:43:16 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 13 Jun 2013 10:43:16 -0700 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: Perhaps you can get around somewhat by using macros? I asked the following question on the mailing list a while back, so maybe something similar can be used here: https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Thu Jun 13 10:46:02 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 13 Jun 2013 10:46:02 -0700 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 10:43 AM, Ziad Hatahet wrote: > Perhaps you can get around somewhat by using macros? I asked the following > question on the mailing list a while back, so maybe something similar can > be used here: > > https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html > > -- > Ziad > > This reply in particular: https://mail.mozilla.org/pipermail/rust-dev/2013-May/004182.html -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From noamraph at gmail.com Thu Jun 13 11:31:05 2013 From: noamraph at gmail.com (Noam Yorav-Raphael) Date: Thu, 13 Jun 2013 21:31:05 +0300 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: Thanks for the answer! As I said, I really don't mean that list comprehensions should be added now - just that they may be added some time later, and that they're likely to use the same 'for' syntax. I believe you're going to find that rust's audience will be much wider than current C/C++ programmers. Say I want to write an application that is not very computationally heavy. Which language should I choose? Java and C# require a big runtime so hard to distribute, C# is windows-only, Java startup time is annoying. Python is slow and too dynamic (hard time refactoring). C/C++ will mean that I'll have to deal with segmentation faults all the time. Rust will be a perfect choice. See for example http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ - 0install is a package manager that is currently written in Python. The developer is thinking of rewriting it in a different language. C/C++ are not considered (and rightly so), but rust is, and currently it wins the most points in the author's several comparisons! When rust will mature, it will get a lot more points (startup time, dependencies, tracebacks, standard library) and be a very clear winner. So definitely, make the language as simple as you can for the 1.0 release - it should be made as simple as possible, but not simpler. But I have the feeling that I, as a mainly-python programmer (a bit of C too), am going to enjoy rust quite a lot. And I actually think that with a bit of sugar and some good libraries, I may enjoy rust programming more than I enjoy python programming. tl;dr Rust is already gaining a lot of interest from non C/C++ programmers. I think they should be somewhere at the back of your mind when you are designing rust. Cheers. Noam On 13 June 2013 20:25, Tim Chevalier wrote: > At this point we're focusing on removing features from Rust. We're > vanishingly unlikely to add list comprehensions at this point. Rust's > audience is C and C++ programmers, who won't necessarily notice their > absence anyway. (Personally, I almost never used list comprehensions > when I programmed in Haskell -- I found using higher-order functions > directly to be much more natural -- but that part is just my opinion.) > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Not a riot, it's a rebellion." -- Boots Riley > "Attention Bros and Trolls: When I call out your spew, I'm not angry, > I'm defiant." -- Reg Braithwaite > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Thu Jun 13 14:27:03 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 13 Jun 2013 14:27:03 -0700 Subject: [rust-dev] NOTE: incoming branch retired Message-ID: <51BA3927.7020700@mozilla.com> Hi, We've deleted the `incoming` branch on github. It was a temporary measure until we had sufficiently solid auto-integration, which we now have in the form of bors and the `auto` branch. The tree will be closed for part of today in order to mop up various associated failures. From then on in, we should be back to a "normal" git project, developing on `master`. If you had any automation set up to poll the `incoming` branch, it will now begin failing. Apologies for any inconvenience (if there's some reason you can't update your automation, let me know and I may recreate the ref temporarily, but for now I see no reason to keep it around, just increases confusion). -Graydon From steve at steveklabnik.com Thu Jun 13 14:28:50 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Thu, 13 Jun 2013 17:28:50 -0400 Subject: [rust-dev] NOTE: incoming branch retired In-Reply-To: <51BA3927.7020700@mozilla.com> References: <51BA3927.7020700@mozilla.com> Message-ID: Excellent. This is great news! From tyler.brock at gmail.com Thu Jun 13 15:47:18 2013 From: tyler.brock at gmail.com (Tyler Brock) Date: Thu, 13 Jun 2013 18:47:18 -0400 Subject: [rust-dev] NOTE: incoming branch retired In-Reply-To: References: <51BA3927.7020700@mozilla.com> Message-ID: I've made a pull request to make homebrew's `brew install rust --HEAD` build master instead of incoming: https://github.com/mxcl/homebrew/pull/20492 -Tyler On Thu, Jun 13, 2013 at 5:28 PM, Steve Klabnik wrote: > Excellent. This is great news! > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Thu Jun 13 21:55:49 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 13 Jun 2013 21:55:49 -0700 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: This thread made its way to the Rust subreddit, where people posted a couple of implementations using macros. Very cool stuff! http://www.reddit.com/r/rust/comments/1gag3t/list_comprehensions_in_rust_iterator/ http://en.wikipedia.org/wiki/List_comprehension#Rust -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Thu Jun 13 23:07:40 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 13 Jun 2013 23:07:40 -0700 Subject: [rust-dev] NOTE: incoming branch retired In-Reply-To: <51BA3927.7020700@mozilla.com> References: <51BA3927.7020700@mozilla.com> Message-ID: <51BAB32C.4080801@mozilla.com> On 13/06/2013 2:27 PM, Graydon Hoare wrote: > We've deleted the `incoming` branch on github. It was a temporary > measure until we had sufficiently solid auto-integration, which we now > have in the form of bors and the `auto` branch. > > The tree will be closed for part of today in order to mop up various > associated failures. From then on in, we should be back to a "normal" > git project, developing on `master`. Speaking of "various associated failures": doing this caused all the pull requests open against incoming to be mass-closed. Sorry! I had no idea it was going to do that, though I guess on reflection it should have been obvious. Anyway, I don't think there's anything I can do to undo it. Please re-open any pull requests you meant for us to land, but targeting master! Sorry again, -Graydon From igor at mir2.org Fri Jun 14 09:27:13 2013 From: igor at mir2.org (Igor Bukanov) Date: Fri, 14 Jun 2013 18:27:13 +0200 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: On 13 June 2013 19:25, Tim Chevalier wrote: > Personally, I almost never used list comprehensions > when I programmed in Haskell -- I found using higher-order functions > directly to be much more natural -- but that part is just my opinion. I second that. What one wants is a function composition. A good composing library shoud allow to write code that is just as readable as list comprehensions. From remifontan at yahoo.fr Fri Jun 14 16:11:28 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sat, 15 Jun 2013 11:11:28 +1200 Subject: [rust-dev] cmp::max and generics Message-ID: Hi, I have difficulties understanding how to use functions from the cmp module. With following example, I get errors when trying to compile it. There is something obvious I must not understand. errors: rustc test.rs -o test-test --test test.rs:15:12: 15:20 error: unresolved name test.rs:15 cmp::max(self.x, self.y) ^~~~~~~~ test.rs:15:12: 15:20 error: use of undeclared module `cmp` test.rs:15 cmp::max(self.x, self.y) ^~~~~~~~ test.rs:15:12: 15:20 error: unresolved name `cmp::max`. test.rs:15 cmp::max(self.x, self.y) ^~~~~~~~ error: aborting due to 3 previous errors make: *** [test-test] Error 101 code: extern mod std; use std::cmp; use math::*; pub mod math { #[deriving(Eq, Clone)] struct Vec2x { x:T, y:T } impl Vec2x { pub fn new(a:T, b:T) -> Vec2x { Vec2x{x:a, y:b} } pub fn max(&self) -> T { cmp::max(self.x, self.y) } } } #[test] fn test_Vec2x() { let v = Vec2x::new(1f,2f); } Would you be able to explain me? I'm using the latest rust version from git: brew install rust --HEAD cheers, Remi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Jun 14 22:58:33 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 15 Jun 2013 01:58:33 -0400 Subject: [rust-dev] cmp::max and generics In-Reply-To: References: Message-ID: On Fri, Jun 14, 2013 at 7:11 PM, R?mi Fontan wrote: > Hi, > > I have difficulties understanding how to use functions from the cmp module. > With following example, I get errors when trying to compile it. There is > something obvious I must not understand. > > > errors: > rustc test.rs -o test-test --test > test.rs:15:12: 15:20 error: unresolved name > test.rs:15 cmp::max(self.x, self.y) > ^~~~~~~~ > test.rs:15:12: 15:20 error: use of undeclared module `cmp` > test.rs:15 cmp::max(self.x, self.y) > ^~~~~~~~ > test.rs:15:12: 15:20 error: unresolved name `cmp::max`. > test.rs:15 cmp::max(self.x, self.y) > ^~~~~~~~ > error: aborting due to 3 previous errors > make: *** [test-test] Error 101 > > > > code: > extern mod std; > use std::cmp; > > use math::*; > > pub mod math { > > #[deriving(Eq, Clone)] > struct Vec2x { x:T, y:T } > > impl Vec2x { > pub fn new(a:T, b:T) -> Vec2x { Vec2x{x:a, y:b} } > > pub fn max(&self) -> T { > cmp::max(self.x, self.y) > } > } > } > > > #[test] > fn test_Vec2x() { > let v = Vec2x::new(1f,2f); > } > > > > Would you be able to explain me? > > I'm using the latest rust version from git: brew install rust --HEAD > > cheers, > > Remi > > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand The top-level `use std::cmp` isn't visible from `mod math`. From graydon at mozilla.com Sat Jun 15 01:26:48 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 15 Jun 2013 01:26:48 -0700 Subject: [rust-dev] code generation and rustc speed Message-ID: <51BC2548.7010400@mozilla.com> I saw some more speculation on how to make rustc not-so-terriby-slow to compile today, including dramatic structural changes like splitting it into sub-crates. Please don't do this; it's papering over much more readily solvable problems. A 80kloc library does not need to be generating 16mb of object code. Here are two simple listings of symbols we're generating: http://people.mozilla.org/~graydon/symbols-by-size.txt http://people.mozilla.org/~graydon/symbols-by-name.txt Some things should be immediately apparent: - We're generating some (not all) _very_ large functions. Look at ty::mk_ctxt. It's a single constructor call. It produces 133kb of code. This has got to be some quadratic codegen bug. - There are 15762 functions but only 2039 unique function-sizes. We're not collapsing a _lot_ of identical functions. - We're generating a _lot_ of monomorphic instances. There are 363 hashtable:: functions in there -- about 50 copies of the std::hashtable module. Similar number of copies of std::vec. 68 copies of extfmt::conv_poly. 392 visit:: functions. - We're still generating a _lot_ of glue. Very little of it seems to be properly recycled -- there are many copies of each glue for types that vary only in a not-used type param, of identical size. 7134 of the 15762 functions are glue. Beyond all that, there are pretty apparent systemic taxes as soon as you start digging into the LLVM. Take a look at, say, http://people.mozilla.org/~graydon/graph.svg -- the CFG from middle::trans::inline::maybe_instantiate_inline for example. It's a very modest 100-line function with 3 or 4 of nested matches. It produces 687 CFG nodes, 903 edges, and 8068 LLVM instructions (and that's a _small_ one -- it only winds up as 7k of object code). There are a lot of things in there that shouldn't be being-generated. -Graydon From remifontan at yahoo.fr Sat Jun 15 02:07:46 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sat, 15 Jun 2013 21:07:46 +1200 Subject: [rust-dev] cmp::max and generics In-Reply-To: References: Message-ID: great, that works. I guess I need to read a bit more about how scoping works in rust. thanks, R?mi On Sat, Jun 15, 2013 at 5:58 PM, Daniel Micay wrote: > On Fri, Jun 14, 2013 at 7:11 PM, R?mi Fontan wrote: > > Hi, > > > > I have difficulties understanding how to use functions from the cmp > module. > > With following example, I get errors when trying to compile it. There is > > something obvious I must not understand. > > > > > > errors: > > rustc test.rs -o test-test --test > > test.rs:15:12: 15:20 error: unresolved name > > test.rs:15 cmp::max(self.x, self.y) > > ^~~~~~~~ > > test.rs:15:12: 15:20 error: use of undeclared module `cmp` > > test.rs:15 cmp::max(self.x, self.y) > > ^~~~~~~~ > > test.rs:15:12: 15:20 error: unresolved name `cmp::max`. > > test.rs:15 cmp::max(self.x, self.y) > > ^~~~~~~~ > > error: aborting due to 3 previous errors > > make: *** [test-test] Error 101 > > > > > > > > code: > > extern mod std; > > use std::cmp; > > > > use math::*; > > > > pub mod math { > > > > #[deriving(Eq, Clone)] > > struct Vec2x { x:T, y:T } > > > > impl Vec2x { > > pub fn new(a:T, b:T) -> Vec2x { Vec2x{x:a, y:b} } > > > > pub fn max(&self) -> T { > > cmp::max(self.x, self.y) > > } > > } > > } > > > > > > #[test] > > fn test_Vec2x() { > > let v = Vec2x::new(1f,2f); > > } > > > > > > > > Would you be able to explain me? > > > > I'm using the latest rust version from git: brew install rust --HEAD > > > > cheers, > > > > Remi > > > > > > > > -- > > R?mi Fontan : remifontan at yahoo.fr > > mobile: +64 21 855 351 > > 93 Otaki Street, Miramar 6022 > > Wellington, New Zealand > > The top-level `use std::cmp` isn't visible from `mod math`. > -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From remifontan at yahoo.fr Sat Jun 15 02:52:24 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sat, 15 Jun 2013 21:52:24 +1200 Subject: [rust-dev] function overloading Message-ID: Hi, I read that rust does not handle function overloading. So I seek your advise to how I should be handling the following case. I have a struct vec2d, which is a 2d vector. vec2d{x:float, y:float} I would like to implement the trait Mul such that I can multiply a vector by another vector, component by component let v1: Vec2d = ...; let v2: Vec2d = ...; v1*v2; but I also would like to be able to multiply a vec2d with a scalar. let v3 = v1*-1f; I tried implementing the trait Mul twice but the compiler complains. How would you do it? cheers, R?mi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From remifontan at yahoo.fr Sat Jun 15 03:36:23 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sat, 15 Jun 2013 22:36:23 +1200 Subject: [rust-dev] iterator Message-ID: I found the following example in the doc let a = [100, 200]; let mut it = a.iter().enumerate(); and it prints following when compiling: test.rs:32:17: 32:38 error: type `std::vec::VecIterator/&<>` does not implement any method in scope named `enumerate` test.rs:32 let mut it = a.iter().enumerate(); Would you know what I need to do to simply enumerate a vector? cheers, Remi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From pancake at youterm.com Sat Jun 15 03:42:16 2013 From: pancake at youterm.com (pancake) Date: Sat, 15 Jun 2013 12:42:16 +0200 Subject: [rust-dev] asm directive Message-ID: <61BB0E20-7C52-48F2-8417-E4B985097631@youterm.com> Hi, I've been trying to use some asm inline code in rust. But faced so many issues during the process and end up giving up because of this. Simple asm inline works fine, but when working with clobbers and comunicating rust to asm seems to be broken. I found several segmentation faults (null pointers) when trying to compile the code. Also, I found that there's no direct way to pass variables and set numeric values because both references use the same '$' prefix. Then I tried to pass an input variable with a given value to be able to set a register to a specific value.. And then i got the assembler trying to compile 32bit instructions mixed with 64 bit ones. The question here is: which is the plan for supporting the asm directive? It aims to be gcc syntax compatible? Should we go for a more direct syntax like msvc does with naked keywords and so on? Also, i believe that mixing macros with inlined asm can be another cool way to extend the language possibilities, while allowing fine grained assembly code. --pancake From thadguidry at gmail.com Sat Jun 15 05:55:48 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Sat, 15 Jun 2013 07:55:48 -0500 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BC2548.7010400@mozilla.com> References: <51BC2548.7010400@mozilla.com> Message-ID: >From a holistic approach, does this problem point to : 1. More LLVM tweaking in general is needed ? 2. More use of libraries and better libraries are needed ? 3. Both 1 and 2 ? On Sat, Jun 15, 2013 at 3:26 AM, Graydon Hoare wrote: > I saw some more speculation on how to make rustc not-so-terriby-slow to > compile today, including dramatic structural changes like splitting it into > sub-crates. Please don't do this; it's papering over much more readily > solvable problems. A 80kloc library does not need to be generating 16mb of > object code. > > Here are two simple listings of symbols we're generating: > > http://people.mozilla.org/~**graydon/symbols-by-size.txt > http://people.mozilla.org/~**graydon/symbols-by-name.txt > > Some things should be immediately apparent: > > - We're generating some (not all) _very_ large functions. > Look at ty::mk_ctxt. It's a single constructor call. > It produces 133kb of code. This has got to be some quadratic > codegen bug. > > - There are 15762 functions but only 2039 unique function-sizes. > We're not collapsing a _lot_ of identical functions. > > - We're generating a _lot_ of monomorphic instances. > There are 363 hashtable:: functions in there -- about 50 copies > of the std::hashtable module. Similar number of copies of > std::vec. 68 copies of extfmt::conv_poly. 392 visit:: functions. > > - We're still generating a _lot_ of glue. Very little of it > seems to be properly recycled -- there are many copies of > each glue for types that vary only in a not-used type param, > of identical size. 7134 of the 15762 functions are glue. > > Beyond all that, there are pretty apparent systemic taxes as soon as you > start digging into the LLVM. Take a look at, say, > http://people.mozilla.org/~**graydon/graph.svg-- the CFG from middle::trans::inline::maybe_ > **instantiate_inline for example. It's a very modest 100-line function > with 3 or 4 of nested matches. It produces 687 CFG nodes, 903 edges, and > 8068 LLVM instructions (and that's a _small_ one -- it only winds up as 7k > of object code). There are a lot of things in there that shouldn't be > being-generated. > > -Graydon > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Sat Jun 15 06:15:27 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Sat, 15 Jun 2013 09:15:27 -0400 Subject: [rust-dev] function overloading In-Reply-To: References: Message-ID: This blog post describes how you would achieve this: http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/ See the section entitled "What if I want overloading?" On Sat, Jun 15, 2013 at 5:52 AM, R?mi Fontan wrote: > Hi, > > I read that rust does not handle function overloading. So I seek your > advise to how I should be handling the following case. > > I have a struct vec2d, which is a 2d vector. vec2d{x:float, y:float} > > I would like to implement the trait Mul such that I can multiply a vector > by another vector, component by component > > let v1: Vec2d = ...; > let v2: Vec2d = ...; > v1*v2; > > but I also would like to be able to multiply a vec2d with a scalar. > let v3 = v1*-1f; > > I tried implementing the trait Mul twice but the compiler complains. How > would you do it? > > cheers, > > R?mi > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Jun 15 09:17:22 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 15 Jun 2013 12:17:22 -0400 Subject: [rust-dev] code generation and rustc speed In-Reply-To: References: <51BC2548.7010400@mozilla.com> Message-ID: On Sat, Jun 15, 2013 at 8:55 AM, Thad Guidry wrote: > From a holistic approach, does this problem point to : > Mostly it points to the code being old and crappy. LLVM IR generation needs to be improved a ton, yes. Libraries? Not sure. From pwalton at mozilla.com Sat Jun 15 09:49:50 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 15 Jun 2013 09:49:50 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BC2548.7010400@mozilla.com> References: <51BC2548.7010400@mozilla.com> Message-ID: <51BC9B2E.7010204@mozilla.com> On 6/15/13 1:26 AM, Graydon Hoare wrote: > I saw some more speculation on how to make rustc not-so-terriby-slow to > compile today, including dramatic structural changes like splitting it > into sub-crates. Please don't do this; it's papering over much more > readily solvable problems. A 80kloc library does not need to be > generating 16mb of object code. I don't understand why you object to splitting librustc into subcrates. This is something that should be done regardless, for separate compilation and tooling reasons. Note that clang has separate CodeGen and Sema libraries for this reason. I would understand if people were suggesting that we just split rustc into subcrates and stop working on compilation speed. But nobody is, or has ever, suggested that. Patrick From bsteinbr at gmail.com Sat Jun 15 10:09:22 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Sat, 15 Jun 2013 19:09:22 +0200 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BC2548.7010400@mozilla.com> References: <51BC2548.7010400@mozilla.com> Message-ID: <20130615170922.GA18699@atjola.homenet> On 2013.06.15 01:26:48 -0700, Graydon Hoare wrote: > Here are two simple listings of symbols we're generating: > > http://people.mozilla.org/~graydon/symbols-by-size.txt > http://people.mozilla.org/~graydon/symbols-by-name.txt > > Some things should be immediately apparent: > > - We're generating some (not all) _very_ large functions. > Look at ty::mk_ctxt. It's a single constructor call. > It produces 133kb of code. This has got to be some quadratic > codegen bug. This seems to be due to the landing pads for the function calls. Each contains one more call to drop, so the code grows quadratically with the number of allocations. Bj?rn From graydon at mozilla.com Sat Jun 15 11:34:16 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 15 Jun 2013 11:34:16 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130615170922.GA18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> Message-ID: <51BCB3A8.20901@mozilla.com> On 15/06/2013 10:09 AM, Bj?rn Steinbrink wrote: > This seems to be due to the landing pads for the function calls. Each > contains one more call to drop, so the code grows quadratically with the > number of allocations. Yes. Last time I was in the landing pad code (on the return-unwind branch) I was concerned that this was happening. I deferred a fix because we were in "get it working" mode. I suggest anyone wanting to help attack that first and foremost. -Graydon From pwalton at mozilla.com Sat Jun 15 11:41:04 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 15 Jun 2013 11:41:04 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130615170922.GA18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> Message-ID: <51BCB540.1080406@mozilla.com> On 6/15/13 10:09 AM, Bj?rn Steinbrink wrote: > This seems to be due to the landing pads for the function calls. Each > contains one more call to drop, so the code grows quadratically with the > number of allocations. I had a patch that's bitrotted to turn off table-driven unwinding on failure entirely for rustc. This is a sledgehammer of a solution, but it also seems practical to me: if any stage of the compiler fails, then the compiler can't reasonably do anything but abort anyhow. Patrick From bsteinbr at gmail.com Sat Jun 15 11:46:44 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Sat, 15 Jun 2013 20:46:44 +0200 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BCB3A8.20901@mozilla.com> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> <51BCB3A8.20901@mozilla.com> Message-ID: <20130615184644.GB18699@atjola.homenet> On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote: > On 15/06/2013 10:09 AM, Bj?rn Steinbrink wrote: > > >This seems to be due to the landing pads for the function calls. Each > >contains one more call to drop, so the code grows quadratically with the > >number of allocations. > > Yes. Last time I was in the landing pad code (on the return-unwind > branch) I was concerned that this was happening. I deferred a fix > because we were in "get it working" mode. I suggest anyone wanting > to help attack that first and foremost. Seems interesting, I'll give it a shot. Bj?rn From graydon at mozilla.com Sat Jun 15 11:59:00 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 15 Jun 2013 11:59:00 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BC9B2E.7010204@mozilla.com> References: <51BC2548.7010400@mozilla.com> <51BC9B2E.7010204@mozilla.com> Message-ID: <51BCB974.6080501@mozilla.com> On 15/06/2013 9:49 AM, Patrick Walton wrote: > On 6/15/13 1:26 AM, Graydon Hoare wrote: >> I saw some more speculation on how to make rustc not-so-terriby-slow to >> compile today, including dramatic structural changes like splitting it >> into sub-crates. Please don't do this; it's papering over much more >> readily solvable problems. A 80kloc library does not need to be >> generating 16mb of object code. > > I don't understand why you object to splitting librustc into subcrates. Because it was being proposed as a solution to speed, but: - Bors cycle time won't improve. - "Make check" / testsuite cycle time won't improve. - Since binary compatibility between crates is broken now anyways, anything aside from the topmost-crate in a dependency graph perturbs link-compatibility with everything else. Just changing 1 line. - Even if that was fixed, dependencies are dependencies; you touch the typechecker's type / interface surface, it's going to need to rebuild the dependent crates. Many changes do this. - Even if not, it's a self-hosting compiler and many changes only emerge in stage1-target / stage2. It won't help those steps. > This is something that should be done regardless, for separate > compilation and tooling reasons. Note that clang has separate CodeGen > and Sema libraries for this reason. I agree with that. I don't object to it being in multiple pieces in principle. But as speed work, it'll soak up some (very scarce) optimization time spent on what I see as a not-terribly-helpful diversion. > I would understand if people were suggesting that we just split rustc > into subcrates and stop working on compilation speed. But nobody is, or > has ever, suggested that. We have limited time to allocate between activities, that's all. Every time I've proposed we spend time on optimizing, I've been told feature work is more important. I accept those priority judgments but with the caveat that we not lose sight of the technical debt that needs repaying. These problems have been around for months, some years. -Graydon From pwalton at mozilla.com Sat Jun 15 12:25:49 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 15 Jun 2013 12:25:49 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BCB974.6080501@mozilla.com> References: <51BC2548.7010400@mozilla.com> <51BC9B2E.7010204@mozilla.com> <51BCB974.6080501@mozilla.com> Message-ID: <51BCBFBD.8040503@mozilla.com> On 6/15/13 11:59 AM, Graydon Hoare wrote: > Because it was being proposed as a solution to speed, but: Well, in my case, I often start swapping, which kills codegen performance. So it would help my particular use case. (It would also help us land the GC.) Patrick From graydon at mozilla.com Sat Jun 15 12:41:19 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 15 Jun 2013 12:41:19 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BCBFBD.8040503@mozilla.com> References: <51BC2548.7010400@mozilla.com> <51BC9B2E.7010204@mozilla.com> <51BCB974.6080501@mozilla.com> <51BCBFBD.8040503@mozilla.com> Message-ID: <51BCC35F.4090806@mozilla.com> On 15/06/2013 12:25 PM, Patrick Walton wrote: > On 6/15/13 11:59 AM, Graydon Hoare wrote: >> Because it was being proposed as a solution to speed, but: > > Well, in my case, I often start swapping, which kills codegen > performance. So it would help my particular use case. (It would also > help us land the GC.) Fair point. From a memory-bottleneck perspective, it would help. I still think it's unreasonable to be using that much memory _ever_, and am certain it's related to the gobs-too-much-IR problem. But you're right that this would be a viable strategy to get through memory peaks. Where would you draw the line? Split middle::trans and back off from the phases before them? -Graydon From danielmicay at gmail.com Sat Jun 15 12:42:47 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 15 Jun 2013 15:42:47 -0400 Subject: [rust-dev] iterator In-Reply-To: References: Message-ID: On Sat, Jun 15, 2013 at 6:36 AM, R?mi Fontan wrote: > I found the following example in the doc > > let a = [100, 200]; > let mut it = a.iter().enumerate(); > > and it prints following when compiling: > > test.rs:32:17: 32:38 error: type `std::vec::VecIterator/&<>` does not > implement any method in scope named `enumerate` > test.rs:32 let mut it = a.iter().enumerate(); > > Would you know what I need to do to simply enumerate a vector? > > cheers, > > Remi > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand You need a more up-to-date build, or you can import IteratorUtil manually. From bsteinbr at gmail.com Sat Jun 15 12:44:04 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Sat, 15 Jun 2013 21:44:04 +0200 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <51BCBFBD.8040503@mozilla.com> References: <51BC2548.7010400@mozilla.com> <51BC9B2E.7010204@mozilla.com> <51BCB974.6080501@mozilla.com> <51BCBFBD.8040503@mozilla.com> Message-ID: <20130615194404.GC18699@atjola.homenet> On 2013.06.15 12:25:49 -0700, Patrick Walton wrote: > On 6/15/13 11:59 AM, Graydon Hoare wrote: > >Because it was being proposed as a solution to speed, but: > > Well, in my case, I often start swapping, which kills codegen > performance. So it would help my particular use case. (It would also > help us land the GC.) A new snapshot would also help with that, IIRC peak memory usage has dropped by about 1GB since the last one was made. Not sure how much of a difference that makes for you, though. Bj?rn From graydon at mozilla.com Sat Jun 15 12:57:36 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 15 Jun 2013 12:57:36 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130615194404.GC18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <51BC9B2E.7010204@mozilla.com> <51BCB974.6080501@mozilla.com> <51BCBFBD.8040503@mozilla.com> <20130615194404.GC18699@atjola.homenet> Message-ID: <51BCC730.7090901@mozilla.com> On 15/06/2013 12:44 PM, Bj?rn Steinbrink wrote: > On 2013.06.15 12:25:49 -0700, Patrick Walton wrote: >> On 6/15/13 11:59 AM, Graydon Hoare wrote: >>> Because it was being proposed as a solution to speed, but: >> >> Well, in my case, I often start swapping, which kills codegen >> performance. So it would help my particular use case. (It would also >> help us land the GC.) > > A new snapshot would also help with that, IIRC peak memory usage has > dropped by about 1GB since the last one was made. Not sure how much of a > difference that makes for you, though. Yes. I've been trying to knock down the worst of the culprits in order to land the GC, making decent progress. We can get through 64bit bootstrapping, and 32bit is now able to get through libstd and libsyntax, but it dies OOM on librustc. So Patrick's suggestion would help here. (Much of the remainder is GC accounting structures, though; which is too absurd to be real. I'm sure there are some bad overuse bugs lurking in there too. And I have a replacement bitmap that almost works too.) -Graydon From corey at octayn.net Sat Jun 15 15:03:40 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 15 Jun 2013 18:03:40 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Content copied from http://cmr.github.io/blog/2013/06/15/this-week-in-rust/ -- --- layout: post title: "This Week In Rust" date: 2013-06-15 22:00 comments: true categories: [this-week-in-rust, rust, programming] --- Hello and welcome to the second issue of *This Week In Rust*, a weekly overview of Rust and its community. I'll be covering what's cooking in incoming, meeting summaries, meetups, and anything else pertinent. I've decided to stop using real names and use irc/github names, simply because that is how I, and most everyone, interacts in the community. # What's cooking in incoming? There's been a lot of breakage on incoming this week, with jemalloc breaking 32bit cross-compilation as well as random segfaults and stack corruption of unknown cause. Some heroics by the core devs have got it mostly cleaned up, though the tree is still rather chaotic. Meanwhile a handful of performance improvements have landed, and achricto rewrote `rusti`. There were 17 pull requests merged this week. Total issue churn (excludes pull requests) this week was +2 (this excludes the 38 pull requests that were closed when incoming was killed). ## `incoming` branch annihilated Goodbye `incoming`, hello `master`! This change, long in coming, unfortunately closed all open PRs. Start doing your development against `master` rather than incoming. ## Notable additions, bugfixes, and cleanups There's a concerted effort to remove duplicate freestanding functions where possible. - In [6986][is6986] bjz and jensnockert have cleaned up the numeric code some more, adding methods for existing things like `sin`, as well as adding a bunch of interpolation stuff. - steven_is_false added prototype dynamic library loading support in [7027][is7027], which should remove a lot of pain for people looking for easy dynamic loading. It currently doesn't work on Windows, so if you can sling Windows code, help would be appreciated! - In [7029][is7029] luqmana allows having multiple impl's add static methods, which previously did not work. - Eridius stepped up to [fix the terminfo code][tinfo], colors should be arriving to more people soon. - SiegeLord [improved the CSS][css] used by rustdoc with *huge* improvements. - sully has gotten default methods working for the most part, he is still testing cross-crate edge casses. - vadimcn [has fixed debuginfo][debug], and supposedly the GSoC intern is getting started on improving it next week. - doener has got [some nice][inline] [performance][cache] PRs in place. - aatch is working on [cleaning up trans][trans]. Huge thanks to him! ## Breaking changes - dbaupp and strcat continue their cleanup of the standard library, removing the ad-hoc iterator functions where `std::iterator` can replace them. - All of the string functions that could be reasonably converted to methods have been. - If you're working in the stdlib, acrichto has toggled most of the lint settings to "deny" for std/extra, so watch out. # Meetings The [Tuesday meeting][tues] talked about bblum's [Effect proposal][eff], removing the master/incoming split, and "alloc expressions", a replacement for @-sigils. The consensus on the effect proposal is that it needs investigation and wouldn't be landing in 1.0. Discussion about master/incoming mostly centered on "master isn't always green, how can we add better coverage to bors' tests?" Consensus seems to be that removing incoming would be beneficial, but enabling more OS and valgrind coverage on bors would harmfully impact development speed. The proposed syntax for alloc expressions is `new (provider) expr`, with `new expr` becoming the replacement for the current `~expr`. This would allow custom smart pointers. pcwalton ended the meeting with a huge cliff hanger {% blockquote %} I've been meaning to talk a little bit today about simplifying the mut-borrowing story in regards to this, we may be able to effect a large simplification on the language {% endblockquote %} Personally, I think [kimundi's proposal][kim] has a lot of promise, and the syntax is more pleasing to me. It wasn't brought up at the meeting, though. # Meetups - The Mountain View meetup was a great success. 18 showed up. erickt is planning for another SF Bay area meetup in July. If you want to give a presentation, send him your proposal and how long you need to put it together. - Tim Chevalier will be giving a talk titled "Rust: A Friendly Introduction" on Monday, June 17, 6-9pm in Portland. See [Calagator][rafi] for more details. This is a preview of a talk he will be giving at [Open Source Bridge][osb], also in Portland. # Notable discourse - Still more discussion about [iterators][iter], this time focusing around [changing the semantics][for] of the `for` loop. - Some discussion about [list comprehensions][listcomp], including initial proofs-of-concept. - Graydon explains hashing and versioning https://botbot.me/mozilla/rust/msg/3792753/ - Principal author of 0install evaluates rust among other languages as a python replacement http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ - Niko thinks about parallelism http://smallcultfollowing.com/babysteps/blog/2013/06/11/data-parallelism-in-rust/ - http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ # Other announcements - bjz tells me lmath is *actually* fixed now, and is usable [is6986]: https://github.com/mozilla/rust/pull/6986 [is7027]: https://github.com/mozilla/rust/pull/7027 [is7029]: https://github.com/mozilla/rust/pull/7029 [tues]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-11 [kim]: https://gist.github.com/Kimundi/5744578 [iter]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html [rafi]: http://calagator.org/events/1250464376 [for]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004465.html [listcomp]: http://www.reddit.com/r/rust/comments/1gag3t/list_comprehensions_in_rust_iterator/ [css]: https://github.com/mozilla/rust/pull/7077 [tinfo]: https://github.com/mozilla/rust/pull/7133 [osb]: http://opensourcebridge.org/sessions/970 [debug]: https://github.com/mozilla/rust/pull/7134 [inline]: https://github.com/mozilla/rust/pull/7154 [cache]: https://github.com/mozilla/rust/pull/7144 [trans]: https://github.com/mozilla/rust/pull/7124 From remifontan at yahoo.fr Sat Jun 15 17:06:20 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sun, 16 Jun 2013 12:06:20 +1200 Subject: [rust-dev] function overloading In-Reply-To: References: Message-ID: that's great. thanks. I tried the following, but unsuccessfully. struct Vec { x:float, y:float } trait VecRhs { fn add_to_Vec(&self, lhs: &Vec) -> Vec; } impl Add for Vec { fn add(&self, rhs: &VecRhs) -> Vec { rhs.add_to_Vec(self) } } impl VecRhs for float { fn add_to_Vec(&self, lhs: &Vec) -> Vec { Vec{x:lhs.x+*self, y:lhs.x+*self}; } } I get the following errors: rustc test.rs -o test-test --test test.rs:50:14: 50:20 error: reference to trait `VecRhs` where a type is expected; try `@VecRhs`, `~VecRhs`, or `&VecRhs` test.rs:50 impl Add for Vec { ^~~~~~ test.rs:51:4: 53:5 error: method `add` has an incompatible type: expected &-ptr but found trait VecRhs test.rs:51 fn add(&self, rhs: &VecRhs) -> Vec { test.rs:52 rhs.add_to_Vec(self) test.rs:53 } error: aborting due to 2 previous errors make: *** [test-test] Error 101 I feel sorry to ask so many newbies questions. I would really like to go past the first learning curve and proceed to my initial project. thanks for your help. R?mi On Sun, Jun 16, 2013 at 1:15 AM, Benjamin Striegel wrote: > This blog post describes how you would achieve this: > > > http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/ > > See the section entitled "What if I want overloading?" > > > On Sat, Jun 15, 2013 at 5:52 AM, R?mi Fontan wrote: > >> Hi, >> >> I read that rust does not handle function overloading. So I seek your >> advise to how I should be handling the following case. >> >> I have a struct vec2d, which is a 2d vector. vec2d{x:float, y:float} >> >> I would like to implement the trait Mul such that I can multiply a vector >> by another vector, component by component >> >> let v1: Vec2d = ...; >> let v2: Vec2d = ...; >> v1*v2; >> >> but I also would like to be able to multiply a vec2d with a scalar. >> let v3 = v1*-1f; >> >> I tried implementing the trait Mul twice but the compiler complains. How >> would you do it? >> >> cheers, >> >> R?mi >> >> >> -- >> R?mi Fontan : remifontan at yahoo.fr >> mobile: +64 21 855 351 >> 93 Otaki Street, Miramar 6022 >> Wellington, New Zealand >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsteinbr at gmail.com Sat Jun 15 18:18:18 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Sun, 16 Jun 2013 03:18:18 +0200 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130615184644.GB18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> <51BCB3A8.20901@mozilla.com> <20130615184644.GB18699@atjola.homenet> Message-ID: <20130616011818.GD18699@atjola.homenet> On 2013.06.15 20:46:44 +0200, Bj?rn Steinbrink wrote: > On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote: > > On 15/06/2013 10:09 AM, Bj?rn Steinbrink wrote: > > > > >This seems to be due to the landing pads for the function calls. Each > > >contains one more call to drop, so the code grows quadratically with the > > >number of allocations. > > > > Yes. Last time I was in the landing pad code (on the return-unwind > > branch) I was concerned that this was happening. I deferred a fix > > because we were in "get it working" mode. I suggest anyone wanting > > to help attack that first and foremost. > > Seems interesting, I'll give it a shot. OK, so I have a hackish version [1] that "mostly" handles growing landing pads within a single scope (in nested scopes, the parent cleanup blocks are already reused). "Mostly" because there seems to be some problem with e.g. ~int. Consecutive "let x = ~5" lines don't create chained cleanup blocks, yet. This is probably because of some temporary cleanups, as the shrinking of the cleanup vector isn't adjusted yet as still forces the creation of a completely new landing pad. I'll look into that tomorrow. The results so far are very promising, though. Compile time for librustc drops from ~2:35 to ~2:20, the size of mk_ctxt drops from 127180 to 63738 and librustc itself drops from 15294384 to 14901376. Bj?rn [1] https://github.com/dotdash/rust/commit/e736b567bdfdb44da2436b5b079356d79321b3e6 From pwalton at mozilla.com Sat Jun 15 18:50:34 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 15 Jun 2013 18:50:34 -0700 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130616011818.GD18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> <51BCB3A8.20901@mozilla.com> <20130615184644.GB18699@atjola.homenet> <20130616011818.GD18699@atjola.homenet> Message-ID: <51BD19EA.9080504@mozilla.com> On 6/15/13 6:18 PM, Bj?rn Steinbrink wrote: > OK, so I have a hackish version [1] that "mostly" handles growing > landing pads within a single scope (in nested scopes, the parent cleanup > blocks are already reused). "Mostly" because there seems to be some > problem with e.g. ~int. Consecutive "let x = ~5" lines don't create > chained cleanup blocks, yet. This is probably because of some temporary > cleanups, as the shrinking of the cleanup vector isn't adjusted yet as > still forces the creation of a completely new landing pad. I'll look > into that tomorrow. > > The results so far are very promising, though. Compile time for librustc > drops from ~2:35 to ~2:20, the size of mk_ctxt drops from 127180 > to 63738 and librustc itself drops from 15294384 to 14901376. Excellent! A 10% performance win is great at this stage. Patrick From ben.striegel at gmail.com Sat Jun 15 20:14:29 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Sat, 15 Jun 2013 23:14:29 -0400 Subject: [rust-dev] function overloading In-Reply-To: References: Message-ID: Here's how you would make that work: https://gist.github.com/bstrie/5790616 Don't be afraid to ask questions! :) On Sat, Jun 15, 2013 at 8:06 PM, R?mi Fontan wrote: > that's great. thanks. > > I tried the following, but unsuccessfully. > > > struct Vec { > x:float, y:float > } > > trait VecRhs { > fn add_to_Vec(&self, lhs: &Vec) -> Vec; > } > > > impl Add for Vec { > fn add(&self, rhs: &VecRhs) -> Vec { > rhs.add_to_Vec(self) > } > } > > impl VecRhs for float { > fn add_to_Vec(&self, lhs: &Vec) -> Vec { > Vec{x:lhs.x+*self, y:lhs.x+*self}; > } > } > > I get the following errors: > rustc test.rs -o test-test --test > test.rs:50:14: 50:20 error: reference to trait `VecRhs` where a type is > expected; try `@VecRhs`, `~VecRhs`, or `&VecRhs` > test.rs:50 impl Add for Vec { > ^~~~~~ > test.rs:51:4: 53:5 error: method `add` has an incompatible type: > expected &-ptr but found trait VecRhs > test.rs:51 fn add(&self, rhs: &VecRhs) -> Vec { > test.rs:52 rhs.add_to_Vec(self) > test.rs:53 } > error: aborting due to 2 previous errors > make: *** [test-test] Error 101 > > I feel sorry to ask so many newbies questions. I would really like to go > past the first learning curve and proceed to my initial project. > > thanks for your help. > > R?mi > > > > On Sun, Jun 16, 2013 at 1:15 AM, Benjamin Striegel > wrote: > >> This blog post describes how you would achieve this: >> >> >> http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/ >> >> See the section entitled "What if I want overloading?" >> >> >> On Sat, Jun 15, 2013 at 5:52 AM, R?mi Fontan wrote: >> >>> Hi, >>> >>> I read that rust does not handle function overloading. So I seek your >>> advise to how I should be handling the following case. >>> >>> I have a struct vec2d, which is a 2d vector. vec2d{x:float, y:float} >>> >>> I would like to implement the trait Mul such that I can multiply a >>> vector by another vector, component by component >>> >>> let v1: Vec2d = ...; >>> let v2: Vec2d = ...; >>> v1*v2; >>> >>> but I also would like to be able to multiply a vec2d with a scalar. >>> let v3 = v1*-1f; >>> >>> I tried implementing the trait Mul twice but the compiler complains. How >>> would you do it? >>> >>> cheers, >>> >>> R?mi >>> >>> >>> -- >>> R?mi Fontan : remifontan at yahoo.fr >>> mobile: +64 21 855 351 >>> 93 Otaki Street, Miramar 6022 >>> Wellington, New Zealand >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsteinbr at gmail.com Sun Jun 16 09:15:22 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Sun, 16 Jun 2013 18:15:22 +0200 Subject: [rust-dev] code generation and rustc speed In-Reply-To: <20130616011818.GD18699@atjola.homenet> References: <51BC2548.7010400@mozilla.com> <20130615170922.GA18699@atjola.homenet> <51BCB3A8.20901@mozilla.com> <20130615184644.GB18699@atjola.homenet> <20130616011818.GD18699@atjola.homenet> Message-ID: <20130616161522.GE18699@atjola.homenet> On 2013.06.16 03:18:18 +0200, Bj?rn Steinbrink wrote: > On 2013.06.15 20:46:44 +0200, Bj?rn Steinbrink wrote: > > On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote: > > > On 15/06/2013 10:09 AM, Bj?rn Steinbrink wrote: > > > > > > >This seems to be due to the landing pads for the function calls. Each > > > >contains one more call to drop, so the code grows quadratically with the > > > >number of allocations. > > > > > > Yes. Last time I was in the landing pad code (on the return-unwind > > > branch) I was concerned that this was happening. I deferred a fix > > > because we were in "get it working" mode. I suggest anyone wanting > > > to help attack that first and foremost. > > > > Seems interesting, I'll give it a shot. > > OK, so I have a hackish version [1] that "mostly" handles growing > landing pads within a single scope (in nested scopes, the parent cleanup > blocks are already reused). "Mostly" because there seems to be some > problem with e.g. ~int. Consecutive "let x = ~5" lines don't create > chained cleanup blocks, yet. This is probably because of some temporary > cleanups, as the shrinking of the cleanup vector isn't adjusted yet as > still forces the creation of a completely new landing pad. I'll look > into that tomorrow. It was indeed a temporary for which the cleanup revocation dropped the caching. I handle that case now, which removes another ~200KB from librustc. PR is at https://github.com/mozilla/rust/pull/7186 Bj?rn From niko at alum.mit.edu Sun Jun 16 11:28:53 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 16 Jun 2013 14:28:53 -0400 Subject: [rust-dev] Proposal for function objects In-Reply-To: References: Message-ID: <20130616182853.GH2162@Mr-Bennet> First off, sorry for the delayed response. Busy. I think it would be great to have a trait that means "something callable". This is basically overriding the "call operator". The biggest hurdle to such a thing is the fact that lifetimes can only be bound on `fn` types right now. To achieve parity, we'd have to allow lifetime binders on trait refs (meaning objcets and type parameter bounds). I haven't thought a lot about this except to say that it we did permit it, it would address some other issues that arise elsewhere, for example in conditions (which basically are trying to emulate fn types using closures). The main thing is that there would be no way using the current trait system to encode a type like `fn<'a>(&'a uint) -> &'a uint`. Imagine we had a trait like trait Fn { fn call(&mut self, arg: A) -> R; } To be the equivalent of the fn type `fn<'a>(&'a uint) -> &'a uint`, we'd need some way to say "the argument and return type can be references with any lifetime so long 'a as it's the same". We don't currently have a way to express that. Note that a type like `Fn<&'a uint, &'a uint>` doesn't mean quite the same thing: it does say that both the argument and return type have the same lifetime (`'a`), but here `'a` is referring to some lifetime that is in scope, rather than referring to a lifetime that vary from call to call. It's precisely the distinction between `fn foo(x: T) -> T` vs `fn foo(x: T) -> T`. To address this, perhaps we might permit one to write `<'a> Fn<&'a uint, &'a uint>` to express the equivalent of that fn type. Here the leading `<'a>` binds the lifetime name `'a` so that this type means "takes an argument and return type with some lifetime 'a" rather than "...with *the* lifetime 'a". In theoretical terms, this is a kind of `forall` type (we could also write `forall 'a. Fn<...>`). I haven't thought especially hard about this. We have to be careful not to violate soundness, naturally. I imagine if we limited lifetime binders to trait references, we could still have the conversion from bound lifetimes to concrete names be implicit, for example upon access to a trait member (e.g., when you write `f.call(...)`, much like the bound lifetimes on a closure are instantiated when you call it with `f(...)`). All in all, I think it'd be worthwhile to do something like this, but I had hoped to defer it until later, since there are still some number of implementation issues to address with the current type rules. Niko On Wed, Jun 12, 2013 at 07:11:25PM +0100, Amanieu d'Antras wrote: > Hi, > > I've been working on a proposal to unify Rust's closure type with > traits. The idea is based on C++ function objects, which allow any > object which implements the function call operator to be callable. > > The full proposal is at: > https://github.com/mozilla/rust/wiki/Proposal-for-function-objects > > I would appreciate any feedback you may have. > > Amanieu > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From zo1980 at gmail.com Sun Jun 16 12:34:58 2013 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Sun, 16 Jun 2013 21:34:58 +0200 Subject: [rust-dev] The 'for' syntax for iterators In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 7:25 PM, Tim Chevalier wrote: > I found using higher-order functions > directly to be much more natural > So true. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Mon Jun 17 06:45:53 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Mon, 17 Jun 2013 09:45:53 -0400 Subject: [rust-dev] function overloading In-Reply-To: References: Message-ID: > thanks. that worked. > > so my mistake was to use a trait instead of a type in the generic call? instead of Add Add > > impl Add for Vec { > fn add(&self, rhs: &R) -> Vec { > rhs.add_to_Vec(self) > } > } > > > so now I need to implement VecRhs for each type I need function overloading for. if I want to implement it for every > real, could I write something like this? > > impl VecRhs for T { > fn add_to_Vec(&self, lhs: &Vec) -> Vec { > Vec { x:lhs.x+ *self as float, y:lhs.y+*self as float } > } > } > > > cheers, > > R?mi Sadly I don't think we have a trait right now that captures all floating-point types. You'll need to have one impl block for float, f32, and f64. However, you can avoid code duplication here by using macros: macro_rules! float_impl( ($foo:ty) => ( impl VecRhs for $foo { fn add_to_Vec(&self, lhs: &Vec) -> Vec { Vec { x:lhs.x+ *self as float, y:lhs.y+*self as float } } } ) ) float_impl!(float) float_impl!(f32) float_impl!(f64) The above will generate the necessary impl block for each type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Mon Jun 17 11:03:25 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 17 Jun 2013 11:03:25 -0700 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: References: , <51B23F5D.7050103@mozilla.com> Message-ID: <51BF4F6D.5070806@mozilla.com> Sorry for the slow reply, I did mean to get back to this: On 13-06-07 02:25 PM, Bill Myers wrote: >> Every >> single reviewer I showed a "no cycles" variant of rust to told me >> it was unacceptable and they would walk away from a language that >> prohibited cycles in all cases. All of them. We tried limiting it >> within subsets of the type system rather than pervasively: it still >> irritated and confused everyone. > > Interesting, are these versions online anywhere? No. They'd be in ocaml and many ages ago. I might be able to dig up a source dir but it'd be meaningless by today's standards. The last version I bothered shopping around used a simpler rule than anything we've looked at in this thread: @ just always meant acyclic and RC. The compiler would reject any mutable recursive-typed @ edges, and we were careful that enum was the only way you could introduce ownership recursion. This rule was ... not popular :) > True, in fact fragmentation might be as bad or worse as the dead objects > living on in GC. Possibly. One can synthesize benchmarks that show either thing. I tend to support your belief that tracing-GC resident set will be larger and more cache unfriendly than (say) RC. But I also know that for browsers, code size, fragmentation over days-long browsing sessions, and especially cycle formation and collection are all real issues too. >> We tried this; various strategies for it. Ownership cycles even just >> within subtrees of well-organized ownership trees are not a rare >> occurrence. They are a result both of normal patterns within common data >> structures, and normal levels of coupling between subsystems in large >> applictions. Especially web browsers. > > How about, however, something like (hypotetically) rewriting the Linux > kernel in Rust? (with limited amounts of unsafe code) I think it's a bit unfair that in your example, you insist on wanting fine-grained global RW locks, when in fact linux has been systematically backing away from those in favour of RCU. Indeed, the docs on the RW locks[1] say: NOTE! We are working hard to remove reader-writer spinlocks in most cases, so please don't add a new one without consensus. (Instead, see Documentation/RCU/rcu.txt for complete information.) RCU, as you know, is very different, and .. I actually don't know if it's easy to encode in rust's current rules or not. But I think it's neither helped by the rules you were proposing either. I think kernels are dealing with way more complication than we can encode into any set of rules: weird IO memory mappings and barrier rules[2], per-CPU structures, interrupt safety, custom allocators and lifetime patterns, all sorts of stuff that we can't handle "optimally". I would expect a kernel written in rust to involve a lot of looking at our type system for tools-that-might-help, but ultimately when facing a performance-vs-safety trade, or a hardware-reality-vs-rust-types trade, to go with performance and reality, and larger blocks of supporting "unsafe" code they've reasoned carefully about. That's what they do now and, somehow, they manage to code with a level of attention-to-detail and minimalism wherein it seems to mostly work. -Graydon [1] https://www.kernel.org/doc/Documentation/spinlocks.txt [2] https://www.kernel.org/doc/Documentation/memory-barriers.txt From graydon at mozilla.com Mon Jun 17 17:57:45 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 17 Jun 2013 17:57:45 -0700 Subject: [rust-dev] tree maintenance Message-ID: <51BFB089.8020507@mozilla.com> Hi, As part of preparation for 0.7 (due around the end of june / early july) we're going to be closing the tree for a while, fixing the lingering breakage that's snuck through 'auto' and accumulated on 'master', and greatly widening the 'auto' coverage such that this stuff doesn't build up anymore. For now, bors is turned off and the tree is closed. Fear not though: this should ultimately improve life for everyone. More coverage, better differential testing, less chasing ghosts. Thanks for your patience. It'll be back asap (along with a snapshot!) -Graydon From thadguidry at gmail.com Mon Jun 17 18:21:48 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Mon, 17 Jun 2013 20:21:48 -0500 Subject: [rust-dev] tree maintenance In-Reply-To: <51BFB089.8020507@mozilla.com> References: <51BFB089.8020507@mozilla.com> Message-ID: Nice. Will there also be a Snapshot for 64 bit Windows ? On Mon, Jun 17, 2013 at 7:57 PM, Graydon Hoare wrote: > Hi, > > As part of preparation for 0.7 (due around the end of june / early july) > we're going to be closing the tree for a while, fixing the lingering > breakage that's snuck through 'auto' and accumulated on 'master', and > greatly widening the 'auto' coverage such that this stuff doesn't build > up anymore. > > For now, bors is turned off and the tree is closed. Fear not though: > this should ultimately improve life for everyone. More coverage, better > differential testing, less chasing ghosts. > > Thanks for your patience. It'll be back asap (along with a snapshot!) > > -Graydon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Tue Jun 18 08:28:01 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 18 Jun 2013 08:28:01 -0700 Subject: [rust-dev] tree maintenance In-Reply-To: References: <51BFB089.8020507@mozilla.com> Message-ID: <51C07C81.7090800@mozilla.com> On 13-06-17 06:21 PM, Thad Guidry wrote: > Nice. > > Will there also be a Snapshot for 64 bit Windows ? Unfortunately nobody has spent the requisite time to enable the mingw-w64 port yet. I saw some rumblings of it but there's no support in-tree for it yet. Similarly, no support for clang-only win32/64 nor msvc32/64. When there's support for any of these variants, yes, absolutely. -Graydon From thadguidry at gmail.com Tue Jun 18 08:33:27 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 18 Jun 2013 10:33:27 -0500 Subject: [rust-dev] tree maintenance In-Reply-To: <51C07C81.7090800@mozilla.com> References: <51BFB089.8020507@mozilla.com> <51C07C81.7090800@mozilla.com> Message-ID: On Tue, Jun 18, 2013 at 10:28 AM, Graydon Hoare wrote: > On 13-06-17 06:21 PM, Thad Guidry wrote: > >> Nice. >> >> Will there also be a Snapshot for 64 bit Windows ? >> > > Unfortunately nobody has spent the requisite time to enable the mingw-w64 > port yet. I saw some rumblings of it but there's no support in-tree for it > yet. Similarly, no support for clang-only win32/64 nor msvc32/64. > > Right, OK, I remember that I should be trying to spend some time with getting a mingw-w64 port. (My Cygwin adventures had detoured towards that) So, I probably need to go back and work my way up that food chain (tool chain) again but with my (now working properly and documented on the wiki now...) MinGW installation. > When there's support for any of these variants, yes, absolutely. > > OK, so if I pull off a nice port to enable mingw-w64 then you (we) will support it as a Snapshot. Gotcha. Thanks, -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Tue Jun 18 10:06:27 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Tue, 18 Jun 2013 19:06:27 +0200 Subject: [rust-dev] On tunable Garbage Collection Message-ID: Hi, I was reading with interest the proposal on library-defined garbage collection (by use of dedicated types), and I have a couple of questions. My main worry, and thus question, is how to handle cross-scheme cycles ? There does not seem to be anything preventing me to have a Rc reference a Gc (and vice-versa), and I am wondering how garbage collectors are supposed to cooperate to realize that those may be dead cycles to collect. As such, I am wondering if despite being neat (and highly tunable) users might not be satisfied with a simpler scheme. It seems to me that lifetime already provide natural GC boundaries (they at least provide an upper-bound of the lifetime of the object) and thus that maybe it may be more natural to attach a gc to a lifetime (or set of lifetimes) rather than to a particular object ? I was thinking of something like: #pragma gc ReferenceCountingGC fn somefunction(s: String) -> Int Note that in the latter case Rust would retain the @ sigil to denote garbage collected pointers but depending on where the object was allocated the @ would not refer to the same garbage collector. I have, obviously, no idea whether this would actually practical; and it might not! -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Tue Jun 18 10:52:19 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 18 Jun 2013 10:52:19 -0700 Subject: [rust-dev] On tunable Garbage Collection In-Reply-To: References: Message-ID: <51C09E53.2020205@mozilla.com> On 13-06-18 10:06 AM, Matthieu Monrocq wrote: > Hi, > > I was reading with interest the proposal on library-defined garbage > collection (by use of dedicated types), and I have a couple of questions. > > My main worry, and thus question, is how to handle cross-scheme cycles ? > There does not seem to be anything preventing me to have a Rc > reference a Gc (and vice-versa), and I am wondering how garbage > collectors are supposed to cooperate to realize that those may be dead > cycles to collect. There are 3 options that I'm aware of: - Teach the GC to traverse foreign graphs, like the XPCOM CC does - Statically prohibit such constructs - Leak cycles and put a warning up I don't have a strong preference. Maybe a minor preference for statically preventing it (eg. a NonManaged bound, such as Daniel was suggesting we add to help support the Rc<> type yesterday). > As such, I am wondering if despite being neat (and highly tunable) users > might not be satisfied with a simpler scheme. It seems to me that > lifetime already provide natural GC boundaries (they at least provide an > upper-bound of the lifetime of the object) and thus that maybe it may be > more natural to attach a gc to a lifetime (or set of lifetimes) rather > than to a particular object ? I don't really know how this would work out. There might be something in there that would work, but it'd require some more-detailed proposal. I can't quite see it myself. -Graydon From bill_myers at outlook.com Tue Jun 18 11:51:09 2013 From: bill_myers at outlook.com (Bill Myers) Date: Tue, 18 Jun 2013 18:51:09 +0000 Subject: [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers In-Reply-To: <51BF4F6D.5070806@mozilla.com> References: , <51B23F5D.7050103@mozilla.com> , <51BF4F6D.5070806@mozilla.com> Message-ID: > > How about, however, something like (hypotetically) rewriting the Linux > > kernel in Rust? (with limited amounts of unsafe code) > > I think it's a bit unfair that in your example, you insist on wanting > fine-grained global RW locks, when in fact linux has been systematically > backing away from those in favour of RCU. Indeed, the docs on the RW > locks[1] say: > NOTE! We are working hard to remove reader-writer spinlocks in most > cases, so please don't add a new one without consensus. (Instead, > see Documentation/RCU/rcu.txt for complete information.) > > RCU, as you know, is very different, and .. I actually don't know if > it's easy to encode in rust's current rules or not. But I think it's > neither helped by the rules you were proposing either. Well, in many cases RCU is just used on data structures, so a special RcuList, RcuHashTable, etc. implemented with unsafe code would probably do the job. > I think kernels are dealing with way more complication than we can > encode into any set of rules: weird IO memory mappings and barrier > rules[2], per-CPU structures, interrupt safety, custom allocators and > lifetime patterns, all sorts of stuff that we can't handle "optimally". > I would expect a kernel written in rust to involve a lot of looking at > our type system for tools-that-might-help, but ultimately when facing a > performance-vs-safety trade, or a hardware-reality-vs-rust-types trade, > to go with performance and reality, and larger blocks of supporting > "unsafe" code they've reasoned carefully about. That's what they do now > and, somehow, they manage to code with a level of attention-to-detail > and minimalism wherein it seems to mostly work. Yes, although most of those specific issues can probably be isolated in snippets of unsafe code. However, it's enough to consider the kernel as an implementation of POSIX file system calls using a RAM disk to have a broader issue: the natural and simplest way to express it in current Rust is a "filesystem task" accessing task-local data implemented with garbage collected @ boxes, but that would have equivalent serialization and thus performance to a big kernel lock. Otherwise, one needs multiple tasks concurrently mutating shared objects, which requires either global GC or global reference counting that needs both the ability to nest mutable pointers in ways that are statically acyclic due to their types, and probably some sort of mutable RcTree class that would allow reparenting with O(tree_height) checks of acyclicity (like Linux VFS does manually for rename on directories). BTW, there is in fact a probably better way than what I originally proposed to do more general acyclic reference counting: 1. Add a DoesntStronglyPointTo kind (with a shorter name) that would allow to declare RcMut as RcMut>>, and would have the compiler check that there is no sequence of non-weak-reference pointers going from T to RcMut 2. Enhance RcMut to RcMut>, that would hold a (T, U) pair, allow to get a &(T, U) pointer while reading, but only a (&T, &mut U) pointer pair when writing, making T immutable and U mutable 3. Add RcList, RcTree for those structures (and RWARC versions) Then, one would put the cyclic pointers in the T part, which would be OK since they are immutable, and put everything acyclic in the U part with the DoesntStronglyPointTo bound checking that it's indeed acyclic. This avoids the magic of having the compiler infer which pointers can be allowed to mutate, instead having the user indicate them and the compiler give an error if the user gets it wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Tue Jun 18 12:07:13 2013 From: bill_myers at outlook.com (Bill Myers) Date: Tue, 18 Jun 2013 19:07:13 +0000 Subject: [rust-dev] On tunable Garbage Collection In-Reply-To: <51C09E53.2020205@mozilla.com> References: , <51C09E53.2020205@mozilla.com> Message-ID: For Rc<>, it should be enough to have the GC traverse raw pointers that have/don't have a special attribute (probably traversing by default is the best choice), as long as the raw pointers have the correct type. Obviously it only makes sense to traverse types if it is possible for them to point to GC pointers. For data held exclusively by external C libraries (assuming that there is any), an unsafe GcVisitor trait that can be implemented to do the visit should work, along with a NonGc kind for code that doesn't want to implement GcVisitor (otherwise, mark&sweep GC would kill live objects). -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Tue Jun 18 13:13:15 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 18 Jun 2013 13:13:15 -0700 Subject: [rust-dev] On tunable Garbage Collection In-Reply-To: References: , <51C09E53.2020205@mozilla.com> Message-ID: <51C0BF5B.1030301@mozilla.com> On 13-06-18 12:07 PM, Bill Myers wrote: > For Rc<>, it should be enough to have the GC traverse raw pointers that > have/don't have a special attribute (probably traversing by default is > the best choice), as long as the raw pointers have the correct type. > > Obviously it only makes sense to traverse types if it is possible for > them to point to GC pointers. Oh, oops, yes, of course. I must have been confused writing my previous reply. Currently this should already work: the presence of @ in an Rc<@foo> struct, like in any struct, will cause the Rc part to be considered "managed-unique" and allocated in the local heap, traced-through during collection. This was the first bug I fixed on the path to getting GC working. You might not _want_ that, if you're using Rc to "avoid GC", but that's up to you to avoid instantiating Rc<@foo>. If you do so, it should automatically participate in GC like any other managed-unique stuff. -Graydon From fedor at indutny.com Wed Jun 19 03:50:55 2013 From: fedor at indutny.com (Fedor Indutny) Date: Wed, 19 Jun 2013 12:50:55 +0200 Subject: [rust-dev] Generic block Message-ID: Hi all! I'm trying to add more generics to my library to replace internal uints with user-supplied enums, but, while possible using current language tools, I found it really complicated and hard to support. What if instead of attributing every trait and every struct with and respectively, rust will support following language struct: generic { /// code } Its mostly a syntax sugar, but it'd help a lot. Thoughts? Cheers, Fedor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeaye at arrownext.com Wed Jun 19 08:49:55 2013 From: jeaye at arrownext.com (Jeaye) Date: Wed, 19 Jun 2013 08:49:55 -0700 Subject: [rust-dev] Generic block In-Reply-To: References: Message-ID: <51C1D323.5060605@arrownext.com> On 06/19/2013 03:50 AM, Fedor Indutny wrote: > Hi all! > > I'm trying to add more generics to my library to replace internal > uints with user-supplied enums, but, while possible using current > language tools, I found it really complicated and hard to support. > > What if instead of attributing every trait and every struct with T1, S2: T2...> and respectively, rust will support following > language struct: > > generic { > > /// code > > } > > Its mostly a syntax sugar, but it'd help a lot. Thoughts? > > Cheers, > Fedor. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev This seems entirely possible with macros, which are likely going to be the suggested route. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed Jun 19 13:01:19 2013 From: corey at octayn.net (Corey Richardson) Date: Wed, 19 Jun 2013 16:01:19 -0400 Subject: [rust-dev] rustdoc rewrite and redesign Message-ID: I am going to rewrite and redesign rustdoc. Current bikeshed: https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc Please discuss, give me your feature requests, comments, etc. From masklinn at masklinn.net Wed Jun 19 13:32:29 2013 From: masklinn at masklinn.net (Masklinn) Date: Wed, 19 Jun 2013 22:32:29 +0200 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: On 2013-06-19, at 22:01 , Corey Richardson wrote: > I am going to rewrite and redesign rustdoc. Current bikeshed: > > https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc > > Please discuss, give me your feature requests, comments, etc. This is "just" the data extraction from rust source, then a separate-ish TBD backend would turn it into markup for either use or further processing (e.g. a markdown/pandoc generator for the current one, some sort of autorustdoc for sphinx integration, ?) correct? From lindsey at composition.al Wed Jun 19 14:02:09 2013 From: lindsey at composition.al (Lindsey Kuper) Date: Wed, 19 Jun 2013 17:02:09 -0400 Subject: [rust-dev] rusti: a call to action In-Reply-To: References: Message-ID: On Wed, May 8, 2013 at 10:22 PM, Lindsey Kuper wrote: > On Tue, May 7, 2013 at 12:01 AM, James Tranovich > wrote: >> Just wondering what the general plan of attack was and if there was anything >> I could do to help. > > We have a plan to make a plan, but no plan yet. But an obvious > problem that we can do something about at the moment is that there are > no tests for rusti (https://github.com/mozilla/rust/issues/5469), > which astrieanna and I are (slowly) working on fixing. Just leaving a note for future rust-dev thread archaeologists. My plan to work on rusti ran out of steam rather quickly, and it doesn't look as though I'll have time in the near future, either. I unassigned myself from the bug I was on. But in the meantime, rusti was rewritten entirely (which was probably necessary anyway), and there are now some tests, so I think it's fair to say the situation has improved a lot. Cheers. Lindsey From corey at octayn.net Wed Jun 19 15:11:33 2013 From: corey at octayn.net (Corey Richardson) Date: Wed, 19 Jun 2013 18:11:33 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: On Wed, Jun 19, 2013 at 4:32 PM, Masklinn wrote: > On 2013-06-19, at 22:01 , Corey Richardson wrote: > >> I am going to rewrite and redesign rustdoc. Current bikeshed: >> >> https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc >> >> Please discuss, give me your feature requests, comments, etc. > > This is "just" the data extraction from rust source, then a separate-ish > TBD backend would turn it into markup for either use or further processing > (e.g. a markdown/pandoc generator for the current one, some sort of > autorustdoc for sphinx integration, ?) correct? > No. It is all a part of rustdoc, it's just a more modular design. From slabode at aim.com Wed Jun 19 18:04:49 2013 From: slabode at aim.com (SiegeLord) Date: Wed, 19 Jun 2013 21:04:49 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: <51C25531.4000808@aim.com> On 06/19/2013 04:01 PM, Corey Richardson wrote: > Please discuss, give me your feature requests, comments, etc. I am unclear why the XML/JSON is part of the parsing/extraction step, it seems like it's on the same level as the generator step. I.e. after the parser/extractor/filter do their thing, the XML generator will take the internal representation and create an XML file for external tools to do what they want with, just like is done with Markdown for pandoc. I don't see what good the XML is with all the extra indentation that is only removed a step below, but without useful things like the brief descriptions. Speaking of brief descriptions... this might not be a concept that is universal to all generators (e.g. sphinx doesn't seem to use them). I'm not sure what differentiates the filter step from the extraction step. Is it meant to be done in parallel while the rest is done serially? Overall it's not clear which steps are to be done in parallel (which should be expanded upon, as it seems to be one of the main motivations behind this). Overall I guess what I'm really not clear about is how this is different than what is done today design-wise (aside from the multiple backends bit). It seems to me to be mostly a refactoring effort. -SL From corey at octayn.net Wed Jun 19 18:52:44 2013 From: corey at octayn.net (Corey Richardson) Date: Wed, 19 Jun 2013 21:52:44 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C25531.4000808@aim.com> References: <51C25531.4000808@aim.com> Message-ID: On Wed, Jun 19, 2013 at 9:04 PM, SiegeLord wrote: > On 06/19/2013 04:01 PM, Corey Richardson wrote: > >> Please discuss, give me your feature requests, comments, etc. > > > I am unclear why the XML/JSON is part of the parsing/extraction step, it > seems like it's on the same level as the generator step. I.e. after the > parser/extractor/filter do their thing, the XML generator will take the > internal representation and create an XML file for external tools to do what > they want with, just like is done with Markdown for pandoc. I don't see what > good the XML is with all the extra indentation that is only removed a step > below, but without useful things like the brief descriptions. Speaking of > brief descriptions... this might not be a concept that is universal to all > generators (e.g. sphinx doesn't seem to use them). > Brief descriptions would be ancillary data, optional for a backend to use. For certain outputs that filter wouldn't even be included if it doesn't make sense. > I'm not sure what differentiates the filter step from the extraction step. > Is it meant to be done in parallel while the rest is done serially? Overall > it's not clear which steps are to be done in parallel (which should be > expanded upon, as it seems to be one of the main motivations behind this). > So here is a diagram of what I envision happening: https://gist.github.com/cmr/5819695 At any point, rustdoc can stop and barf out a XML/JSON document(s). Otherwise it's all in its internal representation. Filter order will be configurable (similar to how rustc currently accepts a --passes argument for llvm optimization passes) > Overall I guess what I'm really not clear about is how this is different > than what is done today design-wise (aside from the multiple backends bit). > It seems to me to be mostly a refactoring effort. > brson said he had ideas and would review my proposal. I've only been using rust for the past ~month, and I never worked on rustdoc before, so I don't know how sane it is or if there is a better thing to use. From banderson at mozilla.com Thu Jun 20 16:30:35 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 20 Jun 2013 16:30:35 -0700 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: <51C3909B.4090101@mozilla.com> On 06/19/2013 01:01 PM, Corey Richardson wrote: > I am going to rewrite and redesign rustdoc. Current bikeshed: > > https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc > > Please discuss, give me your feature requests, comments, etc. > This is great news. Here are my thoughts about rustdoc: the next generation. The most important thing is the presentation - does rustdoc give me the information I need, and is it easy to understand and navigate? I'll propose that the only output format that matters is HTML, so focus on that. I strongly suggest approaching a rustdoc redesign with an upfront UI design phase. Create an HTML mockup that illustrates an attractive way to present Rust, iterate on community feedback, then build the tool to fill in the content. When rustdoc was originally written the Rust AST was much simpler. Everything was an 'item', so I figured "we'll just display a tree of items - no sweat". Shortly after Rust 0.1 of course the AST became much more nuanced and this model fell apart. There are a few tricky bits that rustdoc doesn't do right and that must be solved in a successful rewrite. Firstly, impls and their relationships to traits must be captured in an intuitive way. The current presentation is atrocious. I'd suggest that the way to do this is, for each type, provide a list of trait implementations with links back to the trait definition. The other major deficiency in rustdoc is with reexports - they are just not surfaced by rustdoc in any way. This could probably be treated similarly to impls, with each module listing the reexports with a link to the original definition. The big, big problem with both these things is that to do them right requires running resolve. Running resolve to produce documentation though is not generally possible because it requires upstream crates to already be compiled. My preference here is for rustdoc to implement it's own, much more limited, resolve pass, possibly resorting to heuristics in some cases. I suspect that a sufficiently educated guess will usually get the answer right. Where resolution fails we can maybe use attributes to give rustdoc more hints. Patrick disagrees with me on this. Regarding HTML generation, I think we should not lean on pandoc so heavily. rustdoc currently produces a page of markdown at a time to pass to pandoc. This conversion drops a lot of semantic content on the floor. We should instead output proper semantic HTML that is tailored to Rust and only use a markdown renderer to convert small sections of doc comments to HTML. And finally, a subtle point regarding the architecture: the core data structure in rustdoc is a 'document', which is iterated over and refined through a number of passes. I think this is probably the wrong way to conceptualize this data structure, and instead it should be considered a limited AST + documentation metadata, reflecting the code structure, not the document structure. Only convert it to do document immediately before rendering. From danielmicay at gmail.com Thu Jun 20 16:44:44 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 20 Jun 2013 19:44:44 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C3909B.4090101@mozilla.com> References: <51C3909B.4090101@mozilla.com> Message-ID: On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: > Regarding HTML generation, I think we should not lean on pandoc so heavily. > rustdoc currently produces a page of markdown at a time to pass to pandoc. > This conversion drops a lot of semantic content on the floor. We should > instead output proper semantic HTML that is tailored to Rust and only use a > markdown renderer to convert small sections of doc comments to HTML. We could be making much better use of pandoc since it uses a superset of markdown. For example, with an up-to-date pandoc, the function signatures and code examples get syntax highlighted. http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown Another thing to consider is switching to sphinx and avoiding the pain of doing this all ourselves. Converting our markdown to restructured text would be pretty trivial. From corey at octayn.net Thu Jun 20 16:47:00 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 20 Jun 2013 19:47:00 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C3909B.4090101@mozilla.com> References: <51C3909B.4090101@mozilla.com> Message-ID: On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: > On 06/19/2013 01:01 PM, Corey Richardson wrote: >> >> I am going to rewrite and redesign rustdoc. Current bikeshed: >> >> https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc >> >> Please discuss, give me your feature requests, comments, etc. >> > > This is great news. Here are my thoughts about rustdoc: the next generation. > > [snip] > > The big, big problem with both these things is that to do them right > requires running resolve. Running resolve to produce documentation though is > not generally possible because it requires upstream crates to already be > compiled. > I think this is a problem with rust overall right now, and it's one of the things that a header system allows quite nicely: usage of API declaration without compilation. I'm not sure what the best way to solve this is, though. The best I can come up with is maybe an `.rmd` file that just contains extracted crate metadata, and that there be a rustc mode that allows this. I don't know the exact details of the metadata: maybe someone else could elaborate on what it is, where it comes from, and what it is used for? (This would fit in with my goal of "replace the monstrosity that is ebml"). It might be worth looking into how .NET or other platforms with similar architecture accomplish this, if at all. > My preference here is for rustdoc to implement it's own, much more > limited, resolve pass, possibly resorting to heuristics in some cases. I > suspect that a sufficiently educated guess will usually get the answer > right. Where resolution fails we can maybe use attributes to give rustdoc > more hints. Patrick disagrees with me on this. > When discussing this exact thing with SiegeLord I had the idea of partially implementing a resolve pass, but there are so many problems with it that I don't really see it as desirable. I would really like to run the real resolve code, if possible. > Regarding HTML generation, I think we should not lean on pandoc so heavily. > rustdoc currently produces a page of markdown at a time to pass to pandoc. > This conversion drops a lot of semantic content on the floor. We should > instead output proper semantic HTML that is tailored to Rust and only use a > markdown renderer to convert small sections of doc comments to HTML. > +1, for the general case. Having non-HTML (XML, probably) output is useful for exporting to docbook, or something that can be turned into a PDF (and also for use in IDEs). > And finally, a subtle point regarding the architecture: the core data > structure in rustdoc is a 'document', which is iterated over and refined > through a number of passes. I think this is probably the wrong way to > conceptualize this data structure, and instead it should be considered a > limited AST + documentation metadata, reflecting the code structure, not the > document structure. Only convert it to do document immediately before > rendering. > I'll run with this idea, it seems solid. From banderson at mozilla.com Thu Jun 20 17:58:19 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 20 Jun 2013 17:58:19 -0700 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C3909B.4090101@mozilla.com> Message-ID: <51C3A52B.9040902@mozilla.com> On 06/20/2013 04:47 PM, Corey Richardson wrote: > On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: >> On 06/19/2013 01:01 PM, Corey Richardson wrote: >>> I am going to rewrite and redesign rustdoc. Current bikeshed: >>> >>> https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc >>> >>> Please discuss, give me your feature requests, comments, etc. >>> >> This is great news. Here are my thoughts about rustdoc: the next generation. >> >> [snip] >> >> The big, big problem with both these things is that to do them right >> requires running resolve. Running resolve to produce documentation though is >> not generally possible because it requires upstream crates to already be >> compiled. >> > I think this is a problem with rust overall right now, and it's one of > the things that a header system allows quite nicely: usage of API > declaration without compilation. I'm not sure what the best way to > solve this is, though. The best I can come up with is maybe an `.rmd` > file that just contains extracted crate metadata, and that there be a > rustc mode that allows this. I don't know the exact details of the > metadata: maybe someone else could elaborate on what it is, where it > comes from, and what it is used for? (This would fit in with my goal > of "replace the monstrosity that is ebml"). It might be worth looking > into how .NET or other platforms with similar architecture accomplish > this, if at all. This has the same problem though - the compiler still must be run on upstream crates to produce the metadata. From banderson at mozilla.com Thu Jun 20 18:02:46 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 20 Jun 2013 18:02:46 -0700 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C3909B.4090101@mozilla.com> Message-ID: <51C3A636.70409@mozilla.com> On 06/20/2013 04:44 PM, Daniel Micay wrote: > On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: >> Regarding HTML generation, I think we should not lean on pandoc so heavily. >> rustdoc currently produces a page of markdown at a time to pass to pandoc. >> This conversion drops a lot of semantic content on the floor. We should >> instead output proper semantic HTML that is tailored to Rust and only use a >> markdown renderer to convert small sections of doc comments to HTML. > We could be making much better use of pandoc since it uses a superset > of markdown. For example, with an up-to-date pandoc, the function > signatures and code examples get syntax highlighted. > > http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown > > Another thing to consider is switching to sphinx and avoiding the pain > of doing this all ourselves. Converting our markdown to restructured > text would be pretty trivial. I guess if we're going to switch to sphinx now is the time, but I haven't looked at it. Their web page does make it sound fairly python-centric though. From dbp at riseup.net Thu Jun 20 21:46:38 2013 From: dbp at riseup.net (Daniel Patterson) Date: Fri, 21 Jun 2013 00:46:38 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C3909B.4090101@mozilla.com> References: <51C3909B.4090101@mozilla.com> Message-ID: On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: > And finally, a subtle point regarding the architecture: the core data > structure in rustdoc is a 'document', which is iterated over and refined > through a number of passes. I think this is probably the wrong way to > conceptualize this data structure, and instead it should be considered a > limited AST + documentation metadata, reflecting the code structure, not the > document structure. Only convert it to do document immediately before > rendering. This should also make it much easier to re-use the extraction in other tools - a limited AST + documentation is a really useful structure to work with. I'm thinking specifically of my experiment of producing a Hoogle[1]-like tool that lives at [2]. I experimented with trying to hook into rustdoc at an intermediary stage, but it ended up being easier to write a bad parser on the generated html, because the intermediary data structures weren't all that different - ie, I would have had to parse them too - which is silly. 1. http://www.haskell.org/hoogle/ 2. https://github.com/dbp/rustle From dbau.pp at gmail.com Thu Jun 20 22:28:58 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 21 Jun 2013 15:28:58 +1000 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C3909B.4090101@mozilla.com> Message-ID: <51C3E49A.5020307@gmail.com> Nice! I'd really like Hoogle-like tool for Rust. (Also, using libsyntax to get an AST directly is pretty easy. It was about 3 function calls to get a parsed & macro-expanded AST from a string last time I used it. The tests in libsyntax and/or the first parts of the rustc driver are decent examples.) Huon On 21/06/13 14:46, Daniel Patterson wrote: > On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: >> And finally, a subtle point regarding the architecture: the core data >> structure in rustdoc is a 'document', which is iterated over and refined >> through a number of passes. I think this is probably the wrong way to >> conceptualize this data structure, and instead it should be considered a >> limited AST + documentation metadata, reflecting the code structure, not the >> document structure. Only convert it to do document immediately before >> rendering. > This should also make it much easier to re-use the extraction in other > tools - a limited AST + documentation is a really useful structure to > work with. I'm thinking specifically of my experiment of producing a > Hoogle[1]-like tool that lives at [2]. I experimented with trying to > hook into rustdoc at an intermediary stage, but it ended up being > easier to write a bad parser on the generated html, because the > intermediary data structures weren't all that different - ie, I would > have had to parse them too - which is silly. > > 1. http://www.haskell.org/hoogle/ > 2. https://github.com/dbp/rustle > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From masklinn at masklinn.net Fri Jun 21 02:03:34 2013 From: masklinn at masklinn.net (Masklinn) Date: Fri, 21 Jun 2013 11:03:34 +0200 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: <4395B705-3E41-4030-9D75-C8E4598C6F86@masklinn.net> On 2013-06-20, at 00:11 , Corey Richardson wrote: > On Wed, Jun 19, 2013 at 4:32 PM, Masklinn wrote: >> On 2013-06-19, at 22:01 , Corey Richardson wrote: >> >>> I am going to rewrite and redesign rustdoc. Current bikeshed: >>> >>> https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc >>> >>> Please discuss, give me your feature requests, comments, etc. >> >> This is "just" the data extraction from rust source, then a separate-ish >> TBD backend would turn it into markup for either use or further processing >> (e.g. a markdown/pandoc generator for the current one, some sort of >> autorustdoc for sphinx integration, ?) correct? >> > > No. It is all a part of rustdoc, it's just a more modular design. Then I'd wish for the option to just get a raw-ish stream of language-independent data events (think TAP). From masklinn at masklinn.net Fri Jun 21 02:14:26 2013 From: masklinn at masklinn.net (Masklinn) Date: Fri, 21 Jun 2013 11:14:26 +0200 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C3A636.70409@mozilla.com> References: <51C3909B.4090101@mozilla.com> <51C3A636.70409@mozilla.com> Message-ID: <3D661A4C-F2CC-4D4B-BB98-9BE82D805CE8@masklinn.net> On 2013-06-21, at 03:02 , Brian Anderson wrote: > On 06/20/2013 04:44 PM, Daniel Micay wrote: >> On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: >>> Regarding HTML generation, I think we should not lean on pandoc so heavily. >>> rustdoc currently produces a page of markdown at a time to pass to pandoc. >>> This conversion drops a lot of semantic content on the floor. We should >>> instead output proper semantic HTML that is tailored to Rust and only use a >>> markdown renderer to convert small sections of doc comments to HTML. >> We could be making much better use of pandoc since it uses a superset >> of markdown. For example, with an up-to-date pandoc, the function >> signatures and code examples get syntax highlighted. >> >> http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown >> >> Another thing to consider is switching to sphinx and avoiding the pain >> of doing this all ourselves. Converting our markdown to restructured >> text would be pretty trivial. > > I guess if we're going to switch to sphinx now is the time, but I haven't looked at it. Their web page does make it sound fairly python-centric though. It was created for Python and is developed in Python (so is the underlying docutils library for processing restructuredtext), so the main community using it is the Python community, but sphinx isn't python specific at all. Most of the markup is generic text things, it bundles non-python domains[0] (code coloration uses pygments so it already does way more than just python) and there is an API for creating new domains, you can find examples of such new domains as part of sphinx-contrib[1]. Switching rust's documentation to sphinx would likely require developing a Rust domain so Sphinx can create all the right cross-references, e.g. :func:`str::each` linking to the right place without requiring further efforts by the documentation author. [0] http://sphinx-doc.org/latest/domains.html#the-c-domain [1] https://bitbucket.org/birkenfeld/sphinx-contrib/src From lucian.branescu at gmail.com Fri Jun 21 02:24:00 2013 From: lucian.branescu at gmail.com (Lucian Branescu) Date: Fri, 21 Jun 2013 10:24:00 +0100 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <3D661A4C-F2CC-4D4B-BB98-9BE82D805CE8@masklinn.net> References: <51C3909B.4090101@mozilla.com> <51C3A636.70409@mozilla.com> <3D661A4C-F2CC-4D4B-BB98-9BE82D805CE8@masklinn.net> Message-ID: On 21 June 2013 10:14, Masklinn wrote: > On 2013-06-21, at 03:02 , Brian Anderson wrote: > > On 06/20/2013 04:44 PM, Daniel Micay wrote: > >> On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson wrote: > >> Another thing to consider is switching to sphinx and avoiding the pain > >> of doing this all ourselves. Converting our markdown to restructured > >> text would be pretty trivial. > > > > I guess if we're going to switch to sphinx now is the time, but I haven't looked at it. Their web page does make it sound fairly python-centric though. > > It was created for Python and is developed in Python (so is the > underlying docutils library for processing restructuredtext), so the > main community using it is the Python community, but sphinx isn't python > specific at all. Most of the markup is generic text things, it bundles > non-python domains[0] (code coloration uses pygments so it already does > way more than just python) and there is an API for creating new domains, > you can find examples of such new domains as part of sphinx-contrib[1]. > > Switching rust's documentation to sphinx would likely require developing > a Rust domain so Sphinx can create all the right cross-references, e.g. > :func:`str::each` linking to the right place without requiring further > efforts by the documentation author. FWIW, LLVM switched to Sphinx http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/033737.html From corey at octayn.net Fri Jun 21 04:12:58 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 07:12:58 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C3A52B.9040902@mozilla.com> References: <51C3909B.4090101@mozilla.com> <51C3A52B.9040902@mozilla.com> Message-ID: On Thu, Jun 20, 2013 at 8:58 PM, Brian Anderson wrote: > This has the same problem though - the compiler still must be run on > upstream crates to produce the metadata. > RIght, but hopefully it could be a fast metadata-only pass, or the metadata could be distributed, or somesuch. Half baked idea, maybe not a good one! I haven't looked into it but maybe it's possible to run resolve anyway and just ignore failures? From qwertie256 at gmail.com Fri Jun 21 07:54:43 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Fri, 21 Jun 2013 08:54:43 -0600 Subject: [rust-dev] rustdoc rewrite and redesign Message-ID: > It might be worth looking into how .NET or other platforms with similar > architecture accomplish this, if at all. The C# compiler has a switch that converts C# XML doc comments into an XML file, which is placed in the output folder beside the .DLL or .EXE file. This starting point makes a lot of sense, as binaries can be distributed with their documentation, and IDE "intellisense" can show basic documentation directly from the XML file, which is found automatically by looking for an XML file beside each referenced DLL. (Creating pretty-printed HTML documentation from the XML gets a bit complicated; a remarkably large number of separate tools are involved, but these tools are bundled together, and thanks to IDE features, the plain XML gets a lot of mileage.) While creating XML, the compiler resolves short references like into a complete reference like (where "M" means "Method", "T" means "Type", etc.) -- - David http://loyc-etc.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daede003 at umn.edu Fri Jun 21 08:20:18 2013 From: daede003 at umn.edu (Thomas Daede) Date: Fri, 21 Jun 2013 10:20:18 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems Message-ID: Hello, I'm relatively new to Rust, and this is the first time I've posted on this list. For my senior honors thesis, I would like to improve Rust so that it can be used on microcontrollers and other small embedded systems. This is a sector dominated by C and has seen little change for quite a while, due to most other languages not meeting the unique requirements. Besides being constrained in RAM and CPU power, the program binary also generally runs directly out of NOR Flash based ROM, so that the binary code itself takes no RAM space. This precludes most JIT based systems - interpreter based languages take less RAM, but are also very slow. Rust is in many ways a very good fit for microcontrollers. Its memory safety is very useful for many different applications, and helps greatly for task isolation on systems without memory protection. In addition, memory allocation is explicit so the programmer can choose where best to allocate the RAM - important for things like avoiding the GC in sensitive code regions. And of course, there are all the other benefits that Rust has compared to C in general. However, Rust isn't ready for microcontrollers yet. Here's what I plan to implement, in order: - Static linking for runtime and Core crate - Compiling runtime and Core without thread support - Adding compatibility with the newlib C library - Adding configurable stack allocation - Adding arm-none-eabi target - Wrappers around a native C peripheral library, such as libopencm3 This should be the bare minimum to get a demo up and running. I plan to target the STM32F4 series of microcontrollers initially, using libopencm3's linker scripts, and the C compiler and linker from gnu-arm-embedded. I know there has been some work to remove the dependency on the core and runtime libraries, however it seems difficult to strip them out entirely, and I think they are useful enough that I would rather port them instead. I would like to know if anyone else has tried this yet, or has comments about how this should be implemented. - Thomas Daede From danielmicay at gmail.com Fri Jun 21 08:21:55 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 21 Jun 2013 11:21:55 -0400 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: On Fri, Jun 21, 2013 at 11:20 AM, Thomas Daede wrote: > Hello, > > I'm relatively new to Rust, and this is the first time I've posted on > this list. For my senior honors thesis, I would like to improve Rust > so that it can be used on microcontrollers and other small embedded > systems. This is a sector dominated by C and has seen little change > for quite a while, due to most other languages not meeting the unique > requirements. Besides being constrained in RAM and CPU power, the > program binary also generally runs directly out of NOR Flash based > ROM, so that the binary code itself takes no RAM space. This precludes > most JIT based systems - interpreter based languages take less RAM, > but are also very slow. > > Rust is in many ways a very good fit for microcontrollers. Its memory > safety is very useful for many different applications, and helps > greatly for task isolation on systems without memory protection. In > addition, memory allocation is explicit so the programmer can choose > where best to allocate the RAM - important for things like avoiding > the GC in sensitive code regions. And of course, there are all the > other benefits that Rust has compared to C in general. > > However, Rust isn't ready for microcontrollers yet. Here's what I plan > to implement, in order: > - Static linking for runtime and Core crate > - Compiling runtime and Core without thread support > - Adding compatibility with the newlib C library > - Adding configurable stack allocation > - Adding arm-none-eabi target > - Wrappers around a native C peripheral library, such as libopencm3 > > This should be the bare minimum to get a demo up and running. I plan > to target the STM32F4 series of microcontrollers initially, using > libopencm3's linker scripts, and the C compiler and linker from > gnu-arm-embedded. I know there has been some work to remove the > dependency on the core and runtime libraries, however it seems > difficult to strip them out entirely, and I think they are useful > enough that I would rather port them instead. > > I would like to know if anyone else has tried this yet, or has > comments about how this should be implemented. > > - Thomas Daede You might be interested in zero.rs[1], although it needs a bit of an update. [1] https://github.com/pcwalton/zero.rs From thadguidry at gmail.com Fri Jun 21 08:33:55 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Fri, 21 Jun 2013 10:33:55 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: I would rather see Atmel AVR or ARM Cortex M0 as targets. Also, would low voltage, low power 8-bit targets with under 512KB ram be impossible ? On Fri, Jun 21, 2013 at 10:20 AM, Thomas Daede wrote: > Hello, > > I'm relatively new to Rust, and this is the first time I've posted on > this list. For my senior honors thesis, I would like to improve Rust > so that it can be used on microcontrollers and other small embedded > systems. This is a sector dominated by C and has seen little change > for quite a while, due to most other languages not meeting the unique > requirements. Besides being constrained in RAM and CPU power, the > program binary also generally runs directly out of NOR Flash based > ROM, so that the binary code itself takes no RAM space. This precludes > most JIT based systems - interpreter based languages take less RAM, > but are also very slow. > > Rust is in many ways a very good fit for microcontrollers. Its memory > safety is very useful for many different applications, and helps > greatly for task isolation on systems without memory protection. In > addition, memory allocation is explicit so the programmer can choose > where best to allocate the RAM - important for things like avoiding > the GC in sensitive code regions. And of course, there are all the > other benefits that Rust has compared to C in general. > > However, Rust isn't ready for microcontrollers yet. Here's what I plan > to implement, in order: > - Static linking for runtime and Core crate > - Compiling runtime and Core without thread support > - Adding compatibility with the newlib C library > - Adding configurable stack allocation > - Adding arm-none-eabi target > - Wrappers around a native C peripheral library, such as libopencm3 > > This should be the bare minimum to get a demo up and running. I plan > to target the STM32F4 series of microcontrollers initially, using > libopencm3's linker scripts, and the C compiler and linker from > gnu-arm-embedded. I know there has been some work to remove the > dependency on the core and runtime libraries, however it seems > difficult to strip them out entirely, and I think they are useful > enough that I would rather port them instead. > > I would like to know if anyone else has tried this yet, or has > comments about how this should be implemented. > > - Thomas Daede > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jun 21 08:48:25 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 11:48:25 -0400 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: On Fri, Jun 21, 2013 at 11:33 AM, Thad Guidry wrote: > I would rather see Atmel AVR or ARM Cortex M0 as targets. > Would need an LLVM backend for AVR. A quick google found http://sourceforge.net/projects/avr-llvm/ though. I don't know anything about it though. From daede003 at umn.edu Fri Jun 21 08:53:01 2013 From: daede003 at umn.edu (Thomas Daede) Date: Fri, 21 Jun 2013 10:53:01 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: On Fri, Jun 21, 2013 at 10:33 AM, Thad Guidry wrote: > I would rather see Atmel AVR or ARM Cortex M0 as targets. > > Also, would low voltage, low power 8-bit targets with under 512KB ram be > impossible ? > Where are you finding 8-bit targets with 512KB ram? Generally they have 8K or less. The highest end device I plan to work on only has 192KB of RAM. ARM Cortex-M0 is very similar to Cortex-M4 - it's a subset of ARMv6 rather than ARMv7 technically, so it needs different compiler options to LLVM, but I would like to support it too. It's easier to develop on the M4 though, just because of the RAM - ST sells a devkit for $15 that includes a processor with 1MB of Flash and 192KB of SRAM. Once I get it working there, I'll probably add support for the M3 and M0/M0+ too. AVR doesn't have a LLVM backend, nor do I think one would be worthwhile, when vendors like NXP are selling Cortex-M0 chips for under $1.00. The ARM NVIC is also a lot nicer and it should be relatively easy to implement interrupt routines in pure Rust (with a C method signature) From thadguidry at gmail.com Fri Jun 21 09:07:43 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Fri, 21 Jun 2013 11:07:43 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: I was thinking more of Industrial systems VS. Gadgetry & Robotics projects. No problems. Getting support for the M0 will be important long term is what I am saying. On Fri, Jun 21, 2013 at 10:53 AM, Thomas Daede wrote: > On Fri, Jun 21, 2013 at 10:33 AM, Thad Guidry > wrote: > > I would rather see Atmel AVR or ARM Cortex M0 as targets. > > > > Also, would low voltage, low power 8-bit targets with under 512KB ram be > > impossible ? > > > > Where are you finding 8-bit targets with 512KB ram? Generally they > have 8K or less. The highest end device I plan to work on only has > 192KB of RAM. > > ARM Cortex-M0 is very similar to Cortex-M4 - it's a subset of ARMv6 > rather than ARMv7 technically, so it needs different compiler options > to LLVM, but I would like to support it too. It's easier to develop on > the M4 though, just because of the RAM - ST sells a devkit for $15 > that includes a processor with 1MB of Flash and 192KB of SRAM. Once I > get it working there, I'll probably add support for the M3 and M0/M0+ > too. > > AVR doesn't have a LLVM backend, nor do I think one would be > worthwhile, when vendors like NXP are selling Cortex-M0 chips for > under $1.00. The ARM NVIC is also a lot nicer and it should be > relatively easy to implement interrupt routines in pure Rust (with a C > method signature) > -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Jun 21 11:32:19 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 14:32:19 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: Using https://github.com/huonw/rust-rand as the example crate, I've started a sketch at http://octayn.net/rdoc-proto/. Not intended to work or be pretty or usable, but intended to present the structure of documentation. From evans at cs.virginia.edu Fri Jun 21 11:50:23 2013 From: evans at cs.virginia.edu (David Evans) Date: Fri, 21 Jun 2013 14:50:23 -0400 Subject: [rust-dev] Using Rust in an OS course Message-ID: <51C4A06F.7010904@cs.virginia.edu> I'm developing a new operating systems course that I'll teach this fall. I haven't taught operating systems before, so have a lot of flexibility in developing the course, but mainly I want to give students experience with lower-level systems programming, understanding of OS concepts including resource management, concurrency, and security. I don't have much experience with Rust yet, but from what I've seen it seems like a great language to use for this. Does anyone know of any other efforts to use Rust in teaching, or have any advice on this? I would welcome any suggestions or pointers to resources that might be useful for this (or caveats if people think Rust is not ready/appropriate to use for an undergraduate course now?) Thanks a bunch, --- Dave =============================================== David Evans http://www.cs.virginia.edu/evans Professor of Computer Science University of Virginia From slabode at aim.com Fri Jun 21 12:21:36 2013 From: slabode at aim.com (SiegeLord) Date: Fri, 21 Jun 2013 15:21:36 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: <51C4A7C0.1090503@aim.com> On 06/21/2013 02:32 PM, Corey Richardson wrote: > Using https://github.com/huonw/rust-rand as the example crate, I've > started a sketch at http://octayn.net/rdoc-proto/. Not intended to > work or be pretty or usable, but intended to present the structure of > documentation. I don't know how I feel about the struct definition. I feel like it should be replaced with a list of public fields (in order, so you can use the documentation to instantiate a struct manually). Alternatively it could stay, but each field could link to an documentation entry for that field. This also brings a point of public vs private API, it'd be nice if the doc generator could generate a public-only API documentation and a public + private API documentation. -SL From garethdanielsmith at gmail.com Fri Jun 21 12:26:03 2013 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Fri, 21 Jun 2013 20:26:03 +0100 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: <51C4A8CB.3020601@gmail.com> On 19/06/13 21:01, Corey Richardson wrote: > I am going to rewrite and redesign rustdoc. Current bikeshed: > > https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc > > Please discuss, give me your feature requests, comments, etc. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev I have had recent good experiences with the Sencha documentation (its a Javascript framework): http://docs.sencha.com/extjs/4.2.1/#!/api In particular: - It has a search function that is actually useful - it matches what you type in against language-specific items like class and method names only, but it updates in real time rather than having to hit enter to view the search results, and it is very fast. The search also works offline because the dataset it searches is fairly small. For most languages I google the documentation, but for Sencha it is actually much faster to use the documentations built-in search. - It has lots of information available (including user comments), but most of it is hidden by default. I think this is nicer than, say, JavaDoc, where instead of descriptions expanding in place there is a list of method signatures and a separate list of detailed method documentations. - Everything is linked to everything else. - It has a tree on the left where you can see everything, but only the top level of the tree is visible by default. I just want to chuck this out there as something that I really liked and hope rust copies. Cheers Gareth From corey at octayn.net Fri Jun 21 12:35:59 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 15:35:59 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C4A7C0.1090503@aim.com> References: <51C4A7C0.1090503@aim.com> Message-ID: On Fri, Jun 21, 2013 at 3:21 PM, SiegeLord wrote: > I don't know how I feel about the struct definition. I feel like it should > be replaced with a list of public fields (in order, so you can use the > documentation to instantiate a struct manually). Alternatively it could > stay, but each field could link to an documentation entry for that field. > Good point. It probably should only include the "raw" definition in a collapsed box, only the field list, hyperlinked and doc'd, would be included. > This also brings a point of public vs private API, it'd be nice if the doc > generator could generate a public-only API documentation and a public + > private API documentation. > Definitely. From corey at octayn.net Fri Jun 21 12:38:30 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 15:38:30 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: <51C4A8CB.3020601@gmail.com> References: <51C4A8CB.3020601@gmail.com> Message-ID: On Fri, Jun 21, 2013 at 3:26 PM, Gareth Smith wrote: > I just want to chuck this out there as something that I really liked and > hope rust copies. > Thanks for the pointer! It's definitely useful to have examples of existing things that work really well and that people like. From jack at metajack.im Fri Jun 21 12:45:59 2013 From: jack at metajack.im (Jack Moffitt) Date: Fri, 21 Jun 2013 13:45:59 -0600 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C4A8CB.3020601@gmail.com> Message-ID: > Thanks for the pointer! It's definitely useful to have examples of > existing things that work really well and that people like. erldocs (http://erldocs.com) is one of my personal favorites. For a demo, hit tab then start typing "lists:a" and hit enter on anything you like. It uses the same data set that the ofificial erlang docs use, but shows how much better docs can be when a little UI is added. jack. From corey at octayn.net Fri Jun 21 13:04:18 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 16:04:18 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C4A8CB.3020601@gmail.com> Message-ID: On Fri, Jun 21, 2013 at 3:45 PM, Jack Moffitt wrote: >> Thanks for the pointer! It's definitely useful to have examples of >> existing things that work really well and that people like. > > erldocs (http://erldocs.com) is one of my personal favorites. For a > demo, hit tab then start typing "lists:a" and hit enter on anything > you like. It uses the same data set that the ofificial erlang docs > use, but shows how much better docs can be when a little UI is added. > One of my goals is to have rustdoc be able to emit useful, complete docs in a machine-usable form to enable alternative UIs like this. Thanks for the link! From banderson at mozilla.com Fri Jun 21 14:17:46 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 21 Jun 2013 14:17:46 -0700 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: Message-ID: <51C4C2FA.8020406@mozilla.com> On 06/21/2013 08:20 AM, Thomas Daede wrote: > Hello, > > I'm relatively new to Rust, and this is the first time I've posted on > this list. For my senior honors thesis, I would like to improve Rust > so that it can be used on microcontrollers and other small embedded > systems. This is a sector dominated by C and has seen little change > for quite a while, due to most other languages not meeting the unique > requirements. Besides being constrained in RAM and CPU power, the > program binary also generally runs directly out of NOR Flash based > ROM, so that the binary code itself takes no RAM space. This precludes > most JIT based systems - interpreter based languages take less RAM, > but are also very slow. > > Rust is in many ways a very good fit for microcontrollers. Its memory > safety is very useful for many different applications, and helps > greatly for task isolation on systems without memory protection. In > addition, memory allocation is explicit so the programmer can choose > where best to allocate the RAM - important for things like avoiding > the GC in sensitive code regions. And of course, there are all the > other benefits that Rust has compared to C in general. > > However, Rust isn't ready for microcontrollers yet. Here's what I plan > to implement, in order: Sounds good. When you start work on it I can point you in the right direction on most of these topics. Feel free to ask questions on the mailing list or on IRC. > - Static linking for runtime and Core crate https://github.com/mozilla/rust/issues/552 https://github.com/mozilla/rust/issues/3361 > - Compiling runtime and Core without thread support This is a major refactoring project which isn't made any easier by the current situation in which we have 2 entire runtimes. https://github.com/mozilla/rust/issues/7282 > - Adding compatibility with the newlib C library Last time this came up we preferred musl. https://github.com/mozilla/rust/issues/7283 > - Adding configurable stack allocation I'm not sure this means in this context. Can you elaborate? From banderson at mozilla.com Fri Jun 21 14:23:34 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 21 Jun 2013 14:23:34 -0700 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: <51C3909B.4090101@mozilla.com> <51C3A52B.9040902@mozilla.com> Message-ID: <51C4C456.4060209@mozilla.com> On 06/21/2013 04:12 AM, Corey Richardson wrote: > On Thu, Jun 20, 2013 at 8:58 PM, Brian Anderson wrote: >> This has the same problem though - the compiler still must be run on >> upstream crates to produce the metadata. >> > RIght, but hopefully it could be a fast metadata-only pass, or the > metadata could be distributed, or somesuch. Half baked idea, maybe not > a good one! > > I haven't looked into it but maybe it's possible to run resolve anyway > and just ignore failures? It is not possible to run resolve while ignoring failures and still get the correct answers, unfortunately. I did this once and Patrick gave me a scolding. From asb at asbradbury.org Fri Jun 21 14:26:09 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Fri, 21 Jun 2013 22:26:09 +0100 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: <51C4C2FA.8020406@mozilla.com> References: <51C4C2FA.8020406@mozilla.com> Message-ID: On 21 June 2013 22:17, Brian Anderson wrote: >> - Adding compatibility with the newlib C library > > > Last time this came up we preferred musl. > > https://github.com/mozilla/rust/issues/7283 Musl isn't really comparable to Newlib. Newlib is (relatively) easy to port to platforms running with no OS. Musl, uclibc, glibc all have strong dependencies on Linux. Alex From daede003 at umn.edu Fri Jun 21 14:53:38 2013 From: daede003 at umn.edu (Thomas Daede) Date: Fri, 21 Jun 2013 16:53:38 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: <51C4C2FA.8020406@mozilla.com> References: <51C4C2FA.8020406@mozilla.com> Message-ID: On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson wrote: > On 06/21/2013 08:20 AM, Thomas Daede wrote: >> - Compiling runtime and Core without thread support > > > This is a major refactoring project which isn't made any easier by the > current situation in which we have 2 entire runtimes. > > https://github.com/mozilla/rust/issues/7282 I'm not sure what you mean by two entire runtimes. Are you referring to the split between core and std? I really would like to port at least core - zero.rs looks neat and good for getting something workable early on, but I think having core there with a complete language implementation would be a lot better. Issue 3360 looks like a good, if difficult, place to start. >> - Adding compatibility with the newlib C library > > > Last time this came up we preferred musl. > > https://github.com/mozilla/rust/issues/7283 I had never heard of musl, but it looks like it's Linux only, whereas newlib is designed for "bare metal" or RTOS-based systems. >> - Adding configurable stack allocation > > > I'm not sure this means in this context. Can you elaborate? Right now Rust uses a segmented stack, and I believe the stack is allocated in 4MB segments - which is way too huge. It would be better to be able to set the size of the segments - or maybe fix the size of the stack(s). From corey at octayn.net Fri Jun 21 15:01:31 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 21 Jun 2013 18:01:31 -0400 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: <51C4C2FA.8020406@mozilla.com> Message-ID: On Fri, Jun 21, 2013 at 5:53 PM, Thomas Daede wrote: > On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson wrote: >> On 06/21/2013 08:20 AM, Thomas Daede wrote: >>> - Compiling runtime and Core without thread support >> >> >> This is a major refactoring project which isn't made any easier by the >> current situation in which we have 2 entire runtimes. >> >> https://github.com/mozilla/rust/issues/7282 > > I'm not sure what you mean by two entire runtimes. Are you referring > to the split between core and std? > core/std was renamed to std/extra, btw. You'll want to be reading the "Trunk" documentation. From lindsey at composition.al Fri Jun 21 15:10:27 2013 From: lindsey at composition.al (Lindsey Kuper) Date: Fri, 21 Jun 2013 18:10:27 -0400 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: <51C4C2FA.8020406@mozilla.com> Message-ID: On Fri, Jun 21, 2013 at 5:53 PM, Thomas Daede wrote: > On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson wrote: >> On 06/21/2013 08:20 AM, Thomas Daede wrote: >>> - Compiling runtime and Core without thread support >> >> >> This is a major refactoring project which isn't made any easier by the >> current situation in which we have 2 entire runtimes. >> >> https://github.com/mozilla/rust/issues/7282 > > I'm not sure what you mean by two entire runtimes. Are you referring > to the split between core and std? This refers to the fact that the Rust runtime system ("rt") has been (or is being) rewritten in Rust, and the new runtime system lives in the standard library (formerly known as "core", but now known as "std"). So, at the moment, there are in fact two runtime systems, one in src/rt, which will presumably go away, and one almost-working one in std. In fact, I think it's correct to say that std will *be* the Rust runtime in some sense. Lindsey From banderson at mozilla.com Fri Jun 21 15:42:07 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 21 Jun 2013 15:42:07 -0700 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: <51C4C2FA.8020406@mozilla.com> Message-ID: <51C4D6BF.3040508@mozilla.com> On 06/21/2013 02:53 PM, Thomas Daede wrote: > On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson wrote: >> On 06/21/2013 08:20 AM, Thomas Daede wrote: >>> - Compiling runtime and Core without thread support >> >> This is a major refactoring project which isn't made any easier by the >> current situation in which we have 2 entire runtimes. >> >> https://github.com/mozilla/rust/issues/7282 > I'm not sure what you mean by two entire runtimes. Are you referring > to the split between core and std? We are in the process of rewriting the old C++ rust task scheduler (which to large degree is 'the Rust runtime') in Rust. At this moment and for at least another few weeks there is an entire C++ runtime implementation in src/rt and another in libstd/rt written in Rust. All the code paths in std that depend on runtime state currently have branches to pick between the two implementations, so an effort to refactor the libraries to create a microcontroller profile will have to deal with additional complexity. > >>> - Adding compatibility with the newlib C library >> >> Last time this came up we preferred musl. >> >> https://github.com/mozilla/rust/issues/7283 > I had never heard of musl, but it looks like it's Linux only, whereas > newlib is designed for "bare metal" or RTOS-based systems. > >>> - Adding configurable stack allocation >> >> I'm not sure this means in this context. Can you elaborate? > Right now Rust uses a segmented stack, and I believe the stack is > allocated in 4MB segments - which is way too huge. It would be better > to be able to set the size of the segments - or maybe fix the size of > the stack(s). I didn't imagine you wanted to use green thread scheduling still. That will be interesting. From daede003 at umn.edu Fri Jun 21 15:53:03 2013 From: daede003 at umn.edu (Thomas Daede) Date: Fri, 21 Jun 2013 17:53:03 -0500 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: <51C4D6BF.3040508@mozilla.com> References: <51C4C2FA.8020406@mozilla.com> <51C4D6BF.3040508@mozilla.com> Message-ID: On Fri, Jun 21, 2013 at 5:42 PM, Brian Anderson wrote: > On 06/21/2013 02:53 PM, Thomas Daede wrote: >> >> On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson >> wrote: >>> >>> On 06/21/2013 08:20 AM, Thomas Daede wrote: >>>> >>>> - Compiling runtime and Core without thread support >>> >>> >>> This is a major refactoring project which isn't made any easier by the >>> current situation in which we have 2 entire runtimes. >>> >>> https://github.com/mozilla/rust/issues/7282 >> >> I'm not sure what you mean by two entire runtimes. Are you referring >> to the split between core and std? > > > We are in the process of rewriting the old C++ rust task scheduler (which to > large degree is 'the Rust runtime') in Rust. At this moment and for at least > another few weeks there is an entire C++ runtime implementation in src/rt > and another in libstd/rt written in Rust. All the code paths in std that > depend on runtime state currently have branches to pick between the two > implementations, so an effort to refactor the libraries to create a > microcontroller profile will have to deal with additional complexity. > > >> >>>> - Adding compatibility with the newlib C library >>> >>> >>> Last time this came up we preferred musl. >>> >>> https://github.com/mozilla/rust/issues/7283 >> >> I had never heard of musl, but it looks like it's Linux only, whereas >> newlib is designed for "bare metal" or RTOS-based systems. >> >>>> - Adding configurable stack allocation >>> >>> >>> I'm not sure this means in this context. Can you elaborate? >> >> Right now Rust uses a segmented stack, and I believe the stack is >> allocated in 4MB segments - which is way too huge. It would be better >> to be able to set the size of the segments - or maybe fix the size of >> the stack(s). > > > I didn't imagine you wanted to use green thread scheduling still. That will > be interesting. > I was under the impression that *all* stacks in Rust were segmented and bounds-checked. Is that not true for the main stack? If so, it won't actually be a problem, though I was actually interested in porting the scheduler at some point. From banderson at mozilla.com Fri Jun 21 16:01:53 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 21 Jun 2013 16:01:53 -0700 Subject: [rust-dev] Rust on microcontrollers and embedded systems In-Reply-To: References: <51C4C2FA.8020406@mozilla.com> <51C4D6BF.3040508@mozilla.com> Message-ID: <51C4DB61.6040202@mozilla.com> On 06/21/2013 03:53 PM, Thomas Daede wrote: > On Fri, Jun 21, 2013 at 5:42 PM, Brian Anderson wrote: >> On 06/21/2013 02:53 PM, Thomas Daede wrote: >>> On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson >>> wrote: >>>> On 06/21/2013 08:20 AM, Thomas Daede wrote: >>>>> - Compiling runtime and Core without thread support >>>> >>>> This is a major refactoring project which isn't made any easier by the >>>> current situation in which we have 2 entire runtimes. >>>> >>>> https://github.com/mozilla/rust/issues/7282 >>> I'm not sure what you mean by two entire runtimes. Are you referring >>> to the split between core and std? >> >> We are in the process of rewriting the old C++ rust task scheduler (which to >> large degree is 'the Rust runtime') in Rust. At this moment and for at least >> another few weeks there is an entire C++ runtime implementation in src/rt >> and another in libstd/rt written in Rust. All the code paths in std that >> depend on runtime state currently have branches to pick between the two >> implementations, so an effort to refactor the libraries to create a >> microcontroller profile will have to deal with additional complexity. >> >> >>>>> - Adding compatibility with the newlib C library >>>> >>>> Last time this came up we preferred musl. >>>> >>>> https://github.com/mozilla/rust/issues/7283 >>> I had never heard of musl, but it looks like it's Linux only, whereas >>> newlib is designed for "bare metal" or RTOS-based systems. >>> >>>>> - Adding configurable stack allocation >>>> >>>> I'm not sure this means in this context. Can you elaborate? >>> Right now Rust uses a segmented stack, and I believe the stack is >>> allocated in 4MB segments - which is way too huge. It would be better >>> to be able to set the size of the segments - or maybe fix the size of >>> the stack(s). >> >> I didn't imagine you wanted to use green thread scheduling still. That will >> be interesting. >> > I was under the impression that *all* stacks in Rust were segmented > and bounds-checked. Is that not true for the main stack? If so, it > won't actually be a problem, though I was actually interested in > porting the scheduler at some point. Rust does not necessarily require segmented stacks, though almost all existing code uses them. Even today if you override the `start` function (a more primitive `main`) with the `#[start]` attribute, you can run Rust code with no before-main runtime setup and will not be using segmented stacks. One small correction though: Rust stack segments are not allocated in 4MB segments. The initial stack segment is somewhere between 3k and 21k depending on platform. From there each new segment doubles in size. From remifontan at yahoo.fr Sat Jun 22 01:35:35 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sat, 22 Jun 2013 20:35:35 +1200 Subject: [rust-dev] howto: c++ reference in rust Message-ID: Hi, is there a way to write something as follow in rust? class matrix { ... float& Get(int r, int c) { return this.data[r + c*4]; } } matrix m; m.Get(0, 1) = 42.; in trust, my struct matrix would have a method called Get, but what would it return? struct Mat { data:[float, ..16] } impl Mat { pub fn Get(&mut self, r:int, c:int) -> &mut float { &self.data[r+c*4] } } I get error messages about lifetime or about mutability est.rs:107:8: 107:24 error: mismatched types: expected `&mut float` but found `&float` (values differ in mutability) test.rs:107 &self.data[r*4+c] ^~~~~~~~~~~~~~~~ cheers, Remi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From blei42 at gmail.com Sat Jun 22 01:47:27 2013 From: blei42 at gmail.com (=?UTF-8?Q?Philipp_Br=C3=BCschweiler?=) Date: Sat, 22 Jun 2013 10:47:27 +0200 Subject: [rust-dev] howto: c++ reference in rust In-Reply-To: References: Message-ID: Hi R?mi, The problem in your code was that you have to return a &mut reference. Here's a version of your code that works: ``` struct Mat { data:[float, ..16] } impl Mat { pub fn new() -> Mat { Mat { data: [0.0, ..16] } } pub fn Get<'a>(&'a mut self, r:int, c:int) -> &'a mut float { &mut self.data[r+c*4] } } fn main() { let mut a = Mat::new(); *a.Get(0, 0) = 5.0; println(fmt!("%?", a)); } ``` Note that besides taking an &mut reference, we have to tell the compiler that the lifetime of that reference is the same as of the original object, which is done by anotating both references with the same lifetime variable ('a in this code). Cheers, Philipp On Sat, Jun 22, 2013 at 10:35 AM, R?mi Fontan wrote: > Hi, > > is there a way to write something as follow in rust? > > class matrix { > ... > float& Get(int r, int c) { return this.data[r + c*4]; } > } > > matrix m; > m.Get(0, 1) = 42.; > > > in trust, my struct matrix would have a method called Get, but what would > it return? > > struct Mat { > data:[float, ..16] > } > > impl Mat { > pub fn Get(&mut self, r:int, c:int) -> &mut float { > &self.data[r+c*4] > } > } > > > I get error messages about lifetime or about mutability > > est.rs:107:8: 107:24 error: mismatched types: expected `&mut float` but > found `&float` (values differ in mutability) > test.rs:107 &self.data[r*4+c] > ^~~~~~~~~~~~~~~~ > > > cheers, > > Remi > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Jun 22 06:02:57 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 22 Jun 2013 09:02:57 -0400 Subject: [rust-dev] This Week in Rust Message-ID: --- layout: post title: "This Week in Rust" date: 2013-06-22 05:21 comments: true categories: programming, rust, this-week-in-rust --- Hello and welcome to the third issue of *This Week in Rust*, a weekly overview of Rust and its community. It has come to my attention that Github does not categorize some merged-by-bors pull requests as "merged" and instead categorizes it as "closed". This skews the numbers and also the PRs that I looked through for inclusion into twir. I'll no longer be including issue churn/PR numbers, and I hope I didn't miss any import PRs in the last two issues. # What's cooking in incoming? The last of the tree breakage has been cleaned up. The mysterious stack corruption was traced down by Blei to occur in jemalloc. It has been disabled until the real cause of the error is found. A bunch more buildbot configurations have been turned on for auto, to fend off more breakage. The tree is open, and aatch got out a new snapshot! Most of the work this week is cleanup and preparation for 0.7, but since the tree has been closed (and the extra auto buildbots lengthen the time it takes for a PR to be tested for the day it has been open), not much has landed these past few days, but a bunch happened earlier this week. ## Notable additions, bugfixes, and cleanup - doener made compiles faster by emitting less useless copies and allocations in [7259](https://github.com/mozilla/rust/pull/7259) - aatch landed [part 1](https://github.com/mozilla/rust/pull/7124) and [part 2](https://github.com/mozilla/rust/pull/7182) of his huge trans refactor effort, which make trans faster and less terrible. - sully got [default methods](https://github.com/mozilla/rust/pull/7203) less broken - yichoi landed a [bunch](https://github.com/mozilla/rust/pull/7128) of Android fixes. - vadimcn has [fixed debuginfo](https://github.com/mozilla/rust/pull/7134), which is super amazing. This makes it a lot easier for the GSoC student (mw) to get started. - doener has [fixed](https://github.com/mozilla/rust/pull/7186) some pathological behavior in how codegen creates cleanup blocks. This makes the IR better, reducing compile time, and also allowing better optimization, reducing binary size. {% blockquote https://github.com/mozilla/rust/pull/7259 %} They reduce compile times by about 10% in total. {% endblockquote %} {% blockquote https://github.com/mozilla/rust/pull/7186 %} Reduces the size of librustc by about 5% and the time required to build it by about 10%. {% endblockquote %} {% blockquote https://github.com/mozilla/rust/pull/7154 %} The resulting code for rustc is about 13% faster (measured up to and including the "trans" pass) and the resulting librustc is about 5% smaller. {% endblockquote %} ## Breaking changes strcat [continues](https://github.com/mozilla/rust/pull/7263) [work](https://github.com/mozilla/rust/pull/7162) with iterators. The changes that landed are vector cleanups. Probably most importantly, the `each` and `eachi` methods are being removed. The `eachi` removal landed but the `each` one broke bors, so it's currently in limbo. The current replacement is: ``` // each for your_vec.iter().advance |element| { ... } // eachi for your_vec.iter().enumerate().advance |(i, element)| { ... } ``` Once the rest of the iterator work is hashed out and lands, it will just be ``` // each for your_vec |element| { ... } // eachi for your_vec.enumerate() |(i, element)| { ... } ``` although the syntax might be slightly different (`for element in your_vec` is my favorite proposal). # Meetings The [Tuesday meeting's](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-18) main topics were once fn's and how namespaces work. For once fn's, graydon says "I'm concerned with adding new features and I want to see if we can live without it, I understand it is common," not yet making a decision to include them in the language. # Meetups - tjc's pre-talk and talk, "Rust: A Friendly Introduction" went very well. The [slides](http://catamorphism.org/Writing/Rust-Tutorial-tjc.pdf) are up, and a recording is coming soon (hopefuly). tjc says the slides aren't as understanable without the audio of the talk. - nmatsakis has expressed willingness/interest in a Boston meetup sometime. If you're interested, contact him on IRC or the ML. # Notable discourse and external projects - [mmap and the Rust FFI](http://maniagnosis.crsr.net/2013/06/mmap-and-rust-foreign-function-interface.html) (indutny is working on mman bindings in libc, for the record. will mention in next week's twir when it lands) - [code generation and rustc speed](https://mail.mozilla.org/pipermail/rust-dev/2013-June/004480.html) - [Rust for game development?](http://www.reddit.com/r/rust/comments/1gs93k/rust_for_game_development/) - [Feed us some low hanging fruit!](http://www.reddit.com/r/rust/comments/1grj61/feed_us_some_low_hanging_fruit/) - [Paying Technical Debt in rustc](http://aatch.github.io/blog/2013/06/19/paying-technical-debt-in-rustc/) - [What issues in Rust today effect (sic) you most?](http://www.reddit.com/r/rust/comments/1gpbcs/what_issues_in_rust_today_effect_you_most/) - [rustdoc rewrite and redesign](https://mail.mozilla.org/pipermail/rust-dev/2013-June/004520.html) - [rust-bench: a tool for profiling memory usage](http://www.reddit.com/r/rust/comments/1gmac5/linux_rustbench_a_tool_for_profiling_memory_usage/) # Other announcements - Michael Woerister (mw), the GSoC student working on debug info, has begun work. His project log is at http://michaelwoerister.github.io/, and will be updated weekly. I'm looking forward to a much better debug experience. From marcianx at gmail.com Sat Jun 22 09:26:09 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 22 Jun 2013 12:26:09 -0400 Subject: [rust-dev] tjc's pre-talk and talk (was: This Week in Rust) Message-ID: > - tjc's pre-talk and talk, "Rust: A Friendly Introduction" went very well. The > [slides](http://catamorphism.org/Writing/Rust-Tutorial-tjc.pdf) are up, and > a recording is coming soon (hopefuly). tjc says the slides aren't as > understanable without the audio of the talk. Thanks for the tutorial! The slides seem perfectly comprehensible without audio, except possibly for some points below that may either be corrected or perhaps addressed in the slide notes themselves. POSSIBLE ERRATA: Slide 40: The notes say "Change [@Drawable] to [~@Drawable]". The latter should be ~[@Drawable], or, to be consistent with the Slide 41, perhaps &[@Drawable]? Both tested to work. Slide 51: The program seems to be missing a unique pointer sigil ~; and the types of the array and the initializer ("quux") don't match. Here is a possible correction? (Tested.) fn h(b: ~[int]) { } fn g(a: ~[int]) { } fn f(n: uint) { let v: ~[int] = vec::from_elem(n,1); h(v); g(v); } Slide 53: Perhaps the audio is needed for this slide, but I am confused. Before I start with that, I checked struct Cat { a : int, } fn main() { let v: Cat::new(); } It seems that there is no default new() function, so I don't know the type of the object returned by Cat::new(). Is it Cat or ~Cat here? The comment about Cat not being copyable seems to imply that the type is Cat (i.e. stack-allocated). But then send_cat_to_moon(cat) should not be able to invalidate the reference, right? So there should not be a problem with that code as webcam should get destructed before cat at the end of the block. If Cat::new() returns ~Cat and Webcam::new() returns ~Webcam, then I can see this working out, but then there is the implicit assumption (that could perhaps be clarified in the comments) that send_cat_to_moon(cat) takes its argument as ~Cat rather than, say, &Cat. From banderson at mozilla.com Sat Jun 22 15:38:26 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 22 Jun 2013 15:38:26 -0700 Subject: [rust-dev] Using Rust in an OS course In-Reply-To: <51C4A06F.7010904@cs.virginia.edu> References: <51C4A06F.7010904@cs.virginia.edu> Message-ID: <51C62762.4080403@mozilla.com> On 06/21/2013 11:50 AM, David Evans wrote: > I'm developing a new operating systems course that I'll teach this > fall. I haven't taught operating systems before, so have a lot of > flexibility in developing the course, but mainly I want to give > students experience with lower-level systems programming, > understanding of OS concepts including resource management, > concurrency, and security. > > I don't have much experience with Rust yet, but from what I've seen it > seems like a great language to use for this. > > Does anyone know of any other efforts to use Rust in teaching, or have > any advice on this? I would welcome any suggestions or pointers to > resources that might be useful for this (or caveats if people think > Rust is not ready/appropriate to use for an undergraduate course now?) I agree Rust would be great for presenting these issues since it is designed to make the programmer understand the costs of abstractions, but it also doesn't punish them for making errors in the various ways that C does. I totally want this to happen but at this stage basing a university course around Rust would be risky; I don't know anybody teaching Rust so you would be way out on a limb. I can imagine that students taking a systems-programming course based around Rust would have to spend a fair bit of time learning how to cope with Rust's novel semantics (affine types in particular). Hopefully those hurdles would still be easier than managing the unsafety of C. Of course there's also the risk of frustrating students with the large number of compiler bugs still present in rustc. Not sure how useful they are for preparing a course, but Tim posted his recent tutorial [slides], and there are some other slide decks floating around. [slides]: http://catamorphism.org/Writing/Rust-Tutorial-tjc.pdf Sorry this isn't so helpful, but I'm happy to offer any further assistance. Regards, Brian From lindsey at composition.al Sat Jun 22 16:22:52 2013 From: lindsey at composition.al (Lindsey Kuper) Date: Sat, 22 Jun 2013 19:22:52 -0400 Subject: [rust-dev] Using Rust in an OS course In-Reply-To: <51C4A06F.7010904@cs.virginia.edu> References: <51C4A06F.7010904@cs.virginia.edu> Message-ID: On Fri, Jun 21, 2013 at 2:50 PM, David Evans wrote: > Does anyone know of any other efforts to use Rust in teaching, or have any > advice on this? I would welcome any suggestions or pointers to resources > that might be useful for this (or caveats if people think Rust is not > ready/appropriate to use for an undergraduate course now?) One risk that no one has mentioned yet is that the Rust documentation isn't all that good yet, by which I mean both the official docs and the other resources that are available. I know that when I was an undergrad, I sometimes struggled with picking up a new language even when the docs were quite complete and correct, and that isn't the case with Rust yet. And for some undergrads, just building and installing Rust might be a hurdle. Moreover, if they install a released version of the language and then complain of problems on the IRC channel, they're likely to hear, "That's been fixed in the head of the tree for three weeks already. Keep up!" For that matter, if your students aren't already familiar with how to participate (even as a user) in a young open-source project, they might be stymied in trying to work with Rust. At the moment, step 0 in learning Rust may be learning how to use IRC. All this will, of course, improve with time. Lindsey From marcianx at gmail.com Sat Jun 22 19:53:01 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 22 Jun 2013 22:53:01 -0400 Subject: [rust-dev] Front page example Message-ID: I have been out of rust for a bit, and coming back to it, I am having a difficult time adapting the front page example at http://www.rust-lang.org/ to the trunk version of rust (updated last night). I turned the example to -------- use std::*; fn main() { for ["Alice", "Bob", "Carol"].each |&name| { do task::spawn { let v = rand::rng().shuffle([1, 2, 3]); for v.each |&num| { io::print(fmt!("%s says: '%d'\n", name, num)) } } } } -------- and rustc complains with -------- hello.rs:6:20: 6:51 error: type `std::rand::IsaacRng` does not implement any method in scope named `shuffle` hello.rs:6 let v = rand::rng().shuffle([1, 2, 3]); -------- and a type inference error triggered by this part failing. In libstd/rand.rs, RngUtil seems to be defined for everything implementing Rng, which IsaacRng does. Is this a bug or is it some change in the lookup? From dbau.pp at gmail.com Sat Jun 22 20:00:35 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Sun, 23 Jun 2013 13:00:35 +1000 Subject: [rust-dev] Front page example In-Reply-To: References: Message-ID: <51C664D3.3030104@gmail.com> On 23/06/13 12:53, Ashish Myles wrote: > I have been out of rust for a bit, and coming back to it, I am having > a difficult time adapting the front page example at > http://www.rust-lang.org/ to the trunk version of rust (updated last > night). I turned the example to > > -------- > use std::*; > > fn main() { > for ["Alice", "Bob", "Carol"].each |&name| { > do task::spawn { > let v = rand::rng().shuffle([1, 2, 3]); > for v.each |&num| { > io::print(fmt!("%s says: '%d'\n", name, num)) > } > } > } > } > -------- > > and rustc complains with > > -------- > hello.rs:6:20: 6:51 error: type `std::rand::IsaacRng` does not > implement any method in scope named `shuffle` > hello.rs:6 let v = rand::rng().shuffle([1, 2, 3]); > -------- > > and a type inference error triggered by this part failing. In > libstd/rand.rs, RngUtil seems to be defined for everything > implementing Rng, which IsaacRng does. Is this a bug or is it some > change in the lookup? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev To use the methods from a trait, it has to be in scope, so: use std::rand::{rng, RngUtil}; fn main() { for ["Alice", "Bob", "Carol"].each |&name| { do spawn { let v = rng().shuffle([1, 2, 3]); for v.each |&num| { print(fmt!("%s says: '%d'\n", name, num)) } } } } seems to work with my rustc (ba05af7 2013-06-20 22:28:52 -0700). (The reason many other traits don't need to be explicitly imported is that they are exported from std::prelude, which is implicitly added as `use std::prelude::*;` at the top of every mod.) Huon From pnathan at vandals.uidaho.edu Sat Jun 22 20:38:01 2013 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Sat, 22 Jun 2013 20:38:01 -0700 Subject: [rust-dev] Using Rust in an OS course In-Reply-To: References: <51C4A06F.7010904@cs.virginia.edu> Message-ID: <51C66D99.70003@vandals.uidaho.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/22/2013 04:22 PM, Lindsey Kuper wrote: > On Fri, Jun 21, 2013 at 2:50 PM, David Evans > wrote: >> Does anyone know of any other efforts to use Rust in teaching, or >> have any advice on this? I would welcome any suggestions or >> pointers to resources that might be useful for this (or caveats >> if people think Rust is not ready/appropriate to use for an >> undergraduate course now?) > > One risk that no one has mentioned yet is that the Rust > documentation isn't all that good yet, by which I mean both the > official docs and the other resources that are available. I know > that when I was an undergrad, I sometimes struggled with picking up > a new language even when the docs were quite complete and correct, > and that isn't the case with Rust yet. > > And for some undergrads, just building and installing Rust might be > a hurdle. Moreover, if they install a released version of the > language and then complain of problems on the IRC channel, they're > likely to hear, "That's been fixed in the head of the tree for > three weeks already. Keep up!" > > For that matter, if your students aren't already familiar with how > to participate (even as a user) in a young open-source project, > they might be stymied in trying to work with Rust. At the moment, > step 0 in learning Rust may be learning how to use IRC. > > All this will, of course, improve with time. > > Lindsey _______________________________________________ Rust-dev > mailing list Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > . > David, I have not heard of other people using Rust for teaching, at least in communiques on the list. My advice, as someone who's run lab sessions for undergrads before, is to lock onto a particular version. Say, 0.7, as its coming out soon. You'll probably want to snapshot it and compile it for x86 & x64; if you have a server for your undergrads, it's probably best to call that the 'regulation' Rust. I think the docs for Rust are still underpowered for newbies. Perhaps you might want to write the authoritative book on Learn Programming With Rust in 24 Hours and make your fortune. ;-) At least, I would expect to have to provide exhaustive notes to students. Particularly if they are not familiar with languages such as OCaml, Haskell, F#, etc. On the bright side, I think teaching with Rust would be ideal for an Honors course and the top 20% of students would benefit immensely. It's entirely possible that the bottom 40% will flame out in a very distressingly impressive way due to the uncommon semantics and lack of a well trod "here's how you do it" path. I can't speak for the rest of the list, but I'd love to see an after-action report if you do teach a course with Rust. - -- Regards, Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRxm2ZAAoJEOKsXdnj/GaoE2YP/Rmjm33h72Xdb5TvIhSlRE0P sjB2GSVvksYNVH2MqTRity3pSw8soaIxOpxqyIhXAZ4jSYFt5bRKXynaJtvgL1hj TNI42c2EIw4OHdopOmpZc7LJ99Yk56s9JvMBMtB4HMc46BwB4vEFcQkqGIvW1l6h NOZPX2w8XiV5V30BPPUVSge3FbnPyAD9HGWJyH1A/Er4QByVYoQQMp/o487vt6oV CVrrRZJJoglkftaSrg/ajILv5ij4dnkF/tzW+nnS1xdu5ihgDgRP8Qmc0PIlxY0G QueZivm0dCzjINIUjySOrwdmwO+gB0VRHoyS/gqR2cJLrYYDpW+yQQ/LYHGSXhMf vJzU26C0XvB8yclJIznL+N6LhcEA0Gsh3e2AXRaAq1oat0LIdUUGd4mo3E5N36sl l10uYyRXNUzcLCrZHpGdvINcQRMn5ZRR3Fpuxoaie+acYuL34PfddVJt3QWlQJ/Q uhYueN4i+T4NHtE2xRvoyDYrqmdUxIj9dOPbVUl5bpq18WpQJLgdd/iNlbsHuUJa ZWNDxektBBLf3hmQiXc8Np+B0mJb8LyCHWuCY3H+YW9ktQAwSB/dvyKHzcaTVOo6 TdEIWTqcilgXx8Sy7XbAEkLQNbviZfYxvWH2tnSedQ7jkwmik5jwCQg8CWMthoCQ vZrcEMg9r72yLjV5qMvu =SfCY -----END PGP SIGNATURE----- From marcianx at gmail.com Sun Jun 23 13:06:16 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sun, 23 Jun 2013 16:06:16 -0400 Subject: [rust-dev] Front page example In-Reply-To: <51C664D3.3030104@gmail.com> References: <51C664D3.3030104@gmail.com> Message-ID: Great, thanks, it works! Is there a way to invoke the shuffle() without bringing it explicitly into local scope, say via some verbose way that specifies the trait to be used? Ashish On Sat, Jun 22, 2013 at 11:00 PM, Huon Wilson wrote: > On 23/06/13 12:53, Ashish Myles wrote: >> >> I have been out of rust for a bit, and coming back to it, I am having >> a difficult time adapting the front page example at >> http://www.rust-lang.org/ to the trunk version of rust (updated last >> night). I turned the example to >> >> -------- >> use std::*; >> >> fn main() { >> for ["Alice", "Bob", "Carol"].each |&name| { >> do task::spawn { >> let v = rand::rng().shuffle([1, 2, 3]); >> for v.each |&num| { >> io::print(fmt!("%s says: '%d'\n", name, num)) >> } >> } >> } >> } >> -------- >> >> and rustc complains with >> >> -------- >> hello.rs:6:20: 6:51 error: type `std::rand::IsaacRng` does not >> implement any method in scope named `shuffle` >> hello.rs:6 let v = rand::rng().shuffle([1, 2, 3]); >> -------- >> >> and a type inference error triggered by this part failing. In >> libstd/rand.rs, RngUtil seems to be defined for everything >> implementing Rng, which IsaacRng does. Is this a bug or is it some >> change in the lookup? >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > To use the methods from a trait, it has to be in scope, so: > > use std::rand::{rng, RngUtil}; > > > fn main() { > for ["Alice", "Bob", "Carol"].each |&name| { > do spawn { > let v = rng().shuffle([1, 2, 3]); > for v.each |&num| { > > print(fmt!("%s says: '%d'\n", name, num)) > } > } > } > } > > seems to work with my rustc (ba05af7 2013-06-20 22:28:52 -0700). > > (The reason many other traits don't need to be explicitly imported > is that they are exported from std::prelude, which is implicitly added > as `use std::prelude::*;` at the top of every mod.) > > > Huon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From dwrenshaw at gmail.com Sun Jun 23 18:54:16 2013 From: dwrenshaw at gmail.com (David Renshaw) Date: Sun, 23 Jun 2013 21:54:16 -0400 Subject: [rust-dev] cross-file trait impls Message-ID: Hello, I have a question that may be related to Ashish's recent questions. I was trying to compile the below files and I discovered, unexpectedly, that one fix is to add the line "use file1::file2::*;" at the top of test-crate.rc. Can someone clarify what's going on here? Is there a fix that modifies file1.rs instead? Thanks, David ------ test-crate.rc ----- mod file1; mod file2; fn main() { file1::bar(); } ------ file1.rs ------ mod file2; struct X { x : int } impl file2::HasInt for X { fn foo(&self) -> int { self.x } } pub fn bar() -> int { let x = X{x : 10}; x.foo() } ------- file2.rs ----- pub trait HasInt { fn foo(&self) -> int; } --------------------- $ rustc test-crate.rc file1.rs:16:4: 18:1 error: type `file1::X` does not implement any method in scope named `foo` file1.rs:16 x.foo() file1.rs:17 file1.rs:18 } error: aborting due to previous error -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at gmail.com Mon Jun 24 02:14:33 2013 From: michaelwoerister at gmail.com (Michael Woerister) Date: Mon, 24 Jun 2013 11:14:33 +0200 Subject: [rust-dev] Memory layout of types Message-ID: <51C80DF9.8090301@gmail.com> Hi everyone! As you may know, I'm working on debug info support for rustc. Last week I found a small bug regarding the size of structs as stored in the debug info. Once found, it was not hard to fix but it led me to thinking a bit more on how to handle memory layout in the debug info code and how to make this as stable as possible. I will give a bit of an overview of the problem first and then I have some questions towards the end. Maybe someone here can help me out with this. At the moment the debuginfo module essentially tries to reconstruct/mirror the behavior of other compiler parts that actually define the memory layout. For example, debuginfo::create_struct() emulates the behavior of LLVM's StructLayout class [1], and debuginfo::create_boxed_type() adds a hardcoded set of fields to the struct representing a box. Unfortunately this approach can lead to fragile code: (1) The reconstructed algorithm may miss corner cases. E.g. the current struct layout algorithm in debuginfo does not handle 'packed' structs (i.e. structs without padding bytes) or structs with destructors (because they have an additional bool field, added by the compiler) (2) When something changes somewhere else in the compiler, the debug info algorithm may go out of sync. E.g. the comment section at the beginning of trans/adt.rs indicates that in the future enums may support optimized layouts to conserve space [2]. This will obviously break debug info, if it assumed that discriminant are always word-sized and at some fixed offset. Duplicating the layouting logic is simply not 'DRY'. Consequently, I think we should use an approach that doesn't try to replicate layout information logic but reads it from the definite sources. I think this problem can be broken down into two distinct subproblems: (1) Given a struct/tuple/enum type and a list of its field types, what is the offset and allocation size of each field. (2) What *are* the fields of a given composite type? I think the best strategy to solve problem (1) is to query the finished LLVM struct type. This should really be the definite source for a types memory layout and saves us from having to emulate and keep up-to-date a complicated layouting algorithm (there is not only the 'packed' parameter but also the much more involved DataLayout[3] specification that needs to be accounted for). This can probably also be implemented rather easily by wrapping LLVM's DataLayout class [3]. Problem (2) might not be that easy to solve. Or maybe its just knowing the right function(s) to call. That is the main reason for posting this email, maybe someone here knows the best way to solve this cleanly. There are a few places that look promising: * For structs, there is ty::struct_fields()---which is what is used at the moment---but it does not account for additional fields generated by the compiler, such as the 'destroyedness' flag. * There is the trans::adt module and the Repr enum which look very promising. It does not provide all the information I need (e.g. it will include generated fields, but does not explicitely specify where they are located, just in comments (enum discriminant) or code (destroyedness flag)). But otherwise it seems the place to go for a definite field list of composite types. * Then there is middle::trans::type_::Type which seems to contain some valueable information on the layout of boxes, trait stores, vecs, etc. I wonder, however, where this information is taken from? Is it specified somewhere? It would be great to have an exhaustive list of any structures used internally by the compiler, like boxes, vecs, any kind of fat pointer, etc. Can this be found somewhere? Any help and comments are appreciated. Thanks for taking the time to read this! -Michael -------------------- [1] http://llvm.org/docs/doxygen/html/DataLayout_8cpp_source.html#l00044 [2] https://github.com/mozilla/rust/blob/d2e9912aea87f9b1812a0f44e093c0405848f7ce/src/librustc/middle/trans/adt.rs#L11 [3] http://llvm.org/docs/doxygen/html/classllvm_1_1DataLayout.html From blei42 at gmail.com Mon Jun 24 04:48:05 2013 From: blei42 at gmail.com (=?UTF-8?Q?Philipp_Br=C3=BCschweiler?=) Date: Mon, 24 Jun 2013 13:48:05 +0200 Subject: [rust-dev] howto: c++ reference in rust In-Reply-To: References: Message-ID: Hi R?mi, Yes, this looks like a compiler bug to me. Cheers, Philipp On Mon, Jun 24, 2013 at 1:07 PM, R?mi Fontan wrote: > I have another example that puzzles me. > > struct Vec { x:float, y:float, z:float } > impl Vec { > pub fn getRef<'a>(&'a mut self, i:uint) -> &'a mut float { > // if(i==0) { &mut self.x } > // else if(i==1) { &mut self.x } > // else {&mut self.x } > > match(i) { > 0 => &mut self.x, > 1 => &mut self.y, > _ => &mut self.z > } > } > } > > when compiling with match I get following errors : > > rustc test.rs -o test-test --test > test.rs:122:17: 122:28 error: cannot infer an appropriate lifetime due to > conflicting requirements > test.rs:122 _ => &mut self.z > ^~~~~~~~~~~ > test.rs:121:17: 121:28 note: first, the lifetime must be contained by the > expression at 121:17... > test.rs:121 1 => &mut self.y, > ^~~~~~~~~~~ > test.rs:121:17: 121:28 note: ...due to the following expression > test.rs:121 1 => &mut self.y, > ^~~~~~~~~~~ > test.rs:120:17: 120:28 note: but, the lifetime must also be contained by > the expression at 120:17... > test.rs:120 0 => &mut self.x, > ^~~~~~~~~~~ > test.rs:120:17: 120:28 note: ...due to the following expression > test.rs:120 0 => &mut self.x, > ^~~~~~~~~~~ > error: aborting due to previous error > make: *** [test-test] Error 101 > > > > but it compiles correctly with the if version. I don't understand why it's > not behaving the same way. Actually I don't understand why the compiler is > not capable of finding out about the life cycle on its own for this > particular example. Could the life cycle of the return type of getRef be > inferred from the lifecycle of the intersection of {self.x, self.y, > self.z} ? > > cheers, > > R?mi > > > > > On Mon, Jun 24, 2013 at 2:32 AM, Philipp Br?schweiler wrote: > >> Hi R?mi, >> >> Yes, the documentation of Rust is not very good at the moment. The >> concept and syntax of lifetimes is explained in this and the following >> chapter: >> >> >> http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html#returning-borrowed-pointers >> >> The only single quotes are only used to declare literal characters, e.g. >> 'c', and lifetime variables. >> >> Cheers, >> Philipp >> >> >> On Sun, Jun 23, 2013 at 12:03 PM, R?mi Fontan wrote: >> >>> thanks, it works. >>> >>> however it is not yet very clear to me how lifetime works in rust. is >>> there a bit of doc that explain about the concept of lifetime and the >>> syntax? >>> >>> is using a quote before the lifetime variable necessary? I realised that >>> the first time I read the rust tutorial I saw a lot of variables with a >>> quote in front of their name, I simply ignore that details and went ahead. >>> Were there all lifetime variables? >>> >>> cheers, >>> >>> R?mi >>> >>> >>> On Sat, Jun 22, 2013 at 8:47 PM, Philipp Br?schweiler wrote: >>> >>>> Hi R?mi, >>>> >>>> The problem in your code was that you have to return a &mut reference. >>>> Here's a version of your code that works: >>>> >>>> ``` >>>> >>>> struct Mat { >>>> data:[float, ..16] >>>> } >>>> >>>> impl Mat { >>>> pub fn new() -> Mat { >>>> Mat { data: [0.0, ..16] } >>>> } >>>> pub fn Get<'a>(&'a mut self, r:int, c:int) -> &'a mut float { >>>> &mut self.data[r+c*4] >>>> } >>>> } >>>> >>>> fn main() { >>>> let mut a = Mat::new(); >>>> *a.Get(0, 0) = 5.0; >>>> println(fmt!("%?", a)); >>>> } >>>> ``` >>>> >>>> Note that besides taking an &mut reference, we have to tell the >>>> compiler that the lifetime of that reference is the same as of the original >>>> object, which is done by anotating both references with the same lifetime >>>> variable ('a in this code). >>>> >>>> Cheers, >>>> Philipp >>>> >>>> >>>> On Sat, Jun 22, 2013 at 10:35 AM, R?mi Fontan wrote: >>>> >>>>> Hi, >>>>> >>>>> is there a way to write something as follow in rust? >>>>> >>>>> class matrix { >>>>> ... >>>>> float& Get(int r, int c) { return this.data[r + c*4]; } >>>>> } >>>>> >>>>> matrix m; >>>>> m.Get(0, 1) = 42.; >>>>> >>>>> >>>>> in trust, my struct matrix would have a method called Get, but what >>>>> would it return? >>>>> >>>>> struct Mat { >>>>> data:[float, ..16] >>>>> } >>>>> >>>>> impl Mat { >>>>> pub fn Get(&mut self, r:int, c:int) -> &mut float { >>>>> &self.data[r+c*4] >>>>> } >>>>> } >>>>> >>>>> >>>>> I get error messages about lifetime or about mutability >>>>> >>>>> est.rs:107:8: 107:24 error: mismatched types: expected `&mut float` >>>>> but found `&float` (values differ in mutability) >>>>> test.rs:107 &self.data[r*4+c] >>>>> ^~~~~~~~~~~~~~~~ >>>>> >>>>> >>>>> cheers, >>>>> >>>>> Remi >>>>> -- >>>>> R?mi Fontan : remifontan at yahoo.fr >>>>> mobile: +64 21 855 351 >>>>> 93 Otaki Street, Miramar 6022 >>>>> Wellington, New Zealand >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>>> >>> >>> >>> -- >>> R?mi Fontan : remifontan at yahoo.fr >>> mobile: +64 21 855 351 >>> 93 Otaki Street, Miramar 6022 >>> Wellington, New Zealand >>> >> >> > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Jun 24 05:17:54 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 24 Jun 2013 08:17:54 -0400 Subject: [rust-dev] rustdoc rewrite and redesign In-Reply-To: References: Message-ID: For those interested, I'll be logging my progress on this (and other things) at http://rustlog.octayn.net/ From pwalton at mozilla.com Mon Jun 24 08:26:27 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 24 Jun 2013 08:26:27 -0700 Subject: [rust-dev] Memory layout of types In-Reply-To: <51C80DF9.8090301@gmail.com> References: <51C80DF9.8090301@gmail.com> Message-ID: <51C86523.5060006@mozilla.com> On 6/24/13 2:14 AM, Michael Woerister wrote: > * There is the trans::adt module and the Repr enum which look very > promising. It does not provide all the information I need (e.g. it will > include generated fields, but does not explicitely specify where they > are located, just in comments (enum discriminant) or code (destroyedness > flag)). But otherwise it seems the place to go for a definite field list > of composite types. I think adt is the place for this kind of thing. Feel free to add additional functionality to it if you need. Patrick From michaelwoerister at gmail.com Mon Jun 24 09:10:20 2013 From: michaelwoerister at gmail.com (Michael Woerister) Date: Mon, 24 Jun 2013 18:10:20 +0200 Subject: [rust-dev] Memory layout of types In-Reply-To: <51C86523.5060006@mozilla.com> References: <51C80DF9.8090301@gmail.com> <51C86523.5060006@mozilla.com> Message-ID: <51C86F6C.4030401@gmail.com> On 06/24/2013 05:26 PM, Patrick Walton wrote: > On 6/24/13 2:14 AM, Michael Woerister wrote: >> * There is the trans::adt module and the Repr enum which look very >> promising. It does not provide all the information I need (e.g. it will >> include generated fields, but does not explicitely specify where they >> are located, just in comments (enum discriminant) or code (destroyedness >> flag)). But otherwise it seems the place to go for a definite field list >> of composite types. > > I think adt is the place for this kind of thing. Feel free to add > additional functionality to it if you need. Thanks Patrick! I will probably do that. It's not much that is needed here. This still leaves open the question of internal runtime structures, such as heap boxes, vecs, and possibly pointers. Unsafe and region pointers seem to be regular machine-word sized values, but I think I read somewhere that some pointers (to traits? something about sized-types?) included an additional word. If somebody can easily point me to some document or specific source code describing this, that would be great. If not, it's OK too, I can always find out by looking into the generated LLVM bitcode :-) -Michael From graydon at mozilla.com Mon Jun 24 10:28:16 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 24 Jun 2013 10:28:16 -0700 Subject: [rust-dev] Memory layout of types In-Reply-To: <51C86F6C.4030401@gmail.com> References: <51C80DF9.8090301@gmail.com> <51C86523.5060006@mozilla.com> <51C86F6C.4030401@gmail.com> Message-ID: <51C881B0.6070208@mozilla.com> On 13-06-24 09:10 AM, Michael Woerister wrote: > This still leaves open the question of internal runtime structures, such > as heap boxes, vecs, and possibly pointers. > Unsafe and region pointers seem to be regular machine-word sized values, > but I think I read somewhere that some pointers (to traits? something > about sized-types?) included an additional word. If somebody can easily > point me to some document or specific source code describing this, that > would be great. > If not, it's OK too, I can always find out by looking into the generated > LLVM bitcode :-) Sure. It's not entirely obvious. The main places to look are: src/rt/rust_type.h -- types used by C++ code, that LLVM-code matches src/rt/rust_util.h -- more types used by C++ code src/librustc/back/abi.rs -- *_field_* GEP-displacements of fields the compiler knows about src/librustc/middle/trans/adt.rs -- struct/tuple representations src/librustc/middle/trans/type_.rs -- LLVM TypeRef wrapper: Type src/librustc/middle/trans/type_of.rs -- lowers ty::t -> Type If you have more specific questions, please ask more either here or on IRC. And don't hesitate to file bugs or do cleanup while you're in there. The compiler needs a lot of tidying-up its internals. -Graydon From sh4.seo at samsung.com Mon Jun 24 10:53:37 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Mon, 24 Jun 2013 17:53:37 +0000 (GMT) Subject: [rust-dev] cross-file trait impls Message-ID: <8176639.74861372096417178.JavaMail.weblogic@epml01> > Can someone clarify what's going on here? You have multiple "mod file2" statements in the crate. This is probably not what you want. If you have "mod X" in two files, X::Y in those two files DO NOT refer to the same thing, but to two different things. Use "use" statements instead. From graydon at mozilla.com Mon Jun 24 12:02:55 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 24 Jun 2013 12:02:55 -0700 Subject: [rust-dev] tree maintenance In-Reply-To: <51BFB089.8020507@mozilla.com> References: <51BFB089.8020507@mozilla.com> Message-ID: <51C897DF.2010807@mozilla.com> On 13-06-17 05:57 PM, Graydon Hoare wrote: > Hi, > > As part of preparation for 0.7 (due around the end of june / early july) > we're going to be closing the tree for a while, fixing the lingering > breakage that's snuck through 'auto' and accumulated on 'master', and > greatly widening the 'auto' coverage such that this stuff doesn't build > up anymore. > > For now, bors is turned off and the tree is closed. Fear not though: > this should ultimately improve life for everyone. More coverage, better > differential testing, less chasing ghosts. > > Thanks for your patience. It'll be back asap (along with a snapshot!) Update on this: - The tree is open again (has been since thursday) - There are a whole lot more auto-builders now - Some are slower. Cycle time is (at least) 2h now, where it was formerly closer to 30 minutes. Valgrind is now in the loop, as is a cross-build. These two are the slowest configs. - They are not _as slow_ as they appeared at first; partly that was them warming up (building LLVM) and/or bring overloaded, taking as much as 5h. The successful runs now are 2h. - I believe we can get cycle time way down. I'd appreciate patience while we do this. Reverting to the previous arrangement meant we lost developers to bisection and burning-tree quests, which is even more frustrating than waiting on slow builds. - Especially this week: we're in pre-0.7-release mode and this is a Very Bad Time to be destabilizing stuff. Ways to adapt: - Some of the overloading is limited on real hardware, not EC2. We are waiting on some new minis to arrive. Yell at apple to let us virtualize OSX on clouds. - You may want to test a little more thoroughly before queueing stuff up. The queue is long and the habit of treating a PR as a smoketest is ... less rewarding now than it might have been. - You will also benefit from merging / batching trivial changes, for the time being. If you think you see 3 or 4 PRs that can be combined into one, doing so is a way you can help out. - Furthermore: bors happens to fail-to-run much more often when the queue is long (it fails when github has an API failure); so if you are _willing_ to merge PRs or take them out of the queue to wait until it's moving faster, or you have time to repair them (if they're bad or bitrotted), that'll help. - There are a lot of really bad codegen problems I will be making an effort to organize into bugs for people to work on soon. - I'm going to be spending today trying to adjust buildbot to ensure it overloads machines less often and cuts off builds that are redundant when it sees a failure. Daniel seems to have been doing this manually over the weekend but it needs automation. Thanks again for everyone's patience. I remain convinced that having automatic integration is worth much more than a free-for-all on the tree, but I realize staring at slow build and test cycles is a very trying experience for us all. -Graydon From thadguidry at gmail.com Mon Jun 24 12:19:27 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Mon, 24 Jun 2013 14:19:27 -0500 Subject: [rust-dev] tree maintenance In-Reply-To: <51C897DF.2010807@mozilla.com> References: <51BFB089.8020507@mozilla.com> <51C897DF.2010807@mozilla.com> Message-ID: > Thanks again for everyone's patience. I remain convinced that having > automatic integration is worth much more than a free-for-all on the tree, That alone is worth more than 20 new active developers, I would say. Thanks for your hard work on this Graydon, and team ! -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at gmail.com Mon Jun 24 14:46:07 2013 From: michaelwoerister at gmail.com (Michael Woerister) Date: Mon, 24 Jun 2013 23:46:07 +0200 Subject: [rust-dev] Memory layout of types In-Reply-To: <51C881B0.6070208@mozilla.com> References: <51C80DF9.8090301@gmail.com> <51C86523.5060006@mozilla.com> <51C86F6C.4030401@gmail.com> <51C881B0.6070208@mozilla.com> Message-ID: <51C8BE1F.8090001@gmail.com> On 06/24/2013 07:28 PM, Graydon Hoare wrote: > On 13-06-24 09:10 AM, Michael Woerister wrote: > >> This still leaves open the question of internal runtime structures, such >> as heap boxes, vecs, and possibly pointers. >> Unsafe and region pointers seem to be regular machine-word sized values, >> but I think I read somewhere that some pointers (to traits? something >> about sized-types?) included an additional word. If somebody can easily >> point me to some document or specific source code describing this, that >> would be great. >> If not, it's OK too, I can always find out by looking into the generated >> LLVM bitcode :-) > > Sure. It's not entirely obvious. The main places to look are: > > src/rt/rust_type.h -- types used by C++ code, that LLVM-code matches > src/rt/rust_util.h -- more types used by C++ code > src/librustc/back/abi.rs -- *_field_* GEP-displacements of fields the > compiler knows about > > src/librustc/middle/trans/adt.rs -- struct/tuple representations > src/librustc/middle/trans/type_.rs -- LLVM TypeRef wrapper: Type > src/librustc/middle/trans/type_of.rs -- lowers ty::t -> Type > > If you have more specific questions, please ask more either here or on > IRC. And don't hesitate to file bugs or do cleanup while you're in > there. The compiler needs a lot of tidying-up its internals. > > -Graydon > Thanks, this is very helpful. It had already stumbled upon rust_type.h, but rust_util.h and back/abi.rs are new to me. Regarding code cleanup, I've kept to trans/debuginfo.rs so far. However, as my understanding of the trans module gets better, I certainly plan to help out where I can. -Michael From dwrensha at cs.cmu.edu Mon Jun 24 14:49:44 2013 From: dwrensha at cs.cmu.edu (David Renshaw) Date: Mon, 24 Jun 2013 17:49:44 -0400 Subject: [rust-dev] cross-file trait impls In-Reply-To: <8176639.74861372096417178.JavaMail.weblogic@epml01> References: <8176639.74861372096417178.JavaMail.weblogic@epml01> Message-ID: Thanks. For the sake of completeness, here is the fixed version: ---- test-crate.rc ---- mod file1; mod file2; fn main() { file1::bar(); } ------ file1.rs -------- use file2::HasInt; struct X { x : int } impl HasInt for X { fn foo(&self) -> int { self.x } } pub fn bar() -> int { let x = X{x : 10}; x.foo() } ----- file2.rs ------ pub trait HasInt { fn foo(&self) -> int; } From corey at octayn.net Mon Jun 24 15:07:40 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 24 Jun 2013 18:07:40 -0400 Subject: [rust-dev] Great Renaming redux Message-ID: Hi all, I want to propagate the great renaming throughout the codebase. You can make your (and my) life easier by, when touching a file, doing the following: ``` use extra = std; // if you need to use std = core; ``` and then updating everything to use the proper names. Hopefully this will allow me to not majorly break everyone's PRs when the change lands, and all you will need to do is remove the extra `use`. I plan on doing this Friday afternoon/evening. The tree will be closed for it (thanks Graydon!) From evans at cs.virginia.edu Mon Jun 24 15:52:56 2013 From: evans at cs.virginia.edu (David Evans) Date: Mon, 24 Jun 2013 18:52:56 -0400 Subject: [rust-dev] Using Rust in an OS course In-Reply-To: <51C62762.4080403@mozilla.com> References: <51C4A06F.7010904@cs.virginia.edu> <51C62762.4080403@mozilla.com> Message-ID: <51C8CDC8.7040406@cs.virginia.edu> On 6/22/13 6:38 PM, Brian Anderson wrote: ... > I agree Rust would be great for presenting these issues since it is > designed to make the programmer understand the costs of abstractions, > but it also doesn't punish them for making errors in the various ways > that C does. I totally want this to happen but at this stage basing a > university course around Rust would be risky; I don't know anybody > teaching Rust so you would be way out on a limb. > Thanks, Brian! I'm willing to go a bit out on a limb here...but not all the way to the leaves. :) > I can imagine that students taking a systems-programming course based > around Rust would have to spend a fair bit of time learning how to cope > with Rust's novel semantics (affine types in particular). Hopefully > those hurdles would still be easier than managing the unsafety of C. Of > course there's also the risk of frustrating students with the large > number of compiler bugs still present in rustc. > I'm really more of a PL/security guy than an OS one - so, although the course is called "Operating Systems" in our curriculum, I don't mind if students are spending time in the course learning these things (at least the intellectually interesting parts of them, and hopefully any Rust quirks won't get in the way too much). > Not sure how useful they are for preparing a course, but Tim posted his > recent tutorial [slides], and there are some other slide decks floating > around. > > [slides]: http://catamorphism.org/Writing/Rust-Tutorial-tjc.pdf > Yes, this is better than the other ones I've seen. > Sorry this isn't so helpful, but I'm happy to offer any further assistance. > Great, thanks a bunch for the offer. I may take you up on this when I get a bit further along. Cheers, --- Dave > Regards, > Brian From graydon at mozilla.com Mon Jun 24 18:17:21 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 24 Jun 2013 18:17:21 -0700 Subject: [rust-dev] github security flaw, bors review Message-ID: <51C8EFA1.2020108@mozilla.com> Hi, Some clever folks on #rust have pointed out that there is a (somewhat) exploitable security flaw in the way bors consumes r+ comments. Specifically, github permits a repository owner, in some circumstances (which we can't quite figure out) to _edit comments of other people_ on commits in their repository. This means that the following attack scenario would work: DrEvil: Files a PR Reviewer: Comments "this is awful!" on PR head-commit DrEvil: Edits comment to "r+ p=100" and lands change So, to work around this I'll probably teach bors to require review comments in a different fashion, such as "r+ " on the PR itself, or similar. In the meantime, reviewers beware: anything you say on the head-commit of a PR can be rewritten by the submitter into an r+, so assume that "commenting _at all_ implies approval". -Graydon From danielmicay at gmail.com Mon Jun 24 19:05:50 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 24 Jun 2013 22:05:50 -0400 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C8EFA1.2020108@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> Message-ID: On Mon, Jun 24, 2013 at 9:17 PM, Graydon Hoare wrote: > Hi, > > Some clever folks on #rust have pointed out that there is a (somewhat) > exploitable security flaw in the way bors consumes r+ comments. > Specifically, github permits a repository owner, in some circumstances > (which we can't quite figure out) to _edit comments of other people_ on > commits in their repository. > > This means that the following attack scenario would work: > > > DrEvil: Files a PR > Reviewer: Comments "this is awful!" on PR head-commit > DrEvil: Edits comment to "r+ p=100" and lands change > > So, to work around this I'll probably teach bors to require review comments > in a different fashion, such as "r+ " on the PR itself, or similar. In > the meantime, reviewers beware: anything you say on the head-commit of a PR > can be rewritten by the submitter into an r+, so assume that "commenting _at > all_ implies approval". Also, not just the head commit because someone could reset and force push. :P From graydon at mozilla.com Mon Jun 24 20:15:55 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 24 Jun 2013 20:15:55 -0700 Subject: [rust-dev] github security flaw, bors review In-Reply-To: References: <51C8EFA1.2020108@mozilla.com> Message-ID: <51C90B6B.5050201@mozilla.com> On 13-06-24 07:05 PM, Daniel Micay wrote: > Also, not just the head commit because someone could reset and force push. :P Bors only pays attention to comments on the head commit, and comments on commits adhere to that specific sha1 only. This is intentional. The part where users can edit other people's comments is .. not. -Graydon From graydon at mozilla.com Mon Jun 24 20:17:24 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 24 Jun 2013 20:17:24 -0700 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C90B6B.5050201@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> <51C90B6B.5050201@mozilla.com> Message-ID: <51C90BC4.2080100@mozilla.com> On 13-06-24 08:15 PM, Graydon Hoare wrote: > On 13-06-24 07:05 PM, Daniel Micay wrote: > >> Also, not just the head commit because someone could reset and force >> push. :P > > Bors only pays attention to comments on the head commit, and comments on > commits adhere to that specific sha1 only. This is intentional. > > The part where users can edit other people's comments is .. not. I mean, maybe github thinks it's a great idea to edit other people's words. Maybe it was their intent. I was not aware of this "feature" and it works counter to the intended security design of bors. Hence this thread. -Graydon From steve at steveklabnik.com Mon Jun 24 20:56:58 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 24 Jun 2013 20:56:58 -0700 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C90BC4.2080100@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> <51C90B6B.5050201@mozilla.com> <51C90BC4.2080100@mozilla.com> Message-ID: It's a really useful GitHub feature; people submit bug reports to Rails without using the triple backticks all the time, and it's nice that I can just go ahead and fix their formatting. But yeah, this is bad. :/ From zack at z0w0.me Mon Jun 24 20:58:06 2013 From: zack at z0w0.me (Zack Corr) Date: Tue, 25 Jun 2013 13:58:06 +1000 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C8EFA1.2020108@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> Message-ID: Wouldn't an easier way to fix this (without having to change the way review comments are set out) just be to only allow track "r+" comments if they're unedited? Github seems to support this facility according to the API documentation (just check if created_at and updated_at are the same). If a reviewer wants to backtrack on their review confirmation they can just delete the comment. On Tue, Jun 25, 2013 at 11:17 AM, Graydon Hoare wrote: > Hi, > > Some clever folks on #rust have pointed out that there is a (somewhat) > exploitable security flaw in the way bors consumes r+ comments. > Specifically, github permits a repository owner, in some circumstances > (which we can't quite figure out) to _edit comments of other people_ on > commits in their repository. > > This means that the following attack scenario would work: > > > DrEvil: Files a PR > Reviewer: Comments "this is awful!" on PR head-commit > DrEvil: Edits comment to "r+ p=100" and lands change > > So, to work around this I'll probably teach bors to require review > comments in a different fashion, such as "r+ " on the PR itself, or > similar. In the meantime, reviewers beware: anything you say on the > head-commit of a PR can be rewritten by the submitter into an r+, so assume > that "commenting _at all_ implies approval". > > -Graydon > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack at z0w0.me Mon Jun 24 21:02:40 2013 From: zack at z0w0.me (Zack Corr) Date: Tue, 25 Jun 2013 14:02:40 +1000 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C8EFA1.2020108@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> Message-ID: Oops, accidentally sent that twice. Anyway, I just realised that the timestamp for editing is only accurate to a minute (from what I can see), so someone could easily write a script that automatically edits any comments by a reviewer (or just sticks by their emails and quickly edits it). So disregard my last idea. On Tue, Jun 25, 2013 at 11:17 AM, Graydon Hoare wrote: > Hi, > > Some clever folks on #rust have pointed out that there is a (somewhat) > exploitable security flaw in the way bors consumes r+ comments. > Specifically, github permits a repository owner, in some circumstances > (which we can't quite figure out) to _edit comments of other people_ on > commits in their repository. > > This means that the following attack scenario would work: > > > DrEvil: Files a PR > Reviewer: Comments "this is awful!" on PR head-commit > DrEvil: Edits comment to "r+ p=100" and lands change > > So, to work around this I'll probably teach bors to require review > comments in a different fashion, such as "r+ " on the PR itself, or > similar. In the meantime, reviewers beware: anything you say on the > head-commit of a PR can be rewritten by the submitter into an r+, so assume > that "commenting _at all_ implies approval". > > -Graydon > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From remifontan at yahoo.fr Tue Jun 25 03:18:06 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Tue, 25 Jun 2013 22:18:06 +1200 Subject: [rust-dev] howto: c++ reference in rust In-Reply-To: References: Message-ID: good to know. should I be reporting the bug to some sort of bug-report-system? R?mi On Mon, Jun 24, 2013 at 11:48 PM, Philipp Br?schweiler wrote: > Hi R?mi, > > Yes, this looks like a compiler bug to me. > > Cheers, > Philipp > > > On Mon, Jun 24, 2013 at 1:07 PM, R?mi Fontan wrote: > >> I have another example that puzzles me. >> >> struct Vec { x:float, y:float, z:float } >> impl Vec { >> pub fn getRef<'a>(&'a mut self, i:uint) -> &'a mut float { >> // if(i==0) { &mut self.x } >> // else if(i==1) { &mut self.x } >> // else {&mut self.x } >> >> match(i) { >> 0 => &mut self.x, >> 1 => &mut self.y, >> _ => &mut self.z >> } >> } >> } >> >> when compiling with match I get following errors : >> >> rustc test.rs -o test-test --test >> test.rs:122:17: 122:28 error: cannot infer an appropriate lifetime due >> to conflicting requirements >> test.rs:122 _ => &mut self.z >> ^~~~~~~~~~~ >> test.rs:121:17: 121:28 note: first, the lifetime must be contained by >> the expression at 121:17... >> test.rs:121 1 => &mut self.y, >> ^~~~~~~~~~~ >> test.rs:121:17: 121:28 note: ...due to the following expression >> test.rs:121 1 => &mut self.y, >> ^~~~~~~~~~~ >> test.rs:120:17: 120:28 note: but, the lifetime must also be contained by >> the expression at 120:17... >> test.rs:120 0 => &mut self.x, >> ^~~~~~~~~~~ >> test.rs:120:17: 120:28 note: ...due to the following expression >> test.rs:120 0 => &mut self.x, >> ^~~~~~~~~~~ >> error: aborting due to previous error >> make: *** [test-test] Error 101 >> >> >> >> but it compiles correctly with the if version. I don't understand why >> it's not behaving the same way. Actually I don't understand why the >> compiler is not capable of finding out about the life cycle on its own for >> this particular example. Could the life cycle of the return type of getRef >> be inferred from the lifecycle of the intersection of {self.x, self.y, >> self.z} ? >> >> cheers, >> >> R?mi >> >> >> >> >> On Mon, Jun 24, 2013 at 2:32 AM, Philipp Br?schweiler wrote: >> >>> Hi R?mi, >>> >>> Yes, the documentation of Rust is not very good at the moment. The >>> concept and syntax of lifetimes is explained in this and the following >>> chapter: >>> >>> >>> http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html#returning-borrowed-pointers >>> >>> The only single quotes are only used to declare literal characters, e.g. >>> 'c', and lifetime variables. >>> >>> Cheers, >>> Philipp >>> >>> >>> On Sun, Jun 23, 2013 at 12:03 PM, R?mi Fontan wrote: >>> >>>> thanks, it works. >>>> >>>> however it is not yet very clear to me how lifetime works in rust. is >>>> there a bit of doc that explain about the concept of lifetime and the >>>> syntax? >>>> >>>> is using a quote before the lifetime variable necessary? I realised >>>> that the first time I read the rust tutorial I saw a lot of variables with >>>> a quote in front of their name, I simply ignore that details and went >>>> ahead. Were there all lifetime variables? >>>> >>>> cheers, >>>> >>>> R?mi >>>> >>>> >>>> On Sat, Jun 22, 2013 at 8:47 PM, Philipp Br?schweiler >>> > wrote: >>>> >>>>> Hi R?mi, >>>>> >>>>> The problem in your code was that you have to return a &mut reference. >>>>> Here's a version of your code that works: >>>>> >>>>> ``` >>>>> >>>>> struct Mat { >>>>> data:[float, ..16] >>>>> } >>>>> >>>>> impl Mat { >>>>> pub fn new() -> Mat { >>>>> Mat { data: [0.0, ..16] } >>>>> } >>>>> pub fn Get<'a>(&'a mut self, r:int, c:int) -> &'a mut float { >>>>> &mut self.data[r+c*4] >>>>> } >>>>> } >>>>> >>>>> fn main() { >>>>> let mut a = Mat::new(); >>>>> *a.Get(0, 0) = 5.0; >>>>> println(fmt!("%?", a)); >>>>> } >>>>> ``` >>>>> >>>>> Note that besides taking an &mut reference, we have to tell the >>>>> compiler that the lifetime of that reference is the same as of the original >>>>> object, which is done by anotating both references with the same lifetime >>>>> variable ('a in this code). >>>>> >>>>> Cheers, >>>>> Philipp >>>>> >>>>> >>>>> On Sat, Jun 22, 2013 at 10:35 AM, R?mi Fontan wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> is there a way to write something as follow in rust? >>>>>> >>>>>> class matrix { >>>>>> ... >>>>>> float& Get(int r, int c) { return this.data[r + c*4]; } >>>>>> } >>>>>> >>>>>> matrix m; >>>>>> m.Get(0, 1) = 42.; >>>>>> >>>>>> >>>>>> in trust, my struct matrix would have a method called Get, but what >>>>>> would it return? >>>>>> >>>>>> struct Mat { >>>>>> data:[float, ..16] >>>>>> } >>>>>> >>>>>> impl Mat { >>>>>> pub fn Get(&mut self, r:int, c:int) -> &mut float { >>>>>> &self.data[r+c*4] >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> I get error messages about lifetime or about mutability >>>>>> >>>>>> est.rs:107:8: 107:24 error: mismatched types: expected `&mut float` >>>>>> but found `&float` (values differ in mutability) >>>>>> test.rs:107 &self.data[r*4+c] >>>>>> ^~~~~~~~~~~~~~~~ >>>>>> >>>>>> >>>>>> cheers, >>>>>> >>>>>> Remi >>>>>> -- >>>>>> R?mi Fontan : remifontan at yahoo.fr >>>>>> mobile: +64 21 855 351 >>>>>> 93 Otaki Street, Miramar 6022 >>>>>> Wellington, New Zealand >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> Rust-dev at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> R?mi Fontan : remifontan at yahoo.fr >>>> mobile: +64 21 855 351 >>>> 93 Otaki Street, Miramar 6022 >>>> Wellington, New Zealand >>>> >>> >>> >> >> >> -- >> R?mi Fontan : remifontan at yahoo.fr >> mobile: +64 21 855 351 >> 93 Otaki Street, Miramar 6022 >> Wellington, New Zealand >> > > -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnkfelix at mozilla.com Tue Jun 25 05:48:54 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Tue, 25 Jun 2013 14:48:54 +0200 Subject: [rust-dev] howto: c++ reference in rust In-Reply-To: References: Message-ID: <51C991B6.3040200@mozilla.com> R?mi (cc'ing Philipp and rust-dev list)- We track bugs, work-items, and (some) feature requests here: https://github.com/mozilla/rust/issues Cheers, -Felix On 25/06/2013 12:18, R?mi Fontan wrote: > good to know. should I be reporting the bug to some sort of > bug-report-system? > > R?mi > > > On Mon, Jun 24, 2013 at 11:48 PM, Philipp Br?schweiler > > wrote: > > Hi R?mi, > > Yes, this looks like a compiler bug to me. > > Cheers, > Philipp > > > On Mon, Jun 24, 2013 at 1:07 PM, R?mi Fontan > wrote: > > I have another example that puzzles me. > > struct Vec { x:float, y:float, z:float } > impl Vec { > pub fn getRef<'a>(&'a mut self, i:uint) -> &'a mut float { > // if(i==0) { &mut self.x } > // else if(i==1) { &mut self.x } > // else {&mut self.x } > match(i) { > 0 => &mut self.x, > 1 => &mut self.y, > _ => &mut self.z > } > } > } > > when compiling with match I get following errors : > > rustc test.rs -o test-test --test > test.rs:122:17: 122:28 error: cannot infer an appropriate > lifetime due to conflicting requirements > test.rs:122 _ => &mut self.z > ^~~~~~~~~~~ > test.rs:121:17: 121:28 note: first, the lifetime must be > contained by the expression at 121:17... > test.rs:121 1 => &mut self.y, > ^~~~~~~~~~~ > test.rs:121:17: 121:28 note: ...due to the following expression > test.rs:121 1 => &mut self.y, > ^~~~~~~~~~~ > test.rs:120:17: 120:28 note: but, the lifetime must also be > contained by the expression at 120:17... > test.rs:120 0 => &mut self.x, > ^~~~~~~~~~~ > test.rs:120:17: 120:28 note: ...due to the following expression > test.rs:120 0 => &mut self.x, > ^~~~~~~~~~~ > error: aborting due to previous error > make: *** [test-test] Error 101 > > > > but it compiles correctly with the if version. I don't > understand why it's not behaving the same way. Actually I > don't understand why the compiler is not capable of finding > out about the life cycle on its own for this particular > example. Could the life cycle of the return type of getRef be > inferred from the lifecycle of the intersection of {self.x, > self.y, self.z} ? > > cheers, > > R?mi > > > > > On Mon, Jun 24, 2013 at 2:32 AM, Philipp Br?schweiler > > wrote: > > Hi R?mi, > > Yes, the documentation of Rust is not very good at the > moment. The concept and syntax of lifetimes is explained > in this and the following chapter: > > http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html#returning-borrowed-pointers > > The only single quotes are only used to declare literal > characters, e.g. 'c', and lifetime variables. > > Cheers, > Philipp > > > On Sun, Jun 23, 2013 at 12:03 PM, R?mi Fontan > > wrote: > > thanks, it works. > > however it is not yet very clear to me how lifetime > works in rust. is there a bit of doc that explain > about the concept of lifetime and the syntax? > > is using a quote before the lifetime variable > necessary? I realised that the first time I read the > rust tutorial I saw a lot of variables with a quote in > front of their name, I simply ignore that details and > went ahead. Were there all lifetime variables? > > cheers, > > R?mi > > > On Sat, Jun 22, 2013 at 8:47 PM, Philipp Br?schweiler > > wrote: > > Hi R?mi, > > The problem in your code was that you have to > return a &mut reference. Here's a version of your > code that works: > > ``` > > struct Mat { > data:[float, ..16] > } > > impl Mat { > pub fn new() -> Mat { > Mat { data: [0.0, ..16] } > } > pub fn Get<'a>(&'a mut self, r:int, c:int) -> > &'a mut float { > &mut self.data[r+c*4] > } > } > > fn main() { > let mut a = Mat::new(); > *a.Get(0, 0) = 5.0; > println(fmt!("%?", a)); > } > ``` > > Note that besides taking an &mut reference, we > have to tell the compiler that the lifetime of > that reference is the same as of the original > object, which is done by anotating both references > with the same lifetime variable ('a in this code). > > Cheers, > Philipp > > > On Sat, Jun 22, 2013 at 10:35 AM, R?mi Fontan > > > wrote: > > Hi, > > is there a way to write something as follow in > rust? > > class matrix { > ... > float& Get(int r, int c) { return > this.data[r + c*4]; } > } > > matrix m; > m.Get(0, 1) = 42.; > > > in trust, my struct matrix would have a method > called Get, but what would it return? > > struct Mat { > data:[float, ..16] > } > > impl Mat { > pub fn Get(&mut self, r:int, c:int) -> > &mut float { > &self.data[r+c*4] > } > } > > > I get error messages about lifetime or about > mutability > > est.rs:107:8: 107:24 error: mismatched types: > expected `&mut float` but found `&float` > (values differ in mutability) > test.rs:107 &self.data[r*4+c] > ^~~~~~~~~~~~~~~~ > > > cheers, > > Remi > -- > R?mi Fontan : remifontan at yahoo.fr > > mobile: +64 21 855 351 > > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > R?mi Fontan : remifontan at yahoo.fr > > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > > > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > > > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.boggiano at seld.be Tue Jun 25 06:39:19 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Tue, 25 Jun 2013 15:39:19 +0200 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C90BC4.2080100@mozilla.com> References: <51C8EFA1.2020108@mozilla.com> <51C90B6B.5050201@mozilla.com> <51C90BC4.2080100@mozilla.com> Message-ID: <51C99D87.20002@seld.be> On 25.06.2013 05:17, Graydon Hoare wrote: > On 13-06-24 08:15 PM, Graydon Hoare wrote: >> On 13-06-24 07:05 PM, Daniel Micay wrote: >> >>> Also, not just the head commit because someone could reset and force >>> push. :P >> >> Bors only pays attention to comments on the head commit, and comments on >> commits adhere to that specific sha1 only. This is intentional. >> >> The part where users can edit other people's comments is .. not. > > I mean, maybe github thinks it's a great idea to edit other people's > words. Maybe it was their intent. I was not aware of this "feature" and > it works counter to the intended security design of bors. Hence this > thread. I don't really know the existing system, but how about you change it to read comments on the pull request and not the commits? Those comments can only be edited by repo owners of the pull request target, and those people already have access to the merge button so there is very little risk for abuse I imagine. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From pshagl007 at gmail.com Tue Jun 25 12:17:17 2013 From: pshagl007 at gmail.com (piyush agarwal) Date: Wed, 26 Jun 2013 00:47:17 +0530 Subject: [rust-dev] task failed at borrowed Message-ID: Hi all, When I run this code fn main() { let mut x = @mut 2; let y = x; { let z = & *y; x = @mut 3; io::println(fmt!("%?" , y)); *y = 5; io::println(fmt!("%?" , y)); } } following occurs. rust: task failed at 'borrowed', ???:0 rust: domain main @0xef89c0 root task failed can anyone explain? (using compiler 0.6 ) -- Piyush Agarwal Please don?t print this e-mail unless you really need to! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsteinbr at gmail.com Tue Jun 25 12:40:53 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Tue, 25 Jun 2013 21:40:53 +0200 Subject: [rust-dev] task failed at borrowed In-Reply-To: References: Message-ID: <20130625194053.GB23301@atjola.homenet> Hi, On 2013.06.26 00:47:17 +0530, piyush agarwal wrote: > Hi all, > > When I run this code > > fn main() { > let mut x = @mut 2; > let y = x; > { > let z = & *y; Here, you get a borrowed pointer to the managed value in y. This "freezes" the value, which means that as long as the borrowed pointer is in scope, you're not allowed to change the value. For managed values, this is checked at runtime. > x = @mut 3; > io::println(fmt!("%?" , y)); > *y = 5; Here, you're trying to change the value that has been frozen, violating the rules, and the dynamic borrow checker has identified this violation. See http://smallcultfollowing.com/babysteps/blog/2012/11/18/imagine-never-hearing-the-phrase-aliasable/ HTH Bj?rn From danielmicay at gmail.com Tue Jun 25 13:12:05 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 25 Jun 2013 16:12:05 -0400 Subject: [rust-dev] github security flaw, bors review In-Reply-To: <51C99D87.20002@seld.be> References: <51C8EFA1.2020108@mozilla.com> <51C90B6B.5050201@mozilla.com> <51C90BC4.2080100@mozilla.com> <51C99D87.20002@seld.be> Message-ID: On Tue, Jun 25, 2013 at 9:39 AM, Jordi Boggiano wrote: > On 25.06.2013 05:17, Graydon Hoare wrote: >> On 13-06-24 08:15 PM, Graydon Hoare wrote: >>> On 13-06-24 07:05 PM, Daniel Micay wrote: >>> >>>> Also, not just the head commit because someone could reset and force >>>> push. :P >>> >>> Bors only pays attention to comments on the head commit, and comments on >>> commits adhere to that specific sha1 only. This is intentional. >>> >>> The part where users can edit other people's comments is .. not. >> >> I mean, maybe github thinks it's a great idea to edit other people's >> words. Maybe it was their intent. I was not aware of this "feature" and >> it works counter to the intended security design of bors. Hence this >> thread. > > I don't really know the existing system, but how about you change it to > read comments on the pull request and not the commits? Those comments > can only be edited by repo owners of the pull request target, and those > people already have access to the merge button so there is very little > risk for abuse I imagine. > > Cheers > > -- > Jordi Boggiano > @seldaek - http://nelm.io/jordi They're a review of a specific commit, so they would need to refer to a hash. From catamorphism at gmail.com Tue Jun 25 14:25:14 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue, 25 Jun 2013 14:25:14 -0700 Subject: [rust-dev] tjc's pre-talk and talk (was: This Week in Rust) In-Reply-To: References: Message-ID: Thanks for pointing out these issues! On Sat, Jun 22, 2013 at 9:26 AM, Ashish Myles wrote: > POSSIBLE ERRATA: > > Slide 40: > The notes say "Change [@Drawable] to [~@Drawable]". The latter should be > ~[@Drawable], or, to be consistent with the Slide 41, perhaps > &[@Drawable]? Both tested to work. > Typo, I'm about to upload a fixed copy. > Slide 51: > The program seems to be missing a unique pointer sigil ~; and the types of > the array and the initializer ("quux") don't match. Here is a possible > correction? (Tested.) > > fn h(b: ~[int]) { } > fn g(a: ~[int]) { } > fn f(n: uint) { > let v: ~[int] = vec::from_elem(n,1); > h(v); > g(v); > } Ditto. > > Slide 53: > Perhaps the audio is needed for this slide, but I am confused. Before I > start with that, I checked > struct Cat { > a : int, > } > fn main() { > let v: Cat::new(); > } > It seems that there is no default new() function, so I don't know the > type of the object returned by Cat::new(). Is it Cat or ~Cat here? > > The comment about Cat not being copyable seems to imply that the type is > Cat (i.e. stack-allocated). But then send_cat_to_moon(cat) should not be > able to invalidate the reference, right? So there should not be a problem > with that code as webcam should get destructed before cat at the end of > the block. > > If Cat::new() returns ~Cat and Webcam::new() returns ~Webcam, then I can > see this working out, but then there is the implicit assumption (that > could perhaps be clarified in the comments) that send_cat_to_moon(cat) > takes its argument as ~Cat rather than, say, &Cat. Since this example was just meant to illustrate a potential problem, there are several things about it that aren't valid Rust. I tried to add more comments in the note beneath the slide explaining that. The definitions of the constructors/static methods for WebCam and Cat are omitted, and presumably Cat has some fields that I left out because they're not needed for understanding the problem. In particular, Cat could have fields that are non-copyable, even if its constructor returns a Cat (and not a ~Cat). Thanks for your interest! Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From danielmicay at gmail.com Tue Jun 25 20:44:10 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 25 Jun 2013 23:44:10 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) Message-ID: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> This is a followup from the previous discussion on internal vs. external iterators.[1] Since then, most iterators in the standard library have been converted to external ones. Almost all uses of the `for` loop are now using the `.advance` wrapper, and I don't think there will be any use cases left for the old internal iteration protocol. # External iterators To reiterate the benefits of the external iteration protocol: * It's generic and works well with traits, so functions can be written to work on any arbitrary `Iterator`. Most adaptors can work for any type `A`, whether it's a value, reference or mutable reference. * Iteration state is an object, so iterators can be interleaved. This is required for a generic zip, merge, union, intersect, etc. and is often useful in an ad-hoc fashion to consume only some of an iterator without losing it. * In the future, Rust can have generators using a `yield` statement like C#, compiling down to a fast state machine without requiring context switches, virtual functions or even closures. This would eliminate the difficulty of coding recursive traversals by-hand with external iterators. # Alternatives The iteration protocol can't be based on anything requiring virtual method calls, heap allocations or context switches without the performance becoming significantly worse. There have been some suggestions about following the lead of Clojure and using reducers[2], but the implementation suffers from the same limitations of not having an external state. Rust doesn't yet have a way to write data-parallel code, but when it does gain that, containers can just support partitioning themselves into ranges via `Iterator`. It will work for in-place mutation in parallel too. # A new loop I think it's a foregone conclusion that we'll be replacing `for`, so I suggest that we just reuse the current syntax and change the semantics: for iterator |pattern| { body } This can just be compiled as the following would be: let mut it = iterator; loop { match it.next() { Some(pattern) => { body } None => break } } A lang item can be added for the Iterator trait requirement. This would avoid the `.advance` tacked onto almost every `for` loop at the moment, and rid us of the problems associated with the current `for`: * The `break` and `return` statements can fail to work, so borrow/liveness checking can't trust them. A loop body can't take an `&mut` reference and return it because it could result in grabbing the reference again. This also seems to be why we forbid `return` inside closures and do statements, since it would be confusing to have to act differently than `for`. * The function's local variables are upvars in the closure, so using them is very restricted. It's very obvious that it's not just another block because of this. * Compiling closures is slow, as they have to broken down by SROA and involve inlining a function after proving the function pointer is constant. If we were marking the function pointers as `llvm.invariant` it might stop being a performance hit, but it would remain a compile time issue. # Iterables The `for` loop above can also be extended to work for *any* `Iterable` in the future, not just iterators themselves. for iterable |x| { ... } // use the default iterator for iterable.rev_iter |x| { ... } // use another iterator At the moment, the `Iterable` trait cannot be defined/used because the compiler ignores bounds on trait type parameters, but it would be something like the following: #[lang = "iterable"] trait Iterable> { fn iter(&self) -> T; } trait ReverseIterable> { fn rev_iter(&self) -> T; } trait MutableIterable> { fn mut_iter(&mut self) -> T; } trait MutableReverseIterable> { fn mut_rev_iter(&mut self) -> T; } # Links [1]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html [2]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25#iterators -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From tkuehn at mozilla.com Wed Jun 26 12:44:06 2013 From: tkuehn at mozilla.com (Timothy Kuehn) Date: Wed, 26 Jun 2013 12:44:06 -0700 (PDT) Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> What motivates your suggestion to keep the syntax the same? I think it's confusing that it looks like a closure but is functionally different from one. I remember seeing suggestions to change it to " for pattern in iterator. " Besides being less confusing, I think it simply looks nicer. ----- Original Message ----- From: "Daniel Micay" To: rust-dev at mozilla.org Sent: Tuesday, June 25, 2013 8:44:10 PM Subject: [rust-dev] Language support for external iterators (new for loop) This is a followup from the previous discussion on internal vs. external iterators.[1] Since then, most iterators in the standard library have been converted to external ones. Almost all uses of the `for` loop are now using the `.advance` wrapper, and I don't think there will be any use cases left for the old internal iteration protocol. # External iterators To reiterate the benefits of the external iteration protocol: * It's generic and works well with traits, so functions can be written to work on any arbitrary `Iterator`. Most adaptors can work for any type `A`, whether it's a value, reference or mutable reference. * Iteration state is an object, so iterators can be interleaved. This is required for a generic zip, merge, union, intersect, etc. and is often useful in an ad-hoc fashion to consume only some of an iterator without losing it. * In the future, Rust can have generators using a `yield` statement like C#, compiling down to a fast state machine without requiring context switches, virtual functions or even closures. This would eliminate the difficulty of coding recursive traversals by-hand with external iterators. # Alternatives The iteration protocol can't be based on anything requiring virtual method calls, heap allocations or context switches without the performance becoming significantly worse. There have been some suggestions about following the lead of Clojure and using reducers[2], but the implementation suffers from the same limitations of not having an external state. Rust doesn't yet have a way to write data-parallel code, but when it does gain that, containers can just support partitioning themselves into ranges via `Iterator`. It will work for in-place mutation in parallel too. # A new loop I think it's a foregone conclusion that we'll be replacing `for`, so I suggest that we just reuse the current syntax and change the semantics: for iterator |pattern| { body } This can just be compiled as the following would be: let mut it = iterator; loop { match it.next() { Some(pattern) => { body } None => break } } A lang item can be added for the Iterator trait requirement. This would avoid the `.advance` tacked onto almost every `for` loop at the moment, and rid us of the problems associated with the current `for`: * The `break` and `return` statements can fail to work, so borrow/liveness checking can't trust them. A loop body can't take an `&mut` reference and return it because it could result in grabbing the reference again. This also seems to be why we forbid `return` inside closures and do statements, since it would be confusing to have to act differently than `for`. * The function's local variables are upvars in the closure, so using them is very restricted. It's very obvious that it's not just another block because of this. * Compiling closures is slow, as they have to broken down by SROA and involve inlining a function after proving the function pointer is constant. If we were marking the function pointers as `llvm.invariant` it might stop being a performance hit, but it would remain a compile time issue. # Iterables The `for` loop above can also be extended to work for *any* `Iterable` in the future, not just iterators themselves. for iterable |x| { ... } // use the default iterator for iterable.rev_iter |x| { ... } // use another iterator At the moment, the `Iterable` trait cannot be defined/used because the compiler ignores bounds on trait type parameters, but it would be something like the following: #[lang = "iterable"] trait Iterable> { fn iter(&self) -> T; } trait ReverseIterable> { fn rev_iter(&self) -> T; } trait MutableIterable> { fn mut_iter(&mut self) -> T; } trait MutableReverseIterable> { fn mut_rev_iter(&mut self) -> T; } # Links [1]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html [2]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25#iterators _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Jun 26 12:45:20 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 26 Jun 2013 15:45:20 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> Message-ID: On Wed, Jun 26, 2013 at 3:44 PM, Timothy Kuehn wrote: > What motivates your suggestion to keep the syntax the same? I think it's > confusing that it looks like a closure but is functionally different from > one. I remember seeing suggestions to change it to "for pattern in > iterator." Besides being less confusing, I think it simply looks nicer. Changing the syntax should be a separate breaking change, if it's going to happen. It would make it a *lot* harder to land this and I think we need this ASAP. From ben.striegel at gmail.com Wed Jun 26 13:13:32 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 26 Jun 2013 16:13:32 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> Message-ID: Yes, let's not get bogged down with syntax discussions until the important semantic changes have landed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uther.ii at gmail.com Wed Jun 26 13:29:56 2013 From: uther.ii at gmail.com (Uther) Date: Wed, 26 Jun 2013 22:29:56 +0200 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> Message-ID: <51CB4F44.3010607@gmail.com> The proposed syntax already a breaking change, isn't it? The "for x in iterable { }" syntax could live along the old "for iterable.each |x| {}" syntax, making the transition easier. >> What motivates your suggestion to keep the syntax the same? I think it's >> confusing that it looks like a closure but is functionally different from >> one. I remember seeing suggestions to change it to "for pattern in >> iterator." Besides being less confusing, I think it simply looks nicer. > Changing the syntax should be a separate breaking change, if it's > going to happen. It would make it a *lot* harder to land this and I > think we need this ASAP. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Wed Jun 26 13:41:31 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 26 Jun 2013 16:41:31 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51CB4F44.3010607@gmail.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <533219007.330497.1372275846464.JavaMail.zimbra@mozilla.com> <51CB4F44.3010607@gmail.com> Message-ID: On Wed, Jun 26, 2013 at 4:29 PM, Uther wrote: > The proposed syntax already a breaking change, isn't it? > > The "for x in iterable { }" syntax could live along the old "for > iterable.each |x| {}" syntax, > making the transition easier. The proposed change can be done by making `advance` the identity function and having the compiler build in both stage0 (old for loop) and stage1/stage2 (new for loop). Changing the syntax of the for loop would be a lot harder... it shouldn't be tied to this important semantic change. From garethdanielsmith at gmail.com Wed Jun 26 15:49:07 2013 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Wed, 26 Jun 2013 23:49:07 +0100 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: <51CB6FE3.6030400@gmail.com> One downside of external iterators is that they produce function signatures that expose implementation details and are harder to understand. For example, an internal iterator function that loops over odd numbers would have a signature like this: fn each_odd(ints: &[int], fn(int) -> bool) -> bool; The same function written to produce an external iterator would have a signature more like this: fn iter_odds<'a>(ints: &'a [int]) -> iterator::FilterMapIterator<'a, &int, int, vec::VecIterator<'a, int>>; This signature is more complicated. It is also likely to change if the implementation of iter_odds changes (e.g. to no longer use filter_map). Gareth On 26/06/13 04:44, Daniel Micay wrote: > This is a followup from the previous discussion on internal vs. external > iterators.[1] > > Since then, most iterators in the standard library have been converted to > external ones. Almost all uses of the `for` loop are now using the `.advance` > wrapper, and I don't think there will be any use cases left for the old > internal iteration protocol. > > # External iterators > > To reiterate the benefits of the external iteration protocol: > > * It's generic and works well with traits, so functions can be written to work > on any arbitrary `Iterator`. Most adaptors can work for any type `A`, > whether it's a value, reference or mutable reference. > > * Iteration state is an object, so iterators can be interleaved. This is > required for a generic zip, merge, union, intersect, etc. and is often useful > in an ad-hoc fashion to consume only some of an iterator without > losing it. > > * In the future, Rust can have generators using a `yield` statement like C#, > compiling down to a fast state machine without requiring context switches, > virtual functions or even closures. This would eliminate the difficulty of > coding recursive traversals by-hand with external iterators. > > # Alternatives > > The iteration protocol can't be based on anything requiring virtual method > calls, heap allocations or context switches without the performance becoming > significantly worse. > > There have been some suggestions about following the lead of Clojure and using > reducers[2], but the implementation suffers from the same limitations of not > having an external state. > > Rust doesn't yet have a way to write data-parallel code, but when it does gain > that, containers can just support partitioning themselves into ranges via > `Iterator`. It will work for in-place mutation in parallel too. > > # A new loop > > I think it's a foregone conclusion that we'll be replacing `for`, so I suggest > that we just reuse the current syntax and change the semantics: > > for iterator |pattern| { body } > > This can just be compiled as the following would be: > > let mut it = iterator; > loop { > match it.next() { > Some(pattern) => { body } > None => break > } > } > > A lang item can be added for the Iterator trait requirement. > > This would avoid the `.advance` tacked onto almost every `for` loop at the > moment, and rid us of the problems associated with the current `for`: > > * The `break` and `return` statements can fail to work, so borrow/liveness > checking can't trust them. A loop body can't take an `&mut` reference and > return it because it could result in grabbing the reference again. This also > seems to be why we forbid `return` inside closures and do statements, since it > would be confusing to have to act differently than `for`. > > * The function's local variables are upvars in the closure, so using them is > very restricted. It's very obvious that it's not just another block because > of this. > > * Compiling closures is slow, as they have to broken down by SROA and involve > inlining a function after proving the function pointer is constant. If we > were marking the function pointers as `llvm.invariant` it might stop being a > performance hit, but it would remain a compile time issue. > > # Iterables > > The `for` loop above can also be extended to work for *any* `Iterable` in the > future, not just iterators themselves. > > for iterable |x| { ... } // use the default iterator > for iterable.rev_iter |x| { ... } // use another iterator > > At the moment, the `Iterable` trait cannot be defined/used because the compiler > ignores bounds on trait type parameters, but it would be something like the > following: > > #[lang = "iterable"] > trait Iterable> { > fn iter(&self) -> T; > } > > trait ReverseIterable> { > fn rev_iter(&self) -> T; > } > > trait MutableIterable> { > fn mut_iter(&mut self) -> T; > } > > trait MutableReverseIterable> { > fn mut_rev_iter(&mut self) -> T; > } > > # Links > > [1]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html > [2]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25#iterators > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Jun 26 16:09:01 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 26 Jun 2013 19:09:01 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51CB6FE3.6030400@gmail.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> Message-ID: On Wed, Jun 26, 2013 at 6:49 PM, Gareth Smith wrote: > One downside of external iterators is that they produce function signatures > that expose implementation details and are harder to understand. > > For example, an internal iterator function that loops over odd numbers would > have a signature like this: > > fn each_odd(ints: &[int], fn(int) -> bool) -> bool; > > The same function written to produce an external iterator would have a > signature more like this: > > fn iter_odds<'a>(ints: &'a [int]) -> iterator::FilterMapIterator<'a, &int, > int, vec::VecIterator<'a, int>>; > > This signature is more complicated. It is also likely to change if the > implementation of iter_odds changes (e.g. to no longer use filter_map). You can implement a struct and make the fields private, no need to expose the implementation details. A syntax for generators with `yield` would do this for you. From slabode at aim.com Thu Jun 27 14:39:50 2013 From: slabode at aim.com (SiegeLord) Date: Thu, 27 Jun 2013 17:39:50 -0400 Subject: [rust-dev] rustpkg use scenarios Message-ID: <51CCB126.60909@aim.com> I've been trying to understand how rustpkg is meant to be used, and I found that it didn't quite mesh with my experience with other package management systems. Since it's quite incomplete and under-documented, instead of trying to comment on the status quo, I decided its best to form a few scenarios of usage, and hopefully have the people who understand where rustpkg is going help me to see if these scenarios are going to be possible (or if not, what's wrong with them). To that end, the syntax for rustpkg will be my own and not the current syntax. Prelude 1: 1 Package != 1 crate. I think a package should be able to contain several crates. E.g. Debian packages routinely contain multiple binaries/libraries etc. Prelude 2: Package source != package name. Regardless of where you get the package from and no matter what the package file name was, the package metadata (name/author/version) should not be affected, and should be the only things that determine the identity of the package. I don't think these things are inferrable, so I envision a metadata file with all those things specified. Each package in these scenarios is named 'bar' and has a 'baz' crate. Scenario 1: Installation from a package file Given a package file foo.zip, I want to be able to do this: sudo rustpkg install foo.zip This would install it to /usr/local. `--prefix` switch would specify where to install it (perhaps something more clever can be done here for the sake of Windows). You should be able to install multiple packages with the same name but different authors/versions, e.g this should install two separate packages if their metadata are different. rustpkg install ~/dir1/foo.zip rustpkg install ~/dir2/foo.zip Scenario 2: Installation from an appropriately structured directory Same thing should work with a local directory. rustpkg install ~/foo ...and a remote one (like a github repository): rustpkg install https://github.com/user/foo.git --branch master If nothing is specified, it uses the current directory. Scenario 3: Uninstallation This should work if there's only one bar. rustpkg uninstall --package bar If there are multiple bar's, (different metadata) then you should be able to disambiguate between them: rustpkg uninstall --author Author --package bar Or you can specify a package file here as well, instead of a package name. Scenario 4: Fetching/building without installation Building without installing: rustpkg build If you then run `rustpkg install ` or `rustpkg install --package bar`, then it'll use that pre-built copy without fetching the sources and building them again. Speaking of fetching, this would just fetch the sources: rustpkg fetch Scenario 5: Specifying a workspace All of the above commands used some system workspace to store the intermediate files. You should also be able to specify a custom workspace, e.g. for the sake of development: rustpkg build --workspace . That command would fetch into the local directory as well as building in it. -SL From graydon at mozilla.com Thu Jun 27 15:14:26 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 27 Jun 2013 15:14:26 -0700 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCB126.60909@aim.com> References: <51CCB126.60909@aim.com> Message-ID: <51CCB942.7060207@mozilla.com> On 13-06-27 02:39 PM, SiegeLord wrote: > I've been trying to understand how rustpkg is meant to be used, and I > found that it didn't quite mesh with my experience with other package > management systems. Since it's quite incomplete and under-documented, > instead of trying to comment on the status quo, I decided its best to > form a few scenarios of usage, and hopefully have the people who > understand where rustpkg is going help me to see if these scenarios are > going to be possible (or if not, what's wrong with them). To that end, > the syntax for rustpkg will be my own and not the current syntax. Rustpkg does have some documentation. It's sparse and additions would certainly be welcome. I suggest reading over the existing docs and discussions: https://github.com/mozilla/rust/blob/master/doc/rustpkg.md https://github.com/mozilla/rust/wiki/Bikeshed-rustpkg https://mail.mozilla.org/pipermail/rust-dev/2013-February/003200.html I'll try to answer your preludes and scenarios based on what I know of it, but please understand that there are a _lot_ of competing tensions on rustpkg and not every user's intuitions are immediately met on first encounter. Rather than redesign it (again) at this late a phase, I'd like to see it completed and deployed, and adjusted as-needed based on experience. > Prelude 1: > > 1 Package != 1 crate. I think a package should be able to contain > several crates. E.g. Debian packages routinely contain multiple > binaries/libraries etc. This is true in the design we're currently working on. > > Prelude 2: > > Package source != package name. Regardless of where you get the package > from and no matter what the package file name was, the package metadata > (name/author/version) should not be affected, and should be the only > things that determine the identity of the package. I don't think these > things are inferrable, so I envision a metadata file with all those > things specified. This is currently not true in the design we're working on. Or .. not exactly. Packages are given a pkgid, which is a URL-fragment-like name. It is _not_ a complete URL, but it's most of one, and it's standing in for having separate metadata. It is enough that: - It can be globally unambiguous by beginning with a DNS name - It can be locally overridden by prepending some local prefix - It may also be able to hint rustpkg at an internet access method This does not mean that you must fetch a package named "github.com/graydon/foo" from github.com, but it means that if you don't have any other source for that package, you can guess at where to get it. And it has a unique name (assuming you decide to use that fact). This was chosen very carefully, very intentionally, and (for the time being) we're not revisiting this choice. We experimented before with having multiple points of name-indirection or metadata and it appears to have just annoyed and confused everyone. > Scenario 1: Installation from a package file I don't think this is on the current work list. It might be at some point. It won't be especially hard, but neither is it hard to just unpack a package in a workspace and build it using the existing directory-based approach. It is not installing to /usr/local or any filesystem global location by default. It is intended to localize dependencies (in terms of using nearby directories) as much as possible by default. > Scenario 2: Installation from an appropriately structured directory In these cases, you pass a pkgid and it finds an installation candidate using RUST_PATH. If it can't find a candidate it guesses an access method for a remote from the pkgid and pulls that into the first entry in RUST_PATH. > Scenario 3: Uninstallation I don't think this is on the current work list but it's not hard. > Scenario 4: Fetching/building without installation This is in the current work list. I do not think fetch is separate from build, but it might be. Tim will know more. > Scenario 5: Specifying a workspace Workspaces (each of which contains subdirectories for sources, builds and installed binaries, per-package) are specified by RUST_PATH in the current design. -Graydon From slabode at aim.com Thu Jun 27 18:34:39 2013 From: slabode at aim.com (SiegeLord) Date: Thu, 27 Jun 2013 21:34:39 -0400 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCB942.7060207@mozilla.com> References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> Message-ID: <51CCE82F.1000006@aim.com> On 06/27/2013 06:14 PM, Graydon Hoare wrote: > This does not mean that you must fetch a package named > "github.com/graydon/foo" from github.com, but it means that if you don't > have any other source for that package, you can guess at where to get > it. And it has a unique name (assuming you decide to use that fact). I have a rust project hosted on github, but the package name is certainly not github.com// in my mind. What if it was hosted on bitbucket? What if I delete the repository? I find it puzzling to have to place my local repository inside a directory named github.com// for me to be able to build my local copy using rustpkg. It's the last bit that bothers me the most: I can't build my local project unless I introduce a completely irrelevant aspect (my git host and username) into my metadata (the directory structure). > > This was chosen very carefully, very intentionally, and (for the time > being) we're not revisiting this choice. We experimented before with > having multiple points of name-indirection or metadata and it appears to > have just annoyed and confused everyone. Most package system I've reviewed prior to writing that email used a metadata file in its package system. It really is not clear why Rust must be nearly unique in this point. In the 3 sources of documentation you've linked to there really wasn't a motivation behind why the widespread metadata file approach was wrong. I understand that this is too late to change this, but at the same time I find integrating my (sole for now) Rust project into rustpkg to be really disruptive, relative to simply including a metadata file like I've done for my projects in other languages. -SL From zack at z0w0.me Thu Jun 27 19:09:55 2013 From: zack at z0w0.me (Zack Corr) Date: Fri, 28 Jun 2013 12:09:55 +1000 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCE82F.1000006@aim.com> References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> Message-ID: I think you're confused here. You don't need to name the directory github.com// at all, this is just an abstracted URL that can be used to fetch a Rustpkg project from Github. More abstracted URLs could be added to fetch projects from other sources. Honestly, I agree with you. I still prefer requiring a central pkg.rs file with a name, version and author defined. Sure, these can be inferred based on this abstract URL concept, but it's nice having a central metadata file that exists across sources. I'm still cloudy about how versioning is going to be inferred based on branches and I think I will continue to be until it's implemented and working well. On Fri, Jun 28, 2013 at 11:34 AM, SiegeLord wrote: > On 06/27/2013 06:14 PM, Graydon Hoare wrote: > > This does not mean that you must fetch a package named >> "github.com/graydon/foo" from github.com, but it means that if you don't >> have any other source for that package, you can guess at where to get >> it. And it has a unique name (assuming you decide to use that fact). >> > > I have a rust project hosted on github, but the package name is certainly > not github.com//<**repository_name> in my mind. What if it > was hosted on bitbucket? What if I delete the repository? I find it > puzzling to have to place my local repository inside a directory named > github.com//<**repository_name> for me to be able to build > my local copy using rustpkg. > > It's the last bit that bothers me the most: I can't build my local project > unless I introduce a completely irrelevant aspect (my git host and > username) into my metadata (the directory structure). > > > >> This was chosen very carefully, very intentionally, and (for the time >> being) we're not revisiting this choice. We experimented before with >> having multiple points of name-indirection or metadata and it appears to >> have just annoyed and confused everyone. >> > > Most package system I've reviewed prior to writing that email used a > metadata file in its package system. It really is not clear why Rust must > be nearly unique in this point. In the 3 sources of documentation you've > linked to there really wasn't a motivation behind why the widespread > metadata file approach was wrong. > > I understand that this is too late to change this, but at the same time I > find integrating my (sole for now) Rust project into rustpkg to be really > disruptive, relative to simply including a metadata file like I've done for > my projects in other languages. > > -SL > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Thu Jun 27 19:55:30 2013 From: slabode at aim.com (SiegeLord) Date: Thu, 27 Jun 2013 22:55:30 -0400 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> Message-ID: <51CCFB22.7040205@aim.com> On 06/27/2013 10:09 PM, Zack Corr wrote: > > I think you're confused here. You don't need to name the directory > github.com/ / at all, this is just an > abstracted URL that can be used to fetch a Rustpkg project from Github. > More abstracted URLs could be added to fetch projects from other sources. Well, consider this. Let's say I have a project A has a different project B as its dependency, which I, by accident of history, host on github. I.e. project A has this line in it (I think this is the proposed syntax): extern mod "github.com/SiegeLord/ProjectB"; How would I get rustpkg to use my local copy of it? I assume it will try to do: rustpkg install github.com/SiegeLord/ProjectB which will only work the way I want if I re-create that directory structure on my system. -SL From graydon at mozilla.com Thu Jun 27 20:23:18 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 27 Jun 2013 20:23:18 -0700 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCE82F.1000006@aim.com> References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> Message-ID: <51CD01A6.5090908@mozilla.com> On 13-06-27 06:34 PM, SiegeLord wrote: > On 06/27/2013 06:14 PM, Graydon Hoare wrote: > >> This does not mean that you must fetch a package named >> "github.com/graydon/foo" from github.com, but it means that if you don't >> have any other source for that package, you can guess at where to get >> it. And it has a unique name (assuming you decide to use that fact). > > I have a rust project hosted on github, but the package name is > certainly not github.com// in my mind. That is what its pkgid would be, in the design we chose. It meets the relevant criteria: - decentralized - collision-free - "single string" package identification for use in 'extern mod' - support for remote and local packages, overrides, redirects > What if it was hosted on bitbucket? Then you would either: - name it bitbucket.com/username/package - (re)name it something else, via the redirect procedures below > What if I delete the repository? Then either you will: - redirect at server side[1] - have downstream users override or redirect locally - name it internally using an attribute, at the cost of losing the ability for a user to fetch it remotely via pkgid > find it puzzling to have to place my local repository inside a directory > named github.com// for me to be able to > build my local copy using rustpkg. It may be puzzling but it is both simple to explain and relatively robust against misconfiguration. In any case, you only need to do that if you expect to publish it. You can put it in a shorter named directory -- any name you like -- if you don't expect to. > It's the last bit that bothers me the most: I can't build my local > project unless I introduce a completely irrelevant aspect (my git host > and username) into my metadata (the directory structure). When we did it the other way, people were upset that they had to make a separate file to hold metadata in, and they faced the difficulty of having no simple unique names to refer to packages by when denoting a dependency from one package to another or referring to a package on a command line. This structure reuses a single form of relatively robust structured identifiers for multiple roles (links in source code, remote access protocols, filesystem organization). It is economical, which is why we adopted it. > Most package system I've reviewed prior to writing that email used a > metadata file in its package system. Which did you review, and which do you think we should imitate? Most package systems I reviewed have numerous other failure modes: - central index / namespace of all packages - shallow, collision-prone global namespace - poor to no integration with language module system - poor to no integration with revision control - weak or confusing support for mixing local overrides with remote packages > It really is not clear why Rust must be nearly unique in this point. We made it quite clear during design that we were copying seemingly-wise and economical design choices from the Go package manager, and deviating in places where they were weak (eg. versioning) > In the 3 sources of documentation > you've linked to there really wasn't a motivation behind why the > widespread metadata file approach was wrong. I suppose not, though I'd hoped it was obvious reading through the development threads. I hope I've outlined motives here well enough: that this approach appears to be more-economical with names and number of moving parts. Fewer layers of indirection, more reliance on constraints from the outside world. > I understand that this is too late to change this, but at the same time > I find integrating my (sole for now) Rust project into rustpkg to be > really disruptive, relative to simply including a metadata file like > I've done for my projects in other languages. It is late in the process. I'm sorry that it's disappointing to you but to return to redesign at this point would mean shipping another whole development cycle without a working package manager. I realize the design may not be identical to other systems, but I believe it's quite economical. We made it as simple as possible, so there were as few ways to get things wrong as possible. All you need to do is: - rename the package directory to match its pkgid - rename your crate entry points to {main,lib,test,bench}.rs Is this really so disruptive? It's easy to explain and easy to get right, hard to get wrong. At least that's the idea. -Graydon [1] if it helps, we are also planning to offer a 'pkg.rust-lang.org/user/foo' URL-redirection service, for people who "don't trust code hosting URLs". This is _exactly as reliable_ a mechanism as any other central-index thingy we might decide to operate. From graydon at mozilla.com Thu Jun 27 20:30:12 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 27 Jun 2013 20:30:12 -0700 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCFB22.7040205@aim.com> References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> <51CCFB22.7040205@aim.com> Message-ID: <51CD0344.2010001@mozilla.com> On 13-06-27 07:55 PM, SiegeLord wrote: > Well, consider this. Let's say I have a project A has a different > project B as its dependency, which I, by accident of history, host on > github. > > I.e. project A has this line in it (I think this is the proposed syntax): > > extern mod "github.com/SiegeLord/ProjectB"; > > How would I get rustpkg to use my local copy of it? You would make a local directory "$W/github.com/SiegeLord/ProjectB" in some workspace $W that's part of your RUST_PATH, that contains your local override. > I assume it will try > to do: rustpkg install github.com/SiegeLord/ProjectB which will only > work the way I want if I re-create that directory structure on my system. Correct. I think Zack misunderstood your objection. To override a pkgid locally you would need to create a local directory of the same name. -Graydon From zack at z0w0.me Thu Jun 27 21:52:37 2013 From: zack at z0w0.me (Zack Corr) Date: Fri, 28 Jun 2013 14:52:37 +1000 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CD0344.2010001@mozilla.com> References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> <51CCFB22.7040205@aim.com> <51CD0344.2010001@mozilla.com> Message-ID: Yeah, I misunderstood, apologies. I was reading over the documents you linked earlier to see if there was any further information on how versions were going to be handled. Surely forcing packages without version control to be 0.1 is restrictive? I feel as though the central metadata thing should still be optional, i.e. you can supply a version number in the case that you will be distributing the project as a tarball. It seems pkg.rs will be kept as an optional tool for custom compilation logic, so it makes sense that the metadata could be optional as well. On Fri, Jun 28, 2013 at 1:30 PM, Graydon Hoare wrote: > On 13-06-27 07:55 PM, SiegeLord wrote: > > Well, consider this. Let's say I have a project A has a different >> project B as its dependency, which I, by accident of history, host on >> github. >> >> I.e. project A has this line in it (I think this is the proposed syntax): >> >> extern mod "github.com/SiegeLord/ProjectB**"; >> >> How would I get rustpkg to use my local copy of it? >> > > You would make a local directory "$W/github.com/SiegeLord/**ProjectB" > in some workspace $W that's part of your RUST_PATH, that contains your > local override. > > > I assume it will try >> to do: rustpkg install github.com/SiegeLord/ProjectB which will only >> work the way I want if I re-create that directory structure on my system. >> > > Correct. I think Zack misunderstood your objection. To override a pkgid > locally you would need to create a local directory of the same name. > > -Graydon > > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack at z0w0.me Thu Jun 27 21:56:46 2013 From: zack at z0w0.me (Zack Corr) Date: Fri, 28 Jun 2013 14:56:46 +1000 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: References: <51CCB126.60909@aim.com> <51CCB942.7060207@mozilla.com> <51CCE82F.1000006@aim.com> <51CCFB22.7040205@aim.com> <51CD0344.2010001@mozilla.com> Message-ID: Quick thought: If you're going to definitely go along with inferring everything, maybe you could look for the tarball or directory to be optionally named something like "rust-sdl-v0.1.tar.gz" and extract the version from that? On Fri, Jun 28, 2013 at 2:52 PM, Zack Corr wrote: > Yeah, I misunderstood, apologies. > > I was reading over the documents you linked earlier to see if there was > any further information on how versions were going to be handled. Surely > forcing packages without version control to be 0.1 is restrictive? I feel > as though the central metadata thing should still be optional, i.e. you can > supply a version number in the case that you will be distributing the > project as a tarball. It seems pkg.rs will be kept as an optional tool > for custom compilation logic, so it makes sense that the metadata could be > optional as well. > > > On Fri, Jun 28, 2013 at 1:30 PM, Graydon Hoare wrote: > >> On 13-06-27 07:55 PM, SiegeLord wrote: >> >> Well, consider this. Let's say I have a project A has a different >>> project B as its dependency, which I, by accident of history, host on >>> github. >>> >>> I.e. project A has this line in it (I think this is the proposed syntax): >>> >>> extern mod "github.com/SiegeLord/ProjectB**"; >>> >>> How would I get rustpkg to use my local copy of it? >>> >> >> You would make a local directory "$W/github.com/SiegeLord/**ProjectB" >> in some workspace $W that's part of your RUST_PATH, that contains your >> local override. >> >> >> I assume it will try >>> to do: rustpkg install github.com/SiegeLord/ProjectB which will only >>> work the way I want if I re-create that directory structure on my system. >>> >> >> Correct. I think Zack misunderstood your objection. To override a pkgid >> locally you would need to create a local directory of the same name. >> >> -Graydon >> >> >> ______________________________**_________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/**listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Thu Jun 27 23:47:47 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 27 Jun 2013 23:47:47 -0700 Subject: [rust-dev] rustpkg use scenarios In-Reply-To: <51CCB126.60909@aim.com> References: <51CCB126.60909@aim.com> Message-ID: Graydon answered this pretty thoroughly, but just to add: On Thu, Jun 27, 2013 at 2:39 PM, SiegeLord wrote: > Scenario 4: Fetching/building without installation > > Building without installing: > > rustpkg build > > If you then run `rustpkg install ` or `rustpkg install --package bar`, > then it'll use that pre-built copy without fetching the sources and building This is the intended behavior, though currently it will rebuild, because https://github.com/mozilla/rust/issues/7075 isn't implemented yet. > them again. Speaking of fetching, this would just fetch the sources: > > rustpkg fetch > Planned -- see https://github.com/mozilla/rust/issues/7242 Also, I opened https://github.com/mozilla/rust/issues/7447 for Zack's suggestions about versions. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Not a riot, it's a rebellion." -- Boots Riley "Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant." -- Reg Braithwaite From michaelwoerister at gmail.com Fri Jun 28 04:27:57 2013 From: michaelwoerister at gmail.com (Michael Woerister) Date: Fri, 28 Jun 2013 13:27:57 +0200 Subject: [rust-dev] mk_t() and interning in middle/ty.rs Message-ID: <51CD733D.7060706@gmail.com> Hi, I hope this question is not too specific for the mailing list, but I stumbled upon something I don't understand today and thought I'd better ask. In librustc/middle/ty.rs there is the mk_t() function which creates and caches objects of type "t" from values of type "sty". However, the way it uses the cache seems kind of strange, especially the key creation at the beginning: fn mk_t(cx: ctxt, st: sty) -> t { // Check for primitive types. // ... omitted here ... let key = intern_key { sty: to_unsafe_ptr(&st) }; match cx.interner.find(&key) { Some(t) => unsafe { return cast::transmute(&t.sty); }, _ => () } The intern_key is created by taking a pointer to "st", which in effect is the address of the argument slot on the stack. That can't be right, can it? Is it possible that this cache is actually never used and the compiler always creates new t_box_ instances every time mk_t() is called somewhere? I don't know how bad this would be, maybe mk_t() is only called once per unique type anyway. Or maybe I'm overlooking something here? Any insight on this would be appreciated :) Cheers, Michael From niko at alum.mit.edu Fri Jun 28 11:23:47 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 28 Jun 2013 14:23:47 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51CB6FE3.6030400@gmail.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> Message-ID: <20130628182347.GF9985@Mr-Bennet> Specificity is the cost of non-virtual dispatch. However, if it is truly undesirable in some cases, we can eventually permit you to return `~Iterator`, once ~-objects work properly. Niko On Wed, Jun 26, 2013 at 11:49:07PM +0100, Gareth Smith wrote: > One downside of external iterators is that they produce function > signatures that expose implementation details and are harder to > understand. > > For example, an internal iterator function that loops over odd > numbers would have a signature like this: > > fn each_odd(ints: &[int], fn(int) -> bool) -> bool; > > The same function written to produce an external iterator would have > a signature more like this: > > fn iter_odds<'a>(ints: &'a [int]) -> iterator::FilterMapIterator<'a, > &int, int, vec::VecIterator<'a, int>>; > > This signature is more complicated. It is also likely to change if > the implementation of iter_odds changes (e.g. to no longer use > filter_map). > > Gareth > > On 26/06/13 04:44, Daniel Micay wrote: > >This is a followup from the previous discussion on internal vs. external > >iterators.[1] > > > >Since then, most iterators in the standard library have been converted to > >external ones. Almost all uses of the `for` loop are now using the `.advance` > >wrapper, and I don't think there will be any use cases left for the old > >internal iteration protocol. > > > ># External iterators > > > >To reiterate the benefits of the external iteration protocol: > > > >* It's generic and works well with traits, so functions can be written to work > > on any arbitrary `Iterator`. Most adaptors can work for any type `A`, > > whether it's a value, reference or mutable reference. > > > >* Iteration state is an object, so iterators can be interleaved. This is > > required for a generic zip, merge, union, intersect, etc. and is often useful > > in an ad-hoc fashion to consume only some of an iterator without > > losing it. > > > >* In the future, Rust can have generators using a `yield` statement like C#, > > compiling down to a fast state machine without requiring context switches, > > virtual functions or even closures. This would eliminate the difficulty of > > coding recursive traversals by-hand with external iterators. > > > ># Alternatives > > > >The iteration protocol can't be based on anything requiring virtual method > >calls, heap allocations or context switches without the performance becoming > >significantly worse. > > > >There have been some suggestions about following the lead of Clojure and using > >reducers[2], but the implementation suffers from the same limitations of not > >having an external state. > > > >Rust doesn't yet have a way to write data-parallel code, but when it does gain > >that, containers can just support partitioning themselves into ranges via > >`Iterator`. It will work for in-place mutation in parallel too. > > > ># A new loop > > > >I think it's a foregone conclusion that we'll be replacing `for`, so I suggest > >that we just reuse the current syntax and change the semantics: > > > > for iterator |pattern| { body } > > > >This can just be compiled as the following would be: > > > > let mut it = iterator; > > loop { > > match it.next() { > > Some(pattern) => { body } > > None => break > > } > > } > > > >A lang item can be added for the Iterator trait requirement. > > > >This would avoid the `.advance` tacked onto almost every `for` loop at the > >moment, and rid us of the problems associated with the current `for`: > > > >* The `break` and `return` statements can fail to work, so borrow/liveness > > checking can't trust them. A loop body can't take an `&mut` reference and > > return it because it could result in grabbing the reference again. This also > > seems to be why we forbid `return` inside closures and do statements, since it > > would be confusing to have to act differently than `for`. > > > >* The function's local variables are upvars in the closure, so using them is > > very restricted. It's very obvious that it's not just another block because > > of this. > > > >* Compiling closures is slow, as they have to broken down by SROA and involve > > inlining a function after proving the function pointer is constant. If we > > were marking the function pointers as `llvm.invariant` it might stop being a > > performance hit, but it would remain a compile time issue. > > > ># Iterables > > > >The `for` loop above can also be extended to work for *any* `Iterable` in the > >future, not just iterators themselves. > > > > for iterable |x| { ... } // use the default iterator > > for iterable.rev_iter |x| { ... } // use another iterator > > > >At the moment, the `Iterable` trait cannot be defined/used because the compiler > >ignores bounds on trait type parameters, but it would be something like the > >following: > > > > #[lang = "iterable"] > > trait Iterable> { > > fn iter(&self) -> T; > > } > > > > trait ReverseIterable> { > > fn rev_iter(&self) -> T; > > } > > > > trait MutableIterable> { > > fn mut_iter(&mut self) -> T; > > } > > > > trait MutableReverseIterable> { > > fn mut_rev_iter(&mut self) -> T; > > } > > > ># Links > > > >[1]: https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html > >[2]: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25#iterators > > > > > >_______________________________________________ > >Rust-dev mailing list > >Rust-dev at mozilla.org > >https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pwalton at mozilla.com Fri Jun 28 11:29:01 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 28 Jun 2013 11:29:01 -0700 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130628182347.GF9985@Mr-Bennet> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> Message-ID: <51CDD5ED.80209@mozilla.com> On 6/28/13 11:23 AM, Niko Matsakis wrote: > Specificity is the cost of non-virtual dispatch. However, if it is > truly undesirable in some cases, we can eventually permit you to > return `~Iterator`, once ~-objects work properly. They basically do now (in master), no? Patrick From niko at alum.mit.edu Fri Jun 28 11:55:41 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 28 Jun 2013 14:55:41 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> Message-ID: <20130628185541.GG9985@Mr-Bennet> On Tue, Jun 25, 2013 at 11:44:10PM -0400, Daniel Micay wrote: > Rust doesn't yet have a way to write data-parallel code, but when it does gain > that, containers can just support partitioning themselves into ranges via > `Iterator`. It will work for in-place mutation in parallel too. I do not follow what you mean by "support partitioning themselves into ranges via `Iterator`". That said, I don't think the optimal sequential protocol will necessarily be the optimal parallel protocol, and it's not clear to me how general it will be to have a protocol that yields slices. It'd work ok for vectors and btrees but perhaps not that much else? I suspect the best thing will be to have the iterable trait optimized for sequential access, and provide a second trait to be used for optimal parallel access, probably some kind of "divide-and-conquer"-like trait that can split an iterator into two other iterators. For types that lack the DivideAndConquer trait, you could also have a poor man's D&C that is implemented in terms of an iterator, or just serialize to a vec. Niko From danielmicay at gmail.com Fri Jun 28 12:09:21 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Jun 2013 15:09:21 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130628185541.GG9985@Mr-Bennet> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <20130628185541.GG9985@Mr-Bennet> Message-ID: On Fri, Jun 28, 2013 at 2:55 PM, Niko Matsakis wrote: > On Tue, Jun 25, 2013 at 11:44:10PM -0400, Daniel Micay wrote: >> Rust doesn't yet have a way to write data-parallel code, but when it does gain >> that, containers can just support partitioning themselves into ranges via >> `Iterator`. It will work for in-place mutation in parallel too. > > I do not follow what you mean by "support partitioning themselves into > ranges via `Iterator`". That said, I don't think the optimal > sequential protocol will necessarily be the optimal parallel protocol, > and it's not clear to me how general it will be to have a protocol > that yields slices. It'd work ok for vectors and btrees but perhaps > not that much else? > > I suspect the best thing will be to have the iterable trait optimized > for sequential access, and provide a second trait to be used for > optimal parallel access, probably some kind of > "divide-and-conquer"-like trait that can split an iterator into two > other iterators. For types that lack the DivideAndConquer trait, you > could also have a poor man's D&C that is implemented in terms of an > iterator, or just serialize to a vec. What I meant by partitioning is the divide-and-conquer strategy you mentioned, with either `Iterator<&mut [T]>` or `Iterator>`. If we had a method on vectors returning two disjoint sub-slices as `(&mut [T], &mut [T])`, you could just divide it up as much as you needed. I don't think most containers will need anything special to do this with immutable slices/iterators though. From bsteinbr at gmail.com Fri Jun 28 13:04:30 2013 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Fri, 28 Jun 2013 22:04:30 +0200 Subject: [rust-dev] mk_t() and interning in middle/ty.rs In-Reply-To: <51CD733D.7060706@gmail.com> References: <51CD733D.7060706@gmail.com> Message-ID: <20130628200430.GA24665@atjola.homenet> Hi, On 2013.06.28 13:27:57 +0200, Michael Woerister wrote: > I hope this question is not too specific for the mailing list, but I > stumbled upon something I don't understand today and thought I'd > better ask. > In librustc/middle/ty.rs there is the mk_t() function which creates > and caches objects of type "t" from values of type "sty". However, > the way it uses the cache seems kind of strange, especially the key > creation at the beginning: > > fn mk_t(cx: ctxt, st: sty) -> t { > // Check for primitive types. > // ... omitted here ... > > let key = intern_key { sty: to_unsafe_ptr(&st) }; > match cx.interner.find(&key) { > Some(t) => unsafe { return cast::transmute(&t.sty); }, > _ => () > } > > The intern_key is created by taking a pointer to "st", which in > effect is the address of the argument slot on the stack. That can't > be right, can it? The IterBytes implementation for intern_key, which is used to generate the key for the hashmap, derefs the stored pointer, so it's using the actual value on the stack. And when actually interning, the interned value has a "sty" field, which is referenced by the key for that value, so the pointer in the intern_key stays valid as long as the value is in the interner. HTH Bj?rn From michaelwoerister at gmail.com Fri Jun 28 14:18:59 2013 From: michaelwoerister at gmail.com (=?ISO-8859-1?Q?Michael_W=F6rister?=) Date: Fri, 28 Jun 2013 23:18:59 +0200 Subject: [rust-dev] mk_t() and interning in middle/ty.rs In-Reply-To: <20130628200430.GA24665@atjola.homenet> References: <51CD733D.7060706@gmail.com> <20130628200430.GA24665@atjola.homenet> Message-ID: Ah, thanks for clearing that up. That makes much more sense now :) On Jun 28, 2013 10:04 PM, "Bj?rn Steinbrink" wrote: > Hi, > > On 2013.06.28 13:27:57 +0200, Michael Woerister wrote: > > I hope this question is not too specific for the mailing list, but I > > stumbled upon something I don't understand today and thought I'd > > better ask. > > In librustc/middle/ty.rs there is the mk_t() function which creates > > and caches objects of type "t" from values of type "sty". However, > > the way it uses the cache seems kind of strange, especially the key > > creation at the beginning: > > > > fn mk_t(cx: ctxt, st: sty) -> t { > > // Check for primitive types. > > // ... omitted here ... > > > > let key = intern_key { sty: to_unsafe_ptr(&st) }; > > match cx.interner.find(&key) { > > Some(t) => unsafe { return cast::transmute(&t.sty); }, > > _ => () > > } > > > > The intern_key is created by taking a pointer to "st", which in > > effect is the address of the argument slot on the stack. That can't > > be right, can it? > > The IterBytes implementation for intern_key, which is used to generate > the key for the hashmap, derefs the stored pointer, so it's using the > actual value on the stack. And when actually interning, the interned > value has a "sty" field, which is referenced by the key for that value, > so the pointer in the intern_key stays valid as long as the value is in > the interner. > > HTH > Bj?rn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Fri Jun 28 14:46:43 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 28 Jun 2013 14:46:43 -0700 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130628182347.GF9985@Mr-Bennet> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> Message-ID: <51CE0443.7060209@mozilla.com> On 13-06-28 11:23 AM, Niko Matsakis wrote: > Specificity is the cost of non-virtual dispatch. However, if it is > truly undesirable in some cases, we can eventually permit you to > return `~Iterator`, once ~-objects work properly. This is interesting. I assume we'd want these to be Iterator<> cast to &Iterator<>, no? But we can't really do that in a return value; we'd have to return the Iterator and have the caller cast it to &Iterator<>. ~-allocating here seems a bit much.. -Graydon From niko at alum.mit.edu Sat Jun 29 10:39:22 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 29 Jun 2013 13:39:22 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51CE0443.7060209@mozilla.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> Message-ID: <20130629173922.GK3671@Mr-Bennet> On Fri, Jun 28, 2013 at 02:46:43PM -0700, Graydon Hoare wrote: > >Specificity is the cost of non-virtual dispatch. However, if it is > >truly undesirable in some cases, we can eventually permit you to > >return `~Iterator`, once ~-objects work properly. > > This is interesting. I assume we'd want these to be Iterator<> cast > to &Iterator<>, no? But we can't really do that in a return value; > we'd have to return the Iterator and have the caller cast it to > &Iterator<>. ~-allocating here seems a bit much.. Yes, allocating is somewhat heavy handed, but I don't see any alternative if you want to hide the precise type of the iterator: even if you were going to store the result on the caller's stack frame, the caller would have to know how much space to allocate! Conceivably one could pass in an arena or something once those work. Otherwise, you need something like an internal iterator. But in the end I just don't see this as a big problem one way or the other. Niko From james at mansionfamily.plus.com Sat Jun 29 14:29:25 2013 From: james at mansionfamily.plus.com (james) Date: Sat, 29 Jun 2013 22:29:25 +0100 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <20130629173922.GK3671@Mr-Bennet> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> <20130629173922.GK3671@Mr-Bennet> Message-ID: <51CF51B5.9070507@mansionfamily.plus.com> On 29/06/2013 18:39, Niko Matsakis wrote: > if you were going to store the result on the caller's stack frame, the > caller would have to know how much space to allocate! Conceivably one If you can have a function that returns an allocated iterator, can't you instead have a function that informs how big it would be, and a function that uses a passed in pointer from alloca? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Jun 29 14:32:14 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 29 Jun 2013 17:32:14 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51CF51B5.9070507@mansionfamily.plus.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> <20130629173922.GK3671@Mr-Bennet> <51CF51B5.9070507@mansionfamily.plus.com> Message-ID: On Sat, Jun 29, 2013 at 5:29 PM, james wrote: > On 29/06/2013 18:39, Niko Matsakis wrote: > > if you were going to store the result on the caller's stack frame, the > caller would have to know how much space to allocate! Conceivably one > > > If you can have a function that returns an allocated iterator, can't you > instead have > a function that informs how big it would be, and a function that uses a > passed in > pointer from alloca? We don't have alloca, but if we did, it would be less efficient than a statically sized allocation since it would involve an extra stack size check. A low-level, unsafe workaround like that isn't needed when you can just have a function return an iterator of a specific type. From corey at octayn.net Sat Jun 29 16:47:16 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 29 Jun 2013 19:47:16 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Sorry it's a bit late, family things. Copy of content at http://cmr.github.io/blog/2013/06/29/this-week-in-rust/ -- --- layout: post title: "This Week in Rust" date: 2013-06-29 12:26 comments: true categories: programming rust this-week-in-rust --- Hello and welcome to the fourth issue of *This Week in Rust*, a weekly overview of Rust and its community. `0.7` is being cut soon (today, I think). There are preliminary release notes [on GitHub](https://github.com/mozilla/rust/blob/master/RELEASES.txt). The tree has been quite calm, with regards to breakage. Cycle time is still high, but at least when things land they don't break master. # What's cooking on master? Issue churn this week was -1. Yay! Issue churn this month was -47. 61 people pushed 1,080 commits, changing 2,117 files and adding a total of 53347 lines. The top 10 committers were pcwalton, brson, dbaupp, strcat, bblum, nmatsakis, acricto, Blei, me (cmr), and aatch. Much of the work this week was cleanup or rebases of older PRs that just hadn't made it in yet. ## Notable additions, bugfixes, and cleanup - Eridius has finished (I think!) the last bit of UNIX [terminal support](https://github.com/mozilla/rust/pull/7436), adding fallback and smarter detection. It should work in 8-color terminals now too. - pcwalton [rewrote each_path](https://github.com/mozilla/rust/pull/7451), with the goal of future performance enhancements. - tjc has done a [bunch](https://github.com/mozilla/rust/pull/7397) of [rustpkg](https://github.com/mozilla/rust/pull/7403) work. - aatch did some [trans cleanup](https://github.com/mozilla/rust/pull/7272). - gifnksm added [`max_by` and `min_by`](https://github.com/mozilla/rust/pull/7414) methods to `IteratorUtil` for getting the largest/smallest value in an iterator given a score function. - brson got a fix that [releases large stacks](https://github.com/mozilla/rust/pull/7111) after they are used to lower memory usage. - mw has a bunch of [debuginfo](https://github.com/mozilla/rust/pull/7432) work, as well as [docs and cleanup](https://github.com/mozilla/rust/pull/7255). - Blei did an [intrinsic overhaul](https://github.com/mozilla/rust/pull/7254). - acrichto implemented [`static mut`](https://github.com/mozilla/rust/pull/7291), for globals. Using them requires unsafe code. - DaGenix [cleaned up and extended](https://github.com/mozilla/rust/pull/7207) the SHA code. - acrichto renamed `.rc` files to `.rs`. `.rc` is deprecated and functionally equivalent to `.rs`, all new code should use it. He also [added](https://github.com/mozilla/rust/pull/7371) a `warnings` lint attribute for enabling/disabling warnings in bulk. - indutny added [`mman` (including `mmap`)](https://github.com/mozilla/rust/pull/7257) FFI. - dbaupp found a [curious performance win](https://github.com/mozilla/rust/pull/7297) by changing some ordering around, while also enabling conditionally defined macros and macro expansion to items with `#[cfg]` attributes. - Luqman [fixed by-value self](https://github.com/mozilla/rust/pull/7410). - acrichto expanded the `deriving(ToStr)` code to use `ToStr` on fields rather than using `fmt!("%?", x)`. - Blei [fixed a lot of problems](https://github.com/mozilla/rust/pull/7214) with owned trait objects (`~Trait`). - sully has [landed some default method fixes](https://github.com/mozilla/rust/pull/7471) ## Breaking Changes - As usual, [a](https://github.com/mozilla/rust/pull/7274) [bunch](https://github.com/mozilla/rust/pull/7334) [of](https://github.com/mozilla/rust/pull/7373) [iterator](https://github.com/mozilla/rust/pull/7319) work. - pcwalton renamed Owned to Send and Const to Freeze, better reflecting their actual semantics. - He also disallowed `mut` from distributing over bindings. For example, the following code no longer works: `let mut (a, b) = (c, d)`. - dbaupp [converted](https://github.com/mozilla/rust/pull/7430) many vector functions to methods. He has a [second part](https://github.com/mozilla/rust/pull/7487) in line. - Luqman renamed the `finalize` method in the `Drop` trait to `drop`. ## Other changes bblum did some trait/fn/closure bounds [here](https://github.com/mozilla/rust/pull/7314) and [here](https://github.com/mozilla/rust/pull/7354), but I don't really understand what they do or their significance. He said: {% blockquote %} it changes the way traits/closures and captured data fulfill kind bounds, so you can restrict or loosen the requirements instead of having the fixed defaults of "can only capture Send things in ~fn/~Trait" one example is that you can add the extra requirement of Freeze, so you can put existential data inside of ARCs see https://github.com/mozilla/rust/blob/master/src/test/run-pass/trait-bounds-in-arc.rs http://smallcultfollowing.com/babysteps/blog/2013/06/11/data-parallelism-in-rust/ is another, more complicated but less contrived, example for how they would be useful {% endblockquote %} # Meetings The [Tuesday meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-06-25) mainly discussed `@mut` and iterators, as well as some minor 0.7 releng stuff. I suggest reading the `@mut` discussion yourself, but essentially it revolves around it not quite fitting into the language, and that it could be easily punted to a library. The iterator discussion was not notable. # Discussion + Blog posts - [New container/iterator tutorial](http://static.rust-lang.org/doc/tutorial-container.html) - ["Language support for external iterators"](http://thread.gmane.org/gmane.comp.lang.rust.devel/4528) - ["Rust gets a lot of things right"](http://spin.atomicobject.com/2013/06/25/rust-language/) - ["Planning a project in rust?"](http://www.reddit.com/r/rust/comments/1ha3yi/planning_a_project_in_rust/) - ["Memory layout of types"](https://mail.mozilla.org/pipermail/rust-dev/2013-June/004572.html) - [mw's second status report](http://michaelwoerister.github.io/2013/06/28/Status-Update-2.html) # External projects - QuickCheck for Rust. - [GitHub](https://github.com/blake2-ppc/qc.rs) - [Reddit discussion](http://www.reddit.com/r/rust/comments/1h0217/mockup_of_quickcheck/) - RustGnuplot ([GitHub](https://github.com/SiegeLord/RustGnuplot)) From james at mansionfamily.plus.com Sun Jun 30 07:22:13 2013 From: james at mansionfamily.plus.com (james) Date: Sun, 30 Jun 2013 15:22:13 +0100 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> <20130629173922.GK3671@Mr-Bennet> <51CF51B5.9070507@mansionfamily.plus.com> Message-ID: <51D03F15.1060503@mansionfamily.plus.com> On 29/06/2013 22:32, Daniel Micay wrote: > On Sat, Jun 29, 2013 at 5:29 PM, james wrote: >> >On 29/06/2013 18:39, Niko Matsakis wrote: >> > >> >if you were going to store the result on the caller's stack frame, the >> >caller would have to know how much space to allocate! Conceivably one >> > >> > >> >If you can have a function that returns an allocated iterator, can't you >> >instead have >> >a function that informs how big it would be, and a function that uses a >> >passed in >> >pointer from alloca? > We don't have alloca, but if we did, it would be less efficient than a > statically sized allocation since it would involve an extra stack size > check. A low-level, unsafe workaround like that isn't needed when you > can just have a function return an iterator of a specific type. Well, if the caller knows the type of the returned object and it is returned by value - yes. But I thought the discussion had strayed to considering a case where the type is hidden inside the iterated-over object, so the caller using the pattern does not know how to allocate space for it and receive such an object by value. I was trying to suggest that it is not necessary for the caller to know much about the iterator object to avoid a heap allocation - it has to ask the size, and it has to then allocate and pass some raw storage on its stack. And I guess it has to ask for a function to call on the raw store when it has finished with it. I'm not claiming that this is more efficient that a return by value, just that it may be possible to avoid a heap allocation even in the case where the call site only sees an abstract iterator interface, and does not know any details. This is very much similar to tradeoffs in C++ between using inheritance and interfaces vs templates, and my experience has been that moving to templates has in some cases swapped a small runtime overhead for major problems with compilation speed and emitted code size - and the latter has caused runtime performance issues all of its own. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun Jun 30 07:38:43 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 30 Jun 2013 16:38:43 +0200 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51D03F15.1060503@mansionfamily.plus.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> <20130629173922.GK3671@Mr-Bennet> <51CF51B5.9070507@mansionfamily.plus.com> <51D03F15.1060503@mansionfamily.plus.com> Message-ID: Hello, Regarding type-erasure without stack-allocation I remember a question on StackOverflow on how to implement this. In C++ this can be done using templates => template class Pimpl; Pimpl will then declare raw storage (char [] in C++03, std::aligned_storage::type in C++11), and then this space will be used by `T` (which was forward declared). An important (and maybe overlooked) aspect is that Size and Alignment are upper-bounds. Whilst to avoid wasting space it is better they be as close to the necessary value, equality is not necessary. And thus one could perfectly imagine a AgnosticIterator and it is up to the builder to create a type that fit... and maybe use dynamic allocation as a fallback if the iterator state cannot fit within the provided size. -- Matthieu. On Sun, Jun 30, 2013 at 4:22 PM, james wrote: > On 29/06/2013 22:32, Daniel Micay wrote: > > On Sat, Jun 29, 2013 at 5:29 PM, james wrote: > > > On 29/06/2013 18:39, Niko Matsakis wrote:>> if you were going to store the result on the caller's stack frame, the> caller would have to know how much space to allocate! Conceivably one>>> If you can have a function that returns an allocated iterator, can't you> instead have> a function that informs how big it would be, and a function that uses a> passed in> pointer from alloca? > > We don't have alloca, but if we did, it would be less efficient than a > statically sized allocation since it would involve an extra stack size > check. A low-level, unsafe workaround like that isn't needed when you > can just have a function return an iterator of a specific type. > > Well, if the caller knows the type of the returned object and it is > returned by value - yes. > > But I thought the discussion had strayed to considering a case where the > type is hidden > inside the iterated-over object, so the caller using the pattern does not > know how to > allocate space for it and receive such an object by value. I was trying > to suggest that > it is not necessary for the caller to know much about the iterator object > to avoid a > heap allocation - it has to ask the size, and it has to then allocate and > pass some raw > storage on its stack. And I guess it has to ask for a function to call on > the raw store > when it has finished with it. > > I'm not claiming that this is more efficient that a return by value, just > that it may be > possible to avoid a heap allocation even in the case where the call site > only sees an > abstract iterator interface, and does not know any details. > > This is very much similar to tradeoffs in C++ between using inheritance > and interfaces > vs templates, and my experience has been that moving to templates has in > some > cases swapped a small runtime overhead for major problems with compilation > speed > and emitted code size - and the latter has caused runtime performance > issues all of > its own. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Jun 30 11:21:43 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 30 Jun 2013 14:21:43 -0400 Subject: [rust-dev] Language support for external iterators (new for loop) In-Reply-To: <51D03F15.1060503@mansionfamily.plus.com> References: <20130626034410.GA10499@thinktank.vlan1.phub.net.cable.rogers.com> <51CB6FE3.6030400@gmail.com> <20130628182347.GF9985@Mr-Bennet> <51CE0443.7060209@mozilla.com> <20130629173922.GK3671@Mr-Bennet> <51CF51B5.9070507@mansionfamily.plus.com> <51D03F15.1060503@mansionfamily.plus.com> Message-ID: On Sun, Jun 30, 2013 at 10:22 AM, james wrote: > On 29/06/2013 22:32, Daniel Micay wrote: > > On Sat, Jun 29, 2013 at 5:29 PM, james wrote: > >> On 29/06/2013 18:39, Niko Matsakis wrote: >> >> if you were going to store the result on the caller's stack frame, the >> caller would have to know how much space to allocate! Conceivably one >> >> >> If you can have a function that returns an allocated iterator, can't you >> instead have >> a function that informs how big it would be, and a function that uses a >> passed in >> pointer from alloca? > > We don't have alloca, but if we did, it would be less efficient than a > statically sized allocation since it would involve an extra stack size > check. A low-level, unsafe workaround like that isn't needed when you > can just have a function return an iterator of a specific type. > > Well, if the caller knows the type of the returned object and it is returned > by value - yes. > > But I thought the discussion had strayed to considering a case where the > type is hidden > inside the iterated-over object, so the caller using the pattern does not > know how to > allocate space for it and receive such an object by value. I was trying to > suggest that > it is not necessary for the caller to know much about the iterator object to > avoid a > heap allocation - it has to ask the size, and it has to then allocate and > pass some raw > storage on its stack. And I guess it has to ask for a function to call on > the raw store > when it has finished with it. There's no way to dynamically allocate space on the stack in Rust. If it was possible, it would require unsafe code to obtain the arbitrary pointer and more unsafe code to pass it into functions requiring that object. All of those functions would have to be explicitly designed for this pattern and marked as unsafe. > I'm not claiming that this is more efficient that a return by value, just > that it may be > possible to avoid a heap allocation even in the case where the call site > only sees an > abstract iterator interface, and does not know any details. I don't think it's possible. > This is very much similar to tradeoffs in C++ between using inheritance and > interfaces > vs templates, and my experience has been that moving to templates has in > some > cases swapped a small runtime overhead for major problems with compilation > speed > and emitted code size - and the latter has caused runtime performance issues > all of > its own. Rust could offer alternate strategies for compiling generics, we aren't restricted to specializing them in every case forever. Keep in mind iterator adaptors are tiny functions and that inlining them is always desired, for every one that's currently done. If you do write a large function using iterators, you can hoist out the parts that don't require generic code as a workaround.