From codywmack at gmail.com Mon Sep 1 05:51:56 2014 From: codywmack at gmail.com (Cody Mack) Date: Mon, 1 Sep 2014 08:51:56 -0400 Subject: [rust-dev] Arbitrary-precision arithmetic Message-ID: Hi, Regarding issue #8937 (https://github.com/rust-lang/rust/issues/8937), add a BigDecimal type, there is discussion about wrapping GMP, and even possibly replacing Rust's current BigInt with this wrapper. One comment mentions that Rust's current BigInt is ~100x slower than GMP in some cases. However, GMP is licensed under LGPL. 1. Are there benchmarks displayed somewhere for comparison of BigInt vs. GMP? It would be helpful to know cases from where the factor 100x came. 2. Haskell's GHC (https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes) takes the approach of having two implementations available for use: a pure-Haskell implementation and a wrapper around GMP. The former does not have the performance of the latter yet has GHC's BSD-style license. Would there be any objections to having a pure-Rust implementation and a GMP-wrapper implementation which users could choose? Starting out, the pure-Rust implementation would not have the years of optimization which GMP has, but effort could be made to improve the pure-Rust performance. Thanks. From danielmicay at gmail.com Mon Sep 1 20:12:33 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 01 Sep 2014 23:12:33 -0400 Subject: [rust-dev] Arbitrary-precision arithmetic In-Reply-To: References: Message-ID: <540535A1.9010101@gmail.com> On 01/09/14 08:51 AM, Cody Mack wrote: > Hi, > > Regarding issue #8937 (https://github.com/rust-lang/rust/issues/8937), > add a BigDecimal type, there is discussion about wrapping GMP, and > even possibly replacing Rust's current BigInt with this wrapper. One > comment mentions that Rust's current BigInt is ~100x slower than GMP > in some cases. However, GMP is licensed under LGPL. > > 1. Are there benchmarks displayed somewhere for comparison of BigInt > vs. GMP? It would be helpful to know cases from where the factor 100x > came. Rust's BigInt has progressively more inferior *time complexity* as the numbers get bigger. It's far worse than 100x for very large numbers. It's significantly slower for relatively small numbers because it lacks years of work writing optimized assembly. This gets more important as domain specific instructions like MULX are added to CPUs, along with more diverse SIMD instructions with wider registers. Auto-vectorization doesn't work for complex cases like this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From erick.tryzelaar at gmail.com Tue Sep 2 17:01:31 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 2 Sep 2014 17:01:31 -0700 Subject: [rust-dev] Rust Bay Area September Meetup - Web Tech part 2 Message-ID: Greetings Rustlers! I'm pleased to announce the next Bay Area Rust meetup on Tuesday, September 23rd at Mozilla in San Francisco. This is the second part of our web series. Here is our lineup of speakers: ? Chris Morgan (in person!): Teepee - The Rust Web Toolkit ? Alan Andrade: OxidizeJS - Parallel JavaScript compression We may have some time available too if anyone else wants to show off something web-y. As always, Mozilla will be graciously providing food and drink. If you would like to attend, please sign up for the event here: http://www.meetup.com/Rust-Bay-Area/events/194567252/ I hope you all can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Wed Sep 3 22:17:47 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Wed, 03 Sep 2014 22:17:47 -0700 (PDT) Subject: [rust-dev] [ANN] Iobuf Message-ID: <1409807867203.485e8bdf@Nodemailer> Hey everyone! Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. ? ? ? ? ? ? https://github.com/cgaebel/iobuf Enjoy, ? - Clark -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Thu Sep 4 00:46:06 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Thu, 4 Sep 2014 11:46:06 +0400 Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <1409807867203.485e8bdf@Nodemailer> References: <1409807867203.485e8bdf@Nodemailer> Message-ID: <62B94AC3-DD15-45DA-8111-146674903742@gmail.com> Hi! I?ve noticed this piece of code in your library: #[inline] fn as_mut_slice(&self) -> &mut [u8] { unsafe { match self { &OwnedBuffer(ref v) => { let mut_v: &mut Vec = mem::transmute(v); mut_v.as_mut_slice() }, &BorrowedBuffer(ref s) => { let mut_s: &mut &mut [u8] = mem::transmute(s); mut_s.as_mut_slice() }, } } } I was under impression that transmuting & to &mut is undefined behavior in Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong? On 04 ????. 2014 ?., at 9:17, Clark Gaebel wrote: > Hey everyone! > > Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! > > An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. > > https://github.com/cgaebel/iobuf > > Enjoy, > - Clark > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From cg.wowus.cg at gmail.com Thu Sep 4 01:15:24 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 04 Sep 2014 01:15:24 -0700 (PDT) Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <62B94AC3-DD15-45DA-8111-146674903742@gmail.com> References: <62B94AC3-DD15-45DA-8111-146674903742@gmail.com> Message-ID: <1409818524724.681ffe3c@Nodemailer> I think you?re right! Thanks for pointing at UnsafeCell. That seems like exactly what I want. It has been fixed. Thanks a ton for the catch! ? - Clark On Thu, Sep 4, 2014 at 12:46 AM, Vladimir Matveev wrote: > Hi! > I?ve noticed this piece of code in your library: > #[inline] > fn as_mut_slice(&self) -> &mut [u8] { > unsafe { > match self { > &OwnedBuffer(ref v) => { > let mut_v: &mut Vec = mem::transmute(v); > mut_v.as_mut_slice() > }, > &BorrowedBuffer(ref s) => { > let mut_s: &mut &mut [u8] = mem::transmute(s); > mut_s.as_mut_slice() > }, > } > } > } > I was under impression that transmuting & to &mut is undefined behavior in Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong? > On 04 ????. 2014 ?., at 9:17, Clark Gaebel wrote: >> Hey everyone! >> >> Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! >> >> An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. >> >> https://github.com/cgaebel/iobuf >> >> Enjoy, >> - Clark >> _______________________________________________ >> 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 john.archie.mckown at gmail.com Thu Sep 4 18:57:01 2014 From: john.archie.mckown at gmail.com (John McKown) Date: Thu, 4 Sep 2014 20:57:01 -0500 Subject: [rust-dev] minor problem with "amke install" Message-ID: I run as a normal user (non-root) on Linux using Fedora 20 x86_64. I did a git clone of rust just for fun and to learn. I then did: ,.configure && make all && sudo make install The sudo make install worked, placing tge rust programs in /var/local. However, it also left almost 4000 files behind in subdirectories under the rust directory in my $HOME and they are owned by root. I do _not_ consider this to be a nice thing to do. These are the rust/tmp subdirectory and the others are scattered under rust/doc. The file containing the output from: find rust -user 0 -ls iis 464K in size, 3959 lines. compressed with xz, the compressed size is 43K. I was going to attach that file to this email, but then felt that would be unkind and likely violate forum rules. So I have created a public gist on github. It is here: https://gist.github.com/JohnArchieMckown/69104fcfde6835eb4d9f Thanks for listening. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown From banderson at mozilla.com Thu Sep 4 18:59:18 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 04 Sep 2014 18:59:18 -0700 Subject: [rust-dev] minor problem with "amke install" In-Reply-To: References: Message-ID: <540918F6.5060102@mozilla.com> Thanks for the report. It's probably https://github.com/rust-lang/rust/issues/13728. This is an easy first bug to fix if somebody wants to jump on it. On 09/04/2014 06:57 PM, John McKown wrote: > I run as a normal user (non-root) on Linux using Fedora 20 x86_64. I > did a git clone of rust just for fun and to learn. I then did: > ,.configure && make all && sudo make install > > The sudo make install worked, placing tge rust programs in /var/local. > However, it also left almost 4000 files behind in subdirectories under > the rust directory in my $HOME and they are owned by root. I do _not_ > consider this to be a nice thing to do. These are the rust/tmp > subdirectory and the others are scattered under rust/doc. > > The file containing the output from: > > find rust -user 0 -ls > iis 464K in size, 3959 lines. > compressed with xz, the compressed size is 43K. I was going to attach > that file to this email, but then felt that would be unkind and likely > violate forum rules. So I have created a public gist on github. It is > here: https://gist.github.com/JohnArchieMckown/69104fcfde6835eb4d9f > > Thanks for listening. > From kevin at sb.org Thu Sep 4 20:36:38 2014 From: kevin at sb.org (Kevin Ballard) Date: Thu, 4 Sep 2014 20:36:38 -0700 Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <1409818524724.681ffe3c@Nodemailer> References: <62B94AC3-DD15-45DA-8111-146674903742@gmail.com> <1409818524724.681ffe3c@Nodemailer> Message-ID: <7086655D-64C1-4655-A1C5-051EF8F2A8C2@sb.org> I?m still seeing bad transmutes. fn from_str<'a>(s: &'a str) -> RawIobuf<'a> { unsafe { let bytes: &mut [u8] = mem::transmute(s.as_bytes()); RawIobuf::of_buf(BorrowedBuffer(bytes)) } } This is taking a `&str`, converting to `&[u8]`, and then transmuting to `&mut [u8]`. Besides being undefined, I have to assume it's also possible for other code later on to end up attempting to actually mutate this data, which will either a) be really bad, or b) not even be possible if it's a string constant in read-only member. -Kevin > On Sep 4, 2014, at 1:15 AM, Clark Gaebel wrote: > > I think you?re right! Thanks for pointing at UnsafeCell. That seems like exactly what I want. It has been fixed. > > Thanks a ton for the catch! > - Clark > > > On Thu, Sep 4, 2014 at 12:46 AM, Vladimir Matveev wrote: > > Hi! > > I?ve noticed this piece of code in your library: > > #[inline] > fn as_mut_slice(&self) -> &mut [u8] { > unsafe { > match self { > &OwnedBuffer(ref v) => { > let mut_v: &mut Vec = mem::transmute(v); > mut_v.as_mut_slice() > }, > &BorrowedBuffer(ref s) => { > let mut_s: &mut &mut [u8] = mem::transmute(s); > mut_s.as_mut_slice() > }, > } > } > } > > I was under impression that transmuting & to &mut is undefined behavior in Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong? > > On 04 ????. 2014 ?., at 9:17, Clark Gaebel wrote: > > > Hey everyone! > > > > Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! > > > > An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. > > > > https://github.com/cgaebel/iobuf > > > > Enjoy, > > - Clark > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From cg.wowus.cg at gmail.com Thu Sep 4 23:55:28 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 04 Sep 2014 23:55:28 -0700 (PDT) Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <7086655D-64C1-4655-A1C5-051EF8F2A8C2@sb.org> References: <7086655D-64C1-4655-A1C5-051EF8F2A8C2@sb.org> Message-ID: <1409900128387.8022fc72@Nodemailer> from_str is only used to construct read-only Iobufs, which do not support writing into the buffer. Also, if you modify the string, it should invalidate the Iobuf since the lifetime is bound to the borrowed reference of the string. ? - Clark On Thu, Sep 4, 2014 at 8:36 PM, Kevin Ballard wrote: > I?m still seeing bad transmutes. > fn from_str<'a>(s: &'a str) -> RawIobuf<'a> { > unsafe { > let bytes: &mut [u8] = mem::transmute(s.as_bytes()); > RawIobuf::of_buf(BorrowedBuffer(bytes)) > } > } > This is taking a `&str`, converting to `&[u8]`, and then transmuting to `&mut [u8]`. Besides being undefined, I have to assume it's also possible for other code later on to end up attempting to actually mutate this data, which will either a) be really bad, or b) not even be possible if it's a string constant in read-only member. > -Kevin >> On Sep 4, 2014, at 1:15 AM, Clark Gaebel wrote: >> >> I think you?re right! Thanks for pointing at UnsafeCell. That seems like exactly what I want. It has been fixed. >> >> Thanks a ton for the catch! >> - Clark >> >> >> On Thu, Sep 4, 2014 at 12:46 AM, Vladimir Matveev wrote: >> >> Hi! >> >> I?ve noticed this piece of code in your library: >> >> #[inline] >> fn as_mut_slice(&self) -> &mut [u8] { >> unsafe { >> match self { >> &OwnedBuffer(ref v) => { >> let mut_v: &mut Vec = mem::transmute(v); >> mut_v.as_mut_slice() >> }, >> &BorrowedBuffer(ref s) => { >> let mut_s: &mut &mut [u8] = mem::transmute(s); >> mut_s.as_mut_slice() >> }, >> } >> } >> } >> >> I was under impression that transmuting & to &mut is undefined behavior in Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong? >> >> On 04 ????. 2014 ?., at 9:17, Clark Gaebel wrote: >> >> > Hey everyone! >> > >> > Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! >> > >> > An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. >> > >> > https://github.com/cgaebel/iobuf >> > >> > Enjoy, >> > - Clark >> > _______________________________________________ >> > 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 kevin at sb.org Fri Sep 5 02:55:27 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 5 Sep 2014 02:55:27 -0700 Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <1409900128387.8022fc72@Nodemailer> References: <7086655D-64C1-4655-A1C5-051EF8F2A8C2@sb.org> <1409900128387.8022fc72@Nodemailer> Message-ID: <12E9B35F-0E3C-4C44-902C-0A3BD185DF59@sb.org> It's still undefined behavior to construct the &mut reference like that, even if it's never actually mutated. I think you need to ditch &mut and start using *mut instead. -Kevin > On Sep 4, 2014, at 11:55 PM, "Clark Gaebel" wrote: > > from_str is only used to construct read-only Iobufs, which do not support writing into the buffer. Also, if you modify the string, it should invalidate the Iobuf since the lifetime is bound to the borrowed reference of the string. > > - Clark > > >> On Thu, Sep 4, 2014 at 8:36 PM, Kevin Ballard wrote: >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.archie.mckown at gmail.com Fri Sep 5 05:00:29 2014 From: john.archie.mckown at gmail.com (John McKown) Date: Fri, 5 Sep 2014 07:00:29 -0500 Subject: [rust-dev] minor problem with "amke install" In-Reply-To: <540918F6.5060102@mozilla.com> References: <540918F6.5060102@mozilla.com> Message-ID: On Thu, Sep 4, 2014 at 8:59 PM, Brian Anderson wrote: > Thanks for the report. It's probably > https://github.com/rust-lang/rust/issues/13728. This is an easy first bug to > fix if somebody wants to jump on it. > Thanks for that link. I had some minor surgery yesterday, in the morning, and was a bit "tipsy" the rest of the day. Including when I sent the message. Which, somewhat, explains the poor grammar and spelling. But only somewhat. I will look at those issues in github before asking questions again, just to be sure that I'm not wasting anybody's time. In this particular case, the solution, for me, is a simple "sudo find" to chown the files. I might even be good enough to figure out how to _properly_ do that during the "make install" processing. If I do, I'll look up how to submit a change. I imagine it is in the documentation somewhere. And, obviously from posting a gist, I have a github account that I can use so that the maintainers could just do a pull from my copy. OOPS, time to go. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown From oldrich.vetesnik at gmail.com Fri Sep 5 08:41:51 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Fri, 5 Sep 2014 17:41:51 +0200 Subject: [rust-dev] Decodable trait cannot be found when used in a module Message-ID: Hello all, I?m having some trouble when using external crates in a module. For example the following code won?t compile. But if I put everything in main.rs it will compile. (Note: the code is also here https://gist.github.com/ollie/90e266f4cbfcad21501d if it gets mangled along the way.) main.rs: use lib::decode_json_file; mod lib; fn main() { decode_json_file(); } lib.rs: extern crate serialize; use self::serialize::json; // This has no effect: // use self::serialize::{Decodable, Decoder}; #[deriving(Show, Decodable)] struct Foo { foo: u8, } pub fn decode_json_file() { let raw_json = "{ \"foo\": 1 }"; let foo: Foo = json::decode(raw_json).unwrap(); println!("{}", foo); } When I run rustc main.rs, it prints this: lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize`? lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site lib.rs:7:18: 7:27 error: attempt to bound type parameter with a nonexistent trait `serialize::Decoder` lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize`? lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site lib.rs:7:18: 7:27 error: attempt to implement a nonexistent trait `serialize::Decodable` lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize::Decodable`? lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site lib.rs:7:18: 7:27 error: unresolved name `serialize::Decodable::decode`. lib.rs:7 #[deriving(Show, Decodable)] ^~~~~~~~~ note: in expansion of #[deriving] lib.rs:7:1: 7:29 note: expansion site error: aborting due to 6 previous errors Am I doing something wrong? Thank you and have a nice day, Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Fri Sep 5 08:49:39 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 05 Sep 2014 08:49:39 -0700 (PDT) Subject: [rust-dev] [ANN] Iobuf In-Reply-To: <12E9B35F-0E3C-4C44-902C-0A3BD185DF59@sb.org> References: <12E9B35F-0E3C-4C44-902C-0A3BD185DF59@sb.org> Message-ID: <1409932179662.12cbfee9@Nodemailer> It just seems weird to me that transmuting to a raw::Slice, and then casting the data ptr to a *mut u8 when I need it is safer than just using the &?a mut [u8] directly. But alas, I?ll fix it. ? - Clark On Fri, Sep 5, 2014 at 2:55 AM, Kevin Ballard wrote: > It's still undefined behavior to construct the &mut reference like that, even if it's never actually mutated. I think you need to ditch &mut and start using *mut instead. > -Kevin >> On Sep 4, 2014, at 11:55 PM, "Clark Gaebel" wrote: >> >> from_str is only used to construct read-only Iobufs, which do not support writing into the buffer. Also, if you modify the string, it should invalidate the Iobuf since the lifetime is bound to the borrowed reference of the string. >> >> - Clark >> >> >>> On Thu, Sep 4, 2014 at 8:36 PM, Kevin Ballard wrote: >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Fri Sep 5 09:05:07 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Fri, 5 Sep 2014 09:05:07 -0700 Subject: [rust-dev] Decodable trait cannot be found when used in a module In-Reply-To: References: Message-ID: Woah, this is unexpected behavior. I've slimmed down this error to: lib.rs: ``` extern crate serialize; struct Foo; impl , E> ::serialize::Decodable for Foo { fn decode(_d: &mut D) -> Result { fail!() } } ``` main.rs: ``` mod lib; fn main() {} ``` Which errors with: ``` lib.rs:5:10: 5:19 error: failed to resolve. Did you mean `self::serialize`? lib.rs:5 impl , E> ::serialize::Decodable for Foo { ^~~~~~~~~ lib.rs:5:10: 5:33 error: attempt to bound type parameter with a nonexistent trait `serialize::Decoder` lib.rs:5 impl , E> ::serialize::Decodable for Foo { ^~~~~~~~~~~~~~~~~~~~~~~ lib.rs:5:38: 5:47 error: failed to resolve. Did you mean `self::serialize`? lib.rs:5 impl , E> ::serialize::Decodable for Foo { ^~~~~~~~~ lib.rs:5:38: 5:66 error: attempt to implement a nonexistent trait `serialize::Decodable` lib.rs:5 impl , E> ::serialize::Decodable for Foo { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 4 previous errors ``` However, if instead we use a relative path to `serialize::Decoder` and etc, it works: ``` extern crate serialize; struct Foo; impl , E> serialize::Decodable for Foo { fn decode(_d: &mut D) -> Result { fail!() } } ``` It also works if we move the `extern crate serialize` into `main.rs`. Since almost everyone puts the `extern crate` in the lib.rs/main.rs of a project, we tend not to run into this. I thought this used to work. Has anything recently changed in name resolution that would have changed how how `extern crate` works with submodules? On Fri, Sep 5, 2014 at 8:41 AM, Old?ich Vete?n?k wrote: > Hello all, > > I?m having some trouble when using external crates in a module. For > example the following code won?t compile. > But if I put everything in main.rs it will compile. > (Note: the code is also here > https://gist.github.com/ollie/90e266f4cbfcad21501d if it gets mangled > along the way.) > > main.rs: > > use lib::decode_json_file; > > mod lib; > > fn main() { > decode_json_file(); > } > > lib.rs: > > extern crate serialize; > > use self::serialize::json; > // This has no effect: > // use self::serialize::{Decodable, Decoder}; > > #[deriving(Show, Decodable)] > struct Foo { > foo: u8, > } > > pub fn decode_json_file() { > let raw_json = "{ \"foo\": 1 }"; > > let foo: Foo = json::decode(raw_json).unwrap(); > > println!("{}", foo); > } > > When I run rustc main.rs, it prints this: > > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean > `self::serialize`? > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > lib.rs:7:18: 7:27 error: attempt to bound type parameter with a > nonexistent trait `serialize::Decoder` > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean > `self::serialize`? > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > lib.rs:7:18: 7:27 error: attempt to implement a nonexistent trait > `serialize::Decodable` > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean > `self::serialize::Decodable`? > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > lib.rs:7:18: 7:27 error: unresolved name `serialize::Decodable::decode`. > lib.rs:7 #[deriving(Show, Decodable)] > ^~~~~~~~~ > note: in expansion of #[deriving] > lib.rs:7:1: 7:29 note: expansion site > error: aborting due to 6 previous errors > > Am I doing something wrong? > > Thank you and have a nice day, > Ollie > > _______________________________________________ > 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 kevin at sb.org Fri Sep 5 13:03:28 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 5 Sep 2014 13:03:28 -0700 Subject: [rust-dev] minor problem with "amke install" In-Reply-To: References: <540918F6.5060102@mozilla.com> Message-ID: I submitted a PR yesterday in response to this thread that fixes `sudo make install` to drop the root privs for everything except the actual installation: https://github.com/rust-lang/rust/pull/17009 -Kevin > On Sep 5, 2014, at 5:00 AM, John McKown wrote: > > On Thu, Sep 4, 2014 at 8:59 PM, Brian Anderson wrote: >> Thanks for the report. It's probably >> https://github.com/rust-lang/rust/issues/13728. This is an easy first bug to >> fix if somebody wants to jump on it. >> > > Thanks for that link. I had some minor surgery yesterday, in the > morning, and was a bit "tipsy" the rest of the day. Including when I > sent the message. Which, somewhat, explains the poor grammar and > spelling. But only somewhat. I will look at those issues in github > before asking questions again, just to be sure that I'm not wasting > anybody's time. In this particular case, the solution, for me, is a > simple "sudo find" to chown the files. I might even be good enough to > figure out how to _properly_ do that during the "make install" > processing. If I do, I'll look up how to submit a change. I imagine it > is in the documentation somewhere. And, obviously from posting a gist, > I have a github account that I can use so that the maintainers could > just do a pull from my copy. > > OOPS, time to go. > > > -- > There is nothing more pleasant than traveling and meeting new people! > Genghis Khan > > Maranatha! <>< > John McKown > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From oldrich.vetesnik at gmail.com Fri Sep 5 13:28:24 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Fri, 5 Sep 2014 22:28:24 +0200 Subject: [rust-dev] Decodable trait cannot be found when used in a module In-Reply-To: References: Message-ID: <837C51A4341D407FBC973377DA55D95C@gmail.com> Ha, you?re right, if I put the `extern crate` in main.rs and drop the `self::`, it works. Anyway should I make an issue on github? On Friday 5 September 2014 at 18:05, Erick Tryzelaar wrote: > Woah, this is unexpected behavior. I've slimmed down this error to: > > lib.rs (http://lib.rs): > ``` > extern crate serialize; > > struct Foo; > > impl , E> ::serialize::Decodable for Foo { > fn decode(_d: &mut D) -> Result { > fail!() > } > } > ``` > > main.rs (http://main.rs): > ``` > mod lib; > fn main() {} > ``` > > > Which errors with: > > ``` > lib.rs:5:10: 5:19 error: failed to resolve. Did you mean `self::serialize`? > lib.rs:5 (http://lib.rs:5) impl , E> ::serialize::Decodable for Foo { > ^~~~~~~~~ > lib.rs:5:10: 5:33 error: attempt to bound type parameter with a nonexistent trait `serialize::Decoder` > lib.rs:5 (http://lib.rs:5) impl , E> ::serialize::Decodable for Foo { > ^~~~~~~~~~~~~~~~~~~~~~~ > lib.rs:5:38: 5:47 error: failed to resolve. Did you mean `self::serialize`? > lib.rs:5 (http://lib.rs:5) impl , E> ::serialize::Decodable for Foo { > ^~~~~~~~~ > lib.rs:5:38: 5:66 error: attempt to implement a nonexistent trait `serialize::Decodable` > lib.rs:5 (http://lib.rs:5) impl , E> ::serialize::Decodable for Foo { > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > error: aborting due to 4 previous errors > ``` > > However, if instead we use a relative path to `serialize::Decoder` and etc, it works: > > ``` > extern crate serialize; > > struct Foo; > > impl , E> serialize::Decodable for Foo { > fn decode(_d: &mut D) -> Result { > fail!() > } > } > ``` > > It also works if we move the `extern crate serialize` into `main.rs (http://main.rs)`. Since almost everyone puts the `extern crate` in the lib.rs/main.rs (http://lib.rs/main.rs) of a project, we tend not to run into this. I thought this used to work. Has anything recently changed in name resolution that would have changed how how `extern crate` works with submodules? > > > > On Fri, Sep 5, 2014 at 8:41 AM, Old?ich Vete?n?k wrote: > > Hello all, > > > > I?m having some trouble when using external crates in a module. For example the following code won?t compile. > > But if I put everything in main.rs (http://main.rs) it will compile. > > (Note: the code is also here https://gist.github.com/ollie/90e266f4cbfcad21501d if it gets mangled along the way.) > > > > main.rs (http://main.rs): > > > > use lib::decode_json_file; > > > > mod lib; > > > > fn main() { > > decode_json_file(); > > } > > > > > > lib.rs (http://lib.rs): > > > > extern crate serialize; > > > > use self::serialize::json; > > // This has no effect: > > // use self::serialize::{Decodable, Decoder}; > > > > #[deriving(Show, Decodable)] > > struct Foo { > > foo: u8, > > } > > > > pub fn decode_json_file() { > > let raw_json = "{ \"foo\": 1 }"; > > > > let foo: Foo = json::decode(raw_json).unwrap(); > > > > println!("{}", foo); > > } > > > > > > When I run rustc main.rs (http://main.rs), it prints this: > > > > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize`? > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > lib.rs:7:18: 7:27 error: attempt to bound type parameter with a nonexistent trait `serialize::Decoder` > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize`? > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > lib.rs:7:18: 7:27 error: attempt to implement a nonexistent trait `serialize::Decodable` > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > lib.rs:7:18: 7:27 error: failed to resolve. Did you mean `self::serialize::Decodable`? > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > lib.rs:7:18: 7:27 error: unresolved name `serialize::Decodable::decode`. > > lib.rs:7 (http://lib.rs:7) #[deriving(Show, Decodable)] > > ^~~~~~~~~ > > note: in expansion of #[deriving] > > lib.rs:7:1: 7:29 note: expansion site > > error: aborting due to 6 previous errors > > > > > > Am I doing something wrong? > > > > Thank you and have a nice day, > > Ollie > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org) > > https://mail.mozilla.org/listinfo/rust-dev > From banderson at mozilla.com Fri Sep 5 15:29:00 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 05 Sep 2014 15:29:00 -0700 Subject: [rust-dev] minor problem with "amke install" In-Reply-To: References: <540918F6.5060102@mozilla.com> Message-ID: <540A392C.4000800@mozilla.com> Thanks, Kevin! On 09/05/2014 01:03 PM, Kevin Ballard wrote: > I submitted a PR yesterday in response to this thread that fixes `sudo make install` to drop the root privs for everything except the actual installation: https://github.com/rust-lang/rust/pull/17009 > > -Kevin > >> On Sep 5, 2014, at 5:00 AM, John McKown wrote: >> >> On Thu, Sep 4, 2014 at 8:59 PM, Brian Anderson wrote: >>> Thanks for the report. It's probably >>> https://github.com/rust-lang/rust/issues/13728. This is an easy first bug to >>> fix if somebody wants to jump on it. >>> >> Thanks for that link. I had some minor surgery yesterday, in the >> morning, and was a bit "tipsy" the rest of the day. Including when I >> sent the message. Which, somewhat, explains the poor grammar and >> spelling. But only somewhat. I will look at those issues in github >> before asking questions again, just to be sure that I'm not wasting >> anybody's time. In this particular case, the solution, for me, is a >> simple "sudo find" to chown the files. I might even be good enough to >> figure out how to _properly_ do that during the "make install" >> processing. If I do, I'll look up how to submit a change. I imagine it >> is in the documentation somewhere. And, obviously from posting a gist, >> I have a github account that I can use so that the maintainers could >> just do a pull from my copy. >> >> OOPS, time to go. >> >> >> -- >> There is nothing more pleasant than traveling and meeting new people! >> Genghis Khan >> >> Maranatha! <>< >> John McKown >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev From john.archie.mckown at gmail.com Fri Sep 5 16:27:06 2014 From: john.archie.mckown at gmail.com (John McKown) Date: Fri, 5 Sep 2014 18:27:06 -0500 Subject: [rust-dev] minor problem with "amke install" In-Reply-To: References: <540918F6.5060102@mozilla.com> Message-ID: On Fri, Sep 5, 2014 at 3:03 PM, Kevin Ballard wrote: > I submitted a PR yesterday in response to this thread that fixes `sudo make install` to drop the root privs for everything except the actual installation: https://github.com/rust-lang/rust/pull/17009 > > -Kevin > They must have integrated your patch (or whatever its called with git - merged?). I just did: git pull && ./configure && make all && sudo make install There were no files owned by root in my ~/source-oem/rust subdirectory. I use "source-oem" for other people and vendor's source. Thank you very much for that. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown From smadhueagle at outlook.com Sat Sep 6 10:09:30 2014 From: smadhueagle at outlook.com (Madhu Srinivasan) Date: Sat, 6 Sep 2014 17:09:30 +0000 Subject: [rust-dev] rust and cuda Message-ID: Hello fellow Rustians, I am wondering (before attempting anything) if anyone has tried creating cuda bindings for rust? Or has discovered any other route to use cuda kernels with rust as the host language ? If not, I am willing to work in this direction, but would need some guidance from the community on using rust-bindgen and it's FFI usage etc. Thanks, Madhu https://github.com/smadhueagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Sep 6 11:06:35 2014 From: corey at octayn.net (Corey Richardson) Date: Sat, 6 Sep 2014 14:06:35 -0400 Subject: [rust-dev] rust and cuda In-Reply-To: References: Message-ID: See http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf and http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/ for prior work. On Sat, Sep 6, 2014 at 1:09 PM, Madhu Srinivasan wrote: > Hello fellow Rustians, > > I am wondering (before attempting anything) if anyone has tried creating > cuda bindings for rust? Or has discovered any other route to use cuda > kernels with rust as the host language ? > > If not, I am willing to work in this direction, but would need some guidance > from the community on using rust-bindgen and it's FFI usage etc. > > > Thanks, > > Madhu > > https://github.com/smadhueagle > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From smadhueagle at outlook.com Sat Sep 6 12:25:10 2014 From: smadhueagle at outlook.com (Madhu Srinivasan) Date: Sat, 6 Sep 2014 19:25:10 +0000 Subject: [rust-dev] rust and cuda In-Reply-To: References: , Message-ID: Thanks ! Yes, I came across the blog and I've read the paper. However, I am not looking at writing GPU Kernels in Rust that can be LLVM'ed into a PTX backend. I'm looking for something along the lines of rust-opencl https://github.com/luqmana/rust-opencl . I'll be looking into this more deeply in the coming weeks, so please let me know if you have any inputs/opinions. Madhu > Date: Sat, 6 Sep 2014 14:06:35 -0400 > Subject: Re: [rust-dev] rust and cuda > From: corey at octayn.net > To: smadhueagle at outlook.com > CC: rust-dev at mozilla.org > > See http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf and > http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/ > for prior work. > > On Sat, Sep 6, 2014 at 1:09 PM, Madhu Srinivasan > wrote: > > Hello fellow Rustians, > > > > I am wondering (before attempting anything) if anyone has tried creating > > cuda bindings for rust? Or has discovered any other route to use cuda > > kernels with rust as the host language ? > > > > If not, I am willing to work in this direction, but would need some guidance > > from the community on using rust-bindgen and it's FFI usage etc. > > > > > > Thanks, > > > > Madhu > > > > https://github.com/smadhueagle > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > http://octayn.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.archie.mckown at gmail.com Sat Sep 6 15:49:18 2014 From: john.archie.mckown at gmail.com (John McKown) Date: Sat, 6 Sep 2014 17:49:18 -0500 Subject: [rust-dev] doc format error? rust.html Message-ID: Starting at line 607 in doc/rust.html
num_lit : nonzero_dec [ dec_digit |
'_' ] * num_suffix ?
        | '0' [       [ dec_digit | '_' ] * num_suffix ?
              | 'b'   [ '1' | '0' |
'_' ] + int_suffix ?
              | 'o'   [ oct_digit | '_' ] + int_suffix ?
              | 'x'   [ hex_digit | '_' ] + int_suffix ? ] ;

