Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Corey Richardson
On Wed, Aug 21, 2013 at 11:03 PM, Patrick Walton wrote: > On 8/21/13 7:47 PM, Corey Richardson wrote: >> >> IO and especially disk IO are almost 0 compilation time. All files in >> a crate are read at once, then compilation happens. > > > I don't believe this is true, as disk IO from metadata read

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Patrick Walton
On 8/21/13 7:44 PM, Graydon Hoare wrote: Again, large amount of work to rearrange everything that uses metadata to work with this sort of thing. This actually isn't that hard, I don't think. It's just incompatible with compression and might require hacking the LLVM ObjectFile interface a bit.

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Patrick Walton
On 8/21/13 7:47 PM, Corey Richardson wrote: IO and especially disk IO are almost 0 compilation time. All files in a crate are read at once, then compilation happens. I don't believe this is true, as disk IO from metadata reading hurts. - Metadata is large. It is multiple megabytes of data (un

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Graydon Hoare
On 13-08-21 07:47 PM, Corey Richardson wrote: > - Metadata is large. It is multiple megabytes of data (uncompressed. > compressed as of now it is 749K) for libstd. I'm not sure whether we > are encoding too much data or if it's exactly what we need, but this > is a very large constant that every i

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Corey Richardson
On Wed, Aug 21, 2013 at 8:53 PM, Bill Myers wrote: > Have you considered the following "non-specific" quick fixes? > > 1. Build on a ramfs/ramdisk > IO and especially disk IO are almost 0 compilation time. All files in a crate are read at once, then compilation happens. > 2. Distribute compilati

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Graydon Hoare
On 13-08-21 05:53 PM, Bill Myers wrote: > Have you considered the following "non-specific" quick fixes? > > 1. Build on a ramfs/ramdisk Not I/O bound. > 2. Distribute compilations and tests across a cluster of machines (like > distcc) Already doing what we can here. The remainder doesn't parall

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Bill Myers
Have you considered the following "non-specific" quick fixes? 1. Build on a ramfs/ramdisk 2. Distribute compilations and tests across a cluster of machines (like distcc) 3. If non-parallelizable code is still the bottleneck, use the fastest CPU possible (i.e. an overclocked Core i7 4770K, over

Re: [rust-dev] Avoiding borrow check assertions with @mut

2013-08-21 Thread Oren Ben-Kiki
Thanks for all the responses! I knew there was something simple I could do in my specific case - in this case, `.take()` or more generically `utils::replace`. Thanks for the pointers. That said, the general problem remains. I think it goes as follows: - There is a container accessible from some

Re: [rust-dev] Borrowed pointers with lifetime in structures cause weird errors

2013-08-21 Thread Vladimir Matveev
Hi Niko, Thank you for your response. I forgot to put it in the original message, but here is a link to bitbucket repository with all the code I got so far: https://bitbucket.org/googolplex/algo/src, see module io. Maybe it will be helpful. I'm still inclined to think that this is a bug, and I re

Re: [rust-dev] Avoiding borrow check assertions with @mut

2013-08-21 Thread Kevin Ballard
You should be able to just use .take() instead of invoking util::replace(), although the end-result should be the same. let root = self.levels[last].root.take(); -Kevin On Aug 20, 2013, at 7:35 PM, Niko Matsakis wrote: > There may be another way, but one safe option is to use util::replac

Re: [rust-dev] Issue in borrowing

2013-08-21 Thread Niko Matsakis
Depending on what you are trying to do, there are multiple answers to your (implied) question. In general you are not permitted to have two borrows of the same element at the same time; in this case, your program is being rejected because the compiler is conservative and it assumes that any two arr

Re: [rust-dev] Issue in borrowing

2013-08-21 Thread Eric P. Mangold
Hi Piyush, could you try that again without HTML email and tracking gifs? Plain text mail is standard for mailing lists. Thanks, -E On Wed, Aug 21, 2013 at 11:38:49AM +, Piyush Agarwal wrote: > Samsung Enterprise Portal mySingle > > P { > MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMIL

[rust-dev] Issue in borrowing

2013-08-21 Thread Piyush Agarwal
Title: Samsung Enterprise Portal mySingle Hi All, Rust Compiler is giving error in following code :-   fn main() {  let mut vec = ~[1 ,2 , 3, 4];  f1(&mut vec); } fn f1 (b: &mut ~[int]) {  let mut a = &mut b[0]; //process(a);  a = &mut b[3];}   error: cannot borrow '(**b)[]' as mutable more than

Re: [rust-dev] cycle time, compile/test performance

2013-08-21 Thread Graydon Hoare
On 13-08-20 09:15 PM, Brian Anderson wrote: I tried reproducing the regression with a subset of the run-pass tests earlier and failed, so tonight I tried harder by running all of make check like `make check CFG_ENABLE_VALGRIND=1 RUST_THREADS=1` (after previously building the compiler with `make`