Re: [rust-dev] Large Collection of rustc builds

2014-04-14 Thread Alex Bradbury
On 14 April 2014 04:43, Corey Richardson co...@octayn.net wrote: Hello all, I now have on a disk here every merge into master that builds on my machine, built. That is, 3733 copies, using 560GB of disk, of rustc going back to the first run of bors on February 1, 2013. If there's anything

Re: [rust-dev] Convincing compiler that *T is safe

2014-04-14 Thread Huon Wilson
On 14/04/14 19:04, Flaper87 wrote: 2014-04-13 22:22 GMT+02:00 György Andrasek jur...@gmail.com mailto:jur...@gmail.com: You could make a container struct: struct Dev { ptr: *mut InternalDev } and then impl your methods on that. I'd recommend using

Re: [rust-dev] Convincing compiler that *T is safe

2014-04-14 Thread Huon Wilson
On 14/04/14 06:12, Vladimir Pouzanov wrote: I have a number of I/O mapped registers that look like: struct Dev { .. // u32 fields } pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev; with macro-generated getters and setters: pub fn $getter_name(self) - u32 { unsafe {

[rust-dev] master [run-pass]: most tests failed. mingw + windows 7.

2014-04-14 Thread Liigo Zhuang
test result: FAILED. 2 passed; 1387 failed; 50 ignored; 0 measured what happens? Most tests failed at 'explicit failure': [run-pass] run-pass/unwind-unique.rs stdout error: test run failed! command:

Re: [rust-dev] Convincing compiler that *T is safe

2014-04-14 Thread Vladimir Pouzanov
Well, the Dev as a pointer would be immutable in terms of that you can't change its address, and all access to fields is done via getter/setter methods using volatiles. It seems that I cannot use transmute in a context of static though and I can't trade runtime size over better syntax. On Mon,

Re: [rust-dev] Large Collection of rustc builds

2014-04-14 Thread Steve Klabnik
Oh! Oh! This is really useful because we have a bootstrapped compiler. It's Monday, and I'm still on my first coffee, but couldn't this lead to every single build since the history of time being signed? - Steve ___ Rust-dev mailing list

Re: [rust-dev] Do I need to watch out for memory fragmentation?

2014-04-14 Thread Matthieu Monrocq
Memory fragmentation is a potential issue in all languages that not use a Compacting GC, so yes. There are some attenuating circumstances in Rust, notably the fact that unless you use a ~ pointer the memory is allocated in a task private heap which is entirely recycled at the death of the task,

Re: [rust-dev] Do I need to watch out for memory fragmentation?

2014-04-14 Thread Zach Moazeni
Thanks Matthieu. I thought that might be the case. I'll keep a look out as I work with Rust and ping the mailing list if I need to cross that bridge. Kind Regards, Zach On Mon, Apr 14, 2014 at 12:41 PM, Matthieu Monrocq matthieu.monr...@gmail.com wrote: Memory fragmentation is a

Re: [rust-dev] Large Collection of rustc builds

2014-04-14 Thread Tony Arcieri
On Mon, Apr 14, 2014 at 9:10 AM, Steve Klabnik st...@steveklabnik.comwrote: This is really useful because we have a bootstrapped compiler. It's Monday, and I'm still on my first coffee, but couldn't this lead to every single build since the history of time being signed? Worried about Ken

Re: [rust-dev] Large Collection of rustc builds

2014-04-14 Thread Steve Klabnik
Maybe. For anyone who doesn't get Tony's reference: http://cm.bell-labs.com/who/ken/trust.html ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Do I need to watch out for memory fragmentation?

2014-04-14 Thread Daniel Micay
On 14/04/14 12:41 PM, Matthieu Monrocq wrote: Memory fragmentation is a potential issue in all languages that not use a Compacting GC, so yes. It's much less of an issue than people make it out to be on 32-bit, and it's a non-issue on 64-bit with a good allocator (jemalloc, tcmalloc). Small