The line:
       | '0' [       [ dec_digit | '_' ] * num_suffix ?
the very first [ seems to be inserted in error. I.e the line should read
       | '0'         [ dec_digit | '_' ] * num_suffix ?
This backtracks to line 401 of file src/doc/rust.md. This appears true
to me because I modified that line to remove the extraneous [, then
did a "make docs".

detail:

$git diff
diff --git a/src/doc/rust.md b/src/doc/rust.md
index 69bef81..06bdc87 100644
--- a/src/doc/rust.md
+++ b/src/doc/rust.md
@@ -398,7 +398,7 @@ b"\\x52"; br"\x52";                  // \x52

 ~~~~ {.ebnf .gram}
 num_lit : nonzero_dec [ dec_digit | '_' ] * num_suffix ?
-        | '0' [       [ dec_digit | '_' ] * num_suffix ?
+        | '0'         [ dec_digit | '_' ] * num_suffix ?
               | 'b'   [ '1' | '0' | '_' ] + int_suffix ?
               | 'o'   [ oct_digit | '_' ] + int_suffix ?
               | 'x'   [ hex_digit | '_' ] + int_suffix ? ] ;

The above is relative to commit
20c0ba1279efb5d40fcd4a739a50d09e48e0b37f . I cloned from the repo at
https://github.com/rust-lang/rust.git

===

One question about the above definition of a num_lit. Can any body
explain why the first two lines are not simply:

num_lit: dec_digit [ dec_digit|'_']* num_suffix ?

Why have two lines, which are identical other than the starting
character either a 0 or a nonzero_dec? I am not claiming to be an
expert on EBNF but it seems unnecessary.

===
As an aside:

One possible enhancement to the documentation would be if it
_explicitly_ stated that block comments can be nested. I have worked
with other languages which also use /* ... */ to delimit block
comments, but they do not allow a block comment within a block
comment. This is not really an error, but might be helpful to others
who have encounter this restriction in other languages.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

From john.archie.mckown at gmail.com  Sun Sep  7 08:39:29 2014
From: john.archie.mckown at gmail.com (John McKown)
Date: Sun, 7 Sep 2014 10:39:29 -0500
Subject: [rust-dev] submitting documentation updates?
Message-ID: 

Perhaps this is somewhere in the rust distribution and I simply
haven't found it yet. I have been read the rust documentation, which I
built from the doc/rust.html by converting it to a PDF, then reading
the PDF on my tablet. Which is beside the point.

I have seen some parts of the documentation which I believe are
incomplete (or just confusing to me) or not formatted correctly.

I am wondering what is the correct way to submit documentation updates
to the maintainers? I have done a fork on github into my own account.
And I keep it fairly well synchronized with the rust-lang repository.
I keep my changes in a separate branch, not in "master", so it is
easier for me to tell what I have changed.

One thing I'm curious about is: Should I make each logical change a
separate commit? If I do, it seems to me that would make it easier for
the maintainers to "cherry pick" what they would like and ignore
things they disagree with. I'm not used to using git for true
collaboration.

Many thanks for your assistance.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

From me at kevincantu.org  Sun Sep  7 15:54:22 2014
From: me at kevincantu.org (Kevin Cantu)
Date: Sun, 7 Sep 2014 15:54:22 -0700
Subject: [rust-dev] submitting documentation updates?
In-Reply-To: 
References: 
Message-ID: 

Pull requests are fine.  Just go on GitHub and do a pull request from to
you/rust:branchx to rust-lang/rust:master.  (Pull requests can go
cross-repo like that.)  The core team is unlikely to cherry-pick.

Depends on what you're doing how much you'll want to put in separate pull
requests or all together.

Just ask around and we'll have you fluent with git in a jiffy.


Kevin






On Sun, Sep 7, 2014 at 8:39 AM, John McKown 
wrote:

> Perhaps this is somewhere in the rust distribution and I simply
> haven't found it yet. I have been read the rust documentation, which I
> built from the doc/rust.html by converting it to a PDF, then reading
> the PDF on my tablet. Which is beside the point.
>
> I have seen some parts of the documentation which I believe are
> incomplete (or just confusing to me) or not formatted correctly.
>
> I am wondering what is the correct way to submit documentation updates
> to the maintainers? I have done a fork on github into my own account.
> And I keep it fairly well synchronized with the rust-lang repository.
> I keep my changes in a separate branch, not in "master", so it is
> easier for me to tell what I have changed.
>
> One thing I'm curious about is: Should I make each logical change a
> separate commit? If I do, it seems to me that would make it easier for
> the maintainers to "cherry pick" what they would like and ignore
> things they disagree with. I'm not used to using git for true
> collaboration.
>
> Many thanks for your assistance.
>
> --
> There is nothing more pleasant than traveling and meeting new people!
> Genghis Khan
>
> Maranatha! <><
> John McKown
> _______________________________________________
> 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 john.archie.mckown at gmail.com  Sun Sep  7 17:47:32 2014
From: john.archie.mckown at gmail.com (John McKown)
Date: Sun, 7 Sep 2014 19:47:32 -0500
Subject: [rust-dev] submitting documentation updates?
In-Reply-To: 
References: 
	
Message-ID: 

On Sun, Sep 7, 2014 at 5:54 PM, Kevin Cantu  wrote:
> Pull requests are fine.  Just go on GitHub and do a pull request from to
> you/rust:branchx to rust-lang/rust:master.  (Pull requests can go cross-repo
> like that.)  The core team is unlikely to cherry-pick.
>
> Depends on what you're doing how much you'll want to put in separate pull
> requests or all together.
>
> Just ask around and we'll have you fluent with git in a jiffy.
>
>
> Kevin
>

Thanks for the information. Upon further review, my "fix" wasn't one.
I had cataract surgery 3 days ago (went very well) and my vision was a
bit blurry. So I misread what the original author wrote. The doc is
correct.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

From me at kevincantu.org  Sun Sep  7 19:21:02 2014
From: me at kevincantu.org (Kevin Cantu)
Date: Sun, 7 Sep 2014 19:21:02 -0700
Subject: [rust-dev] submitting documentation updates?
In-Reply-To: 
References: 
	
	
Message-ID: 

Haha, good luck on the recovery.  :)


Kevin

On Sun, Sep 7, 2014 at 5:47 PM, John McKown 
wrote:

> On Sun, Sep 7, 2014 at 5:54 PM, Kevin Cantu  wrote:
> > Pull requests are fine.  Just go on GitHub and do a pull request from to
> > you/rust:branchx to rust-lang/rust:master.  (Pull requests can go
> cross-repo
> > like that.)  The core team is unlikely to cherry-pick.
> >
> > Depends on what you're doing how much you'll want to put in separate pull
> > requests or all together.
> >
> > Just ask around and we'll have you fluent with git in a jiffy.
> >
> >
> > Kevin
> >
>
> Thanks for the information. Upon further review, my "fix" wasn't one.
> I had cataract surgery 3 days ago (went very well) and my vision was a
> bit blurry. So I misread what the original author wrote. The doc is
> correct.
>
> --
> There is nothing more pleasant than traveling and meeting new people!
> Genghis Khan
>
> Maranatha! <><
> John McKown
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From oldrich.vetesnik at gmail.com  Mon Sep  8 06:44:08 2014
From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=)
Date: Mon, 8 Sep 2014 15:44:08 +0200
Subject: [rust-dev] Is there a PNG lib?
Message-ID: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>

Hello,

I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
I tried searching but wasn?t very successful. :-)

Thank you,
Ollie


From corey at octayn.net  Mon Sep  8 06:56:55 2014
From: corey at octayn.net (Corey Richardson)
Date: Mon, 8 Sep 2014 09:56:55 -0400
Subject: [rust-dev] Is there a PNG lib?
In-Reply-To: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
References: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
Message-ID: 

https://github.com/PistonDevelopers/rust-image

On Mon, Sep 8, 2014 at 9:44 AM, Old?ich Vete?n?k
 wrote:
> Hello,
>
> I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
> I tried searching but wasn?t very successful. :-)
>
> Thank you,
> Ollie
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/

From dpx.infinity at gmail.com  Mon Sep  8 06:57:16 2014
From: dpx.infinity at gmail.com (Vladimir Matveev)
Date: Mon, 8 Sep 2014 17:57:16 +0400
Subject: [rust-dev] Is there a PNG lib?
In-Reply-To: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
References: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
Message-ID: 

Hi!

These libraries may be interesting for you:
 * https://github.com/servo/rust-png
 * https://github.com/PistonDevelopers/rust-image

It is also very simple to run external tools like ImageMagick from Rust. You will need Command [1] API for that.

  [1]: http://doc.rust-lang.org/std/io/process/struct.Command.html

On 08 ????. 2014 ?., at 17:44, Old?ich Vete?n?k  wrote:

> Hello,
> 
> I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
> I tried searching but wasn?t very successful. :-)
> 
> Thank you,
> Ollie
> 
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev


From oldrich.vetesnik at gmail.com  Mon Sep  8 07:03:22 2014
From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=)
Date: Mon, 8 Sep 2014 16:03:22 +0200
Subject: [rust-dev] Is there a PNG lib?
In-Reply-To: 
References: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
	
Message-ID: <1EFC19B2B78946DB93A098A384CA2CFF@gmail.com>

Awesome, thank you guys!

I?m really looking forward to ?cargo search?. :-)

Ollie


On Monday 8 September 2014 at 15:57, Vladimir Matveev wrote:

> Hi!
>  
> These libraries may be interesting for you:
> * https://github.com/servo/rust-png
> * https://github.com/PistonDevelopers/rust-image
>  
> It is also very simple to run external tools like ImageMagick from Rust. You will need Command [1] API for that.
>  
> [1]: http://doc.rust-lang.org/std/io/process/struct.Command.html
>  
> On 08 ????. 2014 ?., at 17:44, Old?ich Vete?n?k  wrote:
>  
> > Hello,
> >  
> > I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
> > I tried searching but wasn?t very successful. :-)
> >  
> > Thank you,
> > Ollie
> >  
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org)
> > https://mail.mozilla.org/listinfo/rust-dev
>  




From dpx.infinity at gmail.com  Mon Sep  8 07:09:56 2014
From: dpx.infinity at gmail.com (Vladimir Matveev)
Date: Mon, 8 Sep 2014 18:09:56 +0400
Subject: [rust-dev] Is there a PNG lib?
In-Reply-To: <1EFC19B2B78946DB93A098A384CA2CFF@gmail.com>
References: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
	
	<1EFC19B2B78946DB93A098A384CA2CFF@gmail.com>
Message-ID: <3C4D4CD1-AD3A-40F6-B109-C13D69699DA3@gmail.com>

You?re welcome :)

Cargo will provide a central repository in the future, but in the meantime you can use these sites [1][2] to search for packages. Also, as Github is the main repository hosting used by the Rust community, you can search there and you can be fairly confident that if you can?t find something there then it probably does not exists :)

  [1]: http://www.rust-ci.org/
  [2]: http://rustkit.io/

On 08 ????. 2014 ?., at 18:03, Old?ich Vete?n?k  wrote:

> Awesome, thank you guys!
> 
> I?m really looking forward to ?cargo search?. :-)
> 
> Ollie
> 
> 
> On Monday 8 September 2014 at 15:57, Vladimir Matveev wrote:
> 
>> Hi!
>> 
>> These libraries may be interesting for you:
>> * https://github.com/servo/rust-png
>> * https://github.com/PistonDevelopers/rust-image
>> 
>> It is also very simple to run external tools like ImageMagick from Rust. You will need Command [1] API for that.
>> 
>> [1]: http://doc.rust-lang.org/std/io/process/struct.Command.html
>> 
>> On 08 ????. 2014 ?., at 17:44, Old?ich Vete?n?k  wrote:
>> 
>>> Hello,
>>> 
>>> I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
>>> I tried searching but wasn?t very successful. :-)
>>> 
>>> Thank you,
>>> Ollie
>>> 
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org)
>>> https://mail.mozilla.org/listinfo/rust-dev
>> 
> 
> 
> 


From oldrich.vetesnik at gmail.com  Mon Sep  8 07:22:49 2014
From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=)
Date: Mon, 8 Sep 2014 16:22:49 +0200
Subject: [rust-dev] Is there a PNG lib?
In-Reply-To: <3C4D4CD1-AD3A-40F6-B109-C13D69699DA3@gmail.com>
References: <5E7AF0AEBCDD48EAB4441BDD099742DA@gmail.com>
	
	<1EFC19B2B78946DB93A098A384CA2CFF@gmail.com>
	<3C4D4CD1-AD3A-40F6-B109-C13D69699DA3@gmail.com>
Message-ID: <1AB77D23936749369028CDF74D8904C6@gmail.com>

Awesome again. :-)

I think those two could/should be mentioned in the Cargo FAQ until it is ready.
Also Cargo could be mentioned on doc.rust-lang.org somewhere, probably in the crates section.
I?ll try to come up with a PR if there is time.

Ollie


On Monday 8 September 2014 at 16:09, Vladimir Matveev wrote:

> You?re welcome :)
>  
> Cargo will provide a central repository in the future, but in the meantime you can use these sites [1][2] to search for packages. Also, as Github is the main repository hosting used by the Rust community, you can search there and you can be fairly confident that if you can?t find something there then it probably does not exists :)
>  
> [1]: http://www.rust-ci.org/
> [2]: http://rustkit.io/
>  
> On 08 ????. 2014 ?., at 18:03, Old?ich Vete?n?k  wrote:
>  
> > Awesome, thank you guys!
> >  
> > I?m really looking forward to ?cargo search?. :-)
> >  
> > Ollie
> >  
> >  
> > On Monday 8 September 2014 at 15:57, Vladimir Matveev wrote:
> >  
> > > Hi!
> > >  
> > > These libraries may be interesting for you:
> > > * https://github.com/servo/rust-png
> > > * https://github.com/PistonDevelopers/rust-image
> > >  
> > > It is also very simple to run external tools like ImageMagick from Rust. You will need Command [1] API for that.
> > >  
> > > [1]: http://doc.rust-lang.org/std/io/process/struct.Command.html
> > >  
> > > On 08 ????. 2014 ?., at 17:44, Old?ich Vete?n?k  wrote:
> > >  
> > > > Hello,
> > > >  
> > > > I?m curious - is there a PNG processing lib for Rust? I?d like to write a tiny client tool for processing a directory of images into HTML and I?ll need to resize those big images.
> > > > I tried searching but wasn?t very successful. :-)
> > > >  
> > > > Thank you,
> > > > Ollie
> > > >  
> > > > _______________________________________________
> > > > Rust-dev mailing list
> > > > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org)
> > > > https://mail.mozilla.org/listinfo/rust-dev
> > >  
> >  
>  




From Michael.Fox at caviumnetworks.com  Sun Sep  7 18:03:26 2014
From: Michael.Fox at caviumnetworks.com (Fox, Michael)
Date: Mon, 8 Sep 2014 01:03:26 +0000
Subject: [rust-dev] FFI: how to deal with different platforms
Message-ID: <1D87E94D-2FF8-4FEE-9E9A-DCD14976B424@caviumnetworks.com>

How can FFI work across platforms unless you compile against the specific platform?s headers?

Sometimes a common header defines the same-named structure, type or macro differently depending on your platform.

For example, here?s a definition from termios.h on OSX:

 #define CSIZE       0x00000300  /* character size mask */

And here?s the same one on some old Linux:

 #define CSIZE   0000060

So, you can?t just take one of them and define it like:

  pub static CSIZE: ulong_t = 0x300;

I don?t see how it can work unless you embed a C compiler which reads and uses the actual platform?s headers.

From jack at metajack.im  Mon Sep  8 09:44:56 2014
From: jack at metajack.im (Jack Moffitt)
Date: Mon, 8 Sep 2014 10:44:56 -0600
Subject: [rust-dev] FFI: how to deal with different platforms
In-Reply-To: <1D87E94D-2FF8-4FEE-9E9A-DCD14976B424@caviumnetworks.com>
References: <1D87E94D-2FF8-4FEE-9E9A-DCD14976B424@caviumnetworks.com>
Message-ID: 

> Sometimes a common header defines the same-named structure, type or macro differently depending on your platform.
>
> For example, here?s a definition from termios.h on OSX:
>
>  #define CSIZE       0x00000300  /* character size mask */
>
> And here?s the same one on some old Linux:
>
>  #define CSIZE   0000060

You'll need to do something like this:

#[cfg(target_os="macos")]
pub static CSIZE: ulong_t = 0x300;
#[cfg(target_os="linux")]
pub static CSIZE: ulong_t = 0x60;

jack.

From smcarthur at mozilla.com  Mon Sep  8 09:49:48 2014
From: smcarthur at mozilla.com (Sean McArthur)
Date: Mon, 8 Sep 2014 09:49:48 -0700
Subject: [rust-dev] FFI: how to deal with different platforms
In-Reply-To: <1D87E94D-2FF8-4FEE-9E9A-DCD14976B424@caviumnetworks.com>
References: <1D87E94D-2FF8-4FEE-9E9A-DCD14976B424@caviumnetworks.com>
Message-ID: 

You can use define the CSIZE a couple times in your file, with conditional
compilation: http://doc.rust-lang.org/rust.html#conditional-compilation


On Sun, Sep 7, 2014 at 6:03 PM, Fox, Michael  wrote:

> How can FFI work across platforms unless you compile against the specific
> platform?s headers?
>
> Sometimes a common header defines the same-named structure, type or macro
> differently depending on your platform.
>
> For example, here?s a definition from termios.h on OSX:
>
>  #define CSIZE       0x00000300  /* character size mask */
>
> And here?s the same one on some old Linux:
>
>  #define CSIZE   0000060
>
> So, you can?t just take one of them and define it like:
>
>   pub static CSIZE: ulong_t = 0x300;
>
> I don?t see how it can work unless you embed a C compiler which reads and
> uses the actual platform?s headers.
> _______________________________________________
> 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 allen.welkie at gmail.com  Tue Sep  9 13:39:01 2014
From: allen.welkie at gmail.com (Allen Welkie)
Date: Tue, 9 Sep 2014 16:39:01 -0400
Subject: [rust-dev] Closures with owned environments
Message-ID: 

In this stackoverflow question:

http://stackoverflow.com/questions/21130272/return-a-closure-from-a-function

Chris Morgan mentions the possibility of adding closures with owned
environments with the DST implementation. Is this being done with the
current DST effort? If not, are there plans to add it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dpx.infinity at gmail.com  Tue Sep  9 14:00:09 2014
From: dpx.infinity at gmail.com (Vladimir Matveev)
Date: Wed, 10 Sep 2014 01:00:09 +0400
Subject: [rust-dev] Closures with owned environments
In-Reply-To: 
References: 
Message-ID: 

Hi, Allen!

In fact, it is possible to do it now without DST, using unboxed closures only:

#![feature(unboxed_closures, unboxed_closure_sugar)]

fn make_adder(x: int) -> Box<|&: int| -> int> {
    box |&: y: int| x + y
}

fn main() {
    let f = make_adder(3);
    println!("{}", f.call((4i,)));
}

Test it here: http://is.gd/mCJ6Dh

This code employs the idea that unboxed closure is just an instance of
some anonymous struct implementing one of Fn* traits, so we can just
return a boxed trait object representing the closure. The call syntax
is ugly, however, but this should change in the nearest future (though
explicit dereferencing, like (*f)(x), will likely be needed anyway).

2014-09-10 0:39 GMT+04:00 Allen Welkie :
> In this stackoverflow question:
>
> http://stackoverflow.com/questions/21130272/return-a-closure-from-a-function
>
> Chris Morgan mentions the possibility of adding closures with owned
> environments with the DST implementation. Is this being done with the
> current DST effort? If not, are there plans to add it?
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

From allen.welkie at gmail.com  Tue Sep  9 14:17:50 2014
From: allen.welkie at gmail.com (Allen Welkie)
Date: Tue, 9 Sep 2014 17:17:50 -0400
Subject: [rust-dev] Closures with owned environments
In-Reply-To: 
References: 
	
Message-ID: 

Oh, cool. Instead of returning the closure from a function, I'd rather use
it in a call to map(), then return that Map struct. Something like:

fn map_add>(it: I, x: int) -> Map<...> {
    it.map(|&: y: int| x + y)
}

So does this mean I just need to wait until the map() function accepts
unboxed closures?

On Tue, Sep 9, 2014 at 5:00 PM, Vladimir Matveev 
wrote:

> Hi, Allen!
>
> In fact, it is possible to do it now without DST, using unboxed closures
> only:
>
> #![feature(unboxed_closures, unboxed_closure_sugar)]
>
> fn make_adder(x: int) -> Box<|&: int| -> int> {
>     box |&: y: int| x + y
> }
>
> fn main() {
>     let f = make_adder(3);
>     println!("{}", f.call((4i,)));
> }
>
> Test it here: http://is.gd/mCJ6Dh
>
> This code employs the idea that unboxed closure is just an instance of
> some anonymous struct implementing one of Fn* traits, so we can just
> return a boxed trait object representing the closure. The call syntax
> is ugly, however, but this should change in the nearest future (though
> explicit dereferencing, like (*f)(x), will likely be needed anyway).
>
> 2014-09-10 0:39 GMT+04:00 Allen Welkie :
> > In this stackoverflow question:
> >
> >
> http://stackoverflow.com/questions/21130272/return-a-closure-from-a-function
> >
> > Chris Morgan mentions the possibility of adding closures with owned
> > environments with the DST implementation. Is this being done with the
> > current DST effort? If not, are there plans to add 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 pnathan.software at gmail.com  Tue Sep  9 14:28:14 2014
From: pnathan.software at gmail.com (Paul Nathan)
Date: Tue, 9 Sep 2014 14:28:14 -0700
Subject: [rust-dev] [ANN] Seattle Rust G+ community created
Message-ID: 

For people in Seattle (or are interested) who want to keep in touch better
than the extant Eventbrite:

https://plus.google.com/u/0/communities/110407313039175953018
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidb at davidb.org  Tue Sep  9 17:22:13 2014
From: davidb at davidb.org (David Brown)
Date: Tue, 9 Sep 2014 17:22:13 -0700
Subject: [rust-dev] Bug in lifetime inference?
In-Reply-To: 
References: 
Message-ID: <20140910002213.GA28123@davidb.org>

I've seen something similar recently, with this code:

----------------------------------------------------------------------
fn main() {
    // Fails.
    assert_eq!(stuff(), &[]);

    // Works
    let tmp: &'static [uint] = &[];
    assert_eq!(stuff(), tmp);
}

static simple: &'static [uint] = &[1, 2];

fn stuff() -> &'static [uint] {
    simple
}
----------------------------------------------------------------------

The failing code worked a week or so ago.  Similar issue in that I can
make it work by giving an explicit type for the literal array.

David

On Sat, Aug 30, 2014 at 04:52:00PM +0800, Kai Noda wrote:
>Hi Rusters,
>I'm very new to Rust, so I'd like you to check if this is really a
>compiler bug or not.
>fn main() {
>? ? let s1 = &[0i];
>? ? {
>? ? ? ? let s2 = &[0i];
>? ? ? ? let s3 = if true { s1 } else { s2 };
>? ? };
>}
>[1]http://is.gd/NCeGpl
>
>:5:19: 5:23 error: borrowed value does not live long enough
>:5         let s2 = &[0i];
>                           ^~~~
>:2:11: 8:2 note: reference must be valid for the block at 2:10...
>:2 fn main() {
>:3     let s1 = &[0i];
>:4     {
>:5         let s2 = &[0i];
>:6         let s3 = if true { s1 } else { s2 };
>:7     };
>         ...
>:4:5: 7:6 note: ...but borrowed value is only valid for the block at 4:4
>:4     {
>:5         let s2 = &[0i];
>:6         let s3 = if true { s1 } else { s2 };
>:7     };
>error: aborting due to previous error
>
>Seems like s1 and s2 are inferred as &[int, ..1] and when I manually
>type them as &[int], it successfully compiles.
>fn main() {
>? ? let s1: &[int] = &[0i];
>? ? {
>? ? ? ? let s2: &[int] = &[0i];
>? ? ? ? let s3 = if true { s1 } else { s2 };
>? ? };
>}
>Putting s1 and s2 into a single block also satisfies the compiler.
>fn main() {
>? ? let s1 = &[0i];
>? ? let s2 = &[0i];
>? ? let s3 = if true { s1 } else { s2 };
>}
>I came from C++ and I think the way I take reference of a fixed vector
>literal is correct.
>[2]http://doc.rust-lang.org/rust.html#pointer-types
>I was originally trying to fix this line which doesn't compile with
>the nightly build of Rust:
>[3]https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55
>No similar issue is filed here:
>[4]https://github.com/rust-lang/rust/labels/A-lifetimes
>Best regards,
>Kai
>??? ? <[5]nodakai at gmail.com>
>
>References
>
>   Visible links
>   1. http://is.gd/NCeGpl
>   2. http://doc.rust-lang.org/rust.html#pointer-types
>   3. https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55
>   4. https://github.com/rust-lang/rust/labels/A-lifetimes
>   5. mailto:nodakai at gmail.com

>_______________________________________________
>Rust-dev mailing list
>Rust-dev at mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev


From nodakai at gmail.com  Wed Sep 10 03:26:47 2014
From: nodakai at gmail.com (Kai Noda)
Date: Wed, 10 Sep 2014 18:26:47 +0800
Subject: [rust-dev] Bug in lifetime inference?
In-Reply-To: <20140910002213.GA28123@davidb.org>
References: 
	<20140910002213.GA28123@davidb.org>
Message-ID: 

Hi David,

I stopped worrying about the alleged bug I had reported after I saw Git
HEAD happily compiled it a few days later.

I found your case more interesting because I could compile your code by
changing

assert_eq!(stuff(), &[]);

to

let b = stuff() == &[];

Regards,
Kai


2014-09-10 8:22 GMT+08:00 David Brown :

> I've seen something similar recently, with this code:
>
> ----------------------------------------------------------------------
> fn main() {
>    // Fails.
>    assert_eq!(stuff(), &[]);
>
>    // Works
>    let tmp: &'static [uint] = &[];
>    assert_eq!(stuff(), tmp);
> }
>
> static simple: &'static [uint] = &[1, 2];
>
> fn stuff() -> &'static [uint] {
>    simple
> }
> ----------------------------------------------------------------------
>
> The failing code worked a week or so ago.  Similar issue in that I can
> make it work by giving an explicit type for the literal array.
>
> David
>
> On Sat, Aug 30, 2014 at 04:52:00PM +0800, Kai Noda wrote:
>
>> Hi Rusters,
>> I'm very new to Rust, so I'd like you to check if this is really a
>> compiler bug or not.
>> fn main() {
>>     let s1 = &[0i];
>>     {
>>         let s2 = &[0i];
>>         let s3 = if true { s1 } else { s2 };
>>     };
>> }
>> [1]http://is.gd/NCeGpl
>>
>>
>> :5:19: 5:23 error: borrowed value does not live long enough
>> :5         let s2 = &[0i];
>>                           ^~~~
>> :2:11: 8:2 note: reference must be valid for the block at 2:10...
>> :2 fn main() {
>> :3     let s1 = &[0i];
>> :4     {
>> :5         let s2 = &[0i];
>> :6         let s3 = if true { s1 } else { s2 };
>> :7     };
>>         ...
>> :4:5: 7:6 note: ...but borrowed value is only valid for the block
>> at 4:4
>> :4     {
>> :5         let s2 = &[0i];
>> :6         let s3 = if true { s1 } else { s2 };
>> :7     };
>> error: aborting due to previous error
>>
>> Seems like s1 and s2 are inferred as &[int, ..1] and when I manually
>> type them as &[int], it successfully compiles.
>> fn main() {
>>     let s1: &[int] = &[0i];
>>     {
>>         let s2: &[int] = &[0i];
>>         let s3 = if true { s1 } else { s2 };
>>     };
>> }
>> Putting s1 and s2 into a single block also satisfies the compiler.
>> fn main() {
>>     let s1 = &[0i];
>>     let s2 = &[0i];
>>     let s3 = if true { s1 } else { s2 };
>> }
>> I came from C++ and I think the way I take reference of a fixed vector
>> literal is correct.
>> [2]http://doc.rust-lang.org/rust.html#pointer-types
>> I was originally trying to fix this line which doesn't compile with
>> the nightly build of Rust:
>> [3]https://github.com/servo/rust-url/blob/master/src/form_
>> urlencoded.rs#L55
>> No similar issue is filed here:
>> [4]https://github.com/rust-lang/rust/labels/A-lifetimes
>> Best regards,
>> Kai
>> ??  ? <[5]nodakai at gmail.com>
>>
>> References
>>
>>   Visible links
>>   1. http://is.gd/NCeGpl
>>   2. http://doc.rust-lang.org/rust.html#pointer-types
>>   3. https://github.com/servo/rust-url/blob/master/src/form_
>> urlencoded.rs#L55
>>   4. https://github.com/rust-lang/rust/labels/A-lifetimes
>>   5. mailto:nodakai at gmail.com
>>
>
>  _______________________________________________
>> 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 oldrich.vetesnik at gmail.com  Wed Sep 10 07:05:12 2014
From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=)
Date: Wed, 10 Sep 2014 16:05:12 +0200
Subject: [rust-dev] Mutable nested data structure with functions help
Message-ID: <3BA269E87A554B7D96EDCF91A7BEDBED@gmail.com>

Hello,

I have a problem with creating a mutable nested data structure when combined with functions.
I?m lost in all those &muts, boxes and lifetimes. :-)

I would like to crawl a directory looking for subdirectories and in those subdirectories find all images.
So I started with a vector for holding those subdirectories.
Then I created a struct to hold a directory path and a vector of images.
Also a struct for the image itself.

It all works in one function body but not when refactored into functions.
I understand that when a variable is sent as an argument, the ownership is moved so it cannot be used after the function call.
So I sent &-references instead but then it would yell at me that borrowed things are not mutable.
So I &mut-ed it all and it would yell that lifetimes are not defined.
So I tried to define lifetimes but then it would say that things do not live long enough. This is where I stopped.
I also tried the box-way but that yells about immutable dereference. I?m not even sure I have those boxes right.

This is the code:
(Also available here https://gist.github.com/ollie/9c81d2a368bf7bf0831a, there is also a Ruby version not listed here.)


With references and lifetimes:

#[deriving(Show)]
struct Image {
    filename: String,
}

#[deriving(Show)]
struct Section<'a> {
    path:   String,
    images: &'a mut Vec,
}

impl Image {
    fn new(filename: &str) -> Image {
        Image {
            filename: String::from_str(filename),
        }
    }
}

impl<'a> Section<'a> {
    fn new(path: &str) -> Section {
        Section {
            path:   String::from_str(path),
            images: &mut Vec::new(),
        }
    }

    fn add_image(&mut self, image: Image) {
        self.images.push(image);
    }
}

fn read_directories(sections: &mut Vec<&mut Section>) {
    let dirs = ["./dir-a", "./dir-b"];

    for dir in dirs.iter() {
        let mut section = &mut Section::new(*dir);
        read_images(section);
        sections.push(section);
    }
}

fn read_images(section: &mut Section) {
    let files = ["./image-1.png", "./image-2.png"];

    for file in files.iter() {
        section.add_image(Image::new(*file));
    }
}

fn main() {
    let mut sections = Vec::new();
    read_directories(&mut sections);
    println!("{}", sections);
}



With boxes:

#[deriving(Show)]
struct Image {
    filename: String,
}

#[deriving(Show)]
struct Section {
    path:   String,
    images: Box>,
}

impl Image {
    fn new(filename: &str) -> Image {
        Image {
            filename: String::from_str(filename),
        }
    }
}

impl Section {
    fn new(path: &str) -> Section {
        Section {
            path:   String::from_str(path),
            images: box Vec::new(),
        }
    }

    fn add_image(&mut self, image: Image) {
        self.images.push(image);
    }
}

fn read_directories(sections: Box>>) {
    let dirs = ["./dir-a", "./dir-b"];

    for dir in dirs.iter() {
        let mut section = box Section::new(*dir);
        read_images(section);
        sections.push(section);
    }
}

fn read_images(section: Box
) { let files = ["./image-1.png", "./image-2.png"]; for file in files.iter() { section.add_image(Image::new(*file)); } } fn main() { let mut sections = box Vec::new(); read_directories(sections); println!("{}", sections); } All in one, no referenes and lifetimes: #[deriving(Show)] struct Image { filename: String, } #[deriving(Show)] struct Section { path: String, images: Vec, } impl Image { fn new(filename: &str) -> Image { Image { filename: String::from_str(filename), } } } impl Section { fn new(path: &str) -> Section { Section { path: String::from_str(path), images: Vec::new(), } } fn add_image(&mut self, image: Image) { self.images.push(image); } } fn main() { let mut sections = Vec::new(); let dirs = ["./dir-a", "./dir-b"]; for dir in dirs.iter() { let mut section = Section::new(*dir); let files = ["./image-1.png", "./image-2.png"]; for file in files.iter() { section.add_image(Image::new(*file)); } sections.push(section); } println!("{}", sections); // [ // Section { // path: ./dir-a, // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] // }, // Section { // path: ./dir-b, // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] // } // ] } I?ve read the tutorial, the rust-by-example site but it still feels alien to me. :-/ Thank you, Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Wed Sep 10 08:17:01 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Wed, 10 Sep 2014 19:17:01 +0400 Subject: [rust-dev] Mutable nested data structure with functions help In-Reply-To: <3BA269E87A554B7D96EDCF91A7BEDBED@gmail.com> References: <3BA269E87A554B7D96EDCF91A7BEDBED@gmail.com> Message-ID: Hi, Ollie, The working piece of code code: http://is.gd/dX7hzB First of all, try to go through the official Rust guide [1]. It is mostly finished and it is *really* good. In particular, it explains what ownership is and how it should be managed. I?ve took your `example_box.rs` as a base and modified it as follows: 1. I?ve removed `Box`es everywhere. You shouldn?t use them unless you really know why you need them. You can read more on boxes and other kinds of pointers here [2]. You will need to do it anyway if you go through the guide [1] anyway. 2. I?ve made your functions to accept &mut Vec
and &mut Section. This is exactly what ownership is about: these functions should not take ownership of their arguments, but they need to modify them, so &mut is the solution. Apart from that your code is mostly fine. Hope that helps! [1]: http://doc.rust-lang.org/guide.html [2]: http://doc.rust-lang.org/guide-pointers.html On 10 ????. 2014 ?., at 18:05, Old?ich Vete?n?k wrote: > Hello, > > I have a problem with creating a mutable nested data structure when combined with functions. > I?m lost in all those &muts, boxes and lifetimes. :-) > > I would like to crawl a directory looking for subdirectories and in those subdirectories find all images. > So I started with a vector for holding those subdirectories. > Then I created a struct to hold a directory path and a vector of images. > Also a struct for the image itself. > > It all works in one function body but not when refactored into functions. > I understand that when a variable is sent as an argument, the ownership is moved so it cannot be used after the function call. > So I sent &-references instead but then it would yell at me that borrowed things are not mutable. > So I &mut-ed it all and it would yell that lifetimes are not defined. > So I tried to define lifetimes but then it would say that things do not live long enough. This is where I stopped. > I also tried the box-way but that yells about immutable dereference. I?m not even sure I have those boxes right. > > This is the code: > (Also available here https://gist.github.com/ollie/9c81d2a368bf7bf0831a, there is also a Ruby version not listed here.) > > > With references and lifetimes: > > #[deriving(Show)] > struct Image { > filename: String, > } > > #[deriving(Show)] > struct Section<'a> { > path: String, > images: &'a mut Vec, > } > > impl Image { > fn new(filename: &str) -> Image { > Image { > filename: String::from_str(filename), > } > } > } > > impl<'a> Section<'a> { > fn new(path: &str) -> Section { > Section { > path: String::from_str(path), > images: &mut Vec::new(), > } > } > > fn add_image(&mut self, image: Image) { > self.images.push(image); > } > } > > fn read_directories(sections: &mut Vec<&mut Section>) { > let dirs = ["./dir-a", "./dir-b"]; > > for dir in dirs.iter() { > let mut section = &mut Section::new(*dir); > read_images(section); > sections.push(section); > } > } > > fn read_images(section: &mut Section) { > let files = ["./image-1.png", "./image-2.png"]; > > for file in files.iter() { > section.add_image(Image::new(*file)); > } > } > > fn main() { > let mut sections = Vec::new(); > read_directories(&mut sections); > println!("{}", sections); > } > > > With boxes: > > #[deriving(Show)] > struct Image { > filename: String, > } > > #[deriving(Show)] > struct Section { > path: String, > images: Box>, > } > > impl Image { > fn new(filename: &str) -> Image { > Image { > filename: String::from_str(filename), > } > } > } > > impl Section { > fn new(path: &str) -> Section { > Section { > path: String::from_str(path), > images: box Vec::new(), > } > } > > fn add_image(&mut self, image: Image) { > self.images.push(image); > } > } > > fn read_directories(sections: Box>>) { > let dirs = ["./dir-a", "./dir-b"]; > > for dir in dirs.iter() { > let mut section = box Section::new(*dir); > read_images(section); > sections.push(section); > } > } > > fn read_images(section: Box
) { > let files = ["./image-1.png", "./image-2.png"]; > > for file in files.iter() { > section.add_image(Image::new(*file)); > } > } > > fn main() { > let mut sections = box Vec::new(); > read_directories(sections); > println!("{}", sections); > } > > > All in one, no referenes and lifetimes: > > #[deriving(Show)] > struct Image { > filename: String, > } > > #[deriving(Show)] > struct Section { > path: String, > images: Vec, > } > > impl Image { > fn new(filename: &str) -> Image { > Image { > filename: String::from_str(filename), > } > } > } > > impl Section { > fn new(path: &str) -> Section { > Section { > path: String::from_str(path), > images: Vec::new(), > } > } > > fn add_image(&mut self, image: Image) { > self.images.push(image); > } > } > > fn main() { > let mut sections = Vec::new(); > let dirs = ["./dir-a", "./dir-b"]; > > for dir in dirs.iter() { > let mut section = Section::new(*dir); > let files = ["./image-1.png", "./image-2.png"]; > > for file in files.iter() { > section.add_image(Image::new(*file)); > } > > sections.push(section); > } > > println!("{}", sections); > > // [ > // Section { > // path: ./dir-a, > // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] > // }, > // Section { > // path: ./dir-b, > // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] > // } > // ] > } > > I?ve read the tutorial, the rust-by-example site but it still feels alien to me. :-/ > > Thank you, > Ollie > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From davidb at davidb.org Wed Sep 10 08:20:25 2014 From: davidb at davidb.org (David Brown) Date: Wed, 10 Sep 2014 08:20:25 -0700 Subject: [rust-dev] Bug in lifetime inference? In-Reply-To: References: <20140910002213.GA28123@davidb.org> Message-ID: <20140910152025.GA30625@davidb.org> On Wed, Sep 10, 2014 at 06:26:47PM +0800, Kai Noda wrote: >Hi David, >I stopped worrying about the alleged bug I had reported after I saw >Git HEAD happily compiled it a few days later. >I found your case more interesting because I could compile your code >by changing >assert_eq!(stuff(), &[]); >to >let b = stuff() == &[]; `assert_eq` does the equality check in both directions. It seems that: let b = &[] == stuff(); still fails to compile: test.rs:6:20: 6:27 error: mismatched types: expected `&[, .. 0]`, found `&'static [uint]` (expected vector, found vector) test.rs:6 let b = &[] == stuff(); ^~~~~~~ test.rs:6:13: 6:27 error: cannot determine a type for this bounded type parameter: unconstrained type test.rs:6 let b = &[] == stuff(); which is basically the same error seen in the expansion of the `assert_eq`. It seems that the array literal cannot be used on the left side of a comparison. If anything, the "expected vector, found vector" isn't particularly helpful. David >Regards, >Kai > >2014-09-10 8:22 GMT+08:00 David Brown <[1]davidb at davidb.org>: > > I've seen something similar recently, with this code: > > ---------------------------------------------------------------------- > fn main() { > ? ?// Fails. > ? ?assert_eq!(stuff(), &[]); > > ? ?// Works > ? ?let tmp: &'static [uint] = &[]; > ? ?assert_eq!(stuff(), tmp); > } > > static simple: &'static [uint] = &[1, 2]; > > fn stuff() -> &'static [uint] { > ? ?simple > } > ---------------------------------------------------------------------- > > The failing code worked a week or so ago.? Similar issue in that I > can > make it work by giving an explicit type for the literal array. > > David > > On Sat, Aug 30, 2014 at 04:52:00PM +0800, Kai Noda wrote: > > Hi Rusters, > I'm very new to Rust, so I'd like you to check if this is really a > compiler bug or not. > fn main() { > ? ? let s1 = &[0i]; > ? ? { > ? ? ? ? let s2 = &[0i]; > ? ? ? ? let s3 = if true { s1 } else { s2 }; > ? ? }; > } > [1][2]http://is.gd/NCeGpl > > :5:19: 5:23 error: borrowed value does not live long enough > :5? ? ? ? ?let s2 = &[0i]; > ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~ > :2:11: 8:2 note: reference must be valid for the block at > 2:10... > :2 fn main() { > :3? ? ?let s1 = &[0i]; > :4? ? ?{ > :5? ? ? ? ?let s2 = &[0i]; > :6? ? ? ? ?let s3 = if true { s1 } else { s2 }; > :7? ? ?}; > ? ? ? ? ... > :4:5: 7:6 note: ...but borrowed value is only valid for the > block at 4:4 > :4? ? ?{ > :5? ? ? ? ?let s2 = &[0i]; > :6? ? ? ? ?let s3 = if true { s1 } else { s2 }; > :7? ? ?}; > error: aborting due to previous error > > Seems like s1 and s2 are inferred as &[int, ..1] and when I > manually > type them as &[int], it successfully compiles. > fn main() { > ? ? let s1: &[int] = &[0i]; > ? ? { > ? ? ? ? let s2: &[int] = &[0i]; > ? ? ? ? let s3 = if true { s1 } else { s2 }; > ? ? }; > } > Putting s1 and s2 into a single block also satisfies the compiler. > fn main() { > ? ? let s1 = &[0i]; > ? ? let s2 = &[0i]; > ? ? let s3 = if true { s1 } else { s2 }; > } > I came from C++ and I think the way I take reference of a fixed > vector > literal is correct. > [2][3]http://doc.rust-lang.org/rust.html#pointer-types > I was originally trying to fix this line which doesn't compile > with > the nightly build of Rust: > [3][4]https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55 > No similar issue is filed here: > [4][5]https://github.com/rust-lang/rust/labels/A-lifetimes > Best regards, > Kai > ??? ? <[5][6]nodakai at gmail.com> > > References > > ? Visible links > ? 1. [7]http://is.gd/NCeGpl > ? 2. [8]http://doc.rust-lang.org/rust.html#pointer-types > ? 3. > [9]https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55 > ? 4. [10]https://github.com/rust-lang/rust/labels/A-lifetimes > ? 5. mailto:[11]nodakai at gmail.com > > _______________________________________________ > Rust-dev mailing list > [12]Rust-dev at mozilla.org > [13]https://mail.mozilla.org/listinfo/rust-dev > >References > > Visible links > 1. mailto:davidb at davidb.org > 2. http://is.gd/NCeGpl > 3. http://doc.rust-lang.org/rust.html#pointer-types > 4. https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55 > 5. https://github.com/rust-lang/rust/labels/A-lifetimes > 6. mailto:nodakai at gmail.com > 7. http://is.gd/NCeGpl > 8. http://doc.rust-lang.org/rust.html#pointer-types > 9. https://github.com/servo/rust-url/blob/master/src/form_urlencoded.rs#L55 > 10. https://github.com/rust-lang/rust/labels/A-lifetimes > 11. mailto:nodakai at gmail.com > 12. mailto:Rust-dev at mozilla.org > 13. https://mail.mozilla.org/listinfo/rust-dev From oldrich.vetesnik at gmail.com Thu Sep 11 00:25:50 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Thu, 11 Sep 2014 09:25:50 +0200 Subject: [rust-dev] Mutable nested data structure with functions help In-Reply-To: References: <3BA269E87A554B7D96EDCF91A7BEDBED@gmail.com> Message-ID: Hi Vladimir, thanks for the pointers guide, I forgot about it. I remember reading about it in the ?normal? guide but didn?t really understand it. Hopefully if I read it a few times, it will sink in. :-) Ollie On Wednesday 10 September 2014 at 17:17, Vladimir Matveev wrote: > Hi, Ollie, > > The working piece of code code: http://is.gd/dX7hzB > > First of all, try to go through the official Rust guide [1]. It is mostly finished and it is *really* good. In particular, it explains what ownership is and how it should be managed. > > I?ve took your `example_box.rs` as a base and modified it as follows: > 1. I?ve removed `Box`es everywhere. You shouldn?t use them unless you really know why you need them. You can read more on boxes and other kinds of pointers here [2]. You will need to do it anyway if you go through the guide [1] anyway. > 2. I?ve made your functions to accept &mut Vec
and &mut Section. This is exactly what ownership is about: these functions should not take ownership of their arguments, but they need to modify them, so &mut is the solution. > > Apart from that your code is mostly fine. > > Hope that helps! > > [1]: http://doc.rust-lang.org/guide.html > [2]: http://doc.rust-lang.org/guide-pointers.html > > > On 10 ????. 2014 ?., at 18:05, Old?ich Vete?n?k wrote: > > > Hello, > > > > I have a problem with creating a mutable nested data structure when combined with functions. > > I?m lost in all those &muts, boxes and lifetimes. :-) > > > > I would like to crawl a directory looking for subdirectories and in those subdirectories find all images. > > So I started with a vector for holding those subdirectories. > > Then I created a struct to hold a directory path and a vector of images. > > Also a struct for the image itself. > > > > It all works in one function body but not when refactored into functions. > > I understand that when a variable is sent as an argument, the ownership is moved so it cannot be used after the function call. > > So I sent &-references instead but then it would yell at me that borrowed things are not mutable. > > So I &mut-ed it all and it would yell that lifetimes are not defined. > > So I tried to define lifetimes but then it would say that things do not live long enough. This is where I stopped. > > I also tried the box-way but that yells about immutable dereference. I?m not even sure I have those boxes right. > > > > This is the code: > > (Also available here https://gist.github.com/ollie/9c81d2a368bf7bf0831a, there is also a Ruby version not listed here.) > > > > > > With references and lifetimes: > > > > #[deriving(Show)] > > struct Image { > > filename: String, > > } > > > > #[deriving(Show)] > > struct Section<'a> { > > path: String, > > images: &'a mut Vec, > > } > > > > impl Image { > > fn new(filename: &str) -> Image { > > Image { > > filename: String::from_str(filename), > > } > > } > > } > > > > impl<'a> Section<'a> { > > fn new(path: &str) -> Section { > > Section { > > path: String::from_str(path), > > images: &mut Vec::new(), > > } > > } > > > > fn add_image(&mut self, image: Image) { > > self.images.push(image); > > } > > } > > > > fn read_directories(sections: &mut Vec<&mut Section>) { > > let dirs = ["./dir-a", "./dir-b"]; > > > > for dir in dirs.iter() { > > let mut section = &mut Section::new(*dir); > > read_images(section); > > sections.push(section); > > } > > } > > > > fn read_images(section: &mut Section) { > > let files = ["./image-1.png", "./image-2.png"]; > > > > for file in files.iter() { > > section.add_image(Image::new(*file)); > > } > > } > > > > fn main() { > > let mut sections = Vec::new(); > > read_directories(&mut sections); > > println!("{}", sections); > > } > > > > > > With boxes: > > > > #[deriving(Show)] > > struct Image { > > filename: String, > > } > > > > #[deriving(Show)] > > struct Section { > > path: String, > > images: Box>, > > } > > > > impl Image { > > fn new(filename: &str) -> Image { > > Image { > > filename: String::from_str(filename), > > } > > } > > } > > > > impl Section { > > fn new(path: &str) -> Section { > > Section { > > path: String::from_str(path), > > images: box Vec::new(), > > } > > } > > > > fn add_image(&mut self, image: Image) { > > self.images.push(image); > > } > > } > > > > fn read_directories(sections: Box>>) { > > let dirs = ["./dir-a", "./dir-b"]; > > > > for dir in dirs.iter() { > > let mut section = box Section::new(*dir); > > read_images(section); > > sections.push(section); > > } > > } > > > > fn read_images(section: Box
) { > > let files = ["./image-1.png", "./image-2.png"]; > > > > for file in files.iter() { > > section.add_image(Image::new(*file)); > > } > > } > > > > fn main() { > > let mut sections = box Vec::new(); > > read_directories(sections); > > println!("{}", sections); > > } > > > > > > All in one, no referenes and lifetimes: > > > > #[deriving(Show)] > > struct Image { > > filename: String, > > } > > > > #[deriving(Show)] > > struct Section { > > path: String, > > images: Vec, > > } > > > > impl Image { > > fn new(filename: &str) -> Image { > > Image { > > filename: String::from_str(filename), > > } > > } > > } > > > > impl Section { > > fn new(path: &str) -> Section { > > Section { > > path: String::from_str(path), > > images: Vec::new(), > > } > > } > > > > fn add_image(&mut self, image: Image) { > > self.images.push(image); > > } > > } > > > > fn main() { > > let mut sections = Vec::new(); > > let dirs = ["./dir-a", "./dir-b"]; > > > > for dir in dirs.iter() { > > let mut section = Section::new(*dir); > > let files = ["./image-1.png", "./image-2.png"]; > > > > for file in files.iter() { > > section.add_image(Image::new(*file)); > > } > > > > sections.push(section); > > } > > > > println!("{}", sections); > > > > // [ > > // Section { > > // path: ./dir-a, > > // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] > > // }, > > // Section { > > // path: ./dir-b, > > // images: [Image { filename: ./image-1.png }, Image { filename: ./image-2.png }] > > // } > > // ] > > } > > > > I?ve read the tutorial, the rust-by-example site but it still feels alien to me. :-/ > > > > Thank you, > > Ollie > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org) > > https://mail.mozilla.org/listinfo/rust-dev > > > > From errordeveloper at gmail.com Thu Sep 11 04:52:20 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Thu, 11 Sep 2014 12:52:20 +0100 Subject: [rust-dev] New Directions in Operating Systems, A one day conference, 25 November, London Message-ID: Hi List, As I know that some of you are probably going to be quite interested in this, here is a conference coming up in November. http://operatingsystems.io/ They are still open for talk submissions. Cheers, -- Ilya From allen.welkie at gmail.com Thu Sep 11 05:56:04 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Thu, 11 Sep 2014 08:56:04 -0400 Subject: [rust-dev] Rust Radio - an SDR framework Message-ID: If anyone is interested in software defined radios, I'm starting a project called Rust Radio (very similar to GNU Radio). Take a look at https://github.com/awelkie/rustradio. It's still pretty new, but critiques and contributions are always welcome! -------------- next part -------------- An HTML attachment was scrubbed... URL: From eg1290 at gmail.com Thu Sep 11 07:32:26 2014 From: eg1290 at gmail.com (Evan G) Date: Thu, 11 Sep 2014 10:32:26 -0400 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: This is so cool! SDR are awesome. On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie wrote: > If anyone is interested in software defined radios, I'm starting a project > called Rust Radio (very similar to GNU Radio). Take a look at > https://github.com/awelkie/rustradio. It's still pretty new, but > critiques and contributions are always welcome! > > _______________________________________________ > 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 thadguidry at gmail.com Thu Sep 11 07:46:32 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 11 Sep 2014 09:46:32 -0500 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: SDR is an EXCELLENT software design challenge to flex Rust's muscles (and expose latent bugs) ! On Thu, Sep 11, 2014 at 9:32 AM, Evan G wrote: > This is so cool! SDR are awesome. > > On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie > wrote: > >> If anyone is interested in software defined radios, I'm starting a >> project called Rust Radio (very similar to GNU Radio). Take a look at >> https://github.com/awelkie/rustradio. It's still pretty new, but >> critiques and contributions are always welcome! >> >> _______________________________________________ >> 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 > > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at taricorp.net Thu Sep 11 08:45:47 2014 From: peter at taricorp.net (Peter Marheine) Date: Thu, 11 Sep 2014 09:45:47 -0600 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: Your design bears significant similarity to my own work on an audio streaming framework [1], which seems a bit more mature despite still being the subject of significant experimentation on my part. It looks like your elements do a lot of copying, which could have a significant negative effect on performance. I approached the same problem by having elements (Source in audiostream) return references to mutable buffers (which may not be possible with Iterator). This should allow elimination of most copies in real-world applications, though at the moment my design calls for independent tasks for each linear pipeline segment while will require a copy for each task. I also found your Interleave block interesting, since I've been working on squeezing performance out of my own Interleave block (I expect most pipelines with have at least one of both Interleave and DeInterleave, so vector optimizations are a good goal to reach for). I'm pleased with the performance so far (10.5 GB/s on the ~3 GHz Core i5 machine I'm testing on), but it might be useful to break that into its own library so others can benefit from the vector optimizations. Your connect! macro is nice; I've been planning to do something similar (possibly define a whole DSL for pipeline specification which can be used as a macro), but you beat me to it in this case. :) Anyway, it looks like there are things we can learn from each other here, and I'll be watching your project- might be a good excuse to get some use out of my HackRF and contribute some components back. [1] https://bitbucket.org/tari/audiostream.rs/ On Thu, Sep 11, 2014 at 6:56 AM, Allen Welkie wrote: > If anyone is interested in software defined radios, I'm starting a project > called Rust Radio (very similar to GNU Radio). Take a look at > https://github.com/awelkie/rustradio. It's still pretty new, but critiques > and contributions are always welcome! > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Peter Marheine Don't Panic From allen.welkie at gmail.com Thu Sep 11 10:07:56 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Thu, 11 Sep 2014 13:07:56 -0400 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: Yeah, I set up the block to work on iterators over objects instead of references because it made a lot of things simpler. But you're right that it causes a lot of unnecessary copying. I think its time to revisit that decision. I'll play around with using iterators over references instead of objects. Thanks! On Sep 11, 2014 11:46 AM, "Peter Marheine" wrote: > Your design bears significant similarity to my own work on an audio > streaming framework [1], which seems a bit more mature despite still > being the subject of significant experimentation on my part. > > It looks like your elements do a lot of copying, which could have a > significant negative effect on performance. I approached the same > problem by having elements (Source in audiostream) return references > to mutable buffers (which may not be possible with Iterator). This > should allow elimination of most copies in real-world applications, > though at the moment my design calls for independent tasks for each > linear pipeline segment while will require a copy for each task. > > I also found your Interleave block interesting, since I've been > working on squeezing performance out of my own Interleave block (I > expect most pipelines with have at least one of both Interleave and > DeInterleave, so vector optimizations are a good goal to reach for). > I'm pleased with the performance so far (10.5 GB/s on the ~3 GHz Core > i5 machine I'm testing on), but it might be useful to break that into > its own library so others can benefit from the vector optimizations. > > Your connect! macro is nice; I've been planning to do something > similar (possibly define a whole DSL for pipeline specification which > can be used as a macro), but you beat me to it in this case. :) > > Anyway, it looks like there are things we can learn from each other > here, and I'll be watching your project- might be a good excuse to get > some use out of my HackRF and contribute some components back. > > [1] https://bitbucket.org/tari/audiostream.rs/ > > On Thu, Sep 11, 2014 at 6:56 AM, Allen Welkie > wrote: > > If anyone is interested in software defined radios, I'm starting a > project > > called Rust Radio (very similar to GNU Radio). Take a look at > > https://github.com/awelkie/rustradio. It's still pretty new, but > critiques > > and contributions are always welcome! > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > Peter Marheine > Don't Panic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From explodingmind at gmail.com Thu Sep 11 10:28:39 2014 From: explodingmind at gmail.com (Ian Daniher) Date: Thu, 11 Sep 2014 13:28:39 -0400 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: Very cool. I did some work on discrete time DSP with SDR applications. The library's at https://github.com/ade-ma/LibRedio. Best, Ian On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie wrote: > If anyone is interested in software defined radios, I'm starting a project > called Rust Radio (very similar to GNU Radio). Take a look at > https://github.com/awelkie/rustradio. It's still pretty new, but > critiques and contributions are always welcome! > > _______________________________________________ > 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 allen.welkie at gmail.com Thu Sep 11 10:45:13 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Thu, 11 Sep 2014 13:45:13 -0400 Subject: [rust-dev] Rust Radio - an SDR framework In-Reply-To: References: Message-ID: Looks like there's a lot of good stuff in there. I especially like the rtlsdr bindings: I'll be able to get live data sooner than I thought! On Sep 11, 2014 1:28 PM, "Ian Daniher" wrote: > Very cool. I did some work on discrete time DSP with SDR applications. The > library's at https://github.com/ade-ma/LibRedio. > > Best, > Ian > > On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie > wrote: > >> If anyone is interested in software defined radios, I'm starting a >> project called Rust Radio (very similar to GNU Radio). Take a look at >> https://github.com/awelkie/rustradio. It's still pretty new, but >> critiques and contributions are always welcome! >> >> _______________________________________________ >> 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 christophe.pedretti at gmail.com Thu Sep 11 12:26:16 2014 From: christophe.pedretti at gmail.com (Christophe Pedretti) Date: Thu, 11 Sep 2014 21:26:16 +0200 Subject: [rust-dev] reference has a longer lifetime than the data it references Message-ID: Hello, with 0.11.0, this code was ok pub struct Cursor<'a, 'b> { > pStmt : &'b Statement<'a>, > error : bool > } now, with the nighly, i receive a sql\connection.rs:50:1: 53:2 error: in type `&'b sql::connection::Statement<'a>`, reference has a longer lifetime than the data it references sql\connection.rs:50 pub struct Cursor<'a, 'b> { sql\connection.rs:51 pStmt : &'b Statement<'a>, sql\connection.rs:52 error : bool sql\connection.rs:53 } sql\connection.rs:50:1: 53:2 note: the pointer is valid for the lifetime 'b as defined on the struct at 50:0 sql\connection.rs:50 pub struct Cursor<'a, 'b> { sql\connection.rs:51 pStmt : &'b Statement<'a>, sql\connection.rs:52 error : bool sql\connection.rs:53 } sql\connection.rs:50:1: 53:2 note: but the referenced data is only valid for the lifetime 'a as defined on the struct at 50:0 sql\connection.rs:50 pub struct Cursor<'a, 'b> { sql\connection.rs:51 pStmt : &'b Statement<'a>, sql\connection.rs:52 error : bool sql\connection.rs:53 } error: aborting due to previous error why this change ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thesaint1987 at googlemail.com Thu Sep 11 12:35:16 2014 From: thesaint1987 at googlemail.com (Chris Skittles) Date: Thu, 11 Sep 2014 21:35:16 +0200 Subject: [rust-dev] reference has a longer lifetime than the data it references In-Reply-To: References: Message-ID: Probably because its wrong. It was likely a compiler bug that got fixed. The compiler says pretty clearly what the issue is. What if A has a shorter lifetime than B? Then you are basically holding a reference to data that has been disposed, which is what "can't" happen in rust. On Thu, Sep 11, 2014 at 9:26 PM, Christophe Pedretti wrote: > Hello, > > with 0.11.0, this code was ok > >> pub struct Cursor<'a, 'b> { >> pStmt : &'b Statement<'a>, >> error : bool >> } > > > now, with the nighly, i receive a > > sql\connection.rs:50:1: 53:2 error: in type `&'b > sql::connection::Statement<'a>`, reference has a longer lifetime than the > data it references > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > sql\connection.rs:50:1: 53:2 note: the pointer is valid for the lifetime 'b > as defined on the struct at 50:0 > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > sql\connection.rs:50:1: 53:2 note: but the referenced data is only valid for > the lifetime 'a as defined on the struct at 50:0 > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > error: aborting due to previous error > > why this change ? > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From bsteinbr at gmail.com Thu Sep 11 12:44:41 2014 From: bsteinbr at gmail.com (=?iso-8859-1?Q?Bj=F6rn?= Steinbrink) Date: Thu, 11 Sep 2014 21:44:41 +0200 Subject: [rust-dev] reference has a longer lifetime than the data it references In-Reply-To: References: Message-ID: <20140911194441.GA5662@atjola.homenet> On 2014.09.11 21:26:16 +0200, Christophe Pedretti wrote: > Hello, > > with 0.11.0, this code was ok > > pub struct Cursor<'a, 'b> { > > pStmt : &'b Statement<'a>, > > error : bool > > } You need a bound on the lifetime now, to guarantee that the reference(s) with lifetime 'a contained in Statement<'a> are valid for at least as long as the reference with lifetime 'b. So the struct should now look like this: pub struct Cursor<'a, 'b: 'a> { pStmt: &'a Statement<'b>, error: bool, } This is correctly handled now that RFC 49 [1] has been implemented. The corresponding PR is #16453 [2] and it lists the relevant breaking changes. Bj?rn [1] https://github.com/rust-lang/rfcs/pull/192 [2] https://github.com/rust-lang/rust/pull/16453 > > > now, with the nighly, i receive a > > sql\connection.rs:50:1: 53:2 error: in type `&'b > sql::connection::Statement<'a>`, reference has a longer lifetime than the > data it references > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > sql\connection.rs:50:1: 53:2 note: the pointer is valid for the lifetime 'b > as defined on the struct at 50:0 > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > sql\connection.rs:50:1: 53:2 note: but the referenced data is only valid > for the lifetime 'a as defined on the struct at 50:0 > sql\connection.rs:50 pub struct Cursor<'a, 'b> { > sql\connection.rs:51 pStmt : &'b Statement<'a>, > sql\connection.rs:52 error : bool > sql\connection.rs:53 } > error: aborting due to previous error > > why this change ? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From oldrich.vetesnik at gmail.com Fri Sep 12 04:35:35 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Fri, 12 Sep 2014 13:35:35 +0200 Subject: [rust-dev] String capitalization Message-ID: <660308CAECEF4F2AA231931848BF4BD0@gmail.com> Hello, this is probably going to sound silly, but can this be written better? I?d like to turn ?hello-there? into ?Hello There?. I was thinking about something along the lines of split -> map -> capitalize -> join but the capitalization seems kind of awful to me. use std::char; fn name_from_file(file: String) -> String { let mut words: Vec<&str> = file.as_slice().split('-').collect(); let mut cap_words = Vec::new(); for word in words.mut_iter() { let first = char::to_uppercase(word.char_at(0)).to_string(); let rest = word.slice_chars(1, word.len()); let cap_word = first.append(rest); cap_words.push(cap_word); } cap_words.connect(" ") } fn main() { let hypenated_string = "hello-there".to_string(); let capitalized_string = name_from_file(hypenated_string); println!("{}", capitalized_string); } Thanks, Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Fri Sep 12 05:29:41 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Fri, 12 Sep 2014 16:29:41 +0400 Subject: [rust-dev] String capitalization In-Reply-To: <660308CAECEF4F2AA231931848BF4BD0@gmail.com> References: <660308CAECEF4F2AA231931848BF4BD0@gmail.com> Message-ID: <7832E128-476F-47D7-AA1F-A7C48323ED32@gmail.com> Hi, Ollie, This variant is terser, but it could be even more readable if there were some kind of connect() for iterators. It surprised me that there is no such thing in Rust iterators. It would be possible to use some kind of interleave() for iterators for the same purpose, but there is no such thing as well. Hence I had to use fold() and then pop_char() which is rather nasty as it breaks method chain. On the other hand, this variant performs less allocations than your original version because the resulting string is allocated in advance. use std::char; fn name_from_file(file: String) -> String { let mut r = file.as_slice().split('-') .map(|w| char::to_uppercase(w.char_at(0)).to_string().append(w.slice_chars(1, w.len()))) .fold( String::with_capacity(file.len()+1), |r, w| r.append(w.as_slice()).append(" ") ); r.pop_char(); r } fn main() { let hypenated_string = "hello-there".to_string(); let capitalized_string = name_from_file(hypenated_string); println!("{}", capitalized_string); } See it in action here: http://is.gd/UKKB96 BTW, I suggest you to use Stackoverflow [1] (preferred) or Reddit [2] to ask questions like this. The active community there is much larger than here, so you can get an answer quicker. [1]: http://stackoverflow.com/questions/tagged/rust [2]: http://www.reddit.com/r/rust/ On 12 ????. 2014 ?., at 15:35, Old?ich Vete?n?k wrote: > Hello, > > this is probably going to sound silly, but can this be written better? > I?d like to turn ?hello-there? into ?Hello There?. > I was thinking about something along the lines of split -> map -> capitalize -> join but the capitalization seems kind of awful to me. > > use std::char; > > fn name_from_file(file: String) -> String { > let mut words: Vec<&str> = file.as_slice().split('-').collect(); > let mut cap_words = Vec::new(); > > for word in words.mut_iter() { > let first = char::to_uppercase(word.char_at(0)).to_string(); > let rest = word.slice_chars(1, word.len()); > > let cap_word = first.append(rest); > cap_words.push(cap_word); > } > > cap_words.connect(" ") > } > > fn main() { > let hypenated_string = "hello-there".to_string(); > let capitalized_string = name_from_file(hypenated_string); > println!("{}", capitalized_string); > } > > > Thanks, > Ollie > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From acharles at outlook.com Fri Sep 12 06:26:17 2014 From: acharles at outlook.com (Ahmed Charles) Date: Fri, 12 Sep 2014 06:26:17 -0700 Subject: [rust-dev] String capitalization In-Reply-To: <7832E128-476F-47D7-AA1F-A7C48323ED32@gmail.com> References: <660308CAECEF4F2AA231931848BF4BD0@gmail.com>, <7832E128-476F-47D7-AA1F-A7C48323ED32@gmail.com> Message-ID: > From: dpx.infinity at gmail.com > Date: Fri, 12 Sep 2014 16:29:41 +0400 > To: oldrich.vetesnik at gmail.com > CC: rust-dev at mozilla.org > Subject: Re: [rust-dev] String capitalization > > Hi, Ollie, > > This variant is terser, but it could be even more readable if there were some kind of connect() for iterators. It surprised me that there is no such thing in Rust iterators. It would be possible to use some kind of interleave() for iterators for the same purpose, but there is no such thing as well. Hence I had to use fold() and then pop_char() which is rather nasty as it breaks method chain. > > On the other hand, this variant performs less allocations than your original version because the resulting string is allocated in advance. This is what I tried to do as well. I think you can just check if r is empty and only append a space to it if it's not before appending w. Note, I don't think either one is very readable. > use std::char; > > fn name_from_file(file: String) -> String { > let mut r = file.as_slice().split('-') > .map(|w| char::to_uppercase(w.char_at(0)).to_string().append(w.slice_chars(1, w.len()))) > .fold( > String::with_capacity(file.len()+1), > |r, w| r.append(w.as_slice()).append(" ") > ); > r.pop_char(); > r > } > > fn main() { > let hypenated_string = "hello-there".to_string(); > let capitalized_string = name_from_file(hypenated_string); > println!("{}", capitalized_string); > } > > See it in action here: http://is.gd/UKKB96 > > BTW, I suggest you to use Stackoverflow [1] (preferred) or Reddit [2] to ask questions like this. The active community there is much larger than here, so you can get an answer quicker. > > [1]: http://stackoverflow.com/questions/tagged/rust > [2]: http://www.reddit.com/r/rust/ > > > On 12 ????. 2014 ?., at 15:35, Old?ich Vete?n?k wrote: > > > Hello, > > > > this is probably going to sound silly, but can this be written better? > > I?d like to turn ?hello-there? into ?Hello There?. > > I was thinking about something along the lines of split -> map -> capitalize -> join but the capitalization seems kind of awful to me. > > > > use std::char; > > > > fn name_from_file(file: String) -> String { > > let mut words: Vec<&str> = file.as_slice().split('-').collect(); > > let mut cap_words = Vec::new(); > > > > for word in words.mut_iter() { > > let first = char::to_uppercase(word.char_at(0)).to_string(); > > let rest = word.slice_chars(1, word.len()); > > > > let cap_word = first.append(rest); > > cap_words.push(cap_word); > > } > > > > cap_words.connect(" ") > > } > > > > fn main() { > > let hypenated_string = "hello-there".to_string(); > > let capitalized_string = name_from_file(hypenated_string); > > println!("{}", capitalized_string); > > } > > > > > > Thanks, > > Ollie > > _______________________________________________ > > 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 oldrich.vetesnik at gmail.com Fri Sep 12 11:42:20 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Fri, 12 Sep 2014 20:42:20 +0200 Subject: [rust-dev] String capitalization In-Reply-To: <7832E128-476F-47D7-AA1F-A7C48323ED32@gmail.com> References: <660308CAECEF4F2AA231931848BF4BD0@gmail.com> <7832E128-476F-47D7-AA1F-A7C48323ED32@gmail.com> Message-ID: <4220A2A2-0189-4365-8172-722D32CE62E7@gmail.com> Hehe, pretty ugly too :-), but thanks. 12. 9. 2014 v 14:29, Vladimir Matveev : > Hi, Ollie, > > This variant is terser, but it could be even more readable if there were some kind of connect() for iterators. It surprised me that there is no such thing in Rust iterators. It would be possible to use some kind of interleave() for iterators for the same purpose, but there is no such thing as well. Hence I had to use fold() and then pop_char() which is rather nasty as it breaks method chain. > > On the other hand, this variant performs less allocations than your original version because the resulting string is allocated in advance. > > use std::char; > > fn name_from_file(file: String) -> String { > let mut r = file.as_slice().split('-') > .map(|w| char::to_uppercase(w.char_at(0)).to_string().append(w.slice_chars(1, w.len()))) > .fold( > String::with_capacity(file.len()+1), > |r, w| r.append(w.as_slice()).append(" ") > ); > r.pop_char(); > r > } > > fn main() { > let hypenated_string = "hello-there".to_string(); > let capitalized_string = name_from_file(hypenated_string); > println!("{}", capitalized_string); > } > > See it in action here: http://is.gd/UKKB96 > > BTW, I suggest you to use Stackoverflow [1] (preferred) or Reddit [2] to ask questions like this. The active community there is much larger than here, so you can get an answer quicker. > > [1]: http://stackoverflow.com/questions/tagged/rust > [2]: http://www.reddit.com/r/rust/ > > >> On 12 ????. 2014 ?., at 15:35, Old?ich Vete?n?k wrote: >> >> Hello, >> >> this is probably going to sound silly, but can this be written better? >> I?d like to turn ?hello-there? into ?Hello There?. >> I was thinking about something along the lines of split -> map -> capitalize -> join but the capitalization seems kind of awful to me. >> >> use std::char; >> >> fn name_from_file(file: String) -> String { >> let mut words: Vec<&str> = file.as_slice().split('-').collect(); >> let mut cap_words = Vec::new(); >> >> for word in words.mut_iter() { >> let first = char::to_uppercase(word.char_at(0)).to_string(); >> let rest = word.slice_chars(1, word.len()); >> >> let cap_word = first.append(rest); >> cap_words.push(cap_word); >> } >> >> cap_words.connect(" ") >> } >> >> fn main() { >> let hypenated_string = "hello-there".to_string(); >> let capitalized_string = name_from_file(hypenated_string); >> println!("{}", capitalized_string); >> } >> >> >> Thanks, >> Ollie >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > From pnovotnik at googlemail.com Sun Sep 14 23:34:36 2014 From: pnovotnik at googlemail.com (Petr Novotnik) Date: Mon, 15 Sep 2014 08:34:36 +0200 Subject: [rust-dev] Count of lines Message-ID: <5416887C.8090102@googlemail.com> Hello folks, recently I've been playing around with Rust and I'm really impressed. I like the language a lot! While writing a program to count the number of lines in a file, I realized it ran twice as slow as an older program I wrote in Go some time ago. After more experiments, I've figured out that Go's speed boost comes from an optimized function in its standard library utilizing SSE instructions, in particular the function bytes.IndexByte (http://golang.org/pkg/bytes/#IndexByte). I was wondering whether Rust would ever provide such optimized implementations as well as part of its standard library or whether it's up to developers to write their own versions of such functions. Maybe I just missed something, so I'm attaching the rust program: http://pastebin.com/NfFgMNGe And for the sake of completeness, here's the Go version I compared with: http://pastebin.com/4tiLsRpu Pete. From dbau.pp at gmail.com Mon Sep 15 01:49:59 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Mon, 15 Sep 2014 18:49:59 +1000 Subject: [rust-dev] Count of lines In-Reply-To: <5416887C.8090102@googlemail.com> References: <5416887C.8090102@googlemail.com> Message-ID: <5416A837.8050608@gmail.com> Are you compiling with optimisations? (Pass the -O flag to rustc.) For me, the Go and the optimised Rust are pretty similar, with the Go a few percent faster on a 1.3GB MP4 file, and the two languages indistinguishable on a 30MB XML file. Also, Rust prefers iterators to manual indexing since it avoids unnecessary bounds checks, that is, replace the inner loop with: for b in buf.slice_to(n).iter() { if *b == b'\n' { lines += 1; } } However, in this case, LLVM optimises that to a large chunk of SSE instructions https://gist.github.com/huonw/37cdd3dea3518abdb1c4 which seem to be reading only 2 bytes per memory access and only 4 bytes per tick of the loop (i.e. it's rather unoptimal); this means that the iterator version is only minutely faster than the naive range(0, n) loop in this case. I also wrote a 16-bytes-at-a-time SSE byte counter (it's unlikely to be optimal), which is about 20% faster than the Go on that same 1.3GB MP4 file and 3-4 times faster on the XML, so everyone has room for improvement. :) Code: https://gist.github.com/huonw/b6bfe4ad3623b6c37717 Btw, the Go is significantly slower when the file contains a lot of newlines, e.g. this file is 75% \n's yes 'foo' | head -100000000 > newlines.txt The Rust built with -O takes ~0.4s for me, and the Go takes 2.6s. The crossover point on my computer for very regular files like that is about 1 \n in every 30 bytes. Huon On 15/09/14 16:34, Petr Novotnik wrote: > Hello folks, > > recently I've been playing around with Rust and I'm really impressed. > I like the language a lot! > > While writing a program to count the number of lines in a file, I > realized it ran twice as slow as an older program I wrote in Go some > time ago. After more experiments, I've figured out that Go's speed > boost comes from an optimized function in its standard library > utilizing SSE instructions, in particular the function bytes.IndexByte > (http://golang.org/pkg/bytes/#IndexByte). > > I was wondering whether Rust would ever provide such optimized > implementations as well as part of its standard library or whether > it's up to developers to write their own versions of such functions. > > Maybe I just missed something, so I'm attaching the rust program: > > http://pastebin.com/NfFgMNGe > > And for the sake of completeness, here's the Go version I compared with: > > http://pastebin.com/4tiLsRpu > > Pete. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pnovotnik at googlemail.com Mon Sep 15 09:52:26 2014 From: pnovotnik at googlemail.com (Petr Novotnik) Date: Mon, 15 Sep 2014 18:52:26 +0200 Subject: [rust-dev] Count of lines In-Reply-To: <5416A837.8050608@gmail.com> References: <5416887C.8090102@googlemail.com> <5416A837.8050608@gmail.com> Message-ID: <5417194A.8050006@googlemail.com> Huon, your optimized version is blazing fast! :) I tried again all versions of the program on different kinds of input. It really seems that the performance difference I initially experienced is due to the character of my log file (100+ chars per line) - here, Go's optimized bytes.IndexByte (http://golang.org/src/pkg/runtime/asm_amd64.s#L1283) simply dominates the workload. Is there any chance for such specialized/optimized implementations to end up in the std. library? Many thanks so far, Pete. On 09/15/2014 10:49 AM, Huon Wilson wrote: > Are you compiling with optimisations? (Pass the -O flag to rustc.) For > me, the Go and the optimised Rust are pretty similar, with the Go a few > percent faster on a 1.3GB MP4 file, and the two languages > indistinguishable on a 30MB XML file. > > > Also, Rust prefers iterators to manual indexing since it avoids > unnecessary bounds checks, that is, replace the inner loop with: > > for b in buf.slice_to(n).iter() { > if *b == b'\n' { > lines += 1; > } > } > > However, in this case, LLVM optimises that to a large chunk of SSE > instructions https://gist.github.com/huonw/37cdd3dea3518abdb1c4 which > seem to be reading only 2 bytes per memory access and only 4 bytes per > tick of the loop (i.e. it's rather unoptimal); this means that the > iterator version is only minutely faster than the naive range(0, n) loop > in this case. > > I also wrote a 16-bytes-at-a-time SSE byte counter (it's unlikely to be > optimal), which is about 20% faster than the Go on that same 1.3GB MP4 > file and 3-4 times faster on the XML, so everyone has room for > improvement. :) Code: https://gist.github.com/huonw/b6bfe4ad3623b6c37717 > > > Btw, the Go is significantly slower when the file contains a lot of > newlines, e.g. this file is 75% \n's > > yes 'foo' | head -100000000 > newlines.txt > > The Rust built with -O takes ~0.4s for me, and the Go takes 2.6s. The > crossover point on my computer for very regular files like that is about > 1 \n in every 30 bytes. > > > Huon > > > > On 15/09/14 16:34, Petr Novotnik wrote: >> Hello folks, >> >> recently I've been playing around with Rust and I'm really impressed. >> I like the language a lot! >> >> While writing a program to count the number of lines in a file, I >> realized it ran twice as slow as an older program I wrote in Go some >> time ago. After more experiments, I've figured out that Go's speed >> boost comes from an optimized function in its standard library >> utilizing SSE instructions, in particular the function bytes.IndexByte >> (http://golang.org/pkg/bytes/#IndexByte). >> >> I was wondering whether Rust would ever provide such optimized >> implementations as well as part of its standard library or whether >> it's up to developers to write their own versions of such functions. >> >> Maybe I just missed something, so I'm attaching the rust program: >> >> http://pastebin.com/NfFgMNGe >> >> And for the sake of completeness, here's the Go version I compared with: >> >> http://pastebin.com/4tiLsRpu >> >> Pete. >> _______________________________________________ >> 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 pnovotnik at googlemail.com Tue Sep 16 12:41:30 2014 From: pnovotnik at googlemail.com (Petr Novotnik) Date: Tue, 16 Sep 2014 21:41:30 +0200 Subject: [rust-dev] std::rand::Rng Message-ID: <5418926A.8060802@googlemail.com> Hello list, I've got this small program: > use std::rand::{Rng, task_rng}; > > fn main() { > let rng = &mut task_rng(); > print_numbers(rng); > } > > fn print_numbers(r: &mut Rng) { > for _ in range(0u, 10) { > println!("{}", r.gen::()); > } > } generating me this compiler error: > rustc random.rs > random.rs:10:24: 10:39 error: cannot call a generic method through an object [E0039] > random.rs:10 println!("{}", r.gen::()); > ^~~~~~~~~~~~~~~ > note: in expansion of format_args! > :2:23: 2:77 note: expansion site > :1:1: 3:2 note: in expansion of println! > random.rs:10:9: 10:41 note: expansion site > error: aborting due to previous error I think the reason for the error message is because the compiler cannot statically dispatch the call. Correct? If so, I wonder what the motivation is for having generic methods in traits which themselves are not generified. If I understand it correctly, there's no chance invoking such a generic method through a trait type. Pete. From pnovotnik at googlemail.com Tue Sep 16 12:53:37 2014 From: pnovotnik at googlemail.com (Petr Novotnik) Date: Tue, 16 Sep 2014 21:53:37 +0200 Subject: [rust-dev] std::rand::Rng In-Reply-To: <5418926A.8060802@googlemail.com> References: <5418926A.8060802@googlemail.com> Message-ID: <54189541.2070008@googlemail.com> Is it to allow the following pattern? > fn print_numbers (r: &mut R) { > for _ in range(0u, 10) { > println!("{}", r.gen::()); > } > } Pete. From rtfm.rtfm.rtfm at gmail.com Wed Sep 17 07:04:18 2014 From: rtfm.rtfm.rtfm at gmail.com (Daneel Yaitskov) Date: Wed, 17 Sep 2014 18:04:18 +0400 Subject: [rust-dev] Can macro use variable values? Message-ID: Hi, Does Rust macro have flow control based on a variable value? I didn't find such info here http://doc.rust-lang.org/guide-macros.html. I'd like to get a macro expading a for loop. doTimes(3, println!("DDDD")) => println!("DDDD") println!("DDDD") println!("DDDD") -- Daneel S. Yaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at pablobm.com Wed Sep 17 12:53:24 2014 From: pablo at pablobm.com (Pablo Brasero Moreno) Date: Wed, 17 Sep 2014 20:53:24 +0100 Subject: [rust-dev] Bug in the guide? Message-ID: Hello all. I just subscribed to this list only because I found something odd on the Rust Guide, and couldn't find a better place to send feedback. It's about section 13 "Standard Input". The first example code is the following: use std::io; fn main() { println!("Type something!"); let input = std::io::stdin().read_line().ok().expect("Failed to read line"); println!("{}", input); } This code throws a warning because `std::io` is imported, and then `std::io::stdin` is used explicitly. >From reading the paragraphs that follow that code, I assume that the original intent of the author was to show that code without the first line, the `use` line. That way, the text seems to make better sense to me. Any t houghts? Also: please provide some obvious means of feedback! :-) Thank you in advance, -- Pablo Brasero Moreno pablo at pablobm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed Sep 17 12:55:29 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 17 Sep 2014 15:55:29 -0400 Subject: [rust-dev] Bug in the guide? In-Reply-To: References: Message-ID: <7FC6FAB0-C339-459D-991C-8563AF29D09F@steveklabnik.com> Yup, that leading std:: in main shouldn't be there. From tim at timdumol.com Wed Sep 17 12:58:20 2014 From: tim at timdumol.com (Tim Joseph Dumol) Date: Thu, 18 Sep 2014 03:58:20 +0800 Subject: [rust-dev] Bug in the guide? In-Reply-To: <7FC6FAB0-C339-459D-991C-8563AF29D09F@steveklabnik.com> References: <7FC6FAB0-C339-459D-991C-8563AF29D09F@steveklabnik.com> Message-ID: Hi Pablo, You can submit a pull request at the Rust Github repo ( https://github.com/rust-lang/rust). The relevant file is at `/src/doc/ guide.md`: https://github.com/rust-lang/rust/blob/master/src/doc/guide.md. Cheers, Tim Dumol On Thu, Sep 18, 2014 at 3:55 AM, Steve Klabnik wrote: > Yup, that leading std:: in main shouldn't be there. > _______________________________________________ > 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 pablo at pablobm.com Wed Sep 17 13:34:25 2014 From: pablo at pablobm.com (Pablo Brasero Moreno) Date: Wed, 17 Sep 2014 21:34:25 +0100 Subject: [rust-dev] Bug in the guide? In-Reply-To: References: <7FC6FAB0-C339-459D-991C-8563AF29D09F@steveklabnik.com> Message-ID: Rust community living up to its fame of awesomeness! Thanks for that. The pull request is already on the queue. On 17 September 2014 20:58, Tim Joseph Dumol wrote: > Hi Pablo, > > You can submit a pull request at the Rust Github repo ( > https://github.com/rust-lang/rust). The relevant file is at `/src/doc/ > guide.md`: https://github.com/rust-lang/rust/blob/master/src/doc/guide.md. > > Cheers, > > Tim Dumol > > On Thu, Sep 18, 2014 at 3:55 AM, Steve Klabnik > wrote: > >> Yup, that leading std:: in main shouldn't be there. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > -- Pablo Brasero Moreno pablo at pablobm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cptroot at gmail.com Wed Sep 17 14:26:58 2014 From: cptroot at gmail.com (Evan Davis) Date: Wed, 17 Sep 2014 14:26:58 -0700 Subject: [rust-dev] std::rand::Rng In-Reply-To: <54189541.2070008@googlemail.com> References: <5418926A.8060802@googlemail.com> <54189541.2070008@googlemail.com> Message-ID: The problem is that you're trying to use a trait as a type. This code works for me ``` use std::rand::{Rng, task_rng}; fn main() { let rng = &mut task_rng(); print_numbers(rng); } fn print_numbers(r: &mut T) { for _ in range(0u, 10) { println!("{}", r.gen::()); } } ``` -Evan Davis On Tue, Sep 16, 2014 at 12:53 PM, Petr Novotnik wrote: > Is it to allow the following pattern? > > fn print_numbers (r: &mut R) { >> for _ in range(0u, 10) { >> println!("{}", r.gen::()); >> } >> } >> > > Pete. > _______________________________________________ > 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 smcarthur at mozilla.com Wed Sep 17 14:33:11 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Wed, 17 Sep 2014 14:33:11 -0700 Subject: [rust-dev] std::rand::Rng In-Reply-To: References: <5418926A.8060802@googlemail.com> <54189541.2070008@googlemail.com> Message-ID: On Wed, Sep 17, 2014 at 2:26 PM, Evan Davis wrote: > > The problem is that you're trying to use a trait as a type. > That shouldn't be a problem. You can use a `&mut Trait`, and you'll get dynamic dispatch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnkfelix at mozilla.com Thu Sep 18 01:42:10 2014 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Thu, 18 Sep 2014 10:42:10 +0200 Subject: [rust-dev] std::rand::Rng In-Reply-To: References: <5418926A.8060802@googlemail.com> <54189541.2070008@googlemail.com> Message-ID: <0BA9BA1A-CD73-46E3-A760-95D686D3FEFD@mozilla.com> On 17 Sep 2014, at 23:33, Sean McArthur wrote: > On Wed, Sep 17, 2014 at 2:26 PM, Evan Davis wrote: > > The problem is that you're trying to use a trait as a type. > > That shouldn't be a problem. You can use a `&mut Trait`, and you'll get dynamic dispatch. You cannot mix dynamic dispatch with generic methods. (This is because we implement generic methods by monomorphization, i.e. by creating separate copies of the implementation for each instantiation -- but with dynamic dispatch, we do not know a priori what all of the calls to the method will be.) I would link a relevant portion of the Rust manual here, but I cannot actually find documentation of this restriction. ---- Pete?s original question was actually answered in his followup email. It is true that you cannot do: > fn print_numbers(r: &mut Rng) { > for _ in range(0u, 10) { > println!("{}", r.gen::()); > } > } due to the restriction I described above, but you can do: > fn print_numbers (r: &mut R) { > for _ in range(0u, 10) { > println!("{}", r.gen::()); > } > } where the trait is now being used as a bound on a generic type, rather than as the basis of an object type. Cheers, -Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtfm.rtfm.rtfm at gmail.com Thu Sep 18 08:44:39 2014 From: rtfm.rtfm.rtfm at gmail.com (Daneel Yaitskov) Date: Thu, 18 Sep 2014 19:44:39 +0400 Subject: [rust-dev] json read_str crashes Message-ID: I have a custom json deserializer. It can parse string or number. json functions return Result enum so I guess if it fails it should return Err. But lines println!("crap") or println!("string is ok") are not reached. Program crashes with the following output: not int. let's try string task '
' failed at 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/ option.rs:278 extern crate serialize; use serialize::{json, Decodable, Decoder}; fn main() { let raw_json = "\"ddd\""; let person: Primitive = json::decode(raw_json).unwrap(); println!("{}", person); } #[deriving(Show)] enum Primitive { ItInt(int), ItStr(String) } impl, E> Decodable for Primitive { fn decode(decoder: &mut S) -> Result { match decoder.read_int() { Ok(n) => Ok(ItInt(n)), _ => { println!("not int. let's try string"); match decoder.read_str() { Ok(s) => { println!("string is ok"); Ok(ItStr(s)) }, _ => { println!("crap"); Ok(ItStr("DDD".to_string())) } } } } } } -- Daneel S. Yaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at timdumol.com Thu Sep 18 08:52:23 2014 From: tim at timdumol.com (Tim Joseph Dumol) Date: Thu, 18 Sep 2014 23:52:23 +0800 Subject: [rust-dev] json read_str crashes In-Reply-To: References: Message-ID: Hi Daneel, Your `read_str` function tried to unwrap an `Option` that turned out to be `None`, which caused your error. You'll want to `match` on the that `Option` instead and handle for the case when it's a `None`. Good luck! Cheers, Tim Joseph Dumol On Thu, Sep 18, 2014 at 11:44 PM, Daneel Yaitskov wrote: > I have a custom json deserializer. It can parse string or number. > > json functions return Result enum so I guess if it fails it should return > Err. But lines println!("crap") or println!("string is ok") are not > reached. > > Program crashes with the following output: > > not int. let's try string > task '
' failed at 'called `Option::unwrap()` on a `None` value', > /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/ > option.rs:278 > > > extern crate serialize; > use serialize::{json, Decodable, Decoder}; > > fn main() { > let raw_json = "\"ddd\""; > let person: Primitive = json::decode(raw_json).unwrap(); > println!("{}", person); > } > > #[deriving(Show)] > enum Primitive { ItInt(int), ItStr(String) } > > impl, E> Decodable for Primitive { > fn decode(decoder: &mut S) -> Result { > match decoder.read_int() { > Ok(n) => Ok(ItInt(n)), > _ => { > println!("not int. let's try string"); > match decoder.read_str() { > Ok(s) => { > println!("string is ok"); > Ok(ItStr(s)) > }, > _ => { > println!("crap"); > Ok(ItStr("DDD".to_string())) > } > } > } > } > } > } > > -- > Daneel S. Yaitskov > > _______________________________________________ > 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 tim at timdumol.com Thu Sep 18 09:54:05 2014 From: tim at timdumol.com (Tim Joseph Dumol) Date: Fri, 19 Sep 2014 00:54:05 +0800 Subject: [rust-dev] json read_str crashes In-Reply-To: References: Message-ID: Hi Daneel, What seems to be happening (which others might be able to confirm) is that the JSON decoder is consuming the string as a stack, and after the first read_int() fails, there is no nothing left to pop (in doc.rust-lang.org/src/serialize/home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libserialize/json.rs.html#1916), which causes the subsequent read_str() to fail. You can double-check this by removing the `read_int()` call, after which the `read_str()` works. Cheers, Tim Joseph Dumol On Fri, Sep 19, 2014 at 12:40 AM, Tim Joseph Dumol wrote: > Whoops, my bad! I misread your code in my haste to answer your question. > I'm a newbie to Rust, actually, so I'll have to spend some time exploring > why this is happening. Maybe someone else can help faster. Sorry for the > confusion! > > Tim Joseph Dumol > > On Fri, Sep 19, 2014 at 12:23 AM, Daneel Yaitskov < > rtfm.rtfm.rtfm at gmail.com> wrote: > >> Why does read_str returns Result? I cannot catch the Err because of fail! >> It looks weird. Where is the sense? >> >> Just String result would better fit to read_str wiith such behavior, >> wouldn't it? >> >> Here is another question. Have Rust standard painless method to >> deserialize json map with different primitive value types (int, string, >> bool...)? >> >> json::decode(String) -> Option> >> or >> json::decode(String) -> Option> >> >> where >> enum Primitive { Pint(int), Pstr(String), .... } >> >> On Sep 18, 2014 7:52 PM, "Tim Joseph Dumol" wrote: >> >>> Hi Daneel, >>> >>> Your `read_str` function tried to unwrap an `Option` that turned out to >>> be `None`, which caused your error. You'll want to `match` on the that >>> `Option` instead and handle for the case when it's a `None`. Good luck! >>> >>> Cheers, >>> >>> Tim Joseph Dumol >>> >>> On Thu, Sep 18, 2014 at 11:44 PM, Daneel Yaitskov < >>> rtfm.rtfm.rtfm at gmail.com> wrote: >>> >>>> I have a custom json deserializer. It can parse string or number. >>>> >>>> json functions return Result enum so I guess if it fails it should >>>> return >>>> Err. But lines println!("crap") or println!("string is ok") are not >>>> reached. >>>> >>>> Program crashes with the following output: >>>> >>>> not int. let's try string >>>> task '
' failed at 'called `Option::unwrap()` on a `None` value', >>>> /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/ >>>> option.rs:278 >>>> >>>> >>>> extern crate serialize; >>>> use serialize::{json, Decodable, Decoder}; >>>> >>>> fn main() { >>>> let raw_json = "\"ddd\""; >>>> let person: Primitive = json::decode(raw_json).unwrap(); >>>> println!("{}", person); >>>> } >>>> >>>> #[deriving(Show)] >>>> enum Primitive { ItInt(int), ItStr(String) } >>>> >>>> impl, E> Decodable for Primitive { >>>> fn decode(decoder: &mut S) -> Result { >>>> match decoder.read_int() { >>>> Ok(n) => Ok(ItInt(n)), >>>> _ => { >>>> println!("not int. let's try string"); >>>> match decoder.read_str() { >>>> Ok(s) => { >>>> println!("string is ok"); >>>> Ok(ItStr(s)) >>>> }, >>>> _ => { >>>> println!("crap"); >>>> Ok(ItStr("DDD".to_string())) >>>> } >>>> } >>>> } >>>> } >>>> } >>>> } >>>> >>>> -- >>>> Daneel S. Yaitskov >>>> >>>> _______________________________________________ >>>> 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 rtfm.rtfm.rtfm at gmail.com Thu Sep 18 12:42:21 2014 From: rtfm.rtfm.rtfm at gmail.com (Daneel Yaitskov) Date: Thu, 18 Sep 2014 23:42:21 +0400 Subject: [rust-dev] json read_str crashes In-Reply-To: References: Message-ID: Thanks, Tim. I understood my fault but still cannot get deserialization mixed value. I tried to call pop method directly but it's private. extern crate serialize; use serialize::{Decodable, Decoder}; use serialize::json::{Json, Boolean, String, Null, I64, U64, F64}; use serialize::json; #[deriving(Show)] struct Primitive(Json); impl, E> Decodable for Primitive { fn decode(decoder: &mut S) -> Result { match decoder.pop() { Null => Primitive(Null), b @ Boolean(_)=> Primitive(b), n @ I64(_) => Primitive(n), n @ U64(_) => Primitive(n), n @ F64(_) => Primitive(n), s @ String(_) => Primitive(s), bad => fail!("bad {}", bad) } } } On Thu, Sep 18, 2014 at 8:54 PM, Tim Joseph Dumol wrote: > Hi Daneel, > > What seems to be happening (which others might be able to confirm) is that > the JSON decoder is consuming the string as a stack, and after the first > read_int() fails, there is no nothing left to pop (in > doc.rust-lang.org/src/serialize/home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libserialize/json.rs.html#1916), > which causes the subsequent read_str() to fail. You can double-check this by > removing the `read_int()` call, after which the `read_str()` works. > > Cheers, > > Tim Joseph Dumol > > On Fri, Sep 19, 2014 at 12:40 AM, Tim Joseph Dumol wrote: >> >> Whoops, my bad! I misread your code in my haste to answer your question. >> I'm a newbie to Rust, actually, so I'll have to spend some time exploring >> why this is happening. Maybe someone else can help faster. Sorry for the >> confusion! >> >> Tim Joseph Dumol >> >> On Fri, Sep 19, 2014 at 12:23 AM, Daneel Yaitskov >> wrote: >>> >>> Why does read_str returns Result? I cannot catch the Err because of fail! >>> It looks weird. Where is the sense? >>> >>> Just String result would better fit to read_str wiith such behavior, >>> wouldn't it? >>> >>> Here is another question. Have Rust standard painless method to >>> deserialize json map with different primitive value types (int, string, >>> bool...)? >>> >>> json::decode(String) -> Option> >>> or >>> json::decode(String) -> Option> >>> >>> where >>> enum Primitive { Pint(int), Pstr(String), .... } >>> >>> On Sep 18, 2014 7:52 PM, "Tim Joseph Dumol" wrote: >>>> >>>> Hi Daneel, >>>> >>>> Your `read_str` function tried to unwrap an `Option` that turned out to >>>> be `None`, which caused your error. You'll want to `match` on the that >>>> `Option` instead and handle for the case when it's a `None`. Good luck! >>>> >>>> Cheers, >>>> >>>> Tim Joseph Dumol >>>> >>>> On Thu, Sep 18, 2014 at 11:44 PM, Daneel Yaitskov >>>> wrote: >>>>> >>>>> I have a custom json deserializer. It can parse string or number. >>>>> >>>>> json functions return Result enum so I guess if it fails it should >>>>> return >>>>> Err. But lines println!("crap") or println!("string is ok") are not >>>>> reached. >>>>> >>>>> Program crashes with the following output: >>>>> >>>>> not int. let's try string >>>>> task '
' failed at 'called `Option::unwrap()` on a `None` value', >>>>> /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/option.rs:278 >>>>> >>>>> >>>>> extern crate serialize; >>>>> use serialize::{json, Decodable, Decoder}; >>>>> >>>>> fn main() { >>>>> let raw_json = "\"ddd\""; >>>>> let person: Primitive = json::decode(raw_json).unwrap(); >>>>> println!("{}", person); >>>>> } >>>>> >>>>> #[deriving(Show)] >>>>> enum Primitive { ItInt(int), ItStr(String) } >>>>> >>>>> impl, E> Decodable for Primitive { >>>>> fn decode(decoder: &mut S) -> Result { >>>>> match decoder.read_int() { >>>>> Ok(n) => Ok(ItInt(n)), >>>>> _ => { >>>>> println!("not int. let's try string"); >>>>> match decoder.read_str() { >>>>> Ok(s) => { >>>>> println!("string is ok"); >>>>> Ok(ItStr(s)) >>>>> }, >>>>> _ => { >>>>> println!("crap"); >>>>> Ok(ItStr("DDD".to_string())) >>>>> } >>>>> } >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> -- >>>>> Daneel S. Yaitskov >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>> >> > -- Daneel S. Yaitskov From blastrock0 at free.fr Thu Sep 18 13:00:56 2014 From: blastrock0 at free.fr (Philippe) Date: Thu, 18 Sep 2014 22:00:56 +0200 Subject: [rust-dev] Synchronizing with non-rust thread (async ffi callback) In-Reply-To: <5419FE4A.5020802@free.fr> References: <5419FE4A.5020802@free.fr> Message-ID: <541B39F8.4050201@free.fr> Hi again, I think this is a bug in rust. Here is a minimal example attached. Uncompress and type "make run". On my debian amd64 unstable machine, I get: fatal runtime error: assertion failed: !ptr.is_null() Illegal instruction I'm not sure how to report it, where should I upload the file? Philippe On 09/17/2014 11:34 PM, Philippe wrote: > Hi, > > I have a case very similar to the one described here: > http://doc.rust-lang.org/guide-ffi.html#asynchronous-callbacks . The > guide explains what to do but not how to do it. I tried to share a > Mutex between the rust thread and the c thread using combinations of > Arc, std::mem::drop and stuff, std::ptr::read and stuff. So far I got > only segfaults and assertion failures when I try to lock the mutex. > How are we supposed to send an object to a C callback and give it > ownership? > > Also, there seems not to be Promise/Future classes in the standard > library, why is that? > > Thanks, > Philippe -------------- next part -------------- A non-text attachment was scrubbed... Name: rustcrash.tar.bz2 Type: application/x-bzip2 Size: 814 bytes Desc: not available URL: From lee at weiyen.me Thu Sep 18 21:09:20 2014 From: lee at weiyen.me (Lee Wei Yen) Date: Fri, 19 Sep 2014 14:09:20 +1000 Subject: [rust-dev] Rust BigInt Message-ID: Hi all! I?ve just started learning to use Rust now, and so far it?s been everything I wanted in a language. I saw from the docs that the num::bigint::BigInt type has been deprecated - does it have a replacement? -- Lee Wei Yen -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Sep 18 21:13:28 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 19 Sep 2014 00:13:28 -0400 Subject: [rust-dev] Rust BigInt In-Reply-To: References: Message-ID: <541BAD68.3010000@gmail.com> On 19/09/14 12:09 AM, Lee Wei Yen wrote: > Hi all! > > I?ve just started learning to use Rust now, and so far it?s been > everything I wanted in a language. > > I saw from the docs that the num::bigint::BigInt type has been > deprecated - does it have a replacement? > > -- > Lee Wei Yen It was moved to https://github.com/rust-lang/num There's also https://github.com/thestinger/rust-gmp which binds to GMP. GMP has better time complexity for the operations, significantly faster constant factors (10-20x for some operations) and more functionality. It also doesn't have lots of showstopper bugs since it's a mature library. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From silvio.frischi at gmail.com Fri Sep 19 00:39:53 2014 From: silvio.frischi at gmail.com (silvio) Date: Fri, 19 Sep 2014 09:39:53 +0200 Subject: [rust-dev] iterate over pairs and why no multiple mutable references Message-ID: <541BDDC9.7030601@gmail.com> Hi Rust, I've recently tried to investigate rust's claim of being fast and had a look at debian shootout. A particular program I took a looked at is the n-body problem in which you have to loop over pairs of bodies to calculate their gravitational attraction. What struck me as strange was the number of indexing operations. bodies[i] bodies[j] bodies[i] bodies[j] ... Now I don't know if the compiler is smart enough to optimize this away. However, it seems generally impossible to make references. let mut body_i = bodies.someMethod(i) let mut body_j = bodies.someMethod(j) So how is this usually done? Why are multiple mutable references to the same object not allowed. To achieve safe memory you only need to guarantee that different threads don't write/read from/to the same memory location at the same time and that is handled via ownership. (borrowed) references & don't have ownership. Additionally, you need to ensure that all references not only mut are not usable anymore until you can transfer ownership. So, I don't understand why mut and not mut are treated differently. An other small thing. I read that you should always return a type directly. fn foo(args) -> big_struct Does this mean that all return values are secretly pointers passed to the function except for things that fit into registers? regards silvio From klesnil at centrum.cz Fri Sep 19 01:13:43 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Fri, 19 Sep 2014 10:13:43 +0200 Subject: [rust-dev] iterate over pairs and why no multiple mutable references In-Reply-To: <541BDDC9.7030601@gmail.com> References: <541BDDC9.7030601@gmail.com> Message-ID: <541BE5B7.6050607@centrum.cz> Hi, indexing operations check boundaries. Compiler (LLVM backend) is capable of removing some of them, sometimes, but generally indexed accesses tends to be slower in comparison to iteration using the Iterator. Multiple mutable references are not only bad for multithreading and data races but also they create more aliases that prevent optimizations. Moreover, single-threaded code can be turned into multi-threaded easily if you follow stricter rules from the start. http://doc.rust-lang.org/guide.html#ownership,-borrowing,-and-lifetimes Multiple mutable borrows from a same vector is currently one of the biggest weaknesses of Rust. There are some proposals to cope with it but I personally do not know what is the current state of the matter. Large return values are placed in preallocated space, the same way as RVO works in C++. http://doc.rust-lang.org/guide-pointers.html#returning-pointers JK On 19.9.2014 09:39, silvio wrote: > Hi Rust, > > I've recently tried to investigate rust's claim of being fast and had a > look at debian shootout. > > A particular program I took a looked at is the n-body problem in which > you have to loop over pairs of bodies to calculate their gravitational > attraction. What struck me as strange was the number of indexing operations. > > bodies[i] > bodies[j] > bodies[i] > bodies[j] > ... > > Now I don't know if the compiler is smart enough to optimize this away. > However, it seems generally impossible to make references. > > let mut body_i = bodies.someMethod(i) > let mut body_j = bodies.someMethod(j) > > So how is this usually done? > > Why are multiple mutable references to the same object not allowed. To > achieve safe memory you only need to guarantee that different threads > don't write/read from/to the same memory location at the same time and > that is handled via ownership. (borrowed) references & don't have > ownership. Additionally, you need to ensure that all references not only > mut are not usable anymore until you can transfer ownership. So, I don't > understand why mut and not mut are treated differently. > > An other small thing. I read that you should always return a type directly. > > fn foo(args) -> big_struct > > Does this mean that all return values are secretly pointers passed to > the function except for things that fit into registers? > > > regards > > silvio > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From manishsmail at gmail.com Fri Sep 19 01:13:57 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Fri, 19 Sep 2014 13:43:57 +0530 Subject: [rust-dev] iterate over pairs and why no multiple mutable references In-Reply-To: <541BDDC9.7030601@gmail.com> References: <541BDDC9.7030601@gmail.com> Message-ID: Iterator invalidation is a common memory safety issue where you have two references being simultaneously used -- one mutable, one immutable. With multiple mutable references worse errors can happen. -Manish Goregaokar On Fri, Sep 19, 2014 at 1:09 PM, silvio wrote: > Hi Rust, > > I've recently tried to investigate rust's claim of being fast and had a > look at debian shootout. > > A particular program I took a looked at is the n-body problem in which > you have to loop over pairs of bodies to calculate their gravitational > attraction. What struck me as strange was the number of indexing > operations. > > bodies[i] > bodies[j] > bodies[i] > bodies[j] > ... > > Now I don't know if the compiler is smart enough to optimize this away. > However, it seems generally impossible to make references. > > let mut body_i = bodies.someMethod(i) > let mut body_j = bodies.someMethod(j) > > So how is this usually done? > > Why are multiple mutable references to the same object not allowed. To > achieve safe memory you only need to guarantee that different threads > don't write/read from/to the same memory location at the same time and > that is handled via ownership. (borrowed) references & don't have > ownership. Additionally, you need to ensure that all references not only > mut are not usable anymore until you can transfer ownership. So, I don't > understand why mut and not mut are treated differently. > > An other small thing. I read that you should always return a type directly. > > fn foo(args) -> big_struct > > Does this mean that all return values are secretly pointers passed to > the function except for things that fit into registers? > > > regards > > silvio > _______________________________________________ > 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 cg.wowus.cg at gmail.com Fri Sep 19 08:32:09 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 19 Sep 2014 08:32:09 -0700 (PDT) Subject: [rust-dev] iterate over pairs and why no multiple mutable references In-Reply-To: References: Message-ID: <1411140729777.49c63054@Nodemailer> You can use a Vec> for this.? Sent from Mailbox On Fri, Sep 19, 2014 at 1:14 AM, Manish Goregaokar wrote: > Iterator invalidation is a common memory safety issue where you have two > references being simultaneously used -- one mutable, one immutable. With > multiple mutable references worse errors can happen. > -Manish Goregaokar > On Fri, Sep 19, 2014 at 1:09 PM, silvio wrote: >> Hi Rust, >> >> I've recently tried to investigate rust's claim of being fast and had a >> look at debian shootout. >> >> A particular program I took a looked at is the n-body problem in which >> you have to loop over pairs of bodies to calculate their gravitational >> attraction. What struck me as strange was the number of indexing >> operations. >> >> bodies[i] >> bodies[j] >> bodies[i] >> bodies[j] >> ... >> >> Now I don't know if the compiler is smart enough to optimize this away. >> However, it seems generally impossible to make references. >> >> let mut body_i = bodies.someMethod(i) >> let mut body_j = bodies.someMethod(j) >> >> So how is this usually done? >> >> Why are multiple mutable references to the same object not allowed. To >> achieve safe memory you only need to guarantee that different threads >> don't write/read from/to the same memory location at the same time and >> that is handled via ownership. (borrowed) references & don't have >> ownership. Additionally, you need to ensure that all references not only >> mut are not usable anymore until you can transfer ownership. So, I don't >> understand why mut and not mut are treated differently. >> >> An other small thing. I read that you should always return a type directly. >> >> fn foo(args) -> big_struct >> >> Does this mean that all return values are secretly pointers passed to >> the function except for things that fit into registers? >> >> >> regards >> >> silvio >> _______________________________________________ >> 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 Fri Sep 19 09:40:01 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 19 Sep 2014 18:40:01 +0200 Subject: [rust-dev] Rust BigInt In-Reply-To: <541BAD68.3010000@gmail.com> References: <541BAD68.3010000@gmail.com> Message-ID: On Fri, Sep 19, 2014 at 6:13 AM, Daniel Micay wrote: > On 19/09/14 12:09 AM, Lee Wei Yen wrote: > > Hi all! > > > > I?ve just started learning to use Rust now, and so far it?s been > > everything I wanted in a language. > > > > I saw from the docs that the num::bigint::BigInt type has been > > deprecated - does it have a replacement? > > > > -- > > Lee Wei Yen > > It was moved to https://github.com/rust-lang/num > > There's also https://github.com/thestinger/rust-gmp which binds to GMP. > > GMP has better time complexity for the operations, significantly faster > constant factors (10-20x for some operations) and more functionality. > > It also doesn't have lots of showstopper bugs since it's a mature library. > > Disclaimer, for the unwary, GMP is a GPL library; so using it implies complying with the GPL license. > > _______________________________________________ > 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 jauhien at gentoo.org Fri Sep 19 09:46:22 2014 From: jauhien at gentoo.org (Jauhien Piatlicki) Date: Fri, 19 Sep 2014 18:46:22 +0200 Subject: [rust-dev] Rust BigInt In-Reply-To: References: <541BAD68.3010000@gmail.com> Message-ID: <541C5DDE.7040403@gentoo.org> Hi, On 09/19/2014 06:40 PM, Matthieu Monrocq wrote: > Disclaimer, for the unwary, GMP is a GPL library; so using it implies > complying with the GPL license. > LGPL afaik, so you can dynamically link with it in any case. > >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Fri Sep 19 13:14:03 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 19 Sep 2014 16:14:03 -0400 Subject: [rust-dev] Rust BigInt In-Reply-To: References: <541BAD68.3010000@gmail.com> Message-ID: <541C8E8B.2070302@gmail.com> On 19/09/14 12:40 PM, Matthieu Monrocq wrote: > > > On Fri, Sep 19, 2014 at 6:13 AM, Daniel Micay > wrote: > > On 19/09/14 12:09 AM, Lee Wei Yen wrote: > > Hi all! > > > > I?ve just started learning to use Rust now, and so far it?s been > > everything I wanted in a language. > > > > I saw from the docs that the num::bigint::BigInt type has been > > deprecated - does it have a replacement? > > > > -- > > Lee Wei Yen > > It was moved to https://github.com/rust-lang/num > > There's also https://github.com/thestinger/rust-gmp which binds to GMP. > > GMP has better time complexity for the operations, significantly faster > constant factors (10-20x for some operations) and more functionality. > > It also doesn't have lots of showstopper bugs since it's a mature > library. > > > Disclaimer, for the unwary, GMP is a GPL library; so using it implies > complying with the GPL license. Not true. It's under the LGPL license and proprietary applications can both dynamically link and statically link against it. The end user needs to be able to replace the library - which is a given with dynamic linking, and can be done with static linking by providing linkable object files rather than a binary (or both). Rust itself relies on plenty of GPL with linking exception / LGPL code like glibc / libgcc / libunwind. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Fri Sep 19 13:15:07 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 19 Sep 2014 16:15:07 -0400 Subject: [rust-dev] Rust BigInt In-Reply-To: <541C5DDE.7040403@gentoo.org> References: <541BAD68.3010000@gmail.com> <541C5DDE.7040403@gentoo.org> Message-ID: <541C8ECB.2050703@gmail.com> On 19/09/14 12:46 PM, Jauhien Piatlicki wrote: > Hi, > > On 09/19/2014 06:40 PM, Matthieu Monrocq wrote: >> Disclaimer, for the unwary, GMP is a GPL library; so using it implies >> complying with the GPL license. >> > > LGPL afaik, so you can dynamically link with it in any case. Static linking of a proprietary application is fine too, as long as linkable object files are provided so the user can replace GMP with a patched / updated library. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From silvio.frischi at gmail.com Sat Sep 20 14:20:50 2014 From: silvio.frischi at gmail.com (silvio) Date: Sat, 20 Sep 2014 23:20:50 +0200 Subject: [rust-dev] SSE problem Message-ID: <541DEFB2.3000007@gmail.com> Hello I've been trying to replicate an SSE trick from a c program in rust and come up with some strange behavior. It seems work for --opt-level 0,1 but gives the wrong result on 2,3. I used the !asm instruction to execute assembly commands. I'm not sure if this is a bug or just me not using asm! correctly. The most condensed version that still produces the bug is appended. on opt 0,1 I get the correct answer 2 on opt 2,3 I get the wrong answer 0 Silvio -------------- next part -------------- #![feature(asm)] use std::simd::f32x4; use std::simd::f64x2; fn main() { let one2 = f64x2(1f64,1f64); println!("one2 1: {}", one2); let shift = mm_convert_f32x4_f64x2(mm_convert_f64x2_f32x4(one2))+one2; let f64x2(res1, _) = shift; println!("res: {}", res1); } #[cfg(target_arch = "x86")] #[cfg(target_arch = "x86_64")] fn mm_convert_f32x4_f64x2(a: f32x4) -> f64x2 { let mut ret : f64x2 = unsafe {std::mem::uninitialized()}; unsafe { asm!("cvtps2pd $0, $1" : "=x"(ret) : "x"(a) ); } ret } #[cfg(target_arch = "x86")] #[cfg(target_arch = "x86_64")] fn mm_convert_f64x2_f32x4(a: f64x2) -> f32x4 { let mut ret : f32x4 = unsafe {std::mem::uninitialized()}; unsafe { asm!("cvtpd2ps $0, $1" : "=x"(ret) : "x"(a) ); } ret } #[cfg(target_arch = "x86")] #[cfg(target_arch = "x86_64")] fn mm_sqrt_reciprocal_f32x4(a: f32x4) -> f32x4 { let mut ret : f32x4 = unsafe {std::mem::uninitialized()}; unsafe { asm!("rsqrtps $0, $1" : "=x"(ret) : "x"(a) ); } ret } From peter at taricorp.net Sat Sep 20 15:05:10 2014 From: peter at taricorp.net (Peter Marheine) Date: Sat, 20 Sep 2014 16:05:10 -0600 Subject: [rust-dev] SSE problem In-Reply-To: <541DEFB2.3000007@gmail.com> References: <541DEFB2.3000007@gmail.com> Message-ID: What kind of "strange behavior" are you getting? Segfaults, wrong results, or something else entirely? Your code looks okay to me at a glance, but I'd be inclined to think it's still a problem on your end. asm! mostly plumbs down to LLVM for expansion, and the odds of LLVM having a bug there are lower than those of you having a bug. Have you looked at the generated assembly to see what it's doing (--emit asm)? I'd guess there's a problem with the constraints you're specifying, which will probably be pretty obvious. You'll probably see wrong values going into the inline assembly block or the computation clobbering a register used soon afterward. On Sat, Sep 20, 2014 at 3:20 PM, silvio wrote: > Hello > > I've been trying to replicate an SSE trick from a c program in rust and > come up with some strange behavior. It seems work for --opt-level 0,1 > but gives the wrong result on 2,3. I used the !asm instruction to > execute assembly commands. > > I'm not sure if this is a bug or just me not using asm! correctly. > > The most condensed version that still produces the bug is appended. > > on opt 0,1 I get the correct answer 2 > on opt 2,3 I get the wrong answer 0 > > Silvio > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Peter Marheine Don't Panic From silvio.frischi at gmail.com Sat Sep 20 17:18:41 2014 From: silvio.frischi at gmail.com (silvio) Date: Sun, 21 Sep 2014 02:18:41 +0200 Subject: [rust-dev] SSE problem In-Reply-To: References: <541DEFB2.3000007@gmail.com> Message-ID: <541E1961.3010008@gmail.com> On 09/21/2014 12:05 AM, Peter Marheine wrote: > What kind of "strange behavior" are you getting? Segfaults, wrong > results, or something else entirely? ok I found out I had the source dest order reversed, because i was leafing through the intel manual. That was really annoying I never heard of that. If I added some sse functions to f32x4, ... using this inline style. Would this be likely be merged or are there plans to deal with simd in some other way? Is there some code already around? Also is there also a way of inlineing llvm instructions? Because they already have some already abstracted simd operations. Silvio From bascule at gmail.com Sat Sep 20 23:29:21 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 21 Sep 2014 01:29:21 -0500 Subject: [rust-dev] On the use of unsafe Message-ID: Traditionally in Rust, "unsafe" has centered around memory safety. The reference manual describes it as such: http://doc.rust-lang.org/rust.html#unsafety At Strange Loop, during Chris Morgan's talk, someone asked about using the type system to present SQL injection after he described using the type system to handle escaping. He suggested using unsafe to call out when a SQL query is being made with a raw string. On the one hand I really liked the clarity of calling out passing a raw string to a SQL driver as being inherently unsafe, but on the other hand it seems to be semantically different from Rust's traditional sense of what's unsafe. Is it ok to extend unsafe to things which are unsafe from a security standpoint, or is this conflating concerns? Should there be a standard way to express things which are potentially unsafe from a security standpoint but not necessarily from a memory safety standpoint? I think something like that would be pretty cool. "insecure" ? ;) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Sep 20 23:34:38 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 21 Sep 2014 02:34:38 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: Message-ID: <541E717E.5010309@gmail.com> On 21/09/14 02:29 AM, Tony Arcieri wrote: > Traditionally in Rust, "unsafe" has centered around memory safety. The > reference manual describes it as such: > > http://doc.rust-lang.org/rust.html#unsafety > > At Strange Loop, during Chris Morgan's talk, someone asked about using > the type system to present SQL injection after he described using the > type system to handle escaping. > > He suggested using unsafe to call out when a SQL query is being made > with a raw string. > > On the one hand I really liked the clarity of calling out passing a raw > string to a SQL driver as being inherently unsafe, but on the other hand > it seems to be semantically different from Rust's traditional sense of > what's unsafe. > > Is it ok to extend unsafe to things which are unsafe from a security > standpoint, or is this conflating concerns? > > Should there be a standard way to express things which are potentially > unsafe from a security standpoint but not necessarily from a memory > safety standpoint? > > I think something like that would be pretty cool. "insecure" ? ;) > > -- > Tony Arcieri It's not intended to be used for anything other than memory safety. The requirements are the same across all libraries / applications. It's not possible to represent the semantics of 'insecure' in the language as that's very poorly defined and varies across domains and libraries. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bascule at gmail.com Sat Sep 20 23:39:26 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 21 Sep 2014 01:39:26 -0500 Subject: [rust-dev] On the use of unsafe In-Reply-To: <541E717E.5010309@gmail.com> References: <541E717E.5010309@gmail.com> Message-ID: On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay wrote: > It's not possible to represent the semantics of 'insecure' in the > language as > that's very poorly defined and varies across domains and libraries. I'd define it as "think before you use this" -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sat Sep 20 23:41:16 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 21 Sep 2014 01:41:16 -0500 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> Message-ID: I'd also note: having a way of calling out these sorts of cases explicitly is enormously beneficial to code reviewers. It provides an easily greppable way to find where to focus their attention. I assume it would be beneficial for static analysis tools as well. On Sun, Sep 21, 2014 at 1:39 AM, Tony Arcieri wrote: > On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay > wrote: > >> It's not possible to represent the semantics of 'insecure' in the >> language as >> that's very poorly defined and varies across domains and libraries. > > > I'd define it as "think before you use this" > > -- > Tony Arcieri > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sat Sep 20 23:47:32 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 21 Sep 2014 01:47:32 -0500 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> Message-ID: Also, here's a paper that provides a formalized definition of security domains using dependent types: https://research.microsoft.com/en-us/um/people/nswamy/papers/gradual-typing-embedded-securely-in-javascript-draft.pdf Would love to see Rust get dependent types eventually... but hey, I get it, gotta ship 1.0 before anyone gets a pony? ;) On Sun, Sep 21, 2014 at 1:41 AM, Tony Arcieri wrote: > I'd also note: having a way of calling out these sorts of cases explicitly > is enormously beneficial to code reviewers. It provides an easily greppable > way to find where to focus their attention. I assume it would be beneficial > for static analysis tools as well. > > On Sun, Sep 21, 2014 at 1:39 AM, Tony Arcieri wrote: > >> On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay >> wrote: >> >>> It's not possible to represent the semantics of 'insecure' in the >>> language as >>> that's very poorly defined and varies across domains and libraries. >> >> >> I'd define it as "think before you use this" >> >> -- >> Tony Arcieri >> > > > > -- > Tony Arcieri > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From zwarich at mozilla.com Sun Sep 21 00:02:23 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Sun, 21 Sep 2014 00:02:23 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: Message-ID: On Sep 20, 2014, at 11:29 PM, Tony Arcieri wrote: > He suggested using unsafe to call out when a SQL query is being made with a raw string. > > On the one hand I really liked the clarity of calling out passing a raw string to a SQL driver as being inherently unsafe, but on the other hand it seems to be semantically different from Rust's traditional sense of what's unsafe. > > Is it ok to extend unsafe to things which are unsafe from a security standpoint, or is this conflating concerns? > > Should there be a standard way to express things which are potentially unsafe from a security standpoint but not necessarily from a memory safety standpoint? The usual solution to this particular problem in typed languages is to make a new type wrapping sanitized strings, use some feature of the language (e.g. abstract types or module privacy) to restrict the creation of instances of this new type, and expose functions that produce an instance of this type by sanitization. I think that this is a better use of the language than using ?unsafe? in a confusing and unidiomatic way. Rust doesn?t really provide any specific features for security beyond memory safety, but it should be possible to extend the language to support things like information-flow security, etc. Cameron From bascule at gmail.com Sun Sep 21 00:06:51 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 21 Sep 2014 02:06:51 -0500 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: Message-ID: On Sun, Sep 21, 2014 at 2:02 AM, Cameron Zwarich wrote: > The usual solution to this particular problem in typed languages is to > make a new type wrapping sanitized strings, use some feature of the > language (e.g. abstract types or module privacy) to restrict the creation > of instances of this new type, and expose functions that produce an > instance of this type by sanitization. I think that this is a better use of > the language than using ?unsafe? in a confusing and unidiomatic way. > Definitely, a SQL driver should operate on a RawQuery or what have you. Rust doesn?t really provide any specific features for security beyond > memory safety, but it should be possible to extend the language to support > things like information-flow security, etc. Yeah, the paper I linked describes using dependent types to do what is effectively taint checking by proof -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Sun Sep 21 02:57:33 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Sun, 21 Sep 2014 10:57:33 +0100 Subject: [rust-dev] On the use of unsafe In-Reply-To: <541E717E.5010309@gmail.com> References: <541E717E.5010309@gmail.com> Message-ID: <541EA10D.2060003@exyr.org> On 21/09/14 07:34, Daniel Micay wrote: > It's not intended to be used for anything other than memory safety. It?s also used to maintain invariants, such as the bytes inside a String being valid UTF-8: String::push_bytes() is unsafe, but String::push_str() is not. -- Simon Sapin From pazaconyoman at gmail.com Sun Sep 21 10:24:47 2014 From: pazaconyoman at gmail.com (Viktor Dahl) Date: Sun, 21 Sep 2014 19:24:47 +0200 Subject: [rust-dev] iterate over pairs and why no multiple mutable references In-Reply-To: <1411140729777.49c63054@Nodemailer> References: <1411140729777.49c63054@Nodemailer> Message-ID: You can break memory safety in a single thread if you allow multiple mutable references to the same object. Consider an enum like this: enum Foo { Pointer(Box), Integer(i32) } Take one reference to the boxed `T` inside a `Foo` of the `Pointer` variant. It doesn't even have to be mutable. Then use a mutable reference to the enum object itself to change the variant to `Integer`. Reading from the first reference now is a use-after-free, since the boxed T was freed when the variant changed. If you'd taken a reference to the box instead, you'd be trying to follow a garbage pointer. 2014-09-19 17:32 GMT+02:00 Clark Gaebel : > You can use a Vec> for this. > ? > Sent from Mailbox > > > On Fri, Sep 19, 2014 at 1:14 AM, Manish Goregaokar > wrote: > >> Iterator invalidation is a common memory safety issue where you have two >> references being simultaneously used -- one mutable, one immutable. With >> multiple mutable references worse errors can happen. >> >> -Manish Goregaokar >> >> On Fri, Sep 19, 2014 at 1:09 PM, silvio wrote: >> >>> Hi Rust, >>> >>> I've recently tried to investigate rust's claim of being fast and had a >>> look at debian shootout. >>> >>> A particular program I took a looked at is the n-body problem in which >>> you have to loop over pairs of bodies to calculate their gravitational >>> attraction. What struck me as strange was the number of indexing >>> operations. >>> >>> bodies[i] >>> bodies[j] >>> bodies[i] >>> bodies[j] >>> ... >>> >>> Now I don't know if the compiler is smart enough to optimize this away. >>> However, it seems generally impossible to make references. >>> >>> let mut body_i = bodies.someMethod(i) >>> let mut body_j = bodies.someMethod(j) >>> >>> So how is this usually done? >>> >>> Why are multiple mutable references to the same object not allowed. To >>> achieve safe memory you only need to guarantee that different threads >>> don't write/read from/to the same memory location at the same time and >>> that is handled via ownership. (borrowed) references & don't have >>> ownership. Additionally, you need to ensure that all references not only >>> mut are not usable anymore until you can transfer ownership. So, I don't >>> understand why mut and not mut are treated differently. >>> >>> An other small thing. I read that you should always return a type >>> directly. >>> >>> fn foo(args) -> big_struct >>> >>> Does this mean that all return values are secretly pointers passed to >>> the function except for things that fit into registers? >>> >>> >>> regards >>> >>> silvio >>> _______________________________________________ >>> 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 jauhien at gentoo.org Sun Sep 21 12:54:41 2014 From: jauhien at gentoo.org (Jauhien Piatlicki) Date: Sun, 21 Sep 2014 21:54:41 +0200 Subject: [rust-dev] rust LLVM bindings Message-ID: <541F2D01.60603@gentoo.org> Hi, are there any plans to implement complete common safe bindings to LLVM? I know about existing ones, but they have problems: -- they are low level unsafe extern C functions, it would be nice to have LLVM API wrapped in safe idiomatic rust code -- some parts are wrapped in safe rust code, but these parts are very rust compiler specific -- even available unsafe bindings are far from being complete, they lack lots of useful LLVM functionality (e.g. JIT compilation functionality useful for proper REPL implementation) -- Regards, Jauhien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From silvio.frischi at gmail.com Sun Sep 21 13:00:08 2014 From: silvio.frischi at gmail.com (silvio) Date: Sun, 21 Sep 2014 22:00:08 +0200 Subject: [rust-dev] iterate over pairs and why no multiple mutable references In-Reply-To: References: <1411140729777.49c63054@Nodemailer> Message-ID: <541F2E48.7050806@gmail.com> Thanks that was a very illuminating example. As for iterating over pairs would it be possible to have an iterator that gives both: 1. A mutable reference to the next element 2. An iterator over the rest of the elements the idea would be to be able to write for (ele_i, rest) in list.iterator() { for ele_j in rest { do stuff } } silvio From danielmicay at gmail.com Sun Sep 21 13:12:16 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 21 Sep 2014 16:12:16 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: <541EA10D.2060003@exyr.org> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> Message-ID: <541F3120.1010602@gmail.com> On 21/09/14 05:57 AM, Simon Sapin wrote: > On 21/09/14 07:34, Daniel Micay wrote: >> It's not intended to be used for anything other than memory safety. > > It?s also used to maintain invariants, such as the bytes inside a String > being valid UTF-8: String::push_bytes() is unsafe, but > String::push_str() is not. No, it's not used to maintain invariants unrelated to memory safety. Strings assume the contents are UTF-8 and violating that invariant would violate memory safety. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From eg1290 at gmail.com Sun Sep 21 13:27:15 2014 From: eg1290 at gmail.com (Evan G) Date: Sun, 21 Sep 2014 16:27:15 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: <541F3120.1010602@gmail.com> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> Message-ID: Personally, I feel "safety" generalizes pretty well to "any concept that should be called out explicitly as unsafe"--not just memory safety. On Sun, Sep 21, 2014 at 4:12 PM, Daniel Micay wrote: > On 21/09/14 05:57 AM, Simon Sapin wrote: >> On 21/09/14 07:34, Daniel Micay wrote: >>> It's not intended to be used for anything other than memory safety. >> >> It?s also used to maintain invariants, such as the bytes inside a String >> being valid UTF-8: String::push_bytes() is unsafe, but >> String::push_str() is not. > > No, it's not used to maintain invariants unrelated to memory safety. > > Strings assume the contents are UTF-8 and violating that invariant would > violate memory safety. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From richo at psych0tik.net Sun Sep 21 16:33:22 2014 From: richo at psych0tik.net (richo) Date: Mon, 22 Sep 2014 00:33:22 +0100 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> Message-ID: <20140921233322.GA49514@xenia.local> On 21/09/14 16:27 -0400, Evan G wrote: >Personally, I feel "safety" generalizes pretty well to "any concept >that should be called out explicitly as unsafe"--not just memory >safety. > You can feel that all you want, but memory safety is reasonably straightforward to define in a general context, whereas eg, unsafe string interpolation of strings for a SQL query is not really the domain of the compiler itself (rather, a problem for the type system). See Go's html library for a bunch of hilarity when this goes sideways, particularly some of the debate around comment handling. From zwarich at mozilla.com Sun Sep 21 16:37:50 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Sun, 21 Sep 2014 16:37:50 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> Message-ID: On Sep 21, 2014, at 1:27 PM, Evan G wrote: > Personally, I feel "safety" generalizes pretty well to "any concept > that should be called out explicitly as unsafe"--not just memory > safety. The difference is that the current uses of `unsafe` are guarding things that cause a program to not have a defined meaning (ignoring the fact that Rust has no real semantics yet, so arguably no program has a defined meaning), whereas these other uses are for programs that have a defined meaning, just not the one that was intended. Cameron From danielmicay at gmail.com Sun Sep 21 16:40:31 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 21 Sep 2014 19:40:31 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> Message-ID: <541F61EF.10509@gmail.com> On 21/09/14 04:27 PM, Evan G wrote: > Personally, I feel "safety" generalizes pretty well to "any concept > that should be called out explicitly as unsafe"--not just memory > safety. That's not how Rust defines `unsafe`. It's open to misuse, and the compiler will happily point out that it's not being used correctly via the unnecessary unsafe lint. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From manishsmail at gmail.com Sun Sep 21 19:50:40 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Mon, 22 Sep 2014 08:20:40 +0530 Subject: [rust-dev] On the use of unsafe In-Reply-To: <541F61EF.10509@gmail.com> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: > That's not how Rust defines `unsafe`. It's open to misuse, and the > compiler will happily point out that it's not being used correctly via > the unnecessary unsafe lint. > If that's the case, do you think there's some worth in allowing the programmer to define arbitrary generic safety types? E.g have an `#[unsafe(strings)]` attribute that can be placed on methods that break String guarantees (and placed on blocks where we wish to allow such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If something like this slide was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities can have `#[unsafe(xss)]`. Rust does a bunch of compile time checking to achieve memory safety. It also provides a syntax extension/lint system that allows for programmers to define further compile time checks, which open up the gate for many more possible safety guarantees (instead of relying on separate static analysis tools), and not just memory safety. Perhaps we should start recognizing and leveraging that ability more :) -Manish Goregaokar -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldrich.vetesnik at gmail.com Mon Sep 22 08:20:15 2014 From: oldrich.vetesnik at gmail.com (=?utf-8?Q?Old=C5=99ich_Vete=C5=A1n=C3=ADk?=) Date: Mon, 22 Sep 2014 17:20:15 +0200 Subject: [rust-dev] Builders in Mustache Message-ID: <2477BB9C3B3A43E0A23FC1BE3E9EE422@gmail.com> Hello, does anybody here use Rust Mustache? If so, would you please take a look at this question? :-) https://stackoverflow.com/questions/25929640/can-i-use-loops-inside-a-rust-mustache-mapbuilder Thanks a million times, Ollie From matthieu.monrocq at gmail.com Mon Sep 22 09:40:06 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Mon, 22 Sep 2014 18:40:06 +0200 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: It's completely unnecessary actually. If a method requires a XSS-safe string, then it should take the XssSafeString parameter, which would implement Deref and would be built from a String by a method performing the necessary escaping. If a method requires a SQL-safe string... ah no, don't do that, use bind-parameters and you are guaranteed to be sql-injection safe. In each case, the attributes so defined can be perfectly replaced with appropriate types... so why not use types ? On Mon, Sep 22, 2014 at 4:50 AM, Manish Goregaokar wrote: > > That's not how Rust defines `unsafe`. It's open to misuse, and the >> compiler will happily point out that it's not being used correctly via >> the unnecessary unsafe lint. >> > > If that's the case, do you think there's some worth in allowing the > programmer to define arbitrary generic safety types? > > E.g have an `#[unsafe(strings)]` attribute that can be placed on methods > that break String guarantees (and placed on blocks where we wish to allow > such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If > something like this slide > > was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities > can have `#[unsafe(xss)]`. > > Rust does a bunch of compile time checking to achieve memory safety. It > also provides a syntax extension/lint system that allows for programmers to > define further compile time checks, which open up the gate for many more > possible safety guarantees (instead of relying on separate static analysis > tools), and not just memory safety. Perhaps we should start recognizing and > leveraging that ability more :) > > -Manish Goregaokar > > > _______________________________________________ > 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 wink at saville.com Mon Sep 22 09:46:33 2014 From: wink at saville.com (Wink Saville) Date: Mon, 22 Sep 2014 09:46:33 -0700 Subject: [rust-dev] Rust compiler for Risc-v Message-ID: I'm interested in writing deeply embedded low level Rust code for risc-v ( http://riscv.org/) that thus don't expect to need a significant runtime library. As such I expect to use #![no_std] and #![no_start]. Anyway, there is a risc-v "llvm compiler" ( http://riscv.org/download.html#tab_llvm) and it appears that rustc is an "llvm compiler". It seems with both being llvm I should be able to connect the Rust's llvm "frontend" to the risc-v "backend" and thus be able to generate Rust code for risc-v. Would love to know if Rust compiler people would think this is reasonably easy and if so what general guidance on how to do it. -- Wink -------------- next part -------------- An HTML attachment was scrubbed... URL: From manishsmail at gmail.com Mon Sep 22 10:16:32 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Mon, 22 Sep 2014 22:46:32 +0530 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: This had to do with XSS-proofing templates, which is a bit different and requires compile time magic. I've seen people concatenate strings while using prepared PDO queries in PHP -- nonnegotiable safety built in to the library is much better. This can't be handled with a type system. -Manish Goregaokar On Mon, Sep 22, 2014 at 10:10 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > It's completely unnecessary actually. > > If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref and would be > built from a String by a method performing the necessary escaping. > > If a method requires a SQL-safe string... ah no, don't do that, use > bind-parameters and you are guaranteed to be sql-injection safe. > > In each case, the attributes so defined can be perfectly replaced with > appropriate types... so why not use types ? > > > > On Mon, Sep 22, 2014 at 4:50 AM, Manish Goregaokar > wrote: > >> >> That's not how Rust defines `unsafe`. It's open to misuse, and the >>> compiler will happily point out that it's not being used correctly via >>> the unnecessary unsafe lint. >>> >> >> If that's the case, do you think there's some worth in allowing the >> programmer to define arbitrary generic safety types? >> >> E.g have an `#[unsafe(strings)]` attribute that can be placed on methods >> that break String guarantees (and placed on blocks where we wish to allow >> such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If >> something like this slide >> >> was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities >> can have `#[unsafe(xss)]`. >> >> Rust does a bunch of compile time checking to achieve memory safety. It >> also provides a syntax extension/lint system that allows for programmers to >> define further compile time checks, which open up the gate for many more >> possible safety guarantees (instead of relying on separate static analysis >> tools), and not just memory safety. Perhaps we should start recognizing and >> leveraging that ability more :) >> >> -Manish Goregaokar >> >> >> _______________________________________________ >> 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 bascule at gmail.com Mon Sep 22 10:39:54 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 22 Sep 2014 10:39:54 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: On Mon, Sep 22, 2014 at 9:40 AM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref and would be > built from a String by a method performing the necessary escaping. > This relies on all paths to XssSafeString being "safe" ones, which may be the case, but all it takes is a single chink in the armor for things to go amiss. I'd also note that "SafeString" is a terrible name and has lead to a lot of confusion in e.g. Ember.js. I'd suggest using "RawString" or "RawQuery", which is a lot more indicative of its actual contents. Having some sort of real taint analysis (or something akin to TS*'s Un type) to solve problems like this generically (i.e. tainted strings should not be used directly in any sort of templating would be a lot more interesting. Maybe in Rust 9.0 ;) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.zemtsov at gmail.com Mon Sep 22 01:32:25 2014 From: e.zemtsov at gmail.com (Eugene Zemtsov) Date: Mon, 22 Sep 2014 01:32:25 -0700 Subject: [rust-dev] trait implementations for references Message-ID: Hi All, I have just recently discovered that it is possible to provide a trait implementation for a reference type. This feature by itself seems to me very controversial. But it also leads to surprising dispatches when combined with argument matching for references. Consider following program: trait A { fn f(self); fn g(&self); } impl A for int { fn f(self) { println!("f() for int"); } fn g(&self) { println!("g() for int"); } } impl<'a> A for &'a int { fn f(self) { println!("f() for reference"); } fn g(&self) { println!("g() for reference"); } } fn main() { let one = 1i; let one_ref = &one; one_ref.f(); one_ref.g(); } The output of this program is f() for reference g() for int When I am analyzing this output, I can kinda understand how compiler finds "the most suitable" implementation. But this is still an example of a very tricky behavior we have so much of in C++. Is this a product of a conscious design decision or just a intermediate state of the language which is under construction? If it is by design, is there a place (RFC, github issue, mailing thread) where I can read a discussion about pros and cons of allowing separate trait implementations for references? P.S. If it matters my rust version is 0.12.0-pre-nightly (79a5448f4 2014-09-13 20:36:02 +0000) Thanks, Eugene Zemtsov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From masa.taku40 at gmail.com Sun Sep 21 01:10:30 2014 From: masa.taku40 at gmail.com (Taku Masa) Date: Sun, 21 Sep 2014 17:10:30 +0900 Subject: [rust-dev] type annotaion of &mut Message-ID: This is very simple code about mutable borrow. code1 is compiled, but code2 is not compiled. difference of them is `let b` has explicit type-annotation or not. In this case, why is explicit annotation needed? //code1 fn main(){ let a = &mut 10i; { let b:&mut int = a; *b = 11i; } println!("{}",a); } //code2 fn main(){ let a = &mut 10i; { let b = a; *b = 11i; } println!("{}",a); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Sep 22 10:54:44 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 22 Sep 2014 13:54:44 -0400 Subject: [rust-dev] type annotaion of &mut In-Reply-To: References: Message-ID: Because you need to make b mutable to change its value. Rust's variable bindings are immutable by default. From errordeveloper at gmail.com Mon Sep 22 11:31:46 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Mon, 22 Sep 2014 19:31:46 +0100 Subject: [rust-dev] Rust compiler for Risc-v In-Reply-To: References: Message-ID: Hi Wink, I would be interested to help with RISC-V port. In terms of slim runtime and other non-OS aspects, have you looked at Zinc yet? Cheers, -- Ilya On 22 Sep 2014 17:47, "Wink Saville" wrote: > I'm interested in writing deeply embedded low level Rust code for risc-v ( > http://riscv.org/) that thus don't expect to need a significant runtime > library. As such I expect to use #![no_std] and #![no_start]. > > Anyway, there is a risc-v "llvm compiler" ( > http://riscv.org/download.html#tab_llvm) and it appears that rustc is an > "llvm compiler". > > It seems with both being llvm I should be able to connect the Rust's llvm > "frontend" to the risc-v "backend" and thus be able to generate Rust code > for risc-v. > > Would love to know if Rust compiler people would think this is reasonably > easy and if so what general guidance on how to do it. > > -- Wink > > _______________________________________________ > 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 tkuehn at cmu.edu Mon Sep 22 11:35:53 2014 From: tkuehn at cmu.edu (Tim Kuehn) Date: Mon, 22 Sep 2014 11:35:53 -0700 Subject: [rust-dev] type annotaion of &mut In-Reply-To: References: Message-ID: That doesn't seem to be what the compilation error says: mut.rs:10:19: 10:20 error: use of moved value: `a` mut.rs:10 println!("{}",a); ^ note: in expansion of format_args! :2:23: 2:77 note: expansion site :1:1: 3:2 note: in expansion of println! mut.rs:10:5: 10:22 note: expansion site mut.rs:6:13: 6:14 note: `a` moved here because it has type `&mut int`, which is moved by default (use `ref` to override) mut.rs:6 let b = a; It isn't intuitive that type-annotating `b` would make this error go away. On Mon, Sep 22, 2014 at 10:54 AM, Steve Klabnik wrote: > Because you need to make b mutable to change its value. Rust's > variable bindings are immutable by default. > _______________________________________________ > 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 me at chrismorgan.info Mon Sep 22 12:21:29 2014 From: me at chrismorgan.info (Chris Morgan) Date: Mon, 22 Sep 2014 14:21:29 -0500 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: > It's completely unnecessary actually. Would that it were. There was a time when I believed it was, but it's not. > If a method requires a XSS-safe string, then it should take the XssSafeString parameter, which would implement Deref and would be built from a String by a method performing the necessary escaping. This sort of thing is the idea?building it all into the type system is the goal. The question was to do with getting around that, doing something that would *not* be safe. You can build as great a library with the type system as you like, but eventually someone will want?nay, need?an escape hatch. Perhaps they are dealing with a legacy system that, alas, requires broken behavior; or perhaps a performance issue with the normal way of doing it needs to be circumvented. This part, breaking the rules in a reasonable manner yet without it being so normal that everyone does it (*cough* PHP *cough*), is the part that was being discussed at that point. I consider `unsafe` to be entirely justified here because we're dealing with data being able to break the invariants of the type. If, for an arbitrary example, we have an HTML chunk we are going to emit and wish to insert something known to be legal HTML as we emit it, there are shortcuts that can be taken. But if it was not in fact legal HTML, the invariants of the type are broken and the interpretation of the data no longer certain. Thus it should be marked image, just like the UTF-8 constraint of strings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Sep 22 12:32:04 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 22 Sep 2014 15:32:04 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: <54207934.7050406@gmail.com> On 22/09/14 03:21 PM, Chris Morgan wrote: >> It's completely unnecessary actually. > Would that it were. There was a time when I believed it was, but it's not. > >> If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref and would > be built from a String by a method performing the necessary escaping. > This sort of thing is the idea?building it all into the type system is > the goal. The question was to do with getting around that, doing > something that would *not* be safe. You can build as great a library > with the type system as you like, but eventually someone will want?nay, > need?an escape hatch. Perhaps they are dealing with a legacy system > that, alas, requires broken behavior; or perhaps a performance issue > with the normal way of doing it needs to be circumvented. This part, > breaking the rules in a reasonable manner yet without it being so normal > that everyone does it (*cough* PHP *cough*), is the part that was being > discussed at that point. > > I consider `unsafe` to be entirely justified here because we're dealing > with data being able to break the invariants of the type. If, for an > arbitrary example, we have an HTML chunk we are going to emit and wish > to insert something known to be legal HTML as we emit it, there are > shortcuts that can be taken. But if it was not in fact legal HTML, the > invariants of the type are broken and the interpretation of the data no > longer certain. Thus it should be marked image, just like the UTF-8 > constraint of strings. Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It uses `unsafe` as a memory safety boundary, and in this case breaking the invariant would be memory unsafe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bombela at gmail.com Mon Sep 22 13:23:50 2014 From: bombela at gmail.com (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Bourlet?=) Date: Mon, 22 Sep 2014 13:23:50 -0700 Subject: [rust-dev] trait implementations for references In-Reply-To: References: Message-ID: Hi, My little understanding is that the compiler has some sort of priority on type inference depending of the kind of modification applied to the type in order to match anything. Rust can auto-deref on the "." operator and auto-borrow when passing to reference parameters, and I suspect that an auto-deref is of higher priority than an auto-borrow. But I might be very wrong! On Mon, Sep 22, 2014 at 1:32 AM, Eugene Zemtsov wrote: > Hi All, > > I have just recently discovered that it is possible to provide a trait > implementation for a reference type. > This feature by itself seems to me very controversial. But it also leads > to surprising dispatches when combined with argument matching for > references. > Consider following program: > > trait A { > fn f(self); > fn g(&self); > } > > impl A for int { > fn f(self) { > println!("f() for int"); > } > fn g(&self) { > println!("g() for int"); > } > } > > impl<'a> A for &'a int { > fn f(self) { > println!("f() for reference"); > } > fn g(&self) { > println!("g() for reference"); > } > } > > fn main() { > let one = 1i; > let one_ref = &one; > one_ref.f(); > one_ref.g(); > } > > > The output of this program is > > f() for reference > > g() for int > > > When I am analyzing this output, I can kinda understand how compiler finds > "the most suitable" implementation. > But this is still an example of a very tricky behavior we have so much of > in C++. > > Is this a product of a conscious design decision or just a intermediate > state of the language which is under construction? > If it is by design, is there a place (RFC, github issue, mailing thread) > where I can read a discussion about pros and cons of allowing separate > trait implementations for references? > > P.S. > If it matters my rust version is 0.12.0-pre-nightly (79a5448f4 2014-09-13 > 20:36:02 +0000) > > Thanks, > Eugene Zemtsov. > > _______________________________________________ > 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 bascule at gmail.com Mon Sep 22 14:12:14 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 22 Sep 2014 14:12:14 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: <54207934.7050406@gmail.com> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> Message-ID: On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay wrote: > Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It > uses `unsafe` as a memory safety boundary, and in this case breaking the > invariant would be memory unsafe. I just want to say that I completely agree with you that "unsafe" is the wrong tool for the job here. However there is still a problem I feel is potentially solved via type systems, not necessarily Rust's, only if Rust chooses to rise to the challenge. After 1.0 might be a good time to start considering these problems. I know you already have enough work on your plate as-is. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Sep 22 14:15:36 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 22 Sep 2014 17:15:36 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> Message-ID: <54209178.6030000@gmail.com> On 22/09/14 05:12 PM, Tony Arcieri wrote: > On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay > wrote: > > Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It > uses `unsafe` as a memory safety boundary, and in this case breaking the > invariant would be memory unsafe. > > > I just want to say that I completely agree with you that "unsafe" is the > wrong tool for the job here. > > However there is still a problem I feel is potentially solved via type > systems, not necessarily Rust's, only if Rust chooses to rise to the > challenge. > > After 1.0 might be a good time to start considering these problems. I > know you already have enough work on your plate as-is. I think it can be solved by using visibility, along with providing a way to override the visibility rules and call private functions. That means replacing the current usage of visibility for memory safety with unsafe fields though, but I think that's important to make the memory safety boundary work properly anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bascule at gmail.com Mon Sep 22 14:31:51 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 22 Sep 2014 14:31:51 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: <54209178.6030000@gmail.com> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> <54209178.6030000@gmail.com> Message-ID: On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay wrote: > I think it can be solved by using visibility, along with providing a way > to override the visibility rules and call private functions. That means > replacing the current usage of visibility for memory safety with unsafe > fields though, but I think that's important to make the memory safety > boundary work properly anyway. > Just to clarify what I see going on here and how other (type) systems have solved this: For things like XSS and SQLi, the problem is untrusted off-the-wire data being used in what is more or less a "secure" context. Some might refer to this sort of untrusted off-the-wire data as "tainted" and try to use some sort of taint analysis to solve the problem. The TS* dependent type system refers to it as "Un" (i.e. untrusted) and relies on its dependent type system to prove Un data isn't used in a secure context. Very fancy and possibly overkill, but that said, a pretty awesome solution to the problem. There is a *generic* problem here of using such untrusted data in any sort of templating or metalinguistic context. The general problem is OWASP #1: failure to sanitize input, affecting vulnerabilities like XSS, SQLi, and LDAP injection. I am absolutely certain this affects systems like Servo as well ;) Preventing untrusted data from penetrating the secure contexts of the program using the type system has the potential to mitigate the most common security vulnerabilities if done correctly. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From manishsmail at gmail.com Mon Sep 22 15:45:30 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Tue, 23 Sep 2014 04:15:30 +0530 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> <54209178.6030000@gmail.com> Message-ID: As Chris mentioned, it's not about using the type system to create safety. We're assuming that exists, the idea is to gate unchecked access to the data (which *is* required for libraries created for generic use) with the `unsafe` keyword. However, many seem to be of the opinion that `unsafe` is just for memory safety, in which case it would be nice to have a wider range of `unsafe` attributes (or something) which allow us to gate methods that are prone to SQL injection (etc etc). -Manish Goregaokar On Tue, Sep 23, 2014 at 3:01 AM, Tony Arcieri wrote: > On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay > wrote: > >> I think it can be solved by using visibility, along with providing a way >> to override the visibility rules and call private functions. That means >> replacing the current usage of visibility for memory safety with unsafe >> fields though, but I think that's important to make the memory safety >> boundary work properly anyway. >> > > Just to clarify what I see going on here and how other (type) systems have > solved this: > > For things like XSS and SQLi, the problem is untrusted off-the-wire data > being used in what is more or less a "secure" context. > > Some might refer to this sort of untrusted off-the-wire data as "tainted" > and try to use some sort of taint analysis to solve the problem. The TS* > dependent type system refers to it as "Un" (i.e. untrusted) and relies on > its dependent type system to prove Un data isn't used in a secure context. > Very fancy and possibly overkill, but that said, a pretty awesome solution > to the problem. > > There is a *generic* problem here of using such untrusted data in any sort > of templating or metalinguistic context. The general problem is OWASP #1: > failure to sanitize input, affecting vulnerabilities like XSS, SQLi, and > LDAP injection. > > I am absolutely certain this affects systems like Servo as well ;) > > Preventing untrusted data from penetrating the secure contexts of the > program using the type system has the potential to mitigate the most common > security vulnerabilities if done correctly. > > -- > Tony Arcieri > > _______________________________________________ > 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 bascule at gmail.com Mon Sep 22 15:52:33 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 22 Sep 2014 15:52:33 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> <54209178.6030000@gmail.com> Message-ID: On Mon, Sep 22, 2014 at 3:45 PM, Manish Goregaokar wrote: > As Chris mentioned, it's not about using the type system to create safety. > We're assuming that exists > The sort of safety I'm describing does not exist in Rust whatsoever AFAIK. The very specific approach I'm referring to depends on dependent types, which Rust does not implement, and I would suggest you look to for future, post-1.0 food for thought: https://research.microsoft.com/en-us/um/people/nswamy/papers/gradual-typing-embedded-securely-in-javascript-draft.pdf the idea is to gate unchecked access to the data (which *is* required for > libraries created for generic use) with the `unsafe` keyword. > Many, including myself, have expressed the opinion that "unsafe" is ill-suited to this sort of safety-by-taint analysis and security contexts. In my OP, I suggested it was colluding concerns. This, again, goes back to Chris Morgan's Strange Loop talk. I may be misinterpreting what he was suggesting too, it'd be great to hear from him directly! I think there needs to be a different security context for these sorts of problems. > However, many seem to be of the opinion that `unsafe` is just for memory > safety, in which case it would be nice to have a wider range of `unsafe` > attributes (or something) which allow us to gate methods that are prone to > SQL injection (etc etc). > Yes, however the cases of SQLi, XSS, and LDAP injection all depend on using untrusted data in trusted contexts, which is a fundamentally different problem from what Rust is trying to solve with "unsafe", and the solutions the type system should pursue to solve these problems are different. All that said, even in the absence of a dependent type system, I think Rust can *being* to call these cases out in advance, if only for the benefit of human code review, but with the goal of the eventual inclusion of something in the type system to formally verify these sorts of guarantees. The specific use case is quite clear to me: inclusion of tainted data in secure strings. There are many systems today in which this would be an error. I can totally understand omitting these sorts of things until there is a formal correctness check in the complier. At the same time, these are the sorts of cases I feel need to be called out while they're fresh in people's minds. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Sep 22 16:31:17 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 22 Sep 2014 19:31:17 -0400 Subject: [rust-dev] On the use of unsafe In-Reply-To: References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> <54209178.6030000@gmail.com> Message-ID: <5420B145.6090706@gmail.com> On 22/09/14 06:45 PM, Manish Goregaokar wrote: > As Chris mentioned, it's not about using the type system to create > safety. We're assuming that exists, the idea is to gate unchecked access > to the data (which /is/ required for libraries created for generic use) > with the `unsafe` keyword. However, many seem to be of the opinion that > `unsafe` is just for memory safety, in which case it would be nice to > have a wider range of `unsafe` attributes (or something) which allow us > to gate methods that are prone to SQL injection (etc etc). > > -Manish Goregaokar It's not an opinion, it's how it's defined in the documentation (see the Rust manual) and the compiler warns about unnecessary usage of `unsafe` - which could be finished if there were `unsafe` fields. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From manishsmail at gmail.com Mon Sep 22 18:02:00 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Tue, 23 Sep 2014 06:32:00 +0530 Subject: [rust-dev] On the use of unsafe In-Reply-To: <5420B145.6090706@gmail.com> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <54207934.7050406@gmail.com> <54209178.6030000@gmail.com> <5420B145.6090706@gmail.com> Message-ID: I'm not talking about unsafe fields. (maybe I gave that impression? Sorry.) That's how it is defined in the manual, sure, but the language is changing :) Anyway, as mentioned before we don't need to use `unsafe` for non-memory safety guarantees, if we define anothe attribute that genericises it. -Manish Goregaokar On Tue, Sep 23, 2014 at 5:01 AM, Daniel Micay wrote: > On 22/09/14 06:45 PM, Manish Goregaokar wrote: > > As Chris mentioned, it's not about using the type system to create > > safety. We're assuming that exists, the idea is to gate unchecked access > > to the data (which /is/ required for libraries created for generic use) > > with the `unsafe` keyword. However, many seem to be of the opinion that > > `unsafe` is just for memory safety, in which case it would be nice to > > have a wider range of `unsafe` attributes (or something) which allow us > > to gate methods that are prone to SQL injection (etc etc). > > > > -Manish Goregaokar > > It's not an opinion, it's how it's defined in the documentation (see the > Rust manual) and the compiler warns about unnecessary usage of `unsafe` > - which could be finished if there were `unsafe` fields. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Mon Sep 22 18:30:33 2014 From: wink at saville.com (Wink Saville) Date: Mon, 22 Sep 2014 18:30:33 -0700 Subject: [rust-dev] Rust compiler for Risc-v In-Reply-To: References: Message-ID: Thanks for the heads up on Zinc , looks to be originally announced on this list here and its github page is here . So I happy to see someone else is interested in rust on riscv. I know nothing about llvm so I hope we'll see some advice from some knowledgable people to give us some guidance. But if nothing is forth coming, I suggest we start with the following tasks: 1. Get sources for both Rust and Risc-v compilers and build them locally validating both "work". 2. Create one github project with both sources in two different source trees and again validate both "work" 3. Learn how LLVM frontend/backends communicate 4. Work to combine the Rust Frontend with the Risc-v backend 5. Iterate over 3 and 4 until we have a working Rust compiler for Risc-V A first question is where is the current compilers. On the main github rust page there is a link to rust-lang/llvm , but that link seems to point to something that was last updated in April 2014. Instead if you go to rust-lang/rust/src and then click on the submodule "llvm @ e9d0374 " you're at a commit that was 23 days ago. So for Rust it looks like we should clone the rust-lang/rust . On the main githug riscv page there is a link to riscv-llvm. with the last commit from August 19, so that probably good. We could start with one of us getting Rust working and the other getting Risc-v, which would you like to do or maybe you have a different suggestion on how to proceed? -- Wink -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Tue Sep 23 07:25:11 2014 From: wink at saville.com (Wink Saville) Date: Tue, 23 Sep 2014 07:25:11 -0700 Subject: [rust-dev] Rust compiler for Risc-v In-Reply-To: References: Message-ID: So after some more research, maybe we can use "rustc --emit=ir" or --emit=bc and then feed the output file to "llc" in the riscv compiler tool chain. On Sep 22, 2014 6:30 PM, "Wink Saville" wrote: > > Thanks for the heads up on Zinc , looks to be originally > announced on this list here > and > its github page is here . So I happy > to see someone else is interested in rust on riscv. I know nothing about > llvm so I hope we'll see some advice from some knowledgable people to give > us some guidance. > > But if nothing is forth coming, I suggest we start with the following > tasks: > > 1. Get sources for both Rust and Risc-v compilers and build them locally > validating both "work". > 2. Create one github project with both sources in two different source > trees and again validate both "work" > 3. Learn how LLVM frontend/backends communicate > 4. Work to combine the Rust Frontend with the Risc-v backend > 5. Iterate over 3 and 4 until we have a working Rust compiler for Risc-V > > A first question is where is the current compilers. On the main github > rust page > there is a link to rust-lang/llvm , but > that link seems to point to something that > was last updated in April 2014. Instead if you go to rust-lang/rust/src > and then click > on the submodule "llvm @ e9d0374 > " > you're at a commit that was 23 days ago. > So for Rust it looks like we should clone the rust-lang/rust > . > > On the main githug riscv page there is a > link to riscv-llvm. with the last > commit > from August 19, so that probably good. > > We could start with one of us getting Rust working and the other getting > Risc-v, > which would you like to do or maybe you have a different suggestion on how > to proceed? > > -- Wink > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clements at brinckerhoff.org Wed Sep 24 08:30:41 2014 From: clements at brinckerhoff.org (John Clements) Date: Wed, 24 Sep 2014 08:30:41 -0700 Subject: [rust-dev] Can macro use variable values? In-Reply-To: References: Message-ID: <760BD264-D6DA-4B17-9F7A-769275613266@brinckerhoff.org> On Sep 17, 2014, at 7:04 AM, Daneel Yaitskov wrote: > Hi, > > > Does Rust macro have flow control based on a variable value? > > I didn't find such info here http://doc.rust-lang.org/guide-macros.html. > > I'd like to get a macro expading a for loop. > > doTimes(3, println!("DDDD")) > => > println!("DDDD") > println!("DDDD") > println!("DDDD?) Perhaps I?m misunderstanding you, but in general that?s impossible. Specifically, variable varues aren?t known at runtime. So, for instance, if you wrote doTimes(x, println!(?DDDD?)) ? there?s no way (in general) to know the value of ?x? until the program is run. Is there some reason you can?t just use a function call, here? John Clements From eg1290 at gmail.com Wed Sep 24 08:59:21 2014 From: eg1290 at gmail.com (Evan G) Date: Wed, 24 Sep 2014 11:59:21 -0400 Subject: [rust-dev] Can macro use variable values? In-Reply-To: <760BD264-D6DA-4B17-9F7A-769275613266@brinckerhoff.org> References: <760BD264-D6DA-4B17-9F7A-769275613266@brinckerhoff.org> Message-ID: The thought is that you should be able to do it with static variables (ones that are known at compile time, like his example) This is known as Compile Time Function Evaluation, I know there's been some work on it, and you can probably search the RFCs to figure out the status currently. On Wed, Sep 24, 2014 at 11:30 AM, John Clements wrote: > > On Sep 17, 2014, at 7:04 AM, Daneel Yaitskov wrote: > >> Hi, >> >> >> Does Rust macro have flow control based on a variable value? >> >> I didn't find such info here http://doc.rust-lang.org/guide-macros.html. >> >> I'd like to get a macro expading a for loop. >> >> doTimes(3, println!("DDDD")) >> => >> println!("DDDD") >> println!("DDDD") >> println!("DDDD?) > > Perhaps I?m misunderstanding you, but in general that?s impossible. Specifically, variable varues aren?t known at runtime. So, for instance, if you wrote > > doTimes(x, println!(?DDDD?)) > > ? there?s no way (in general) to know the value of ?x? until the program is run. > > Is there some reason you can?t just use a function call, here? > > John Clements > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From fredrik.widlund at gmail.com Thu Sep 25 12:17:42 2014 From: fredrik.widlund at gmail.com (Fredrik Widlund) Date: Thu, 25 Sep 2014 21:17:42 +0200 Subject: [rust-dev] Timing vector inserts Message-ID: http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ (disclaimer: *not* about comparing languages and claiming language X is "better" than language Y) Kind regards, Fredrik Widlund -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Thu Sep 25 12:33:03 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 25 Sep 2014 12:33:03 -0700 (PDT) Subject: [rust-dev] Timing vector inserts In-Reply-To: References: Message-ID: <1411673583151.1f8a85a@Nodemailer> I sent a pull request, but the tl;dr of it is that the rust version was run without optimizations turned on. On Thu, Sep 25, 2014 at 12:17 PM, Fredrik Widlund wrote: > http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ > (disclaimer: *not* about comparing languages and claiming language X is > "better" than language Y) > Kind regards, > Fredrik Widlund -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik.widlund at gmail.com Thu Sep 25 12:37:47 2014 From: fredrik.widlund at gmail.com (Fredrik Widlund) Date: Thu, 25 Sep 2014 21:37:47 +0200 Subject: [rust-dev] Timing vector inserts In-Reply-To: <1411673583151.1f8a85a@Nodemailer> References: <1411673583151.1f8a85a@Nodemailer> Message-ID: Great, thanks! Will update asap. F On Thu, Sep 25, 2014 at 9:33 PM, Clark Gaebel wrote: > I sent a pull request, but the tl;dr of it is that the rust version was > run without optimizations turned on. > > > > On Thu, Sep 25, 2014 at 12:17 PM, Fredrik Widlund < > fredrik.widlund at gmail.com> wrote: > >> >> http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ >> >> (disclaimer: *not* about comparing languages and claiming language X is >> "better" than language Y) >> >> Kind regards, >> Fredrik Widlund >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Sep 25 15:59:48 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 25 Sep 2014 18:59:48 -0400 Subject: [rust-dev] Timing vector inserts In-Reply-To: References: Message-ID: <54249E64.1090800@gmail.com> On 25/09/14 03:17 PM, Fredrik Widlund wrote: > http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ > > (disclaimer: *not* about comparing languages and claiming language X is > "better" than language Y) > > Kind regards, > Fredrik Widlund https://github.com/jemalloc/jemalloc/issues/126 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From cg.wowus.cg at gmail.com Thu Sep 25 16:05:38 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 25 Sep 2014 16:05:38 -0700 (PDT) Subject: [rust-dev] Timing vector inserts In-Reply-To: <54249E64.1090800@gmail.com> References: <54249E64.1090800@gmail.com> Message-ID: <1411686338083.81e6c513@Nodemailer> You?re also timing two pushes, as opposed to a push and an array write in the C version. On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay wrote: > On 25/09/14 03:17 PM, Fredrik Widlund wrote: >> http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ >> >> (disclaimer: *not* about comparing languages and claiming language X is >> "better" than language Y) >> >> Kind regards, >> Fredrik Widlund > https://github.com/jemalloc/jemalloc/issues/126 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bombela at gmail.com Thu Sep 25 18:18:59 2014 From: bombela at gmail.com (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Bourlet?=) Date: Thu, 25 Sep 2014 18:18:59 -0700 Subject: [rust-dev] Timing vector inserts In-Reply-To: <1411686338083.81e6c513@Nodemailer> References: <54249E64.1090800@gmail.com> <1411686338083.81e6c513@Nodemailer> Message-ID: On my machine I get: C: 100000000,0.509391 rust: 100000000,0.466069 So rust is faster for me. For fun, I tried to write the rust version using unsafe and pre-allocation to remove the second push: let mut m = Vec::from_fn(101, |_| 0); let pm = m.as_mut_ptr(); let mut m_idx = 1i; let t = time::precise_time_ns(); for _i in iter::range_step(0, n, n/100) { for j in range(0, n/100) { v.push(j); } unsafe { ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t); } m_idx += 1; } But I get a little slower result (maybe I am doing something wrong with the unsafe and ptr): rust2: 100000000,0.472749 And just to be sure, I tested getting rid of iterators (using manual while loop instead) and this changed nothing (as expected). my 2 cents On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel wrote: > You?re also timing two pushes, as opposed to a push and an array write in > the C version. > > > > On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay wrote: >> >> > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From bombela at gmail.com Thu Sep 25 18:26:56 2014 From: bombela at gmail.com (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Bourlet?=) Date: Thu, 25 Sep 2014 18:26:56 -0700 Subject: [rust-dev] Timing vector inserts In-Reply-To: References: <54249E64.1090800@gmail.com> <1411686338083.81e6c513@Nodemailer> Message-ID: and hitting reply-all is better... quick update: the implementation with unsafe & ptr is not slower. I just have too many cores + power-boost to get a clean benchmark every time. Running the benchs with n=1 billions (instead of 100 millions) gives me: ==> vector_grow_c.csv <== 1000000000,5.084604 ==> vector_grow_rust.csv <== 1000000000,5.217096 ==> vector_grow_rust2.csv <== 1000000000,4.912147 (yes, getting rid of the second push works!) $ rustc --version rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +0000) $ gcc --version gcc (GCC) 4.9.1 On Thu, Sep 25, 2014 at 6:18 PM, Fran?ois-Xavier Bourlet wrote: > On my machine I get: > > C: 100000000,0.509391 > rust: 100000000,0.466069 > > So rust is faster for me. > > For fun, I tried to write the rust version using unsafe and > pre-allocation to remove the second push: > > let mut m = Vec::from_fn(101, |_| 0); > let pm = m.as_mut_ptr(); > let mut m_idx = 1i; > let t = time::precise_time_ns(); > for _i in iter::range_step(0, n, n/100) { > for j in range(0, n/100) { > v.push(j); > } > unsafe { > ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t); > } > m_idx += 1; > } > > But I get a little slower result (maybe I am doing something wrong > with the unsafe and ptr): > rust2: 100000000,0.472749 > > And just to be sure, I tested getting rid of iterators (using manual > while loop instead) and this changed nothing (as expected). > > my 2 cents > > > On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel wrote: >> You?re also timing two pushes, as opposed to a push and an array write in >> the C version. >> >> >> >> On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay wrote: >>> >>> >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> From cg.wowus.cg at gmail.com Thu Sep 25 21:30:50 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 25 Sep 2014 21:30:50 -0700 (PDT) Subject: [rust-dev] Timing vector inserts In-Reply-To: References: Message-ID: <1411705850175.9b5aba08@Nodemailer> Another problem I noticed is that the elements in the vector in the rust code are `uint` (which on most systems is 64-bit) and in the C code you?re inserting `int`s (32-bits on most systems). That?s not really a fair contest. ? - Clark On Thu, Sep 25, 2014 at 6:26 PM, Fran?ois-Xavier Bourlet wrote: > and hitting reply-all is better... > quick update: the implementation with unsafe & ptr is not slower. I > just have too many cores + power-boost to get a clean benchmark every > time. > Running the benchs with n=1 billions (instead of 100 millions) gives me: > ==> vector_grow_c.csv <== > 1000000000,5.084604 > ==> vector_grow_rust.csv <== > 1000000000,5.217096 > ==> vector_grow_rust2.csv <== > 1000000000,4.912147 (yes, getting rid of the second push works!) > $ rustc --version > rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +0000) > $ gcc --version > gcc (GCC) 4.9.1 > On Thu, Sep 25, 2014 at 6:18 PM, Fran?ois-Xavier Bourlet > wrote: >> On my machine I get: >> >> C: 100000000,0.509391 >> rust: 100000000,0.466069 >> >> So rust is faster for me. >> >> For fun, I tried to write the rust version using unsafe and >> pre-allocation to remove the second push: >> >> let mut m = Vec::from_fn(101, |_| 0); >> let pm = m.as_mut_ptr(); >> let mut m_idx = 1i; >> let t = time::precise_time_ns(); >> for _i in iter::range_step(0, n, n/100) { >> for j in range(0, n/100) { >> v.push(j); >> } >> unsafe { >> ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t); >> } >> m_idx += 1; >> } >> >> But I get a little slower result (maybe I am doing something wrong >> with the unsafe and ptr): >> rust2: 100000000,0.472749 >> >> And just to be sure, I tested getting rid of iterators (using manual >> while loop instead) and this changed nothing (as expected). >> >> my 2 cents >> >> >> On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel wrote: >>> You?re also timing two pushes, as opposed to a push and an array write in >>> the C version. >>> >>> >>> >>> On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay wrote: >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 me at nongraphical.com Thu Sep 25 23:05:46 2014 From: me at nongraphical.com (Frank Huang) Date: Thu, 25 Sep 2014 23:05:46 -0700 Subject: [rust-dev] How to pass NULL to a function pointer in Rust? Message-ID: Hello, I'd like to ask a naive question about Rust/C FFI. Say I have a C struct which, among other things, has a function pointer: #[repr(C)] struct CStruct { data: libc::c_int, callback: extern fn(libc::uint8_t) } And I would like to create an instance of this struct, but I would like to make that function pointer be NULL. How should I set the callback field of the struct so that C functions see a NULL pointer there? I have tried: let cs = CStruct { data: 0, callback: ptr::null(), }; As well as: let cs = CStruct { data: 0, callback: mem::transmute(ptr::null()), }; But both give compile errors. Any pointers (heh) about this problem? Thanks for your help! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From laden at csclub.uwaterloo.ca Thu Sep 25 23:12:05 2014 From: laden at csclub.uwaterloo.ca (Luqman Aden) Date: Fri, 26 Sep 2014 02:12:05 -0400 Subject: [rust-dev] How to pass NULL to a function pointer in Rust? In-Reply-To: References: Message-ID: <8E58DCFA-3E9D-465E-B09E-4A4307AD2437@csclub.uwaterloo.ca> You would use an Option and then just pass None. So something like: #[repr(C)] struct CStruct { data: libc::c_int, callback: Option } On Sep 26, 2014, at 2:05 AM, Frank Huang wrote: > Hello, > > I'd like to ask a naive question about Rust/C FFI. Say I have a C struct which, among other things, has a function pointer: > > #[repr(C)] > struct CStruct { > data: libc::c_int, > callback: extern fn(libc::uint8_t) > } > > And I would like to create an instance of this struct, but I would like to make that function pointer be NULL. How should I set the callback field of the struct so that C functions see a NULL pointer there? I have tried: > > let cs = CStruct { > data: 0, > callback: ptr::null(), > }; > > As well as: > > let cs = CStruct { > data: 0, > callback: mem::transmute(ptr::null()), > }; > > But both give compile errors. Any pointers (heh) about this problem? > > Thanks for your help! > > Frank > _______________________________________________ > 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 bombela at gmail.com Fri Sep 26 12:21:02 2014 From: bombela at gmail.com (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Bourlet?=) Date: Fri, 26 Sep 2014 12:21:02 -0700 Subject: [rust-dev] Timing vector inserts In-Reply-To: <1411705850175.9b5aba08@Nodemailer> References: <1411705850175.9b5aba08@Nodemailer> Message-ID: with i32 for rust: (I am on x86_64) ==> vector_grow_c.csv <== 1000000000,4.741286 ==> vector_grow_rust.csv <== 1000000000,3.147506 ==> vector_grow_rust2.csv <== 1000000000,3.153482 On Thu, Sep 25, 2014 at 9:30 PM, Clark Gaebel wrote: > Another problem I noticed is that the elements in the vector in the rust > code are `uint` (which on most systems is 64-bit) and in the C code you?re > inserting `int`s (32-bits on most systems). > > That?s not really a fair contest. > > - Clark > > > > On Thu, Sep 25, 2014 at 6:26 PM, Fran?ois-Xavier Bourlet > wrote: >> >> and hitting reply-all is better... >> >> quick update: the implementation with unsafe & ptr is not slower. I >> just have too many cores + power-boost to get a clean benchmark every >> time. >> Running the benchs with n=1 billions (instead of 100 millions) gives me: >> >> >> ==> vector_grow_c.csv <== >> 1000000000,5.084604 >> >> ==> vector_grow_rust.csv <== >> 1000000000,5.217096 >> >> ==> vector_grow_rust2.csv <== >> 1000000000,4.912147 (yes, getting rid of the second push works!) >> >> $ rustc --version >> rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +0000) >> $ gcc --version >> gcc (GCC) 4.9.1 >> >> On Thu, Sep 25, 2014 at 6:18 PM, Fran?ois-Xavier Bourlet >> wrote: >> > On my machine I get: >> > >> > C: 100000000,0.509391 >> > rust: 100000000,0.466069 >> > >> > So rust is faster for me. >> > >> > For fun, I tried to write the rust version using unsafe and >> > pre-allocation to remove the second push: >> > >> > let mut m = Vec::from_fn(101, |_| 0); >> > let pm = m.as_mut_ptr(); >> > let mut m_idx = 1i; >> > let t = time::precise_time_ns(); >> > for _i in iter::range_step(0, n, n/100) { >> > for j in range(0, n/100) { >> > v.push(j); >> > } >> > unsafe { >> > ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t); >> > } >> > m_idx += 1; >> > } >> > >> > But I get a little slower result (maybe I am doing something wrong >> > with the unsafe and ptr): >> > rust2: 100000000,0.472749 >> > >> > And just to be sure, I tested getting rid of iterators (using manual >> > while loop instead) and this changed nothing (as expected). >> > >> > my 2 cents >> > >> > >> > On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel >> > wrote: >> >> You?re also timing two pushes, as opposed to a push and an array write >> >> in >> >> the C version. >> >> >> >> >> >> >> >> On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay >> >> wrote: >> >>> >> >>> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > From yousuffauzan at gmail.com Fri Sep 26 21:07:12 2014 From: yousuffauzan at gmail.com (Yousuf Fauzan) Date: Fri, 26 Sep 2014 21:07:12 -0700 Subject: [rust-dev] Rust on CodeBunk Message-ID: Hi Guys, Just wanted to let you all know that CodeBunk (http://codebunk.com) now supports Rust. Do check it out. -- Yousuf Fauzan CodeBunk CodeBunk provides a Realtime Collaborative Editor with Compile/Run and REPL shells. CodeBunk is an Online Compiler/Interpreter for *Rust*, R, Coffeescript, Scala, PHP, Python, Ruby, Perl, Lua, Javascript, C, C++, Java, Erlang, Haskell, Julia, Clojure, Go. CodeBunk also has Peer-to-Peer Video/Audio chat facility. CodeBunk is ideal for Online Interview of Developers as well as Learning to code from Friends. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik.widlund at gmail.com Sat Sep 27 03:44:56 2014 From: fredrik.widlund at gmail.com (Fredrik Widlund) Date: Sat, 27 Sep 2014 12:44:56 +0200 Subject: [rust-dev] Timing vector inserts In-Reply-To: References: <1411705850175.9b5aba08@Nodemailer> Message-ID: Hi, The benchmarks are updated since a while back, all versions use 64 bit values, and there are different versions for jemalloc and the glibc allocator (for Rust and C). As noted by Daniel Micay the most important factor here will be the memory allocator. Rust builds with jemalloc by default, which compared to the glibc allocator on my Linux system is about twice as slow. Without knowing anything about your system a likely cause could be that the allocator used for the C version on your system is not the glibc allocator. The timing operation is run every 1/10^6 iteration (or 1/10^7 in your case), so optimizing it should not typically change the result. F On Fri, Sep 26, 2014 at 9:21 PM, Fran?ois-Xavier Bourlet wrote: > with i32 for rust: > (I am on x86_64) > > ==> vector_grow_c.csv <== > 1000000000,4.741286 > > ==> vector_grow_rust.csv <== > 1000000000,3.147506 > > ==> vector_grow_rust2.csv <== > 1000000000,3.153482 > > On Thu, Sep 25, 2014 at 9:30 PM, Clark Gaebel > wrote: > > Another problem I noticed is that the elements in the vector in the rust > > code are `uint` (which on most systems is 64-bit) and in the C code > you?re > > inserting `int`s (32-bits on most systems). > > > > That?s not really a fair contest. > > > > - Clark > > > > > > > > On Thu, Sep 25, 2014 at 6:26 PM, Fran?ois-Xavier Bourlet < > bombela at gmail.com> > > wrote: > >> > >> and hitting reply-all is better... > >> > >> quick update: the implementation with unsafe & ptr is not slower. I > >> just have too many cores + power-boost to get a clean benchmark every > >> time. > >> Running the benchs with n=1 billions (instead of 100 millions) gives me: > >> > >> > >> ==> vector_grow_c.csv <== > >> 1000000000,5.084604 > >> > >> ==> vector_grow_rust.csv <== > >> 1000000000,5.217096 > >> > >> ==> vector_grow_rust2.csv <== > >> 1000000000,4.912147 (yes, getting rid of the second push works!) > >> > >> $ rustc --version > >> rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +0000) > >> $ gcc --version > >> gcc (GCC) 4.9.1 > >> > >> On Thu, Sep 25, 2014 at 6:18 PM, Fran?ois-Xavier Bourlet > >> wrote: > >> > On my machine I get: > >> > > >> > C: 100000000,0.509391 > >> > rust: 100000000,0.466069 > >> > > >> > So rust is faster for me. > >> > > >> > For fun, I tried to write the rust version using unsafe and > >> > pre-allocation to remove the second push: > >> > > >> > let mut m = Vec::from_fn(101, |_| 0); > >> > let pm = m.as_mut_ptr(); > >> > let mut m_idx = 1i; > >> > let t = time::precise_time_ns(); > >> > for _i in iter::range_step(0, n, n/100) { > >> > for j in range(0, n/100) { > >> > v.push(j); > >> > } > >> > unsafe { > >> > ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t); > >> > } > >> > m_idx += 1; > >> > } > >> > > >> > But I get a little slower result (maybe I am doing something wrong > >> > with the unsafe and ptr): > >> > rust2: 100000000,0.472749 > >> > > >> > And just to be sure, I tested getting rid of iterators (using manual > >> > while loop instead) and this changed nothing (as expected). > >> > > >> > my 2 cents > >> > > >> > > >> > On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel > >> > wrote: > >> >> You?re also timing two pushes, as opposed to a push and an array > write > >> >> in > >> >> the C version. > >> >> > >> >> > >> >> > >> >> On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay > > >> >> wrote: > >> >>> > >> >>> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 alan.andradec at gmail.com Sat Sep 27 15:30:34 2014 From: alan.andradec at gmail.com (Alan Andrade) Date: Sat, 27 Sep 2014 15:30:34 -0700 Subject: [rust-dev] Rust Learning Group In-Reply-To: References: Message-ID: <19626836-8BB3-4DD3-B46D-95B945795A22@gmail.com> Hey Rusties, As I said in the last Meetup, I've renamed the group "Rust Bay Area Hacknights? to "Rust Learning Group?. Check it out here: http://www.meetup.com/Rust-Learning-Group/ I decided to choose a name that was generic enough so that the events can happen anywhere. You?re encouraged to run a meetup using this group. I wanted to switch the name since the idea from the beginning was to get people together with the main purpose of learning, not to code as if there was no tomorrow. Please spread the word and follow https://twitter.com/rust_learning if you want to stay tuned. Please share the topics you would like to see in Rust Learning Group. Thanks. - Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Sat Sep 27 18:54:28 2014 From: wink at saville.com (Wink Saville) Date: Sat, 27 Sep 2014 18:54:28 -0700 Subject: [rust-dev] Async Message passing. Message-ID: I'd like to have one API which would allow sending/receiving messages asynchronously, safely and efficiently over any transport and should work for components that run in the same thread, different threads, different processes or between devices which might be connected via any arbitrary hardware. Has any such API been developed? -- wink -------------- next part -------------- An HTML attachment was scrubbed... URL: From ike.braun at googlemail.com Mon Sep 29 03:04:27 2014 From: ike.braun at googlemail.com (Heiko Braun) Date: Mon, 29 Sep 2014 12:04:27 +0200 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: I havn't looked at it in detail, but nanomsg [1] seems to cover these requirements. There's a rust binding [2] available too. Regards, Heiko [1] http://nanomsg.org [2] https://github.com/thehydroimpulse/nanomsg.rs On 28 Sep 2014, at 03:54, Wink Saville wrote: > I'd like to have one API which would allow sending/receiving messages asynchronously, safely and efficiently over any transport and should work for components that run in the same thread, different threads, different processes or between devices which might be connected via any arbitrary hardware. > > Has any such API been developed? > > -- wink > > _______________________________________________ > 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 wink at saville.com Mon Sep 29 13:01:03 2014 From: wink at saville.com (Wink Saville) Date: Mon, 29 Sep 2014 13:01:03 -0700 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: Nanomsg looks interesting and I'll take a closer look. But I'm interested in a pure rust implementation of async messaging because I'd like to create an embedded OS using rust and not use C if possible. I been thinking about the problem and one of the questions I have is how to transfer ownership of a pointer from one entity to another. Not borrow but actually transfer ownership. So if I "allocated" a Message in one entity then send it to another I want the receiver to "free" the Message. Does the rust ownership model allow ownership to be transferred? -- Wink On Sep 29, 2014 3:04 AM, "Heiko Braun" wrote: > I havn't looked at it in detail, but nanomsg [1] seems to cover these > requirements. There's a rust binding [2] available too. > > Regards, Heiko > > [1] http://nanomsg.org > [2] https://github.com/thehydroimpulse/nanomsg.rs > > > > On 28 Sep 2014, at 03:54, Wink Saville wrote: > > I'd like to have one API which would allow sending/receiving messages > asynchronously, safely and efficiently over any transport and should work > for components that run in the same thread, different threads, different > processes or between devices which might be connected via any arbitrary > hardware. > > Has any such API been developed? > > -- wink > _______________________________________________ > 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 paul at colomiets.name Mon Sep 29 13:10:50 2014 From: paul at colomiets.name (Paul Colomiets) Date: Mon, 29 Sep 2014 23:10:50 +0300 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: Hi, On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville wrote: > Nanomsg looks interesting and I'll take a closer look. But I'm interested in > a pure rust implementation of async messaging because I'd like to create an > embedded OS using rust and not use C if possible. > I think even if there will be nanomsg implementation in pure rust, that would probably require rust stdlib, which is usually not used for embedded purposes, right? > I been thinking about the problem and one of the questions I have is how to > transfer ownership of a pointer from one entity to another. Not borrow but > actually transfer ownership. So if I "allocated" a Message in one entity > then send it to another I want the receiver to "free" the Message. > > Does the rust ownership model allow ownership to be transferred? > Sure, you can just send Vec of bytes or any other rust object though the channel (just like almost any rust object). And semantics is just like you described. You can also use Arc> that allows to use that message in several places simultaneously (e.g. if you want publish-subscribe) -- Paul From bascule at gmail.com Mon Sep 29 14:03:16 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 29 Sep 2014 14:03:16 -0700 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: On Mon, Sep 29, 2014 at 1:01 PM, Wink Saville wrote: > Nanomsg looks interesting and I'll take a closer look. But I'm interested > in a pure rust implementation of async messaging because I'd like to create > an embedded OS using rust and not use C if possible > You might take a look at capnproto-rust: https://github.com/dwrensha/capnproto-rust It doesn't support asynchronous messaging (yet) but it is planned. That said it supports an RPC system that's fully asynchronous under the covers, so async messaging becomes effectively "disregard the response" It also provides a typed description language for messages that maps nicely to Rust's type system. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Mon Sep 29 21:46:08 2014 From: wink at saville.com (Wink Saville) Date: Mon, 29 Sep 2014 21:46:08 -0700 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: On Mon, Sep 29, 2014 at 1:10 PM, Paul Colomiets wrote: > Hi, > > On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville wrote: > > Nanomsg looks interesting and I'll take a closer look. But I'm > interested in > > a pure rust implementation of async messaging because I'd like to create > an > > embedded OS using rust and not use C if possible. > > > > I think even if there will be nanomsg implementation in pure rust, > that would probably require rust stdlib, which is usually not used for > embedded purposes, right? > > > I been thinking about the problem and one of the questions I have is how > to > > transfer ownership of a pointer from one entity to another. Not borrow > but > > actually transfer ownership. So if I "allocated" a Message in one entity > > then send it to another I want the receiver to "free" the Message. > > > > > > Does the rust ownership model allow ownership to be transferred? > > > > Sure, you can just send Vec of bytes or any other rust object though > the channel (just like almost any rust object). And semantics is just > like you described. You can also use Arc> that allows to use > that message in several places simultaneously (e.g. if you want > publish-subscribe) > I'd rather not use a channel as channels appear to only work between tasks. I'd like to have the transfer semantics work between any two entities. For instance, I'd like to have a queue between two entities and transfer a reference via the queue from A to B. .i.e. allocate a Message in A then place the Message on a queue. A would no longer have a reference to the Message and the only reference would be the one in the queue. Then when B retrieved the message from the queue B would have the only reference. Finally, when B went out of scope, the message would be freed. Is that possible as the language is currently defined, if so could I be pointed to an example or documentation? Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Mon Sep 29 21:50:11 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Mon, 29 Sep 2014 21:50:11 -0700 (PDT) Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: <1412052611612.7d2f2cd9@Nodemailer> These are the semantics of a boxed value. On Mon, Sep 29, 2014 at 9:47 PM, Wink Saville wrote: > On Mon, Sep 29, 2014 at 1:10 PM, Paul Colomiets wrote: >> Hi, >> >> On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville wrote: >> > Nanomsg looks interesting and I'll take a closer look. But I'm >> interested in >> > a pure rust implementation of async messaging because I'd like to create >> an >> > embedded OS using rust and not use C if possible. >> > >> >> I think even if there will be nanomsg implementation in pure rust, >> that would probably require rust stdlib, which is usually not used for >> embedded purposes, right? >> >> > I been thinking about the problem and one of the questions I have is how >> to >> > transfer ownership of a pointer from one entity to another. Not borrow >> but >> > actually transfer ownership. So if I "allocated" a Message in one entity >> > then send it to another I want the receiver to "free" the Message. >> > >> >> >> > Does the rust ownership model allow ownership to be transferred? >> > >> >> Sure, you can just send Vec of bytes or any other rust object though >> the channel (just like almost any rust object). And semantics is just >> like you described. You can also use Arc> that allows to use >> that message in several places simultaneously (e.g. if you want >> publish-subscribe) >> > I'd rather not use a channel as channels appear to only work between > tasks. I'd like to have the transfer semantics work between any two > entities. > For instance, I'd like to have a queue between two entities and transfer a > reference via the queue from A to B. .i.e. allocate a Message in A then > place the Message on a queue. A would no longer have a reference to the > Message and the only reference would be the one in the queue. Then when B > retrieved the message from the queue B would have the only reference. > Finally, when B went out of scope, the message would be freed. > Is that possible as the language is currently defined, if so could I be > pointed > to an example or documentation? > Paul >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Mon Sep 29 21:50:22 2014 From: wink at saville.com (Wink Saville) Date: Mon, 29 Sep 2014 21:50:22 -0700 Subject: [rust-dev] Async Message passing. In-Reply-To: References: Message-ID: Cool, I've been following capn proto and have used protobufs a little. This is the direction of what I'm thinking and I'm wondering if the rust notion of ownership can be leveraged in message passing. Hence my silly questions. On Mon, Sep 29, 2014 at 2:03 PM, Tony Arcieri wrote: > On Mon, Sep 29, 2014 at 1:01 PM, Wink Saville wrote: > >> Nanomsg looks interesting and I'll take a closer look. But I'm interested >> in a pure rust implementation of async messaging because I'd like to create >> an embedded OS using rust and not use C if possible >> > You might take a look at capnproto-rust: > > https://github.com/dwrensha/capnproto-rust > > It doesn't support asynchronous messaging (yet) but it is planned. That > said it supports an RPC system that's fully asynchronous under the covers, > so async messaging becomes effectively "disregard the response" > > It also provides a typed description language for messages that maps > nicely to Rust's type system. > > -- > Tony Arcieri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wink at saville.com Mon Sep 29 21:53:52 2014 From: wink at saville.com (Wink Saville) Date: Mon, 29 Sep 2014 21:53:52 -0700 Subject: [rust-dev] Async Message passing. In-Reply-To: <1412052611612.7d2f2cd9@Nodemailer> References: <1412052611612.7d2f2cd9@Nodemailer> Message-ID: Perfect! On Mon, Sep 29, 2014 at 9:50 PM, Clark Gaebel wrote: > These are the semantics of a boxed value. > > > > On Mon, Sep 29, 2014 at 9:47 PM, Wink Saville wrote: > >> >> >> On Mon, Sep 29, 2014 at 1:10 PM, Paul Colomiets >> wrote: >> >>> Hi, >>> >>> On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville wrote: >>> > Nanomsg looks interesting and I'll take a closer look. But I'm >>> interested in >>> > a pure rust implementation of async messaging because I'd like to >>> create an >>> > embedded OS using rust and not use C if possible. >>> > >>> >>> I think even if there will be nanomsg implementation in pure rust, >>> that would probably require rust stdlib, which is usually not used for >>> embedded purposes, right? >>> >>> > I been thinking about the problem and one of the questions I have is >>> how to >>> > transfer ownership of a pointer from one entity to another. Not borrow >>> but >>> > actually transfer ownership. So if I "allocated" a Message in one >>> entity >>> > then send it to another I want the receiver to "free" the Message. >>> > >>> >>> >>> > Does the rust ownership model allow ownership to be transferred? >>> > >>> >>> Sure, you can just send Vec of bytes or any other rust object though >>> the channel (just like almost any rust object). And semantics is just >>> like you described. You can also use Arc> that allows to use >>> that message in several places simultaneously (e.g. if you want >>> publish-subscribe) >>> >> >> I'd rather not use a channel as channels appear to only work between >> tasks. I'd like to have the transfer semantics work between any two >> entities. >> >> For instance, I'd like to have a queue between two entities and transfer a >> reference via the queue from A to B. .i.e. allocate a Message in A then >> place the Message on a queue. A would no longer have a reference to the >> Message and the only reference would be the one in the queue. Then when B >> retrieved the message from the queue B would have the only reference. >> Finally, when B went out of scope, the message would be freed. >> >> Is that possible as the language is currently defined, if so could I be >> pointed >> to an example or documentation? >> >> >> Paul >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Mon Sep 29 22:39:31 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 29 Sep 2014 22:39:31 -0700 Subject: [rust-dev] Rust crypto highlights Message-ID: I've been trying to keep an eye on what's been brewing in the Rust crypto-world. There's a lot of parts that people have been working on that I'd really love to see brought together in a coherent manner, perhaps in the form of an (out-of-tree) common crypto library for Rust. Here are a few highlights: - common.rs : a cool library with a terrible name! This library implements SBufs : secure buffers with guard pages, suitable for storing keying material. I would still love to see this extended to do RAII-style memory protection that sets PROT_NONE on buffer pages when they're not in use - rust-constanttime : [ WARNING: BROKEN DO NOT USE ] a library similar to Go's crypto/subtle : data types that try to ensure constant-time operations, unfortunately LLVM is really smart and likes to performance optimize by adding branches even when you really don't want it to. If someone knew of a way to make it actually verifiably constant time, that would be amazing. - suruga : a Rust implementation of TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have to use OpenSSL? ;) This seems like it could benefit from SBufs and rust-constanttime, if they were fully baked. Right now it does no memory protections around keying material or internal cipher state. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Mon Sep 29 22:44:59 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 29 Sep 2014 22:44:59 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: Message-ID: Sidebar on SBuf: I'd be curious how it could be written completely in terms of MemoryMap, or if MemoryMap needs to be extended to support mprotect() / VirtualProtect(). On Mon, Sep 29, 2014 at 10:39 PM, Tony Arcieri wrote: > I've been trying to keep an eye on what's been brewing in the Rust > crypto-world. There's a lot of parts that people have been working on that > I'd really love to see brought together in a coherent manner, perhaps in > the form of an (out-of-tree) common crypto library for Rust. Here are a few > highlights: > > - common.rs : a cool library with a > terrible name! This library implements SBufs > : secure > buffers with guard pages, suitable for storing keying material. I would > still love to see this extended to do RAII-style memory protection that > sets PROT_NONE on buffer pages when they're not in use > > - rust-constanttime > : [ WARNING: > BROKEN DO NOT USE ] a library similar to Go's crypto/subtle > : data types that try to ensure > constant-time operations, unfortunately LLVM is really smart and likes to > performance optimize by adding branches even when you really don't want it > to. If someone knew of a way to make it actually verifiably constant time, > that would be amazing. > > - suruga : a Rust implementation of TLS > 1.2. Wouldn't it be great if a Servo-powered browser didn't have to use > OpenSSL? ;) This seems like it could benefit from SBufs and > rust-constanttime, if they were fully baked. Right now it does no memory > protections around keying material or internal cipher state. > > -- > Tony Arcieri > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Sep 29 22:50:26 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 30 Sep 2014 01:50:26 -0400 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: Message-ID: <542A44A2.1030102@gmail.com> On 30/09/14 01:44 AM, Tony Arcieri wrote: > Sidebar on SBuf: I'd be curious how it could be written completely in > terms of MemoryMap, or if MemoryMap needs to be extended to support > mprotect() / VirtualProtect(). MemoryMap doesn't support controlling memory protections. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bascule at gmail.com Mon Sep 29 22:54:27 2014 From: bascule at gmail.com (Tony Arcieri) Date: Mon, 29 Sep 2014 22:54:27 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: <542A44A2.1030102@gmail.com> References: <542A44A2.1030102@gmail.com> Message-ID: On Mon, Sep 29, 2014 at 10:50 PM, Daniel Micay wrote: > MemoryMap doesn't support controlling memory protections. Will it ever, or is the recommended approach to brew your own MemoryMap-alike like SBuf is presently doing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From florob at babelmonkeys.de Tue Sep 30 07:05:37 2014 From: florob at babelmonkeys.de (Florian Zeitz) Date: Tue, 30 Sep 2014 16:05:37 +0200 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: Message-ID: <542AB8B1.4000705@babelmonkeys.de> On 30.09.2014 07:39, Tony Arcieri wrote: > I've been trying to keep an eye on what's been brewing in the Rust > crypto-world. There's a lot of parts that people have been working on > that I'd really love to see brought together in a coherent manner, > perhaps in the form of an (out-of-tree) common crypto library for Rust. > Here are a few highlights: > > - common.rs : a cool library with a > terrible name! This library implements SBufs > : secure > buffers with guard pages, suitable for storing keying material. I would > still love to see this extended to do RAII-style memory protection that > sets PROT_NONE on buffer pages when they're not in use > > - rust-constanttime > : [ WARNING: > BROKEN DO NOT USE ] a library similar to Go's crypto/subtle > : data types that try to ensure > constant-time operations, unfortunately LLVM is really smart and likes > to performance optimize by adding branches even when you really don't > want it to. If someone knew of a way to make it actually verifiably > constant time, that would be amazing. > > - suruga : a Rust implementation of > TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have to > use OpenSSL? ;) This seems like it could benefit from SBufs and > rust-constanttime, if they were fully baked. Right now it does no memory > protections around keying material or internal cipher state. > Is there any particular reason you chose this three projects? I was rather surprised rust-crypto isn't on your list. Also common.rs links to the two projects it was written for: crypto.rs and Curve41417.rs , which seem rather interesting to me. Regards, Florian Zeitz From bascule at gmail.com Tue Sep 30 09:06:39 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 30 Sep 2014 09:06:39 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: <542AB8B1.4000705@babelmonkeys.de> References: <542AB8B1.4000705@babelmonkeys.de> Message-ID: On Tue, Sep 30, 2014 at 7:05 AM, Florian Zeitz wrote: > Is there any particular reason you chose this three projects? > Because I consider it somewhat bad idea to implement cryptographic primitives building on this sort of foundation. > I was rather surprised rust-crypto > isn't on your list. rust-crypto is exactly the kind of library that needs these cryptographic primitives. Since it doesn't have them, it's most likely providing implementations that aren't sidechannel resistant, and it doesn't protect data in memory. Perhaps I should test the former empirically empirically with djb's cpucycles library. This is, of course, why I bring up the need for these things now: retrofitting them later will be difficult. > Also > common.rs links to the two projects it was written for: crypto.rs > and Curve41417.rs > , which seem rather interesting > to me. Yes, although they are, again lacking constant time primitives to build on. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Sep 30 10:05:09 2014 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 30 Sep 2014 10:05:09 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: Message-ID: <542AE2C5.5080708@mozilla.com> Thanks for the updates, Tony. On 09/29/2014 10:39 PM, Tony Arcieri wrote: > I've been trying to keep an eye on what's been brewing in the Rust > crypto-world. There's a lot of parts that people have been working on > that I'd really love to see brought together in a coherent manner, > perhaps in the form of an (out-of-tree) common crypto library for > Rust. Here are a few highlights: > > - common.rs : a cool library with > a terrible name! This library implements SBufs > : secure > buffers with guard pages, suitable for storing keying material. I > would still love to see this extended to do RAII-style memory > protection that sets PROT_NONE on buffer pages when they're not in use > > - rust-constanttime > : [ WARNING: > BROKEN DO NOT USE ] a library similar to Go's crypto/subtle > : data types that try to ensure > constant-time operations, unfortunately LLVM is really smart and likes > to performance optimize by adding branches even when you really don't > want it to. If someone knew of a way to make it actually verifiably > constant time, that would be amazing. I've been told by LLVM folks that getting LLVM to do constant time code generation is essentially hopeless, and it should just be written in asm. One could start by compiling with LLVM, then hand-inspecting the output. > > - suruga : a Rust implementation of > TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have > to use OpenSSL? ;) This seems like it could benefit from SBufs and > rust-constanttime, if they were fully baked. Right now it does no > memory protections around keying material or internal cipher state. > > -- > Tony Arcieri > > > _______________________________________________ > 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 dragon.lala.28 at gmail.com Tue Sep 30 09:56:39 2014 From: dragon.lala.28 at gmail.com (dragon lala lalo) Date: Tue, 30 Sep 2014 13:56:39 -0300 Subject: [rust-dev] Issues with the Floating Point Message-ID: Floating Point 's Issue I was in a little research related to the loss of significance of the Floating Point. http://en.wikipedia.org/wiki/Loss_of_significance After, i looked for other options to the floating point, here is one. "The Residue Logarithmic Number System: Theory and Implementation" Mark G. Arnold - Lehigh University "Circuit Design Residue Logarithmic Number System (RLNS) Using the One-Hot system" Now, because, you, people, are in the area of compilers, I have 2 doubts: 1) Is there some place where accuracy play a very very very important role? 2) Does this issue have a real importance in the development of a Compiler? ...or simply it's more like an if-it-works-don't-change-it thing? :D -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Tue Sep 30 11:12:22 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 30 Sep 2014 11:12:22 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: <542AE2C5.5080708@mozilla.com> References: <542AE2C5.5080708@mozilla.com> Message-ID: On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson wrote: > I've been told by LLVM folks that getting LLVM to do constant time code > generation is essentially hopeless, and it should just be written in asm. > One could start by compiling with LLVM, then hand-inspecting the output. > That's unfortunate. It would probably be good for any pure Rust implementation of any cryptographic primitive to do a timing variability study on the main CPU architectures they intend for their code to be run on. Perhaps I'll work on a tool to do that ;) If any you are curious why this is a problem, I'd suggest taking a look at djb's original cache timing attacks paper, where he demonstrates over-the-network AES key recovery using cache timing sidechannels in OpenSSL: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf Things get worse when you're talking about two VMs that are cotenant on the same hypervisor, or shared hosting systems in general. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From blastrock0 at free.fr Tue Sep 30 11:33:42 2014 From: blastrock0 at free.fr (Philippe Daouadi) Date: Tue, 30 Sep 2014 20:33:42 +0200 Subject: [rust-dev] Synchronizing with non-rust thread (async ffi callback) In-Reply-To: <541B39F8.4050201@free.fr> References: <5419FE4A.5020802@free.fr> <541B39F8.4050201@free.fr> Message-ID: <542AF786.2050609@free.fr> Hi, The bug is reported here https://github.com/rust-lang/rust/issues/17485 but I got no answer. I just added the stack trace (thanks benjamin). Philippe On 09/18/2014 10:00 PM, Philippe wrote: > Hi again, > > I think this is a bug in rust. Here is a minimal example attached. > Uncompress and type "make run". > On my debian amd64 unstable machine, I get: > fatal runtime error: assertion failed: !ptr.is_null() > Illegal instruction > > I'm not sure how to report it, where should I upload the file? > > Philippe > > On 09/17/2014 11:34 PM, Philippe wrote: >> Hi, >> >> I have a case very similar to the one described here: >> http://doc.rust-lang.org/guide-ffi.html#asynchronous-callbacks . The >> guide explains what to do but not how to do it. I tried to share a >> Mutex between the rust thread and the c thread using combinations of >> Arc, std::mem::drop and stuff, std::ptr::read and stuff. So far I got >> only segfaults and assertion failures when I try to lock the mutex. >> How are we supposed to send an object to a C callback and give it >> ownership? >> >> Also, there seems not to be Promise/Future classes in the standard >> library, why is that? >> >> Thanks, >> Philippe > From erick.tryzelaar at gmail.com Tue Sep 30 20:19:51 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 30 Sep 2014 20:19:51 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: What a great coincidence that this came up. I'm in the process of organizing a crypto-themed rust meetup. Would anyone like to give a talk about something crypto related? On Tue, Sep 30, 2014 at 11:12 AM, Tony Arcieri wrote: > On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson > wrote: > >> I've been told by LLVM folks that getting LLVM to do constant time code >> generation is essentially hopeless, and it should just be written in asm. >> One could start by compiling with LLVM, then hand-inspecting the output. >> > > That's unfortunate. It would probably be good for any pure Rust > implementation of any cryptographic primitive to do a timing variability > study on the main CPU architectures they intend for their code to be run > on. Perhaps I'll work on a tool to do that ;) > > If any you are curious why this is a problem, I'd suggest taking a look at > djb's original cache timing attacks paper, where he demonstrates > over-the-network AES key recovery using cache timing sidechannels in > OpenSSL: > > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf > > Things get worse when you're talking about two VMs that are cotenant on > the same hypervisor, or shared hosting systems in general. > > -- > Tony Arcieri > > _______________________________________________ > 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 bascule at gmail.com Tue Sep 30 20:29:49 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 30 Sep 2014 20:29:49 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: I already talked to you about giving a talk so seems good ;) I also had various point me at rust-crypto's implementation and it is much better than I realized. It's using the asm! macro to take advantage of a lot of neat Intel features including AES-NI acceleration. That's great! I also learned about the existence of the asm! macro in the process. It'd be really interesting to see someone try to reimplement rust-constanttime in ASM. That should solve any worries about LLVM optimizations, and provide a good building block for implementing crypto in otherwise pure Rust, specifically for things like RSA or ECC. On Tue, Sep 30, 2014 at 8:19 PM, Erick Tryzelaar wrote: > What a great coincidence that this came up. I'm in the process of > organizing a crypto-themed rust meetup. Would anyone like to give a talk > about something crypto related? > > On Tue, Sep 30, 2014 at 11:12 AM, Tony Arcieri wrote: > >> On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson >> wrote: >> >>> I've been told by LLVM folks that getting LLVM to do constant time code >>> generation is essentially hopeless, and it should just be written in asm. >>> One could start by compiling with LLVM, then hand-inspecting the output. >>> >> >> That's unfortunate. It would probably be good for any pure Rust >> implementation of any cryptographic primitive to do a timing variability >> study on the main CPU architectures they intend for their code to be run >> on. Perhaps I'll work on a tool to do that ;) >> >> If any you are curious why this is a problem, I'd suggest taking a look >> at djb's original cache timing attacks paper, where he demonstrates >> over-the-network AES key recovery using cache timing sidechannels in >> OpenSSL: >> >> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf >> >> Things get worse when you're talking about two VMs that are cotenant on >> the same hypervisor, or shared hosting systems in general. >> >> -- >> Tony Arcieri >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: