From davidb at davidb.org Tue Jul 1 07:35:08 2014 From: davidb at davidb.org (David Brown) Date: Tue, 1 Jul 2014 07:35:08 -0700 Subject: [rust-dev] Drop and lifetimes Message-ID: <20140701143508.GA14879@davidb.org> Imagine a hypothetical database interface: struct Database { ... } struct Cursor<'a> { db: &'a Database, ... } impl Database { fn query<'a>(&'a self, ...) -> Cursor<'a> { ... } } Ideally, I would like both the Database, and the Cursor to implement Drop. The underlying database API requires the cursors to all be closed before the database itself is closed. My first concern is that the trend seems to be to disallow Drop on the Cursor (it requires #[unsafe_destructor] to compile right now). My second concern is around what seems to be to be a reasonable use of this: struct Thing<'a> { db: Database, q1: Cursor<'a>, ... } This would be common with the use of an SQL database, where there are a handful of prepared statements that get reused with different data. (minor other question, I can't figure out how to make a 'Thing', everything I've tried results in some kind of lifetime error). But, the question then becomes, what order would Drop be called when Thing goes out of scope? Am I missing a better way of doing all of this? I don't see 'Rc' or 'Gc' helping, least because they only handle an immutable value, but also, they are non-Send, so can't have Drop either. Thanks, David Brown From sfackler at gmail.com Tue Jul 1 09:22:31 2014 From: sfackler at gmail.com (Steven Fackler) Date: Tue, 1 Jul 2014 09:22:31 -0700 Subject: [rust-dev] Drop and lifetimes In-Reply-To: <20140701143508.GA14879@davidb.org> References: <20140701143508.GA14879@davidb.org> Message-ID: Drop implementations for types with lifetime parameters need to be tagged with #[unsafe_destructor] because they're currently unsound in certain situations: https://github.com/rust-lang/rust/issues/8861. The intended semantics are what you would expect: Cursor would drop before Database. It's something that will be fixed before 1.0. Rust-Postgres uses this kind of lifetime setup and it works pretty well (ignoring the memory corruption which is hackily checked for right now with a canary): https://github.com/sfackler/rust-postgres. You can't safely create a Thing. Cursor contains a pointer to the Database, but the Database will move to a new location in memory when you place it into the Thing, and every time Thing moves afterwards. All of those moves will cause the Cursor's reference to the Database to point to stale memory. You may be able to adjust Thing so it contains a reference to the Database instead. Steven Fackler On Tue, Jul 1, 2014 at 7:35 AM, David Brown wrote: > Imagine a hypothetical database interface: > > struct Database { ... } > struct Cursor<'a> { > db: &'a Database, > ... > } > impl Database { > fn query<'a>(&'a self, ...) -> Cursor<'a> { ... } > } > > Ideally, I would like both the Database, and the Cursor to implement > Drop. The underlying database API requires the cursors to all be > closed before the database itself is closed. > > My first concern is that the trend seems to be to disallow Drop on the > Cursor (it requires #[unsafe_destructor] to compile right now). > > My second concern is around what seems to be to be a reasonable use of > this: > > struct Thing<'a> { > db: Database, > q1: Cursor<'a>, > ... > } > > This would be common with the use of an SQL database, where there are > a handful of prepared statements that get reused with different data. > (minor other question, I can't figure out how to make a 'Thing', > everything I've tried results in some kind of lifetime error). > > But, the question then becomes, what order would Drop be called when > Thing goes out of scope? > > Am I missing a better way of doing all of this? I don't see 'Rc' or > 'Gc' helping, least because they only handle an immutable value, but > also, they are non-Send, so can't have Drop either. > > Thanks, > David Brown > _______________________________________________ > 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 arkrost at gmail.com Tue Jul 1 13:38:59 2014 From: arkrost at gmail.com (Arkadii Rost) Date: Wed, 2 Jul 2014 00:38:59 +0400 Subject: [rust-dev] conflicting implementations for trait Message-ID: Hi, Can I override trait impl in another module? For example, I want to do something like this use foo_mod::MyTrait; mod foo_mod { pub trait MyTrait { fn foo (&self) -> int; } impl MyTrait for int { fn foo(&self) -> int { return self + 2; } } impl MyTrait for ~str { fn foo(&self) -> int { return 42; } } } impl MyTrait for int { fn foo(&self) -> int { return self - 2; } } Yours, Arkadii Rost -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan.software at gmail.com Tue Jul 1 13:48:52 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Tue, 1 Jul 2014 13:48:52 -0700 Subject: [rust-dev] Seattle Meetup in July In-Reply-To: References: Message-ID: Hello everyone! It looks like no one has expressed strong opinions on the actual date of the meetup. I have travel next week Wed-Friday, so I pick Monday, June 7th. :-) - Eric from UW has offered to give presentations on either the borrow checker or the runtime. Please let Eric know what you'd like to see! - I will offer up some remarks on my experiences writing a CI server in Rust, as someone coming primarily from fully refcounted/GC'd languages. My employer has graciously allowed me to host the meetup at their office: Climate Corporation 419 Occidental Ave S Seattle, WA 98104 It is approximately 5 minutes walk from the International District transit station. Car parking exists over by the stadia. I've created an event in EventBrite to gauge attendance - it'd be appreciated if you got a free "ticket" to RSVP. https://www.eventbrite.com/e/seattle-mozilla-rust-meetup-tickets-12142932839 Please let your friends and colleagues know about this. :-) On Thu, Jun 19, 2014 at 11:17 PM, Paul Nathan wrote: > Good evening Rust colleagues; > > As we discussed at the May Seattle meetup (A success! about 6 people from > larger, smaller, and academic environments visited), we'd like to meetup in > July and talk about our current projects in a quasi-presentation format at > one of the local companies or the University of Washington. > > I'd like to propose a day in the July 7-11 range with the following agenda: > > *7pm Start* > > - 20 minutes Meet & Greet > - 2-4 10-minute long presentations of different projects (ideas, scraps of > code, working projects). > - 1-2 20-minute presentations - I think Eli? from UW volunteered to talk > about the borrow checker. > - 20 minutes Socialize More > > *9pm end* > > If I remember right, several different venues with projectors/large TVs > were an option... I know I can lay my hands on at least one venue. :-) > > Best Regards, > Paul Nathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Tue Jul 1 15:17:06 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 1 Jul 2014 18:17:06 -0400 Subject: [rust-dev] conflicting implementations for trait In-Reply-To: References: Message-ID: You cannot. From fantix.king at gmail.com Tue Jul 1 23:38:49 2014 From: fantix.king at gmail.com (Fantix King) Date: Wed, 2 Jul 2014 14:38:49 +0800 Subject: [rust-dev] =?iso-8859-1?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_?= =?iso-8859-1?q?=D8MQ_in_Rus?= Message-ID: Hi, Here is zmq.rs, a native implementation of ?MQ in the Rust programming language in MPLv2. I've just got a very ugly prototype running till now, and I'm expecting to hear more comments on anything. https://github.com/zeromq/zmq.rs For who wants to know more about ?MQ, it looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. (according to http://zguide.zeromq.org/page:all) Back to the project, I did a few iterations and got what it is now, in the hope that more discussion can be raised over some actual code to talk about. zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I also blogged a bit about the design here (more to come): http://blog.segmentfault.com/fantix/1190000000593564 You are more than welcome to: * comment on the design * suggest different solution * complain about whatever you don't like * open issues on github * send me PRs and code reviews * join me developing and maintaining it * or even star it on github ;) BR, Fantix -- http://about.me/fantix -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed Jul 2 00:16:15 2014 From: corey at octayn.net (Corey Richardson) Date: Wed, 2 Jul 2014 00:16:15 -0700 Subject: [rust-dev] =?utf-8?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_=C3=98M?= =?utf-8?q?Q_in_Rus?= In-Reply-To: References: Message-ID: Complaining about something I don't like: Due to the choice of MPLv2, this won't be usable in the wider Rust ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) requires that any distribution in "Executable Form" carry a notice about how to acquire the source code of zmq.rs. This is not unworkable, but it is something we have avoided so far in the community. Otherwise, I look forward to reviewing this in more depth tomorrow. Nice work! On Tue, Jul 1, 2014 at 11:38 PM, Fantix King wrote: > Hi, > > Here is zmq.rs, a native implementation of ?MQ in the Rust programming > language in MPLv2. I've just got a very ugly prototype running till now, and > I'm expecting to hear more comments on anything. > > https://github.com/zeromq/zmq.rs > > For who wants to know more about ?MQ, it looks like an embeddable networking > library but acts like a concurrency framework. It gives you sockets that > carry atomic messages across various transports like in-process, > inter-process, TCP, and multicast. You can connect sockets N-to-N with > patterns like fan-out, pub-sub, task distribution, and request-reply. > (according to http://zguide.zeromq.org/page:all) > > Back to the project, I did a few iterations and got what it is now, in the > hope that more discussion can be raised over some actual code to talk about. > zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I also > blogged a bit about the design here (more to come): > > http://blog.segmentfault.com/fantix/1190000000593564 > > You are more than welcome to: > * comment on the design > * suggest different solution > * complain about whatever you don't like > * open issues on github > * send me PRs and code reviews > * join me developing and maintaining it > * or even star it on github ;) > > > BR, > Fantix > -- > http://about.me/fantix > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From fantix.king at gmail.com Wed Jul 2 00:40:15 2014 From: fantix.king at gmail.com (Fantix King) Date: Wed, 2 Jul 2014 15:40:15 +0800 Subject: [rust-dev] =?iso-8859-1?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_?= =?iso-8859-1?q?=D8MQ_in_Rus?= In-Reply-To: References: Message-ID: Thank you, Corey! Honestly I didn't dig deep about licensing. It was MIT which I think is the most open one as BSD. Then http://zeromq.org/docs:organization suggested MPLv2 - something between BSD and GPL just sounded "also not bad" for me, so I didn't pay much attention changing to MPLv2. I wouldn't mind changing back to MIT if that works better for the community :) BR, Fantix -- http://about.me/fantix On Wed, Jul 2, 2014 at 3:16 PM, Corey Richardson wrote: > Complaining about something I don't like: > > Due to the choice of MPLv2, this won't be usable in the wider Rust > ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) > requires that any distribution in "Executable Form" carry a notice > about how to acquire the source code of zmq.rs. This is not > unworkable, but it is something we have avoided so far in the > community. > > Otherwise, I look forward to reviewing this in more depth tomorrow. Nice > work! > > On Tue, Jul 1, 2014 at 11:38 PM, Fantix King > wrote: > > Hi, > > > > Here is zmq.rs, a native implementation of ?MQ in the Rust programming > > language in MPLv2. I've just got a very ugly prototype running till now, > and > > I'm expecting to hear more comments on anything. > > > > https://github.com/zeromq/zmq.rs > > > > For who wants to know more about ?MQ, it looks like an embeddable > networking > > library but acts like a concurrency framework. It gives you sockets that > > carry atomic messages across various transports like in-process, > > inter-process, TCP, and multicast. You can connect sockets N-to-N with > > patterns like fan-out, pub-sub, task distribution, and request-reply. > > (according to http://zguide.zeromq.org/page:all) > > > > Back to the project, I did a few iterations and got what it is now, in > the > > hope that more discussion can be raised over some actual code to talk > about. > > zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I > also > > blogged a bit about the design here (more to come): > > > > http://blog.segmentfault.com/fantix/1190000000593564 > > > > You are more than welcome to: > > * comment on the design > > * suggest different solution > > * complain about whatever you don't like > > * open issues on github > > * send me PRs and code reviews > > * join me developing and maintaining it > > * or even star it on github ;) > > > > > > BR, > > Fantix > > -- > > http://about.me/fantix > > > > _______________________________________________ > > 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 contact at bitpuffin.com Wed Jul 2 03:49:12 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Wed, 2 Jul 2014 12:49:12 +0200 Subject: [rust-dev] Cargo multiple targets Message-ID: Hello Rust folks! I am using Cargo and I am trying to specify mulitple targets in my Cargo.toml file. First of all is this even possible? The way I have set things up is that I have src/hmwhoami.rs which builds to a binary, and uses src/proof.rs and that builds totally fine. My Cargo file looks like this: [package] name = "hmproof" version = "0.1.0" authors = [ "isak at houstonmedia.se" ] [[bin]] name = "hmwhoami" [dependencies.rust-http] git = "https://github.com/chris-morgan/rust-http.git" Now what I also want to do is to build src/proof.rs as a library (that is linkable with C programs so they can call the extern fn's). My initial approach was this: [package] name = "hmproof" version = "0.1.0" authors = [ "isak at houstonmedia.se" ] [[bin]] name = "hmwhoami" [[lib]] name = "proof" (I also tried adding a path) path = "src/proof.rs" [dependencies.rust-http] git = "https://github.com/chris-morgan/rust-http.git" I also tried putting the [[lib]] part after the dependencies part. The error I get is this: error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such file or directory (No such file or directory); path=src/bin/hmwhoami.rs; mode=open; access=read) Whiich doesn't make any sense at all to me. Why does it suddenly start looking in src/bin? Do I have to put my bin code in src/bin and my lib code in src lib or what? That would probably break the hmwhoami executable because I'd have to make the proof library an extern crate, at least I think I would have to do that. Thanks! Isak Andersson -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.gesemann at gmail.com Wed Jul 2 04:37:58 2014 From: s.gesemann at gmail.com (Sebastian Gesemann) Date: Wed, 2 Jul 2014 13:37:58 +0200 Subject: [rust-dev] Cargo multiple targets In-Reply-To: References: Message-ID: On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: > Hello Rust folks! > > I am using Cargo and I am trying to specify mulitple targets in my > Cargo.toml file. > First of all is this even possible? > ... > [package] > name = "hmproof" > version = "0.1.0" > authors = [ "isak at houstonmedia.se" ] > [[bin]] > name = "hmwhoami" > [[lib]] > name = "proof" > (I also tried adding a path) > path = "src/proof.rs" > [dependencies.rust-http] > git = "https://github.com/chris-morgan/rust-http.git" > > I also tried putting the [[lib]] part after the dependencies part. The error > I get is this: > error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such file > or directory [...] > Whiich doesn't make any sense at all to me. Why does it suddenly start > looking in src/bin? According to http://crates.io/manifest.html the default path for a binary is src (if there is no other lib) and src/bin (if there is also a lib target). You should be able to override this with path = src/hmwhoami. > Do I have to put my bin code in src/bin and my lib code in src lib or what? Currently, only a single lib per package is supported and it seems, judging by the document about the manifest format, that Cargo always looks for src/lib.rs for a library unless you override this using a "path=something". As for how to tell Cargo to invoke rustc with the appropriate -L option: I don't know. HTH, sg From contact at bitpuffin.com Wed Jul 2 04:58:04 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Wed, 2 Jul 2014 13:58:04 +0200 Subject: [rust-dev] Cargo multiple targets In-Reply-To: References: Message-ID: Hi! Thanks for the reply! Apparently multiple targets does in fact work. Just that you can't rely on the default path anymore, so I had to add the path = ... to both the [[lib]] and [[bin]]. Not sure if this is a bug or not. However the library compiles as an rlib and I'm not sure how to change it to build a C library instead (a .a or .so on *nix or .lib I think on windows). Actually I'm not even sure how to make rustc build a C library so I guess that's what I will start looking at. On Wed, Jul 2, 2014 at 1:37 PM, Sebastian Gesemann wrote: > On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: > > Hello Rust folks! > > > > I am using Cargo and I am trying to specify mulitple targets in my > > Cargo.toml file. > > First of all is this even possible? > > ... > > [package] > > name = "hmproof" > > version = "0.1.0" > > authors = [ "isak at houstonmedia.se" ] > > [[bin]] > > name = "hmwhoami" > > [[lib]] > > name = "proof" > > (I also tried adding a path) > > path = "src/proof.rs" > > [dependencies.rust-http] > > git = "https://github.com/chris-morgan/rust-http.git" > > > > I also tried putting the [[lib]] part after the dependencies part. The > error > > I get is this: > > error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such > file > > or directory [...] > > Whiich doesn't make any sense at all to me. Why does it suddenly start > > looking in src/bin? > > According to http://crates.io/manifest.html the default path for a > binary is src (if there is no other lib) and src/bin (if there is also > a lib target). You should be able to override this with path = > src/hmwhoami. > > > Do I have to put my bin code in src/bin and my lib code in src lib or > what? > > Currently, only a single lib per package is supported and it seems, > judging by the document about the manifest format, that Cargo always > looks for src/lib.rs for a library unless you override this using a > "path=something". > > As for how to tell Cargo to invoke rustc with the appropriate -L > option: I don't know. > > HTH, > sg > _______________________________________________ > 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 dpx.infinity at gmail.com Wed Jul 2 05:09:48 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Wed, 2 Jul 2014 16:09:48 +0400 Subject: [rust-dev] Cargo multiple targets In-Reply-To: References: Message-ID: Hi, Isak! According to manifest documentation [1] you can specify crate type (dynamic or static lib or rlib) using crate_type option: [[lib]] ? crate_type = ["dylib", "staticlib"] The above configuration should build you both .a and .so files. [1]: http://crates.io/manifest.html, search for "crate_type" w/o quotes On 02 ???? 2014 ?., at 15:58, Isak Andersson wrote: > Hi! > > Thanks for the reply! > > Apparently multiple targets does in fact work. Just that you can't rely on the > default path anymore, so I had to add the path = ... to both the [[lib]] and [[bin]]. > Not sure if this is a bug or not. > > However the library compiles as an rlib and I'm not sure how to change it to build > a C library instead (a .a or .so on *nix or .lib I think on windows). > > Actually I'm not even sure how to make rustc build a C library so I guess that's what > I will start looking at. > > > On Wed, Jul 2, 2014 at 1:37 PM, Sebastian Gesemann wrote: > On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: > > Hello Rust folks! > > > > I am using Cargo and I am trying to specify mulitple targets in my > > Cargo.toml file. > > First of all is this even possible? > > ... > > [package] > > name = "hmproof" > > version = "0.1.0" > > authors = [ "isak at houstonmedia.se" ] > > [[bin]] > > name = "hmwhoami" > > [[lib]] > > name = "proof" > > (I also tried adding a path) > > path = "src/proof.rs" > > [dependencies.rust-http] > > git = "https://github.com/chris-morgan/rust-http.git" > > > > I also tried putting the [[lib]] part after the dependencies part. The error > > I get is this: > > error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such file > > or directory [...] > > Whiich doesn't make any sense at all to me. Why does it suddenly start > > looking in src/bin? > > According to http://crates.io/manifest.html the default path for a > binary is src (if there is no other lib) and src/bin (if there is also > a lib target). You should be able to override this with path = > src/hmwhoami. > > > Do I have to put my bin code in src/bin and my lib code in src lib or what? > > Currently, only a single lib per package is supported and it seems, > judging by the document about the manifest format, that Cargo always > looks for src/lib.rs for a library unless you override this using a > "path=something". > > As for how to tell Cargo to invoke rustc with the appropriate -L > option: I don't know. > > HTH, > sg > _______________________________________________ > 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 contact at bitpuffin.com Wed Jul 2 05:38:16 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Wed, 2 Jul 2014 14:38:16 +0200 Subject: [rust-dev] Cargo multiple targets In-Reply-To: References: Message-ID: Hi! Wow I didn't know about the manifest page, I was under the impression that the docs were very lacking. But this is pretty great. Thanks a bunch that was super helpful! On Wed, Jul 2, 2014 at 2:09 PM, Vladimir Matveev wrote: > Hi, Isak! > > According to manifest documentation [1] you can specify crate type > (dynamic or static lib or rlib) using crate_type option: > > [[lib]] > ? > crate_type = ["dylib", "staticlib"] > > The above configuration should build you both .a and .so files. > > [1]: http://crates.io/manifest.html, search for "crate_type" w/o > quotes > > On 02 ???? 2014 ?., at 15:58, Isak Andersson > wrote: > > > Hi! > > > > Thanks for the reply! > > > > Apparently multiple targets does in fact work. Just that you can't rely > on the > > default path anymore, so I had to add the path = ... to both the [[lib]] > and [[bin]]. > > Not sure if this is a bug or not. > > > > However the library compiles as an rlib and I'm not sure how to change > it to build > > a C library instead (a .a or .so on *nix or .lib I think on windows). > > > > Actually I'm not even sure how to make rustc build a C library so I > guess that's what > > I will start looking at. > > > > > > On Wed, Jul 2, 2014 at 1:37 PM, Sebastian Gesemann > wrote: > > On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: > > > Hello Rust folks! > > > > > > I am using Cargo and I am trying to specify mulitple targets in my > > > Cargo.toml file. > > > First of all is this even possible? > > > ... > > > [package] > > > name = "hmproof" > > > version = "0.1.0" > > > authors = [ "isak at houstonmedia.se" ] > > > [[bin]] > > > name = "hmwhoami" > > > [[lib]] > > > name = "proof" > > > (I also tried adding a path) > > > path = "src/proof.rs" > > > [dependencies.rust-http] > > > git = "https://github.com/chris-morgan/rust-http.git" > > > > > > I also tried putting the [[lib]] part after the dependencies part. The > error > > > I get is this: > > > error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no such > file > > > or directory [...] > > > Whiich doesn't make any sense at all to me. Why does it suddenly start > > > looking in src/bin? > > > > According to http://crates.io/manifest.html the default path for a > > binary is src (if there is no other lib) and src/bin (if there is also > > a lib target). You should be able to override this with path = > > src/hmwhoami. > > > > > Do I have to put my bin code in src/bin and my lib code in src lib or > what? > > > > Currently, only a single lib per package is supported and it seems, > > judging by the document about the manifest format, that Cargo always > > looks for src/lib.rs for a library unless you override this using a > > "path=something". > > > > As for how to tell Cargo to invoke rustc with the appropriate -L > > option: I don't know. > > > > HTH, > > sg > > _______________________________________________ > > 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 s.gesemann at gmail.com Wed Jul 2 08:49:39 2014 From: s.gesemann at gmail.com (Sebastian Gesemann) Date: Wed, 2 Jul 2014 17:49:39 +0200 Subject: [rust-dev] ref binding for parameters of functions? Message-ID: So far I knew that `ref` could be used in `let` and `match` expressions. But I just tried using it for a function's parameter to see what happens and it actually compiled! :) fn foo(ref p: int) -> int { *p + 1 } fn main() { let x = 1729i; let y = foo(x); println!("{}",y); } What I was wondering then was: What is the type of foo and what does it mean for how the parameter is passed exactly? After adding let bar: fn(int)->int = foo; to the main function, I realized that the reference called p probably refers to a function-local temporary int. A part of me hoped for p referring to main's x thus saving a copy/move. But in that case, the function's type would have to be different, right? So, for a brief moment I thought that Rust already supports auto-referencing for non-self parameters just like C++ does for "const T&". The reason I'm mentioning this is that I noticed an RFC PR for a feature like this. So, what do you think about what kind of semantic you want for such a function? Should its p refer to main's x in this case? Should its type be fn(ref:int)->int which would be ABI-compatible with fn(&T)->int? Due to ABI compatibility one could even be allowed to convert one function pointer to another: let f = foo; // fn(ref:int)->int with auto-referencing let g = f as fn(&int)->int; // no auto-referencing anymore The parameter "type" ref:T could be useful for getting rid of some explicit borrows one would otherwise need at the invocation site: fn show_vec(ref v: Vec) {...} fn main() { let x = vec!(1,2,3i); show_vec(x); } Comments? Opinions? Maybe this could be useful. And maybe this is a bad idea. I don't know. What I *don't* like about it is that "ref:T" is not really a type and this could compose badly in generic code. Cheers! sg From erick.tryzelaar at gmail.com Wed Jul 2 08:50:27 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 2 Jul 2014 08:50:27 -0700 Subject: [rust-dev] conflicting implementations for trait In-Reply-To: References: Message-ID: If you do want to do this, you can wrap the type in a struct, as in: ``` use foo_mod::MyTrait; mod foo_mod { pub trait MyTrait { fn foo (&self) -> int; } impl MyTrait for int { fn foo(&self) -> int { return self + 2; } } impl MyTrait for ~str { fn foo(&self) -> int { return 42; } } } struct MyInt(int) impl MyTrait for MyInt { fn foo(&self) -> int { let MyInt(i) = *self; return i - 2; } } ``` Rust will optimize away the wrapper struct, so there's no overhead in doing this. On Tue, Jul 1, 2014 at 3:17 PM, Steve Klabnik wrote: > You cannot. > _______________________________________________ > 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 alex at crichton.co Wed Jul 2 09:21:24 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 2 Jul 2014 12:21:24 -0400 Subject: [rust-dev] ref binding for parameters of functions? In-Reply-To: References: Message-ID: Binding by ref is subtly different that the function still owns the argument. For example, this may go awry with "ref:T" struct Foo; impl Drop for Foo { fn drop(&mut self) { println!("dropping"); } } fn foo(ref _param: Foo) {} fn main() { let f1: fn(ref:Foo) = foo; let f2: fn(Foo) = foo; let f3: fn(&Foo) = foo; f1(Foo); f2(Foo); f3(&Foo); } In that program, how many times is `dropping` printed? It should be three, but I believe it will print four times due to f3 not understanding that the value has already been dropped. On Wed, Jul 2, 2014 at 11:49 AM, Sebastian Gesemann wrote: > So far I knew that `ref` could be used in `let` and `match` > expressions. But I just tried using it for a function's parameter to > see what happens and it actually compiled! :) > > fn foo(ref p: int) -> int { > *p + 1 > } > > fn main() { > let x = 1729i; > let y = foo(x); > println!("{}",y); > } > > What I was wondering then was: What is the type of foo and what does > it mean for how the parameter is passed exactly? > > After adding > > let bar: fn(int)->int = foo; > > to the main function, I realized that the reference called p probably > refers to a function-local temporary int. A part of me hoped for p > referring to main's x thus saving a copy/move. But in that case, the > function's type would have to be different, right? > > So, for a brief moment I thought that Rust already supports > auto-referencing for non-self parameters just like C++ does for "const > T&". The reason I'm mentioning this is that I noticed an RFC PR for a > feature like this. > > So, what do you think about what kind of semantic you want for such a > function? Should its p refer to main's x in this case? Should its type > be fn(ref:int)->int which would be ABI-compatible with fn(&T)->int? > Due to ABI compatibility one could even be allowed to convert one > function pointer to another: > > let f = foo; // fn(ref:int)->int with auto-referencing > let g = f as fn(&int)->int; // no auto-referencing anymore > > The parameter "type" ref:T could be useful for getting rid of some > explicit borrows one would otherwise need at the invocation site: > > fn show_vec(ref v: Vec) {...} > > fn main() { > let x = vec!(1,2,3i); > show_vec(x); > } > > Comments? Opinions? Maybe this could be useful. And maybe this is a > bad idea. I don't know. What I *don't* like about it is that "ref:T" > is not really a type and this could compose badly in generic code. > > Cheers! > sg > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From s.gesemann at gmail.com Wed Jul 2 10:04:29 2014 From: s.gesemann at gmail.com (Sebastian Gesemann) Date: Wed, 2 Jul 2014 19:04:29 +0200 Subject: [rust-dev] ref binding for parameters of functions? In-Reply-To: References: Message-ID: On Wed, Jul 2, 2014 at 6:21 PM, Alex Crichton wrote: > Binding by ref is subtly different that the function still owns the > argument. For example, this may go awry with "ref:T" > > struct Foo; > impl Drop for Foo { > fn drop(&mut self) { println!("dropping"); } > } > > fn foo(ref _param: Foo) {} > > fn main() { > let f1: fn(ref:Foo) = foo; > let f2: fn(Foo) = foo; > let f3: fn(&Foo) = foo; > > f1(Foo); > f2(Foo); > f3(&Foo); > } > > In that program, how many times is `dropping` printed? It should be > three, This program would not compile. Here's why: If one wanted `foo`'s `_param` to refer to the caller's memory -- a behaviour one *might* expect because that's how `ref` works in other contexts, specifically, it does not create a temporary and then a reference it -- this would make the first parameter of `foo` effectivly a reference to `Foo`, not a value of `Foo`. The only difference between ref:T and &T in a function signature would be that ref:T implies auto-referencing at the call site where &T does not. The function pointers would be compatible because the implementation of foo just works on a reference in both cases. The line let f2: fn(Foo) = foo; however, tries to assign the adress of a function taking a reference to Foo to a pointer for functions that take a value of Foo. This would be a type error. Cheers! sg From erick.tryzelaar at gmail.com Wed Jul 2 10:13:39 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 2 Jul 2014 10:13:39 -0700 Subject: [rust-dev] =?utf-8?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_=C3=98M?= =?utf-8?q?Q_in_Rus?= In-Reply-To: References: Message-ID: This is awesome! I look forward to deprecating https://github.com/erickt/rust-zmq. On Wed, Jul 2, 2014 at 12:40 AM, Fantix King wrote: > Thank you, Corey! > > Honestly I didn't dig deep about licensing. It was MIT which I think is > the most open one as BSD. Then http://zeromq.org/docs:organization > suggested MPLv2 - something between BSD and GPL just sounded "also not bad" > for me, so I didn't pay much attention changing to MPLv2. I wouldn't mind > changing back to MIT if that works better for the community :) > > BR, > Fantix > -- > http://about.me/fantix > > > On Wed, Jul 2, 2014 at 3:16 PM, Corey Richardson wrote: > >> Complaining about something I don't like: >> >> Due to the choice of MPLv2, this won't be usable in the wider Rust >> ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) >> requires that any distribution in "Executable Form" carry a notice >> about how to acquire the source code of zmq.rs. This is not >> unworkable, but it is something we have avoided so far in the >> community. >> >> Otherwise, I look forward to reviewing this in more depth tomorrow. Nice >> work! >> >> On Tue, Jul 1, 2014 at 11:38 PM, Fantix King >> wrote: >> > Hi, >> > >> > Here is zmq.rs, a native implementation of ?MQ in the Rust programming >> > language in MPLv2. I've just got a very ugly prototype running till >> now, and >> > I'm expecting to hear more comments on anything. >> > >> > https://github.com/zeromq/zmq.rs >> > >> > For who wants to know more about ?MQ, it looks like an embeddable >> networking >> > library but acts like a concurrency framework. It gives you sockets that >> > carry atomic messages across various transports like in-process, >> > inter-process, TCP, and multicast. You can connect sockets N-to-N with >> > patterns like fan-out, pub-sub, task distribution, and request-reply. >> > (according to http://zguide.zeromq.org/page:all) >> > >> > Back to the project, I did a few iterations and got what it is now, in >> the >> > hope that more discussion can be raised over some actual code to talk >> about. >> > zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I >> also >> > blogged a bit about the design here (more to come): >> > >> > http://blog.segmentfault.com/fantix/1190000000593564 >> > >> > You are more than welcome to: >> > * comment on the design >> > * suggest different solution >> > * complain about whatever you don't like >> > * open issues on github >> > * send me PRs and code reviews >> > * join me developing and maintaining it >> > * or even star it on github ;) >> > >> > >> > BR, >> > Fantix >> > -- >> > http://about.me/fantix >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> >> >> >> -- >> http://octayn.net/ >> > > > _______________________________________________ > 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 alex at crichton.co Wed Jul 2 11:07:08 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 2 Jul 2014 14:07:08 -0400 Subject: [rust-dev] Rust 0.11.0 Released Message-ID: Mozilla and the Rust community are pleased to announce version 0.11.0 of the Rust compiler and tools. Rust is a systems programming language with a focus on safety, performance and concurrency. While this was a very active development cycle, it was largely focused on polishing the type system and libraries. The major technical focuses this time were implementing infrastructure for dynamically sized types and refactoring the standard library. This release also marks the complete removal of the `~` and `@` syntax in favor of library types `Box` and `Gc`. The brief release notes are included in this announcement, and there is further explanation in the detailed release [notes] on the wiki. Documentation and all the links in this email are available on the [website]. As usual, version 0.11.0 should be considered an alpha release, suitable for early adopters and language enthusiasts. Please file [bugs] and join the [fun]. [website]: http://www.rust-lang.org [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes [bugs]: https://github.com/mozilla/rust/issues [fun]: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors Source * http://static.rust-lang.org/dist/rust-0.11.0.tar.gz http://static.rust-lang.org/dist/rust-0.11.0.tar.gz.asc SHA256 (of .tar.gz): d1b3e36448bf12b8c9289024df416de10774b6d3235d7b1d22b248ef634411ba Windows installer * http://static.rust-lang.org/dist/rust-0.11.0-install.exe http://static.rust-lang.org/dist/rust-0.11.0-install.exe.asc SHA256 (of .exe): fb253072ba5373eb0af388f63e51122af9dd13379d762ca4100ee7334dbec9d2 Linux binary tarballs * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz.asc SHA256 (of .tar.gz): 331d6374b3c8fca3e2b5fffb65ce75dfce3529bd47333de4a9ce636cb87be432 * http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz.asc SHA256 (of .tar.gz): cbfe2050f708479f2625a935d2f41165868f354ff740d2697e08acb2255670b2 Mac OS X binary installers * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg.asc SHA256 (of .pkg): 1183d6c8ab021f4049a2906c1527f705bae4bb4935aea897f4860eb5337363c3 * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg.asc SHA256 (of .pkg): 8f5a1fe491d83c6be0a3082f0ac8504c89eed38263ae0ac0fad15d8c02e3b267 Mac OS X binary tarballs * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz.asc SHA256 (of .tar.gz): bbac91aff5464c20f39afcf078a693c4612717d6b1cc3f86f92075b2103bc22e * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz.asc SHA256 (of .tar.gz): 93d6e6e98d00df3e946e4f7765172ad522a118dd34f1fac73ba74d43df92698b Thanks to everyone who contributed! Regards, The Rust Team Version 0.11.0 (July 2014) ------------------------- * ~1700 changes, numerous bugfixes * Language * ~[T] has been removed from the language. This type is superseded by the Vec type. * ~str has been removed from the language. This type is superseded by the String type. * ~T has been removed from the language. This type is superseded by the Box type. * @T has been removed from the language. This type is superseded by the standard library's std::gc::Gc type. * Struct fields are now all private by default. * Vector indices and shift amounts are both required to be a `uint` instead of any integral type. * Byte character, byte string, and raw byte string literals are now all supported by prefixing the normal literal with a `b`. * Multiple ABIs are no longer allowed in an ABI string * The syntax for lifetimes on closures/procedures has been tweaked slightly: `<'a>|A, B|: 'b + K -> T` * Floating point modulus has been removed from the language; however it is still provided by a library implementation. * Private enum variants are now disallowed. * The `priv` keyword has been removed from the language. * A closure can no longer be invoked through a &-pointer. * The `use foo, bar, baz;` syntax has been removed from the language. * The transmute intrinsic no longer works on type parameters. * Statics now allow blocks/items in their definition. * Trait bounds are separated from objects with + instead of : now. * Objects can no longer be read while they are mutably borrowed. * The address of a static is now marked as insignificant unless the #[inline(never)] attribute is placed it. * The #[unsafe_destructor] attribute is now behind a feature gate. * Struct literals are no longer allowed in ambiguous positions such as if, while, match, and for..in. * Declaration of lang items and intrinsics are now feature-gated by default. * Integral literals no longer default to `int`, and floating point literals no longer default to `f64`. Literals must be suffixed with an appropriate type if inference cannot determine the type of the literal. * The Box type is no longer implicitly borrowed to &mut T. * Procedures are now required to not capture borrowed references. * Libraries * The standard library is now a "facade" over a number of underlying libraries. This means that development on the standard library should be speeder due to smaller crates, as well as a clearer line between all dependencies. * A new library, libcore, lives under the standard library's facade which is Rust's "0-assumption" library, suitable for embedded and kernel development for example. * A regex crate has been added to the standard distribution. This crate includes statically compiled regular expressions. * The unwrap/unwrap_err methods on Result require a Show bound for better error messages. * The return types of the std::comm primitives have been centralized around the Result type. * A number of I/O primitives have gained the ability to time out their operations. * A number of I/O primitives have gained the ability to close their reading/writing halves to cancel pending operations. * Reverse iterator methods have been removed in favor of `rev()` on their forward-iteration counterparts. * A bitflags! macro has been added to enable easy interop with C and management of bit flags. * A debug_assert! macro is now provided which is disabled when `--cfg ndebug` is passed to the compiler. * A graphviz crate has been added for creating .dot files. * The std::cast module has been migrated into std::mem. * The std::local_data api has been migrated from freestanding functions to being based on methods. * The Pod trait has been renamed to Copy. * jemalloc has been added as the default allocator for types. * The API for allocating memory has been changed to use proper alignment and sized deallocation * Connecting a TcpStream or binding a TcpListener is now based on a string address and a u16 port. This allows connecting to a hostname as opposed to an IP. * The Reader trait now contains a core method, read_at_least(), which correctly handles many repeated 0-length reads. * The process-spawning API is now centered around a builder-style Command struct. * The :? printing qualifier has been moved from the standard library to an external libdebug crate. * Eq/Ord have been renamed to PartialEq/PartialOrd. TotalEq/TotalOrd have been renamed to Eq/Ord. * The select/plural methods have been removed from format!. The escapes for { and } have also changed from \{ and \} to {{ and }}, respectively. * The TaskBuilder API has been re-worked to be a true builder, and extension traits for spawning native/green tasks have been added. * Tooling * All breaking changes to the language or libraries now have their commit message annotated with `[breaking-change]` to allow for easy discovery of breaking changes. * The compiler will now try to suggest how to annotate lifetimes if a lifetime-related error occurs. * Debug info continues to be improved greatly with general bug fixes and better support for situations like link time optimization (LTO). * Usage of syntax extensions when cross-compiling has been fixed. * Functionality equivalent to GCC & Clang's -ffunction-sections, -fdata-sections and --gc-sections has been enabled by default * The compiler is now stricter about where it will load module files from when a module is declared via `mod foo;`. * The #[phase(syntax)] attribute has been renamed to #[phase(plugin)]. Syntax extensions are now discovered via a "plugin registrar" type which will be extended in the future to other various plugins. * Lints have been restructured to allow for dynamically loadable lints. * A number of rustdoc improvements: * The HTML output has been visually redesigned. * Markdown is now powered by hoedown instead of sundown. * Searching heuristics have been greatly improved. * The search index has been reduced in size by a great amount. * Cross-crate documentation via `pub use` has been greatly improved. * Primitive types are now hyperlinked and documented. * Documentation has been moved from static.rust-lang.org/doc to doc.rust-lang.org * A new sandbox, play.rust-lang.org, is available for running and sharing rust code examples on-line. * Unused attributes are now more robustly warned about. * The dead_code lint now warns about unused struct fields. * Cross-compiling to iOS is now supported. * Cross-compiling to mipsel is now supported. * Stability attributes are now inherited by default and no longer apply to intra-crate usage, only inter-crate usage. * Error message related to non-exhaustive match expressions have been greatly improved. Contributors to Rust 0.11.0 --------------------------- Aaron Raimist Aaron Turon Adolfo Ochagav?a Adrien T?tar Ahmed Charles Alan Andrade Alan Williams Alex Crichton Alexandre Gagnon Alexei Sholik Ali Smesseim Andrew Gallant Anton L?fgren Arcterus Ariel Ben-Yehuda Axel Viala Ben Noordhuis Benjamin Adamson Benjamin Herr Bj?rn Steinbrink Boris Egorov Brandon Waskiewicz Brendan McLoughlin Brendan Zabarauskas Brian Anderson Cameron Zwarich Chris Morgan Chris Shea Christoph Burgdorf Christopher Bergqvist Christopher Kendell Clark Gaebel Conrad Kleinespel Corey Richardson Daniel Brooks Daniel Fagnan Daniel Micay David Creswick Derek Chiang (Enchi Jiang) Dirk Leifeld Dmitry Promsky Douglas Young Dylan Braithwaite Eduard Bopp Eduard Burtescu Edward Wang Emanuel Rylke Erick Tryzelaar Falco Hirschenberger Falco Hirschenberger Felix S. Klock II Flavio Percoco Florian Gilcher Florian Hartwig Florian Zeitz Gary M. Josack Guillaume Pinot G?bor Lehel Hanno Braun Heather Herman J. Radtke III HeroesGrave Huon Wilson Ivan Petkov J.C. Moyer Jacob Hegna Jakub Wieczorek James Laverack James Miller James Sanders Jeong YunWon Jihyeok Seo Jim Radford John Clements John Fresco John Schmidt John Simon Jonathan Bailey Jonathan Bailey Jonathan Reem Jonathan S Jordi Boggiano Jorge Aparicio Joseph Crail JustAPerson Justin Noah Jyun-Yan You Kang Seonghoon Kasey Carrothers Keegan McAllister Keegan McAllister Kevin Ballard Kevin Butler Kevin Cantu Kiet Tran Liigo Zhuang Luqman Aden Luqman Aden Manish Goregaokar Marvin L?bel Matt Brubeck Meyer S. Jacobs Michael Dagitses Michael Darakananda Michael Fairley Michael Pratt Michael Reinhard Michael Woerister Michael Zhou Mihnea Dobrescu-Balaur Mike Boutin Ms2ger Nathan Typanski Nick Cameron Nicolas Silva Nikita Pekin Niklas Koep Niko Matsakis Noam Yorav-Raphael OGINO Masanori P1start Patrick Walton Paul Stansifer Pawel Olzacki Phil Ruffwind Piotr Czarnecki Piotr Jawniak Randati Raphael Speyer Reilly Watson Renato Riccieri Santos Zannon Renato Zannon Richard Diamond Richo Healey Robert Buonpastore Ryan Mulligan Ryman R?diger Sonderfeld Santiago Rodriguez Sean Gillespie Sean McArthur Seo Sanghyeon Sergio Benitez Simon Sapin Stepan Koltsov Steve Klabnik Steven Fackler Steven Sheldon Sylvestre Ledru Ted Horst Thomas Backman Tim Brooks Timoth?e Ravier Tobba Tobias Bucher Tom Jakubowski Tom Lee TyOverby Utkarsh Kukreti Vadim Chugunov Valentin Tsatskin Valerii Hiora Virgile Andreani Wendell Smith Yehuda Katz Yuri Kunde Schlesner Zach Pomerantz Zooko Wilcox-O'Hearn aochagavia bachm bors fort free-Runner iancormac84 klutzy lucy m-r-r mdinger moonglum mrec theptrk From glaebhoerl at gmail.com Wed Jul 2 11:19:49 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Wed, 2 Jul 2014 20:19:49 +0200 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: Thanks, this is a good step, as is delaying taking actions by a day as proposed in the meeting itself. If you have any suggestions for how this regular email or the process in > general could be improved, please let us know. Most fundamentally, what I'm wondering is, why do most of the things discussed at the meetings need to be discussed separately in the first place? Why not have those discussions directly in the comments for the respective RFC PRs? Up to and including leaving comments like "we suggest closing this, because {justification}, unless someone convinces us otherwise", "we suggest merging this because {justification}", and so on. In an ideal world, the meetings could merely ratify the decisions which were already evident from the PR discussions themselves. This could also help avoid situations where the two discussions end up disjoint in some way, e.g. according to this week's meeting notes @pcwalton and @aturon essentially recapitulated the exact same debate about the lifetime elision "self rule" at the meeting which @aturon and I had previously gone through in the PR comments. >From the proposed-for-discussion list: https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for prefix-style > type parameter lists - ben0x539 > Sugary syntax for putting a group of type parameters and their bounds > before a group of functions. Motivation is our often unwieldly lists of > type parameters. > Not much feedback, but mostly positive. Generally for the motivation, > rather than the solution. > Recommend close in deference to RFC 135 (where clauses) which solve > the motivating problem here, along with other issues. > The two are complementary, not substitutive. 122 allows factoring out type parameter lists for multiple declarations. 135 allows writing them differently. >From the meeting itself, because it concerns process: > > - nrc: Do we want to keep this open? It's the <> to [] changes. > - acrichto: It's so new, I don't think we should close it. > - nrc: Even so, if we're not going to do it, I don't think we should > keep it open. > > I don't see what could have been gained by closing it. Potential scenarios if it's left open: (1) Participants end up convincing each other than the change is not worth doing. (This is what ended up happening in this case.) (2) Contrary to expectations, a consensus emerges in favor of the change. Maybe there is some factor that hadn't been taken into account previously, or the arguments of one side end up convincing the other. I think this might be useful information to have learned. Then you can evaluate the decision on the merits. Whereas if it's closed early: (3) People are left with the opinions they already had, and now might also have the impression that Mozilla has heavy-handedly shut down the debate. I mean, possibly leave a comment like "Just so you know, we are extremely unlikely to do this, but feel free to keep discussing", but I think that was clear to everyone at the outset. I just don't see what could have been gained by preventing the discussion from playing itself out. Cheers, G?bor On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: > Hi all, there have recently been some calls to be more open about the Rust > meetings, in particular to publish the agenda beforehand. The agenda > setting has been quite informal, often not coming together until the > meeting starts. Not to say that we won't publish an agenda in the future, > but that it is not as easy as it might seem. However, as a step towards > that, I will be mailing out the part of the agenda that is set in advance > which is the set of (usually older) RFCs where discussion has mostly ceased > and where we feel we can make a decision on progress. This email is a > relatively new convention in any case. It has been sent to most meeting > attendees at the start of the week. From now on, I'll send it to the > mailing list instead. If you have comments on the RFCs, please comment on > the RFC PR itself, please do not reply to the mailing list. > > Some explanation of the process here - each week there are two Rust > meetings where we discuss RFCs, the general Rust meeting and the triage > meeting. We only accept RFCs at the general meeting. RFCs may be closed at > either meeting. In order to make sure no older RFCs slip through the > cracks, RFCs where discussion has come to a stop (or nearly so) are > recommended each week for discussion. Based on the outcome of the > discussion on the PR and the current goals of the Rust project (in > particular in not accepting any major backwards compatible changes before > 1.0) an RFC will be proposed for discussion at the general meeting if it > needs discussion or we are likely to accept, or to the triage meeting if it > is likely to closed. To clarify, what actually happens to an RFC is decided > at the meeting, not by which meeting it is discussed at. Often, other RFCs > are also discussed at the meetings where attendees think there is a more > urgent need to discuss something. You can see the minutes of the meeting > discussions at https://github.com/rust-lang/meeting-minutes. Not all the > RFCs proposed in this email get discussed at the meetings - either because > we run out of time or because a key person is not at the meeting. > > The 'actions agreed' section keeps track of actions on older RFCs agreed > at previous meetings, but which have not yet been carried out. > > If you have any suggestions for how this regular email or the process in > general could be improved, please let us know. > > Cheers, Nick > > > Proposed for discussion at Rust meeting > --------------------------------------- > > https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and > blocks > huon has updated > should we accept now? > > https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt > No recommendation, just needs a kick to get moving again. > > https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for > module imports - tommit > Allow e.g., `use module::{self, Type};` for `use module::Type; use > module;`. > Generally positive response. Some bike shedding around the use of > `self` since we call the file mod.rs, and some proposal to allow self.rs > instead. > Recommend we accept (possibly we should bikeshed the synax `self`). We > could postpone this (it would be backwards compatible), but it seems very > desirable and would be little effort to implement. > > https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis > A lot of discussion, pretty much all about the details. General > sentiment that we want this. > Recommend we accept - is this the right RFC to accept, I've not really > been keeping track - pnkfelix, pcwalton - is there something which > supersedes this? I think this needs a small update to reflect some of the > later comments. > > https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - > stevelabnik > Loads of opinion in the thread (162 comments!). Note that Niko has an > upcoming RFC with the concept of unsafe/trusted traits where the keyword > `trusted` makes a lot more sense than `unsafe`, so we could save a keyword > here. > Recommend we discuss this. > > https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic > operators to take their arguments by value not by ref - pcwalton. > Pretty negative feedback (though not all). I remember being convinced > this was the proper way to implement arithmetic operators a while back, but > I can't remember why (something about using tuples in the signature maybe? > I can't remember). There seems to be some poor interaction with BigInt, > etc. where implementing for `&BigInt` isn't what you want (but I don't see > why from the comment, pcwalton seems to in his reply though). > Lets discuss this. > > > Proposed for discussion at triage > --------------------------------- > > https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' > pointers (pretty much out params, aiui) - gereeter > A new form of reference, `&uninit`, is added that is write-only and > points to possibly uninitialized data. > Mixed reactions - overall positive, but agreement on low priority. > Recommend close as postponed - was this agreed last week? > > https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - > bmyers > Proposes range types and other complicated stuff, but discusses other > options. > Lots of discussion on integer overflow in general, no agreement. Also > discussed to death on the mailing list several times, including currently. > Recommend close - we might conceivably do something, but we won't do > this and we won't lose anything by closing this RFC (there's also a new RFC > with a different proposal derived from the most recent mailing list thread). > > https://github.com/rust-lang/rfcs/pull/119 - add support to > serialize::json for incrementally reading multiple JSON objects - XMPPwocky > Apparently this is included in RFC 22, which has an implementation. > Recommend close in deference to RFC 22. > > https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as > sugar for nested match statements - bvssvni > Syntax for flattening match statements by 'chaining' arms of a match > statement. > Feedback is mostly negative. Some positive feelings for including the > macro rather than first class syntax. Others want to wait for HKT and have > a function. > Recommend close as postponed. We probably want something like this, > but not pre-1.0. > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for > prefix-style type parameter lists - ben0x539 > Sugary syntax for putting a group of type parameters and their bounds > before a group of functions. Motivation is our often unwieldly lists of > type parameters. > Not much feedback, but mostly positive. Generally for the motivation, > rather than the solution. > Recommend close in deference to RFC 135 (where clauses) which solve > the motivating problem here, along with other issues. > > > Actions agreed > -------------- > > https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of > tagged values - erikt > Changes to the deserialisation framework. Allows for decoding into an > enum. No commentary for or against. > erikt to update? > > https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count > sequence repetitions - Eridius > More discussion - esp, can it be done with a macro > > https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern > matching for slices - krdln > No comments. The RFC is a little bit vague, but seems like kind of a > win. Backwards incompatible. > Close. > > > _______________________________________________ > 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 kevincantu.org Wed Jul 2 11:26:59 2014 From: me at kevincantu.org (Kevin Cantu) Date: Wed, 2 Jul 2014 11:26:59 -0700 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: Possibly some of this is driven by how GitHub automatically spams a large number of people with the conversations. While I'm sure the core team is more patient than me, I don't want to listen to twenty years worth of debate about semicolons in a dead RFC. ;D Kevin On Wed, Jul 2, 2014 at 11:19 AM, G?bor Lehel wrote: > Thanks, this is a good step, as is delaying taking actions by a day as > proposed in the meeting itself. > > > > If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. > > > Most fundamentally, what I'm wondering is, why do most of the things > discussed at the meetings need to be discussed separately in the first > place? > > Why not have those discussions directly in the comments for the respective > RFC PRs? Up to and including leaving comments like "we suggest closing > this, because {justification}, unless someone convinces us otherwise", "we > suggest merging this because {justification}", and so on. In an ideal > world, the meetings could merely ratify the decisions which were already > evident from the PR discussions themselves. This could also help avoid > situations where the two discussions end up disjoint in some way, e.g. > according to this week's meeting notes @pcwalton and @aturon essentially > recapitulated the exact same debate about the lifetime elision "self rule" > at the meeting which @aturon and I had previously gone through in the PR > comments. > > > From the proposed-for-discussion list: > > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> > > The two are complementary, not substitutive. 122 allows factoring out type > parameter lists for multiple declarations. 135 allows writing them > differently. > > > From the meeting itself, because it concerns process: > >> >> - nrc: Do we want to keep this open? It's the <> to [] changes. >> - acrichto: It's so new, I don't think we should close it. >> - nrc: Even so, if we're not going to do it, I don't think we should >> keep it open. >> >> I don't see what could have been gained by closing it. Potential > scenarios if it's left open: > > (1) Participants end up convincing each other than the change is not > worth doing. (This is what ended up happening in this case.) > (2) Contrary to expectations, a consensus emerges in favor of the change. > Maybe there is some factor that hadn't been taken into account previously, > or the arguments of one side end up convincing the other. I think this > might be useful information to have learned. Then you can evaluate the > decision on the merits. > > Whereas if it's closed early: > > (3) People are left with the opinions they already had, and now might > also have the impression that Mozilla has heavy-handedly shut down the > debate. > > I mean, possibly leave a comment like "Just so you know, we are extremely > unlikely to do this, but feel free to keep discussing", but I think that > was clear to everyone at the outset. I just don't see what could have been > gained by preventing the discussion from playing itself out. > > Cheers, > G?bor > > > > On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: > >> Hi all, there have recently been some calls to be more open about the >> Rust meetings, in particular to publish the agenda beforehand. The agenda >> setting has been quite informal, often not coming together until the >> meeting starts. Not to say that we won't publish an agenda in the future, >> but that it is not as easy as it might seem. However, as a step towards >> that, I will be mailing out the part of the agenda that is set in advance >> which is the set of (usually older) RFCs where discussion has mostly ceased >> and where we feel we can make a decision on progress. This email is a >> relatively new convention in any case. It has been sent to most meeting >> attendees at the start of the week. From now on, I'll send it to the >> mailing list instead. If you have comments on the RFCs, please comment on >> the RFC PR itself, please do not reply to the mailing list. >> >> Some explanation of the process here - each week there are two Rust >> meetings where we discuss RFCs, the general Rust meeting and the triage >> meeting. We only accept RFCs at the general meeting. RFCs may be closed at >> either meeting. In order to make sure no older RFCs slip through the >> cracks, RFCs where discussion has come to a stop (or nearly so) are >> recommended each week for discussion. Based on the outcome of the >> discussion on the PR and the current goals of the Rust project (in >> particular in not accepting any major backwards compatible changes before >> 1.0) an RFC will be proposed for discussion at the general meeting if it >> needs discussion or we are likely to accept, or to the triage meeting if it >> is likely to closed. To clarify, what actually happens to an RFC is decided >> at the meeting, not by which meeting it is discussed at. Often, other RFCs >> are also discussed at the meetings where attendees think there is a more >> urgent need to discuss something. You can see the minutes of the meeting >> discussions at https://github.com/rust-lang/meeting-minutes. Not all the >> RFCs proposed in this email get discussed at the meetings - either because >> we run out of time or because a key person is not at the meeting. >> >> The 'actions agreed' section keeps track of actions on older RFCs agreed >> at previous meetings, but which have not yet been carried out. >> >> If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. >> >> Cheers, Nick >> >> >> Proposed for discussion at Rust meeting >> --------------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and >> blocks >> huon has updated >> should we accept now? >> >> https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt >> No recommendation, just needs a kick to get moving again. >> >> https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for >> module imports - tommit >> Allow e.g., `use module::{self, Type};` for `use module::Type; use >> module;`. >> Generally positive response. Some bike shedding around the use of >> `self` since we call the file mod.rs, and some proposal to allow self.rs >> instead. >> Recommend we accept (possibly we should bikeshed the synax `self`). >> We could postpone this (it would be backwards compatible), but it seems >> very desirable and would be little effort to implement. >> >> https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis >> A lot of discussion, pretty much all about the details. General >> sentiment that we want this. >> Recommend we accept - is this the right RFC to accept, I've not >> really been keeping track - pnkfelix, pcwalton - is there something which >> supersedes this? I think this needs a small update to reflect some of the >> later comments. >> >> https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - >> stevelabnik >> Loads of opinion in the thread (162 comments!). Note that Niko has an >> upcoming RFC with the concept of unsafe/trusted traits where the keyword >> `trusted` makes a lot more sense than `unsafe`, so we could save a keyword >> here. >> Recommend we discuss this. >> >> https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic >> operators to take their arguments by value not by ref - pcwalton. >> Pretty negative feedback (though not all). I remember being convinced >> this was the proper way to implement arithmetic operators a while back, but >> I can't remember why (something about using tuples in the signature maybe? >> I can't remember). There seems to be some poor interaction with BigInt, >> etc. where implementing for `&BigInt` isn't what you want (but I don't see >> why from the comment, pcwalton seems to in his reply though). >> Lets discuss this. >> >> >> Proposed for discussion at triage >> --------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' >> pointers (pretty much out params, aiui) - gereeter >> A new form of reference, `&uninit`, is added that is write-only and >> points to possibly uninitialized data. >> Mixed reactions - overall positive, but agreement on low priority. >> Recommend close as postponed - was this agreed last week? >> >> https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - >> bmyers >> Proposes range types and other complicated stuff, but discusses other >> options. >> Lots of discussion on integer overflow in general, no agreement. Also >> discussed to death on the mailing list several times, including currently. >> Recommend close - we might conceivably do something, but we won't do >> this and we won't lose anything by closing this RFC (there's also a new RFC >> with a different proposal derived from the most recent mailing list thread). >> >> https://github.com/rust-lang/rfcs/pull/119 - add support to >> serialize::json for incrementally reading multiple JSON objects - XMPPwocky >> Apparently this is included in RFC 22, which has an implementation. >> Recommend close in deference to RFC 22. >> >> https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as >> sugar for nested match statements - bvssvni >> Syntax for flattening match statements by 'chaining' arms of a match >> statement. >> Feedback is mostly negative. Some positive feelings for including the >> macro rather than first class syntax. Others want to wait for HKT and have >> a function. >> Recommend close as postponed. We probably want something like this, >> but not pre-1.0. >> >> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> >> >> Actions agreed >> -------------- >> >> https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of >> tagged values - erikt >> Changes to the deserialisation framework. Allows for decoding into an >> enum. No commentary for or against. >> erikt to update? >> >> https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count >> sequence repetitions - Eridius >> More discussion - esp, can it be done with a macro >> >> https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern >> matching for slices - krdln >> No comments. The RFC is a little bit vague, but seems like kind of a >> win. Backwards incompatible. >> Close. >> >> >> _______________________________________________ >> 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 banderson at mozilla.com Wed Jul 2 11:56:09 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 02 Jul 2014 11:56:09 -0700 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: <53B455C9.1060507@mozilla.com> On 07/02/2014 11:19 AM, G?bor Lehel wrote: > Thanks, this is a good step, as is delaying taking actions by a day as > proposed in the meeting itself. > > > If you have any suggestions for how this regular email or the > process in general could be improved, please let us know. > > > Most fundamentally, what I'm wondering is, why do most of the things > discussed at the meetings need to be discussed separately in the first > place? > > Why not have those discussions directly in the comments for the > respective RFC PRs? Up to and including leaving comments like "we > suggest closing this, because {justification}, unless someone > convinces us otherwise", "we suggest merging this because > {justification}", and so on. In an ideal world, the meetings could > merely ratify the decisions which were already evident from the PR > discussions themselves. This could also help avoid situations where > the two discussions end up disjoint in some way, e.g. according to > this week's meeting notes @pcwalton and @aturon essentially > recapitulated the exact same debate about the lifetime elision "self > rule" at the meeting which @aturon and I had previously gone through > in the PR comments. I would like to move in this direction, but like many cultural changes it will be gradual. The primary reason we do so much in meetings is because face-to-face discussions move much faster and involve much less argumentation than asynchronous online discussions. In the immediate future I'd like to put more pressure on meeting participants to express their opinions on the issue ahead of meetings, which this initiative Nick is working on helps by making it clear what issues are coming up. > > > From the proposed-for-discussion list: > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for > prefix-style type parameter lists - ben0x539 > Sugary syntax for putting a group of type parameters and their > bounds before a group of functions. Motivation is our often > unwieldly lists of type parameters. > Not much feedback, but mostly positive. Generally for the > motivation, rather than the solution. > Recommend close in deference to RFC 135 (where clauses) which > solve the motivating problem here, along with other issues. > > > The two are complementary, not substitutive. 122 allows factoring out > type parameter lists for multiple declarations. 135 allows writing > them differently. > > > From the meeting itself, because it concerns process: > > * nrc: Do we want to keep this open? It's the |<>| to |[]| changes. > * acrichto: It's so new, I don't think we should close it. > * nrc: Even so, if we're not going to do it, I don't think we > should keep it open. > > I don't see what could have been gained by closing it. Potential > scenarios if it's left open: > > (1) Participants end up convincing each other than the change is not > worth doing. (This is what ended up happening in this case.) > (2) Contrary to expectations, a consensus emerges in favor of the > change. Maybe there is some factor that hadn't been taken into account > previously, or the arguments of one side end up convincing the other. > I think this might be useful information to have learned. Then you can > evaluate the decision on the merits. > > Whereas if it's closed early: > > (3) People are left with the opinions they already had, and now might > also have the impression that Mozilla has heavy-handedly shut down the > debate. > > I mean, possibly leave a comment like "Just so you know, we are > extremely unlikely to do this, but feel free to keep discussing", but > I think that was clear to everyone at the outset. I just don't see > what could have been gained by preventing the discussion from playing > itself out. > > Cheers, > G?bor > > > > On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron > wrote: > > Hi all, there have recently been some calls to be more open about > the Rust meetings, in particular to publish the agenda beforehand. > The agenda setting has been quite informal, often not coming > together until the meeting starts. Not to say that we won't > publish an agenda in the future, but that it is not as easy as it > might seem. However, as a step towards that, I will be mailing out > the part of the agenda that is set in advance which is the set of > (usually older) RFCs where discussion has mostly ceased and where > we feel we can make a decision on progress. This email is a > relatively new convention in any case. It has been sent to most > meeting attendees at the start of the week. From now on, I'll send > it to the mailing list instead. If you have comments on the RFCs, > please comment on the RFC PR itself, please do not reply to the > mailing list. > > Some explanation of the process here - each week there are two > Rust meetings where we discuss RFCs, the general Rust meeting and > the triage meeting. We only accept RFCs at the general meeting. > RFCs may be closed at either meeting. In order to make sure no > older RFCs slip through the cracks, RFCs where discussion has come > to a stop (or nearly so) are recommended each week for discussion. > Based on the outcome of the discussion on the PR and the current > goals of the Rust project (in particular in not accepting any > major backwards compatible changes before 1.0) an RFC will be > proposed for discussion at the general meeting if it needs > discussion or we are likely to accept, or to the triage meeting if > it is likely to closed. To clarify, what actually happens to an > RFC is decided at the meeting, not by which meeting it is > discussed at. Often, other RFCs are also discussed at the meetings > where attendees think there is a more urgent need to discuss > something. You can see the minutes of the meeting discussions at > https://github.com/rust-lang/meeting-minutes. Not all the RFCs > proposed in this email get discussed at the meetings - either > because we run out of time or because a key person is not at the > meeting. > > The 'actions agreed' section keeps track of actions on older RFCs > agreed at previous meetings, but which have not yet been carried out. > > If you have any suggestions for how this regular email or the > process in general could be improved, please let us know. > > Cheers, Nick > > > Proposed for discussion at Rust meeting > --------------------------------------- > > https://github.com/rust-lang/rfcs/pull/16 - attributes on > statements and blocks > huon has updated > should we accept now? > > https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family > - erikt > No recommendation, just needs a kick to get moving again. > > https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax > for module imports - tommit > Allow e.g., `use module::{self, Type};` for `use module::Type; > use module;`. > Generally positive response. Some bike shedding around the use > of `self` since we call the file mod.rs , and some > proposal to allow self.rs instead. > Recommend we accept (possibly we should bikeshed the synax > `self`). We could postpone this (it would be backwards > compatible), but it seems very desirable and would be little > effort to implement. > > https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - > nmatsakis > A lot of discussion, pretty much all about the details. > General sentiment that we want this. > Recommend we accept - is this the right RFC to accept, I've > not really been keeping track - pnkfelix, pcwalton - is there > something which supersedes this? I think this needs a small update > to reflect some of the later comments. > > https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to > trusted - stevelabnik > Loads of opinion in the thread (162 comments!). Note that Niko > has an upcoming RFC with the concept of unsafe/trusted traits > where the keyword `trusted` makes a lot more sense than `unsafe`, > so we could save a keyword here. > Recommend we discuss this. > > https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic > operators to take their arguments by value not by ref - pcwalton. > Pretty negative feedback (though not all). I remember being > convinced this was the proper way to implement arithmetic > operators a while back, but I can't remember why (something about > using tuples in the signature maybe? I can't remember). There > seems to be some poor interaction with BigInt, etc. where > implementing for `&BigInt` isn't what you want (but I don't see > why from the comment, pcwalton seems to in his reply though). > Lets discuss this. > > > Proposed for discussion at triage > --------------------------------- > > https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe > initialised' pointers (pretty much out params, aiui) - gereeter > A new form of reference, `&uninit`, is added that is > write-only and points to possibly uninitialized data. > Mixed reactions - overall positive, but agreement on low priority. > Recommend close as postponed - was this agreed last week? > > https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer > overflow - bmyers > Proposes range types and other complicated stuff, but > discusses other options. > Lots of discussion on integer overflow in general, no > agreement. Also discussed to death on the mailing list several > times, including currently. > Recommend close - we might conceivably do something, but we > won't do this and we won't lose anything by closing this RFC > (there's also a new RFC with a different proposal derived from the > most recent mailing list thread). > > https://github.com/rust-lang/rfcs/pull/119 - add support to > serialize::json for incrementally reading multiple JSON objects - > XMPPwocky > Apparently this is included in RFC 22, which has an > implementation. > Recommend close in deference to RFC 22. > > https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' > keyword as sugar for nested match statements - bvssvni > Syntax for flattening match statements by 'chaining' arms of a > match statement. > Feedback is mostly negative. Some positive feelings for > including the macro rather than first class syntax. Others want to > wait for HKT and have a function. > Recommend close as postponed. We probably want something like > this, but not pre-1.0. > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for > prefix-style type parameter lists - ben0x539 > Sugary syntax for putting a group of type parameters and their > bounds before a group of functions. Motivation is our often > unwieldly lists of type parameters. > Not much feedback, but mostly positive. Generally for the > motivation, rather than the solution. > Recommend close in deference to RFC 135 (where clauses) which > solve the motivating problem here, along with other issues. > > > Actions agreed > -------------- > > https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a > stream of tagged values - erikt > Changes to the deserialisation framework. Allows for decoding > into an enum. No commentary for or against. > erikt to update? > > https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count > sequence repetitions - Eridius > More discussion - esp, can it be done with a macro > > https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern > matching for slices - krdln > No comments. The RFC is a little bit vague, but seems like > kind of a win. Backwards incompatible. > Close. > > > _______________________________________________ > 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 slabode at aim.com Wed Jul 2 12:33:38 2014 From: slabode at aim.com (SiegeLordEx) Date: Wed, 02 Jul 2014 15:33:38 -0400 Subject: [rust-dev] =?utf-8?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_=C3=98M?= =?utf-8?q?Q_in_Rus?= In-Reply-To: References: Message-ID: <53B45E92.7060908@aim.com> On 07/02/2014 03:16 AM, Corey Richardson wrote: > Complaining about something I don't like: > > Due to the choice of MPLv2, this won't be usable in the wider Rust > ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) > requires that any distribution in "Executable Form" carry a notice > about how to acquire the source code of zmq.rs. This is not > unworkable, but it is something we have avoided so far in the > community. I should note that this is not a universally held opinion in the Rust community. While it is true that many/most current Rust projects mimic the license of `rustc` itself, there's nothing in Rust as a language that precludes or encourages the use of any particular license. The mentioned 'avoidance' is likely a consequence of the people just preferring those licenses (i.e. they'd use them for their non-Rust projects as well) rather than Rust being against the spirit of attribution, share-alike, copyleft etc per se. Personally, I would encourage Free Rust software just like I would encourage it in any other language. You shouldn't feel like you need to compromise on your moral principles (or whatever else you consult when choosing a license) to contribute to Rust's success. -SL From corey at octayn.net Wed Jul 2 13:55:04 2014 From: corey at octayn.net (Corey Richardson) Date: Wed, 2 Jul 2014 13:55:04 -0700 Subject: [rust-dev] =?utf-8?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_=C3=98M?= =?utf-8?q?Q_in_Rus?= In-Reply-To: <53B45E92.7060908@aim.com> References: <53B45E92.7060908@aim.com> Message-ID: See also the discussion on IRC: https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232&page=22 It wasn't my intention to discourage using any particular license, but to raise its requirements if they weren't consciously chosen. On Wed, Jul 2, 2014 at 12:33 PM, SiegeLordEx wrote: > On 07/02/2014 03:16 AM, Corey Richardson wrote: >> >> Complaining about something I don't like: >> >> Due to the choice of MPLv2, this won't be usable in the wider Rust >> ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) >> requires that any distribution in "Executable Form" carry a notice >> about how to acquire the source code of zmq.rs. This is not >> unworkable, but it is something we have avoided so far in the >> community. > > > I should note that this is not a universally held opinion in the Rust > community. While it is true that many/most current Rust projects mimic the > license of `rustc` itself, there's nothing in Rust as a language that > precludes or encourages the use of any particular license. The mentioned > 'avoidance' is likely a consequence of the people just preferring those > licenses (i.e. they'd use them for their non-Rust projects as well) rather > than Rust being against the spirit of attribution, share-alike, copyleft etc > per se. > > Personally, I would encourage Free Rust software just like I would encourage > it in any other language. You shouldn't feel like you need to compromise on > your moral principles (or whatever else you consult when choosing a license) > to contribute to Rust's success. > > -SL > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From lists at ncameron.org Wed Jul 2 14:05:57 2014 From: lists at ncameron.org (Nick Cameron) Date: Thu, 3 Jul 2014 09:05:57 +1200 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: On Thu, Jul 3, 2014 at 6:19 AM, G?bor Lehel wrote: > Thanks, this is a good step, as is delaying taking actions by a day as > proposed in the meeting itself. > > > > If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. > > > Most fundamentally, what I'm wondering is, why do most of the things > discussed at the meetings need to be discussed separately in the first > place? > > Why not have those discussions directly in the comments for the respective > RFC PRs? Up to and including leaving comments like "we suggest closing > this, because {justification}, unless someone convinces us otherwise", "we > suggest merging this because {justification}", and so on. In an ideal > world, the meetings could merely ratify the decisions which were already > evident from the PR discussions themselves. This could also help avoid > situations where the two discussions end up disjoint in some way, e.g. > according to this week's meeting notes @pcwalton and @aturon essentially > recapitulated the exact same debate about the lifetime elision "self rule" > at the meeting which @aturon and I had previously gone through in the PR > comments. > > > From the proposed-for-discussion list: > > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> > > The two are complementary, not substitutive. 122 allows factoring out type > parameter lists for multiple declarations. 135 allows writing them > differently. > > Please comment on the RFCs rather than replying to the mailing list. I'll make a note of this, but in the general case, I guarantee that replies to the mailing list will get lost or forgotten. I agree the two RFCs are not substitutive and could both be accepted, but they do both tackle the same problem (ugly type param lists). > > From the meeting itself, because it concerns process: > >> >> - nrc: Do we want to keep this open? It's the <> to [] changes. >> - acrichto: It's so new, I don't think we should close it. >> - nrc: Even so, if we're not going to do it, I don't think we should >> keep it open. >> >> I don't see what could have been gained by closing it. Potential > scenarios if it's left open: > > (1) Participants end up convincing each other than the change is not > worth doing. (This is what ended up happening in this case.) > (2) Contrary to expectations, a consensus emerges in favor of the change. > Maybe there is some factor that hadn't been taken into account previously, > or the arguments of one side end up convincing the other. I think this > might be useful information to have learned. Then you can evaluate the > decision on the merits. > > Whereas if it's closed early: > > (3) People are left with the opinions they already had, and now might > also have the impression that Mozilla has heavy-handedly shut down the > debate. > > I mean, possibly leave a comment like "Just so you know, we are extremely > unlikely to do this, but feel free to keep discussing", but I think that > was clear to everyone at the outset. I just don't see what could have been > gained by preventing the discussion from playing itself out. > > We will (at some point) have a separate discussion on the policy, as was briefly touched upon in the meeting we decided it was a policy question and we shouldn't do anything in this case. My motivation for early closure of some RFCs is to be honest - I don't want to waste people's time, energy, or emotional investment arguing about it if they have the (false) impression that it might change. As you suggest leaving a comment and leaving the RFC open is probably a better way to do this (although you can still comment on a closed PR, so I'm not sure there is really much difference, other than whether the RFC shows up in the list of open PRs). Another reason is simply that I don't like to see pointless arguing, and I feel that on RFCs like this which come down to taste, it really is arguing and not discussion. I think the Rust community would be a better place without it. Of course, I could just ignore the GitHub spam, but I would rather the arguing just doesn't happen. FWIW, your point 1 is very valid and probably outweighs my points, just saying that there are other disadvantages. The chance of 2 happening in a case like this seems so small that I wouldn't worry about it. Cheers, Nick Cheers, > G?bor > > > > On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: > >> Hi all, there have recently been some calls to be more open about the >> Rust meetings, in particular to publish the agenda beforehand. The agenda >> setting has been quite informal, often not coming together until the >> meeting starts. Not to say that we won't publish an agenda in the future, >> but that it is not as easy as it might seem. However, as a step towards >> that, I will be mailing out the part of the agenda that is set in advance >> which is the set of (usually older) RFCs where discussion has mostly ceased >> and where we feel we can make a decision on progress. This email is a >> relatively new convention in any case. It has been sent to most meeting >> attendees at the start of the week. From now on, I'll send it to the >> mailing list instead. If you have comments on the RFCs, please comment on >> the RFC PR itself, please do not reply to the mailing list. >> >> Some explanation of the process here - each week there are two Rust >> meetings where we discuss RFCs, the general Rust meeting and the triage >> meeting. We only accept RFCs at the general meeting. RFCs may be closed at >> either meeting. In order to make sure no older RFCs slip through the >> cracks, RFCs where discussion has come to a stop (or nearly so) are >> recommended each week for discussion. Based on the outcome of the >> discussion on the PR and the current goals of the Rust project (in >> particular in not accepting any major backwards compatible changes before >> 1.0) an RFC will be proposed for discussion at the general meeting if it >> needs discussion or we are likely to accept, or to the triage meeting if it >> is likely to closed. To clarify, what actually happens to an RFC is decided >> at the meeting, not by which meeting it is discussed at. Often, other RFCs >> are also discussed at the meetings where attendees think there is a more >> urgent need to discuss something. You can see the minutes of the meeting >> discussions at https://github.com/rust-lang/meeting-minutes. Not all the >> RFCs proposed in this email get discussed at the meetings - either because >> we run out of time or because a key person is not at the meeting. >> >> The 'actions agreed' section keeps track of actions on older RFCs agreed >> at previous meetings, but which have not yet been carried out. >> >> If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. >> >> Cheers, Nick >> >> >> Proposed for discussion at Rust meeting >> --------------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and >> blocks >> huon has updated >> should we accept now? >> >> https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt >> No recommendation, just needs a kick to get moving again. >> >> https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for >> module imports - tommit >> Allow e.g., `use module::{self, Type};` for `use module::Type; use >> module;`. >> Generally positive response. Some bike shedding around the use of >> `self` since we call the file mod.rs, and some proposal to allow self.rs >> instead. >> Recommend we accept (possibly we should bikeshed the synax `self`). >> We could postpone this (it would be backwards compatible), but it seems >> very desirable and would be little effort to implement. >> >> https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis >> A lot of discussion, pretty much all about the details. General >> sentiment that we want this. >> Recommend we accept - is this the right RFC to accept, I've not >> really been keeping track - pnkfelix, pcwalton - is there something which >> supersedes this? I think this needs a small update to reflect some of the >> later comments. >> >> https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - >> stevelabnik >> Loads of opinion in the thread (162 comments!). Note that Niko has an >> upcoming RFC with the concept of unsafe/trusted traits where the keyword >> `trusted` makes a lot more sense than `unsafe`, so we could save a keyword >> here. >> Recommend we discuss this. >> >> https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic >> operators to take their arguments by value not by ref - pcwalton. >> Pretty negative feedback (though not all). I remember being convinced >> this was the proper way to implement arithmetic operators a while back, but >> I can't remember why (something about using tuples in the signature maybe? >> I can't remember). There seems to be some poor interaction with BigInt, >> etc. where implementing for `&BigInt` isn't what you want (but I don't see >> why from the comment, pcwalton seems to in his reply though). >> Lets discuss this. >> >> >> Proposed for discussion at triage >> --------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' >> pointers (pretty much out params, aiui) - gereeter >> A new form of reference, `&uninit`, is added that is write-only and >> points to possibly uninitialized data. >> Mixed reactions - overall positive, but agreement on low priority. >> Recommend close as postponed - was this agreed last week? >> >> https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - >> bmyers >> Proposes range types and other complicated stuff, but discusses other >> options. >> Lots of discussion on integer overflow in general, no agreement. Also >> discussed to death on the mailing list several times, including currently. >> Recommend close - we might conceivably do something, but we won't do >> this and we won't lose anything by closing this RFC (there's also a new RFC >> with a different proposal derived from the most recent mailing list thread). >> >> https://github.com/rust-lang/rfcs/pull/119 - add support to >> serialize::json for incrementally reading multiple JSON objects - XMPPwocky >> Apparently this is included in RFC 22, which has an implementation. >> Recommend close in deference to RFC 22. >> >> https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as >> sugar for nested match statements - bvssvni >> Syntax for flattening match statements by 'chaining' arms of a match >> statement. >> Feedback is mostly negative. Some positive feelings for including the >> macro rather than first class syntax. Others want to wait for HKT and have >> a function. >> Recommend close as postponed. We probably want something like this, >> but not pre-1.0. >> >> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> >> >> Actions agreed >> -------------- >> >> https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of >> tagged values - erikt >> Changes to the deserialisation framework. Allows for decoding into an >> enum. No commentary for or against. >> erikt to update? >> >> https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count >> sequence repetitions - Eridius >> More discussion - esp, can it be done with a macro >> >> https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern >> matching for slices - krdln >> No comments. The RFC is a little bit vague, but seems like kind of a >> win. Backwards incompatible. >> Close. >> >> >> _______________________________________________ >> 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 dnfagnan at gmail.com Wed Jul 2 14:29:05 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Wed, 2 Jul 2014 15:29:05 -0600 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: I never thought a change like the one I proposed would be accepted. That was until a few people also supported the idea so it was a shot in the dark. My motivation for the rfc was the supposed elimination of the ambiguities that the current syntax has. I mistakenly overlooked the conflict with the array syntax. I still think [] is better than <> , but for Rust, there's no convincing objective argument for such a change. Thus, if the rfc was kept open, it would be subjective argument leading to nowhere. I definitely don't want to participate in such argument, because it becomes a waste of time. I'm convinced that the current syntax needs to stay because we simply don't get any tangible benefits. So I closed the rfc. On Jul 2, 2014 12:19 PM, "G?bor Lehel" wrote: > Thanks, this is a good step, as is delaying taking actions by a day as > proposed in the meeting itself. > > > If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. > > > Most fundamentally, what I'm wondering is, why do most of the things > discussed at the meetings need to be discussed separately in the first > place? > > Why not have those discussions directly in the comments for the respective > RFC PRs? Up to and including leaving comments like "we suggest closing > this, because {justification}, unless someone convinces us otherwise", "we > suggest merging this because {justification}", and so on. In an ideal > world, the meetings could merely ratify the decisions which were already > evident from the PR discussions themselves. This could also help avoid > situations where the two discussions end up disjoint in some way, e.g. > according to this week's meeting notes @pcwalton and @aturon essentially > recapitulated the exact same debate about the lifetime elision "self rule" > at the meeting which @aturon and I had previously gone through in the PR > comments. > > > From the proposed-for-discussion list: > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> > > The two are complementary, not substitutive. 122 allows factoring out type > parameter lists for multiple declarations. 135 allows writing them > differently. > > > From the meeting itself, because it concerns process: > >> >> - nrc: Do we want to keep this open? It's the <> to [] changes. >> - acrichto: It's so new, I don't think we should close it. >> - nrc: Even so, if we're not going to do it, I don't think we should >> keep it open. >> >> I don't see what could have been gained by closing it. Potential > scenarios if it's left open: > > (1) Participants end up convincing each other than the change is not > worth doing. (This is what ended up happening in this case.) > (2) Contrary to expectations, a consensus emerges in favor of the change. > Maybe there is some factor that hadn't been taken into account previously, > or the arguments of one side end up convincing the other. I think this > might be useful information to have learned. Then you can evaluate the > decision on the merits. > > Whereas if it's closed early: > > (3) People are left with the opinions they already had, and now might > also have the impression that Mozilla has heavy-handedly shut down the > debate. > > I mean, possibly leave a comment like "Just so you know, we are extremely > unlikely to do this, but feel free to keep discussing", but I think that > was clear to everyone at the outset. I just don't see what could have been > gained by preventing the discussion from playing itself out. > > Cheers, > G?bor > > > > On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: > >> Hi all, there have recently been some calls to be more open about the >> Rust meetings, in particular to publish the agenda beforehand. The agenda >> setting has been quite informal, often not coming together until the >> meeting starts. Not to say that we won't publish an agenda in the future, >> but that it is not as easy as it might seem. However, as a step towards >> that, I will be mailing out the part of the agenda that is set in advance >> which is the set of (usually older) RFCs where discussion has mostly ceased >> and where we feel we can make a decision on progress. This email is a >> relatively new convention in any case. It has been sent to most meeting >> attendees at the start of the week. From now on, I'll send it to the >> mailing list instead. If you have comments on the RFCs, please comment on >> the RFC PR itself, please do not reply to the mailing list. >> >> Some explanation of the process here - each week there are two Rust >> meetings where we discuss RFCs, the general Rust meeting and the triage >> meeting. We only accept RFCs at the general meeting. RFCs may be closed at >> either meeting. In order to make sure no older RFCs slip through the >> cracks, RFCs where discussion has come to a stop (or nearly so) are >> recommended each week for discussion. Based on the outcome of the >> discussion on the PR and the current goals of the Rust project (in >> particular in not accepting any major backwards compatible changes before >> 1.0) an RFC will be proposed for discussion at the general meeting if it >> needs discussion or we are likely to accept, or to the triage meeting if it >> is likely to closed. To clarify, what actually happens to an RFC is decided >> at the meeting, not by which meeting it is discussed at. Often, other RFCs >> are also discussed at the meetings where attendees think there is a more >> urgent need to discuss something. You can see the minutes of the meeting >> discussions at https://github.com/rust-lang/meeting-minutes. Not all the >> RFCs proposed in this email get discussed at the meetings - either because >> we run out of time or because a key person is not at the meeting. >> >> The 'actions agreed' section keeps track of actions on older RFCs agreed >> at previous meetings, but which have not yet been carried out. >> >> If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. >> >> Cheers, Nick >> >> >> Proposed for discussion at Rust meeting >> --------------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and >> blocks >> huon has updated >> should we accept now? >> >> https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt >> No recommendation, just needs a kick to get moving again. >> >> https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for >> module imports - tommit >> Allow e.g., `use module::{self, Type};` for `use module::Type; use >> module;`. >> Generally positive response. Some bike shedding around the use of >> `self` since we call the file mod.rs, and some proposal to allow self.rs >> instead. >> Recommend we accept (possibly we should bikeshed the synax `self`). >> We could postpone this (it would be backwards compatible), but it seems >> very desirable and would be little effort to implement. >> >> https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis >> A lot of discussion, pretty much all about the details. General >> sentiment that we want this. >> Recommend we accept - is this the right RFC to accept, I've not >> really been keeping track - pnkfelix, pcwalton - is there something which >> supersedes this? I think this needs a small update to reflect some of the >> later comments. >> >> https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - >> stevelabnik >> Loads of opinion in the thread (162 comments!). Note that Niko has an >> upcoming RFC with the concept of unsafe/trusted traits where the keyword >> `trusted` makes a lot more sense than `unsafe`, so we could save a keyword >> here. >> Recommend we discuss this. >> >> https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic >> operators to take their arguments by value not by ref - pcwalton. >> Pretty negative feedback (though not all). I remember being convinced >> this was the proper way to implement arithmetic operators a while back, but >> I can't remember why (something about using tuples in the signature maybe? >> I can't remember). There seems to be some poor interaction with BigInt, >> etc. where implementing for `&BigInt` isn't what you want (but I don't see >> why from the comment, pcwalton seems to in his reply though). >> Lets discuss this. >> >> >> Proposed for discussion at triage >> --------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' >> pointers (pretty much out params, aiui) - gereeter >> A new form of reference, `&uninit`, is added that is write-only and >> points to possibly uninitialized data. >> Mixed reactions - overall positive, but agreement on low priority. >> Recommend close as postponed - was this agreed last week? >> >> https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - >> bmyers >> Proposes range types and other complicated stuff, but discusses other >> options. >> Lots of discussion on integer overflow in general, no agreement. Also >> discussed to death on the mailing list several times, including currently. >> Recommend close - we might conceivably do something, but we won't do >> this and we won't lose anything by closing this RFC (there's also a new RFC >> with a different proposal derived from the most recent mailing list thread). >> >> https://github.com/rust-lang/rfcs/pull/119 - add support to >> serialize::json for incrementally reading multiple JSON objects - XMPPwocky >> Apparently this is included in RFC 22, which has an implementation. >> Recommend close in deference to RFC 22. >> >> https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as >> sugar for nested match statements - bvssvni >> Syntax for flattening match statements by 'chaining' arms of a match >> statement. >> Feedback is mostly negative. Some positive feelings for including the >> macro rather than first class syntax. Others want to wait for HKT and have >> a function. >> Recommend close as postponed. We probably want something like this, >> but not pre-1.0. >> >> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> >> >> Actions agreed >> -------------- >> >> https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of >> tagged values - erikt >> Changes to the deserialisation framework. Allows for decoding into an >> enum. No commentary for or against. >> erikt to update? >> >> https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count >> sequence repetitions - Eridius >> More discussion - esp, can it be done with a macro >> >> https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern >> matching for slices - krdln >> No comments. The RFC is a little bit vague, but seems like kind of a >> win. Backwards incompatible. >> Close. >> >> >> _______________________________________________ >> 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 ben.striegel at gmail.com Wed Jul 2 14:42:21 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 2 Jul 2014 17:42:21 -0400 Subject: [rust-dev] Rust 0.11.0 Released In-Reply-To: References: Message-ID: Well done! 1.0 draws closer every day. I'm giddy with anticipation. On Wed, Jul 2, 2014 at 2:07 PM, Alex Crichton wrote: > Mozilla and the Rust community are pleased to announce version 0.11.0 of > the Rust compiler and tools. Rust is a systems programming language with a > focus on safety, performance and concurrency. > > While this was a very active development cycle, it was largely focused on > polishing the type system and libraries. The major technical focuses this > time were implementing infrastructure for dynamically sized types and > refactoring the standard library. This release also marks the complete > removal of the `~` and `@` syntax in favor of library types `Box` and > `Gc`. > > The brief release notes are included in this announcement, and there is > further explanation in the detailed release [notes] on the wiki. > Documentation and all the links in this email are available on the > [website]. As usual, version 0.11.0 should be considered an alpha release, > suitable for early adopters and language enthusiasts. Please file [bugs] > and join the [fun]. > > [website]: http://www.rust-lang.org > [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes > [bugs]: https://github.com/mozilla/rust/issues > [fun]: > https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors > > Source > > * http://static.rust-lang.org/dist/rust-0.11.0.tar.gz > http://static.rust-lang.org/dist/rust-0.11.0.tar.gz.asc > SHA256 (of .tar.gz): > d1b3e36448bf12b8c9289024df416de10774b6d3235d7b1d22b248ef634411ba > > Windows installer > > * http://static.rust-lang.org/dist/rust-0.11.0-install.exe > http://static.rust-lang.org/dist/rust-0.11.0-install.exe.asc > SHA256 (of .exe): > fb253072ba5373eb0af388f63e51122af9dd13379d762ca4100ee7334dbec9d2 > > Linux binary tarballs > > * > http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz > > http://static.rust-lang.org/dist/rust-0.11.0-x86_64-unknown-linux-gnu.tar.gz.asc > SHA256 (of .tar.gz): > 331d6374b3c8fca3e2b5fffb65ce75dfce3529bd47333de4a9ce636cb87be432 > > * > http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz > > http://static.rust-lang.org/dist/rust-0.11.0-i686-unknown-linux-gnu.tar.gz.asc > SHA256 (of .tar.gz): > cbfe2050f708479f2625a935d2f41165868f354ff740d2697e08acb2255670b2 > > Mac OS X binary installers > > * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg > http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.pkg.asc > SHA256 (of .pkg): > 1183d6c8ab021f4049a2906c1527f705bae4bb4935aea897f4860eb5337363c3 > > * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg > http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.pkg.asc > SHA256 (of .pkg): > 8f5a1fe491d83c6be0a3082f0ac8504c89eed38263ae0ac0fad15d8c02e3b267 > > Mac OS X binary tarballs > > * http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz > > http://static.rust-lang.org/dist/rust-0.11.0-x86_64-apple-darwin.tar.gz.asc > SHA256 (of .tar.gz): > bbac91aff5464c20f39afcf078a693c4612717d6b1cc3f86f92075b2103bc22e > > * http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz > > http://static.rust-lang.org/dist/rust-0.11.0-i686-apple-darwin.tar.gz.asc > SHA256 (of .tar.gz): > 93d6e6e98d00df3e946e4f7765172ad522a118dd34f1fac73ba74d43df92698b > > Thanks to everyone who contributed! > > Regards, > The Rust Team > > Version 0.11.0 (July 2014) > ------------------------- > > * ~1700 changes, numerous bugfixes > > * Language > * ~[T] has been removed from the language. This type is superseded by > the Vec type. > * ~str has been removed from the language. This type is superseded by > the String type. > * ~T has been removed from the language. This type is superseded by the > Box type. > * @T has been removed from the language. This type is superseded by the > standard library's std::gc::Gc type. > * Struct fields are now all private by default. > * Vector indices and shift amounts are both required to be a `uint` > instead of any integral type. > * Byte character, byte string, and raw byte string literals are now all > supported by prefixing the normal literal with a `b`. > * Multiple ABIs are no longer allowed in an ABI string > * The syntax for lifetimes on closures/procedures has been tweaked > slightly: `<'a>|A, B|: 'b + K -> T` > * Floating point modulus has been removed from the language; however it > is still provided by a library implementation. > * Private enum variants are now disallowed. > * The `priv` keyword has been removed from the language. > * A closure can no longer be invoked through a &-pointer. > * The `use foo, bar, baz;` syntax has been removed from the language. > * The transmute intrinsic no longer works on type parameters. > * Statics now allow blocks/items in their definition. > * Trait bounds are separated from objects with + instead of : now. > * Objects can no longer be read while they are mutably borrowed. > * The address of a static is now marked as insignificant unless the > #[inline(never)] attribute is placed it. > * The #[unsafe_destructor] attribute is now behind a feature gate. > * Struct literals are no longer allowed in ambiguous positions such as > if, while, match, and for..in. > * Declaration of lang items and intrinsics are now feature-gated by > default. > * Integral literals no longer default to `int`, and floating point > literals no longer default to `f64`. Literals must be suffixed with > an > appropriate type if inference cannot determine the type of the > literal. > * The Box type is no longer implicitly borrowed to &mut T. > * Procedures are now required to not capture borrowed references. > > * Libraries > * The standard library is now a "facade" over a number of underlying > libraries. This means that development on the standard library should > be speeder due to smaller crates, as well as a clearer line between > all dependencies. > * A new library, libcore, lives under the standard library's facade > which is Rust's "0-assumption" library, suitable for embedded and > kernel development for example. > * A regex crate has been added to the standard distribution. This crate > includes statically compiled regular expressions. > * The unwrap/unwrap_err methods on Result require a Show bound for > better error messages. > * The return types of the std::comm primitives have been centralized > around the Result type. > * A number of I/O primitives have gained the ability to time out their > operations. > * A number of I/O primitives have gained the ability to close their > reading/writing halves to cancel pending operations. > * Reverse iterator methods have been removed in favor of `rev()` on > their forward-iteration counterparts. > * A bitflags! macro has been added to enable easy interop with C and > management of bit flags. > * A debug_assert! macro is now provided which is disabled when > `--cfg ndebug` is passed to the compiler. > * A graphviz crate has been added for creating .dot files. > * The std::cast module has been migrated into std::mem. > * The std::local_data api has been migrated from freestanding functions > to being based on methods. > * The Pod trait has been renamed to Copy. > * jemalloc has been added as the default allocator for types. > * The API for allocating memory has been changed to use proper > alignment > and sized deallocation > * Connecting a TcpStream or binding a TcpListener is now based on a > string address and a u16 port. This allows connecting to a hostname > as > opposed to an IP. > * The Reader trait now contains a core method, read_at_least(), which > correctly handles many repeated 0-length reads. > * The process-spawning API is now centered around a builder-style > Command struct. > * The :? printing qualifier has been moved from the standard library to > an external libdebug crate. > * Eq/Ord have been renamed to PartialEq/PartialOrd. TotalEq/TotalOrd > have been renamed to Eq/Ord. > * The select/plural methods have been removed from format!. The escapes > for { and } have also changed from \{ and \} to {{ and }}, > respectively. > * The TaskBuilder API has been re-worked to be a true builder, and > extension traits for spawning native/green tasks have been added. > > * Tooling > * All breaking changes to the language or libraries now have their > commit message annotated with `[breaking-change]` to allow for easy > discovery of breaking changes. > * The compiler will now try to suggest how to annotate lifetimes if a > lifetime-related error occurs. > * Debug info continues to be improved greatly with general bug fixes > and > better support for situations like link time optimization (LTO). > * Usage of syntax extensions when cross-compiling has been fixed. > * Functionality equivalent to GCC & Clang's -ffunction-sections, > -fdata-sections and --gc-sections has been enabled by default > * The compiler is now stricter about where it will load module files > from when a module is declared via `mod foo;`. > * The #[phase(syntax)] attribute has been renamed to #[phase(plugin)]. > Syntax extensions are now discovered via a "plugin registrar" type > which will be extended in the future to other various plugins. > * Lints have been restructured to allow for dynamically loadable lints. > * A number of rustdoc improvements: > * The HTML output has been visually redesigned. > * Markdown is now powered by hoedown instead of sundown. > * Searching heuristics have been greatly improved. > * The search index has been reduced in size by a great amount. > * Cross-crate documentation via `pub use` has been greatly improved. > * Primitive types are now hyperlinked and documented. > * Documentation has been moved from static.rust-lang.org/doc to > doc.rust-lang.org > * A new sandbox, play.rust-lang.org, is available for running and > sharing rust code examples on-line. > * Unused attributes are now more robustly warned about. > * The dead_code lint now warns about unused struct fields. > * Cross-compiling to iOS is now supported. > * Cross-compiling to mipsel is now supported. > * Stability attributes are now inherited by default and no longer apply > to intra-crate usage, only inter-crate usage. > * Error message related to non-exhaustive match expressions have been > greatly improved. > > Contributors to Rust 0.11.0 > --------------------------- > > Aaron Raimist > Aaron Turon > Adolfo Ochagav?a > Adrien T?tar > Ahmed Charles > Alan Andrade > Alan Williams > Alex Crichton > Alexandre Gagnon > Alexei Sholik > Ali Smesseim > Andrew Gallant > Anton L?fgren > Arcterus > Ariel Ben-Yehuda > Axel Viala > Ben Noordhuis > Benjamin Adamson > Benjamin Herr > Bj?rn Steinbrink > Boris Egorov > Brandon Waskiewicz > Brendan McLoughlin > Brendan Zabarauskas > Brian Anderson > Cameron Zwarich > Chris Morgan > Chris Shea > Christoph Burgdorf > Christopher Bergqvist > Christopher Kendell > Clark Gaebel > Conrad Kleinespel > Corey Richardson > Daniel Brooks > Daniel Fagnan > Daniel Micay > David Creswick > Derek Chiang (Enchi Jiang) > Dirk Leifeld > Dmitry Promsky > Douglas Young > Dylan Braithwaite > Eduard Bopp > Eduard Burtescu > Edward Wang > Emanuel Rylke > Erick Tryzelaar > Falco Hirschenberger > Falco Hirschenberger > Felix S. Klock II > Flavio Percoco > Florian Gilcher > Florian Hartwig > Florian Zeitz > Gary M. Josack > Guillaume Pinot > G?bor Lehel > Hanno Braun > Heather > Herman J. Radtke III > HeroesGrave > Huon Wilson > Ivan Petkov > J.C. Moyer > Jacob Hegna > Jakub Wieczorek > James Laverack > James Miller > James Sanders > Jeong YunWon > Jihyeok Seo > Jim Radford > John Clements > John Fresco > John Schmidt > John Simon > Jonathan Bailey > Jonathan Bailey > Jonathan Reem > Jonathan S > Jordi Boggiano > Jorge Aparicio > Joseph Crail > JustAPerson > Justin Noah > Jyun-Yan You > Kang Seonghoon > Kasey Carrothers > Keegan McAllister > Keegan McAllister > Kevin Ballard > Kevin Butler > Kevin Cantu > Kiet Tran > Liigo Zhuang > Luqman Aden > Luqman Aden > Manish Goregaokar > Marvin L?bel > Matt Brubeck > Meyer S. Jacobs > Michael Dagitses > Michael Darakananda > Michael Fairley > Michael Pratt > Michael Reinhard > Michael Woerister > Michael Zhou > Mihnea Dobrescu-Balaur > Mike Boutin > Ms2ger > Nathan Typanski > Nick Cameron > Nicolas Silva > Nikita Pekin > Niklas Koep > Niko Matsakis > Noam Yorav-Raphael > OGINO Masanori > P1start > Patrick Walton > Paul Stansifer > Pawel Olzacki > Phil Ruffwind > Piotr Czarnecki > Piotr Jawniak > Randati > Raphael Speyer > Reilly Watson > Renato Riccieri Santos Zannon > Renato Zannon > Richard Diamond > Richo Healey > Robert Buonpastore > Ryan Mulligan > Ryman > R?diger Sonderfeld > Santiago Rodriguez > Sean Gillespie > Sean McArthur > Seo Sanghyeon > Sergio Benitez > Simon Sapin > Stepan Koltsov > Steve Klabnik > Steven Fackler > Steven Sheldon > Sylvestre Ledru > Ted Horst > Thomas Backman > Tim Brooks > Timoth?e Ravier > Tobba > Tobias Bucher > Tom Jakubowski > Tom Lee > TyOverby > Utkarsh Kukreti > Vadim Chugunov > Valentin Tsatskin > Valerii Hiora > Virgile Andreani > Wendell Smith > Yehuda Katz > Yuri Kunde Schlesner > Zach Pomerantz > Zooko Wilcox-O'Hearn > aochagavia > bachm > bors > fort > free-Runner > iancormac84 > klutzy > lucy > m-r-r > mdinger > moonglum > mrec > theptrk > _______________________________________________ > 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 zo1980 at gmail.com Wed Jul 2 14:44:03 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Wed, 2 Jul 2014 23:44:03 +0200 Subject: [rust-dev] Rust 0.11.0 Released In-Reply-To: References: Message-ID: Congrat and thank for the good work! On Wed, Jul 2, 2014 at 8:07 PM, Alex Crichton wrote: > Mozilla and the Rust community are pleased to announce version 0.11.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zo1980 at gmail.com Wed Jul 2 14:50:30 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Wed, 2 Jul 2014 23:50:30 +0200 Subject: [rust-dev] Rust 0.11.0 Released In-Reply-To: References: Message-ID: A new number appeared in the version "0.11.0" compared to "0.10". This looks like a preparation for "0.11.1", ... . Are you starting to support these releases with bug-eliminations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at carllerche.com Wed Jul 2 15:00:00 2014 From: me at carllerche.com (Carl Lerche) Date: Wed, 2 Jul 2014 15:00:00 -0700 Subject: [rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point) Message-ID: Hey all, I've been working on libcurl bindings for rust. So far, I've only been focusing on HTTP support. The goal is to provide a fully functioning HTTP client that robustly handles all the edge cases needed in the real world. I'm not trying to build the world's most amazing HTTP client for rust. I'm hoping that one day a pure rust option will fill that need. In the mean time, curl-rust will satisfy your needs. In case you don't know, libcurl (http://curl.haxx.se/libcurl/) is a client-side URL transfer library supporting many, many protocols. Hopefully, if anybody needs support for any of the other protocols curl supports, I will see PRs for them! Cheers, Carl From me at carllerche.com Wed Jul 2 15:00:41 2014 From: me at carllerche.com (Carl Lerche) Date: Wed, 2 Jul 2014 15:00:41 -0700 Subject: [rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point) In-Reply-To: References: Message-ID: And, it seems that I completely forgot to actually provide the link. I need more coffee! https://github.com/carllerche/curl-rust On Wed, Jul 2, 2014 at 3:00 PM, Carl Lerche wrote: > Hey all, > > I've been working on libcurl bindings for rust. So far, I've only been > focusing on HTTP support. The goal is to provide a fully functioning > HTTP client that robustly handles all the edge cases needed in the > real world. I'm not trying to build the world's most amazing HTTP > client for rust. I'm hoping that one day a pure rust option will fill > that need. > > In the mean time, curl-rust will satisfy your needs. > > In case you don't know, libcurl (http://curl.haxx.se/libcurl/) is a > client-side URL transfer library supporting many, many protocols. > Hopefully, if anybody needs support for any of the other protocols > curl supports, I will see PRs for them! > > Cheers, > Carl From contact at bitpuffin.com Wed Jul 2 15:07:19 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Thu, 3 Jul 2014 00:07:19 +0200 Subject: [rust-dev] Met with a terrible fate Message-ID: Hello! I have written a library in Rust that has some pub extern fv's in it so that they are callable from C. I wrote a C program to try calling these functions and I was met with the following message: % ./test You've met with a terrible fate, haven't you? fatal runtime error: Could not unwind stack, error = 5 zsh: illegal hardware instruction ./test To begin with, nice reference! Second of all. How do I fix this, I am guessing that I need to start the rust runtime or something but I don't know how to do this, if someone could point me in the right direction that would be great! If you need more specific code examples of what I'm doing I can provide it it's just that I'm gonna sleep now and it doesn't seem like that's all too relevant. Also I did link to the libraries in the order it told me to. Cheers! Isak Andersson -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed Jul 2 15:56:23 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 2 Jul 2014 18:56:23 -0400 Subject: [rust-dev] Rust 0.11.0 Released In-Reply-To: References: Message-ID: > Are you starting to support these releases with bug-eliminations? AFAIK there is no intention to start issuing bugfix releases at this time. The reason for the extra number at the end is for stricter adherence to Semantic Versioning, which requires a bugfix number. On Wed, Jul 2, 2014 at 5:50 PM, Zolt?n T?th wrote: > A new number appeared in the version "0.11.0" compared to "0.10". This > looks like a preparation for "0.11.1", ... . Are you starting to support > these releases with bug-eliminations? > > _______________________________________________ > 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 eg1290 at gmail.com Wed Jul 2 15:57:06 2014 From: eg1290 at gmail.com (Evan G) Date: Wed, 2 Jul 2014 17:57:06 -0500 Subject: [rust-dev] Rust 0.11.0 Released In-Reply-To: References: Message-ID: I think its just so we parse as a proper semantic version. I know I ran into a problem yesterday where Cargo had to have an extra .0 in my version number to understand my version declaration. On Wed, Jul 2, 2014 at 4:50 PM, Zolt?n T?th wrote: > A new number appeared in the version "0.11.0" compared to "0.10". This > looks like a preparation for "0.11.1", ... . Are you starting to support > these releases with bug-eliminations? > > _______________________________________________ > 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 ben at 0x539.de Wed Jul 2 16:39:19 2014 From: ben at 0x539.de (Benjamin Herr) Date: Thu, 03 Jul 2014 01:39:19 +0200 Subject: [rust-dev] Met with a terrible fate In-Reply-To: References: Message-ID: <1404344359.13432.2.camel@vigil> Hi! Anything in the std lib that touches the runtime (task spawning and concurrency stuff, i/o, probably `Gc` and some things I'm forgetting) will assert that it's being called from within a rust task, meaning it can obtain a reference to the runtime object providing those services from it. As far as I know, your options are pretty much to try really hard to avoid using that functionality in code called from C, or arrange for everything that makes use of the runtime into to be wrapped in a call to `native::start()` or `green::start()`, which start up and tear down a runtime object to make it available to user code they run. This isn't super satisfying so I hope someone proves me wrong and provides a better option. I vaguely hope that in the long run there'll be something you can call from all extern "C" functions like `start_up_a_runtime_in_the_background_for_this_thread_if_necessary()` that would make sure that subsequent code can use runtime services without requiring C code to be significantly restructured (and ideally also something more lightweight to catch task failure before it tries to unwind through C code), but afaik we aren't there yet. -benh On Thu, 2014-07-03 at 00:07 +0200, Isak Andersson wrote: > Hello! > I have written a library in Rust that has some pub extern fv's in it > so that they are callable from C. I wrote a C program to try calling > these functions and I was met with the following message: > > % ./test > > You've met with a terrible fate, haven't you? > > fatal runtime error: Could not unwind stack, error = 5 > zsh: illegal hardware instruction ./test > > > To begin with, nice reference! > > > Second of all. How do I fix this, I am guessing that I need to start > the rust runtime or something but I don't know how to do this, if > someone could point me in the right direction that would be great! > > > If you need more specific code examples of what I'm doing I can > provide it it's just that I'm gonna sleep now and it doesn't seem like > that's all too relevant. Also I did link to the libraries in the order > it told me to. > > Cheers! > > > Isak Andersson > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From alex at crichton.co Wed Jul 2 18:23:40 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 2 Jul 2014 21:23:40 -0400 Subject: [rust-dev] Met with a terrible fate In-Reply-To: References: Message-ID: If you touch runtime services (such as those mentioned by Benjamin), it is assume that a Rust Task [1] is available. In your case, you're touching the unwinding service, but you have no set a catch-point for the call to unwinding anywhere. This sounds like you're triggering a failure without a task. This is akin to throwing a C++ exception without a try/catch block on the stack. You may wish to explore the std::rt::unwind [2] module, specifically the try function [3], but keep in mind that it is unsafe and you must be careful about what you're doing (the documentation explains this). I love getting the runtime running in nonstandard locations, so if you have any trouble, feel free to ping me on IRC! My nick is acrichto. [1]: http://doc.rust-lang.org/std/rt/task/struct.Task.html [2]: http://doc.rust-lang.org/std/rt/unwind/ [3]: http://doc.rust-lang.org/std/rt/unwind/fn.try.html On Wed, Jul 2, 2014 at 6:07 PM, Isak Andersson wrote: > Hello! > > I have written a library in Rust that has some pub extern fv's in it so that > they are callable from C. I wrote a C program to try calling these functions > and I was met with the following message: > > % ./test > > You've met with a terrible fate, haven't you? > > fatal runtime error: Could not unwind stack, error = 5 > zsh: illegal hardware instruction ./test > > To begin with, nice reference! > > Second of all. How do I fix this, I am guessing that I need to start the > rust runtime or something but I don't know how to do this, if someone could > point me in the right direction that would be great! > > If you need more specific code examples of what I'm doing I can provide it > it's just that I'm gonna sleep now and it doesn't seem like that's all too > relevant. Also I did link to the libraries in the order it told me to. > > Cheers! > > Isak Andersson > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From oscar at twitter.com Wed Jul 2 19:29:32 2014 From: oscar at twitter.com (Oscar Boykin) Date: Wed, 2 Jul 2014 16:29:32 -1000 Subject: [rust-dev] box syntax question Message-ID: Once in the tutorial, I see this syntax: let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10]; It seems to me, that should be: box, as it feels like box is referring to a container type (which the default type is Box<_>, but may be Rc<_> or Gc<_>). What is the principle behind the current notation? What is "GC" is this context other than a special string that is a one-off syntax? -- Oscar Boykin :: @posco :: http://twitter.com/posco -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed Jul 2 19:39:01 2014 From: corey at octayn.net (Corey Richardson) Date: Wed, 2 Jul 2014 19:39:01 -0700 Subject: [rust-dev] box syntax question In-Reply-To: References: Message-ID: The full syntax is: "box" ["(" EXPR ")"] EXPR The first expression is the "boxer", or where the result of the second expression will be stored. GC and HEAP are special cased right now as the only boxers, but the goal is to use a trait such that you can use Rc, arenas, vectors, or any other arbitrary type as a boxer. On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin wrote: > Once in the tutorial, I see this syntax: > > > let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10]; > > It seems to me, that should be: box, as it feels like box is referring > to a container type (which the default type is Box<_>, but may be Rc<_> or > Gc<_>). > > What is the principle behind the current notation? What is "GC" is this > context other than a special string that is a one-off syntax? > -- > Oscar Boykin :: @posco :: http://twitter.com/posco > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From ben.striegel at gmail.com Wed Jul 2 19:43:59 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 2 Jul 2014 22:43:59 -0400 Subject: [rust-dev] box syntax question In-Reply-To: References: Message-ID: To expand upon what Corey was saying, `box` is basically a huge special-cased hack right now. I'm surprised that a mention of `box(GC)` is even included in the tutorial. Someone tell Steve to rip that out. :P We'll be clarfiying how best to use `box` before 1.0. In the meantime, just don't use GC. Like, at all. You don't need it! :) On Wed, Jul 2, 2014 at 10:39 PM, Corey Richardson wrote: > The full syntax is: "box" ["(" EXPR ")"] EXPR > > The first expression is the "boxer", or where the result of the second > expression will be stored. GC and HEAP are special cased right now as > the only boxers, but the goal is to use a trait such that you can use > Rc, arenas, vectors, or any other arbitrary type as a boxer. > > On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin wrote: > > Once in the tutorial, I see this syntax: > > > > > > let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10]; > > > > It seems to me, that should be: box, as it feels like box is > referring > > to a container type (which the default type is Box<_>, but may be Rc<_> > or > > Gc<_>). > > > > What is the principle behind the current notation? What is "GC" is this > > context other than a special string that is a one-off syntax? > > -- > > Oscar Boykin :: @posco :: http://twitter.com/posco > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > http://octayn.net/ > _______________________________________________ > 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 fantix.king at gmail.com Wed Jul 2 20:01:02 2014 From: fantix.king at gmail.com (Fantix King) Date: Thu, 3 Jul 2014 11:01:02 +0800 Subject: [rust-dev] =?iso-8859-1?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_?= =?iso-8859-1?q?=D8MQ_in_Rus?= In-Reply-To: References: <53B45E92.7060908@aim.com> Message-ID: Thank you all, I learned a lot about licensing from all the discussions, will make the decision then :) Fantix On Thu, Jul 3, 2014 at 4:55 AM, Corey Richardson wrote: > See also the discussion on IRC: > https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232&page=22 > > It wasn't my intention to discourage using any particular license, but > to raise its requirements if they weren't consciously chosen. > > On Wed, Jul 2, 2014 at 12:33 PM, SiegeLordEx wrote: > > On 07/02/2014 03:16 AM, Corey Richardson wrote: > >> > >> Complaining about something I don't like: > >> > >> Due to the choice of MPLv2, this won't be usable in the wider Rust > >> ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a) > >> requires that any distribution in "Executable Form" carry a notice > >> about how to acquire the source code of zmq.rs. This is not > >> unworkable, but it is something we have avoided so far in the > >> community. > > > > > > I should note that this is not a universally held opinion in the Rust > > community. While it is true that many/most current Rust projects mimic > the > > license of `rustc` itself, there's nothing in Rust as a language that > > precludes or encourages the use of any particular license. The mentioned > > 'avoidance' is likely a consequence of the people just preferring those > > licenses (i.e. they'd use them for their non-Rust projects as well) > rather > > than Rust being against the spirit of attribution, share-alike, copyleft > etc > > per se. > > > > Personally, I would encourage Free Rust software just like I would > encourage > > it in any other language. You shouldn't feel like you need to compromise > on > > your moral principles (or whatever else you consult when choosing a > license) > > to contribute to Rust's success. > > > > -SL > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > -- > http://octayn.net/ > _______________________________________________ > 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 igor at mir2.org Wed Jul 2 23:08:34 2014 From: igor at mir2.org (Igor Bukanov) Date: Thu, 3 Jul 2014 08:08:34 +0200 Subject: [rust-dev] box syntax question In-Reply-To: References: Message-ID: So at some future point it would be possible to replace TypedArena_instance().alloc(X) with box(TypedArena_instance) X avoiding an extra move of X from a temporary allocated on the stack that the compiler in general cannot optimize? On 3 July 2014 04:39, Corey Richardson wrote: > The full syntax is: "box" ["(" EXPR ")"] EXPR > > The first expression is the "boxer", or where the result of the second > expression will be stored. GC and HEAP are special cased right now as > the only boxers, but the goal is to use a trait such that you can use > Rc, arenas, vectors, or any other arbitrary type as a boxer. > > On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin wrote: >> Once in the tutorial, I see this syntax: >> >> >> let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10]; >> >> It seems to me, that should be: box, as it feels like box is referring >> to a container type (which the default type is Box<_>, but may be Rc<_> or >> Gc<_>). >> >> What is the principle behind the current notation? What is "GC" is this >> context other than a special string that is a one-off syntax? >> -- >> Oscar Boykin :: @posco :: http://twitter.com/posco >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > http://octayn.net/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pcwalton at mozilla.com Wed Jul 2 23:09:12 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 02 Jul 2014 23:09:12 -0700 Subject: [rust-dev] box syntax question In-Reply-To: References: Message-ID: <53B4F388.8030505@mozilla.com> On 7/2/14 11:08 PM, Igor Bukanov wrote: > So at some future point it would be possible to replace > TypedArena_instance().alloc(X) with box(TypedArena_instance) X > avoiding an extra move of X from a temporary allocated on the stack > that the compiler in general cannot optimize? Yes. Under the hood, this will be implemented via return value optimization and an unboxed closure. Patrick From pibara at gmail.com Wed Jul 2 23:09:41 2014 From: pibara at gmail.com (Rob Meijer) Date: Thu, 3 Jul 2014 08:09:41 +0200 Subject: [rust-dev] Rust and object capabilities? Message-ID: I've been trying to read up on Rust a little bit, and things look really amazing. Given the focus on 'safety' and the strong link between safety and integrity related issues, I was intrigued by the following question: how far would Rust be removed from possibly becoming an object capability language, and has making Rust an object-capability language, or defining an ocap secure Rust subset (like Joe-e jor Java) been considered? Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Jul 2 23:10:26 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 02 Jul 2014 23:10:26 -0700 Subject: [rust-dev] Rust and object capabilities? In-Reply-To: References: Message-ID: <53B4F3D2.3040403@mozilla.com> On 7/2/14 11:09 PM, Rob Meijer wrote: > I've been trying to read up on Rust a little bit, and things look really > amazing. Given the focus on 'safety' and the strong link between safety > and integrity related issues, I was intrigued by the following question: > how far would Rust be removed from possibly becoming an object > capability language, and has making Rust an object-capability language, > or defining an ocap secure Rust subset (like Joe-e jor Java) been > considered? I'm told by ocap folks that it'll likely to be similar to the various ocap work on MLs. Patrick From contact at bitpuffin.com Thu Jul 3 01:44:26 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Thu, 3 Jul 2014 10:44:26 +0200 Subject: [rust-dev] Met with a terrible fate In-Reply-To: References: Message-ID: Hi, thanks for your quick replies! I am thinking that maybe one solution could be that the C code calls an init function that calls native::start and provides a function pointer that start calls back into C. That way the C main thread will have a rust runtime in the background, I *think*?. I hope this would be possible at least, the important thing is that it can be in the main thread, as often mobile platforms require to run in the main thread because the GUI library needs it for some reason. At least in iOS. (I am building a helper lib for making apps easier with our service) Other than that I don't really know how much I can restructure my code to work without (objective-)C(#) not having to do anything special. The way the library will be structured is that it has an internal thread where it runs at operation queue. Once that operation queue is empty the thread terminates and if you add more operations to the queue the thread starts once again. So a lot of the code will run in its own thread, which is at least good. However some of the code will work outside of the operation queue for things like queries that might use some kind of mutex to make sure it's not querying something that the operation queue is already processing. And for those mutexes to work it probably has to be within the same native::start... Unless I can use some kind of unsafe C mutex thing. Thoughts? Cheers! On Thu, Jul 3, 2014 at 3:23 AM, Alex Crichton wrote: > If you touch runtime services (such as those mentioned by Benjamin), > it is assume that a Rust Task [1] is available. In your case, you're > touching the unwinding service, but you have no set a catch-point for > the call to unwinding anywhere. This sounds like you're triggering a > failure without a task. This is akin to throwing a C++ exception > without a try/catch block on the stack. > > You may wish to explore the std::rt::unwind [2] module, specifically > the try function [3], but keep in mind that it is unsafe and you must > be careful about what you're doing (the documentation explains this). > > I love getting the runtime running in nonstandard locations, so if you > have any trouble, feel free to ping me on IRC! My nick is acrichto. > > > [1]: http://doc.rust-lang.org/std/rt/task/struct.Task.html > [2]: http://doc.rust-lang.org/std/rt/unwind/ > [3]: http://doc.rust-lang.org/std/rt/unwind/fn.try.html > > On Wed, Jul 2, 2014 at 6:07 PM, Isak Andersson > wrote: > > Hello! > > > > I have written a library in Rust that has some pub extern fv's in it so > that > > they are callable from C. I wrote a C program to try calling these > functions > > and I was met with the following message: > > > > % ./test > > > > You've met with a terrible fate, haven't you? > > > > fatal runtime error: Could not unwind stack, error = 5 > > zsh: illegal hardware instruction ./test > > > > To begin with, nice reference! > > > > Second of all. How do I fix this, I am guessing that I need to start the > > rust runtime or something but I don't know how to do this, if someone > could > > point me in the right direction that would be great! > > > > If you need more specific code examples of what I'm doing I can provide > it > > it's just that I'm gonna sleep now and it doesn't seem like that's all > too > > relevant. Also I did link to the libraries in the order it told me to. > > > > Cheers! > > > > Isak Andersson > > > > _______________________________________________ > > 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 dwrenshaw at gmail.com Thu Jul 3 06:00:37 2014 From: dwrenshaw at gmail.com (David Renshaw) Date: Thu, 3 Jul 2014 09:00:37 -0400 Subject: [rust-dev] Rust and object capabilities? In-Reply-To: References: Message-ID: Perhaps relevant: Cap'n Proto's RPC protocol aims to be a cross-language distributed-object-capability system, and I have been working on a Rust implementation . On Thu, Jul 3, 2014 at 2:09 AM, Rob Meijer wrote: > I've been trying to read up on Rust a little bit, and things look really > amazing. Given the focus on 'safety' and the strong link between safety > and integrity related issues, I was intrigued by the following question: > how far would Rust be removed from possibly becoming an object capability > language, and has making Rust an object-capability language, or defining an > ocap secure Rust subset (like Joe-e jor Java) been considered? > > Rob > > _______________________________________________ > 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 Jul 3 06:42:37 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 3 Jul 2014 08:42:37 -0500 Subject: [rust-dev] Cargo multiple targets In-Reply-To: References: Message-ID: The links for FAQ and Manifest Format on http://crates.io should be rearranged to be at the top of the homepage...instead of the bottom, in my opinion. On Wed, Jul 2, 2014 at 7:38 AM, Isak Andersson wrote: > Hi! > > Wow I didn't know about the manifest page, I was under the impression that > the docs were very lacking. But this is pretty great. > > Thanks a bunch that was super helpful! > > > On Wed, Jul 2, 2014 at 2:09 PM, Vladimir Matveev > wrote: > >> Hi, Isak! >> >> According to manifest documentation [1] you can specify crate type >> (dynamic or static lib or rlib) using crate_type option: >> >> [[lib]] >> ? >> crate_type = ["dylib", "staticlib"] >> >> The above configuration should build you both .a and .so files. >> >> [1]: http://crates.io/manifest.html, search for "crate_type" w/o >> quotes >> >> On 02 ???? 2014 ?., at 15:58, Isak Andersson >> wrote: >> >> > Hi! >> > >> > Thanks for the reply! >> > >> > Apparently multiple targets does in fact work. Just that you can't rely >> on the >> > default path anymore, so I had to add the path = ... to both the >> [[lib]] and [[bin]]. >> > Not sure if this is a bug or not. >> > >> > However the library compiles as an rlib and I'm not sure how to change >> it to build >> > a C library instead (a .a or .so on *nix or .lib I think on windows). >> > >> > Actually I'm not even sure how to make rustc build a C library so I >> guess that's what >> > I will start looking at. >> > >> > >> > On Wed, Jul 2, 2014 at 1:37 PM, Sebastian Gesemann < >> s.gesemann at gmail.com> wrote: >> > On Wed, Jul 2, 2014 at 12:49 PM, Isak Andersson wrote: >> > > Hello Rust folks! >> > > >> > > I am using Cargo and I am trying to specify mulitple targets in my >> > > Cargo.toml file. >> > > First of all is this even possible? >> > > ... >> > > [package] >> > > name = "hmproof" >> > > version = "0.1.0" >> > > authors = [ "isak at houstonmedia.se" ] >> > > [[bin]] >> > > name = "hmwhoami" >> > > [[lib]] >> > > name = "proof" >> > > (I also tried adding a path) >> > > path = "src/proof.rs" >> > > [dependencies.rust-http] >> > > git = "https://github.com/chris-morgan/rust-http.git" >> > > >> > > I also tried putting the [[lib]] part after the dependencies part. >> The error >> > > I get is this: >> > > error: couldn't read src/bin/hmwhoami.rs: couldn't open file (no >> such file >> > > or directory [...] >> > > Whiich doesn't make any sense at all to me. Why does it suddenly start >> > > looking in src/bin? >> > >> > According to http://crates.io/manifest.html the default path for a >> > binary is src (if there is no other lib) and src/bin (if there is also >> > a lib target). You should be able to override this with path = >> > src/hmwhoami. >> > >> > > Do I have to put my bin code in src/bin and my lib code in src lib or >> what? >> > >> > Currently, only a single lib per package is supported and it seems, >> > judging by the document about the manifest format, that Cargo always >> > looks for src/lib.rs for a library unless you override this using a >> > "path=something". >> > >> > As for how to tell Cargo to invoke rustc with the appropriate -L >> > option: I don't know. >> > >> > HTH, >> > sg >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Thu Jul 3 06:58:19 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 3 Jul 2014 09:58:19 -0400 Subject: [rust-dev] Met with a terrible fate In-Reply-To: References: Message-ID: > I am thinking that maybe one solution could be that the C code calls > an init function that calls native::start and provides a function pointer > that start calls back into C. That way the C main thread will have a rust > runtime in the background, I *think*?. That is correct! > I hope this would be possible at least, the important thing is that it can > be > in the main thread, as often mobile platforms require to run in the main > thread because the GUI library needs it for some reason. At least in iOS. > (I am building a helper lib for making apps easier with our service) This is indeed possible! We have many many applications and games being written in Rust right now, and they all have the same requirement. > Other than that I don't really know how much I can restructure my code to > work without (objective-)C(#) not having to do anything special. The way > the library will be structured is that it has an internal thread where it > runs > at operation queue. Once that operation queue is empty the thread terminates > and if you add more operations to the queue the thread starts once again. So > a lot of the code will run in its own thread, which is at least good. > However > some of the code will work outside of the operation queue for things like > queries > that might use some kind of mutex to make sure it's not querying something > that > the operation queue is already processing. And for those mutexes to work it > probably > has to be within the same native::start... Unless I can use some kind of > unsafe C > mutex thing. Right now the C => Rust FFI bridge isn't as convenient as it could be. One option you may want to look into is what rust-civet [1] does which is to create a new native rust task per-request, but it doesn't spawn a thread per request. [1]: https://github.com/wycats/rust-civet/blob/master/src/raw.rs#L91-L106 From glaebhoerl at gmail.com Thu Jul 3 07:29:04 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Thu, 3 Jul 2014 16:29:04 +0200 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: <53B455C9.1060507@mozilla.com> References: <53B455C9.1060507@mozilla.com> Message-ID: On Wed, Jul 2, 2014 at 8:56 PM, Brian Anderson wrote: > > On 07/02/2014 11:19 AM, G?bor Lehel wrote: > > Thanks, this is a good step, as is delaying taking actions by a day > as proposed in the meeting itself. > > > If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. > > > Most fundamentally, what I'm wondering is, why do most of the things > discussed at the meetings need to be discussed separately in the first > place? > > Why not have those discussions directly in the comments for the respective > RFC PRs? Up to and including leaving comments like "we suggest closing > this, because {justification}, unless someone convinces us otherwise", "we > suggest merging this because {justification}", and so on. In an ideal > world, the meetings could merely ratify the decisions which were already > evident from the PR discussions themselves. This could also help avoid > situations where the two discussions end up disjoint in some way, e.g. > according to this week's meeting notes @pcwalton and @aturon essentially > recapitulated the exact same debate about the lifetime elision "self rule" > at the meeting which @aturon and I had previously gone through in the PR > comments. > > > I would like to move in this direction, but like many cultural changes it > will be gradual. The primary reason we do so much in meetings is because > face-to-face discussions move much faster and involve much less > argumentation than asynchronous online discussions. In the immediate future > I'd like to put more pressure on meeting participants to express their > opinions on the issue ahead of meetings, which this initiative Nick is > working on helps by making it clear what issues are coming up. > Excellent, thanks. I definitely agree about face-to-face discussions being so much easier. > > > > > From the proposed-for-discussion list: > > https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> > > The two are complementary, not substitutive. 122 allows factoring out > type parameter lists for multiple declarations. 135 allows writing them > differently. > > > From the meeting itself, because it concerns process: > >> >> - nrc: Do we want to keep this open? It's the <> to [] changes. >> - acrichto: It's so new, I don't think we should close it. >> - nrc: Even so, if we're not going to do it, I don't think we should >> keep it open. >> >> I don't see what could have been gained by closing it. Potential > scenarios if it's left open: > > (1) Participants end up convincing each other than the change is not > worth doing. (This is what ended up happening in this case.) > (2) Contrary to expectations, a consensus emerges in favor of the > change. Maybe there is some factor that hadn't been taken into account > previously, or the arguments of one side end up convincing the other. I > think this might be useful information to have learned. Then you can > evaluate the decision on the merits. > > Whereas if it's closed early: > > (3) People are left with the opinions they already had, and now might > also have the impression that Mozilla has heavy-handedly shut down the > debate. > > I mean, possibly leave a comment like "Just so you know, we are extremely > unlikely to do this, but feel free to keep discussing", but I think that > was clear to everyone at the outset. I just don't see what could have been > gained by preventing the discussion from playing itself out. > > Cheers, > G?bor > > > > On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: > >> Hi all, there have recently been some calls to be more open about the >> Rust meetings, in particular to publish the agenda beforehand. The agenda >> setting has been quite informal, often not coming together until the >> meeting starts. Not to say that we won't publish an agenda in the future, >> but that it is not as easy as it might seem. However, as a step towards >> that, I will be mailing out the part of the agenda that is set in advance >> which is the set of (usually older) RFCs where discussion has mostly ceased >> and where we feel we can make a decision on progress. This email is a >> relatively new convention in any case. It has been sent to most meeting >> attendees at the start of the week. From now on, I'll send it to the >> mailing list instead. If you have comments on the RFCs, please comment on >> the RFC PR itself, please do not reply to the mailing list. >> >> Some explanation of the process here - each week there are two Rust >> meetings where we discuss RFCs, the general Rust meeting and the triage >> meeting. We only accept RFCs at the general meeting. RFCs may be closed at >> either meeting. In order to make sure no older RFCs slip through the >> cracks, RFCs where discussion has come to a stop (or nearly so) are >> recommended each week for discussion. Based on the outcome of the >> discussion on the PR and the current goals of the Rust project (in >> particular in not accepting any major backwards compatible changes before >> 1.0) an RFC will be proposed for discussion at the general meeting if it >> needs discussion or we are likely to accept, or to the triage meeting if it >> is likely to closed. To clarify, what actually happens to an RFC is decided >> at the meeting, not by which meeting it is discussed at. Often, other RFCs >> are also discussed at the meetings where attendees think there is a more >> urgent need to discuss something. You can see the minutes of the meeting >> discussions at https://github.com/rust-lang/meeting-minutes. Not all the >> RFCs proposed in this email get discussed at the meetings - either because >> we run out of time or because a key person is not at the meeting. >> >> The 'actions agreed' section keeps track of actions on older RFCs agreed >> at previous meetings, but which have not yet been carried out. >> >> If you have any suggestions for how this regular email or the process in >> general could be improved, please let us know. >> >> Cheers, Nick >> >> >> Proposed for discussion at Rust meeting >> --------------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and >> blocks >> huon has updated >> should we accept now? >> >> https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt >> No recommendation, just needs a kick to get moving again. >> >> https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for >> module imports - tommit >> Allow e.g., `use module::{self, Type};` for `use module::Type; use >> module;`. >> Generally positive response. Some bike shedding around the use of >> `self` since we call the file mod.rs, and some proposal to allow self.rs >> instead. >> Recommend we accept (possibly we should bikeshed the synax `self`). >> We could postpone this (it would be backwards compatible), but it seems >> very desirable and would be little effort to implement. >> >> https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis >> A lot of discussion, pretty much all about the details. General >> sentiment that we want this. >> Recommend we accept - is this the right RFC to accept, I've not >> really been keeping track - pnkfelix, pcwalton - is there something which >> supersedes this? I think this needs a small update to reflect some of the >> later comments. >> >> https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - >> stevelabnik >> Loads of opinion in the thread (162 comments!). Note that Niko has an >> upcoming RFC with the concept of unsafe/trusted traits where the keyword >> `trusted` makes a lot more sense than `unsafe`, so we could save a keyword >> here. >> Recommend we discuss this. >> >> https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic >> operators to take their arguments by value not by ref - pcwalton. >> Pretty negative feedback (though not all). I remember being convinced >> this was the proper way to implement arithmetic operators a while back, but >> I can't remember why (something about using tuples in the signature maybe? >> I can't remember). There seems to be some poor interaction with BigInt, >> etc. where implementing for `&BigInt` isn't what you want (but I don't see >> why from the comment, pcwalton seems to in his reply though). >> Lets discuss this. >> >> >> Proposed for discussion at triage >> --------------------------------- >> >> https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' >> pointers (pretty much out params, aiui) - gereeter >> A new form of reference, `&uninit`, is added that is write-only and >> points to possibly uninitialized data. >> Mixed reactions - overall positive, but agreement on low priority. >> Recommend close as postponed - was this agreed last week? >> >> https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - >> bmyers >> Proposes range types and other complicated stuff, but discusses other >> options. >> Lots of discussion on integer overflow in general, no agreement. Also >> discussed to death on the mailing list several times, including currently. >> Recommend close - we might conceivably do something, but we won't do >> this and we won't lose anything by closing this RFC (there's also a new RFC >> with a different proposal derived from the most recent mailing list thread). >> >> https://github.com/rust-lang/rfcs/pull/119 - add support to >> serialize::json for incrementally reading multiple JSON objects - XMPPwocky >> Apparently this is included in RFC 22, which has an implementation. >> Recommend close in deference to RFC 22. >> >> https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as >> sugar for nested match statements - bvssvni >> Syntax for flattening match statements by 'chaining' arms of a match >> statement. >> Feedback is mostly negative. Some positive feelings for including the >> macro rather than first class syntax. Others want to wait for HKT and have >> a function. >> Recommend close as postponed. We probably want something like this, >> but not pre-1.0. >> >> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >> prefix-style type parameter lists - ben0x539 >> Sugary syntax for putting a group of type parameters and their bounds >> before a group of functions. Motivation is our often unwieldly lists of >> type parameters. >> Not much feedback, but mostly positive. Generally for the motivation, >> rather than the solution. >> Recommend close in deference to RFC 135 (where clauses) which solve >> the motivating problem here, along with other issues. >> >> >> Actions agreed >> -------------- >> >> https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of >> tagged values - erikt >> Changes to the deserialisation framework. Allows for decoding into an >> enum. No commentary for or against. >> erikt to update? >> >> https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count >> sequence repetitions - Eridius >> More discussion - esp, can it be done with a macro >> >> https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern >> matching for slices - krdln >> No comments. The RFC is a little bit vague, but seems like kind of a >> win. Backwards incompatible. >> Close. >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://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 glaebhoerl at gmail.com Thu Jul 3 07:58:24 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Thu, 3 Jul 2014 16:58:24 +0200 Subject: [rust-dev] Partial meeting agenda - older RFCs In-Reply-To: References: Message-ID: On Wed, Jul 2, 2014 at 11:05 PM, Nick Cameron wrote: > > > > On Thu, Jul 3, 2014 at 6:19 AM, G?bor Lehel wrote: > >> Thanks, this is a good step, as is delaying taking actions by a day as >> proposed in the meeting itself. >> >> >> >> If you have any suggestions for how this regular email or the process in >>> general could be improved, please let us know. >> >> >> Most fundamentally, what I'm wondering is, why do most of the things >> discussed at the meetings need to be discussed separately in the first >> place? >> >> Why not have those discussions directly in the comments for the >> respective RFC PRs? Up to and including leaving comments like "we suggest >> closing this, because {justification}, unless someone convinces us >> otherwise", "we suggest merging this because {justification}", and so on. >> In an ideal world, the meetings could merely ratify the decisions which >> were already evident from the PR discussions themselves. This could also >> help avoid situations where the two discussions end up disjoint in some >> way, e.g. according to this week's meeting notes @pcwalton and @aturon >> essentially recapitulated the exact same debate about the lifetime elision >> "self rule" at the meeting which @aturon and I had previously gone through >> in the PR comments. >> >> >> From the proposed-for-discussion list: >> >> >> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >>> prefix-style type parameter lists - ben0x539 >>> Sugary syntax for putting a group of type parameters and their >>> bounds before a group of functions. Motivation is our often unwieldly lists >>> of type parameters. >>> Not much feedback, but mostly positive. Generally for the >>> motivation, rather than the solution. >>> Recommend close in deference to RFC 135 (where clauses) which solve >>> the motivating problem here, along with other issues. >>> >> >> The two are complementary, not substitutive. 122 allows factoring out >> type parameter lists for multiple declarations. 135 allows writing them >> differently. >> >> Please comment on the RFCs rather than replying to the mailing list. I'll > make a note of this, but in the general case, I guarantee that replies to > the mailing list will get lost or forgotten. I agree the two RFCs are not > substitutive and could both be accepted, but they do both tackle the same > problem (ugly type param lists). > OK. I didn't miss that admonishment in the original e-mail. I had the impression that it referred to general commentary, rather than replies to specific things in the e-mail itself. It feels strange to reply to a statement in a venue where the statement hasn't been made. > >> From the meeting itself, because it concerns process: >> >>> >>> - nrc: Do we want to keep this open? It's the <> to [] changes. >>> - acrichto: It's so new, I don't think we should close it. >>> - nrc: Even so, if we're not going to do it, I don't think we should >>> keep it open. >>> >>> I don't see what could have been gained by closing it. Potential >> scenarios if it's left open: >> >> (1) Participants end up convincing each other than the change is not >> worth doing. (This is what ended up happening in this case.) >> (2) Contrary to expectations, a consensus emerges in favor of the >> change. Maybe there is some factor that hadn't been taken into account >> previously, or the arguments of one side end up convincing the other. I >> think this might be useful information to have learned. Then you can >> evaluate the decision on the merits. >> >> Whereas if it's closed early: >> >> (3) People are left with the opinions they already had, and now might >> also have the impression that Mozilla has heavy-handedly shut down the >> debate. >> >> I mean, possibly leave a comment like "Just so you know, we are extremely >> unlikely to do this, but feel free to keep discussing", but I think that >> was clear to everyone at the outset. I just don't see what could have been >> gained by preventing the discussion from playing itself out. >> >> We will (at some point) have a separate discussion on the policy, as was > briefly touched upon in the meeting we decided it was a policy question and > we shouldn't do anything in this case. > > My motivation for early closure of some RFCs is to be honest - I don't > want to waste people's time, energy, or emotional investment arguing about > it if they have the (false) impression that it might change. As you suggest > leaving a comment and leaving the RFC open is probably a better way to do > this (although you can still comment on a closed PR, so I'm not sure there > is really much difference, other than whether the RFC shows up in the list > of open PRs). Another reason is simply that I don't like to see pointless > arguing, and I feel that on RFCs like this which come down to taste, it > really is arguing and not discussion. I think the Rust community would be a > better place without it. Of course, I could just ignore the GitHub spam, > but I would rather the arguing just doesn't happen. FWIW, your point 1 is > very valid and probably outweighs my points, just saying that there are > other disadvantages. The chance of 2 happening in a case like this seems so > small that I wouldn't worry about it. > > Cheers, Nick > >From a philosophical perspective, as with democracy (which I recognize this is not), I think the value is not necessarily in the outcomes but in the process itself. People are more likely to be constructive and accepting of the outcome if they feel that they've gotten their fair say. (For what it's worth, I didn't perceive this particular discussion as arguing.) > > Cheers, >> G?bor >> >> >> >> On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote: >> >>> Hi all, there have recently been some calls to be more open about the >>> Rust meetings, in particular to publish the agenda beforehand. The agenda >>> setting has been quite informal, often not coming together until the >>> meeting starts. Not to say that we won't publish an agenda in the future, >>> but that it is not as easy as it might seem. However, as a step towards >>> that, I will be mailing out the part of the agenda that is set in advance >>> which is the set of (usually older) RFCs where discussion has mostly ceased >>> and where we feel we can make a decision on progress. This email is a >>> relatively new convention in any case. It has been sent to most meeting >>> attendees at the start of the week. From now on, I'll send it to the >>> mailing list instead. If you have comments on the RFCs, please comment on >>> the RFC PR itself, please do not reply to the mailing list. >>> >>> Some explanation of the process here - each week there are two Rust >>> meetings where we discuss RFCs, the general Rust meeting and the triage >>> meeting. We only accept RFCs at the general meeting. RFCs may be closed at >>> either meeting. In order to make sure no older RFCs slip through the >>> cracks, RFCs where discussion has come to a stop (or nearly so) are >>> recommended each week for discussion. Based on the outcome of the >>> discussion on the PR and the current goals of the Rust project (in >>> particular in not accepting any major backwards compatible changes before >>> 1.0) an RFC will be proposed for discussion at the general meeting if it >>> needs discussion or we are likely to accept, or to the triage meeting if it >>> is likely to closed. To clarify, what actually happens to an RFC is decided >>> at the meeting, not by which meeting it is discussed at. Often, other RFCs >>> are also discussed at the meetings where attendees think there is a more >>> urgent need to discuss something. You can see the minutes of the meeting >>> discussions at https://github.com/rust-lang/meeting-minutes. Not all >>> the RFCs proposed in this email get discussed at the meetings - either >>> because we run out of time or because a key person is not at the meeting. >>> >>> The 'actions agreed' section keeps track of actions on older RFCs agreed >>> at previous meetings, but which have not yet been carried out. >>> >>> If you have any suggestions for how this regular email or the process in >>> general could be improved, please let us know. >>> >>> Cheers, Nick >>> >>> >>> Proposed for discussion at Rust meeting >>> --------------------------------------- >>> >>> https://github.com/rust-lang/rfcs/pull/16 - attributes on statements >>> and blocks >>> huon has updated >>> should we accept now? >>> >>> https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - >>> erikt >>> No recommendation, just needs a kick to get moving again. >>> >>> https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for >>> module imports - tommit >>> Allow e.g., `use module::{self, Type};` for `use module::Type; use >>> module;`. >>> Generally positive response. Some bike shedding around the use of >>> `self` since we call the file mod.rs, and some proposal to allow self.rs >>> instead. >>> Recommend we accept (possibly we should bikeshed the synax `self`). >>> We could postpone this (it would be backwards compatible), but it seems >>> very desirable and would be little effort to implement. >>> >>> https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - >>> nmatsakis >>> A lot of discussion, pretty much all about the details. General >>> sentiment that we want this. >>> Recommend we accept - is this the right RFC to accept, I've not >>> really been keeping track - pnkfelix, pcwalton - is there something which >>> supersedes this? I think this needs a small update to reflect some of the >>> later comments. >>> >>> https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - >>> stevelabnik >>> Loads of opinion in the thread (162 comments!). Note that Niko has >>> an upcoming RFC with the concept of unsafe/trusted traits where the keyword >>> `trusted` makes a lot more sense than `unsafe`, so we could save a keyword >>> here. >>> Recommend we discuss this. >>> >>> https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic >>> operators to take their arguments by value not by ref - pcwalton. >>> Pretty negative feedback (though not all). I remember being >>> convinced this was the proper way to implement arithmetic operators a while >>> back, but I can't remember why (something about using tuples in the >>> signature maybe? I can't remember). There seems to be some poor interaction >>> with BigInt, etc. where implementing for `&BigInt` isn't what you want (but >>> I don't see why from the comment, pcwalton seems to in his reply though). >>> Lets discuss this. >>> >>> >>> Proposed for discussion at triage >>> --------------------------------- >>> >>> https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised' >>> pointers (pretty much out params, aiui) - gereeter >>> A new form of reference, `&uninit`, is added that is write-only and >>> points to possibly uninitialized data. >>> Mixed reactions - overall positive, but agreement on low priority. >>> Recommend close as postponed - was this agreed last week? >>> >>> https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow - >>> bmyers >>> Proposes range types and other complicated stuff, but discusses >>> other options. >>> Lots of discussion on integer overflow in general, no agreement. >>> Also discussed to death on the mailing list several times, including >>> currently. >>> Recommend close - we might conceivably do something, but we won't do >>> this and we won't lose anything by closing this RFC (there's also a new RFC >>> with a different proposal derived from the most recent mailing list thread). >>> >>> https://github.com/rust-lang/rfcs/pull/119 - add support to >>> serialize::json for incrementally reading multiple JSON objects - XMPPwocky >>> Apparently this is included in RFC 22, which has an implementation. >>> Recommend close in deference to RFC 22. >>> >>> https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword >>> as sugar for nested match statements - bvssvni >>> Syntax for flattening match statements by 'chaining' arms of a match >>> statement. >>> Feedback is mostly negative. Some positive feelings for including >>> the macro rather than first class syntax. Others want to wait for HKT and >>> have a function. >>> Recommend close as postponed. We probably want something like this, >>> but not pre-1.0. >>> >>> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for >>> prefix-style type parameter lists - ben0x539 >>> Sugary syntax for putting a group of type parameters and their >>> bounds before a group of functions. Motivation is our often unwieldly lists >>> of type parameters. >>> Not much feedback, but mostly positive. Generally for the >>> motivation, rather than the solution. >>> Recommend close in deference to RFC 135 (where clauses) which solve >>> the motivating problem here, along with other issues. >>> >>> >>> Actions agreed >>> -------------- >>> >>> https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream >>> of tagged values - erikt >>> Changes to the deserialisation framework. Allows for decoding into >>> an enum. No commentary for or against. >>> erikt to update? >>> >>> https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count >>> sequence repetitions - Eridius >>> More discussion - esp, can it be done with a macro >>> >>> https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern >>> matching for slices - krdln >>> No comments. The RFC is a little bit vague, but seems like kind of a >>> win. Backwards incompatible. >>> Close. >>> >>> >>> _______________________________________________ >>> 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 Jul 3 08:30:06 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 3 Jul 2014 10:30:06 -0500 Subject: [rust-dev] =?utf-8?q?=5BANN=5D_zmq=2Ers_-_native_stack_of_=C3=98M?= =?utf-8?q?Q_in_Rus?= In-Reply-To: References: <53B45E92.7060908@aim.com> Message-ID: Hey Fantix, nice job ! By the way, if you really have time to spare...MQTT would also be a "nice to have" library...for the embeddable sensor domain guys. A bit about it here: http://clockwerx.blogspot.com/2014/06/whats-mqtt-and-how-can-you-use-it.html -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at bitpuffin.com Thu Jul 3 08:41:48 2014 From: contact at bitpuffin.com (Isak Andersson) Date: Thu, 3 Jul 2014 17:41:48 +0200 Subject: [rust-dev] Met with a terrible fate In-Reply-To: References: Message-ID: Aright great! I'll give it a try and let you all know if there is issues. I'll check the link as well, thank you! Cheers! Isak Andersson On Thu, Jul 3, 2014 at 3:58 PM, Alex Crichton wrote: > > I am thinking that maybe one solution could be that the C code calls > > an init function that calls native::start and provides a function pointer > > that start calls back into C. That way the C main thread will have a rust > > runtime in the background, I *think*?. > > That is correct! > > > I hope this would be possible at least, the important thing is that it > can > > be > > in the main thread, as often mobile platforms require to run in the main > > thread because the GUI library needs it for some reason. At least in iOS. > > (I am building a helper lib for making apps easier with our service) > > This is indeed possible! We have many many applications and games > being written in Rust right now, and they all have the same > requirement. > > > Other than that I don't really know how much I can restructure my code to > > work without (objective-)C(#) not having to do anything special. The way > > the library will be structured is that it has an internal thread where it > > runs > > at operation queue. Once that operation queue is empty the thread > terminates > > and if you add more operations to the queue the thread starts once > again. So > > a lot of the code will run in its own thread, which is at least good. > > However > > some of the code will work outside of the operation queue for things like > > queries > > that might use some kind of mutex to make sure it's not querying > something > > that > > the operation queue is already processing. And for those mutexes to work > it > > probably > > has to be within the same native::start... Unless I can use some kind of > > unsafe C > > mutex thing. > > Right now the C => Rust FFI bridge isn't as convenient as it could be. > One option you may want to look into is what rust-civet [1] does which > is to create a new native rust task per-request, but it doesn't spawn > a thread per request. > > [1]: https://github.com/wycats/rust-civet/blob/master/src/raw.rs#L91-L106 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Thu Jul 3 19:20:03 2014 From: lists at ncameron.org (Nick Cameron) Date: Fri, 4 Jul 2014 14:20:03 +1200 Subject: [rust-dev] Older RFCs up for discussion next week Message-ID: Here are the recommendations for discussion at next weeks meeting. Last week we didn't have time to cover older RFCs at the general meeting, so last weeks RFCs are carried over. Also added is RFC 88 for an update. It was previously discussed and we decided it hadn't reached a conclusion. As usual, if you have comments on any of these RFCs, please add them to the discussion on the PR; please don't reply to this message. Cheers, Nick Proposed for discussion at Rust meeting --------------------------------------- https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix - have we reached a conclusion here? https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks huon has updated should we accept now? https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt No recommendation, just needs a kick to get moving again. https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for module imports - tommit Allow e.g., `use module::{self, Type};` for `use module::Type; use module;`. Generally positive response. Some bike shedding around the use of `self` since we call the file mod.rs, and some proposal to allow self.rs instead. Recommend we accept (possibly we should bikeshed the synax `self`). We could postpone this (it would be backwards compatible), but it seems very desirable and would be little effort to implement. https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis A lot of discussion, pretty much all about the details. General sentiment that we want this. Recommend we accept - is this the right RFC to accept, I've not really been keeping track - pnkfelix, pcwalton - is there something which supersedes this? I think this needs a small update to reflect some of the later comments. https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - stevelabnik Loads of opinion in the thread (162 comments!). Note that Niko has an upcoming RFC with the concept of unsafe/trusted traits where the keyword `trusted` makes a lot more sense than `unsafe`, so we could save a keyword here. Recommend we discuss this. https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic operators to take their arguments by value not by ref - pcwalton. Pretty negative feedback (though not all). I remember being convinced this was the proper way to implement arithmetic operators a while back, but I can't remember why (something about using tuples in the signature maybe? I can't remember). There seems to be some poor interaction with BigInt, etc. where implementing for `&BigInt` isn't what you want (but I don't see why from the comment, pcwalton seems to in his reply though). Lets discuss this. Proposed for discussion at triage --------------------------------- https://github.com/rust-lang/rfcs/pull/124 - cloned and stable - tommit allows C++-like implicit move-optimizations. `cloned` on an arg forces a pass-by-clone semantics, `stable` before an arg allow implementors to choose the passing semantics per implementation. Negative feedback. Possibly impractical due to an implementation issue. Propose close - too much complexity and uncertainty for unknown benefit. https://github.com/rust-lang/rfcs/pull/125 - prefetch intrinsics - saati Data showed no benefit and the proposer thought we should not implement after all. Question about whether we might want this on other platforms though. Recommend close (maybe as postponed) - I expect we will find a proper use case for this at some point, but would be backwards compatible to add https://github.com/rust-lang/rfcs/pull/126 - add optional type parameter to `include_bin!` - tommit Not really sure what is going on here, sorry. huon seems to know. No positive feedback and it is unsafe. Recommend close. https://github.com/rust-lang/rfcs/pull/128 - Rename mod.rs files to self.rs - tommit Just what it says in the title :-) Mixed feedback, but mostly negative. Recommend close. https://github.com/rust-lang/rfcs/pull/137 - Objects of type T should be implicitely convertible to &T - Tomaka17 Auto-borrow types in argument position as well as self position. Mixed feedback. zwarich points out a problematic interaction with copy types. Recommend close. https://github.com/rust-lang/rfcs/pull/152 and https://github.com/rust-lang/rfcs/pull/153 - function overloading of different kinds - iopq Recommend close as postponed. Actions agreed -------------- https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of tagged values - erikt Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against. erikt to update? https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern matching for slices - krdln No comments. The RFC is a little bit vague, but seems like kind of a win. Backwards incompatible. Close. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat.pryce at gmail.com Sat Jul 5 08:07:34 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Sat, 5 Jul 2014 16:07:34 +0100 Subject: [rust-dev] Mutiplexing I/O within a task Message-ID: I've been trying to write tasks that wait for both I/O and channel communication. I've been told that, to maximise communication performance, channels do not support selecting of both channels and I/O objects. Therefore a program should signal to a task that is waiting for I/O over another I/O object, such as a pipe, not by sending a message over a channel. Fair enough. What API should I use to wait for multiple I/O objects within a task? Is there a runtime-independent API for this? And if I write my own I/O abstractions, for example around eventfd on Linux, what traits (platform specific traits, I imagine) should I implement to make them work with the runtime-independent I/O select API? Sorry if this is already covered in the documentation. I've searched but not found anything obvious. Any help much appreciated. --Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Sat Jul 5 13:43:07 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sat, 5 Jul 2014 21:43:07 +0100 Subject: [rust-dev] name resolution rule for enum variants? Message-ID: Hello! I was surprised to find the following compile and run without any bother: #[deriving(Show)] pub enum MyEnum { Path } fn main() { let p = Path::new("/filepath/"); let p2 = Path; println!("{}",p.as_str()); println!("{}",p2); } % ./run Some(/filepath) Path What is the name resolution rule that stops MyEnum's Path overriding the posix Path struct? I'm interested because racer gets this wrong at the moment. Thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sat Jul 5 13:44:19 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 05 Jul 2014 13:44:19 -0700 Subject: [rust-dev] name resolution rule for enum variants? In-Reply-To: References: Message-ID: <53B863A3.2020703@mozilla.com> On 7/5/14 1:43 PM, Phil Dawes wrote: > Hello! > > I was surprised to find the following compile and run without any bother: > > #[deriving(Show)] > pub enum MyEnum { > Path > } > fn main() { > let p = Path::new("/filepath/"); > let p2 = Path; > > println!("{}",p.as_str()); > println!("{}",p2); > } > > % ./run > Some(/filepath) > Path > > What is the name resolution rule that stops MyEnum's Path overriding the > posix Path struct? I'm interested because racer gets this wrong at the > moment. Rust has two namespaces: a type namespace and a value namespace. (Modules are in the type namespace.) Structs are in the type namespace and enum variants are in the value namespace. Patrick From rustphil at phildawes.net Sat Jul 5 14:06:16 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sat, 5 Jul 2014 22:06:16 +0100 Subject: [rust-dev] name resolution rule for enum variants? In-Reply-To: <53B863A3.2020703@mozilla.com> References: <53B863A3.2020703@mozilla.com> Message-ID: Thanks Patrick, that makes sense. I need to think about how to code this into Racer. Can I assume that anything preceding a :: in a path is from the type namespace? (Is there somewhere other than the rustc source where I should be reading about this?) Thanks, Phil On Sat, Jul 5, 2014 at 9:44 PM, Patrick Walton wrote: > On 7/5/14 1:43 PM, Phil Dawes wrote: > >> Hello! >> >> I was surprised to find the following compile and run without any bother: >> >> #[deriving(Show)] >> pub enum MyEnum { >> Path >> } >> fn main() { >> let p = Path::new("/filepath/"); >> let p2 = Path; >> >> println!("{}",p.as_str()); >> println!("{}",p2); >> } >> >> % ./run >> Some(/filepath) >> Path >> >> What is the name resolution rule that stops MyEnum's Path overriding the >> posix Path struct? I'm interested because racer gets this wrong at the >> moment. >> > > Rust has two namespaces: a type namespace and a value namespace. (Modules > are in the type namespace.) Structs are in the type namespace and enum > variants are in the value namespace. > > Patrick > > _______________________________________________ > 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 pcwalton at mozilla.com Sat Jul 5 14:06:41 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 05 Jul 2014 14:06:41 -0700 Subject: [rust-dev] name resolution rule for enum variants? In-Reply-To: References: <53B863A3.2020703@mozilla.com> Message-ID: <53B868E1.2030901@mozilla.com> On 7/5/14 2:06 PM, Phil Dawes wrote: > Thanks Patrick, that makes sense. > > I need to think about how to code this into Racer. Can I assume that > anything preceding a :: in a path is from the type namespace? Yes. > (Is there somewhere other than the rustc source where I should be > reading about this?) It's somewhat documented in the manual. Patrick From dnfagnan at gmail.com Sun Jul 6 00:13:58 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Sun, 6 Jul 2014 01:13:58 -0600 Subject: [rust-dev] Mutiplexing I/O within a task In-Reply-To: References: Message-ID: I'm also interesting in some pointers on the best way to achieve this. -- Daniel Fagnan @TheHydroImpulse http://hydrocodedesign.com M: (780) 983-4997 On Sat, Jul 5, 2014 at 9:07 AM, Nat Pryce wrote: > I've been trying to write tasks that wait for both I/O and channel > communication. I've been told that, to maximise communication performance, > channels do not support selecting of both channels and I/O objects. > Therefore a program should signal to a task that is waiting for I/O over > another I/O object, such as a pipe, not by sending a message over a > channel. Fair enough. > > What API should I use to wait for multiple I/O objects within a task? Is > there a runtime-independent API for this? > > And if I write my own I/O abstractions, for example around eventfd on > Linux, what traits (platform specific traits, I imagine) should I implement > to make them work with the runtime-independent I/O select API? > > Sorry if this is already covered in the documentation. I've searched but > not found anything obvious. > > Any help much appreciated. > > --Nat > > > _______________________________________________ > 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 Sun Jul 6 13:10:47 2014 From: bombela at gmail.com (=?UTF-8?Q?Fran=C3=A7ois=2DXavier_Bourlet?=) Date: Sun, 6 Jul 2014 13:10:47 -0700 Subject: [rust-dev] Mutiplexing I/O within a task In-Reply-To: References: Message-ID: Same here, I am highly interested in the topic. On Jul 5, 2014 10:14 AM, "Nat Pryce" wrote: > I've been trying to write tasks that wait for both I/O and channel > communication. I've been told that, to maximise communication performance, > channels do not support selecting of both channels and I/O objects. > Therefore a program should signal to a task that is waiting for I/O over > another I/O object, such as a pipe, not by sending a message over a > channel. Fair enough. > > What API should I use to wait for multiple I/O objects within a task? Is > there a runtime-independent API for this? > > And if I write my own I/O abstractions, for example around eventfd on > Linux, what traits (platform specific traits, I imagine) should I implement > to make them work with the runtime-independent I/O select API? > > Sorry if this is already covered in the documentation. I've searched but > not found anything obvious. > > Any help much appreciated. > > --Nat > > > _______________________________________________ > 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 Sun Jul 6 15:09:25 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 6 Jul 2014 15:09:25 -0700 Subject: [rust-dev] Mutiplexing I/O within a task In-Reply-To: References: Message-ID: On Sat, Jul 5, 2014 at 8:07 AM, Nat Pryce wrote: > I've been trying to write tasks that wait for both I/O and channel > communication. I've been told that, to maximise communication performance, > channels do not support selecting of both channels and I/O objects. > Therefore a program should signal to a task that is waiting for I/O over > another I/O object, such as a pipe, not by sending a message over a > channel. Fair enough. > > What API should I use to wait for multiple I/O objects within a task? Is > there a runtime-independent API for this? > Sounds like you might want something like a Java NIO Selector. These Selectors bake in a pipe as a wakeup mechanism as well: http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html However, there is more than one way to do it ;) Earlier I sent this message out about providing I/O "as a service" by having a dedicated task (or pool of tasks) that performs I/O operations for you, sending completions back as messages over the normal std::comm message protocol, ala Erlang's ioserver. Perhaps it's relevant to bring up again? ---------- Forwarded message ---------- From: Tony Arcieri Date: Wed, Jan 29, 2014 at 1:40 AM Subject: Multiplexing I/O the Erlang way: an "ioserver" To: "rust-dev at mozilla.org" libnative (fast, low-latency native I/O) and libgreen (libuv backed and great for large numbers of infrequent/idle messengers) are both awesome and provide some great options for network server I/O, particularly since you can mix-and-match them. However there's a seemingly unsolved problem in Rust: multiplexing I/O operations with channels. I think this can be fixed in a purely additive manner (i.e everything else that exists today is great!) with a new feature borrowed from Erlang: the ioserver (noting that Erlang also implements libgreen-style synchronous I/O in addition to ioserver) Ignoring Erlang for a second, the naive solution to the I/O + channel multiplexing is magic select API that can handle both. In my experience (i.e. I wrote and support this approach in a system some people actually use) the backend implementation, especially across POSIX and Windows, ends up quite ugly. There's a better option though... if you want to multiplex IO with channel messages, turn everything into channel messages in one place: the "ioserver" Solution: Centralize I/O event loops into a separate thread (pool if necessary, probably not). Erlang and 0MQ work this way. Erlang implements an API called a "port" to talk to the ioserver. In Rust perhaps you could have a type that implements the same trait as channels? The ioserver becomes the central place to optimize the nitty gritty of taking I/O requests from the rest of the program and multiplexing them with other (i.e channel) events in the system. The basic formula is: - Have the ioserver block for events using libuv or what have you, and have an OS-specific I/O handle (i.e. a pipe) to unblock the selector in the event of in-process communication - Use lock-free mechanisms so if the selector isn't stuck in a system call we can use more efficient coordination of registering and unregistering I/O op interests (Note: libuv is an I/O completions library and not a selector library so the proposed solution is admittedly a bit handwavey) Mixing a pipe-based wakeup mechanism with lock-free operations to eliminate unnecessary system calls has been used somewhat successfully in the Netty I/O library for the JVM. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at kelleysoft.com Sun Jul 6 16:34:57 2014 From: kevin at kelleysoft.com (Kevin Kelley) Date: Sun, 6 Jul 2014 17:34:57 -0600 Subject: [rust-dev] [ANN] Rust binding for NanoVG vector-graphics library Message-ID: <00da01cf9972$e6fb3ce0$b4f1b6a0$@kelleysoft.com> I'd like to announce a binding to NanoVG - a small vector-graphics library written in C that runs on OpenGL backends. I'm using this project as a way to familiarize with Rust, and so am happy to learn whatever I can. Comments and suggestions are very welcome. The project is at https://github.com/KevinKelley/nanovg-rs NanoVG (https://github.com/memononen/nanovg) gives you a low-level vector graphics context, from which you can compose shapes, gradients, beziers, and so on; all generated through OpenGL primitives (I think there's a Direct3D port too). Image-loading is from stb-image; and truetype fonts are supported as well. It's a small library; it doesn't have the extent of cairo-graphics but it's fast. I have implemented the complete API in rust starting with rust-bindgen, and directly translated the example demo to Rust. At the moment that's the only sort of documentation I've done - you'll have to look into the source to see how it works. The original NanoVG headers are pretty well documented, and I'll move that text into my wrapper so that rust-doc can find it. shortly. Development is done on linux, using the OpenGL3 backend. I'll be testing on Windows at some point, but haven't yet; Mac is not in my budget. It might be worthwhile at some point to port the library to Rust, rather than wrapping it; on the other hand that would mean more difficulty tracking updates to the original project. Anyway. It's here, and it runs; it's early days so expect some warts. But it's something that I definitely needed, so maybe it's useful to others as well. License on the NanoVG project is zlib; I'm putting this bindings project under MIT. Thanks, Kevin Kelley -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat.pryce at gmail.com Sun Jul 6 22:23:24 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Mon, 7 Jul 2014 06:23:24 +0100 Subject: [rust-dev] Mutiplexing I/O within a task In-Reply-To: References: Message-ID: Yes, I do want something like an nio Selector. I'm trying to write it myself using epoll and eventfd on Linux. Binding to the syscall is straightforward. However I can't work out how to get the fds of IO objects (File struct, for example) so am stuck again. The ioserver approach sounds promising as long as it can be easily extended with new I/O mechanisms. One thing to keep in mind is that not all I/O can be made non-blocking. Eg I2C and SPI communication on Linux is performed by ioctls that block the calling thread and so would block an event loop that relies on nonblocking IO. --Nat On Sunday, July 6, 2014, Tony Arcieri wrote: > On Sat, Jul 5, 2014 at 8:07 AM, Nat Pryce > wrote: > >> I've been trying to write tasks that wait for both I/O and channel >> communication. I've been told that, to maximise communication performance, >> channels do not support selecting of both channels and I/O objects. >> Therefore a program should signal to a task that is waiting for I/O over >> another I/O object, such as a pipe, not by sending a message over a >> channel. Fair enough. >> >> What API should I use to wait for multiple I/O objects within a task? Is >> there a runtime-independent API for this? >> > > Sounds like you might want something like a Java NIO Selector. These > Selectors bake in a pipe as a wakeup mechanism as well: > > http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html > > However, there is more than one way to do it ;) Earlier I sent this > message out about providing I/O "as a service" by having a dedicated task > (or pool of tasks) that performs I/O operations for you, sending > completions back as messages over the normal std::comm message protocol, > ala Erlang's ioserver. Perhaps it's relevant to bring up again? > > ---------- Forwarded message ---------- > From: Tony Arcieri > > Date: Wed, Jan 29, 2014 at 1:40 AM > Subject: Multiplexing I/O the Erlang way: an "ioserver" > To: "rust-dev at mozilla.org > " < > rust-dev at mozilla.org > > > > > libnative (fast, low-latency native I/O) and libgreen (libuv backed and > great for large numbers of infrequent/idle messengers) are both awesome and > provide some great options for network server I/O, particularly since you > can mix-and-match them. > > However there's a seemingly unsolved problem in Rust: multiplexing I/O > operations with channels. I think this can be fixed in a purely additive > manner (i.e everything else that exists today is great!) with a new feature > borrowed from Erlang: the ioserver (noting that Erlang also implements > libgreen-style synchronous I/O in addition to ioserver) > > Ignoring Erlang for a second, the naive solution to the I/O + channel > multiplexing is magic select API that can handle both. In my experience > (i.e. I wrote and support this approach in a system some people actually > use) the backend implementation, especially across POSIX and Windows, ends > up quite ugly. > > There's a better option though... if you want to multiplex IO with channel > messages, turn everything into channel messages in one place: the "ioserver" > > Solution: Centralize I/O event loops into a separate thread (pool if > necessary, probably not). Erlang and 0MQ work this way. Erlang implements > an API called a "port" to talk to the ioserver. In Rust perhaps you could > have a type that implements the same trait as channels? > > The ioserver becomes the central place to optimize the nitty gritty of > taking I/O requests from the rest of the program and multiplexing them with > other (i.e channel) events in the system. The basic formula is: > > - Have the ioserver block for events using libuv or what have you, and > have an OS-specific I/O handle (i.e. a pipe) to unblock the selector in the > event of in-process communication > - Use lock-free mechanisms so if the selector isn't stuck in a system call > we can use more efficient coordination of registering and unregistering I/O > op interests > > (Note: libuv is an I/O completions library and not a selector library so > the proposed solution is admittedly a bit handwavey) > > Mixing a pipe-based wakeup mechanism with lock-free operations to > eliminate unnecessary system calls has been used somewhat successfully in > the Netty I/O library for the JVM. > > -- > Tony Arcieri > -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantix.king at gmail.com Mon Jul 7 07:56:12 2014 From: fantix.king at gmail.com (Fantix King) Date: Mon, 7 Jul 2014 22:56:12 +0800 Subject: [rust-dev] Mutiplexing I/O within a task In-Reply-To: References: Message-ID: <4E4818DD-1A93-4416-B968-6B87EE3BF12E@gmail.com> > ? 2014?7?5????11:07?Nat Pryce ??? > > I've been trying to write tasks that wait for both I/O and channel communication. I've been told that, to maximise communication performance, channels do not support selecting of both channels and I/O objects. Therefore a program should signal to a task that is waiting for I/O over another I/O object, such as a pipe, not by sending a message over a channel. Fair enough. I was thinking about almost the same thing when trying zmq.rs, but end up with something very different, which might be a bit different than what is in the thread topic. The ioserver solution will certainly work, yet I'm trying to do it differently. Let me try to start with your problem here - why it is wanted to wait on both I/O and channel communication? For my case, I had two reasons: (please let me know if your case is different) 1. Both I/O and channel may produce data at any time in any order for one piece of logic (task) to handle 2. It is wanted that the blocking I/O call can somehow be interrupted so that other code can run cooperatively. For 1 I simply wrapped the I/O operation in a separate Task, communicating with the main Task with a normal channel, which can then be selected together with other channels. With libgreen I think it is a pretty direct decision, because Tasks are very cheap and cooperatively scheduled under the hood which is exactly what we wanted. With libnative it is a bit ugly, there might be hundreds of Tasks to create, so it might be sane to mix in a libgreen scheduler here for those Tasks. As for 2, it does not need to be interrupted for task scheduling any more. However interrupt is still wanted in order to, for example, shutdown the Task. I used a timeout on the I/O operation (thanks to recent changes in Rust), so when the rest of the world is gone, the I/O call times out shortly and the Task fails trying to report the timeout through a broken channel. Drawback is the program freezes for a while on exit. For socket I/O it is also possible to be interrupted by close_read() or close_write() calls. Please see also my blog post http://blog.segmentfault.com/fantix/1190000000593564 and tcp_lisrener.rs of zmq.rs https://github.com/zeromq/zmq.rs/blob/master/src/tcp_listener.rs. I'd love to know if my solution for I/O is reasonable too. BR, Fantix > > What API should I use to wait for multiple I/O objects within a task? Is there a runtime-independent API for this? > > And if I write my own I/O abstractions, for example around eventfd on Linux, what traits (platform specific traits, I imagine) should I implement to make them work with the runtime-independent I/O select API? > > Sorry if this is already covered in the documentation. I've searched but not found anything obvious. > > Any help much appreciated. > > --Nat > > _______________________________________________ > 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 Mon Jul 7 09:50:17 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Mon, 7 Jul 2014 09:50:17 -0700 Subject: [rust-dev] Seattle Meetup in July In-Reply-To: References: Message-ID: A friendly day-of reminder - this meetup is happening TODAY. We have 8 people marked as attending in Eventbrite - I'm looking forward to seeing you! On Tue, Jul 1, 2014 at 1:48 PM, Paul Nathan wrote: > Hello everyone! > > It looks like no one has expressed strong opinions on the actual date of > the meetup. I have travel next week Wed-Friday, so I pick Monday, June 7th. > :-) > > - Eric from UW has offered to give presentations on either the borrow > checker or the runtime. Please let Eric know what you'd like to see! > > - I will offer up some remarks on my experiences writing a CI server in > Rust, as someone coming primarily from fully refcounted/GC'd languages. > > My employer has graciously allowed me to host the meetup at their office: > > Climate Corporation > 419 Occidental Ave S > Seattle, WA 98104 > > It is approximately 5 minutes walk from the International District transit > station. Car parking exists over by the stadia. > > I've created an event in EventBrite to gauge attendance - it'd be > appreciated if you got a free "ticket" to RSVP. > > https://www.eventbrite.com/e/seattle-mozilla-rust-meetup-tickets-12142932839 > > Please let your friends and colleagues know about this. :-) > > > > On Thu, Jun 19, 2014 at 11:17 PM, Paul Nathan > wrote: > >> Good evening Rust colleagues; >> >> As we discussed at the May Seattle meetup (A success! about 6 people from >> larger, smaller, and academic environments visited), we'd like to meetup in >> July and talk about our current projects in a quasi-presentation format at >> one of the local companies or the University of Washington. >> >> I'd like to propose a day in the July 7-11 range with the following >> agenda: >> >> *7pm Start* >> >> - 20 minutes Meet & Greet >> - 2-4 10-minute long presentations of different projects (ideas, scraps >> of code, working projects). >> - 1-2 20-minute presentations - I think Eli? from UW volunteered to talk >> about the borrow checker. >> - 20 minutes Socialize More >> >> *9pm end* >> >> If I remember right, several different venues with projectors/large TVs >> were an option... I know I can lay my hands on at least one venue. :-) >> >> Best Regards, >> Paul Nathan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Jul 8 15:57:27 2014 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 08 Jul 2014 15:57:27 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries Message-ID: <53BC7757.5000200@mozilla.com> Hi. Very soon now the way rustc links crates dynamically is going to change[1], and it will impact the way you work with Rust in some important cases. The TL;DR is that rustc will no longer encode RPATH information in the binaries it produces, so the dynamic linker will be less likely to find the dynamic library (.so, .dylib) dependencies; in some scenarios people will need to use LD_LIBRARY_PATH or rely on higher-level tooling to arrange for libraries to be discovered by the dynamic linker at runtime. [1]: https://github.com/rust-lang/rust/pull/14832 # Background When the OS loads an executable, the dynamic linker searches some set of paths for it's dynamic library dependencies. If it doesn't find them, the program doesn't run, and for the most part the dynamic linker only searches a few system-defined locations, meaning that you're uninstalled development libraries won't be discovered by default. This is a common minor annoyance that is often solved by setting `LD_LIBRARY_PATH` to include the directories containing the dependencies. Long ago Rust tried to solve this annoyance with RPATH. With RPATH you encode potential directories for the dynamic linker to search for dependencies *inside* the dependent libraries. rustc by default puts a few strategically-crafted RPATHs in its binaries that for the most part make the dynamic loading 'just work'. Over time though we've concluded that we should not be doing this. Firstly, this mechanism just doesn't work on Windows. For a while we tried to come up with a hack to simulate the behavior on Windows, but if there are any possibilities there they are very ugly and out of place in a language like Rust that tries not to do too much magic behind the scenes. As it stands now, the models on Unix and Windows are very different, which is a difficult discrepancy to justify. Secondly, using RPATH is widely considered a bad practice. The primary risk with RPATH is that an attacker will place a substitute library on a known RPATH, injecting malicious code. I believe there are other considerations as well. Finally, this behavior is inconsistent with other low-level languages, and inconsistent with the direction we've been moving in for e.g. library versioning. In general the user, or tools higher in the stack, should be in control over how they use their binaries, and Rust shouldn't be enforcing too much policy after compile-time. So we're turning it off. The previous behavior can be restored by passing --rpath to rustc, or re-enabled for the Rust distribution itself by passing --enable-rpath to configure. # Impact Because static linking is the default in Rust, *by default* this change should have no impact on casual and new users unless they are explicitly opting in to dynamic linking. Dynamic libraries installed as part of the Rust distribution should continue to be discovered correctly by the dynamic linker, modulo some potential bugs. *Running rustc directly from the build directory will no longer work by default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath to the configure script. Installing rustc to non-default locations will result in an installation that puts some important libraries in a location the dynamic linker won't find, will need to be compensated for with LD_LIBRARY_PATH. Rust executables that link to dynamic Rust libraries outside of the system paths will not run without LD_LIBRARY_PATH. Thanks. Have a nice day. From simon.sapin at exyr.org Tue Jul 8 16:41:19 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 09 Jul 2014 00:41:19 +0100 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC7757.5000200@mozilla.com> References: <53BC7757.5000200@mozilla.com> Message-ID: <53BC819F.8080901@exyr.org> On 08/07/14 23:57, Brian Anderson wrote: > *Running rustc directly from the build directory will no longer work by > default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath > to the configure script. Does this also apply to running a (nightly) binary distribution from where the tarball was extracted, without installing it? -- Simon Sapin From banderson at mozilla.com Tue Jul 8 16:53:44 2014 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 08 Jul 2014 16:53:44 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC819F.8080901@exyr.org> References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> Message-ID: <53BC8488.3040009@mozilla.com> Yes, it does. On 07/08/2014 04:41 PM, Simon Sapin wrote: > On 08/07/14 23:57, Brian Anderson wrote: >> *Running rustc directly from the build directory will no longer work by >> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath >> to the configure script. > > Does this also apply to running a (nightly) binary distribution from > where the tarball was extracted, without installing it? > From gsingh_2011 at yahoo.com Tue Jul 8 23:47:06 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Tue, 8 Jul 2014 23:47:06 -0700 Subject: [rust-dev] Daemonizing a process Message-ID: Is there currently any way to daemonize a process in Linux? I was using the `daemon` function in C: http://man7.org/linux/man-pages/man3/daemon.3.html. I asked in the IRC but I didn't get a response. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richo at psych0tik.net Wed Jul 9 00:32:54 2014 From: richo at psych0tik.net (richo) Date: Wed, 9 Jul 2014 17:32:54 +1000 Subject: [rust-dev] Daemonizing a process In-Reply-To: References: Message-ID: <20140709073254.GA1179@xenia.local> On 08/07/14 23:47 -0700, Gulshan Singh wrote: >Is there currently any way to daemonize a process in Linux? I was using the >`daemon` function in C: http://man7.org/linux/man-pages/man3/daemon.3.html. >I asked in the IRC but I didn't get a response. There's going to be excitement with this, mostly because typically daemonising involves forking twice to ensure that you're reparented to init, which will result in a Really Bad Time if you're using libnative. Therefore, it's possible but only if you've not done too much stuff, which would be unsafe. Seperately though, rust *does* need a coherent story here. I'm just not at all sure what it will look like. From errordeveloper at gmail.com Wed Jul 9 01:00:42 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 9 Jul 2014 09:00:42 +0100 Subject: [rust-dev] Daemonizing a process In-Reply-To: <20140709073254.GA1179@xenia.local> References: <20140709073254.GA1179@xenia.local> Message-ID: Additionally, I'd like to note that modern best practice is to relay this on the init process itself. With modern init systems, such as systemd or launchctl, this works very nicely and application developer doesn't have to care about daemonisation and logging is also done simply via stdout. On 9 Jul 2014 08:33, "richo" wrote: > On 08/07/14 23:47 -0700, Gulshan Singh wrote: > >> Is there currently any way to daemonize a process in Linux? I was using >> the >> `daemon` function in C: http://man7.org/linux/man- >> pages/man3/daemon.3.html. >> I asked in the IRC but I didn't get a response. >> > > There's going to be excitement with this, mostly because typically > daemonising involves forking twice to ensure that you're reparented to > init, > which will result in a Really Bad Time if you're using libnative. > > Therefore, it's possible but only if you've not done too much stuff, which > would be unsafe. > > Seperately though, rust *does* need a coherent story here. I'm just not at > all sure what it will look like. > > _______________________________________________ > 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 errordeveloper at gmail.com Wed Jul 9 03:25:50 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 9 Jul 2014 11:25:50 +0100 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC8488.3040009@mozilla.com> References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: Is the following error cause by this change? % rustc -v dyld: Library not loaded: x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc Reason: image not found Trace/BPT trap On 9 July 2014 00:53, Brian Anderson wrote: > Yes, it does. > > > On 07/08/2014 04:41 PM, Simon Sapin wrote: >> >> On 08/07/14 23:57, Brian Anderson wrote: >>> >>> *Running rustc directly from the build directory will no longer work by >>> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath >>> to the configure script. >> >> >> Does this also apply to running a (nightly) binary distribution from where >> the tarball was extracted, without installing it? >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From olson.jeffery at gmail.com Wed Jul 9 06:37:18 2014 From: olson.jeffery at gmail.com (Jeffery Olson) Date: Wed, 9 Jul 2014 08:37:18 -0500 Subject: [rust-dev] Issue running documented functions from doc code w/ rustdoc Message-ID: Consider the following docs: /// Foo /// /// ```rust /// under_test(); /// ``` pub fn under_test() { } doing `rustdoc main.rs --test` produces: jeff at jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test running 1 test test foo::under_test_0 ... FAILED failures: ---- foo::under_test_0 stdout ---- :5:5: 5:15 error: unresolved name `under_test`. :5 under_test(); ^~~~~~~~~~ error: aborting due to previous error task 'foo::under_test_0' failed at 'Box', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/ diagnostic.rs:128 failures: foo::under_test_0 test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured Why is this? I've also tried different combinations of module imports to get this to work.. the only place this feature is used, extensively, is in libstd and it appears that maybe this is sidestepped because libstd is always linked by default? The manual doesn't really cover this in-depth, either. Any help would be appreciated. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Jul 9 07:02:40 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 9 Jul 2014 10:02:40 -0400 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: It is indeed! You'll need to ensure that `/Users/ilya/Library/Local/Rust/current/lib` is in your DYLD_LIBRARY_PATH environment variable for OSX. On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko wrote: > Is the following error cause by this change? > > % rustc -v > dyld: Library not loaded: > x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib > Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc > Reason: image not found > Trace/BPT trap > > > On 9 July 2014 00:53, Brian Anderson wrote: >> Yes, it does. >> >> >> On 07/08/2014 04:41 PM, Simon Sapin wrote: >>> >>> On 08/07/14 23:57, Brian Anderson wrote: >>>> >>>> *Running rustc directly from the build directory will no longer work by >>>> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath >>>> to the configure script. >>> >>> >>> Does this also apply to running a (nightly) binary distribution from where >>> the tarball was extracted, without installing it? >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From bob at redivi.com Wed Jul 9 07:42:02 2014 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Jul 2014 07:42:02 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: This seems like madness. No other programming language out there that I've seen requires developers to mangle these environment variables. On Mac, if you don't want all of RPATH to be searched, you can use more specific relative paths such as @executable_path or @loader_path in the load command. If rust does end up sticking with this regression, it should replace all of the tools with little shell scripts that set them appropriately for you and before invoking the real tool. On Wednesday, July 9, 2014, Alex Crichton wrote: > It is indeed! You'll need to ensure that > `/Users/ilya/Library/Local/Rust/current/lib` is in your > DYLD_LIBRARY_PATH environment variable for OSX. > > On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko > > wrote: > > Is the following error cause by this change? > > > > % rustc -v > > dyld: Library not loaded: > > > x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib > > Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc > > Reason: image not found > > Trace/BPT trap > > > > > > On 9 July 2014 00:53, Brian Anderson > wrote: > >> Yes, it does. > >> > >> > >> On 07/08/2014 04:41 PM, Simon Sapin wrote: > >>> > >>> On 08/07/14 23:57, Brian Anderson wrote: > >>>> > >>>> *Running rustc directly from the build directory will no longer work > by > >>>> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath > >>>> to the configure script. > >>> > >>> > >>> Does this also apply to running a (nightly) binary distribution from > where > >>> the tarball was extracted, without installing it? > >>> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Jul 9 07:56:50 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 9 Jul 2014 10:56:50 -0400 Subject: [rust-dev] Issue running documented functions from doc code w/ rustdoc In-Reply-To: References: Message-ID: Doc tests are compiled as if they were clients of a library, so you'll have to write the test assuming the rest of the source was built with `--crate-type lib` and then import it directly. For example, you may have to do this: ```rust main::under_test(); ``` Doc test aren't really designed with executables in mind, sadly, but perhaps that could change! On Wed, Jul 9, 2014 at 9:37 AM, Jeffery Olson wrote: > Consider the following docs: > > > /// Foo > /// > /// ```rust > /// under_test(); > /// ``` > pub fn under_test() { > } > > doing `rustdoc main.rs --test` produces: > > jeff at jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test > > running 1 test > test foo::under_test_0 ... FAILED > > failures: > > ---- foo::under_test_0 stdout ---- > :5:5: 5:15 error: unresolved name `under_test`. > :5 under_test(); > ^~~~~~~~~~ > error: aborting due to previous error > task 'foo::under_test_0' failed at 'Box', > /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:128 > > > > failures: > foo::under_test_0 > > test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured > > > Why is this? I've also tried different combinations of module imports to get > this to work.. the only place this feature is used, extensively, is in > libstd and it appears that maybe this is sidestepped because libstd is > always linked by default? The manual doesn't really cover this in-depth, > either. > > Any help would be appreciated. > > Thanks, > Jeff > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From chandru.in at gmail.com Wed Jul 9 05:13:09 2014 From: chandru.in at gmail.com (Chandru) Date: Wed, 9 Jul 2014 17:43:09 +0530 Subject: [rust-dev] Stack usage of green tasks Message-ID: Hi, This piece of code, #![feature(phase)] #[phase(plugin)] extern crate green; use std::io::timer; use std::task::TaskBuilder; green_start!(main) fn main() { for _ in range(0, 10000i) { TaskBuilder::new().stack_size(20*1024).spawn(proc() { timer::sleep(20000) }); } } fails with, task '' has overflowed its stack Illegal instruction (core dumped) Changing the stack size to 21K works. Why does such a trivial task overflow 20K of stack? -- Chandra Sekar.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Jul 9 08:06:51 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 9 Jul 2014 11:06:51 -0400 Subject: [rust-dev] Stack usage of green tasks In-Reply-To: References: Message-ID: By default, each stack is allocated with a "red zone" at the end for running code on stack overflow, calling C functions, etc. The current size of the red zone is 20K. Requested stack sizes are always at least 20K, but the 20K is not currently added to the stack size. So for your test case when you request a 20K stack you're likely getting a ~10 byte stack (explaining the overflow), and with a 21K stack you get a 1K stack which the task can run in. On Wed, Jul 9, 2014 at 8:13 AM, Chandru wrote: > Hi, > > This piece of code, > > #![feature(phase)] > #[phase(plugin)] > extern crate green; > > use std::io::timer; > use std::task::TaskBuilder; > > green_start!(main) > > fn main() { > for _ in range(0, 10000i) { > TaskBuilder::new().stack_size(20*1024).spawn(proc() { > timer::sleep(20000) > }); > } > } > > fails with, > > task '' has overflowed its stack > Illegal instruction (core dumped) > > Changing the stack size to 21K works. Why does such a trivial task overflow > 20K of stack? > > -- > Chandra Sekar.S > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From chandru.in at gmail.com Wed Jul 9 08:11:23 2014 From: chandru.in at gmail.com (Chandru) Date: Wed, 9 Jul 2014 20:41:23 +0530 Subject: [rust-dev] Stack usage of green tasks In-Reply-To: References: Message-ID: Thanks a lot. After about an hour of searching around, I found the RED_ZONE in stack.rs -- Chandra Sekar.S On Wed, Jul 9, 2014 at 8:36 PM, Alex Crichton wrote: > By default, each stack is allocated with a "red zone" at the end for > running code on stack overflow, calling C functions, etc. The current > size of the red zone is 20K. > > Requested stack sizes are always at least 20K, but the 20K is not > currently added to the stack size. So for your test case when you > request a 20K stack you're likely getting a ~10 byte stack (explaining > the overflow), and with a 21K stack you get a 1K stack which the task > can run in. > > On Wed, Jul 9, 2014 at 8:13 AM, Chandru wrote: > > Hi, > > > > This piece of code, > > > > #![feature(phase)] > > #[phase(plugin)] > > extern crate green; > > > > use std::io::timer; > > use std::task::TaskBuilder; > > > > green_start!(main) > > > > fn main() { > > for _ in range(0, 10000i) { > > TaskBuilder::new().stack_size(20*1024).spawn(proc() { > > timer::sleep(20000) > > }); > > } > > } > > > > fails with, > > > > task '' has overflowed its stack > > Illegal instruction (core dumped) > > > > Changing the stack size to 21K works. Why does such a trivial task > overflow > > 20K of stack? > > > > -- > > Chandra Sekar.S > > > > _______________________________________________ > > 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 pcwalton at mozilla.com Wed Jul 9 09:29:17 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 09 Jul 2014 09:29:17 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: <53BD6DDD.50302@mozilla.com> On 7/9/14 7:42 AM, Bob Ippolito wrote: > This seems like madness. No other programming language out there that > I've seen requires developers to mangle these environment variables. Note that rpath never worked on Windows [1], so it could never be a long-term solution. Patrick [1]: http://stackoverflow.com/questions/107888/is-there-a-windows-msvc-equivalent-to-the-rpath-linker-flag From bob at redivi.com Wed Jul 9 09:44:19 2014 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Jul 2014 09:44:19 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BD6DDD.50302@mozilla.com> References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> <53BD6DDD.50302@mozilla.com> Message-ID: On Wed, Jul 9, 2014 at 9:29 AM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Note that rpath never worked on Windows [1], so it could never be a > long-term solution. > Well, you could emulate it with runtime dynamic linking I guess, but my point is that this is a silly regression. Why hobble every platform just because of Windows? It's fine if you don't want to use @rpath, but you should at least use absolute paths to libraries on Mac, if not @executable_path or @loader_path. Windows will by default search the equivalent of @executable_path/.. if I'm reading [1] correctly. If you wanted a Mac solution that works in 100% of all cases the only solution is absolute paths because dyld will ignore environment variables, @executable_path, and @loader_path if the executable is restricted (setuid, etc.) [2]. [1] http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx#standard_search_order_for_desktop_applications [2] http://www.opensource.apple.com/source/dyld/dyld-239.4/src/dyld.cpp (see processRestricted, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Jul 9 09:48:42 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 09 Jul 2014 09:48:42 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: <53BD726A.7010004@mozilla.com> On 7/9/14 7:42 AM, Bob Ippolito wrote: > This seems like madness. No other programming language out there that > I've seen requires developers to mangle these environment variables. Also, when installing Rust you don't have to mangle these environment variables, since the libraries will be placed into the right place. This should only impact anyone who builds from source without installing. As detailed in the meeting where this decision was made, Linux distros really dislike it when you mess with rpath; it's a deal-breaker in many cases. Patrick From banderson at mozilla.com Wed Jul 9 09:50:04 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 09 Jul 2014 09:50:04 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> Message-ID: <53BD72BC.6010506@mozilla.com> Other programming languages do this. C and C++ do not mandate the use of RPATH, and Rust not applying RPATH by default doesn't exclude people opting into it if they want. In this context I am also considering @executable_path and @loader_path to be 'RPATH', and in fact @loader_path is the feature being disabled on OS X. On 07/09/2014 07:42 AM, Bob Ippolito wrote: > This seems like madness. No other programming language out there that > I've seen requires developers to mangle these environment variables. > On Mac, if you don't want all of RPATH to be searched, you can use > more specific relative paths such as @executable_path or > @loader_path in the load command. If rust does end up sticking with > this regression, it should replace all of the tools with little shell > scripts that set them appropriately for you and before invoking the > real tool. > > On Wednesday, July 9, 2014, Alex Crichton > wrote: > > It is indeed! You'll need to ensure that > `/Users/ilya/Library/Local/Rust/current/lib` is in your > DYLD_LIBRARY_PATH environment variable for OSX. > > On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko > > wrote: > > Is the following error cause by this change? > > > > % rustc -v > > dyld: Library not loaded: > > > x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib > > Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc > > Reason: image not found > > Trace/BPT trap > > > > > > On 9 July 2014 00:53, Brian Anderson > wrote: > >> Yes, it does. > >> > >> > >> On 07/08/2014 04:41 PM, Simon Sapin wrote: > >>> > >>> On 08/07/14 23:57, Brian Anderson wrote: > >>>> > >>>> *Running rustc directly from the build directory will no > longer work by > >>>> default*. To do this either set LD_LIBRARY_PATH or pass > --enable-rpath > >>>> to the configure script. > >>> > >>> > >>> Does this also apply to running a (nightly) binary > distribution from where > >>> the tarball was extracted, without installing it? > >>> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > 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 bob at redivi.com Wed Jul 9 09:54:55 2014 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Jul 2014 09:54:55 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BD726A.7010004@mozilla.com> References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> <53BD726A.7010004@mozilla.com> Message-ID: On Wed, Jul 9, 2014 at 9:48 AM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Also, when installing Rust you don't have to mangle these environment > variables, since the libraries will be placed into the right place. This > should only impact anyone who builds from source without installing. > Fair enough, although you could make it work in both scenarios without environment variables on Mac by linking with absolute paths and -headerpad_max_install_names to the build directory and then rewriting the load commands to the final destination with install_name_tool on install. Probably more trouble than it's worth. > As detailed in the meeting where this decision was made, Linux distros > really dislike it when you mess with rpath; it's a deal-breaker in many > cases. Agreed, I misunderstood that everything does work correctly when installed. My bad! -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Wed Jul 9 13:11:07 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Wed, 09 Jul 2014 16:11:07 -0400 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC7757.5000200@mozilla.com> References: <53BC7757.5000200@mozilla.com> Message-ID: <874myqwaw4.fsf@gmail.com> Brian Anderson writes: > Hi. > > Very soon now the way rustc links crates dynamically is going to > change[1], and it will impact the way you work with Rust in some > important cases. The TL;DR is that rustc will no longer encode RPATH > information in the binaries it produces, so the dynamic linker will be > less likely to find the dynamic library (.so, .dylib) dependencies; in > some scenarios people will need to use LD_LIBRARY_PATH or rely on > higher-level tooling to arrange for libraries to be discovered by the > dynamic linker at runtime. > Perhaps I'm missing something obvious here, but this broke `make install` in the rustc tree for me. The cause appears to be that `make install` tries to verify that it can run the new `rustc` binary in place, which expectedly fails due to missing libraries, /opt/exp/rust $ make install ... install: verifying platform can run binaries /opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: error while loading shared libraries: libnative-4e7c5e5c.so: cannot open shared object file: No such file or directory install: error: can't execute rustc binary on this platform make: *** [install] Error 1 Surely I don't need to mangle LD_LIBRARY_PATH just to run `make install`? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From sfackler at gmail.com Wed Jul 9 13:44:27 2014 From: sfackler at gmail.com (Steven Fackler) Date: Wed, 9 Jul 2014 13:44:27 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <874myqwaw4.fsf@gmail.com> References: <53BC7757.5000200@mozilla.com> <874myqwaw4.fsf@gmail.com> Message-ID: There's a fix for make install waiting on bors right now: https://github.com/rust-lang/rust/pull/15550 Steven Fackler On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari wrote: > Brian Anderson writes: > > > Hi. > > > > Very soon now the way rustc links crates dynamically is going to > > change[1], and it will impact the way you work with Rust in some > > important cases. The TL;DR is that rustc will no longer encode RPATH > > information in the binaries it produces, so the dynamic linker will be > > less likely to find the dynamic library (.so, .dylib) dependencies; in > > some scenarios people will need to use LD_LIBRARY_PATH or rely on > > higher-level tooling to arrange for libraries to be discovered by the > > dynamic linker at runtime. > > > Perhaps I'm missing something obvious here, but this broke `make > install` in the rustc tree for me. The cause appears to be that `make > install` tries to verify that it can run the new `rustc` binary in > place, which expectedly fails due to missing libraries, > > /opt/exp/rust $ make install > ... > install: verifying platform can run binaries > /opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: > error while loading shared libraries: libnative-4e7c5e5c.so: cannot open > shared object file: No such file or directory > install: error: can't execute rustc binary on this platform > make: *** [install] Error 1 > > Surely I don't need to mangle LD_LIBRARY_PATH just to run `make > install`? > > Cheers, > > - Ben > > _______________________________________________ > 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 ntypanski at gmail.com Wed Jul 9 14:13:46 2014 From: ntypanski at gmail.com (Nathan Typanski) Date: Wed, 9 Jul 2014 17:13:46 -0400 Subject: [rust-dev] Syntax sugar: Vec Rc RefCell Box Foo -> Vec>>> In-Reply-To: References: <1403995726.2953.4.camel@vigil> <1404061009.2953.8.camel@vigil> Message-ID: <20140709211346.GA13545@gmail.com> I ran stats on the type parameters on Rust's master branch. (I was dumb and only sent this to Ben Striegel last time. My fault for not knowing how to use an email client.) On 06/30, Benjamin Striegel wrote: > Whether or not we want something like this, I'd be fascinated if someone > managed to gather stats on how many types take only a single type parameter. I had to do part of this by hand (thanks to false positives and it being cumbersome to script for lifetime parameters) but I ran ag "pub.*struct.*<.*(?" > typed in the rustc directory, did my best to weed out false positives, and then counted by crate both the total and the number with only one parameter. So these numbers could be off by a bit - it's possible to write structs that the regex above won't match, and it's possible that somewhere I made a mistake counting things, but this should give a nice rough idea. - 160/191 (84%) parameterized structs in the "standard crates" take only one type parameter. - 40/50 in libcore - 9/10 in librand - 5/5 in liballoc - 1/1 in debug - 5/5 in librustrt - 1/1 in libtest - 2/2 in libterm - 23/24 in libsync - 3/3 in libserialize - 19/28 in libstd - 8/8 in libsyntax - 27/34 in libcollections - 11/14 in librustc - 2/2 in libgreen - 1/1 in libnative - 1/1 in libarena - 2/2 in libnum For traits: - 52/74 (70%) of parameterized traits take one type parameter. - 23/37 in libcore - 1/1 in librustrt - 1/3 in libgraphviz - 4/4 in librand - 1/1 in libterm - 4/6 in libserialize - 11/13 in libcollections - 2/3 in librustc - 2/3 in libstd - 1/1 in librustdoc - 1/1 in librustuv - 1/1 in libsyntax Nathan From davidb at davidb.org Thu Jul 10 04:56:46 2014 From: davidb at davidb.org (David Brown) Date: Thu, 10 Jul 2014 04:56:46 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC7757.5000200@mozilla.com> References: <53BC7757.5000200@mozilla.com> Message-ID: <20140710115645.GA16392@davidb.org> On Tue, Jul 08, 2014 at 03:57:27PM -0700, Brian Anderson wrote: >So we're turning it off. The previous behavior can be restored by >passing --rpath to rustc, or re-enabled for the Rust distribution >itself by passing --enable-rpath to configure. Is the intent to have this --rpath and especially --enable-rpath option remain, or are they options to enable what is considered a deprecated feature? If it's going to remain around, it seems like adding --enable-rpath is just the right thing to do when building rust from source (and, for example, installing it in /usr/local, or /opt). Is there any reason the nightly binaries shouldn't be built with this option? David From gioele at svario.it Thu Jul 10 00:46:18 2014 From: gioele at svario.it (Gioele Barabucci) Date: Thu, 10 Jul 2014 09:46:18 +0200 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation Message-ID: <53BE44CA.9030503@svario.it> Hi, the current robots.txt on docs.rust-lang.org prevents Archive.org from storing copies of the old documentation. I think having the old documentation archived would be a good thing. BTW, all the documentation before 0.10 seems gone and this is a shame. Could you please allow the Archive.org bot to index the site? For the records: $ curl http://doc.rust-lang.org/robots.txt User-agent: * Disallow: /0.3/ Disallow: /0.4/ Disallow: /0.5/ Disallow: /0.6/ Disallow: /0.7/ Disallow: /0.8/ Disallow: /0.9/ Disallow: /0.10/ -- Gioele Barabucci From danielmicay at gmail.com Thu Jul 10 07:56:33 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 10 Jul 2014 10:56:33 -0400 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <53BE44CA.9030503@svario.it> References: <53BE44CA.9030503@svario.it> Message-ID: <53BEA9A1.2020700@gmail.com> On 10/07/14 03:46 AM, Gioele Barabucci wrote: > Hi, > > the current robots.txt on docs.rust-lang.org prevents Archive.org from > storing copies of the old documentation. I think having the old > documentation archived would be a good thing. BTW, all the documentation > before 0.10 seems gone and this is a shame. > > Could you please allow the Archive.org bot to index the site? > > For the records: > > $ curl http://doc.rust-lang.org/robots.txt > User-agent: * > Disallow: /0.3/ > Disallow: /0.4/ > Disallow: /0.5/ > Disallow: /0.6/ > Disallow: /0.7/ > Disallow: /0.8/ > Disallow: /0.9/ > Disallow: /0.10/ The old documentation is all available from the Git repository. The robots.txt rule is there to reverse the trend of searches being filled with out of date documentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From j.wielicki at sotecware.net Thu Jul 10 08:49:55 2014 From: j.wielicki at sotecware.net (Jonas Wielicki) Date: Thu, 10 Jul 2014 17:49:55 +0200 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <53BEA9A1.2020700@gmail.com> References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> Message-ID: <53BEB623.7090903@sotecware.net> On 10.07.2014 16:56, Daniel Micay wrote: > On 10/07/14 03:46 AM, Gioele Barabucci wrote: >> Hi, >> >> the current robots.txt on docs.rust-lang.org prevents Archive.org from >> storing copies of the old documentation. I think having the old >> documentation archived would be a good thing. BTW, all the documentation >> before 0.10 seems gone and this is a shame. >> >> Could you please allow the Archive.org bot to index the site? >> >> For the records: >> >> $ curl http://doc.rust-lang.org/robots.txt >> User-agent: * >> Disallow: /0.3/ >> Disallow: /0.4/ >> Disallow: /0.5/ >> Disallow: /0.6/ >> Disallow: /0.7/ >> Disallow: /0.8/ >> Disallow: /0.9/ >> Disallow: /0.10/ > > The old documentation is all available from the Git repository. The > robots.txt rule is there to reverse the trend of searches being filled > with out of date documentation. While this is a good thing /all/ software projects should be doing imo, one could still explicitly allow Archive.org by prepending: User-agent: ia_archiver Disallow: ? > > > > _______________________________________________ > 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 ivan at ludios.org Thu Jul 10 10:15:16 2014 From: ivan at ludios.org (Ivan Kozik) Date: Thu, 10 Jul 2014 17:15:16 +0000 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <53BEB623.7090903@sotecware.net> References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> Message-ID: On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki wrote: > While this is a good thing /all/ software projects should be doing imo, > one could still explicitly allow Archive.org by prepending: > > User-agent: ia_archiver > Disallow: > > ? It looks like documentation for the old versions e.g. http://doc.rust-lang.org/0.9/ is a 404 anyway. Ivan From lists at ncameron.org Thu Jul 10 17:48:44 2014 From: lists at ncameron.org (Nick Cameron) Date: Fri, 11 Jul 2014 12:48:44 +1200 Subject: [rust-dev] Next week's older RFCs Message-ID: Hi, here are the recommendations for discussion at next weeks meetings. There is a new section of RFCs which are ready for discussion but discussion has been postponed because we're waiting on a key person for that RFC to be present. This is mostly for RFCs which have been brought up for discussion in a meeting but, we've postponed. There are a few other RFCs not on this list where I've ignored them for now because the right people (mostly Niko) aren't around. So, there a very few RFCs this week that are obvious candidates for closure and I we are pretty much up to date in that respect. There is still quite a backlog of RFCs which we should discuss at meetings and that backlog is only shrinking slowly. I think in general we don't have enough time at the general meeting to discuss more RFCs. Should we start discussing RFCs we might accept at triage? Or are we OK slowly chipping away? Or should we have another meeting or some other solution? As usual, if you have comments on any of these RFCs, please add them to the discussion on the PR; please don't reply to this message. Cheers, Nick Proposed for discussion at Rust meeting --------------------------------------- https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for module imports - tommit Allow e.g., `use module::{self, Type};` for `use module::Type; use module;`. Generally positive response. Some bike shedding around the use of `self` since we call the file mod.rs, and some proposal to allow self.rs instead. Recommend we accept (possibly we should bikeshed the synax `self`). We could postpone this (it would be backwards compatible), but it seems very desirable and would be little effort to implement. https://github.com/rust-lang/rfcs/pull/101 - Allow multiple (fixed-size) subslices borrows in one pattern - krdln Allows matching several parts of a vec in one pattern. Adds `xs..n` syntax to match a fixed size slice (and changes variable sized slice pattern syntax to `xs..` from `..xs`). Not much feedback - all positive or corrected later to be positive. Seems like a small generalisation with no downsides. If we change the syntax as recommended for existing patterns (i.e., `..xs` to `xs..`) then the rest should be backwards compatible, I think. https://github.com/rust-lang/rfcs/pull/113 - Provide a common API across `Option` and the `Ok` and `Err` variants of `Result` - bjz Make Option and Result more consistent. Positive feedback for the idea, some discussion on the specifics. I believe this was discussed before and we were going to flesh it out a bit more. Could bjz and aturon update us on progress? https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing - Kimundi Forbid or deprecate name collision of imported names. Positive feedback. Recommend: lets do this! Might need to tidy up the RFC, but nothing major (hopefully). Need to decide whether to depricate via a feature gate or just get rid. Would be good to assess how much damage this will cause. https://github.com/rust-lang/rfcs/pull/123 - Rename Share to Threadsafe - acrichto Rename share. Bit of a bikeshed here, some support also for `sync`, `concurrent`, etc. Recommend: discuss. https://github.com/rust-lang/rfcs/pull/129 - refine the `asm!` extension - pczarn A string/format! based method of doing inline asm. Not much feedback. Seems like we could do better with our inline asm, not sure if this is the right approach. Recommend: probably close, but worth discussing first. Proposed for discussion at triage --------------------------------- https://github.com/rust-lang/rfcs/pull/150 - fused 'use mod' imports with relative paths - dobkeratops Introduces `use mod` to declare and import a module at the same time. Recommend close - we're pretty happy with this aspect of the module system and if necessary this could be added backwards compatibly. https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce universal quantification - glaebhoerl Use `for` rather than `<...>` syntax for type-parametric items. Not much feedback, some discussion. Recommend close - we're not up for changing the syntax of Rust in such a fundamental way at this stage and want to keep with the curly-brace-language heritage. Proposed for discussion at some point ------------------------------------- https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis A lot of discussion, pretty much all about the details. General sentiment that we want this. Recommend we accept - is this the right RFC to accept, I've not really been keeping track - pnkfelix, pcwalton - is there something which supersedes this? I think this needs a small update to reflect some of the later comments. Waiting for Niko. https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of tagged values - erikt Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against. erikt to update? https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - stevelabnik Loads of opinion in the thread (162 comments!). Note that Niko has an upcoming RFC with the concept of unsafe/trusted traits where the keyword `trusted` makes a lot more sense than `unsafe`, so we could save a keyword here. Waiting for Niko. Actions agreed -------------- https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt aturon to comment alex to close https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix + jclements to keep pushing on getting more explanation https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks huon has updated need more discussion on edge cases - see RFC - pnkfelix (and others) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amercieca at gmail.com Fri Jul 11 01:07:36 2014 From: amercieca at gmail.com (Adrian Mercieca) Date: Fri, 11 Jul 2014 10:07:36 +0200 Subject: [rust-dev] Rust Executable size Message-ID: Hi all, I am just starting out looking at Rust and am following the tutorial. I have compiled the sample 'hello world' program (code below - copied from the tutorial) and compiled it. I was somewhat taken aback at the size of the executable size for such a small program. On my Ubuntu 13.10 machine, the resultant executable was a whopping 1054476 bytes. I stripped the program and the resultant file was still 806816 bytes. Why is the executable so large? Is there anything I might be doing wrong? Perhaps I need to use some compiler switches? Thanks for any pointers in this regard. - Adrian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpx.infinity at gmail.com Fri Jul 11 01:18:28 2014 From: dpx.infinity at gmail.com (Vladimir Matveev) Date: Fri, 11 Jul 2014 12:18:28 +0400 Subject: [rust-dev] Rust Executable size In-Reply-To: References: Message-ID: Hi, Adrian, Currently Rust uses static linking to build executables. This means that the simplest ?hello world? program utilizing standard library will take all of this library and all dependent libraries, including Rust runtime, into itself. That?s why the binary is large. If you want to use dynamic linking, you can invoke rustc with `-C prefer-dynamic` arguments, this will link the program dynamically, and it will be much smaller (8 KB in my case): % cat main.rs fn main() { println!("Hello world") } % rustc -C prefer-dynamic main.rs % ls -lh main -rwxr-xr-x 1 dpx-infinity dpx-infinity 8,0K ??? 11 12:14 main However, this will mean that the binary is no longer portable; you can?t compile it yourself and distribute it to other machines unless these machines also have the same version of Rust installed. Disk size is cheap these days, and portability really do matter, so that?s why the static linkage is default. BTW, Go does exactly the same thing. On 11 ???? 2014 ?., at 12:07, Adrian Mercieca wrote: > Hi all, > > I am just starting out looking at Rust and am following the tutorial. > > I have compiled the sample 'hello world' program (code below - copied from the tutorial) and compiled it. > > I was somewhat taken aback at the size of the executable size for such a small program. > > On my Ubuntu 13.10 machine, the resultant executable was a whopping 1054476 bytes. > I stripped the program and the resultant file was still 806816 bytes. > > Why is the executable so large? Is there anything I might be doing wrong? > Perhaps I need to use some compiler switches? > > Thanks for any pointers in this regard. > > - Adrian. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From amercieca at gmail.com Fri Jul 11 01:21:13 2014 From: amercieca at gmail.com (Adrian Mercieca) Date: Fri, 11 Jul 2014 10:21:13 +0200 Subject: [rust-dev] Rust Executable size In-Reply-To: References: Message-ID: Hi Vladimir, Awesome - got the same executable size. Thanks a million for such quick and accurate response. Back to my Rust tutorial... :) Regards. - Adrian. On Fri, Jul 11, 2014 at 10:18 AM, Vladimir Matveev wrote: > Hi, Adrian, > > Currently Rust uses static linking to build executables. This means that > the simplest ?hello world? program utilizing standard library will take all > of this library and all dependent libraries, including Rust runtime, into > itself. That?s why the binary is large. > > If you want to use dynamic linking, you can invoke rustc with `-C > prefer-dynamic` arguments, this will link the program dynamically, and it > will be much smaller (8 KB in my case): > > % cat main.rs > fn main() { > println!("Hello world") > } > % rustc -C prefer-dynamic main.rs > % ls -lh main > -rwxr-xr-x 1 dpx-infinity dpx-infinity 8,0K ??? 11 12:14 main > > However, this will mean that the binary is no longer portable; you can?t > compile it yourself and distribute it to other machines unless these > machines also have the same version of Rust installed. > > Disk size is cheap these days, and portability really do matter, so that?s > why the static linkage is default. BTW, Go does exactly the same thing. > > On 11 ???? 2014 ?., at 12:07, Adrian Mercieca wrote: > > > Hi all, > > > > I am just starting out looking at Rust and am following the tutorial. > > > > I have compiled the sample 'hello world' program (code below - copied > from the tutorial) and compiled it. > > > > I was somewhat taken aback at the size of the executable size for such a > small program. > > > > On my Ubuntu 13.10 machine, the resultant executable was a whopping > 1054476 bytes. > > I stripped the program and the resultant file was still 806816 bytes. > > > > Why is the executable so large? Is there anything I might be doing wrong? > > Perhaps I need to use some compiler switches? > > > > Thanks for any pointers in this regard. > > > > - Adrian. > > > > _______________________________________________ > > 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 chandru.in at gmail.com Fri Jul 11 10:39:27 2014 From: chandru.in at gmail.com (Chandru) Date: Fri, 11 Jul 2014 23:09:27 +0530 Subject: [rust-dev] Seemingly Poor Scalability of M:N Scheduler Message-ID: I tried the rust-http's comparison with go from here. https://github.com/chris-morgan/rust-http/tree/master/comparisons Using the default code, which I guess uses 1:1 scheduling, rust falls behind go when concurrency goes greater than the number of cores (4). I guess this is to be expected as context switches increase without additional parallelism. go 1 wrk 7856.76 rust 1 wrk 19617.39 go 2 wrk 20364.92 rust 2 wrk 30591.88 go 3 wrk 30408.15 rust 3 wrk 45847.69 go 4 wrk 41953.29 rust 4 wrk 53632.75 go 8 wrk 56632.79 rust 8 wrk 54660.72 go 16 wrk 58263.69 rust 16 wrk 54906.18 go 32 wrk 57773.54 rust 32 wrk 56682.38 However, on switching to M:N with this change, #![feature(phase)] #[phase(plugin)] extern crate green; green_start!(main) rust seems to be stuck around 25K req/s while go's throughput goes much higher. go 1 wrk 7850.23 rust 1 wrk 24361.64 go 2 wrk 20478.89 rust 2 wrk 23349.38 go 3 wrk 30592.79 rust 3 wrk 24232.2 go 4 wrk 42165.1 rust 4 wrk 25950.4 go 8 wrk 56540.86 rust 8 wrk 27284.01 go 16 wrk 57957.76 rust 16 wrk 26275.33 go 32 wrk 57611.55 rust 32 wrk 25674.82 Am I reading this wrong or does it indicate some bottleneck in the M:N scheduler? -- Chandra Sekar.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Fri Jul 11 10:41:52 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 11 Jul 2014 13:41:52 -0400 Subject: [rust-dev] Seemingly Poor Scalability of M:N Scheduler In-Reply-To: References: Message-ID: This is a known performance bug in the green schedulers being tracked at https://github.com/rust-lang/rust/issues/11730. To see the difference, you can run with RUST_THREADS=1 when using the green scheduler. On Fri, Jul 11, 2014 at 1:39 PM, Chandru wrote: > I tried the rust-http's comparison with go from here. > https://github.com/chris-morgan/rust-http/tree/master/comparisons > > Using the default code, which I guess uses 1:1 scheduling, rust falls behind > go when concurrency goes greater than the number of cores (4). I guess this > is to be expected as context switches increase without additional > parallelism. > > go 1 wrk 7856.76 > rust 1 wrk 19617.39 > go 2 wrk 20364.92 > rust 2 wrk 30591.88 > go 3 wrk 30408.15 > rust 3 wrk 45847.69 > go 4 wrk 41953.29 > rust 4 wrk 53632.75 > go 8 wrk 56632.79 > rust 8 wrk 54660.72 > go 16 wrk 58263.69 > rust 16 wrk 54906.18 > go 32 wrk 57773.54 > rust 32 wrk 56682.38 > > However, on switching to M:N with this change, > > #![feature(phase)] > #[phase(plugin)] > extern crate green; > > green_start!(main) > > rust seems to be stuck around 25K req/s while go's throughput goes much > higher. > > go 1 wrk 7850.23 > rust 1 wrk 24361.64 > go 2 wrk 20478.89 > rust 2 wrk 23349.38 > go 3 wrk 30592.79 > rust 3 wrk 24232.2 > go 4 wrk 42165.1 > rust 4 wrk 25950.4 > go 8 wrk 56540.86 > rust 8 wrk 27284.01 > go 16 wrk 57957.76 > rust 16 wrk 26275.33 > go 32 wrk 57611.55 > rust 32 wrk 25674.82 > > Am I reading this wrong or does it indicate some bottleneck in the M:N > scheduler? > > -- > Chandra Sekar.S > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From aturon at mozilla.com Fri Jul 11 11:49:15 2014 From: aturon at mozilla.com (Aaron Turon) Date: Fri, 11 Jul 2014 11:49:15 -0700 Subject: [rust-dev] Rust Guidelines Message-ID: <53C031AB.6030407@mozilla.com> Rustafarians, As we head toward 1.0, we need to do do more than stabilize the language: we need a broad and stable base of libraries as well. One of the key steps in that direction is reaching firm decisions on a number of API design questions, ranging from bikesheddy stuff like naming conventions to meatier stuff like when and how to use traits for overloading. # THE RUST GUIDELINES DOCUMENT I've been accumulating a set of guidelines based mostly on current Rust practice: http://aturon.github.io/ but I need a lot of help from the community to bring this project to fruition. As of today, the repository for the guidelines is now owned by the rust-lang github organization: https://github.com/rust-lang/rust-guidelines Each guideline is tagged with a status: * [FIXME]: Marks places where there is clear work to be done that does not require further discussion or consensus. * [OPEN]: Marks open questions that require concrete proposals for further discussion. * [RFC]: Marks concrete, proposed guidelines that need further discussion to reach consensus. * Untagged guidelines are considered accepted. To begin with, there are almost none of these! # VIEWING THE GUIDELINES For now, http://aturon.github.io/ will host snapshots of the current guidelines. I plan to move the guidelines away from gitbook and onto something homegrown (built on rustdoc) soon, at which point we'll do rendering in some more official way as part of the nightlies. The guidelines are also easy to browse from within github. # HOW YOU CAN HELP These guidelines cover a fair amount of ground, but still need a lot of work: * We need to decide whether the [RFC]-status guidelines are ready to be accepted. * We need to write many, many more guidelines. I've stubbed out a lot of these at [OPEN] status, but there are plenty of unknown-unknowns. This project runs the risk of painting the biggest bikeshed ever. To help keep things managable: **DO NOT USE THE MAILING LIST** for discussing guidelines! Instead: - Primarily, use http://discuss.rust-lang.org/ with category "guidelines" - Use the github.com/rust-lang/rust-guidelines issue tracker - Submit PRs! Because guidelines are tagged with statuses, we can accept PRs at [RFC] status without formally "approving" them. # CONSENSUS AND DECISIONS The process for accepting guidelines will evolve over time, as with all of our processes. I'm hoping it will be a lighter-weight version of the RFC process: 1. Discussion on http://discuss.rust-lang.org/ and the repo for a given guideline goes on for a while. 2. At some point, either consensus is reached, or we simply need to make a decision. 3. The decision is made by the Rust team during a "library" meeting. For now, these are separate from the general Rust meetings. Once a guideline is approved, its [RFC] tag will be removed. We still reserve the right to change the guideline later, but expect this to be rare. The best part: approved guidelines can turn into (1) new github issues to bring libstd into line and (2) an authoritative way to resolve debates on libstd PRs. Here's to having these debates one last time, and then ending them! Aaron From banderson at mozilla.com Fri Jul 11 11:58:10 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 11 Jul 2014 11:58:10 -0700 Subject: [rust-dev] Rust Guidelines In-Reply-To: <53C031AB.6030407@mozilla.com> References: <53C031AB.6030407@mozilla.com> Message-ID: <53C033C2.7050007@mozilla.com> Thanks, Aaron. This is going to be an important reference for authors. I love the sensible organization and that it's already seeded with many of our existing conventions. On 07/11/2014 11:49 AM, Aaron Turon wrote: > Rustafarians, > > As we head toward 1.0, we need to do do more than stabilize the > language: we need a broad and stable base of libraries as well. > > One of the key steps in that direction is reaching firm decisions on a > number of API design questions, ranging from bikesheddy stuff like > naming conventions to meatier stuff like when and how to use traits > for overloading. > > > # THE RUST GUIDELINES DOCUMENT > > I've been accumulating a set of guidelines based mostly on current > Rust practice: > > http://aturon.github.io/ > > but I need a lot of help from the community to bring this project to > fruition. > > As of today, the repository for the guidelines is now owned by the > rust-lang github organization: > > https://github.com/rust-lang/rust-guidelines > > Each guideline is tagged with a status: > > * [FIXME]: Marks places where there is clear work to be done that does > not require further discussion or consensus. > > * [OPEN]: Marks open questions that require concrete proposals for > further discussion. > > * [RFC]: Marks concrete, proposed guidelines that need further > discussion to reach consensus. > > * Untagged guidelines are considered accepted. To begin with, there > are almost none of these! > > > # VIEWING THE GUIDELINES > > For now, http://aturon.github.io/ will host snapshots of the current > guidelines. > > I plan to move the guidelines away from gitbook and onto something > homegrown (built on rustdoc) soon, at which point we'll do rendering > in some more official way as part of the nightlies. > > The guidelines are also easy to browse from within github. > > > # HOW YOU CAN HELP > > These guidelines cover a fair amount of ground, but still need a lot > of work: > > * We need to decide whether the [RFC]-status guidelines are ready to > be accepted. > > * We need to write many, many more guidelines. I've stubbed out a lot > of these at [OPEN] status, but there are plenty of unknown-unknowns. > > This project runs the risk of painting the biggest bikeshed ever. To > help keep things managable: > > **DO NOT USE THE MAILING LIST** for discussing guidelines! > > Instead: > > - Primarily, use http://discuss.rust-lang.org/ with category > "guidelines" > - Use the github.com/rust-lang/rust-guidelines issue tracker > - Submit PRs! > > Because guidelines are tagged with statuses, we can accept PRs at > [RFC] status without formally "approving" them. > > > # CONSENSUS AND DECISIONS > > The process for accepting guidelines will evolve over time, as with > all of our processes. I'm hoping it will be a lighter-weight version > of the RFC process: > > 1. Discussion on http://discuss.rust-lang.org/ and the repo for a > given guideline goes on for a while. > > 2. At some point, either consensus is reached, or we simply need to > make a decision. > > 3. The decision is made by the Rust team during a "library" meeting. > For now, these are separate from the general Rust meetings. > > Once a guideline is approved, its [RFC] tag will be removed. We still > reserve the right to change the guideline later, but expect this to be > rare. > > The best part: approved guidelines can turn into (1) new github issues > to bring libstd into line and (2) an authoritative way to resolve > debates on libstd PRs. > > Here's to having these debates one last time, and then ending them! > Aaron > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From zo1980 at gmail.com Fri Jul 11 12:09:22 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Fri, 11 Jul 2014 21:09:22 +0200 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BC7757.5000200@mozilla.com> References: <53BC7757.5000200@mozilla.com> Message-ID: On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson wrote: > > # Impact > > Installing rustc to non-default locations will result in an installation > that puts some important libraries in a location the dynamic linker won't > find, will need to be compensated for with LD_LIBRARY_PATH. > > This is too sad. Some Rust users may not be administrators, but even if they are, installing to some light custom folder is too convenient to miss it. LD_LIBRARY_PATH is not known about by many, and even if known, editing it is messy practice. What about these alternatives? 1) Link dependencies of rustc statically to it? 2) On Windows the folder of the executable is always searched for dependencies. Is this the case on Linux too? Then you could just let 'make install' copy everything next to rustc. I may have misunderstood something basic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Fri Jul 11 12:15:31 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 11 Jul 2014 15:15:31 -0400 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> Message-ID: > LD_LIBRARY_PATH is not known about by many The install.sh script now recommends adding an entry to this variable if it detects that this is necessary, so it's not *entirely* unknown. This doesn't help, however, if it's considered a bad practice. > 1) Link dependencies of rustc statically to it? For plugins to work, we're required to link libstd and friends dynamically to rustc, so sadly we're require to link rustc itself dynamically. > 2) On Windows the folder of the executable is always searched for > dependencies. Is this the case on Linux too? Then you could just let 'make > install' copy everything next to rustc. I do not believe that this is this case for linux or OSX, only for windows. From danielmicay at gmail.com Fri Jul 11 12:22:56 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 11 Jul 2014 15:22:56 -0400 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> Message-ID: <53C03990.7070509@gmail.com> On 11/07/14 03:15 PM, Alex Crichton wrote: >> LD_LIBRARY_PATH is not known about by many > > The install.sh script now recommends adding an entry to this variable > if it detects that this is necessary, so it's not *entirely* unknown. > This doesn't help, however, if it's considered a bad practice. > >> 1) Link dependencies of rustc statically to it? > > For plugins to work, we're required to link libstd and friends > dynamically to rustc, so sadly we're require to link rustc itself > dynamically. > >> 2) On Windows the folder of the executable is always searched for >> dependencies. Is this the case on Linux too? Then you could just let 'make >> install' copy everything next to rustc. > > I do not believe that this is this case for linux or OSX, only for windows. It's not acceptable to dump a bunch of libraries in /usr/bin or /usr/local/bin 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 eg1290 at gmail.com Fri Jul 11 12:27:12 2014 From: eg1290 at gmail.com (Evan G) Date: Fri, 11 Jul 2014 14:27:12 -0500 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53C03990.7070509@gmail.com> References: <53BC7757.5000200@mozilla.com> <53C03990.7070509@gmail.com> Message-ID: I believe the thought was for when we *can't* modify things like /usr/bin, because the user isn't an administrator. Obviously if we were installing things where they were supposed to go, we wouldn't have a problem finding libraries, would we now? So no-one's proposing we dump a bunch of libraries into /usr/bin. On Fri, Jul 11, 2014 at 2:22 PM, Daniel Micay wrote: > On 11/07/14 03:15 PM, Alex Crichton wrote: > >> LD_LIBRARY_PATH is not known about by many > > > > The install.sh script now recommends adding an entry to this variable > > if it detects that this is necessary, so it's not *entirely* unknown. > > This doesn't help, however, if it's considered a bad practice. > > > >> 1) Link dependencies of rustc statically to it? > > > > For plugins to work, we're required to link libstd and friends > > dynamically to rustc, so sadly we're require to link rustc itself > > dynamically. > > > >> 2) On Windows the folder of the executable is always searched for > >> dependencies. Is this the case on Linux too? Then you could just let > 'make > >> install' copy everything next to rustc. > > > > I do not believe that this is this case for linux or OSX, only for > windows. > > It's not acceptable to dump a bunch of libraries in /usr/bin or > /usr/local/bin anyway. > > > _______________________________________________ > 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 changchun.fan at qq.com Fri Jul 11 21:21:20 2014 From: changchun.fan at qq.com (=?gb18030?B?t7azpLS6?=) Date: Sat, 12 Jul 2014 12:21:20 +0800 Subject: [rust-dev] initialization syntax Message-ID: Hi Rust designers, I'm curious why rust uses colon ":" instead of assignment "=" when initialize an object. What is the rationale behind this? From what I see, `Point { x = 2, y = 3 }` looks much better than `Point { x : 2, y : 3}`. Since most of the syntax rules are consistent in rust, why we use `:` to represent different two meanings? I'm new to Rust now. Just can't get the concept behind the design. Thank you in advance Changchun -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Fri Jul 11 21:33:07 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 11 Jul 2014 21:33:07 -0700 Subject: [rust-dev] initialization syntax In-Reply-To: References: Message-ID: Because of JavaScript, basically. Patrick On July 11, 2014 9:21:20 PM PDT, "???" wrote: >Hi Rust designers, > > >I'm curious why rust uses colon ":" instead of assignment "=" when >initialize an object. What is the rationale behind this? > > >From what I see, `Point { x = 2, y = 3 }` looks much better than `Point >{ x : 2, y : 3}`. > > >Since most of the syntax rules are consistent in rust, why we use `:` >to represent different two meanings? > > >I'm new to Rust now. Just can't get the concept behind the design. > > >Thank you in advance >Changchun > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Fri Jul 11 21:34:03 2014 From: lists at ncameron.org (Nick Cameron) Date: Sat, 12 Jul 2014 16:34:03 +1200 Subject: [rust-dev] initialization syntax In-Reply-To: References: Message-ID: The short answer is so that struct initialisation, struct types, and struct de-structuring all have the same syntax. For more detail, see the discussion in this (rejected and closed) RFC for changing from using `:` to `=`. Cheers, Nick On Sat, Jul 12, 2014 at 4:21 PM, ??? wrote: > Hi Rust designers, > > I'm curious why rust uses colon ":" instead of assignment "=" when > initialize an object. What is the rationale behind this? > > From what I see, `Point { x = 2, y = 3 }` looks much better than `Point { > x : 2, y : 3}`. > > Since most of the syntax rules are consistent in rust, why we use `:` to > represent different two meanings? > > I'm new to Rust now. Just can't get the concept behind the design. > > Thank you in advance > Changchun > > _______________________________________________ > 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 jhm456 at gmail.com Fri Jul 11 22:11:55 2014 From: jhm456 at gmail.com (Jerry Morrison) Date: Fri, 11 Jul 2014 22:11:55 -0700 Subject: [rust-dev] RFC about int, uint, and 16-bit CPUs Message-ID: Both Issue #14758 (Specify that int and uint are at least 32 bits on every CPU architecture) and Issue #9940 (rename `int` and `uint` to `intptr`/`uintptr`) call for RFCs. So RFC https://github.com/rust-lang/rfcs/pull/161 summarizes those discussions, explains the core issue of code portability to CPUs with smaller address spaces, conceptions and misconceptions about int/uint, what's a "default" integer type, and proposals including coding style for integer sizing. Let me know what you think. -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From uther.ii at gmail.com Sat Jul 12 03:43:58 2014 From: uther.ii at gmail.com (Uther) Date: Sat, 12 Jul 2014 12:43:58 +0200 Subject: [rust-dev] RFC about int, uint, and 16-bit CPUs In-Reply-To: References: Message-ID: <53C1116E.9040507@gmail.com> I think this is great. Pointer sized integer normal use is array indexing and should be labeled as such. "int" make think wrongly, this is the natural type for integer computation. Le 12/07/2014 07:11, Jerry Morrison a ?crit : > > Both Issue #14758 > (Specify that int and > uint are at least 32 bits on every CPU architecture) and Issue #9940 > (rename `int` and > `uint` to `intptr`/`uintptr`) call for RFCs. > > So RFC https://github.com/rust-lang/rfcs/pull/161 summarizes those > discussions, explains the core issue of code portability to CPUs with > smaller address spaces, conceptions and misconceptions about int/uint, > what's a "default" integer type, and proposals including coding style > for integer sizing. > > Let me know what you think. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thesaint1987 at googlemail.com Sat Jul 12 06:27:19 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Sat, 12 Jul 2014 15:27:19 +0200 Subject: [rust-dev] Using rustc as crate? Message-ID: Hi, I am trying to "externalize" the builtin Lint code, because I want to work on some tooling support and they seem to do a lot of the stuff I would be interested in too.. But I don't want to recompile rustc for every change to my code. I noticed most of the mods are public but still rust doesn't seem to let me import them into my own crate. I just wrote something like the following for testing: #################################################### #![crate_name = "rusttooling"] #![experimental] #![comment = "The Rust Tooling Library"] #![license = "MIT/ASL2"] #![crate_type = "dylib"] #![crate_type = "rlib"] #![doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://doc.rust-lang.org/0.11.0/")] #![allow(deprecated)] #![feature(macro_rules, globs, struct_variant, managed_boxes, quote)] #![feature(default_type_params, phase, unsafe_destructor)] #![allow(unknown_features)] // NOTE: Remove after next snapshot #![feature(rustc_diagnostic_macros)] extern crate arena; extern crate rustc; extern crate debug; extern crate flate; extern crate getopts; extern crate graphviz; extern crate libc; extern crate serialize; extern crate time; #[phase(plugin, link)] extern crate log; #[phase(plugin, link)] extern crate syntax; //pub mod lint; use middle::typeck::infer; use metadata::csearch; #################################################### The last two lines fail for me... "error: unresolved import `middle::typeck::infer`. Maybe a missing `extern crate middle`?" What could be the problem? Was it intended for Lint like stuff to even be used outside the compiler? How would the "officially" supported way look like? PS: I am on windows and the cargo thing doesn't seem to work there yet. Thanks a lot! From singingboyo at gmail.com Sat Jul 12 06:37:37 2014 From: singingboyo at gmail.com (Brandon Sanderson) Date: Sat, 12 Jul 2014 06:37:37 -0700 Subject: [rust-dev] Using rustc as crate? In-Reply-To: References: Message-ID: I haven't done anything like this myself, so I can't say if the lints are intended to be used outside the compiler. However, I think your problem is just a missing rustc:: at the start of your imports. You probably want 'use rustc::middle::typeck::infer', for example. Also, it is possible to get cargo working on windows, or at least it was. I do have a working (old-ish) version that I use regularly. I haven't tried updating it recently, however. On Sat, Jul 12, 2014 at 6:27 AM, Christoph Husse < thesaint1987 at googlemail.com> wrote: > Hi, > > I am trying to "externalize" the builtin Lint code, because I want to > work on some tooling support and they seem to do a lot of the stuff I > would be interested in too.. > > But I don't want to recompile rustc for every change to my code. I > noticed most of the mods are public but still rust doesn't seem to let > me import them into my own crate. > > I just wrote something like the following for testing: > > #################################################### > > #![crate_name = "rusttooling"] > #![experimental] > #![comment = "The Rust Tooling Library"] > #![license = "MIT/ASL2"] > #![crate_type = "dylib"] > #![crate_type = "rlib"] > #![doc(html_logo_url = > "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", > html_favicon_url = "http://www.rust-lang.org/favicon.ico", > html_root_url = "http://doc.rust-lang.org/0.11.0/")] > > #![allow(deprecated)] > #![feature(macro_rules, globs, struct_variant, managed_boxes, quote)] > #![feature(default_type_params, phase, unsafe_destructor)] > > #![allow(unknown_features)] // NOTE: Remove after next snapshot > #![feature(rustc_diagnostic_macros)] > > extern crate arena; > extern crate rustc; > extern crate debug; > extern crate flate; > extern crate getopts; > extern crate graphviz; > extern crate libc; > extern crate serialize; > extern crate time; > #[phase(plugin, link)] extern crate log; > #[phase(plugin, link)] extern crate syntax; > > > //pub mod lint; > use middle::typeck::infer; > use metadata::csearch; > > > #################################################### > > The last two lines fail for me... "error: unresolved import > `middle::typeck::infer`. Maybe a missing `extern crate middle`?" > > What could be the problem? > Was it intended for Lint like stuff to even be used outside the compiler? > How would the "officially" supported way look like? > > PS: I am on windows and the cargo thing doesn't seem to work there yet. > > Thanks a lot! > _______________________________________________ > 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 thesaint1987 at googlemail.com Sat Jul 12 07:07:43 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Sat, 12 Jul 2014 16:07:43 +0200 Subject: [rust-dev] Using rustc as crate? In-Reply-To: References: Message-ID: Thanks! Hmm "use rustc::" kind of works. But its not that simple, since now all other references are misaligned xD. So I have to restructure a bit. Hopefully it works this way in the end :) On Sat, Jul 12, 2014 at 3:37 PM, Brandon Sanderson wrote: > I haven't done anything like this myself, so I can't say if the lints are > intended to be used outside the compiler. However, I think your problem is > just a missing rustc:: at the start of your imports. You probably want 'use > rustc::middle::typeck::infer', for example. > > Also, it is possible to get cargo working on windows, or at least it was. I > do have a working (old-ish) version that I use regularly. I haven't tried > updating it recently, however. > > > On Sat, Jul 12, 2014 at 6:27 AM, Christoph Husse > wrote: >> >> Hi, >> >> I am trying to "externalize" the builtin Lint code, because I want to >> work on some tooling support and they seem to do a lot of the stuff I >> would be interested in too.. >> >> But I don't want to recompile rustc for every change to my code. I >> noticed most of the mods are public but still rust doesn't seem to let >> me import them into my own crate. >> >> I just wrote something like the following for testing: >> >> #################################################### >> >> #![crate_name = "rusttooling"] >> #![experimental] >> #![comment = "The Rust Tooling Library"] >> #![license = "MIT/ASL2"] >> #![crate_type = "dylib"] >> #![crate_type = "rlib"] >> #![doc(html_logo_url = >> "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", >> html_favicon_url = "http://www.rust-lang.org/favicon.ico", >> html_root_url = "http://doc.rust-lang.org/0.11.0/")] >> >> #![allow(deprecated)] >> #![feature(macro_rules, globs, struct_variant, managed_boxes, quote)] >> #![feature(default_type_params, phase, unsafe_destructor)] >> >> #![allow(unknown_features)] // NOTE: Remove after next snapshot >> #![feature(rustc_diagnostic_macros)] >> >> extern crate arena; >> extern crate rustc; >> extern crate debug; >> extern crate flate; >> extern crate getopts; >> extern crate graphviz; >> extern crate libc; >> extern crate serialize; >> extern crate time; >> #[phase(plugin, link)] extern crate log; >> #[phase(plugin, link)] extern crate syntax; >> >> >> //pub mod lint; >> use middle::typeck::infer; >> use metadata::csearch; >> >> >> #################################################### >> >> The last two lines fail for me... "error: unresolved import >> `middle::typeck::infer`. Maybe a missing `extern crate middle`?" >> >> What could be the problem? >> Was it intended for Lint like stuff to even be used outside the compiler? >> How would the "officially" supported way look like? >> >> PS: I am on windows and the cargo thing doesn't seem to work there yet. >> >> Thanks a lot! >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From changchun.fan at qq.com Sat Jul 12 10:13:44 2014 From: changchun.fan at qq.com (=?gb18030?B?t7azpLS6?=) Date: Sun, 13 Jul 2014 01:13:44 +0800 Subject: [rust-dev] =?gb18030?q?=BB=D8=B8=B4=3A__initialization_syntax?= References: Message-ID: Thank you for your explanation. But I didn't find the RFC you mentioned. I have a question that what if we need both struct initialization and struct type declaration in one expression in future? For example, C#'s `anonymous struct` feature is useful in Linq expression. Do we make sure that `anonymous struct` will never be added to Rust language? Thanks, Changchun ------------------ ???? ------------------ ???: "Nick Cameron" ????: 2014?7?12?(???) ??12:34 ???: "???"; ??: "rust-dev"; ??: Re: [rust-dev] initialization syntax The short answer is so that struct initialisation, struct types, and struct de-structuring all have the same syntax. For more detail, see the discussion in this (rejected and closed) RFC for changing from using `:` to `=`. Cheers, Nick On Sat, Jul 12, 2014 at 4:21 PM, ??? wrote: Hi Rust designers, I'm curious why rust uses colon ":" instead of assignment "=" when initialize an object. What is the rationale behind this? From what I see, `Point { x = 2, y = 3 }` looks much better than `Point { x : 2, y : 3}`. Since most of the syntax rules are consistent in rust, why we use `:` to represent different two meanings? I'm new to Rust now. Just can't get the concept behind the design. Thank you in advance Changchun _______________________________________________ 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 lists at ncameron.org Sat Jul 12 15:32:47 2014 From: lists at ncameron.org (Nick Cameron) Date: Sun, 13 Jul 2014 10:32:47 +1200 Subject: [rust-dev] initialization syntax In-Reply-To: References: Message-ID: Whoops! I meant to paste in the URL, but forgot - https://github.com/rust-lang/rfcs/pull/65 Sorry about that. We used to have anonymous structs and they were removed (before my time, so I can't tell you the reasons, sorry), so it is very unlikely we'll get them back. If we did want to, then they could be added backwards compatibly, so they could be considered post-1.0. Cheers, Nick On Sun, Jul 13, 2014 at 5:13 AM, ??? wrote: > Thank you for your explanation. But I didn't find the RFC you mentioned. > > > I have a question that what if we need both struct initialization and struct type declaration in one expression in future? > > > For example, C#'s `anonymous struct` feature is useful in Linq expression. Do we make sure that `anonymous struct` will never be added to Rust language? > > Thanks, > Changchun > ------------------ ???? ------------------ > *???:* "Nick Cameron" > *????:* 2014?7?12?(???) ??12:34 > *???:* "???"; > *??:* "rust-dev"; > *??:* Re: [rust-dev] initialization syntax > The short answer is so that struct initialisation, struct types, and > struct de-structuring all have the same syntax. > > For more detail, see the discussion in this (rejected and closed) RFC for > changing from using `:` to `=`. > > Cheers, Nick > > > On Sat, Jul 12, 2014 at 4:21 PM, ??? wrote: > >> Hi Rust designers, >> >> I'm curious why rust uses colon ":" instead of assignment "=" when >> initialize an object. What is the rationale behind this? >> >> From what I see, `Point { x = 2, y = 3 }` looks much better than `Point { >> x : 2, y : 3}`. >> >> Since most of the syntax rules are consistent in rust, why we use `:` to >> represent different two meanings? >> >> I'm new to Rust now. Just can't get the concept behind the design. >> >> Thank you in advance >> Changchun >> >> _______________________________________________ >> 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 stepan.koltsov at gmail.com Sat Jul 12 16:43:10 2014 From: stepan.koltsov at gmail.com (Stepan Koltsov) Date: Sun, 13 Jul 2014 03:43:10 +0400 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: <53BD726A.7010004@mozilla.com> References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> <53BD726A.7010004@mozilla.com> Message-ID: On Wed, Jul 9, 2014 at 8:48 PM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Also, when installing Rust you don't have to mangle these environment > variables, since the libraries will be placed into the right place. This > should only impact anyone who builds from source without installing. > It also impacts people who: ? want to have several versions of rust side by side to investigate problems ? need different fixed per-project environments ? don't have permission to write into /usr/local (typically on shared servers) ? don't want to have a mess in /usr/local As detailed in the meeting where this decision was made, Linux distros > really dislike it when you mess with rpath; it's a deal-breaker in many > cases. > I don't know about all Linux distros, but apparently Ubuntu is OK about rpath: $ objdump -x /usr/lib/jvm/java-7-openjdk-amd64/bin/java | grep RPATH RPATH $ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64:$ORIGIN/../jre/lib/amd64 Anyway, rust can be built without rpath for linux distros, and with rpath for downloading from site. -- Stepan -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Sat Jul 12 17:08:03 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Sun, 13 Jul 2014 01:08:03 +0100 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> <53BC819F.8080901@exyr.org> <53BC8488.3040009@mozilla.com> <53BD726A.7010004@mozilla.com> Message-ID: On 13 July 2014 00:43, Stepan Koltsov wrote: > -- want to have several versions of rust side by side to investigate problems Not true, the share object files include git revision in the name and that's what they are being looked up by, as far as I understood. So one can have: DYLD_LIBRARY_PATH = /opt/Rust/0/lib/:/opt/Rust/1/lib/:/opt/Rust/2/lib/ My layout is like this: cd /opt; ls Rust/versions/*/*/lib/libnative-* Rust/versions/0f2ae7b932a9045f0d03ca35ff8cfc3fd939414e/rust-nightly-x86_64-apple-darwin/lib/libnative-1fb5e2c0-0.11.0-pre.dylib Rust/versions/21fd11fef66e9973bd424915b9ee958c0990af2b/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib Rust/versions/65395dc2bb240534c288bd60a5983538410af47d/rust-nightly-x86_64-apple-darwin/lib/libnative-35e04b6f-0.11.0.dylib Rust/versions/8d6cd8c1b95b2bb6d14008258e5e571552159f38/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib Rust/versions/a7b8824b2f8388705e4683b938fea442a663ebcb/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib > -- need different fixed per-project environments They will only need to care about executable path, which is something they would need to care about even if this change hadn't been made. > -- don't have permission to write into /usr/local (typically on shared > servers) Is is not a valid reason, they can unpack the tarball into any prefix. > -- don't want to have a mess in /usr/local Sure, so I personally put it under /opt/Rust/ >> As detailed in the meeting where this decision was made, Linux distros >> really dislike it when you mess with rpath; it's a deal-breaker in many >> cases. > > I don't know about all Linux distros, but apparently Ubuntu is OK about > rpath: > > $ objdump -x /usr/lib/jvm/java-7-openjdk-amd64/bin/java | grep RPATH > RPATH > $ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64:$ORIGIN/../jre/lib/amd64 Ubuntu is not the best example of how an OS should be built. It's probably a longstanding OpenJDK issue too, did you check? From stfairy at gmail.com Sat Jul 12 18:37:01 2014 From: stfairy at gmail.com (Xiao Jia) Date: Sun, 13 Jul 2014 09:37:01 +0800 Subject: [rust-dev] Migrate legacy code to Rust Message-ID: Hi, I'm considering migrating a legacy system written in C++ to Rust. It runs on Windows, has dependencies such as boost and Windows GDI+ (yes it has a Win32 window on the screen), and receives real-time messages via an internal low-latency library. Based on these conditions, I consider a direct full-stack migration is infeasible. So I am considering two alternatives: 1. Write core business logic (including spawning and managing multiple worker threads) in Rust and compile as a static library which can be linked together with other C++ code (that I cannot change). 2. Wrap the unchangeable C++ code as a C library, and use the library from Rust. The wrapping is needed because I read from Rust docs that it's not possible to call C++ directly at present. I am completely a newbie in Rust and hope you could give your advice on which way to choose, or on better alternatives :-) P.S. For alternative 1, I wonder if MinGW run-time libraries are needed when the linked program is deployed. I would prefer completely native executable without external run-time dependencies. Thanks Xiao Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From thesaint1987 at googlemail.com Sun Jul 13 00:10:34 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Sun, 13 Jul 2014 09:10:34 +0200 Subject: [rust-dev] Invoking rustc as crate? Message-ID: Hi, I successfully managed to hook into the compiler so far. Or well it's not that successful, because it doesn't work, but at least the code is there ;). Now I am trying to compile an empty file, and it gives me the weird error: "error: can't find crate for `std`" Any chance there could be more insight? Normally a C++ compiler is able to also tell you the library search paths at least, and in this case it would be helpful to print the assumed hash code suffix that was expected (I assume the fact that it runs in my executable instead of the real compiler makes it somehow look for and STD with a different hash suffix). To zero out the chance that I did something wrong with externalizing parts of the compiler driver into my own application, I wrote a simple main method with the following "fallback": rustc::driver::main_args(args.as_slice()) It will simply do what rustc does... Invoke the rustc compiler with the arguments provided. This call will land inside of the compiler that was used to compile the very same statement (I hope). Its using the "rustc" crate after all. Still the same error message ;) So how could that be resolved? This is also an issue for custom Lint plugins I guess, because you will definitely not want to invoke rustc as external command and then have your plugin run in a different process. I basically need the AST after analysis in its pure form, like no JSON or something. Just want to continue where the compiler left off... Instead of generating LLVM & stuff, which is not needed in my case. best chris From thesaint1987 at googlemail.com Sun Jul 13 00:42:30 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Sun, 13 Jul 2014 09:42:30 +0200 Subject: [rust-dev] Invoking rustc as crate? In-Reply-To: References: Message-ID: Hmm interesting, copying the generated tests executable (that is the exe containing my unittests, which in turn invoke the rustc compiler through the rustc crate) into the rust-compiler's root directory solved this problem, even though this "workflow" isn't exactly pleasing... So I tried various things now. Including: 1) Copying the entrie rustc root directory over the generated executable [Same error] 2) Copying the entrie rustc root directory into the working directory of my unit tests [Same error] 3) copying my unittest executable into the rustc root directory [Success] Any ideas how I could make one of the first two options work too? On Sun, Jul 13, 2014 at 9:10 AM, Christoph Husse wrote: > Hi, > > I successfully managed to hook into the compiler so far. Or well it's > not that successful, because it doesn't work, but at least the code is > there ;). > > Now I am trying to compile an empty file, and it gives me the weird error: > > "error: can't find crate for `std`" > > Any chance there could be more insight? Normally a C++ compiler is > able to also tell you the library search paths at least, and in this > case it would be helpful to print the assumed hash code suffix that > was expected (I assume the fact that it runs in my executable instead > of the real compiler makes it somehow look for and STD with a > different hash suffix). > > To zero out the chance that I did something wrong with externalizing > parts of the compiler driver into my own application, I wrote a simple > main method with the following "fallback": > > rustc::driver::main_args(args.as_slice()) > > It will simply do what rustc does... Invoke the rustc compiler with > the arguments provided. This call will land inside of the compiler > that was used to compile the very same statement (I hope). Its using > the "rustc" crate after all. > > Still the same error message ;) > > So how could that be resolved? This is also an issue for custom Lint > plugins I guess, because you will definitely not want to invoke rustc > as external command and then have your plugin run in a different > process. I basically need the AST after analysis in its pure form, > like no JSON or something. Just want to continue where the compiler > left off... Instead of generating LLVM & stuff, which is not needed in > my case. > > best > chris From glaebhoerl at gmail.com Sun Jul 13 07:29:00 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Sun, 13 Jul 2014 16:29:00 +0200 Subject: [rust-dev] Next week's older RFCs In-Reply-To: References: Message-ID: On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: > https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce > universal quantification - glaebhoerl > Use `for` rather than `<...>` syntax for type-parametric items. > Not much feedback, some discussion. > Recommend close - we're not up for changing the syntax of Rust in such > a fundamental way at this stage and want to keep with the > curly-brace-language heritage. > (Thank you for sending these e-mails. I've responded to the substantive aspects of this at the PR, as requested, but for the "meta" aspects pertaining to process, I hope that replying to the e-mail is acceptable.) If I may file a small protest: It feels wrong to me that the first time I hear of this concern is in a recommendation to the meeting group to close the PR because of it. (Which is not to mention that it's based on a basic misunderstanding of the proposal.) Would it be possible to always raise a particular concern in the comments on a PR before using it as justification to close, or recommend closing, that PR? (In general, I think it would be beneficial if the people who get to decide the fate of PRs took a more active role in discussing and shaping them, instead of staying aloof before handing down an opinion at some point.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sun Jul 13 11:18:19 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 13 Jul 2014 11:18:19 -0700 Subject: [rust-dev] Rust Guidelines In-Reply-To: <53C031AB.6030407@mozilla.com> References: <53C031AB.6030407@mozilla.com> Message-ID: On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon wrote: > The best part: approved guidelines can turn into (1) new github issues to > bring libstd into line and (2) an authoritative way to resolve debates on > libstd PRs. How about a gofmt-like source code reformatting utility? -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Sun Jul 13 13:37:11 2014 From: lists at ncameron.org (Nick Cameron) Date: Mon, 14 Jul 2014 08:37:11 +1200 Subject: [rust-dev] Next week's older RFCs In-Reply-To: References: Message-ID: Yes, this is the right place for meta-discussion. I'll make sure to be stricter about commenting on the PRs in the future. The aim of this email is only to summarise the discussion so far, it shouldn't add new opinions or comments beyond applying our 'rules' for accepting PRs in the most uncontroversial manner. Obviously that is kind of a fuzzy statement, but I think you are right that here I didn't quite stick to that. Sorry. In general, I agree with your last point, but it takes considerable time and energy to have an active role and that is in limited supply, so it is always a trade off on whether any particular person gets involved with a particular RFC. Having said that, the vast majority of the discussion for an RFC should always be happening on the RFC. Cheers, Nick On Mon, Jul 14, 2014 at 2:29 AM, G?bor Lehel wrote: > On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: > >> https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce >> universal quantification - glaebhoerl >> Use `for` rather than `<...>` syntax for type-parametric items. >> Not much feedback, some discussion. >> Recommend close - we're not up for changing the syntax of Rust in >> such a fundamental way at this stage and want to keep with the >> curly-brace-language heritage. >> > > (Thank you for sending these e-mails. I've responded to the substantive > aspects of this at the PR, as requested, but for the "meta" aspects > pertaining to process, I hope that replying to the e-mail is acceptable.) > > If I may file a small protest: It feels wrong to me that the first time I > hear of this concern is in a recommendation to the meeting group to close > the PR because of it. (Which is not to mention that it's based on a basic > misunderstanding of the proposal.) Would it be possible to always raise a > particular concern in the comments on a PR before using it as justification > to close, or recommend closing, that PR? > > (In general, I think it would be beneficial if the people who get to > decide the fate of PRs took a more active role in discussing and shaping > them, instead of staying aloof before handing down an opinion at some > point.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Sun Jul 13 15:45:47 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Sun, 13 Jul 2014 23:45:47 +0100 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> Message-ID: On 13 July 2014 19:18, Tony Arcieri wrote: > How about a gofmt-like source code reformatting utility? Provided it will not support hard tabs... From simon.sapin at exyr.org Sun Jul 13 16:12:22 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Mon, 14 Jul 2014 00:12:22 +0100 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> Message-ID: <53C31256.9000307@exyr.org> On 13/07/14 19:18, Tony Arcieri wrote: > On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon > wrote: > > The best part: approved guidelines can turn into (1) new github > issues to bring libstd into line and (2) an authoritative way to > resolve debates on libstd PRs. > > > How about a gofmt-like source code reformatting utility? As far as I can tell, everyone agrees it would be great to have. We just need someone to make it. -- Simon Sapin From gsingh_2011 at yahoo.com Sun Jul 13 18:18:25 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Sun, 13 Jul 2014 18:18:25 -0700 Subject: [rust-dev] Rust Guidelines In-Reply-To: <53C31256.9000307@exyr.org> References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: Looks like it's already in development: https://github.com/pcwalton/rustfmt On Sun, Jul 13, 2014 at 4:12 PM, Simon Sapin wrote: > On 13/07/14 19:18, Tony Arcieri wrote: > >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon > > wrote: >> >> The best part: approved guidelines can turn into (1) new github >> issues to bring libstd into line and (2) an authoritative way to >> resolve debates on libstd PRs. >> >> >> How about a gofmt-like source code reformatting utility? >> > > As far as I can tell, everyone agrees it would be great to have. We just > need someone to make it. > > -- > Simon Sapin > > _______________________________________________ > 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 thesaint1987 at googlemail.com Sun Jul 13 23:24:47 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Mon, 14 Jul 2014 08:24:47 +0200 Subject: [rust-dev] Rust Guidelines In-Reply-To: <53C31256.9000307@exyr.org> References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: Hmm I am actually trying to make one as first step towards accurate code completion and refactoring. But I have never done that before so I can't promise anything :D. On Mon, Jul 14, 2014 at 1:12 AM, Simon Sapin wrote: > On 13/07/14 19:18, Tony Arcieri wrote: >> >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon > > wrote: >> >> The best part: approved guidelines can turn into (1) new github >> issues to bring libstd into line and (2) an authoritative way to >> resolve debates on libstd PRs. >> >> >> How about a gofmt-like source code reformatting utility? > > > As far as I can tell, everyone agrees it would be great to have. We just > need someone to make it. > > -- > Simon Sapin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From richo at psych0tik.net Mon Jul 14 01:13:46 2014 From: richo at psych0tik.net (richo) Date: Mon, 14 Jul 2014 18:13:46 +1000 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> Message-ID: <20140714081346.GA69808@xenia.local> On 10/07/14 17:15 +0000, Ivan Kozik wrote: >On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki > wrote: >> While this is a good thing /all/ software projects should be doing imo, >> one could still explicitly allow Archive.org by prepending: >> >> User-agent: ia_archiver >> Disallow: >> >> ? > >It looks like documentation for the old versions e.g. >http://doc.rust-lang.org/0.9/ is a 404 anyway. > Which is kinda the point of letting archive.org keep a copy for posterity. Not that I have a bunch of sway, but I'm +1 on not letting old docs be searchable, and also +1 on making an exception for archive.org From olson.jeffery at gmail.com Mon Jul 14 06:03:00 2014 From: olson.jeffery at gmail.com (Jeffery Olson) Date: Mon, 14 Jul 2014 08:03:00 -0500 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: On Mon, Jul 14, 2014 at 1:24 AM, Christoph Husse < thesaint1987 at googlemail.com> wrote: > Hmm I am actually trying to make one as first step towards accurate > code completion and refactoring. But I have never done that before so > I can't promise anything :D. > > On Mon, Jul 14, 2014 at 1:12 AM, Simon Sapin wrote: > > On 13/07/14 19:18, Tony Arcieri wrote: > >> > >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon >> > wrote: > >> > >> The best part: approved guidelines can turn into (1) new github > >> issues to bring libstd into line and (2) an authoritative way to > >> resolve debates on libstd PRs. > >> > >> > >> How about a gofmt-like source code reformatting utility? > https://github.com/pcwalton/rustfmt > > > > > > As far as I can tell, everyone agrees it would be great to have. We just > > need someone to make it. > > > > -- > > Simon Sapin > > > > _______________________________________________ > > 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 thesaint1987 at googlemail.com Mon Jul 14 06:12:50 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Mon, 14 Jul 2014 15:12:50 +0200 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: I looked at this tool already, but it has a complementary approach (which definitely is needed in addition anyway). I want to base code completion entirely on the compiler, which means it will only work for something the compiler can get analaysis to pass on. But on the other hand it will be absolutely accurate and "could" be used to restyle an entire codebase without fear of breaking stuff (in an ideal world at least). But of course for many tasks it might also be better to just format stuff that doesn't yet compile. So both approaches have their tradeoffs I think. Just want to make sure I am not doing duplicate work ;), and in this case it looks as if it was a completely different approach. On Mon, Jul 14, 2014 at 3:03 PM, Jeffery Olson wrote: > > > > On Mon, Jul 14, 2014 at 1:24 AM, Christoph Husse > wrote: >> >> Hmm I am actually trying to make one as first step towards accurate >> code completion and refactoring. But I have never done that before so >> I can't promise anything :D. >> >> On Mon, Jul 14, 2014 at 1:12 AM, Simon Sapin wrote: >> > On 13/07/14 19:18, Tony Arcieri wrote: >> >> >> >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon > >> > wrote: >> >> >> >> The best part: approved guidelines can turn into (1) new github >> >> issues to bring libstd into line and (2) an authoritative way to >> >> resolve debates on libstd PRs. >> >> >> >> >> >> How about a gofmt-like source code reformatting utility? > > > https://github.com/pcwalton/rustfmt > >> >> > >> > >> > As far as I can tell, everyone agrees it would be great to have. We just >> > need someone to make it. >> > >> > -- >> > Simon Sapin >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From thesaint1987 at googlemail.com Mon Jul 14 06:13:19 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Mon, 14 Jul 2014 15:13:19 +0200 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: I meant code formatting, not code completion xD On Mon, Jul 14, 2014 at 3:12 PM, Christoph Husse wrote: > I looked at this tool already, but it has a complementary approach > (which definitely is needed in addition anyway). I want to base code > completion entirely on the compiler, which means it will only work for > something the compiler can get analaysis to pass on. But on the other > hand it will be absolutely accurate and "could" be used to restyle an > entire codebase without fear of breaking stuff (in an ideal world at > least). But of course for many tasks it might also be better to just > format stuff that doesn't yet compile. So both approaches have their > tradeoffs I think. Just want to make sure I am not doing duplicate > work ;), and in this case it looks as if it was a completely different > approach. > > On Mon, Jul 14, 2014 at 3:03 PM, Jeffery Olson wrote: >> >> >> >> On Mon, Jul 14, 2014 at 1:24 AM, Christoph Husse >> wrote: >>> >>> Hmm I am actually trying to make one as first step towards accurate >>> code completion and refactoring. But I have never done that before so >>> I can't promise anything :D. >>> >>> On Mon, Jul 14, 2014 at 1:12 AM, Simon Sapin wrote: >>> > On 13/07/14 19:18, Tony Arcieri wrote: >>> >> >>> >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon >> >> > wrote: >>> >> >>> >> The best part: approved guidelines can turn into (1) new github >>> >> issues to bring libstd into line and (2) an authoritative way to >>> >> resolve debates on libstd PRs. >>> >> >>> >> >>> >> How about a gofmt-like source code reformatting utility? >> >> >> https://github.com/pcwalton/rustfmt >> >>> >>> > >>> > >>> > As far as I can tell, everyone agrees it would be great to have. We just >>> > need someone to make it. >>> > >>> > -- >>> > Simon Sapin >>> > >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > Rust-dev at mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> From thesaint1987 at googlemail.com Mon Jul 14 08:47:40 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Mon, 14 Jul 2014 17:47:40 +0200 Subject: [rust-dev] Rust Guidelines In-Reply-To: References: <53C031AB.6030407@mozilla.com> <53C31256.9000307@exyr.org> Message-ID: Indeed I did, but that was back before I understood pretty much anything about Rust :). It seems to use the compiler too so that might be a great starting point for me and a chance to merge efforts. I will look into it! Thanks. On Mon, Jul 14, 2014 at 5:43 PM, Nat Pryce wrote: > Have you looked at Racer? > > --Nat > > On 14 July 2014 14:12, Christoph Husse wrote: >> >> I looked at this tool already, but it has a complementary approach >> (which definitely is needed in addition anyway). I want to base code >> completion entirely on the compiler, which means it will only work for >> something the compiler can get analaysis to pass on. But on the other >> hand it will be absolutely accurate and "could" be used to restyle an >> entire codebase without fear of breaking stuff (in an ideal world at >> least). But of course for many tasks it might also be better to just >> format stuff that doesn't yet compile. So both approaches have their >> tradeoffs I think. Just want to make sure I am not doing duplicate >> work ;), and in this case it looks as if it was a completely different >> approach. >> >> On Mon, Jul 14, 2014 at 3:03 PM, Jeffery Olson >> wrote: >> > >> > >> > >> > On Mon, Jul 14, 2014 at 1:24 AM, Christoph Husse >> > wrote: >> >> >> >> Hmm I am actually trying to make one as first step towards accurate >> >> code completion and refactoring. But I have never done that before so >> >> I can't promise anything :D. >> >> >> >> On Mon, Jul 14, 2014 at 1:12 AM, Simon Sapin >> >> wrote: >> >> > On 13/07/14 19:18, Tony Arcieri wrote: >> >> >> >> >> >> On Fri, Jul 11, 2014 at 11:49 AM, Aaron Turon > >> >> > wrote: >> >> >> >> >> >> The best part: approved guidelines can turn into (1) new github >> >> >> issues to bring libstd into line and (2) an authoritative way to >> >> >> resolve debates on libstd PRs. >> >> >> >> >> >> >> >> >> How about a gofmt-like source code reformatting utility? >> > >> > >> > https://github.com/pcwalton/rustfmt >> > >> >> >> >> > >> >> > >> >> > As far as I can tell, everyone agrees it would be great to have. We >> >> > just >> >> > need someone to make it. >> >> > >> >> > -- >> >> > Simon Sapin >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > Rust-dev at mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> >> Rust-dev mailing list >> >> Rust-dev at mozilla.org >> >> https://mail.mozilla.org/listinfo/rust-dev >> > >> > >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > http://www.natpryce.com From banderson at mozilla.com Mon Jul 14 11:11:41 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 14 Jul 2014 11:11:41 -0700 Subject: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries In-Reply-To: References: <53BC7757.5000200@mozilla.com> Message-ID: <53C41D5D.1010102@mozilla.com> On 07/11/2014 12:09 PM, Zolt?n T?th wrote: > > On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson > wrote: > > > # Impact > > Installing rustc to non-default locations will result in an > installation that puts some important libraries in a location the > dynamic linker won't find, will need to be compensated for with > LD_LIBRARY_PATH. > > > This is too sad. > Some Rust users may not be administrators, but even if they are, > installing to some light custom folder is too convenient to miss it. > LD_LIBRARY_PATH is not known about by many, and even if known, editing > it is messy practice. > > What about these alternatives? > > 1) Link dependencies of rustc statically to it? We could link rustc statically. Right now it's not to reduce binary size. > > 2) On Windows the folder of the executable is always searched for > dependencies. Is this the case on Linux too? Then you could just let > 'make install' copy everything next to rustc. > > I may have misunderstood something basic. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon Jul 14 11:14:14 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 14 Jul 2014 11:14:14 -0700 Subject: [rust-dev] Invoking rustc as crate? In-Reply-To: References: Message-ID: <53C41DF6.6020908@mozilla.com> On 07/13/2014 12:10 AM, Christoph Husse wrote: > Hi, > > I successfully managed to hook into the compiler so far. Or well it's > not that successful, because it doesn't work, but at least the code is > there ;). > > Now I am trying to compile an empty file, and it gives me the weird error: > > "error: can't find crate for `std`" rustc guesses the 'sysroot' based on the location of the rustc binary. It expects a directory layout like bin/ rustc lib/ rustlib/ and will assume it can find libraries somewhere like ../lib/rustlib/... If your binary is not located in the correct location it will fail. Sysroot can be overridden in the session options somewhere. > > Any chance there could be more insight? Normally a C++ compiler is > able to also tell you the library search paths at least, and in this > case it would be helpful to print the assumed hash code suffix that > was expected (I assume the fact that it runs in my executable instead > of the real compiler makes it somehow look for and STD with a > different hash suffix). > > To zero out the chance that I did something wrong with externalizing > parts of the compiler driver into my own application, I wrote a simple > main method with the following "fallback": > > rustc::driver::main_args(args.as_slice()) > > It will simply do what rustc does... Invoke the rustc compiler with > the arguments provided. This call will land inside of the compiler > that was used to compile the very same statement (I hope). Its using > the "rustc" crate after all. > > Still the same error message ;) > > So how could that be resolved? This is also an issue for custom Lint > plugins I guess, because you will definitely not want to invoke rustc > as external command and then have your plugin run in a different > process. I basically need the AST after analysis in its pure form, > like no JSON or something. Just want to continue where the compiler > left off... Instead of generating LLVM & stuff, which is not needed in > my case. > > best > chris > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From banderson at mozilla.com Mon Jul 14 11:16:43 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 14 Jul 2014 11:16:43 -0700 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <20140714081346.GA69808@xenia.local> References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> <20140714081346.GA69808@xenia.local> Message-ID: <53C41E8B.8000703@mozilla.com> Can somebody file an issue described exactly what we should do and cc me? On 07/14/2014 01:13 AM, richo wrote: > On 10/07/14 17:15 +0000, Ivan Kozik wrote: >> On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki >> wrote: >>> While this is a good thing /all/ software projects should be doing imo, >>> one could still explicitly allow Archive.org by prepending: >>> >>> User-agent: ia_archiver >>> Disallow: >>> >>> ? >> >> It looks like documentation for the old versions e.g. >> http://doc.rust-lang.org/0.9/ is a 404 anyway. >> > > Which is kinda the point of letting archive.org keep a copy for > posterity. > > Not that I have a bunch of sway, but I'm +1 on not letting old docs be > searchable, and also +1 on making an exception for archive.org > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From nat.pryce at gmail.com Sun Jul 13 01:43:46 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Sun, 13 Jul 2014 09:43:46 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? Message-ID: Hi. I want to use the existing I/O types (files, sockets, etc.) with epoll. Is there an API call to get hold of their file descriptors? --Nat -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thesaint1987 at googlemail.com Mon Jul 14 11:45:20 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Mon, 14 Jul 2014 20:45:20 +0200 Subject: [rust-dev] C++ to Rust - Is that about right? Message-ID: Hi, I am just starting to think I have wrapped my mind around this type system shift introduced by rust. Now I just want to confirm that view to make sure I haven't missed something important. Declaring a C++ class in rust: ######################### // MyMod/mod.rs - One monolythic file of all structs, enums and traits my "logical module" wants to define struct MyClass { // all member variables go here } trait IMyClass { // all functions (any "new" functions that is) go here } // MyMod/MyClass/mod.rs - Constructors and direct functions go here mod ISomeTrait; impl IMyClass for MyClass { // My implementations go here } impl MyClass { // My constructors go here pub fn new() -> Box { box MyClass{} as Box } } // MyMod/MyClass/ISomeTrait.rs - Implementation of "ISomeTrait" for "MyClass" goes here impl ISomeTrait for MyClass { // My implementation goes here } ######################### Now I can hear the screams already :D. So I want to explain a bit about this choice. First, I find the rust source code I looked at so far pretty unstructured and confusing. Everything seems to be defined somewhere at will, without having a real concept (or I am just blind to see it). I think it is annoying to put exported types into submodules, because this will create a "use" nightmare. It is equally annoying to have those huge files as many rust projects have atm, by defining AND implementing various types in the same module. So my take on this is: 1) Use the "mod.rs" file to define all traits, enums and structs your module exports. This gives a clean and documented overview of what your modules exports, like an index... Or a previous C++ header file usually did. 2) Create subdirectories (if necessary) for each trait/struct defined in your modules, where you can distribute your implementations in a structured manner (like shown above). Since implementations are always imported (thank god) the user of your module doesn't need to create convoluted "use" paths to all spagetti parts of your submodule nightmare... And readers of your module can easily find what they are looking for too. 3) The "interface" naming makes most sense to me because right now I think that's what traits seem to be. Its a way of implementing an interface for classes or other interfaces that you do not control. Basically you are able to inject new functionality into existing types without having source code access to them. Which is great and reminds me a lot of C#'s extension methods, only that the RUST way seems much better... Right now the biggest issue for me is getting structure into a bigger rust project. Small clean files that do only few things (I don't want to have files bigger than a few hundred lines at MAX). But I don't want to have a "use" nightmare either. A "package" like in Java should be consumed by "use path.to.package.SomeType" which is already verbose enough. But for Rust this seems to mean that I have to put all my types into one file, which isn't exactly what I want... Maybe a lot of this is implicitly covered by the tutorial but for all of us who come from languages like Java, C++ and C#, I think its hard to really wrap around this "new" concept. Any comments ;)? Thanks From danielmicay at gmail.com Mon Jul 14 11:58:57 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 14 Jul 2014 14:58:57 -0400 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: <53C42871.8050104@gmail.com> On 14/07/14 02:45 PM, Christoph Husse wrote: > > Now I can hear the screams already :D. So I want to explain a bit > about this choice. > > First, I find the rust source code I looked at so far pretty > unstructured and confusing. Everything seems to be defined somewhere > at will, without having a real concept (or I am just blind to see it). > > I think it is annoying to put exported types into submodules, because > this will create a "use" nightmare. It is equally annoying to have > those huge files as many rust projects have atm, by defining AND > implementing various types in the same module. You don't need your weird trait usage to do this... just put all of the implementations into private submodules if you want smaller files. It's a style choice and shouldn't be exposed to library users. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From robin.kruppe at gmail.com Mon Jul 14 12:33:40 2014 From: robin.kruppe at gmail.com (Robin Kruppe) Date: Mon, 14 Jul 2014 21:33:40 +0200 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: Two things I noticed: This organization, or at least the way you present it, makes the most sense when treating classes as your primary and (almost) only design element ("Kingdom of nouns"). While this is certainly a valid design paradigm, and Rust should support it rather well, focusing on it is an indicator that you're thinking in one paradigm exclusively while using in a multi-paradigm language. This is okay, in fact expected, when coming from a single-paradigm language (Java), or from an environment where a single paradigm dominates (most C# and many C++ jobs and schools). It should naturally decrease as one is exposed to other paradigms, for example by interacting with people from such backgrounds. Just keep in mind that Rust isn't making this hard on purpose, it just offers tools for different (sometimes superior, sometimes inferior) designs too. These different paradigms often give different lenses on, for example, what structs and trait are and what belongs together into one file. Second, the signature of MyClass::new() in your example is... unusual. The return type unnecessarily narrow (returns a trait object instead of the concrete type, even though callers have to know the concrete type anyway to call new()) and does a pointless allocation as a consequence. Just return a MyClass by value. If the call site needs polymorphism, it's trivial to add (box MyClass::new() as Box) and more flexible (can use different smart pointers, or a borrowed reference for short-lived uses). If there are numerous call sites and they all need need trait objects, your design MAY be overly polymorphism-oriented for the taste of Rustaceans. Cheers Robin On Mon, Jul 14, 2014 at 8:45 PM, Christoph Husse < thesaint1987 at googlemail.com> wrote: > Hi, > > I am just starting to think I have wrapped my mind around this type > system shift introduced by rust. Now I just want to confirm that view > to make sure I haven't missed something important. > > Declaring a C++ class in rust: > > ######################### > > // MyMod/mod.rs - One monolythic file of all structs, enums and traits > my "logical module" wants to define > > struct MyClass { > // all member variables go here > } > > trait IMyClass { > // all functions (any "new" functions that is) go here > } > > // MyMod/MyClass/mod.rs - Constructors and direct functions go here > > mod ISomeTrait; > > impl IMyClass for MyClass { > // My implementations go here > } > > impl MyClass { > // My constructors go here > > pub fn new() -> Box { > box MyClass{} as Box > } > } > > // MyMod/MyClass/ISomeTrait.rs - Implementation of "ISomeTrait" for > "MyClass" goes here > > impl ISomeTrait for MyClass { > // My implementation goes here > } > > ######################### > > Now I can hear the screams already :D. So I want to explain a bit > about this choice. > > First, I find the rust source code I looked at so far pretty > unstructured and confusing. Everything seems to be defined somewhere > at will, without having a real concept (or I am just blind to see it). > > I think it is annoying to put exported types into submodules, because > this will create a "use" nightmare. It is equally annoying to have > those huge files as many rust projects have atm, by defining AND > implementing various types in the same module. > > So my take on this is: > > 1) Use the "mod.rs" file to define all traits, enums and structs your > module exports. This gives a clean and documented overview of what > your modules exports, like an index... Or a previous C++ header file > usually did. > > 2) Create subdirectories (if necessary) for each trait/struct defined > in your modules, where you can distribute your implementations in a > structured manner (like shown above). Since implementations are always > imported (thank god) the user of your module doesn't need to create > convoluted "use" paths to all spagetti parts of your submodule > nightmare... And readers of your module can easily find what they are > looking for too. > > 3) The "interface" naming makes most sense to me because right now I > think that's what traits seem to be. Its a way of implementing an > interface for classes or other interfaces that you do not control. > Basically you are able to inject new functionality into existing types > without having source code access to them. Which is great and reminds > me a lot of C#'s extension methods, only that the RUST way seems much > better... > > Right now the biggest issue for me is getting structure into a bigger > rust project. Small clean files that do only few things (I don't want > to have files bigger than a few hundred lines at MAX). But I don't > want to have a "use" nightmare either. A "package" like in Java should > be consumed by "use path.to.package.SomeType" which is already verbose > enough. But for Rust this seems to mean that I have to put all my > types into one file, which isn't exactly what I want... > > Maybe a lot of this is implicitly covered by the tutorial but for all > of us who come from languages like Java, C++ and C#, I think its hard > to really wrap around this "new" concept. > > Any comments ;)? > Thanks > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Mon Jul 14 12:38:56 2014 From: alex at crichton.co (Alex Crichton) Date: Mon, 14 Jul 2014 15:38:56 -0400 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: There is not currently a method of doing so through the `std::io` apis. While possible through the rustuv and native apis, I would discourage manual use of those crates as they have experimental and volatile APIs. You may be interested in https://github.com/rust-lang/rust/pull/15643 which may add support for acquiring the file descriptor. That PR has dome discussion about the hazards of doing so, as well. On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > Hi. I want to use the existing I/O types (files, sockets, etc.) with epoll. > Is there an API call to get hold of their file descriptors? > > --Nat > > -- > http://www.natpryce.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From danielmicay at gmail.com Mon Jul 14 12:44:04 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 14 Jul 2014 15:44:04 -0400 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: <53C43304.7090701@gmail.com> On 14/07/14 03:33 PM, Robin Kruppe wrote: > > Second, the signature of MyClass::new() in your example is... unusual. > The return type unnecessarily narrow (returns a trait object instead of > the concrete type, even though callers have to know the concrete type > anyway to call new()) and does a pointless allocation as a consequence. > Just return a MyClass by value. If the call site needs polymorphism, > it's trivial to add (box MyClass::new() as Box) and more > flexible (can use different smart pointers, or a borrowed reference for > short-lived uses). If there are numerous call sites and they all need > need trait objects, your design MAY be overly polymorphism-oriented for > the taste of Rustaceans. The trait object also results in dynamic dispatch and indirect access to the object, in addition to the memory allocation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From banderson at mozilla.com Mon Jul 14 13:19:57 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 14 Jul 2014 13:19:57 -0700 Subject: [rust-dev] Next week's older RFCs In-Reply-To: References: Message-ID: <53C43B6D.5000101@mozilla.com> On 07/10/2014 05:48 PM, Nick Cameron wrote: > Hi, here are the recommendations for discussion at next weeks > meetings. There is a new section of RFCs which are ready for > discussion but discussion has been postponed because we're waiting on > a key person for that RFC to be present. This is mostly for RFCs which > have been brought up for discussion in a meeting but, we've postponed. > There are a few other RFCs not on this list where I've ignored them > for now because the right people (mostly Niko) aren't around. > > So, there a very few RFCs this week that are obvious candidates for > closure and I we are pretty much up to date in that respect. There is > still quite a backlog of RFCs which we should discuss at meetings and > that backlog is only shrinking slowly. I think in general we don't > have enough time at the general meeting to discuss more RFCs. Should > we start discussing RFCs we might accept at triage? Or are we OK > slowly chipping away? Or should we have another meeting or some other > solution? The situation doesn't seem dire to me yet. Right now there are 37 RFC PR's open. I don't have a sense of how that compares historically, but Rust has 56, and that's a higher number... From nat.pryce at gmail.com Mon Jul 14 14:26:25 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Mon, 14 Jul 2014 22:26:25 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: Are there plans to better link the standard I/O APIs and the platform's native I/O? For example, to control devices (on Linux often done by ioctl, which needs a file descriptor), use non-IP protocols (on Linux, different socket families, return a file descriptor), multiplex I/O events, etc. --Nat On 14 July 2014 20:38, Alex Crichton wrote: > There is not currently a method of doing so through the `std::io` > apis. While possible through the rustuv and native apis, I would > discourage manual use of those crates as they have experimental and > volatile APIs. > > You may be interested in https://github.com/rust-lang/rust/pull/15643 > which may add support for acquiring the file descriptor. That PR has > dome discussion about the hazards of doing so, as well. > > On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > > Hi. I want to use the existing I/O types (files, sockets, etc.) with > epoll. > > Is there an API call to get hold of their file descriptors? > > > > --Nat > > > > -- > > http://www.natpryce.com > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Mon Jul 14 14:47:08 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Mon, 14 Jul 2014 22:47:08 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: Nat, I would very much appreciate if you join the discussion on my pull request. There is also a link to the Stack Overflow answer I got earlier, it describes how you can get the file descriptor form a lower layer `libnative` API... On 14 July 2014 22:26, Nat Pryce wrote: > Are there plans to better link the standard I/O APIs and the platform's > native I/O? For example, to control devices (on Linux often done by ioctl, > which needs a file descriptor), use non-IP protocols (on Linux, different > socket families, return a file descriptor), multiplex I/O events, etc. > > --Nat > > > On 14 July 2014 20:38, Alex Crichton wrote: >> >> There is not currently a method of doing so through the `std::io` >> apis. While possible through the rustuv and native apis, I would >> discourage manual use of those crates as they have experimental and >> volatile APIs. >> >> You may be interested in https://github.com/rust-lang/rust/pull/15643 >> which may add support for acquiring the file descriptor. That PR has >> dome discussion about the hazards of doing so, as well. >> >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with >> > epoll. >> > Is there an API call to get hold of their file descriptors? >> > >> > --Nat >> > >> > -- >> > http://www.natpryce.com >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > > > > > > -- > http://www.natpryce.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From nat.pryce at gmail.com Mon Jul 14 15:15:36 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Mon, 14 Jul 2014 23:15:36 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: I'm currently using the native API to implement new I/O abstractions for GPIO, I2C, etc. But really want to combine them with the existing File and socket APIs. I've had to copy code from the native runtime library to convert native errors to IoError, which makes me uncomfortable. What's the URL of your pull request? On 14 July 2014 22:47, Ilya Dmitrichenko wrote: > Nat, I would very much appreciate if you join the discussion on my pull > request. > > There is also a link to the Stack Overflow answer I got earlier, it > describes how you can get the file descriptor form a lower layer > `libnative` API... > > On 14 July 2014 22:26, Nat Pryce wrote: > > Are there plans to better link the standard I/O APIs and the platform's > > native I/O? For example, to control devices (on Linux often done by > ioctl, > > which needs a file descriptor), use non-IP protocols (on Linux, different > > socket families, return a file descriptor), multiplex I/O events, etc. > > > > --Nat > > > > > > On 14 July 2014 20:38, Alex Crichton wrote: > >> > >> There is not currently a method of doing so through the `std::io` > >> apis. While possible through the rustuv and native apis, I would > >> discourage manual use of those crates as they have experimental and > >> volatile APIs. > >> > >> You may be interested in https://github.com/rust-lang/rust/pull/15643 > >> which may add support for acquiring the file descriptor. That PR has > >> dome discussion about the hazards of doing so, as well. > >> > >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with > >> > epoll. > >> > Is there an API call to get hold of their file descriptors? > >> > > >> > --Nat > >> > > >> > -- > >> > http://www.natpryce.com > >> > > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > > > > > > -- > > http://www.natpryce.com > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Mon Jul 14 16:18:58 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Tue, 15 Jul 2014 00:18:58 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: Are you working on a project targeting MCUs or Linux? If MCUs, I'd strongly encourage you to join the efforts on Zinc (http://Zinc.rs)! On 14 Jul 2014 23:15, "Nat Pryce" wrote: > I'm currently using the native API to implement new I/O abstractions for > GPIO, I2C, etc. But really want to combine them with the existing File and > socket APIs. I've had to copy code from the native runtime library to > convert native errors to IoError, which makes me uncomfortable. > > What's the URL of your pull request? > > > On 14 July 2014 22:47, Ilya Dmitrichenko wrote: > >> Nat, I would very much appreciate if you join the discussion on my pull >> request. >> >> There is also a link to the Stack Overflow answer I got earlier, it >> describes how you can get the file descriptor form a lower layer >> `libnative` API... >> >> On 14 July 2014 22:26, Nat Pryce wrote: >> > Are there plans to better link the standard I/O APIs and the platform's >> > native I/O? For example, to control devices (on Linux often done by >> ioctl, >> > which needs a file descriptor), use non-IP protocols (on Linux, >> different >> > socket families, return a file descriptor), multiplex I/O events, etc. >> > >> > --Nat >> > >> > >> > On 14 July 2014 20:38, Alex Crichton wrote: >> >> >> >> There is not currently a method of doing so through the `std::io` >> >> apis. While possible through the rustuv and native apis, I would >> >> discourage manual use of those crates as they have experimental and >> >> volatile APIs. >> >> >> >> You may be interested in https://github.com/rust-lang/rust/pull/15643 >> >> which may add support for acquiring the file descriptor. That PR has >> >> dome discussion about the hazards of doing so, as well. >> >> >> >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce >> wrote: >> >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with >> >> > epoll. >> >> > Is there an API call to get hold of their file descriptors? >> >> > >> >> > --Nat >> >> > >> >> > -- >> >> > http://www.natpryce.com >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > Rust-dev at mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> > >> > >> > >> > >> > -- >> > http://www.natpryce.com >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > http://www.natpryce.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat.pryce at gmail.com Mon Jul 14 16:45:43 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Tue, 15 Jul 2014 00:45:43 +0100 Subject: [rust-dev] How to get the file descriptors of standard I/O types? In-Reply-To: References: Message-ID: <7843723655664805392@unknownmsgid> I'm writing for the Raspberry Pi, so cross-compiling to ARM Linux. --Nat www.natpryce.com On 15 Jul 2014, at 00:18, Ilya Dmitrichenko wrote: Are you working on a project targeting MCUs or Linux? If MCUs, I'd strongly encourage you to join the efforts on Zinc (http://Zinc.rs)! On 14 Jul 2014 23:15, "Nat Pryce" wrote: > I'm currently using the native API to implement new I/O abstractions for > GPIO, I2C, etc. But really want to combine them with the existing File and > socket APIs. I've had to copy code from the native runtime library to > convert native errors to IoError, which makes me uncomfortable. > > What's the URL of your pull request? > > > On 14 July 2014 22:47, Ilya Dmitrichenko wrote: > >> Nat, I would very much appreciate if you join the discussion on my pull >> request. >> >> There is also a link to the Stack Overflow answer I got earlier, it >> describes how you can get the file descriptor form a lower layer >> `libnative` API... >> >> On 14 July 2014 22:26, Nat Pryce wrote: >> > Are there plans to better link the standard I/O APIs and the platform's >> > native I/O? For example, to control devices (on Linux often done by >> ioctl, >> > which needs a file descriptor), use non-IP protocols (on Linux, >> different >> > socket families, return a file descriptor), multiplex I/O events, etc. >> > >> > --Nat >> > >> > >> > On 14 July 2014 20:38, Alex Crichton wrote: >> >> >> >> There is not currently a method of doing so through the `std::io` >> >> apis. While possible through the rustuv and native apis, I would >> >> discourage manual use of those crates as they have experimental and >> >> volatile APIs. >> >> >> >> You may be interested in https://github.com/rust-lang/rust/pull/15643 >> >> which may add support for acquiring the file descriptor. That PR has >> >> dome discussion about the hazards of doing so, as well. >> >> >> >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce >> wrote: >> >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with >> >> > epoll. >> >> > Is there an API call to get hold of their file descriptors? >> >> > >> >> > --Nat >> >> > >> >> > -- >> >> > http://www.natpryce.com >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > Rust-dev at mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> > >> > >> > >> > >> > -- >> > http://www.natpryce.com >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > http://www.natpryce.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at chrismorgan.info Mon Jul 14 18:56:44 2014 From: me at chrismorgan.info (Chris Morgan) Date: Tue, 15 Jul 2014 11:56:44 +1000 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <53C41E8B.8000703@mozilla.com> References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> <20140714081346.GA69808@xenia.local> <53C41E8B.8000703@mozilla.com> Message-ID: On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson wrote: > Can somebody file an issue described exactly what we should do and cc me? Nothing. Absolutely nothing. robots.txt rules do not apply to historical data; if archive.org has archived something, the introduction of a new Disallow rule will not remove the contents of a previous scan. It therefore has three months in which to make a scan of a release before that release is marked obsolete with the introduction of a Disallow directive. This is right and proper. Special casing a specific user agent is not the right thing to do. The contents won?t be changing after the release, anyway, so allowing archive.org to continue scanning it is a complete waste of effort. From ml at isaac.cedarswampstudios.org Mon Jul 14 19:30:35 2014 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon, 14 Jul 2014 22:30:35 -0400 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> <20140714081346.GA69808@xenia.local> <53C41E8B.8000703@mozilla.com> Message-ID: <53C4924B.5000101@isaac.cedarswampstudios.org> On 07/14/2014 09:56 PM, Chris Morgan wrote: > On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson wrote: >> Can somebody file an issue described exactly what we should do and cc me? > > Nothing. Absolutely nothing. > > robots.txt rules do not apply to historical data; if archive.org has > archived something, the introduction of a new Disallow rule will not > remove the contents of a previous scan. Although that is the robots.txt standard, archive.org does retroactively apply robots.txt Disallow rules to already-archived content. https://archive.org/about/exclude.php > It therefore has three months in which to make a scan of a release > before that release is marked obsolete with the introduction of a > Disallow directive. > > This is right and proper. Special casing a specific user agent is not > the right thing to do. The contents won?t be changing after the > release, anyway, so allowing archive.org to continue scanning it is a > complete waste of effort. It's my understanding that archive.org doesn't have the funding to reliably crawl everything on the Web promptly. I agree with the principle that "Special casing a specific user agent is not the right thing to do." but I also support the Internet Archive's mission. Another option is a `X-Robots-Tag: noindex` HTTP header, which is more robust at banning indexing[1], and it allows archiving (vs. `X-Robots-Tag: noindex, noarchive` would disallow it). It's likely less robust from the perspective of keeping our website serving that header consistently long-term though. For HTML files, X-Robots-Tag can also go in a tag in the head. -Isaac [1] (Google can still list a robots.txt-disallowed page as a search result if many sites it trusts link to that page) From eg1290 at gmail.com Mon Jul 14 19:34:54 2014 From: eg1290 at gmail.com (Evan G) Date: Mon, 14 Jul 2014 21:34:54 -0500 Subject: [rust-dev] robots.txt prevents Archive.org from storing old documentation In-Reply-To: <53C4924B.5000101@isaac.cedarswampstudios.org> References: <53BE44CA.9030503@svario.it> <53BEA9A1.2020700@gmail.com> <53BEB623.7090903@sotecware.net> <20140714081346.GA69808@xenia.local> <53C41E8B.8000703@mozilla.com> <53C4924B.5000101@isaac.cedarswampstudios.org> Message-ID: Its not about "special casing a user agent" its about archiving duplicate copies of old documents. Right now, everything is crawled off of the current docs, and none of the archived docs are allowed. with this change, the IA would store multiple copies of old documentation?once as the "old" entry for docs.rust-lang.org/ and once as the "new" entry for docs.rust-lang.org/0.9/ At least that's how I'm understanding the situation. Also, if you're really interested, all you have to do is a "git checkout 0.9" and run rustdoc. On Mon, Jul 14, 2014 at 9:30 PM, Isaac Dupree < ml at isaac.cedarswampstudios.org> wrote: > On 07/14/2014 09:56 PM, Chris Morgan wrote: > > On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson > wrote: > >> Can somebody file an issue described exactly what we should do and cc > me? > > > > Nothing. Absolutely nothing. > > > > robots.txt rules do not apply to historical data; if archive.org has > > archived something, the introduction of a new Disallow rule will not > > remove the contents of a previous scan. > > Although that is the robots.txt standard, archive.org does retroactively > apply robots.txt Disallow rules to already-archived content. > https://archive.org/about/exclude.php > > > It therefore has three months in which to make a scan of a release > > before that release is marked obsolete with the introduction of a > > Disallow directive. > > > > This is right and proper. Special casing a specific user agent is not > > the right thing to do. The contents won?t be changing after the > > release, anyway, so allowing archive.org to continue scanning it is a > > complete waste of effort. > > It's my understanding that archive.org doesn't have the funding to > reliably crawl everything on the Web promptly. I agree with the > principle that "Special casing a specific user agent is not the right > thing to do." but I also support the Internet Archive's mission. > > Another option is a `X-Robots-Tag: noindex` HTTP header, which is more > robust at banning indexing[1], and it allows archiving (vs. > `X-Robots-Tag: noindex, noarchive` would disallow it). It's likely less > robust from the perspective of keeping our website serving that header > consistently long-term though. For HTML files, X-Robots-Tag can also go > in a tag in the head. > > -Isaac > > [1] (Google can still list a robots.txt-disallowed page as a search > result if many sites it trusts link to that page) > > _______________________________________________ > 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 robin.kruppe at gmail.com Mon Jul 14 21:33:41 2014 From: robin.kruppe at gmail.com (Robin Kruppe) Date: Tue, 15 Jul 2014 06:33:41 +0200 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: Re-CCing list because you don't seem to have dropped it intentionally and I'd prefer more experienced people to shout at me if I say something wrong. On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse wrote: > > > you're thinking in one paradigm exclusively while using in a multi-paradigm > > Well, it's really hard to see how to do it otherwise. I think maybe > the tutorial just needs to make it more clear and keep in mind that > most people come from a C#, C+ or Java background. It's nice to > present the "Rust" way but that is not enough to make it clear. > Somewhere there needs to be an obvious presentation of how to make the > transition from the "normal" patterns to the "rust" patterns. You're right, this is yet another demographic that would benefit from custom tutorials. However, I also believe many people can successfully pick up the general style just by reading "generic" material. Whether they'll be sold on it is another question... > > Second, the signature of MyClass::new() in your example is... unusual. > > Yes I noticed that too :D. But up till now I haven't looked into the > different pointer & reference types yet, that will be next on my list. > Just what I noticed is that I can't use trait implementations on the > struct object. I seem to NEED to cast the struct into a trait to use > the traits method (in contrast to what C# extension methods allow). > Is that a limitation of Rust right now or a design choice? Why doesn't > it know all the interfaces a trait/struct implements somewhere and > then let's you use all that without casting? I could imagine that this > would make things a lot easier for users. After all I can safely cast > it anyway, so the compiler could also do it behind the scenes without > exposing it to the user? This has nothing to do with pointers/references and everything to do with the trait system. You can (and probably already did, there's a couple in the prelude) use trait methods on concrete types. But the trait needs to be in scope (imported) for its methods to be available. Lacking time and technical writing skills to give a full tour, let me just sketch the reasons: Traits are not just Java interfaces, in particular they can be added almost anywhere and at any time (even in a completely different crate), so not only do they sometimes clash with each other (and importing one is a way to disambiguate) it's also pretty hard to make a comprehensive list of all trait impls. It's probably technically feasible to automagically import the impls that are in the same crate but this is undesirable for other reasons: It's surprising, can still lead to name collisions and pollutes namespaces in the same way glob imports do. It also makes less sense when one takes a less OOP-y interpretation of traits (e.g. as type classes) because many of the traits implemented for one type may not be interesting for most users. For example, if MyClass implements a serialization trait that the web framework uses internally, then none of my code needs that trait or its methods. Pulling them in adds no value and has the aforementioned downsides, especially if the web framework chose a method name you'd like to use for your actual business logic (cf. explicit interface implementations in C#). Keeping that trait out of my way makes life easier for me and for the framework authors, they don't need to choose stupid non-clashing names for their internals and I don't need to disambiguate (or worse, rename *my* methods). At first glance this appears to lead to a cascade of additional imports. This doesn't appear to be the case for all Rust code I've seen so far, not even the trait-heavy of your examples. First, usually many methods are defined in "impl MyStruct" blocks (those *are* always imported alongside MyStruct), or you'd want to import the trait anyway: Either to specify it as bound in a generic (fn foo(x: T)) or to speak about trait objects (fn foo(x: &Trait)). In my limited experience, there's one trait I recall importing only to use its methods, and that's AdditiveIterator which is essentially an extension method (sum()) in C# parlance. > Further I still wonder about the file hierachy. Does that mean it's > really intended that I need to organize the files like I have shown > above? Or is there a way to export a type into a specific module > within a crate without it having to be an a specific file for that > module (which from my POV wouldn't make things more obvious xD)? No, as Daniel says, you can organize your code in (almost) any way you like and still present the same public API. This is a significant difference from the languages you know, with the theoretical (ignoring existing conventions) exception of C++. To re-export, just "pub use" it: http://doc.rust-lang.org/tutorial.html#reexporting-names You can check out the libstd source code for extensive examples. Many of the modules in its API are actually just a bunch of re-exports, often even from different crates! std::sync for example is almost entirely documentation and "pub use core_sync::*". It also defines two types (Future and TaskPool), which it puts into private sub-modules (std::sync::future and std::sync::task_pool) for organizational purposes but exports as std::sync::{Future,TaskPool}. None of this affects the API or even details of the rustdoc. > Maybe it's also just because rust is new and still missing best > practices. I just think maybe someone with a better overview should > draw up some best practices of how to organize large projects without > having large monolythic files as most rust projects do at the moment. Auron recently started an effort in that general direction, though concerning many many topics beside file organization take precedence: https://mail.mozilla.org/pipermail/rust-dev/2014-July/010735.html But I don't think the situation is as dire as you think. The organization of most rust code perhaps seems more disorganized to you than it seems to readers from other backgrounds (including the authors). Coming from Python for example, it is not at all natural to have one file per class. The boundaries of a module are a balance between small files, keeping tightly related code together (this can mean up to tens of small classes per module), and exposing a convenient, coherent API (non-issue in Rust due to re-exports). It's another consequence of not making class relationships the pillar of the design. > Further I notices that they often seem to mix test and production code > which is also strange to me. For instance with test driven development > you have tons of problems with that approach. Only mentioning a few: > > 1) Test code will most likely be at least in the order of magnitude of > the production code it tests, so putting them together in the same > directory or even file will get unhandy pretty quickly > 2) The test code this way can access internals of the module, which by > definition should be avoided, since internals are implementation > details and if your tests use them you will get cascades of test > failures for each simple design change > 3) Performance, mostly. To have fast iteration cycles, tests most > likely need to be grouped an executed/compiled intelligently (which > needs some compiler or IDE support) so that only tests that are > relevant to the changes you just made will be compiled and executed. > If you mix tests with production code then then it is a lot more > involved to sieve out tests during compilation, linking and > execution... that not need to run. > > best > chris From thesaint1987 at googlemail.com Mon Jul 14 22:08:35 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Tue, 15 Jul 2014 07:08:35 +0200 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: > pick up the general style just by reading "generic" material. Whether > they'll be sold on it is another question... Well that's the point ;). They will often not be sold because the initial time you need to invest to understand and appreciate rusts "novel" choices will be too high. Just think about most people are working 40 hours a week and they don't have much spare-time (doh it was nice to be a student xD)... They won't spend a few weekends to find out themselfes if rust is a good bet (except they really want to, like me ;) ). There is basically a need for taking up all those tons of C++, etc programmers and show them why this novel design is a lot better than what they were doing for decades maybe even... For me, right now the primary point of sale are traits and impl which for me at the moment classify under "C# extension classes" which don't exist :D. But the concept seems really close. Instead of adding methods to types you don't own, you are adding interfaces and implementations, which is really awesome and something that needs to be done in so many cases. In C# we then endup using extension methods or worse Ad-hoc interfaces, creating instanciations of interfaces at runtime that dynamically cast any class into any interface as long as the class provides those methods... But rust also has made other great design choices, interesting ones too. But mostly I think it's a revolutionary approach to C++ (which is why such tutorials are so important), while D was more just an evolution. Just the type system really needs more in-depth "conversion" tutorials that help people make the transition. The rest is pretty natural, like tasks, no exceptions, memory safety, green threads, etc... I don't need tutorials there to tell me how much better it is ;). > This has nothing to do with pointers/references and everything to do Yes I meant that I return a Box<> ;). That wasn't really thought through. Just came into my mind at that moment, like std::make_shared<>(). > For example, if MyClass implements a serialization trait that the web > framework uses internally, then none of my code needs that trait or Hmm yeah that makes sense of course. I think I just have to read more rust code and try to figure out better ways of doing the above example and making it more rusty ;). > existing conventions) exception of C++. To re-export, just "pub use" > it: http://doc.rust-lang.org/tutorial.html#reexporting-names Huh... Hmm yeah reading public code doesn't mean you see all the details, even if they are right in front of you ;). I think rust can be read quite well so far and if I compare the compiler code and also the standard library with C++ then it is just a sign of how good rust really is, because never in my life so far I could just "look" at a compiler's source and say "Hey that totally makes sense"... With rustc you can really see what the code is doing inside the compiler. I can't particalrly say that about Mono C# (which I wrote a backend for) or Clang, for which I also wrote plugins etc... > Auron recently started an effort in that general direction, though > concerning many many topics beside file organization take precedence: > https://mail.mozilla.org/pipermail/rust-dev/2014-July/010735.html Thanks, I will definitely have a look! > have one file per class. The boundaries of a module are a balance > between small files, keeping tightly related code together (this can > mean up to tens of small classes per module), and exposing a Well, the problem is bad atm because rust doesn't have any sort of IDE as C++, Java or C# have. Without all the search & navigation features it is really annoying to navigate large files. Also this is more of a personal preference I guess. I generally find smaller files easier to grasp and it is also psychologically helpful, because you are not drowned in code when you want to understand the file ;). Also I don't think that tighly related code should be in the same file for the reason of being related. I don't defend Java's "single class per file" either becuase in practice it can be really annoying at times and create a flood of tiny files, which is probably as bad as having large monolythic files. If you have 10 classes that are really tighly related it often means you might have "made" them too tightly coupled and they could be more decoupled ;). When you force yourself into small files and small classes combined with extensive Unittests, decoupling comes pretty natural. But I don't want to discuss that either, since it's not rust specific but rather philosophic. From gsingh_2011 at yahoo.com Mon Jul 14 23:28:55 2014 From: gsingh_2011 at yahoo.com (Gulshan Singh) Date: Mon, 14 Jul 2014 23:28:55 -0700 Subject: [rust-dev] Daemonizing a process In-Reply-To: References: <20140709073254.GA1179@xenia.local> Message-ID: Alex Crichton helped me figure out a solution: use std::io::Command; use std::os; use std::io::timer::sleep; fn main() { let args = os::args(); if args.len() == 1 { let child = Command::new(args.get(0).as_slice()) .arg("child") .detached().spawn().unwrap(); println!("child: {}", child.id()); child.forget(); } else { sleep(40000); // In the daemon } } You can use pgrep to confirm the daemon is running. I don't know how to print to stdout because the file descriptor is closed (and the daemon silently crashes when calling `println`). On Wed, Jul 9, 2014 at 1:00 AM, Ilya Dmitrichenko wrote: > Additionally, I'd like to note that modern best practice is to relay this > on the init process itself. With modern init systems, such as systemd or > launchctl, this works very nicely and application developer doesn't have to > care about daemonisation and logging is also done simply via stdout. > On 9 Jul 2014 08:33, "richo" wrote: > >> On 08/07/14 23:47 -0700, Gulshan Singh wrote: >> >>> Is there currently any way to daemonize a process in Linux? I was using >>> the >>> `daemon` function in C: http://man7.org/linux/man- >>> pages/man3/daemon.3.html. >>> I asked in the IRC but I didn't get a response. >>> >> >> There's going to be excitement with this, mostly because typically >> daemonising involves forking twice to ensure that you're reparented to >> init, >> which will result in a Really Bad Time if you're using libnative. >> >> Therefore, it's possible but only if you've not done too much stuff, which >> would be unsafe. >> >> Seperately though, rust *does* need a coherent story here. I'm just not at >> all sure what it will look like. >> >> _______________________________________________ >> 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 errordeveloper at gmail.com Tue Jul 15 00:35:00 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Tue, 15 Jul 2014 08:35:00 +0100 Subject: [rust-dev] Daemonizing a process In-Reply-To: References: <20140709073254.GA1179@xenia.local> Message-ID: Sure, traditional deamons don't have stdio. You will need to write to a log file and then also care about how that file is being rotated etc. Traditionally daemons have a signal handle that execution reopening of logs... You will also need to write an init script to actually start it. What I was saying is that it is not really necessary with a modern init implementations, such as systemd or upstart. The do take care of stdio and logging as well as "backgrounding" the service. Cheers, -- Ilya On 15 July 2014 07:28, Gulshan Singh wrote: > Alex Crichton helped me figure out a solution: > > use std::io::Command; > use std::os; > use std::io::timer::sleep; > > fn main() { > let args = os::args(); > if args.len() == 1 { > let child = Command::new(args.get(0).as_slice()) > .arg("child") > .detached().spawn().unwrap(); > println!("child: {}", child.id()); > child.forget(); > } else { > sleep(40000); // In the daemon > } > } > > You can use pgrep to confirm the daemon is running. I don't know how to > print to stdout because the file descriptor is closed (and the daemon > silently crashes when calling `println`). > > > On Wed, Jul 9, 2014 at 1:00 AM, Ilya Dmitrichenko > wrote: >> >> Additionally, I'd like to note that modern best practice is to relay this >> on the init process itself. With modern init systems, such as systemd or >> launchctl, this works very nicely and application developer doesn't have to >> care about daemonisation and logging is also done simply via stdout. >> >> On 9 Jul 2014 08:33, "richo" wrote: >>> >>> On 08/07/14 23:47 -0700, Gulshan Singh wrote: >>>> >>>> Is there currently any way to daemonize a process in Linux? I was using >>>> the >>>> `daemon` function in C: >>>> http://man7.org/linux/man-pages/man3/daemon.3.html. >>>> I asked in the IRC but I didn't get a response. >>> >>> >>> There's going to be excitement with this, mostly because typically >>> daemonising involves forking twice to ensure that you're reparented to >>> init, >>> which will result in a Really Bad Time if you're using libnative. >>> >>> Therefore, it's possible but only if you've not done too much stuff, >>> which >>> would be unsafe. >>> >>> Seperately though, rust *does* need a coherent story here. I'm just not >>> at >>> all sure what it will look like. >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev > > From steve at steveklabnik.com Tue Jul 15 04:51:19 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 15 Jul 2014 04:51:19 -0700 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: You shouldn't return a Box unless you have to: box does placement new, so by not doing it yourself, you give them options: struct Point { x: int, y: int, } impl Point { fn bad_new() -> Box { box Point { x: 1, y: 1 } } fn good_new() -> Point { Point { x: 1, y: 1 } } } fn main() { let x = Point::bad_new(); // this _must_ be Box, and nothing else let y = box Point::good_new(); // this is a Box, with no copy, but... let z = box(std::gc::Gc) Point::good_new(); // this is a Gc, with no copy. } From masklinn at masklinn.net Tue Jul 15 05:49:56 2014 From: masklinn at masklinn.net (Masklinn) Date: Tue, 15 Jul 2014 14:49:56 +0200 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: On 2014-07-15, at 13:51 , Steve Klabnik wrote: > let z = box(std::gc::Gc) Point::good_new(); // this is a Gc, > with no copy. > } Unless that's changed in 0.11, IIRC that should be box(std::gc::GC). Which remains weird and annoying, is there any plan to drop the static and allow the type there when/once boxes become pluggable? From steve at steveklabnik.com Tue Jul 15 06:45:03 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 15 Jul 2014 09:45:03 -0400 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: Whoops, yes, it was just a typo. From apoelstra at wpsoftware.net Tue Jul 15 07:18:00 2014 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Tue, 15 Jul 2014 07:18:00 -0700 Subject: [rust-dev] C++ to Rust - Is that about right? In-Reply-To: References: Message-ID: <20140715141800.GM3886@shavo.dd-wrt> > On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse > wrote: > > Further I notices that they often seem to mix test and production code > > which is also strange to me. For instance with test driven development > > you have tons of problems with that approach. Only mentioning a few: > > > > 1) Test code will most likely be at least in the order of magnitude of > > the production code it tests, so putting them together in the same > > directory or even file will get unhandy pretty quickly You've mentioned file size a few times. In vi you type `:vsplit` to split your screen into two views of the same file, then you type `/functionname` in one to go find the relevant function. Alternately, if your functions are in separate files, you add the relevant file name to the `:vsplit` command. So the amount of effort spent editing is basically the same. I expect most IDE's that are not structured around the C#/Java way of doing things are similarly filesize-agnostic. On the other hand, /conceptually/ I find Rust's module system to be much easier to reason about. Even in OO-only languages class boundaries are typically not functionality boundaries (unless you have monolithic classes in which only a small subset of functionality is ever used at any time --- but then you have no modularity, an even worse curse). In Rust, where precisely-scoped traits provide the majority of functionality, more than the `struct Struct`/`impl Struct` pairs that are used to emulate classes, this is even more true. > > 2) The test code this way can access internals of the module, which by > > definition should be avoided, since internals are implementation > > details and if your tests use them you will get cascades of test > > failures for each simple design change Well, in your public interface tests, don't use private functions. When replacing/restructuring private functions, delete the tests which target those. In other languages I find it very inconvienient to have to switch contexts to work on tests, and to have no ability to unit test functions which are not publically exported. > > 3) Performance, mostly. To have fast iteration cycles, tests most > > likely need to be grouped an executed/compiled intelligently (which > > needs some compiler or IDE support) so that only tests that are > > relevant to the changes you just made will be compiled and executed. > > If you mix tests with production code then then it is a lot more > > involved to sieve out tests during compilation, linking and > > execution... that not need to run. > > Well, Rust in general needs some work done on partial compilation :). I'm sure optimizing test compilation will come as part of that. -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school." --Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From erick.tryzelaar at gmail.com Tue Jul 15 12:20:06 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 15 Jul 2014 12:20:06 -0700 Subject: [rust-dev] 7/31 SF Bay Area Meetup Message-ID: Hello Oxidizers! I'm pleased to announce the next Bay Area Rust Meetup on Thursday July 31, 2014, at Hack Reactor in San Francisco. Sign up here to attend: http://www.meetup.com/Rust-Bay-Area/events/181256992/ This meetups theme is based on the amazing work at building Rust's web infrastructure. We have talks across the the entire web stack. Here is are lineup of speakers: ? Jonathan Reem and Zach Pomerantz: Iron middleware framework ? Steven Fackler: The design and a bit of implementation of rust-postgres . I'll also briefly go over rust-postgres-macros which leverages Rust's compiler plugin support to add some static safety checks to SQL statements. ? Christoph Burg: Floor web server ? James Rowe: Why you should make a Web Framework in Rust Since we're having the event in a new location, we'll be funding dinner ourselves tonight, so please bring a couple dollars to help chip in for the food. We also hope to record the sessions for Air Mozilla and stream them live online, but we're figuring out the details for that. I'll send out more once we figure out setup out. Finally, please make sure to grab a visitor's pass from the reception desk when you first get here. See you then! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Wed Jul 16 06:38:34 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 16 Jul 2014 14:38:34 +0100 Subject: [rust-dev] no error or warning when an unknown attribute is used Message-ID: Hi List, Using serialize crate, I have made a typo in attribute name and wrote 'derives' instead of 'deriving' and I got an error message about `ToJson` trait not being implemented. Here is what I did: > cat foo.rs extern crate serialize; use serialize::json; #[derive(Decodable, Encodable)] pub struct Data { test: bool, uuid: int, time: f64, } fn main() { let data = Data { test: true, uuid: 123, time: 34349480.24 }; json::encode(&data); } > rustc foo.rs foo.rs:13:3: 13:15 error: failed to find an implementation of trait serialize::serialize::Encodable,std::io::IoError> for Data foo.rs:13 json::encode(&data); ^~~~~~~~~~~~ The compiler happily skipped over unknown attribute... Is this a desired behaviour or a known issues? Cheers, -- Ilya From mail at bharr.is Wed Jul 16 06:51:36 2014 From: mail at bharr.is (Ben Harris) Date: Wed, 16 Jul 2014 21:51:36 +0800 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: Did it come up as an unused-attribute warning? On 16 July 2014 21:38, Ilya Dmitrichenko wrote: > Hi List, > > Using serialize crate, I have made a typo in attribute name and wrote > 'derives' instead of 'deriving' and I got an error message about > `ToJson` trait not being implemented. > > Here is what I did: > > > cat foo.rs > extern crate serialize; > use serialize::json; > > #[derive(Decodable, Encodable)] > pub struct Data { > test: bool, > uuid: int, > time: f64, > } > > fn main() { > let data = Data { test: true, uuid: 123, time: 34349480.24 }; > json::encode(&data); > } > > > rustc foo.rs > foo.rs:13:3: 13:15 error: failed to find an implementation of trait > > serialize::serialize::Encodable,std::io::IoError> > for Data > foo.rs:13 json::encode(&data); > ^~~~~~~~~~~~ > > The compiler happily skipped over unknown attribute... Is this a > desired behaviour or a known issues? > > Cheers, > -- > Ilya > _______________________________________________ > 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 errordeveloper at gmail.com Wed Jul 16 06:55:38 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 16 Jul 2014 14:55:38 +0100 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: On 16 July 2014 14:51, Ben Harris wrote: > Did it come up as an unused-attribute warning? No, it didn't. This is all the output I got: >> > rustc foo.rs >> foo.rs:13:3: 13:15 error: failed to find an implementation of trait >> >> serialize::serialize::Encodable,std::io::IoError> >> for Data >> foo.rs:13 json::encode(&data); >> ^~~~~~~~~~~~ From mail at bharr.is Wed Jul 16 06:59:46 2014 From: mail at bharr.is (Ben Harris) Date: Wed, 16 Jul 2014 21:59:46 +0800 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: You can ask on the Rust IRC. My guess is that the error is triggering before there is a chance to throw the unused-attribute warning out. In the past it would have told you the error, but with the new plugin system we can define our own attributes, so the lint can't tell that we have done something wrong till the end. On 16 July 2014 21:55, Ilya Dmitrichenko wrote: > On 16 July 2014 14:51, Ben Harris wrote: > > Did it come up as an unused-attribute warning? > > No, it didn't. This is all the output I got: > > >> > rustc foo.rs > >> foo.rs:13:3: 13:15 error: failed to find an implementation of trait > >> > >> > serialize::serialize::Encodable,std::io::IoError> > >> for Data > >> foo.rs:13 json::encode(&data); > >> ^~~~~~~~~~~~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Wed Jul 16 07:11:26 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 16 Jul 2014 15:11:26 +0100 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: On 16 July 2014 14:59, Ben Harris wrote: > You can ask on the Rust IRC. My guess is that the error is triggering before > there is a chance to throw the unused-attribute warning out. In the past it > would have told you the error, but with the new plugin system we can define > our own attributes, so the lint can't tell that we have done something wrong > till the end. Ben, your guess was right. I remove the `json::encode` call and got `warning: unused attribute` and fixing the attribute name gets rid of the warning. I suppose this is a downside of the plugin system... From andres at andrab.com Wed Jul 16 07:19:06 2014 From: andres at andrab.com (=?ISO-8859-1?Q?=22Andr=E9s_N=2E_Robalino=22?=) Date: Wed, 16 Jul 2014 09:19:06 -0500 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: <53C689DA.2050806@andrab.com> If you comment out json::encode(&data) you'll get the expected warnings. On 7/16/14, 8:59, Ben Harris wrote: > You can ask on the Rust IRC. My guess is that the error is triggering > before there is a chance to throw the unused-attribute warning out. In > the past it would have told you the error, but with the new plugin > system we can define our own attributes, so the lint can't tell that > we have done something wrong till the end. > > > On 16 July 2014 21:55, Ilya Dmitrichenko > wrote: > > On 16 July 2014 14:51, Ben Harris > wrote: > > Did it come up as an unused-attribute warning? > > No, it didn't. This is all the output I got: > > >> > rustc foo.rs > >> foo.rs:13:3: 13:15 error: failed to find an implementation of trait > >> > >> > serialize::serialize::Encodable,std::io::IoError> > >> for Data > >> foo.rs:13 json::encode(&data); > >> ^~~~~~~~~~~~ > > > > > _______________________________________________ > 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 thesaint1987 at googlemail.com Wed Jul 16 07:22:59 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Wed, 16 Jul 2014 16:22:59 +0200 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: > Ben, your guess was right. I remove the `json::encode` call and got > `warning: unused attribute` and fixing the attribute name gets rid of > the warning. I suppose this is a downside of the plugin system... I think adding "-D unused-attribute" will do the trick too (might not be spelled correctly though). It should issue an error instead of a warning. If it doesn't then probably there should be some fix, in which all analysis passes are still executed at some point and all errors (at least) collected, like it is done with most existing compilers. Or some other reordering, like running certain "plugin" passes before others etc. From me at chrismorgan.info Wed Jul 16 07:23:05 2014 From: me at chrismorgan.info (Chris Morgan) Date: Thu, 17 Jul 2014 00:23:05 +1000 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: >> Did it come up as an unused-attribute warning? > No, it didn't. The simple reason it doesn?t come up as an unknown attribute is because it did not successfully compile, and so it did not get to the step where it warns about unused attributes. From errordeveloper at gmail.com Wed Jul 16 08:15:33 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 16 Jul 2014 16:15:33 +0100 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: On 16 July 2014 15:23, Chris Morgan wrote: >>> Did it come up as an unused-attribute warning? >> No, it didn't. > The simple reason it doesn't come up as an unknown attribute is > because it did not successfully compile, and so it did not get to the > step where it warns about unused attributes. Sure, it's pretty clear what's going on, but I do think it's a bit of a problem. It's rather hard to spot a misspelled attribute. Should there be a pre-lint stage for this purpose? From glaebhoerl at gmail.com Wed Jul 16 10:54:45 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Wed, 16 Jul 2014 19:54:45 +0200 Subject: [rust-dev] Requesting information (about globs, macros, subtyping) Message-ID: Hello list, There are a couple of subjects I've been trying to ask for information about in comments here-and-there, and by and large not succeeding very much, so I thought I would try again, this time to a whole mailing list. (I was thinking of just asking on IRC, but perhaps an email conversation might benefit more people, and create a more permanent record for referring back to later.) There's four different subjects I'm curious about, and possibly they would be better off as separate threads, but I don't want to spam the list. Instead I'd like to request that anyone who wants to discuss these topics further beyond just trying to answer and discuss the listed questions (e.g. to discuss what Rust should do in the future, as opposed to background on its past and present) should start a new thread for it (edit the subject on the reply). So: 1. What are the problems with glob imports? I've encountered many references to these problems, but not much elaboration on them. Thinking here of consequences both for users of the language and for the implementation. 2. It's been suggested, and also seems natural to me, to have macros scoped like all other items, i.e. to import them from modules with `use` (`use std::io::println;`) and to invoke them qualified with their path (`std::io::println!("for example")`). But there are allegedly problems with this, something to do with the fact that macros can also _create_ modules, if I'm remembering correctly. Could someone elaborate on these issues in greater detail? 3. As far as I'm aware, subtyping in the current language arises only from subtyping of lifetimes. Where is this important? One example was mentioned in [Niko's recent blog post]( http://smallcultfollowing.com/babysteps/blog/2014/07/06/implied-bounds/). Where else? Without this subtyping of lifetimes, what would break? How burdensome would it be if one had to use explicit casts in those circumstances? 4. Currently, items from parent modules are not visible in a given `mod` without an explicit `use`, and the paths in `use` declarations are by-default relative to the crate root, rather than to the current module (while the latter can be specified explicitly with `self::`). Allegedly this is because in Old Rust, it was (like everything) the other way around, and it proved too hard to keep track of which names were coming from where. My question is: Was this also the case for things declared in a parent module within the same file, or was this mainly a problem for modules defined out-of-line in a separate file, and these having access to things from parent modules defined in different files? If it's the former (problematic even within the same file), then examples would also be appreciated. ([Relevant recent musings on my part.]( https://github.com/rust-lang/rfcs/pull/38#issuecomment-47533272)) Awaiting enlightening explanations with bated breath, G?bor -------------- next part -------------- An HTML attachment was scrubbed... URL: From thesaint1987 at googlemail.com Wed Jul 16 11:59:16 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Wed, 16 Jul 2014 20:59:16 +0200 Subject: [rust-dev] Why no "@Override" analogy? Message-ID: This comment from "syntax::visit::Visitor" really gives me a headache: /// If you want to ensure that your code handles every variant /// explicitly, you need to override each method. (And you also need /// to monitor future changes to `Visitor` in case a new method with a /// new default implementation gets introduced.) I kindof thought we would have passed this :(. "I" need to check for future changes :O? How? Closed source 3rd party, just to name one example, or simply oversight. Okay, an IDE could warn too. But we dont' have one right now and in the past it didn't seem like this would have helped much. What's the rationale behind this decision? Why no: #[Impl] attribute or something? Sry, if I bring up old discussions but it was kinda hard to come up with a search term for this. From sfackler at gmail.com Wed Jul 16 12:08:09 2014 From: sfackler at gmail.com (Steven Fackler) Date: Wed, 16 Jul 2014 12:08:09 -0700 Subject: [rust-dev] Why no "@Override" analogy? In-Reply-To: References: Message-ID: I don't see what this has to do with @Override. @Override causes the compiler to check to make sure that the method signature matches a supertype method. Rust always enforces that check inside of a trait implementation block. This kind of thing is always illegal: impl SomeTrait for Foo { fn some_random_method_that_isnt_part_of_some_trait(&self) { ... } } The visitor trait is huge, and 99% of use cases don't need to visit every possible part of the AST, so there are default implementations of all of the methods that simply fall through to visit all of the subparts. That comment is just saying that if you *do* want to visit everything, you have to manually check to make sure you're overriding everything. Steven Fackler On Wed, Jul 16, 2014 at 11:59 AM, Christoph Husse < thesaint1987 at googlemail.com> wrote: > This comment from "syntax::visit::Visitor" really gives me a headache: > > /// If you want to ensure that your code handles every variant > /// explicitly, you need to override each method. (And you also need > /// to monitor future changes to `Visitor` in case a new method with a > /// new default implementation gets introduced.) > > I kindof thought we would have passed this :(. > "I" need to check for future changes :O? How? Closed source 3rd party, > just to name one example, or simply oversight. Okay, an IDE could warn > too. But we dont' have one right now and in the past it didn't seem > like this would have helped much. > > What's the rationale behind this decision? > > Why no: #[Impl] attribute or something? > > Sry, if I bring up old discussions but it was kinda hard to come up > with a search term for this. > _______________________________________________ > 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 thesaint1987 at googlemail.com Wed Jul 16 12:16:16 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Wed, 16 Jul 2014 21:16:16 +0200 Subject: [rust-dev] Why no "@Override" analogy? In-Reply-To: References: Message-ID: doh. okay. it has a lot to do with it but it is enabled by default then :D. slowly climbing the learning curve lol On Wednesday, July 16, 2014, Steven Fackler wrote: > I don't see what this has to do with @Override. @Override causes the > compiler to check to make sure that the method signature matches a > supertype method. Rust always enforces that check inside of a trait > implementation block. This kind of thing is always illegal: > > impl SomeTrait for Foo { > fn some_random_method_that_isnt_part_of_some_trait(&self) { ... } > } > > The visitor trait is huge, and 99% of use cases don't need to visit every > possible part of the AST, so there are default implementations of all of > the methods that simply fall through to visit all of the subparts. That > comment is just saying that if you *do* want to visit everything, you have > to manually check to make sure you're overriding everything. > > Steven Fackler > > > On Wed, Jul 16, 2014 at 11:59 AM, Christoph Husse < > thesaint1987 at googlemail.com > > wrote: > >> This comment from "syntax::visit::Visitor" really gives me a headache: >> >> /// If you want to ensure that your code handles every variant >> /// explicitly, you need to override each method. (And you also need >> /// to monitor future changes to `Visitor` in case a new method with a >> /// new default implementation gets introduced.) >> >> I kindof thought we would have passed this :(. >> "I" need to check for future changes :O? How? Closed source 3rd party, >> just to name one example, or simply oversight. Okay, an IDE could warn >> too. But we dont' have one right now and in the past it didn't seem >> like this would have helped much. >> >> What's the rationale behind this decision? >> >> Why no: #[Impl] attribute or something? >> >> Sry, if I bring up old discussions but it was kinda hard to come up >> with a search term for this. >> _______________________________________________ >> 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 mail at bharr.is Wed Jul 16 17:16:20 2014 From: mail at bharr.is (Ben Harris) Date: Thu, 17 Jul 2014 08:16:20 +0800 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: Have a quick skim over this ( http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/). Lint is the last thing to run before conversion to LLVM. I'f you like to suggest it changed or augmented, the rust-lang/rust issues board would be best. On 16 July 2014 23:15, Ilya Dmitrichenko wrote: > On 16 July 2014 15:23, Chris Morgan wrote: > >>> Did it come up as an unused-attribute warning? > >> No, it didn't. > > The simple reason it doesn't come up as an unknown attribute is > > because it did not successfully compile, and so it did not get to the > > step where it warns about unused attributes. > > Sure, it's pretty clear what's going on, but I do think it's a bit of > a problem. It's rather hard to spot a misspelled attribute. Should > there be a pre-lint stage for this purpose? > _______________________________________________ > 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 sfackler at gmail.com Wed Jul 16 17:19:43 2014 From: sfackler at gmail.com (Steven Fackler) Date: Wed, 16 Jul 2014 17:19:43 -0700 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: The unused attribute lint is actually running earlier than it should right now, which forces it to globally whitelist every attribute that's only used in trans: https://github.com/rust-lang/rust/blob/master/src/librustc/lint/builtin.rs#L563. It can't know if an attribute is unused until we've given the compiler an opportunity to use it! Steven Fackler On Wed, Jul 16, 2014 at 5:16 PM, Ben Harris wrote: > Have a quick skim over this ( > http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/). > Lint is the last thing to run before conversion to LLVM. > > I'f you like to suggest it changed or augmented, the rust-lang/rust issues > board would be best. > > > On 16 July 2014 23:15, Ilya Dmitrichenko wrote: > >> On 16 July 2014 15:23, Chris Morgan wrote: >> >>> Did it come up as an unused-attribute warning? >> >> No, it didn't. >> > The simple reason it doesn't come up as an unknown attribute is >> > because it did not successfully compile, and so it did not get to the >> > step where it warns about unused attributes. >> >> Sure, it's pretty clear what's going on, but I do think it's a bit of >> a problem. It's rather hard to spot a misspelled attribute. Should >> there be a pre-lint stage for this purpose? >> _______________________________________________ >> 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 mail at bharr.is Wed Jul 16 17:20:56 2014 From: mail at bharr.is (Ben Harris) Date: Thu, 17 Jul 2014 08:20:56 +0800 Subject: [rust-dev] no error or warning when an unknown attribute is used In-Reply-To: References: Message-ID: Actually, I've just realised this is not the mailing list I thought it was. I saw the author and my brain said this was the zinc list, not the rust list. :S On 17 July 2014 08:16, Ben Harris wrote: > Have a quick skim over this ( > http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/). > Lint is the last thing to run before conversion to LLVM. > > I'f you like to suggest it changed or augmented, the rust-lang/rust issues > board would be best. > > > On 16 July 2014 23:15, Ilya Dmitrichenko wrote: > >> On 16 July 2014 15:23, Chris Morgan wrote: >> >>> Did it come up as an unused-attribute warning? >> >> No, it didn't. >> > The simple reason it doesn't come up as an unknown attribute is >> > because it did not successfully compile, and so it did not get to the >> > step where it warns about unused attributes. >> >> Sure, it's pretty clear what's going on, but I do think it's a bit of >> a problem. It's rather hard to spot a misspelled attribute. Should >> there be a pre-lint stage for this purpose? >> _______________________________________________ >> 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 g5pw at macports.org Thu Jul 17 01:17:16 2014 From: g5pw at macports.org (=?utf-8?Q?Alja=C5=BE_Srebrni=C4=8D?=) Date: Thu, 17 Jul 2014 10:17:16 +0200 Subject: [rust-dev] Rust universal build issues Message-ID: <052B97C5-0002-46F2-B580-C6373AA241B5@macports.org> Hello list, I?m ono of the maintainers of rust on MacPorts, and I found some issues with the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a comment on line 135: # Forcibly strip off any -arch, as that totally breaks our universal support. Now, it looks like that script strips any -arch flags and adds -arch flags for *all* the supported architectures by the host compiler. As a result, some of the files are compiled as x86_64 only (the original arch flags) and some as a fat binary (i386 and x86_64). In stage3, linking fails: [?] error: ar 'x' '/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a' failed with: exit code: 1 note: stdout --- note: stderr --- ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a: Inappropriate file type or format [?] I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set RC_SUPPORTED_ARCHS=?x86_64?, but to no avail. How can I instruct compiler-rt to build for my architecture only? Thanks, Alja? -- Alja? Srebrni? a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey From clements at brinckerhoff.org Thu Jul 17 09:28:37 2014 From: clements at brinckerhoff.org (John Clements) Date: Thu, 17 Jul 2014 09:28:37 -0700 Subject: [rust-dev] Requesting information (about globs, macros, subtyping) In-Reply-To: References: Message-ID: <6702CF51-C731-487A-AC1A-E70D4D6804D7@brinckerhoff.org> On Jul 16, 2014, at 10:54 AM, G?bor Lehel wrote: > Hello list, > > There are a couple of subjects I've been trying to ask for information about in comments here-and-there, and by and large not succeeding very much, so I thought I would try again, this time to a whole mailing list. (I was thinking of just asking on IRC, but perhaps an email conversation might benefit more people, and create a more permanent record for referring back to later.) > > There's four different subjects I'm curious about, and possibly they would be better off as separate threads, but I don't want to spam the list. Instead I'd like to request that anyone who wants to discuss these topics further beyond just trying to answer and discuss the listed questions (e.g. to discuss what Rust should do in the future, as opposed to background on its past and present) should start a new thread for it (edit the subject on the reply). > > So: > > 1. What are the problems with glob imports? I've encountered many references to these problems, but not much elaboration on them. Thinking here of consequences both for users of the language and for the implementation. Wildcard (glob) imports make resolution/compilation more difficult, because you can?t tell what names are imported to a module without additional knowledge about that module. As just one example that just came up for me yesterday, doing macro expansion ?right? requires knowing what names are present at the top level before expanding macros?but if you have circular dependencies, wildcard imports, and macros that expand into items, this may be? difficult. > > 2. It's been suggested, and also seems natural to me, to have macros scoped like all other items, i.e. to import them from modules with `use` (`use std::io::println;`) and to invoke them qualified with their path (`std::io::println!("for example")`). But there are allegedly problems with this, something to do with the fact that macros can also _create_ modules, if I'm remembering correctly. Could someone elaborate on these issues in greater detail? I would like to see macros exported and imported like other bindings. There are some questions to answered, before this can be implemented. John From pnkfelix at mozilla.com Thu Jul 17 10:04:20 2014 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Thu, 17 Jul 2014 19:04:20 +0200 Subject: [rust-dev] Why no "@Override" analogy? In-Reply-To: References: Message-ID: <1AC4F3AC-177D-4D53-B195-C44531B52042@mozilla.com> Note that we are well aware that the issue Christoph mentioned is a wart for some uses of traits. E.g. some trait implementors really would like to be told when they missed a method because it has a default implementation already. One way to resolve this would be a lint; that has been previously filed as Issue #14220: "add attribute on impl and associated lint for "no default methods" https://github.com/rust-lang/rust/issues/14220 Cheers, -Felix On 16 Jul 2014, at 21:16, Christoph Husse wrote: > doh. okay. it has a lot to do with it but it is enabled by default then :D. slowly climbing the learning curve lol > > On Wednesday, July 16, 2014, Steven Fackler wrote: > I don't see what this has to do with @Override. @Override causes the compiler to check to make sure that the method signature matches a supertype method. Rust always enforces that check inside of a trait implementation block. This kind of thing is always illegal: > > impl SomeTrait for Foo { > fn some_random_method_that_isnt_part_of_some_trait(&self) { ... } > } > > The visitor trait is huge, and 99% of use cases don't need to visit every possible part of the AST, so there are default implementations of all of the methods that simply fall through to visit all of the subparts. That comment is just saying that if you *do* want to visit everything, you have to manually check to make sure you're overriding everything. > > Steven Fackler > > > On Wed, Jul 16, 2014 at 11:59 AM, Christoph Husse wrote: > This comment from "syntax::visit::Visitor" really gives me a headache: > > /// If you want to ensure that your code handles every variant > /// explicitly, you need to override each method. (And you also need > /// to monitor future changes to `Visitor` in case a new method with a > /// new default implementation gets introduced.) > > I kindof thought we would have passed this :(. > "I" need to check for future changes :O? How? Closed source 3rd party, > just to name one example, or simply oversight. Okay, an IDE could warn > too. But we dont' have one right now and in the past it didn't seem > like this would have helped much. > > What's the rationale behind this decision? > > Why no: #[Impl] attribute or something? > > Sry, if I bring up old discussions but it was kinda hard to come up > with a search term for this. > _______________________________________________ > 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 banderson at mozilla.com Thu Jul 17 11:08:12 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 17 Jul 2014 11:08:12 -0700 Subject: [rust-dev] Rust universal build issues In-Reply-To: <052B97C5-0002-46F2-B580-C6373AA241B5@macports.org> References: <052B97C5-0002-46F2-B580-C6373AA241B5@macports.org> Message-ID: <53C8110C.90509@mozilla.com> Thanks for your work on MacPorts. Did you use any flags to configure or arguments to make? What version of OS X, clang/gcc? On 07/17/2014 01:17 AM, Alja? Srebrni? wrote: > Hello list, > I?m ono of the maintainers of rust on MacPorts, and I found some issues with the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a comment on line 135: > > # Forcibly strip off any -arch, as that totally breaks our universal support. > > Now, it looks like that script strips any -arch flags and adds -arch flags for *all* the supported architectures by the host compiler. As a result, some of the files are compiled as x86_64 only (the original arch flags) and some as a fat binary (i386 and x86_64). In stage3, linking fails: I don't believe the build system is supposed to build stage3 on OS X. Seems suspicious. > > [?] > error: ar 'x' '/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a' failed with: exit code: 1 > note: stdout --- > > note: stderr --- > ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it) > ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a: Inappropriate file type or format > [?] > > I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set RC_SUPPORTED_ARCHS=?x86_64?, but to no avail. How can I instruct compiler-rt to build for my architecture only? > > Thanks, > Alja? > > -- > Alja? Srebrni? a.k.a g5pw > My public key: http://bit.ly/g5pw_pubkey > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From lists at ncameron.org Thu Jul 17 20:20:53 2014 From: lists at ncameron.org (Nick Cameron) Date: Fri, 18 Jul 2014 15:20:53 +1200 Subject: [rust-dev] RFCs up for discussion next week Message-ID: Hi, here are the recommendations for discussion at next weeks meetings. As usual, if you have comments on any of these RFCs, please add them to the discussion on the PR; please don't reply to this message. Cheers, Nick Proposed for discussion at Rust meeting --------------------------------------- https://github.com/rust-lang/rfcs/pull/123 - Rename Share to Threadsafe - acrichto Rename share. Bit of a bikeshed here, some support also for `sync`, `concurrent`, etc. Recommend: discuss. https://github.com/rust-lang/rfcs/pull/129 - refine the `asm!` extension - pczarn A string/format! based method of doing inline asm. Not much feedback. Seems like we could do better with our inline asm, not sure if this is the right approach. Recommend: probably close, but worth discussing first. https://github.com/rust-lang/rfcs/pull/130 - RFC to remove some special treatment of Box by borrow checker - nmatsakis Make Box a little bit more like a normal struct, but also make it less expressive. Removes the special ability for the borrow checker to distinguish parts of a boxed value. Pretty much no feedback. Probably accept - we want to make Box less special. https://github.com/rust-lang/rfcs/pull/134 - Remove the `'` from lifetime parameters - pcwalton Simplify the syntax of lifetimes by removing the sigil. LOTS of discussion, mix of positive and negative. I think we want to postpone this until we assess the impact of lifetime elision. Should we close this in the meantime or leave it hanging around. Anything to add to it at this point? https://github.com/rust-lang/rfcs/pull/136 - Ban private items in public APIs - glaebhoerl Not much to add to the title. For example using a private struct as a type in a public function. We have a lint for part of this already. Apparently this is used as a hack for some kind of fine-grained privacy for traits. Seems like we should address that properly. Mostly negative feedback, but (I think) only because of the hacks it would break. Lets discuss this. https://github.com/rust-lang/rfcs/pull/143 - FromLiteral - XMPPwocky FromStringLiteral, FromVectorLiteral traits so that types can be constructed from literals. Mixed feedback - mostly (but not all) positive to the idea, multiple problems in the details. I think we will need to do something to make strings and vecs more ergonomic and this is more attractive than ad hoc hardcoding. But it has a lot of problems and may not even be the right approach. Seems like a good start to the discussion, but we should probably think about this in depth. Proposed for discussion at triage --------------------------------- https://github.com/rust-lang/rfcs/pull/170 - Codegen plugins - farcaller Not enough detail to be accepted as an RFC. Propose closing pending more preliminary discussion (which is already happening on discourse). https://github.com/rust-lang/rfcs/pull/154 - Turn capitalization conventions into language rules - glaebhoerl Make our capitalisation warnings into errors. Mostly negative feedback but some positive too. Many problems identified including all the violations in existing code, languages with different capitalisation rules, FFI. Perhaps this should get discussion at a meeting, but I would recommend close. Discussed and postponed for more feedback ----------------------------------------- https://github.com/rust-lang/rfcs/pull/101 - Allow multiple (fixed-size) subslices borrows in one pattern - krdln Allows matching several parts of a vec in one pattern. Adds `xs..n` syntax to match a fixed size slice (and changes variable sized slice pattern syntax to `xs..` from `..xs`). Not much feedback - all positive or corrected later to be positive. Seems like a small generalisation with no downsides. If we change the syntax as recommended for existing patterns (i.e., `..xs` to `xs..`) then the rest should be backwards compatible, I think. https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing - Kimundi Forbid or deprecate name collision of imported names. Positive feedback. Recommend: lets do this! Might need to tidy up the RFC, but nothing major (hopefully). Need to decide whether to depricate via a feature gate or just get rid. Would be good to assess how much damage this will cause. Proposed for discussion at some point ------------------------------------- https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis A lot of discussion, pretty much all about the details. General sentiment that we want this. Recommend we accept - is this the right RFC to accept, I've not really been keeping track - pnkfelix, pcwalton - is there something which supersedes this? I think this needs a small update to reflect some of the later comments. Waiting for Niko. https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of tagged values - erikt Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against. erikt to update? https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - stevelabnik Loads of opinion in the thread (162 comments!). Note that Niko has an upcoming RFC with the concept of unsafe/trusted traits where the keyword `trusted` makes a lot more sense than `unsafe`, so we could save a keyword here. Waiting for Niko. Actions agreed -------------- https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt aturon to comment alex to close https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix + jclements to keep pushing on getting more explanation https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks huon has updated need more discussion on edge cases - see RFC - pnkfelix (and others) https://github.com/rust-lang/rfcs/pull/113 - Provide a common API across `Option` and the `Ok` and `Err` variants of `Result` - bjz Make Option and Result more consistent. Positive feedback for the idea, some discussion on the specifics. I believe this was discussed before and we were going to flesh it out a bit more. Could bjz and aturon update us on progress? To be closed, more RFCs coming from aturon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhaberman at gmail.com Fri Jul 18 00:29:23 2014 From: jhaberman at gmail.com (Josh Haberman) Date: Fri, 18 Jul 2014 00:29:23 -0700 Subject: [rust-dev] compiling Rust to C? Message-ID: Is there any prospect of compiling Rust to C anytime in the mid to near future? This would be a really attractive option for anyone who wants to write in Rust, but wants the extreme portability of C. Actually maybe I should first ask if this is actually a tractable problem. Are there technical reasons that would prevent compiling Rust into portable C? LLVM's C Backend seems to have fallen out of maintenance -- would this provide the solution I am looking for, if it were maintained? Thanks, Josh From zwarich at mozilla.com Fri Jul 18 00:35:01 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Fri, 18 Jul 2014 00:35:01 -0700 Subject: [rust-dev] compiling Rust to C? In-Reply-To: References: Message-ID: The biggest problem would be probably be handling stack unwinding (IIRC the LLVM C backend never tried to handle this either). The only option when targeting C is to use setjmp / longjmp, but that is going to be pretty inefficient. Alternatively you could just abort instead of unwinding. Cameron On Jul 18, 2014, at 12:29 AM, Josh Haberman wrote: > Is there any prospect of compiling Rust to C anytime in the mid to near future? > > This would be a really attractive option for anyone who wants to write > in Rust, but wants the extreme portability of C. > > Actually maybe I should first ask if this is actually a tractable > problem. Are there technical reasons that would prevent compiling Rust > into portable C? > > LLVM's C Backend seems to have fallen out of maintenance -- would this > provide the solution I am looking for, if it were maintained? > > Thanks, > Josh > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From zwarich at mozilla.com Fri Jul 18 01:16:00 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Fri, 18 Jul 2014 01:16:00 -0700 Subject: [rust-dev] Requesting information (about globs, macros, subtyping) In-Reply-To: References: Message-ID: On Jul 16, 2014, at 10:54 AM, G?bor Lehel wrote: > 3. As far as I'm aware, subtyping in the current language arises only from subtyping of lifetimes. Where is this important? One example was mentioned in [Niko's recent blog post](http://smallcultfollowing.com/babysteps/blog/2014/07/06/implied-bounds/). Where else? Without this subtyping of lifetimes, what would break? How burdensome would it be if one had to use explicit casts in those circumstances? I?ve been thinking about this a bit recently, so I might as well post my thoughts in this thread rather than following up privately with people. All subtyping in Rust is ultimately derived from the inclusion of lifetimes and the contravariance of the &/&mut type constructors in their lifetime parameter: a pointer to something that lives longer than ?a is usable in any place where we are using a pointer to something with lifetime ?a. As far as I know, there are only 3 original sources of bounds ?a <= ?b for lifetimes ?a and ?b: 1) Inclusion of concrete lifetimes, i.e. control-flow regions (currently lexical scopes, but soon to be extended to arbitrary single-entry / multiple exit regions), in the same function. 2) That if a function is parameterized in lifetime ?b and lifetime ?a is a concrete lifetime in that function, then ?a <= ?b. 3) That the scope of a borrow is always included in the lifetime of its referent, e.g. that ?a <= ?b in &?a &?b T. This is described by Niko in his blog post http://smallcultfollowing.com/babysteps/blog/2013/04/04/nested-lifetimes/. This rule is different than the first two because it is the only way that a bound can be propagated on two lifetime *parameters*, whereas the first two involve a concrete lifetime in one of the positions. This is handwaving a bit, since the specifics of 1) and how these all interact in the current lifetime inference (and Niko?s proposed simplification) are all relevant in practice, but I hope this is a correct abstraction of the situation. The simplest question to ask is whether it is possible to remove lifetime subtyping entirely from Rust. Unfortunately, this is not possible, because if you try to do this (see the Tofte-Talpin region system, which is probably the closest thing to pure Hindley-Milner type inference for a region system) then you have lifetime variables for local variables in a function caller and callee unified, so that a called function is allocating local variables in the caller?s lifetime. This means that lifetimes no longer correspond to nested stack frames, and you also can?t implement destructors properly (at least in any trivial way that I can think of). This is not suitable for a systems language. The next logical question to ask is whether you can eliminate the non-invariance of type constructors, since that is how subtyping infects the rest of the language. Since &/&mut are contravariant in their lifetime parameter, the vast majority of type constructors get their variance inferred as contravariant in lifetime parameters. Most examples of contravariance come from something like this: struct A { x: &?a int, y: &?a int, } If I have two distinct &int borrows with concrete lifetimes (meaning an actual control-flow region in the calling function, rather than a lifetime parameter) being used at a construction of A, then one of the lifetimes is nested in the other. Hence I if ?a is the inner lifetime and ?b is the outer lifetime, I can coerce the &?b to an &?a and construct an A. What do I lose by this? Well, it only works at the first level, so that something like this will fail to type-check: struct A<'a> { x: &'a int } fn foo(i: int) { let a = A { x: &i }; if i > 1 { let j = 2; let b = if i > 10 { a } else { A { x: &j } }; } } There are obvious workarounds here, but in more complex examples they could possibly hurt the readability / performance of the program. However, the fallout is internal to a single function, since there is no way to directly propagate the knowledge that one concrete lifetime is included in another to another function (beside the 3rd source of bounds mentioned above. which I will talk about below). You can do similar coercions with the sources of bounds 2) and 3). In 2) one of the lifetimes is a concrete lifetime again, so again all of the fallout is internal to a single function. However, in 3) there is a new complication. since knowledge of the relationship between two lifetimes can actually leak outside of the functions where they originate. Here is the example in Niko?s blog post on 3): struct BorrowedCursor<'b, T> { buffer: &'b [T], position: uint } impl<'b, T> Cursor for BorrowedCursor<'b, T> { fn get<'c>(&'c self) -> &'c T { &self.buffer[self.position] } ... } This would still work, because we?re dealing directly with the & type constructor, and we could still coerce an &?b [] to an &?c []. However, if you were to add one level of abstraction over the borrowing, you would fail to type-check: struct A<'a> { x: &'a int } fn f<'short, 'long>(p: &'short &'long int, a: A<'short>, b: A<'long>) -> A<'short> { b } These examples indicate that if you get rid of contravariance of type constructors, you are demoting user-defined types to being second-class citizens relative to builtin borrowed pointers. This is always possible to work around by just inlining the definitions of types, but it limits the potential for type abstraction. I am still curious how bad the fallout would be, but there is no easy way to tell besides implementing the change. The above reasoning only applies if you think that contravariance is the only useful form of variance for lifetime parameters. Is covariance actually useful? The simplest way it can arise is from a borrowed pointer type with a lifetime parameter in a function parameter, e.g. struct A<'a> { x: |&'a int|:'static -> int } Functions aren?t really stored into data structures that much currently in Rust (maybe that will change), so there aren?t many good examples here. In theory, nested contravariance can also produce covariance, but there are no type constructors that produce a lifetime and non-lifetime contravariance would only arise via a borrowed pointer as a function parameter, so I think this is subsumed by the previous case. I wrote a simple patch that eliminates covariance from type checking by forcing all covariant type constructors to be invariant: https://gist.github.com/zwarich/8d67756efd985fa9b216 This patch actually makes it through all of stage1, only failing on tests that seem to exist only to test covariance (I could be wrong here, I didn?t take a careful look at everything). However, when it hits libsyntax for building stage2 it gets an error: https://gist.github.com/zwarich/afda62376ccab80dcf19 This seems like it is just a bug, since LinkedPathNode should definitely be contravariant (both from the inferred bounds and the fact that a node with a shorter lifetime can point to a node with a longer lifetime, not the other way around), but I don?t have time to see what?s going on. Obviously something is getting inferred as covariant and it?s causing an issue. Anyways, I?ve rambled on about this for long enough. I probably got something wrong here, but I?d be interested in hearing the thoughts of others. Cameron From s.gesemann at gmail.com Fri Jul 18 05:45:03 2014 From: s.gesemann at gmail.com (Sebastian Gesemann) Date: Fri, 18 Jul 2014 14:45:03 +0200 Subject: [rust-dev] "Sendable References" for data-parallel fork/join-style algorithms Message-ID: Hi! I was thinking about fork/join-style parallelism and about whether this can be made to work including the possibility to pass references (or something similar to references) across task boundaries. So far, I came up with a little low-level building block that could be of interest to the community. This basically allows to send reference-like things across task boundaries without any dangling pointer issues (I believe). A use case I had in mind was a divide-and-conquer algorithm where the recursion could benefit from concurrency because the division produces independent problems operating on non-overlapping mut slices. In my case, I tried to parallelize a multibody simulation with this. But you could also think about a parallelized quicksort if you want. After partitioning, sorting the two halves can be done independently and concurrently. But you may wish to avoid splitting one vector into two and joining them together. Instead you may want different tasks to work on the same vector but restricted to their non-overlapping sub-slices. The basic idea is to erase the lifetime parameter (to make the reference-like objects sendable) and to keep it safe w.r.t. to lifetimes by creating a new scope that won't be left by execution until all the borrowed and life-time erased pseudo-references are gone. This is done by reference counting and signal/wait on a mutex. Let me just show you for now how this can be used: trait IntoSendBorrow { unsafe fn into_sendable(self) -> Out; fn sendable(self, func:|Out|->U) -> U { ... } } fn partition_inplace<'a>(s: &'a mut[int]) -> (&'a mut[int],&'a mut[int]) { ... } fn main() { let mut vec = Vec::from_fn(10,|u|-(u as int)); partition_inplace(vec.as_mut_slice()).sendable(|(left,right)|{ // Here, left and right are "sendable slices": SendMutSlice // A "sendable reference" internally refers to a reference counter // stored in a mutex and increases/decreases it on clone/drop. // If the counter reaches zero, it will send a signal. spawn(proc() { let mut left = left; // needed for unique borrowing left.as_mut_slice().sort(); }); let mut right = right; // needed for unique borrowing right.as_mut_slice().sort(); }); // <-- in case the reference counter is not null, sendable waits // for the signal and blocks until until it reaches zero. // This is done within a destructor of a function-local object // that carries the reference counter as a member. for i in vec.iter() { println!("{}", i) } } IntoSendBorrow is simply implemented for all reference-like things (&T, &mut T, &[T], &mut[T] and tuples of these). I'm planning on putting the whole source code online on github. Feel free to comment -- especially if you find this useful. :) One thing I learned is that it does not seem to be possible to emulate the behaviour of mutable references and mutable slices perfectly in the sense that they could be uniquely borrowed without being mutable. I think, I would have to write something like this: impl SendMutSlice { ... fn get<'a>(&'a uniq self, index: uint) -> &'a mut T ... } where self is only uniquely borrowed but does not have to be mutable. At least a unique borrow is needed to avoid returning mutable aliases. Since this is not possible right now, I have to put a "mut" there instead and that's why I need the lines let mut left = left; let mut right = right; in the above example. Cheers! sg From jhaberman at gmail.com Fri Jul 18 09:52:25 2014 From: jhaberman at gmail.com (Josh Haberman) Date: Fri, 18 Jul 2014 09:52:25 -0700 Subject: [rust-dev] compiling Rust to C? In-Reply-To: References: Message-ID: On Fri, Jul 18, 2014 at 12:35 AM, Cameron Zwarich wrote: > The biggest problem would be probably be handling stack > unwinding (IIRC the LLVM C backend never tried to handle > this either). Interesting, I can see what that would be a challenge. > The only option when targeting C is to use > setjmp / longjmp, but that is going to be pretty inefficient. Why do you think of setjmp/longjmp as inefficient? If you use the _setjmp/_longjmp variants that don't fiddle with the signal mask, they seem pretty efficient to me. The bigger problem with setjmp/longjmp to me is that they don't let you clean up variables sitting on the stack, as Rust language semantics do I believe? I can think of a way to do this portably, but it costs two extra pointers every time you declare any stack variables. Basically you could, every time you declare local variables, make them part of a struct that has a pointer to the enclosing local var struct, and a pointer to an unwind function. Then when a task fails, traverse this list of frames and run the unwind function for each one before calling longjmp(). It's wasteful of stack space (since this is basically duplicating unwind info that exists at the system level, like in .eh_frame), but it is portable. In any case, it sounds like no one is working on this, so it's probably unlikely to happen unless someone takes it up. Thanks for the info! Josh From zwarich at mozilla.com Fri Jul 18 10:14:22 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Fri, 18 Jul 2014 10:14:22 -0700 Subject: [rust-dev] compiling Rust to C? In-Reply-To: References: Message-ID: <7516D768-02E5-4484-A1E4-9B85FF27E776@mozilla.com> On Jul 18, 2014, at 9:52 AM, Josh Haberman wrote: > >> The only option when targeting C is to use >> setjmp / longjmp, but that is going to be pretty inefficient. > > Why do you think of setjmp/longjmp as inefficient? If you use the > _setjmp/_longjmp variants that don't fiddle with the signal mask, they > seem pretty efficient to me. > > The bigger problem with setjmp/longjmp to me is that they don't let > you clean up variables sitting on the stack, as Rust language > semantics do I believe? > > I can think of a way to do this portably, but it costs two extra > pointers every time you declare any stack variables. Basically you > could, every time you declare local variables, make them part of a > struct that has a pointer to the enclosing local var struct, and a > pointer to an unwind function. Then when a task fails, traverse this > list of frames and run the unwind function for each one before calling > longjmp(). > > It's wasteful of stack space (since this is basically duplicating > unwind info that exists at the system level, like in .eh_frame), but > it is portable. This is more along the lines of what I meant. The 32-bit ARM Darwin ABI actually uses this form of exception handling, and LLVM has some support for it. Unlike DWARF unwinding you incur a cost for every cleanup that you register, so it can be quite expensive. Having had to debug issues with it in the past in LLVM, I'm not sure I would really trust the codegen to be correct. Cameron From echristo at gmail.com Fri Jul 18 10:31:09 2014 From: echristo at gmail.com (Eric Christopher) Date: Fri, 18 Jul 2014 10:31:09 -0700 Subject: [rust-dev] compiling Rust to C? In-Reply-To: References: Message-ID: On Fri, Jul 18, 2014 at 12:29 AM, Josh Haberman wrote: > Is there any prospect of compiling Rust to C anytime in the mid to near future? > > This would be a really attractive option for anyone who wants to write > in Rust, but wants the extreme portability of C. > > Actually maybe I should first ask if this is actually a tractable > problem. Are there technical reasons that would prevent compiling Rust > into portable C? > > LLVM's C Backend seems to have fallen out of maintenance -- would this > provide the solution I am looking for, if it were maintained? > FWIW I removed the C Backend a few years ago because it was largely unmaintained. It would likely need to be rewritten from scratch to do this. If you're curious about it, let me know. -eric From g5pw at macports.org Fri Jul 18 15:43:56 2014 From: g5pw at macports.org (=?utf-8?Q?Alja=C5=BE_Srebrni=C4=8D?=) Date: Sat, 19 Jul 2014 00:43:56 +0200 Subject: [rust-dev] Rust universal build issues In-Reply-To: <53C8110C.90509@mozilla.com> References: <052B97C5-0002-46F2-B580-C6373AA241B5@macports.org> <53C8110C.90509@mozilla.com> Message-ID: On 17/lug/2014, at 20:08, Brian Anderson wrote: > Thanks for your work on MacPorts. Did you use any flags to configure or arguments to make? What version of OS X, clang/gcc? Yes, sorry, I?m building this on OS X 10.9.4 with system clang (5.1). After further inspection, I can build it with target and host set to x86_64-apple-darwin, but when I try to add i686-apple-darwin to the target list, the build fails. Is compiling for 32 bit on 64 bit host still supported? > > On 07/17/2014 01:17 AM, Alja? Srebrni? wrote: >> Hello list, >> I?m ono of the maintainers of rust on MacPorts, and I found some issues with the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a comment on line 135: >> >> # Forcibly strip off any -arch, as that totally breaks our universal support. >> >> Now, it looks like that script strips any -arch flags and adds -arch flags for *all* the supported architectures by the host compiler. As a result, some of the files are compiled as x86_64 only (the original arch flags) and some as a fat binary (i386 and x86_64). In stage3, linking fails: > > I don't believe the build system is supposed to build stage3 on OS X. Seems suspicious. I could be wrong about the stage number, I just inferred because the stage3 directory had no files in it. > >> >> [?] >> error: ar 'x' '/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a' failed with: exit code: 1 >> note: stdout --- >> >> note: stderr --- >> ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it) >> ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a: Inappropriate file type or format >> [?] >> >> I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set RC_SUPPORTED_ARCHS=?x86_64?, but to no avail. How can I instruct compiler-rt to build for my architecture only? >> >> Thanks, >> Alja? >> >> -- >> Alja? Srebrni? a.k.a g5pw >> My public key: http://bit.ly/g5pw_pubkey >> >> _______________________________________________ >> 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 -- Alja? Srebrni? a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey From banderson at mozilla.com Fri Jul 18 15:57:06 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 18 Jul 2014 15:57:06 -0700 Subject: [rust-dev] Rust universal build issues In-Reply-To: References: <052B97C5-0002-46F2-B580-C6373AA241B5@macports.org> <53C8110C.90509@mozilla.com> Message-ID: <53C9A642.7020206@mozilla.com> On 07/18/2014 03:43 PM, Alja? Srebrni? wrote: > On 17/lug/2014, at 20:08, Brian Anderson wrote: > >> Thanks for your work on MacPorts. Did you use any flags to configure or arguments to make? What version of OS X, clang/gcc? > Yes, sorry, I?m building this on OS X 10.9.4 with system clang (5.1). After further inspection, I can build it with target and host set to x86_64-apple-darwin, but when I try to add i686-apple-darwin to the target list, the build fails. Is compiling for 32 bit on 64 bit host still supported? Yes, it should work. I suspect there is some interaction with your (relatively new) toolchain that nobody has seen before. > >> On 07/17/2014 01:17 AM, Alja? Srebrni? wrote: >>> Hello list, >>> I?m ono of the maintainers of rust on MacPorts, and I found some issues with the build. The script in src/compiler-rt/make/platform/clang_darwin.mk has a comment on line 135: >>> >>> # Forcibly strip off any -arch, as that totally breaks our universal support. >>> >>> Now, it looks like that script strips any -arch flags and adds -arch flags for *all* the supported architectures by the host compiler. As a result, some of the files are compiled as x86_64 only (the original arch flags) and some as a fat binary (i386 and x86_64). In stage3, linking fails: >> I don't believe the build system is supposed to build stage3 on OS X. Seems suspicious. > I could be wrong about the stage number, I just inferred because the stage3 directory had no files in it. > >>> [?] >>> error: ar 'x' '/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a' failed with: exit code: 1 >>> note: stdout --- >>> >>> note: stderr --- >>> ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it) >>> ar: /opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_dports_lang_rust/rust/work/rust-0.11.0/i686-apple-darwin/rt/libjemalloc.a: Inappropriate file type or format >>> [?] >>> >>> I saw a env variable, $RC_SUPPORTED_ARCHS and tried to set RC_SUPPORTED_ARCHS=?x86_64?, but to no avail. How can I instruct compiler-rt to build for my architecture only? >>> >>> Thanks, >>> Alja? >>> >>> -- >>> Alja? Srebrni? a.k.a g5pw >>> My public key: http://bit.ly/g5pw_pubkey >>> >>> _______________________________________________ >>> 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 > > -- > Alja? Srebrni? a.k.a g5pw > My public key: http://bit.ly/g5pw_pubkey > From rlatham at gmail.com Sun Jul 20 07:35:10 2014 From: rlatham at gmail.com (Rob Latham) Date: Sun, 20 Jul 2014 09:35:10 -0500 Subject: [rust-dev] adding a new cross-compile target Message-ID: I probably picked the exact wrong project for diving into rust, but I'd like to teach rust how to build powerpc64-bgq-linux binaries. I've got a powerpc64-bgq-linux toolchain. I added this stanza to mk/platforms.mk, but cribbed from other platforms. Did I leave out any important settings? % git diff diff --git a/mk/platform.mk b/mk/platform.mk index d1ec7c65..f1272eaa 100644 --- a/mk/platform.mk +++ b/mk/platform.mk @@ -580,6 +580,19 @@ CFG_LDPATH_x86_64-unknown-freebsd := CFG_RUN_x86_64-unknown-freebsd=$(2) CFG_RUN_TARG_x86_64-unknown-freebsd=$(call CFG_RUN_x86_64-unknown-freebsd,,$(2)) +# powerpc64-bgq-linux configuration +CC_powerpc64-bgq-linux=powerpc64-bgq-linux-gcc +CXX_powerpc64-bgq-linux=powerpc64-bgq-linux-g++ +CPP_powerpc64-bgq-linux=powerpc64-bgq-linux-cpp +AR_powerpc64-bgq-linux=powerpc64-bgq-linux-ar +CFG_LIB_NAME_powerpc64-bgq-linux=libs$(1).so +CFG_STATIC_LIB_NAME_powerpc64-bgq-linux=libs$(1).a +CFG_LIB_GLOB_powerpc64-bgq-linux=lib$(1)-*.so +CFG_CFLAGS_powerpc64-bgq-linux := $(CFLAGS) +CFG_GCCISH_CFLAGS_powerpc64-bgq-linux := -Wall -Werror -g -fPIC $(CFLAGS) +CFG_UNIXY_powerpc64-bgq-linux := 1 +CFG_RUN_powerpc64-bgq-linux = +CFG_RUN_TARG_powerpc64-bgq-linux = I can configure ok: ../configure --target=powerpc64-bgq-linux --prefix=/sandbox/robl/rust-master But build progresses pretty far, hanging up here: [...] rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libfourcc rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhexfloat rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex_macros make: *** No rule to make target `powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by `powerpc64-bgq-linux/rt/libsmorestack.a'. Stop. I don't know how to go about debugging this. Any ideas? thanks ==rob From errordeveloper at gmail.com Sun Jul 20 07:56:49 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Sun, 20 Jul 2014 15:56:49 +0100 Subject: [rust-dev] adding a new cross-compile target In-Reply-To: References: Message-ID: Hi Rob! It's probably best to way until porting had been simplified. Here is a ongoing discussion of this matter: https://github.com/rust-lang/rfcs/pull/131 Cheers, -- Ilya On 20 Jul 2014 15:35, "Rob Latham" wrote: > I probably picked the exact wrong project for diving into rust, but > I'd like to teach rust how to build powerpc64-bgq-linux binaries. > > I've got a powerpc64-bgq-linux toolchain. I added this stanza to > mk/platforms.mk, but cribbed from other platforms. Did I leave out > any important settings? > > % git diff > diff --git a/mk/platform.mk b/mk/platform.mk > index d1ec7c65..f1272eaa 100644 > --- a/mk/platform.mk > +++ b/mk/platform.mk > @@ -580,6 +580,19 @@ CFG_LDPATH_x86_64-unknown-freebsd := > CFG_RUN_x86_64-unknown-freebsd=$(2) > CFG_RUN_TARG_x86_64-unknown-freebsd=$(call > CFG_RUN_x86_64-unknown-freebsd,,$(2)) > > +# powerpc64-bgq-linux configuration > +CC_powerpc64-bgq-linux=powerpc64-bgq-linux-gcc > +CXX_powerpc64-bgq-linux=powerpc64-bgq-linux-g++ > +CPP_powerpc64-bgq-linux=powerpc64-bgq-linux-cpp > +AR_powerpc64-bgq-linux=powerpc64-bgq-linux-ar > +CFG_LIB_NAME_powerpc64-bgq-linux=libs$(1).so > +CFG_STATIC_LIB_NAME_powerpc64-bgq-linux=libs$(1).a > +CFG_LIB_GLOB_powerpc64-bgq-linux=lib$(1)-*.so > +CFG_CFLAGS_powerpc64-bgq-linux := $(CFLAGS) > +CFG_GCCISH_CFLAGS_powerpc64-bgq-linux := -Wall -Werror -g -fPIC $(CFLAGS) > +CFG_UNIXY_powerpc64-bgq-linux := 1 > +CFG_RUN_powerpc64-bgq-linux = > +CFG_RUN_TARG_powerpc64-bgq-linux = > > I can configure ok: > > ../configure --target=powerpc64-bgq-linux > --prefix=/sandbox/robl/rust-master > > But build progresses pretty far, hanging up here: > > [...] > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libfourcc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhexfloat > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex_macros > make: *** No rule to make target > `powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by > `powerpc64-bgq-linux/rt/libsmorestack.a'. Stop. > > I don't know how to go about debugging this. Any ideas? > > thanks > ==rob > _______________________________________________ > 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 valerii.hiora at gmail.com Sun Jul 20 12:59:47 2014 From: valerii.hiora at gmail.com (Valerii Hiora) Date: Sun, 20 Jul 2014 22:59:47 +0300 Subject: [rust-dev] adding a new cross-compile target In-Reply-To: References: Message-ID: <53CC1FB3.9040008@gmail.com> Hi Rob, > make: *** No rule to make target > `powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by > `powerpc64-bgq-linux/rt/libsmorestack.a'. Stop. > > I don't know how to go about debugging this. Any ideas? There is no way to "debug" this - you have to implement a couple of functions which are required by Rust runtime and are architecture-dependent. They live in src/rt/arch/$ARCH_NAME$ Functions (files) are: morestack (morestack.S) - it is a vestige from segmented stack time. Back then it allocated a new stack segment once were wasn't enough space in the current one. Nowadays it just calls rust_stack_exhausted function. record_sp_limit (record_sp.S) - should store stack limit for current task (usually it uses platform specific thread local storage). get_sp_limit (record_sp.S) - should return stack limit for current task (reads from the same platform-specific thread local storage) rust_swap_registers (_context.S) - I'm not sure about this one, but I assume it allows correct register restoration in case of green task switches. rust_bootstrap_green_task (_context.S) - again, not sure, but I assume it initializes green task. Note, that all stack-related functions (morestack, record_sp_limit, get_sp_limit) should be actually compatible with LLVM segmented stack prologue (in your case consult $LLVM/lib/target/PowerPC/PPCFrameLowering.cpp, emitPrologue and emitEpilogue methods, may be a couple of others). For a reference implementations (and much more additional comments) see src/rt/arch/i386/*.S -- Valerii -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From glaebhoerl at gmail.com Sun Jul 20 15:27:06 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Mon, 21 Jul 2014 00:27:06 +0200 Subject: [rust-dev] Next week's older RFCs In-Reply-To: References: Message-ID: On Sun, Jul 13, 2014 at 10:37 PM, Nick Cameron wrote: > Yes, this is the right place for meta-discussion. > > I'll make sure to be stricter about commenting on the PRs in the future. > The aim of this email is only to summarise the discussion so far, it > shouldn't add new opinions or comments beyond applying our 'rules' for > accepting PRs in the most uncontroversial manner. Obviously that is kind of > a fuzzy statement, but I think you are right that here I didn't quite stick > to that. Sorry. > Yes, this sounds sensible to me. Thanks for explaining. > > In general, I agree with your last point, but it takes considerable time > and energy to have an active role and that is in limited supply, so it is > always a trade off on whether any particular person gets involved with a > particular RFC. Having said that, the vast majority of the discussion for > an RFC should always be happening on the RFC. > > I can really, really sympathize with the limited time and energy problem, because I have it as well. Following that line of thought, we should consider the fact that most contributors have even less time and energy, and aren't compensated for it. As such, any steps, even incremental, in the direction of a more engaged and collaborative process, as opposed to just an ultimate accept/postpone/reject decision, would be very much appreciated. Cheers > > Cheers, Nick > > > On Mon, Jul 14, 2014 at 2:29 AM, G?bor Lehel wrote: > >> On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: >> >>> https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce >>> universal quantification - glaebhoerl >>> Use `for` rather than `<...>` syntax for type-parametric items. >>> Not much feedback, some discussion. >>> Recommend close - we're not up for changing the syntax of Rust in >>> such a fundamental way at this stage and want to keep with the >>> curly-brace-language heritage. >>> >> >> (Thank you for sending these e-mails. I've responded to the substantive >> aspects of this at the PR, as requested, but for the "meta" aspects >> pertaining to process, I hope that replying to the e-mail is acceptable.) >> >> If I may file a small protest: It feels wrong to me that the first time I >> hear of this concern is in a recommendation to the meeting group to close >> the PR because of it. (Which is not to mention that it's based on a basic >> misunderstanding of the proposal.) Would it be possible to always raise a >> particular concern in the comments on a PR before using it as justification >> to close, or recommend closing, that PR? >> >> (In general, I think it would be beneficial if the people who get to >> decide the fate of PRs took a more active role in discussing and shaping >> them, instead of staying aloof before handing down an opinion at some >> point.) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Sun Jul 20 18:29:14 2014 From: diwic at ubuntu.com (David Henningsson) Date: Mon, 21 Jul 2014 03:29:14 +0200 Subject: [rust-dev] Mutable files Message-ID: <53CC6CEA.5070100@ubuntu.com> Hi, Consider these two examples: 1) let mut file = File::open(filename); file.read(buf); 2) let file = File::open(filename); let mut reader = BufferedReader::new(file); reader.read(buf); My question is: in example 2, why doesn't BufferedReader need "file" to be mutable? After all, BufferedReader ends up calling file.read(), which needs a mutable reference to the file. It looks like I'm able to "bypass" the mutability requirement, just because I wrap the file inside a BufferedReader? // David From pcwalton at mozilla.com Sun Jul 20 18:33:31 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Jul 2014 18:33:31 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC6CEA.5070100@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> Message-ID: <53CC6DEB.40508@mozilla.com> On 7/20/14 6:29 PM, David Henningsson wrote: > Hi, > > Consider these two examples: > > 1) > > let mut file = File::open(filename); > file.read(buf); > > 2) > > let file = File::open(filename); > let mut reader = BufferedReader::new(file); > reader.read(buf); > > My question is: in example 2, why doesn't BufferedReader need "file" to > be mutable? After all, BufferedReader ends up calling file.read(), which > needs a mutable reference to the file. > > It looks like I'm able to "bypass" the mutability requirement, just > because I wrap the file inside a BufferedReader? Because `BufferedReader::new` moves `file` and takes ownership of it. (You can see this if you try to use `file` again: the compiler will prevent you.) Mutability is inherited through ownership in Rust: that is, the current owner determines the mutability of a piece of data. So, the mutability of `reader` determines the mutability of the `File` object at the time you try to read, and the mutability restriction is satisfied. Patrick From corey at octayn.net Sun Jul 20 18:34:05 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 20 Jul 2014 18:34:05 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC6CEA.5070100@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> Message-ID: That's right. `BufferedReader` takes the `Reader` it wraps by-value, but the `read` method takes `&mut self`. Moving something doesn't require it to be stored in a mutable variable, but taking a `&mut` to it does. On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson wrote: > Hi, > > Consider these two examples: > > 1) > > let mut file = File::open(filename); > file.read(buf); > > 2) > > let file = File::open(filename); > let mut reader = BufferedReader::new(file); > reader.read(buf); > > My question is: in example 2, why doesn't BufferedReader need "file" to be > mutable? After all, BufferedReader ends up calling file.read(), which needs > a mutable reference to the file. > > It looks like I'm able to "bypass" the mutability requirement, just because > I wrap the file inside a BufferedReader? > > // David > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From diwic at ubuntu.com Sun Jul 20 19:39:35 2014 From: diwic at ubuntu.com (David Henningsson) Date: Mon, 21 Jul 2014 04:39:35 +0200 Subject: [rust-dev] Mutable files In-Reply-To: <53CC6DEB.40508@mozilla.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> Message-ID: <53CC7D67.6050400@ubuntu.com> On 2014-07-21 03:33, Patrick Walton wrote: > On 7/20/14 6:29 PM, David Henningsson wrote: >> Hi, >> >> Consider these two examples: >> >> 1) >> >> let mut file = File::open(filename); >> file.read(buf); >> >> 2) >> >> let file = File::open(filename); >> let mut reader = BufferedReader::new(file); >> reader.read(buf); >> >> My question is: in example 2, why doesn't BufferedReader need "file" to >> be mutable? After all, BufferedReader ends up calling file.read(), which >> needs a mutable reference to the file. >> >> It looks like I'm able to "bypass" the mutability requirement, just >> because I wrap the file inside a BufferedReader? > > Because `BufferedReader::new` moves `file` and takes ownership of it. > (You can see this if you try to use `file` again: the compiler will > prevent you.) Mutability is inherited through ownership in Rust: that > is, the current owner determines the mutability of a piece of data. So, > the mutability of `reader` determines the mutability of the `File` > object at the time you try to read, and the mutability restriction is > satisfied. Thanks for the quick answer! I did two more examples to try to understand when things are moved: 3) struct Dummy { foo: int, bar: int } let f = Dummy {foo: 10, bar: 5}; let mut g = f; // Here the assignment copies..? println!("{}", f.foo + g.foo); // Ok 4) let f = File::open(filename); let mut g = f; // Here the assignment moves..? f.tell(); // Fails - use of moved value How come that the assignment moves in example 4), and copies in example 3)? // David From pwalton at mozilla.com Sun Jul 20 19:43:17 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Jul 2014 19:43:17 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC7D67.6050400@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> Message-ID: Because Foo is a POD type (implements the Copy trait). Essentially, types that can be copied by copying bits only (not allocating) are POD types, and all others move. This may be changed with the Opt-In Built-in Traits proposal so that POD types must be specially declared to implement Copy before they will copy. Patrick On July 20, 2014 7:39:35 PM PDT, David Henningsson wrote: > > >On 2014-07-21 03:33, Patrick Walton wrote: >> On 7/20/14 6:29 PM, David Henningsson wrote: >>> Hi, >>> >>> Consider these two examples: >>> >>> 1) >>> >>> let mut file = File::open(filename); >>> file.read(buf); >>> >>> 2) >>> >>> let file = File::open(filename); >>> let mut reader = BufferedReader::new(file); >>> reader.read(buf); >>> >>> My question is: in example 2, why doesn't BufferedReader need "file" >to >>> be mutable? After all, BufferedReader ends up calling file.read(), >which >>> needs a mutable reference to the file. >>> >>> It looks like I'm able to "bypass" the mutability requirement, just >>> because I wrap the file inside a BufferedReader? >> >> Because `BufferedReader::new` moves `file` and takes ownership of it. >> (You can see this if you try to use `file` again: the compiler will >> prevent you.) Mutability is inherited through ownership in Rust: that >> is, the current owner determines the mutability of a piece of data. >So, >> the mutability of `reader` determines the mutability of the `File` >> object at the time you try to read, and the mutability restriction is >> satisfied. > >Thanks for the quick answer! > >I did two more examples to try to understand when things are moved: > >3) >struct Dummy { > foo: int, > bar: int >} > >let f = Dummy {foo: 10, bar: 5}; >let mut g = f; // Here the assignment copies..? >println!("{}", f.foo + g.foo); // Ok > >4) > >let f = File::open(filename); >let mut g = f; // Here the assignment moves..? >f.tell(); // Fails - use of moved value > >How come that the assignment moves in example 4), and copies in example >3)? > >// David -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Sun Jul 20 19:43:13 2014 From: sfackler at gmail.com (Steven Fackler) Date: Sun, 20 Jul 2014 19:43:13 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC7D67.6050400@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> Message-ID: Some types are implicitly copyable. They implement the built-in trait Copy. A type is Copy if it is a) numeric primitive (e.g. f32 or uint), or b) an immutable reference (e.g. &Foo or &str), or c) a raw pointer (e.g. *const Foo or *mut Foo), or d) a collection of Copy types (e.g. struct Foo { a: int, b: &'static str }). In addition, if a type implements Drop, it is no longer Copy. Steven Fackler On Sun, Jul 20, 2014 at 7:39 PM, David Henningsson wrote: > > > On 2014-07-21 03:33, Patrick Walton wrote: > >> On 7/20/14 6:29 PM, David Henningsson wrote: >> >>> Hi, >>> >>> Consider these two examples: >>> >>> 1) >>> >>> let mut file = File::open(filename); >>> file.read(buf); >>> >>> 2) >>> >>> let file = File::open(filename); >>> let mut reader = BufferedReader::new(file); >>> reader.read(buf); >>> >>> My question is: in example 2, why doesn't BufferedReader need "file" to >>> be mutable? After all, BufferedReader ends up calling file.read(), which >>> needs a mutable reference to the file. >>> >>> It looks like I'm able to "bypass" the mutability requirement, just >>> because I wrap the file inside a BufferedReader? >>> >> >> Because `BufferedReader::new` moves `file` and takes ownership of it. >> (You can see this if you try to use `file` again: the compiler will >> prevent you.) Mutability is inherited through ownership in Rust: that >> is, the current owner determines the mutability of a piece of data. So, >> the mutability of `reader` determines the mutability of the `File` >> object at the time you try to read, and the mutability restriction is >> satisfied. >> > > Thanks for the quick answer! > > I did two more examples to try to understand when things are moved: > > 3) > struct Dummy { > foo: int, > bar: int > } > > let f = Dummy {foo: 10, bar: 5}; > let mut g = f; // Here the assignment copies..? > println!("{}", f.foo + g.foo); // Ok > > 4) > > let f = File::open(filename); > let mut g = f; // Here the assignment moves..? > f.tell(); // Fails - use of moved value > > How come that the assignment moves in example 4), and copies in example 3)? > > // David > > _______________________________________________ > 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 diwic at ubuntu.com Sun Jul 20 20:12:37 2014 From: diwic at ubuntu.com (David Henningsson) Date: Mon, 21 Jul 2014 05:12:37 +0200 Subject: [rust-dev] Mutable files In-Reply-To: References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> Message-ID: <53CC8525.7030008@ubuntu.com> On 2014-07-21 04:43, Steven Fackler wrote: > Some types are implicitly copyable. They implement the built-in trait > Copy. A type is Copy if it is > > a) numeric primitive (e.g. f32 or uint), or > b) an immutable reference (e.g. &Foo or &str), or > c) a raw pointer (e.g. *const Foo or *mut Foo), or > d) a collection of Copy types (e.g. struct Foo { a: int, b: &'static str }). > > In addition, if a type implements Drop, it is no longer Copy. > > Steven Fackler Cool, thanks for the answer. These restrictions seem somewhat complex. This wasn't very intuitive for me, so just throwing this out (feel free to ignore if it has already been discussed :-) ) From a language design perspective, maybe it would be more intuitive to have different syntaxes for copy and move, like: let mut g = f; /* Copies from f to g, error if f is a non-Copy type */ let mut g <- f; /* Moves from f to g, error if trying to use f afterwards */ Or in the File/BufferedReader example, this would be something like: let f = File::open(filename); let mut reader = BufferedReader::new(<- f); /* Bye bye f! */ I'm also afraid that if a library struct decides to change between a copy and non-copy type, this would cause subtle errors in users of that library that expected the other type. But if the compiler is guaranteed to catch all such errors even with today's handling, maybe that is not too much to worry about. > > > On Sun, Jul 20, 2014 at 7:39 PM, David Henningsson > wrote: > > > > On 2014-07-21 03:33, Patrick Walton wrote: > > On 7/20/14 6:29 PM, David Henningsson wrote: > > Hi, > > Consider these two examples: > > 1) > > let mut file = File::open(filename); > file.read(buf); > > 2) > > let file = File::open(filename); > let mut reader = BufferedReader::new(file); > reader.read(buf); > > My question is: in example 2, why doesn't BufferedReader > need "file" to > be mutable? After all, BufferedReader ends up calling > file.read(), which > needs a mutable reference to the file. > > It looks like I'm able to "bypass" the mutability > requirement, just > because I wrap the file inside a BufferedReader? > > > Because `BufferedReader::new` moves `file` and takes ownership > of it. > (You can see this if you try to use `file` again: the compiler will > prevent you.) Mutability is inherited through ownership in Rust: > that > is, the current owner determines the mutability of a piece of > data. So, > the mutability of `reader` determines the mutability of the `File` > object at the time you try to read, and the mutability > restriction is > satisfied. > > > Thanks for the quick answer! > > I did two more examples to try to understand when things are moved: > > 3) > struct Dummy { > foo: int, > bar: int > } > > let f = Dummy {foo: 10, bar: 5}; > let mut g = f; // Here the assignment copies..? > println!("{}", f.foo + g.foo); // Ok > > 4) > > let f = File::open(filename); > let mut g = f; // Here the assignment moves..? > f.tell(); // Fails - use of moved value > > How come that the assignment moves in example 4), and copies in > example 3)? > > // David > > _________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/__listinfo/rust-dev > > > From pcwalton at mozilla.com Sun Jul 20 21:04:56 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Jul 2014 21:04:56 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC8525.7030008@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> Message-ID: <53CC9168.4010601@mozilla.com> On 7/20/14 8:12 PM, David Henningsson wrote: > Cool, thanks for the answer. These restrictions seem somewhat complex. They are required. Otherwise we would end up with a C++-like situation where copies end up happening too frequently. > This wasn't very intuitive for me, so just throwing this out (feel free > to ignore if it has already been discussed :-) ) > > From a language design perspective, maybe it would be more intuitive to > have different syntaxes for copy and move, like: There used to be a unary move operator. This was a huge pain. match move x { Some(move y) => foo(move z); } And so on. I don't want to go back to that world. Patrick From pcwalton at mozilla.com Sun Jul 20 21:06:13 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Jul 2014 21:06:13 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CC9168.4010601@mozilla.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> Message-ID: <53CC91B5.2030300@mozilla.com> On 7/20/14 9:04 PM, Patrick Walton wrote: > On 7/20/14 8:12 PM, David Henningsson wrote: >> Cool, thanks for the answer. These restrictions seem somewhat complex. > > They are required. Otherwise we would end up with a C++-like situation > where copies end up happening too frequently. Also note that these rules, far from being "complex", end up making the language much simpler than C++, as copy (or D-like postblit) constructors are not required. All Rust types, if they are copyable at all, can be copied by simply moving bits around. Patrick From diwic at ubuntu.com Mon Jul 21 02:26:10 2014 From: diwic at ubuntu.com (David Henningsson) Date: Mon, 21 Jul 2014 11:26:10 +0200 Subject: [rust-dev] Mutable files In-Reply-To: <53CC91B5.2030300@mozilla.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <53CC91B5.2030300@mozilla.com> Message-ID: <53CCDCB2.2050806@ubuntu.com> On 2014-07-21 06:06, Patrick Walton wrote: > On 7/20/14 9:04 PM, Patrick Walton wrote: >> On 7/20/14 8:12 PM, David Henningsson wrote: >>> Cool, thanks for the answer. These restrictions seem somewhat complex. >> >> They are required. Otherwise we would end up with a C++-like situation >> where copies end up happening too frequently. > > Also note that these rules, far from being "complex", end up making the > language much simpler than C++, as copy (or D-like postblit) > constructors are not required. All Rust types, if they are copyable at > all, can be copied by simply moving bits around. Fair enough. I just guess it takes a while getting used to, that you sometimes can't use a variable after you've sent it as a parameter to a function. Also now having read the RFC for "Opt-in builtin traits" which you mentioned earlier, I think this RFC makes a lot of sense. Especially the "API Stability" and "Pedagogy" points would have been helpful here. // David From troplin at bluewin.ch Mon Jul 21 08:49:56 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Mon, 21 Jul 2014 15:49:56 +0000 (UTC) Subject: [rust-dev] Mutable files References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> Message-ID: <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> Patrick Walton wrote: > On 7/20/14 8:12 PM, David Henningsson wrote: >> From a language design perspective, maybe it would be more intuitive to >> have different syntaxes for copy and move, like: As a rust newbie, that aspect aways makes me a bit nervous. Two quite different operations with the same syntax and and simply changing a detail in the struct can be enough to switch between the two. AFAIK this also was one of the reasons (if not _the_ reason) why std::auto_ptr was deprecated in C++. Tobi From pcwalton at mozilla.com Mon Jul 21 10:17:05 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 21 Jul 2014 10:17:05 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> Message-ID: <53CD4B11.60909@mozilla.com> On 7/21/14 8:49 AM, Tobias M?ller wrote: > Patrick Walton wrote: >> On 7/20/14 8:12 PM, David Henningsson wrote: >>> From a language design perspective, maybe it would be more intuitive to >>> have different syntaxes for copy and move, like: > > As a rust newbie, that aspect aways makes me a bit nervous. Two quite > different operations with the same syntax and and simply changing a detail > in the struct can be enough to switch between the two. This is the reason for Opt-In Built-In Traits. > AFAIK this also was one of the reasons (if not _the_ reason) why > std::auto_ptr was deprecated in C++. No, `auto_ptr` was deprecated because it copies, not moves, making it hard to sensibly use in containers (among other things). Comparisons between C++ aren't really relevant anyway because the compiler catches any use-after-move at *compile time*, rather than at runtime. This means that mistaking the two doesn't cause any harm: * Causing a move when you thought you were copying results in a compiler error. * Causing a copy when you thought you were moving is harmless, as any implicit copy in Rust has *exactly the same runtime semantics* as a move, except that the compiler prevents you from using the value again. Again, we had that world before. It was extremely annoying to write "move" all over the place. Be careful what you wish for. Patrick From troplin at bluewin.ch Mon Jul 21 14:22:58 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Mon, 21 Jul 2014 21:22:58 +0000 (UTC) Subject: [rust-dev] Mutable files References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> Message-ID: <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> Patrick Walton wrote: > On 7/21/14 8:49 AM, Tobias M?ller wrote: >> As a rust newbie, that aspect aways makes me a bit nervous. Two quite >> different operations with the same syntax and and simply changing a detail >> in the struct can be enough to switch between the two. > > This is the reason for Opt-In Built-In Traits. > >> AFAIK this also was one of the reasons (if not _the_ reason) why >> std::auto_ptr was deprecated in C++. > > No, `auto_ptr` was deprecated because it copies, not moves, making it > hard to sensibly use in containers (among other things). Quoting Andrei Alexandrescu on digitalmars.d: -------- We discussed this with Bartosz literally for weeks (him being a fan of auto_ptr for too long, later completely converted against it and I take credit for that :o)). With auto_ptr this was possible: auto_ptr a(new int); auto_ptr b = a; It would nullify a with copy syntax. That code won't compile with unique_ptr; you'd need an explicit move(a). It only got worse from there: passing into functions, member variables... MOVING WITH COPY SYNTAX DOES NOT WORK. It's cut and dried. Andrei --------- But you are right, Rust is not C++, it's actually the other way round that makes me nervous. > Comparisons between C++ aren't really relevant anyway because the > compiler catches any use-after-move at *compile time*, rather than at > runtime. This means that mistaking the two doesn't cause any harm: > > * Causing a move when you thought you were copying results in a compiler > error. > > * Causing a copy when you thought you were moving is harmless, as any > implicit copy in Rust has *exactly the same runtime semantics* as a > move, except that the compiler prevents you from using the value again. >From a performance point of view that may be true, but you may lose desired semantics. If you want an instance of a type to be move-only, but later decide that copying that type is still useful in another place, then you lose the guarantee in the first place. It's just strange that you can change the semantic of an already existing operation just by adding new capabilities. Adding traits should define new operations with new semantics, not changing the semantics of existing operations. At least that's how it works for all other traits, and deviating from that is at least surprising. > Again, we had that world before. It was extremely annoying to write > "move" all over the place. Be careful what you wish for. Maybe the syntax was just too heavy? Tobi From errordeveloper at gmail.com Mon Jul 21 14:28:35 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Mon, 21 Jul 2014 22:28:35 +0100 Subject: [rust-dev] moving out few odd libraries from the main tree Message-ID: It would be great to discuss which libraries can be removed from the main tree, I can see that there had been some progress with liburl [1], but there appear to be a few other very dubious libraries that can easily leave outside of the main tree. The ones I was able to spot so far, would be: - libfourcc - libsemver The main question would be where would these live on github? Should it be under the main (`github.com/rust`) organisation or actually we could consider creating `github.com/rust-libs`? [1]: https://github.com/rust-lang/rust/issues/10707 Cheers, -- Ilya From pcwalton at mozilla.com Mon Jul 21 14:45:26 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 21 Jul 2014 14:45:26 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> Message-ID: <53CD89F6.4050800@mozilla.com> On 7/21/14 2:22 PM, Tobias M?ller wrote: > We discussed this with Bartosz literally for weeks (him being a fan of > auto_ptr for too long, later completely converted against it and I take > credit for that :o)). With auto_ptr this was possible: > > auto_ptr a(new int); > auto_ptr b = a; > > It would nullify a with copy syntax. That code won't compile with > unique_ptr; you'd need an explicit move(a). > > It only got worse from there: passing into functions, member variables... > > MOVING WITH COPY SYNTAX DOES NOT WORK. > > It's cut and dried. ... in C++. Not in Rust. That's because, unlike C++, Rust is designed from the ground up to support moves and copies in a first class way. > It's just strange that you can change the semantic of an already existing > operation just by adding new capabilities. Adding traits should define new > operations with new semantics, not changing the semantics of existing > operations. At least that's how it works for all other traits, and > deviating from that is at least surprising. Hence the Opt-In Built-In Traits proposal > Maybe the syntax was just too heavy? Any syntax at all is too much. I am convinced of that. Patrick From corey at octayn.net Mon Jul 21 14:46:11 2014 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Jul 2014 14:46:11 -0700 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: Message-ID: I believe it has long been the goal that once we have a robust package manager, we would start moving everything we could get away with out of the tree. Cargo is pretty awesome now, and I think we could get away with moving those out, with the caveat that cargo depends on semver.. On Mon, Jul 21, 2014 at 2:28 PM, Ilya Dmitrichenko wrote: > It would be great to discuss which libraries can be removed from the > main tree, I can see that there had been some progress with liburl > [1], but there appear to be a few other very dubious libraries that > can easily leave outside of the main tree. > > The ones I was able to spot so far, would be: > > - libfourcc > - libsemver > > The main question would be where would these live on github? Should it > be under the main (`github.com/rust`) organisation or actually we > could consider creating `github.com/rust-libs`? > > [1]: https://github.com/rust-lang/rust/issues/10707 > > Cheers, > -- > Ilya > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From errordeveloper at gmail.com Mon Jul 21 15:16:05 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Mon, 21 Jul 2014 23:16:05 +0100 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: Message-ID: On 21 July 2014 22:46, Corey Richardson wrote: > Cargo is pretty awesome now, and I think we could get away with moving those out, with the caveat that cargo depends on semver.. It does have a bunch of things as submodules already. I wouldn't find it unreasonable to just make libsemver part of cargo, as I doubt there would be much use for it outside of cargo in the near feature. Any suggestions on where misc libs should live? If someone create repos, I'll be happy to pull these two out and push into a given repo. In regards to CI, I'm not sure if these will really need buildbot+bors, Travis should be pretty sufficient, I think. From banderson at mozilla.com Mon Jul 21 15:20:51 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 21 Jul 2014 15:20:51 -0700 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: Message-ID: <53CD9243.6010900@mozilla.com> Doing this is a goal, but we're going to need a complete strategy - let's please not start doing this too hastily. Maintaining crates out of tree is not easy, and we need to have the systems in place that will let us succeed (particularly around integration). acrichto will need to be involved because he's the most familiar with all the systems this will touch. On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote: > It would be great to discuss which libraries can be removed from the > main tree, I can see that there had been some progress with liburl > [1], but there appear to be a few other very dubious libraries that > can easily leave outside of the main tree. > > The ones I was able to spot so far, would be: > > - libfourcc > - libsemver > > The main question would be where would these live on github? Should it > be under the main (`github.com/rust`) organisation or actually we > could consider creating `github.com/rust-libs`? > > [1]: https://github.com/rust-lang/rust/issues/10707 > > Cheers, From banderson at mozilla.com Mon Jul 21 15:22:10 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 21 Jul 2014 15:22:10 -0700 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: Message-ID: <53CD9292.4030802@mozilla.com> I expect moving crates out of the main tree to be important for reducing build cycle time. On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote: > It would be great to discuss which libraries can be removed from the > main tree, I can see that there had been some progress with liburl > [1], but there appear to be a few other very dubious libraries that > can easily leave outside of the main tree. > > The ones I was able to spot so far, would be: > > - libfourcc > - libsemver > > The main question would be where would these live on github? Should it > be under the main (`github.com/rust`) organisation or actually we > could consider creating `github.com/rust-libs`? > > [1]: https://github.com/rust-lang/rust/issues/10707 > > Cheers, From banderson at mozilla.com Mon Jul 21 15:24:32 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 21 Jul 2014 15:24:32 -0700 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: Message-ID: <53CD9320.2020109@mozilla.com> As to your original question about candidate libs, here are mine: arena fourcc glob graphviz (with some rustc refactoring) hexfloat regex url uuid On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote: > It would be great to discuss which libraries can be removed from the > main tree, I can see that there had been some progress with liburl > [1], but there appear to be a few other very dubious libraries that > can easily leave outside of the main tree. > > The ones I was able to spot so far, would be: > > - libfourcc > - libsemver > > The main question would be where would these live on github? Should it > be under the main (`github.com/rust`) organisation or actually we > could consider creating `github.com/rust-libs`? > > [1]: https://github.com/rust-lang/rust/issues/10707 > > Cheers, From steve at steveklabnik.com Mon Jul 21 16:43:29 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 21 Jul 2014 19:43:29 -0400 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: <53CD9320.2020109@mozilla.com> References: <53CD9320.2020109@mozilla.com> Message-ID: I like the idea of SemVer being in the language itself, personally. From techiezach at gmail.com Mon Jul 21 18:28:20 2014 From: techiezach at gmail.com (Zach Mertes) Date: Mon, 21 Jul 2014 21:28:20 -0400 Subject: [rust-dev] moving out few odd libraries from the main tree In-Reply-To: References: <53CD9320.2020109@mozilla.com> Message-ID: I'd also like to see semver stay in the language. On Jul 21, 2014 7:43 PM, "Steve Klabnik" wrote: I like the idea of SemVer being in the language itself, personally. _______________________________________________ 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 hallimanearavind at gmail.com Tue Jul 22 02:45:08 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Tue, 22 Jul 2014 15:15:08 +0530 Subject: [rust-dev] How to write Generic traits for enums Message-ID: Hi, I am trying to create a generic function to return value depending on the enum passed. But I don't know to create a generic trait for enum. In following example, print_value works but I don't know how I can write a generic get_value function to get value from enum. #[deriving(Show)] enum MyTypes{ MyBool(bool), MyStr(String), MyInt(int) } fn print_value(arg: MyTypes){ match arg{ MyBool(x) => println!("Bool: {}", x), MyStr(x) => println!("String: {}", x), MyInt(x) => println!("Int: {}", x), } } fn main(){ print_value(MyBool(true)); // Following lines not working, how to write get_value func? // let a: bool = get_value(MyBool(true)); // println!("{}", a); } In case of struct it is simple, struct MyInt { value: int } struct MyBool{ value: bool } trait Value{ fn get(&self) -> S; } impl Value for MyInt{ fn get(&self) -> int{ self.value } } impl Value for MyBool{ fn get(&self) -> bool{ self.value } } fn get_value>(arg: T) -> S{ arg.get() } fn main(){ let a: bool = get_value(MyBool{value: true}); println!("{}", a); let b: int = get_value(MyInt{value: 100}); println!("{}", b); } Please help in writing generic function for enum. -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnkfelix at mozilla.com Tue Jul 22 04:25:53 2014 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Tue, 22 Jul 2014 13:25:53 +0200 Subject: [rust-dev] How to write Generic traits for enums In-Reply-To: References: Message-ID: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> Aravinda (cc?ing rust-dev)- You didn?t show us exactly what you had tried to do to get your code to work, nor did you really describe what it is you want here. E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but since `MyBool` belongs to the `MyTypes` enum, that implies that `get_value` when applied to any variant of `MyTypes` (including `MyInt` or `MyStr`) should also return a boolean ? does that seem right to you? In any case, I suspect the missing piece of the puzzle for you is that you need to write an `impl` for the type in question. I.e. something along the lines of: impl MyTypes { fn render(&self) -> String { match *self { MyBool(x) => format!("{:b}", x), MyStr(ref x) => x.clone(), MyInt(x) => format!("{:d}", x), } } } (except revised from an Impl for the type to being an impl of some trait for the type). Here is a link to a playpen with your code, and with a couple of example `impl`s for enums (like the one above) tossed in, including an impl of one instance of your `Value` trait. http://is.gd/RofN9R There is more discussion of writing implementations that also provides an example with a simpler enum) in the Rust tutorial, see: http://doc.rust-lang.org/tutorial.html#methods Cheers, -Felix On 22 Jul 2014, at 11:45, Aravinda VK wrote: > Hi, > > I am trying to create a generic function to return value depending on the enum passed. But I don't know to create a generic trait for enum. > > In following example, print_value works but I don't know how I can write a generic get_value function to get value from enum. > > #[deriving(Show)] > enum MyTypes{ > MyBool(bool), > MyStr(String), > MyInt(int) > } > > fn print_value(arg: MyTypes){ > match arg{ > MyBool(x) => println!("Bool: {}", x), > MyStr(x) => println!("String: {}", x), > MyInt(x) => println!("Int: {}", x), > } > } > > > fn main(){ > print_value(MyBool(true)); > > // Following lines not working, how to write get_value func? > // let a: bool = get_value(MyBool(true)); > // println!("{}", a); > } > > > In case of struct it is simple, > > struct MyInt { > value: int > } > > struct MyBool{ > value: bool > } > > trait Value{ > fn get(&self) -> S; > } > > impl Value for MyInt{ > fn get(&self) -> int{ > self.value > } > } > > impl Value for MyBool{ > fn get(&self) -> bool{ > self.value > } > } > > fn get_value>(arg: T) -> S{ > arg.get() > } > > fn main(){ > let a: bool = get_value(MyBool{value: true}); > println!("{}", a); > > let b: int = get_value(MyInt{value: 100}); > println!("{}", b); > } > > Please help in writing generic function for enum. > > > > -- > Regards > Aravinda | ?????? > http://aravindavk.in > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From hallimanearavind at gmail.com Tue Jul 22 05:24:33 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Tue, 22 Jul 2014 17:54:33 +0530 Subject: [rust-dev] How to write Generic traits for enums In-Reply-To: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> References: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> Message-ID: Sorry for the incomplete mail. What I wanted is, get_value(MyStr("Rust".to_str())) returns String, get_value(MyBool(true)) returns bool and, get_value(MyInt(100)) returns int I was trying to store generic value in hashmap, as in the example below, use std::collections::hashmap::HashMap; #[deriving(Show)] enum MyTypes{ MyBool(bool), MyStr(String), MyInt(int) } fn main(){ let mut settings:HashMap = HashMap::new(); settings.insert("port".to_str(), MyInt(8000)); settings.insert("name".to_str(), MyStr("Rust".to_str())); settings.insert("enabled".to_str(), MyBool(true)); println!("{}", settings); } So to get the value out of hashmap, I need a generic function which checks the respective type and returns value. Some thing like fn get_value(settings:HashMap, key: &'static str) -> T{ match settings.get(&key) { MyBool(x) => x, MyStr(x) => x, MyInt(x) => x } } But I don't know how to make this work. Thanks. On Tue, Jul 22, 2014 at 4:55 PM, Felix S. Klock II wrote: > Aravinda (cc?ing rust-dev)- > > You didn?t show us exactly what you had tried to do to get your code to > work, nor did you really describe what it is you want here. > > E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but > since `MyBool` belongs to the `MyTypes` enum, that implies that `get_value` > when applied to any variant of `MyTypes` (including `MyInt` or `MyStr`) > should also return a boolean ? does that seem right to you? > > In any case, I suspect the missing piece of the puzzle for you is that you > need to write an `impl` for the type in question. I.e. something along the > lines of: > > impl MyTypes { > fn render(&self) -> String { > match *self { > MyBool(x) => format!("{:b}", x), > MyStr(ref x) => x.clone(), > MyInt(x) => format!("{:d}", x), > } > } > } > > (except revised from an Impl for the type to being an impl of some trait > for the type). > > Here is a link to a playpen with your code, and with a couple of example > `impl`s for enums (like the one above) tossed in, including an impl of one > instance of your `Value` trait. > > http://is.gd/RofN9R > > There is more discussion of writing implementations that also provides an > example with a simpler enum) in the Rust tutorial, see: > > http://doc.rust-lang.org/tutorial.html#methods > > Cheers, > -Felix > > On 22 Jul 2014, at 11:45, Aravinda VK wrote: > > > Hi, > > > > I am trying to create a generic function to return value depending on > the enum passed. But I don't know to create a generic trait for enum. > > > > In following example, print_value works but I don't know how I can write > a generic get_value function to get value from enum. > > > > #[deriving(Show)] > > enum MyTypes{ > > MyBool(bool), > > MyStr(String), > > MyInt(int) > > } > > > > fn print_value(arg: MyTypes){ > > match arg{ > > MyBool(x) => println!("Bool: {}", x), > > MyStr(x) => println!("String: {}", x), > > MyInt(x) => println!("Int: {}", x), > > } > > } > > > > > > fn main(){ > > print_value(MyBool(true)); > > > > // Following lines not working, how to write get_value func? > > // let a: bool = get_value(MyBool(true)); > > // println!("{}", a); > > } > > > > > > In case of struct it is simple, > > > > struct MyInt { > > value: int > > } > > > > struct MyBool{ > > value: bool > > } > > > > trait Value{ > > fn get(&self) -> S; > > } > > > > impl Value for MyInt{ > > fn get(&self) -> int{ > > self.value > > } > > } > > > > impl Value for MyBool{ > > fn get(&self) -> bool{ > > self.value > > } > > } > > > > fn get_value>(arg: T) -> S{ > > arg.get() > > } > > > > fn main(){ > > let a: bool = get_value(MyBool{value: true}); > > println!("{}", a); > > > > let b: int = get_value(MyInt{value: 100}); > > println!("{}", b); > > } > > > > Please help in writing generic function for enum. > > > > > > > > -- > > Regards > > Aravinda | ?????? > > http://aravindavk.in > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnkfelix at mozilla.com Tue Jul 22 06:38:03 2014 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Tue, 22 Jul 2014 15:38:03 +0200 Subject: [rust-dev] How to write Generic traits for enums In-Reply-To: References: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> Message-ID: Aravinda (cc?ing rust-dev)- It seems like you are trying to program in Rust as if it were a dynamically-typed language, or one with runtime-type reflection (i.e. like Java). At least, that is my best guess at where your misunderstanding lies. All functions in Rust, even generic ones, need to have their types resolved at compile-time. A generic function can have different concrete types substituted in for its type parameters at different call-sites, but in the end, a particular call-site needs to resolve to a single type at compile-time; the type cannot be left for later resolution at program runtime. In a signature like your: fn get_value(settings:HashMap, key: &'static str) -> T; the particular instance of `MyTypes` that is returned will depend on which `key` is passed in; therefore, the `T` above could only be dynamically determined based on the runtime computation. It inherently cannot be resolved at compile-time, and therefore it is not statically typed. ---- Rust is not alone in offering this kind of generic types; many programming languages use a similar logic for determining types at compile time. It just gets fuzzy if one is used to languages that maintain types at runtime and do not enforce restrictions like the one I outlined above. These type systems are often said to offer ?parametric polymorphism?; I mention that solely to give you some guidance for a term to search for when goggling this subject. (Though I will say up front that a lot of the results you get on this topic can be very academic and language research-oriented.) Here is a tutorial that may help you get a handle on the concepts here: http://lucacardelli.name/Papers/BasicTypechecking.pdf (Yes, it is from 1987. I think that is why it probably one of the better descriptions I was able to find quickly: At that time, these ideas were not as widely popularized as they were today, so Cardelli took his time explaining the notions and assumed little about the audience.) rust-dev members: If others know of freely available introductions to this topic, I?m all ears; I just didn?t see any obvious winners in my searches. Cheers, -Felix On 22 Jul 2014, at 14:24, Aravinda VK wrote: > Sorry for the incomplete mail. > > What I wanted is, > get_value(MyStr("Rust".to_str())) returns String, > get_value(MyBool(true)) returns bool and, > get_value(MyInt(100)) returns int > > I was trying to store generic value in hashmap, as in the example below, > > use std::collections::hashmap::HashMap; > > #[deriving(Show)] > enum MyTypes{ > MyBool(bool), > MyStr(String), > MyInt(int) > } > > fn main(){ > let mut settings:HashMap = HashMap::new(); > > settings.insert("port".to_str(), MyInt(8000)); > settings.insert("name".to_str(), MyStr("Rust".to_str())); > settings.insert("enabled".to_str(), MyBool(true)); > > println!("{}", settings); > } > > So to get the value out of hashmap, I need a generic function which checks the respective type and returns value. Some thing like > > fn get_value(settings:HashMap, key: &'static str) -> T{ > match settings.get(&key) { > MyBool(x) => x, > MyStr(x) => x, > MyInt(x) => x > } > } > > But I don't know how to make this work. > > Thanks. > > > > On Tue, Jul 22, 2014 at 4:55 PM, Felix S. Klock II wrote: > Aravinda (cc?ing rust-dev)- > > You didn?t show us exactly what you had tried to do to get your code to work, nor did you really describe what it is you want here. > > E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but since `MyBool` belongs to the `MyTypes` enum, that implies that `get_value` when applied to any variant of `MyTypes` (including `MyInt` or `MyStr`) should also return a boolean ? does that seem right to you? > > In any case, I suspect the missing piece of the puzzle for you is that you need to write an `impl` for the type in question. I.e. something along the lines of: > > impl MyTypes { > fn render(&self) -> String { > match *self { > MyBool(x) => format!("{:b}", x), > MyStr(ref x) => x.clone(), > MyInt(x) => format!("{:d}", x), > } > } > } > > (except revised from an Impl for the type to being an impl of some trait for the type). > > Here is a link to a playpen with your code, and with a couple of example `impl`s for enums (like the one above) tossed in, including an impl of one instance of your `Value` trait. > > http://is.gd/RofN9R > > There is more discussion of writing implementations that also provides an example with a simpler enum) in the Rust tutorial, see: > > http://doc.rust-lang.org/tutorial.html#methods > > Cheers, > -Felix > > On 22 Jul 2014, at 11:45, Aravinda VK wrote: > > > Hi, > > > > I am trying to create a generic function to return value depending on the enum passed. But I don't know to create a generic trait for enum. > > > > In following example, print_value works but I don't know how I can write a generic get_value function to get value from enum. > > > > #[deriving(Show)] > > enum MyTypes{ > > MyBool(bool), > > MyStr(String), > > MyInt(int) > > } > > > > fn print_value(arg: MyTypes){ > > match arg{ > > MyBool(x) => println!("Bool: {}", x), > > MyStr(x) => println!("String: {}", x), > > MyInt(x) => println!("Int: {}", x), > > } > > } > > > > > > fn main(){ > > print_value(MyBool(true)); > > > > // Following lines not working, how to write get_value func? > > // let a: bool = get_value(MyBool(true)); > > // println!("{}", a); > > } > > > > > > In case of struct it is simple, > > > > struct MyInt { > > value: int > > } > > > > struct MyBool{ > > value: bool > > } > > > > trait Value{ > > fn get(&self) -> S; > > } > > > > impl Value for MyInt{ > > fn get(&self) -> int{ > > self.value > > } > > } > > > > impl Value for MyBool{ > > fn get(&self) -> bool{ > > self.value > > } > > } > > > > fn get_value>(arg: T) -> S{ > > arg.get() > > } > > > > fn main(){ > > let a: bool = get_value(MyBool{value: true}); > > println!("{}", a); > > > > let b: int = get_value(MyInt{value: 100}); > > println!("{}", b); > > } > > > > Please help in writing generic function for enum. > > > > > > > > -- > > Regards > > Aravinda | ?????? > > http://aravindavk.in > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > Regards > Aravinda | ?????? > http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at dhardy.name Tue Jul 22 07:08:02 2014 From: lists at dhardy.name (Diggory Hardy) Date: Tue, 22 Jul 2014 16:08:02 +0200 Subject: [rust-dev] file logger missing? Message-ID: <3090116.OzZ0v8YF0O@tph-l13071> Isn't log:Logger missing some implementations? http://doc.rust-lang.org/log/trait.Logger.html If it's useful I can push my simple file logger to the Rust tree, but I don't know where it should live. Cheers Diggory From steve at steveklabnik.com Tue Jul 22 07:49:59 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 22 Jul 2014 10:49:59 -0400 Subject: [rust-dev] file logger missing? In-Reply-To: <3090116.OzZ0v8YF0O@tph-l13071> References: <3090116.OzZ0v8YF0O@tph-l13071> Message-ID: I think in general, especially now that Cargo exists, we don't really need to add a lot more to the tree. Publish a package for it instead! From lists at dhardy.name Tue Jul 22 08:11:08 2014 From: lists at dhardy.name (Diggory Hardy) Date: Tue, 22 Jul 2014 17:11:08 +0200 Subject: [rust-dev] file logger missing? In-Reply-To: References: <3090116.OzZ0v8YF0O@tph-l13071> Message-ID: <1645645.hs719icifG@tph-l13071> Are you saying that liblog should be moved too? Because I don't see why a complex logging framework should be separated from a simple log-to-file implementation (36 lines in my case, including doc, use statements, etc). On Tuesday 22 Jul 2014 10:49:59 Steve Klabnik wrote: > I think in general, especially now that Cargo exists, we don't really > need to add a lot more to the tree. Publish a package for it instead! From sfackler at gmail.com Tue Jul 22 08:27:47 2014 From: sfackler at gmail.com (Steven Fackler) Date: Tue, 22 Jul 2014 08:27:47 -0700 Subject: [rust-dev] file logger missing? In-Reply-To: <1645645.hs719icifG@tph-l13071> References: <3090116.OzZ0v8YF0O@tph-l13071> <1645645.hs719icifG@tph-l13071> Message-ID: Is a logger that synchronously writes to the filesystem and doesn't offer any type of rotation more useful than redirecting stderr? Steven Fackler On Tue, Jul 22, 2014 at 8:11 AM, Diggory Hardy wrote: > Are you saying that liblog should be moved too? Because I don't see why a > complex logging framework should be separated from a simple log-to-file > implementation (36 lines in my case, including doc, use statements, etc). > > On Tuesday 22 Jul 2014 10:49:59 Steve Klabnik wrote: > > I think in general, especially now that Cargo exists, we don't really > > need to add a lot more to the tree. Publish a package for it instead! > _______________________________________________ > 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 lists at dhardy.name Tue Jul 22 08:38:04 2014 From: lists at dhardy.name (Diggory Hardy) Date: Tue, 22 Jul 2014 17:38:04 +0200 Subject: [rust-dev] file logger missing? In-Reply-To: References: <3090116.OzZ0v8YF0O@tph-l13071> <1645645.hs719icifG@tph-l13071> Message-ID: <9520457.oJBthlaGut@tph-l13071> For some uses, yes. But I guess log rotation should also be a feature. My first point is why is there a seemingly complex logging framework without this? Does it already exist somewhere? On Tuesday 22 Jul 2014 08:27:47 Steven Fackler wrote: > Is a logger that synchronously writes to the filesystem and doesn't offer > any type of rotation more useful than redirecting stderr? > > Steven Fackler > > On Tue, Jul 22, 2014 at 8:11 AM, Diggory Hardy wrote: > > Are you saying that liblog should be moved too? Because I don't see why a > > complex logging framework should be separated from a simple log-to-file > > implementation (36 lines in my case, including doc, use statements, etc). > > > > On Tuesday 22 Jul 2014 10:49:59 Steve Klabnik wrote: > > > I think in general, especially now that Cargo exists, we don't really > > > need to add a lot more to the tree. Publish a package for it instead! > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev From smcarthur at mozilla.com Tue Jul 22 08:42:59 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Tue, 22 Jul 2014 08:42:59 -0700 Subject: [rust-dev] file logger missing? In-Reply-To: <9520457.oJBthlaGut@tph-l13071> References: <3090116.OzZ0v8YF0O@tph-l13071> <1645645.hs719icifG@tph-l13071> <9520457.oJBthlaGut@tph-l13071> Message-ID: It does not exist in tree. So far, liblog has the features used by rustc and stdlib, and naught else. A papercut with liblog is that you need to remember to set_logger inside every task you spawn, which currently just means it's easier to keep the default. On Jul 22, 2014 8:38 AM, "Diggory Hardy" wrote: > For some uses, yes. But I guess log rotation should also be a feature. > > My first point is why is there a seemingly complex logging framework > without > this? Does it already exist somewhere? > > > On Tuesday 22 Jul 2014 08:27:47 Steven Fackler wrote: > > Is a logger that synchronously writes to the filesystem and doesn't offer > > any type of rotation more useful than redirecting stderr? > > > > Steven Fackler > > > > On Tue, Jul 22, 2014 at 8:11 AM, Diggory Hardy > wrote: > > > Are you saying that liblog should be moved too? Because I don't see > why a > > > complex logging framework should be separated from a simple log-to-file > > > implementation (36 lines in my case, including doc, use statements, > etc). > > > > > > On Tuesday 22 Jul 2014 10:49:59 Steve Klabnik wrote: > > > > I think in general, especially now that Cargo exists, we don't really > > > > need to add a lot more to the tree. Publish a package for it instead! > > > > > > _______________________________________________ > > > 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 hallimanearavind at gmail.com Tue Jul 22 09:07:18 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Tue, 22 Jul 2014 21:37:18 +0530 Subject: [rust-dev] How to write Generic traits for enums In-Reply-To: References: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> Message-ID: Hi Felix, Thanks a lot for the detailed explanation. On Tue, Jul 22, 2014 at 7:08 PM, Felix S. Klock II wrote: > Aravinda (cc?ing rust-dev)- > > It seems like you are trying to program in Rust as if it were a > dynamically-typed language, or one with runtime-type reflection (i.e. like > Java). At least, that is my best guess at where your misunderstanding lies. > > All functions in Rust, even generic ones, need to have their types > resolved at compile-time. A generic function can have different concrete > types substituted in for its type parameters at different call-sites, but > in the end, a particular call-site needs to resolve to a single type at > compile-time; the type cannot be left for later resolution at program > runtime. > > In a signature like your: > > fn get_value(settings:HashMap, key: &'static str) -> > T; > > the particular instance of `MyTypes` that is returned will depend on which > `key` is passed in; therefore, the `T` above could only be dynamically > determined based on the runtime computation. It inherently cannot be > resolved at compile-time, and therefore it is not statically typed. > > ---- > > Rust is not alone in offering this kind of generic types; many programming > languages use a similar logic for determining types at compile time. It > just gets fuzzy if one is used to languages that maintain types at runtime > and do not enforce restrictions like the one I outlined above. > > These type systems are often said to offer ?parametric polymorphism?; I > mention that solely to give you some guidance for a term to search for when > goggling this subject. (Though I will say up front that a lot of the > results you get on this topic can be very academic and language > research-oriented.) > > Here is a tutorial that may help you get a handle on the concepts here: > > http://lucacardelli.name/Papers/BasicTypechecking.pdf > > (Yes, it is from 1987. I think that is why it probably one of the better > descriptions I was able to find quickly: At that time, these ideas were not > as widely popularized as they were today, so Cardelli took his time > explaining the notions and assumed little about the audience.) > > rust-dev members: If others know of freely available introductions to this > topic, I?m all ears; I just didn?t see any obvious winners in my searches. > > Cheers, > -Felix > > > On 22 Jul 2014, at 14:24, Aravinda VK wrote: > > Sorry for the incomplete mail. > > What I wanted is, > get_value(MyStr("Rust".to_str())) returns String, > get_value(MyBool(true)) returns bool and, > get_value(MyInt(100)) returns int > > I was trying to store generic value in hashmap, as in the example below, > > use std::collections::hashmap::HashMap; > > #[deriving(Show)] > enum MyTypes{ > MyBool(bool), > MyStr(String), > MyInt(int) > } > > fn main(){ > let mut settings:HashMap = HashMap::new(); > > settings.insert("port".to_str(), MyInt(8000)); > settings.insert("name".to_str(), MyStr("Rust".to_str())); > settings.insert("enabled".to_str(), MyBool(true)); > > println!("{}", settings); > } > > So to get the value out of hashmap, I need a generic function which checks > the respective type and returns value. Some thing like > > fn get_value(settings:HashMap, key: &'static str) -> T{ > match settings.get(&key) { > MyBool(x) => x, > MyStr(x) => x, > MyInt(x) => x > } > } > > But I don't know how to make this work. > > Thanks. > > > > On Tue, Jul 22, 2014 at 4:55 PM, Felix S. Klock II > wrote: > >> Aravinda (cc?ing rust-dev)- >> >> You didn?t show us exactly what you had tried to do to get your code to >> work, nor did you really describe what it is you want here. >> >> E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but >> since `MyBool` belongs to the `MyTypes` enum, that implies that `get_value` >> when applied to any variant of `MyTypes` (including `MyInt` or `MyStr`) >> should also return a boolean ? does that seem right to you? >> >> In any case, I suspect the missing piece of the puzzle for you is that >> you need to write an `impl` for the type in question. I.e. something along >> the lines of: >> >> impl MyTypes { >> fn render(&self) -> String { >> match *self { >> MyBool(x) => format!("{:b}", x), >> MyStr(ref x) => x.clone(), >> MyInt(x) => format!("{:d}", x), >> } >> } >> } >> >> (except revised from an Impl for the type to being an impl of some trait >> for the type). >> >> Here is a link to a playpen with your code, and with a couple of example >> `impl`s for enums (like the one above) tossed in, including an impl of one >> instance of your `Value` trait. >> >> http://is.gd/RofN9R >> >> There is more discussion of writing implementations that also provides an >> example with a simpler enum) in the Rust tutorial, see: >> >> http://doc.rust-lang.org/tutorial.html#methods >> >> Cheers, >> -Felix >> >> On 22 Jul 2014, at 11:45, Aravinda VK wrote: >> >> > Hi, >> > >> > I am trying to create a generic function to return value depending on >> the enum passed. But I don't know to create a generic trait for enum. >> > >> > In following example, print_value works but I don't know how I can >> write a generic get_value function to get value from enum. >> > >> > #[deriving(Show)] >> > enum MyTypes{ >> > MyBool(bool), >> > MyStr(String), >> > MyInt(int) >> > } >> > >> > fn print_value(arg: MyTypes){ >> > match arg{ >> > MyBool(x) => println!("Bool: {}", x), >> > MyStr(x) => println!("String: {}", x), >> > MyInt(x) => println!("Int: {}", x), >> > } >> > } >> > >> > >> > fn main(){ >> > print_value(MyBool(true)); >> > >> > // Following lines not working, how to write get_value func? >> > // let a: bool = get_value(MyBool(true)); >> > // println!("{}", a); >> > } >> > >> > >> > In case of struct it is simple, >> > >> > struct MyInt { >> > value: int >> > } >> > >> > struct MyBool{ >> > value: bool >> > } >> > >> > trait Value{ >> > fn get(&self) -> S; >> > } >> > >> > impl Value for MyInt{ >> > fn get(&self) -> int{ >> > self.value >> > } >> > } >> > >> > impl Value for MyBool{ >> > fn get(&self) -> bool{ >> > self.value >> > } >> > } >> > >> > fn get_value>(arg: T) -> S{ >> > arg.get() >> > } >> > >> > fn main(){ >> > let a: bool = get_value(MyBool{value: true}); >> > println!("{}", a); >> > >> > let b: int = get_value(MyInt{value: 100}); >> > println!("{}", b); >> > } >> > >> > Please help in writing generic function for enum. >> > >> > >> > >> > -- >> > Regards >> > Aravinda | ?????? >> > http://aravindavk.in >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > Regards > Aravinda | ?????? > http://aravindavk.in > > > -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From allen.welkie at gmail.com Tue Jul 22 09:50:40 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Tue, 22 Jul 2014 12:50:40 -0400 Subject: [rust-dev] Conflicting implementations of a trait Message-ID: Can there be two simultaneous implementations of a generic trait? I ask because I want to extend the Complex class to allow for multiplication by scalars, so that you can use "a * b" where "a" and "b" can be either scalars or Complex. The Complex struct already has an implementation of the Mul trait. I wanted to add another, so I added the implementation of Mul> for Complex, and used the scale() function. But I get a compiler error saying that there are conflicting implementations for trait 'core::ops::Mul'. Is it possible to simultaneously overload the Complex (*) operator scalars and complex numbers? -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Tue Jul 22 10:14:42 2014 From: corey at octayn.net (Corey Richardson) Date: Tue, 22 Jul 2014 10:14:42 -0700 Subject: [rust-dev] Conflicting implementations of a trait In-Reply-To: References: Message-ID: Not right now. Extending the language to allow this is the subject of RFC 24: https://github.com/rust-lang/rfcs/blob/master/active/0024-traits.md On Tue, Jul 22, 2014 at 9:50 AM, Allen Welkie wrote: > Can there be two simultaneous implementations of a generic trait? I ask > because I want to extend the Complex class to allow for multiplication by > scalars, so that you can use "a * b" where "a" and "b" can be either scalars > or Complex. > > The Complex struct already has an implementation of the Mul trait. I wanted > to add another, so I added the implementation of Mul> for > Complex, and used the scale() function. But I get a compiler error saying > that there are conflicting implementations for trait 'core::ops::Mul'. > > Is it possible to simultaneously overload the Complex (*) operator scalars > and complex numbers? > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From hallimanearavind at gmail.com Tue Jul 22 10:15:32 2014 From: hallimanearavind at gmail.com (Aravinda VK) Date: Tue, 22 Jul 2014 22:45:32 +0530 Subject: [rust-dev] How to write Generic traits for enums In-Reply-To: References: <47E30875-05A8-4E24-8879-049DC0D95139@mozilla.com> Message-ID: Hi Felix, Just now got a doubt. Since we know the type of enum during compile time, is it not possible to get the value from enum. Something like this.. enum MyTypes{ MyBool(bool), MyStr(String), MyInt(int) } let a = MyBool(true); a.get_value(); // trait for enum let b = MyInt(100); b.get_value(); Do you think it is possible to implement? On Tue, Jul 22, 2014 at 9:37 PM, Aravinda VK wrote: > Hi Felix, > > Thanks a lot for the detailed explanation. > > > On Tue, Jul 22, 2014 at 7:08 PM, Felix S. Klock II > wrote: > >> Aravinda (cc?ing rust-dev)- >> >> It seems like you are trying to program in Rust as if it were a >> dynamically-typed language, or one with runtime-type reflection (i.e. like >> Java). At least, that is my best guess at where your misunderstanding lies. >> >> All functions in Rust, even generic ones, need to have their types >> resolved at compile-time. A generic function can have different concrete >> types substituted in for its type parameters at different call-sites, but >> in the end, a particular call-site needs to resolve to a single type at >> compile-time; the type cannot be left for later resolution at program >> runtime. >> >> In a signature like your: >> >> fn get_value(settings:HashMap, key: &'static str) -> >> T; >> >> the particular instance of `MyTypes` that is returned will depend on >> which `key` is passed in; therefore, the `T` above could only be >> dynamically determined based on the runtime computation. It inherently >> cannot be resolved at compile-time, and therefore it is not statically >> typed. >> >> ---- >> >> Rust is not alone in offering this kind of generic types; many >> programming languages use a similar logic for determining types at compile >> time. It just gets fuzzy if one is used to languages that maintain types >> at runtime and do not enforce restrictions like the one I outlined above. >> >> These type systems are often said to offer ?parametric polymorphism?; I >> mention that solely to give you some guidance for a term to search for when >> goggling this subject. (Though I will say up front that a lot of the >> results you get on this topic can be very academic and language >> research-oriented.) >> >> Here is a tutorial that may help you get a handle on the concepts here: >> >> http://lucacardelli.name/Papers/BasicTypechecking.pdf >> >> (Yes, it is from 1987. I think that is why it probably one of the better >> descriptions I was able to find quickly: At that time, these ideas were not >> as widely popularized as they were today, so Cardelli took his time >> explaining the notions and assumed little about the audience.) >> >> rust-dev members: If others know of freely available introductions to >> this topic, I?m all ears; I just didn?t see any obvious winners in my >> searches. >> >> Cheers, >> -Felix >> >> >> On 22 Jul 2014, at 14:24, Aravinda VK wrote: >> >> Sorry for the incomplete mail. >> >> What I wanted is, >> get_value(MyStr("Rust".to_str())) returns String, >> get_value(MyBool(true)) returns bool and, >> get_value(MyInt(100)) returns int >> >> I was trying to store generic value in hashmap, as in the example below, >> >> use std::collections::hashmap::HashMap; >> >> #[deriving(Show)] >> enum MyTypes{ >> MyBool(bool), >> MyStr(String), >> MyInt(int) >> } >> >> fn main(){ >> let mut settings:HashMap = HashMap::new(); >> >> settings.insert("port".to_str(), MyInt(8000)); >> settings.insert("name".to_str(), MyStr("Rust".to_str())); >> settings.insert("enabled".to_str(), MyBool(true)); >> >> println!("{}", settings); >> } >> >> So to get the value out of hashmap, I need a generic function which >> checks the respective type and returns value. Some thing like >> >> fn get_value(settings:HashMap, key: &'static str) -> T{ >> match settings.get(&key) { >> MyBool(x) => x, >> MyStr(x) => x, >> MyInt(x) => x >> } >> } >> >> But I don't know how to make this work. >> >> Thanks. >> >> >> >> On Tue, Jul 22, 2014 at 4:55 PM, Felix S. Klock II >> wrote: >> >>> Aravinda (cc?ing rust-dev)- >>> >>> You didn?t show us exactly what you had tried to do to get your code to >>> work, nor did you really describe what it is you want here. >>> >>> E.g. you seem to want `get_value(MyBool(true))` to return a boolean, but >>> since `MyBool` belongs to the `MyTypes` enum, that implies that `get_value` >>> when applied to any variant of `MyTypes` (including `MyInt` or `MyStr`) >>> should also return a boolean ? does that seem right to you? >>> >>> In any case, I suspect the missing piece of the puzzle for you is that >>> you need to write an `impl` for the type in question. I.e. something along >>> the lines of: >>> >>> impl MyTypes { >>> fn render(&self) -> String { >>> match *self { >>> MyBool(x) => format!("{:b}", x), >>> MyStr(ref x) => x.clone(), >>> MyInt(x) => format!("{:d}", x), >>> } >>> } >>> } >>> >>> (except revised from an Impl for the type to being an impl of some trait >>> for the type). >>> >>> Here is a link to a playpen with your code, and with a couple of example >>> `impl`s for enums (like the one above) tossed in, including an impl of one >>> instance of your `Value` trait. >>> >>> http://is.gd/RofN9R >>> >>> There is more discussion of writing implementations that also provides >>> an example with a simpler enum) in the Rust tutorial, see: >>> >>> http://doc.rust-lang.org/tutorial.html#methods >>> >>> Cheers, >>> -Felix >>> >>> On 22 Jul 2014, at 11:45, Aravinda VK >>> wrote: >>> >>> > Hi, >>> > >>> > I am trying to create a generic function to return value depending on >>> the enum passed. But I don't know to create a generic trait for enum. >>> > >>> > In following example, print_value works but I don't know how I can >>> write a generic get_value function to get value from enum. >>> > >>> > #[deriving(Show)] >>> > enum MyTypes{ >>> > MyBool(bool), >>> > MyStr(String), >>> > MyInt(int) >>> > } >>> > >>> > fn print_value(arg: MyTypes){ >>> > match arg{ >>> > MyBool(x) => println!("Bool: {}", x), >>> > MyStr(x) => println!("String: {}", x), >>> > MyInt(x) => println!("Int: {}", x), >>> > } >>> > } >>> > >>> > >>> > fn main(){ >>> > print_value(MyBool(true)); >>> > >>> > // Following lines not working, how to write get_value func? >>> > // let a: bool = get_value(MyBool(true)); >>> > // println!("{}", a); >>> > } >>> > >>> > >>> > In case of struct it is simple, >>> > >>> > struct MyInt { >>> > value: int >>> > } >>> > >>> > struct MyBool{ >>> > value: bool >>> > } >>> > >>> > trait Value{ >>> > fn get(&self) -> S; >>> > } >>> > >>> > impl Value for MyInt{ >>> > fn get(&self) -> int{ >>> > self.value >>> > } >>> > } >>> > >>> > impl Value for MyBool{ >>> > fn get(&self) -> bool{ >>> > self.value >>> > } >>> > } >>> > >>> > fn get_value>(arg: T) -> S{ >>> > arg.get() >>> > } >>> > >>> > fn main(){ >>> > let a: bool = get_value(MyBool{value: true}); >>> > println!("{}", a); >>> > >>> > let b: int = get_value(MyInt{value: 100}); >>> > println!("{}", b); >>> > } >>> > >>> > Please help in writing generic function for enum. >>> > >>> > >>> > >>> > -- >>> > Regards >>> > Aravinda | ?????? >>> > http://aravindavk.in >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > Rust-dev at mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> >> -- >> Regards >> Aravinda | ?????? >> http://aravindavk.in >> >> >> > > > -- > Regards > Aravinda | ?????? > http://aravindavk.in > -- Regards Aravinda | ?????? http://aravindavk.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.parreaux at gmail.com Tue Jul 22 10:16:55 2014 From: lionel.parreaux at gmail.com (Lionel Parreaux) Date: Tue, 22 Jul 2014 19:16:55 +0200 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? Message-ID: Hi, So traits seem to be quite similar to Haskell's classes, being also used for parametric polymorphism. Now, Haskell classes are usually implemented using runtime dictionary passing. In general, code cannot be specialized for every function call, since there may be an unbounded number of instances generated for it, as is explained in this reddit answer: http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju Knowing that Rust implements traits using monomorphization of code (much like C++ templates), I was curious about how it handled such cases, and tried this: struct W { f: T } trait Show { fn show(&self) -> int; } impl Show for int { fn show(&self) -> int { 666 } } impl Show for W { fn show(&self) -> int { self.f.show()+1 } } impl Clone for W { fn clone(&self) -> W { W{f:self.f.clone()} } } fn foo(s: &S, n: int) { let w = W{f:s.clone()}; if n > 0 { foo(&w, n-1); } } fn main() { foo(&W{f:42i},42); } It gave me an "error: reached the recursion limit during monomorphization", which... well, that's a possible solution :) I'm not sure whether this is a big problem in practice, but I was wondering if it would be possible to switch to some runtime mechanism in cases like this. Maybe we could make a special version of every generic functions, that takes a dictionary at runtime and that would be able to handle types unknown at compile-time. We would switch to this version when monomorphization does not work. It could also allow dynamic linking of libraries with generic functions, or it could be a way to compile some programs (or some parts of programs) much faster. I was thinking about, for example, an IDE where generic function calls to types defined inside the files currently being edited use their dynamic version, so that recompile times can be virtually inexistent (like Java). On the other hand, the release build would of course monomorphize as much as possible to make the perf optimal. Now the question is: would this conform to the current semantic of monomorphization? Do special things happen during monomorphization that cannot be reproduced at runtime? This is the case in C++ (and one of the reasons why C++ templates are so "bad"). Is it the case in Rust, which should already have all the required info (type bounds) before monomorphization? I apologize if this has already been discussed. I could not find many satisfying answers by googling. Cheers, LP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Tue Jul 22 10:23:03 2014 From: corey at octayn.net (Corey Richardson) Date: Tue, 22 Jul 2014 10:23:03 -0700 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: Message-ID: You can avoid monomorphization by using "trait objects", which erase the precise implementing type through a vtable + pointer. http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch has some documentation. On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux wrote: > Hi, > > So traits seem to be quite similar to Haskell's classes, being also used for > parametric polymorphism. Now, Haskell classes are usually implemented using > runtime dictionary passing. In general, code cannot be specialized for every > function call, since there may be an unbounded number of instances generated > for it, as is explained in this reddit answer: > http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju > > Knowing that Rust implements traits using monomorphization of code (much > like C++ templates), I was curious about how it handled such cases, and > tried this: > > struct W { > f: T > } > > trait Show { > fn show(&self) -> int; > } > > impl Show for int { > fn show(&self) -> int { 666 } > } > impl Show for W { > fn show(&self) -> int { self.f.show()+1 } > } > impl Clone for W { > fn clone(&self) -> W { W{f:self.f.clone()} } > } > > fn foo(s: &S, n: int) { > let w = W{f:s.clone()}; > if n > 0 { foo(&w, n-1); } > } > > fn main() { > foo(&W{f:42i},42); > } > > > It gave me an "error: reached the recursion limit during monomorphization", > which... well, that's a possible solution :) > > I'm not sure whether this is a big problem in practice, but I was wondering > if it would be possible to switch to some runtime mechanism in cases like > this. Maybe we could make a special version of every generic functions, that > takes a dictionary at runtime and that would be able to handle types unknown > at compile-time. We would switch to this version when monomorphization does > not work. It could also allow dynamic linking of libraries with generic > functions, or it could be a way to compile some programs (or some parts of > programs) much faster. > I was thinking about, for example, an IDE where generic function calls to > types defined inside the files currently being edited use their dynamic > version, so that recompile times can be virtually inexistent (like Java). On > the other hand, the release build would of course monomorphize as much as > possible to make the perf optimal. > > Now the question is: would this conform to the current semantic of > monomorphization? Do special things happen during monomorphization that > cannot be reproduced at runtime? > This is the case in C++ (and one of the reasons why C++ templates are so > "bad"). Is it the case in Rust, which should already have all the required > info (type bounds) before monomorphization? > > I apologize if this has already been discussed. I could not find many > satisfying answers by googling. > > Cheers, > LP. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From s.gesemann at gmail.com Tue Jul 22 10:34:42 2014 From: s.gesemann at gmail.com (Sebastian Gesemann) Date: Tue, 22 Jul 2014 19:34:42 +0200 Subject: [rust-dev] Conflicting implementations of a trait In-Reply-To: References: Message-ID: <53CEA0B2.1040802@gmail.com> Am 22.07.2014 18:50, schrieb Allen Welkie: > Can there be two simultaneous implementations of a generic trait? I ask > because I want to extend the Complex class to allow for multiplication by > scalars, so that you can use "a * b" where "a" and "b" can be either > scalars or Complex. [snip] Something like this was my first attempt in Rust. I was able to define two own types (complex and imaginary) which I could mix with f64 for multiplication, addition, etc. But it required a kind of "double dispatch". Niko explained it here: http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/ Unfortunately, given how these traits are defined now, design requires a bit of foresight. If you want to mix types like this for binary operations eventually, you should probably start this kind of dispatching early on. You can't do that with num's complex struct now. Its Add/Mul/etc impls weren't designed with double-dispatch in mind. For now, you would have to define your own types like I did. But there is a chance that the binary operator traits change. For a binary operator like + and * there is no clear "receiver" (an object you call an add function on). IMHO the operands should be treated equally. One approach that I saw mentioned by Niko (in another blog post I believe) was to use tuples for that: trait Add { fn add(self) -> Out; } impl Add> for (f64,Compex) { fn add((lhs, rhs) : (f64, Complex)) -> Complex { ... } } And this makes it much easier to extend the interface of certain types together. On the other hand, there still needs to go some thought into this with respect to passing operands by value or reference. You don't want unnecessary clones. And you probably don't want operands to be moved-from in some cases. And the way these kinds of traits are refined should work well together with generic code: fn foo(x: T, y: U) -> O where ???: Mul { x * y } Ideally, this should work for every type T and U that can be multiplied somehow. The question however is, how to write down the type bound? Should we write (&T,&U): Add to avoid moving? Should we write (T,U): Add for a nicer, more intuitive syntax perhaps? I don't know. If you have a good idea how to do that, I'm all ears. I'm very much interested in getting easily overloadable operators without the pain of double-dispatch and without the pain of clumsly type bounds for generic functions that only work for half the cases due to references and such. Cheers! sg From b.gh.n.93 at gmail.com Tue Jul 22 11:09:37 2014 From: b.gh.n.93 at gmail.com (Nawfel BGH) Date: Tue, 22 Jul 2014 19:09:37 +0100 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: Message-ID: this remindes me of the issue i got when trying to implement finger trees in Rust so long ago https://github.com/rust-lang/rust/issues/8613 I suggested to let add a way to specify (in the code) how match functions do we want to generate and failing at runtime when the limit is reached. This made sense in my situation. 2014-07-22 18:23 UTC+01:00, Corey Richardson : > You can avoid monomorphization by using "trait objects", which erase > the precise implementing type through a vtable + pointer. > http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch > has some documentation. > > On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux > wrote: >> Hi, >> >> So traits seem to be quite similar to Haskell's classes, being also used >> for >> parametric polymorphism. Now, Haskell classes are usually implemented >> using >> runtime dictionary passing. In general, code cannot be specialized for >> every >> function call, since there may be an unbounded number of instances >> generated >> for it, as is explained in this reddit answer: >> http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju >> >> Knowing that Rust implements traits using monomorphization of code (much >> like C++ templates), I was curious about how it handled such cases, and >> tried this: >> >> struct W { >> f: T >> } >> >> trait Show { >> fn show(&self) -> int; >> } >> >> impl Show for int { >> fn show(&self) -> int { 666 } >> } >> impl Show for W { >> fn show(&self) -> int { self.f.show()+1 } >> } >> impl Clone for W { >> fn clone(&self) -> W { W{f:self.f.clone()} } >> } >> >> fn foo(s: &S, n: int) { >> let w = W{f:s.clone()}; >> if n > 0 { foo(&w, n-1); } >> } >> >> fn main() { >> foo(&W{f:42i},42); >> } >> >> >> It gave me an "error: reached the recursion limit during >> monomorphization", >> which... well, that's a possible solution :) >> >> I'm not sure whether this is a big problem in practice, but I was >> wondering >> if it would be possible to switch to some runtime mechanism in cases like >> this. Maybe we could make a special version of every generic functions, >> that >> takes a dictionary at runtime and that would be able to handle types >> unknown >> at compile-time. We would switch to this version when monomorphization >> does >> not work. It could also allow dynamic linking of libraries with generic >> functions, or it could be a way to compile some programs (or some parts >> of >> programs) much faster. >> I was thinking about, for example, an IDE where generic function calls to >> types defined inside the files currently being edited use their dynamic >> version, so that recompile times can be virtually inexistent (like Java). >> On >> the other hand, the release build would of course monomorphize as much as >> possible to make the perf optimal. >> >> Now the question is: would this conform to the current semantic of >> monomorphization? Do special things happen during monomorphization that >> cannot be reproduced at runtime? >> This is the case in C++ (and one of the reasons why C++ templates are so >> "bad"). Is it the case in Rust, which should already have all the >> required >> info (type bounds) before monomorphization? >> >> I apologize if this has already been discussed. I could not find many >> satisfying answers by googling. >> >> Cheers, >> LP. >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > http://octayn.net/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Tue Jul 22 11:47:18 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 22 Jul 2014 11:47:18 -0700 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: Message-ID: <53CEB1B6.8090708@mozilla.com> On 7/22/14 10:16 AM, Lionel Parreaux wrote: > I'm not sure whether this is a big problem in practice, but I was > wondering if it would be possible to switch to some runtime mechanism in > cases like this. Maybe we could make a special version of every generic > functions, that takes a dictionary at runtime and that would be able to > handle types unknown at compile-time. We would switch to this version > when monomorphization does not work. It could also allow dynamic linking > of libraries with generic functions, or it could be a way to compile > some programs (or some parts of programs) much faster. The hard part about doing that is not the dictionary passing. The hard part is that generic types may have unknown size or alignment. In Haskell this is not a problem because the language is garbage-collected and lazy so values have a uniform representation. But in Rust this is not true. Old Rust used to try to use runtime dictionary passing, where the dictionary contained size and alignment information, and all size/alignment info was computed at runtime for generics. I cannot overstate how *fiendishly* complex this was. We never got all the bugs out. In many cases, the amount of runtime code generated to compute size and alignment outweighed the cost of just monomorphizing. I strongly feel that the current system, where you can use generic type parameters to get monomorphization or trait objects to get dictionary passing, is the sweet spot. Patrick From farcaller at gmail.com Tue Jul 22 12:06:37 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Tue, 22 Jul 2014 20:06:37 +0100 Subject: [rust-dev] A shiny test framework Message-ID: I've just published a tiny test framework: shiny at https://github.com/farcaller/shiny. It's best used with hamcrest-rust. This library exists because I find it ugly to redefine all the initialisation code in every test case and I can't simply move it to a function due to problems with moving [T] out. Here's how shiny looks: #[cfg(test)] mod test { describe!( before_each { let awesome = true; } it "is awesome" { assert!(awesome); } it "injects before_each into all test cases" { let still_awesome = awesome; assert!(still_awesome); } ) } -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Tue Jul 22 12:09:16 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Tue, 22 Jul 2014 20:09:16 +0100 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: Dude, that's pretty much rspec ;) sweet! On 22 Jul 2014 20:07, "Vladimir Pouzanov" wrote: > I've just published a tiny test framework: shiny at > https://github.com/farcaller/shiny. It's best used with hamcrest-rust. > > This library exists because I find it ugly to redefine all the > initialisation code in every test case and I can't simply move it to a > function due to problems with moving [T] out. > > Here's how shiny looks: > > #[cfg(test)] > mod test { > describe!( > before_each { > let awesome = true; > } > > it "is awesome" { > assert!(awesome); > } > > it "injects before_each into all test cases" { > let still_awesome = awesome; > assert!(still_awesome); > } > ) > } > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > 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 hastebrot at gmail.com Tue Jul 22 12:10:48 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 22 Jul 2014 21:10:48 +0200 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: Nice to see an RSpec-like test framework and Hamcrest assertions/matchers for Rust! On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko wrote: > Dude, that's pretty much rspec ;) sweet! > On 22 Jul 2014 20:07, "Vladimir Pouzanov" wrote: > >> I've just published a tiny test framework: shiny at >> https://github.com/farcaller/shiny. It's best used with hamcrest-rust. >> >> This library exists because I find it ugly to redefine all the >> initialisation code in every test case and I can't simply move it to a >> function due to problems with moving [T] out. >> >> Here's how shiny looks: >> >> #[cfg(test)] >> mod test { >> describe!( >> before_each { >> let awesome = true; >> } >> >> it "is awesome" { >> assert!(awesome); >> } >> >> it "injects before_each into all test cases" { >> let still_awesome = awesome; >> assert!(still_awesome); >> } >> ) >> } >> >> -- >> Sincerely, >> Vladimir "Farcaller" Pouzanov >> http://farcaller.net/ >> >> _______________________________________________ >> 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 farcaller at gmail.com Tue Jul 22 12:31:03 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Tue, 22 Jul 2014 20:31:03 +0100 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: One note on why there's no after_each: You cannot really make sure that the epilogue is being called, so if you need to do anything after your test case, use RAII in before_each. On Tue, Jul 22, 2014 at 8:10 PM, Benjamin Gudehus wrote: > Nice to see an RSpec-like test framework and Hamcrest assertions/matchers > for Rust! > > > On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko < > errordeveloper at gmail.com> wrote: > >> Dude, that's pretty much rspec ;) sweet! >> On 22 Jul 2014 20:07, "Vladimir Pouzanov" wrote: >> >>> I've just published a tiny test framework: shiny at >>> https://github.com/farcaller/shiny. It's best used with hamcrest-rust. >>> >>> This library exists because I find it ugly to redefine all the >>> initialisation code in every test case and I can't simply move it to a >>> function due to problems with moving [T] out. >>> >>> Here's how shiny looks: >>> >>> #[cfg(test)] >>> mod test { >>> describe!( >>> before_each { >>> let awesome = true; >>> } >>> >>> it "is awesome" { >>> assert!(awesome); >>> } >>> >>> it "injects before_each into all test cases" { >>> let still_awesome = awesome; >>> assert!(still_awesome); >>> } >>> ) >>> } >>> >>> -- >>> Sincerely, >>> Vladimir "Farcaller" Pouzanov >>> http://farcaller.net/ >>> >>> _______________________________________________ >>> 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 >> >> > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Tue Jul 22 14:10:22 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Tue, 22 Jul 2014 21:10:22 +0000 (UTC) Subject: [rust-dev] Mutable files References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> <53CD89F6.4050800@mozilla.com> Message-ID: <770508180427755615.880695troplin-bluewin.ch@news.gmane.org> Patrick Walton wrote: > On 7/21/14 2:22 PM, Tobias M?ller wrote: >> We discussed this with Bartosz literally for weeks (him being a fan of >> auto_ptr for too long, later completely converted against it and I take >> credit for that :o)). With auto_ptr this was possible: >> >> auto_ptr a(new int); >> auto_ptr b = a; >> >> It would nullify a with copy syntax. That code won't compile with >> unique_ptr; you'd need an explicit move(a). >> >> It only got worse from there: passing into functions, member variables... >> >> MOVING WITH COPY SYNTAX DOES NOT WORK. >> >> It's cut and dried. Please don't snip the attribution, that was a quote! > ... in C++. Not in Rust. That's because, unlike C++, Rust is designed > from the ground up to support moves and copies in a first class way. > >> It's just strange that you can change the semantic of an already existing >> operation just by adding new capabilities. Adding traits should define new >> operations with new semantics, not changing the semantics of existing >> operations. At least that's how it works for all other traits, and >> deviating from that is at least surprising. > > Hence the Opt-In Built-In Traits proposal Opt-In built-In traits makes things a bit better but my point is still valid. By adding Copy (implicitly or explicitly) you remove the possibility of move semantics from the type. Usually you don't work alone on a project and some coworker adding Copy to a type that I expected to be Move may be fatal. No other trait removed works like that. >> Maybe the syntax was just too heavy? > > Any syntax at all is too much. I am convinced of that. I'm still not convinced but maybe my fear is unjustified. Time will tell. Tobi From val at markovic.io Tue Jul 22 16:53:44 2014 From: val at markovic.io (Val Markovic) Date: Tue, 22 Jul 2014 16:53:44 -0700 Subject: [rust-dev] Mutable files In-Reply-To: <53CD89F6.4050800@mozilla.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> <53CD89F6.4050800@mozilla.com> Message-ID: On Mon, Jul 21, 2014 at 2:45 PM, Patrick Walton wrote: > >> ... in C++. Not in Rust. That's because, unlike C++, Rust is designed > from the ground up to support moves and copies in a first class way. As a C++ dev, I feel the need to say THANK YOU for that. Rust being designed with first-class move support is a major feature for me; it's something I highlight when I talk about Rust with other C++ devs and it's universally applauded. > > > It's just strange that you can change the semantic of an already existing >> operation just by adding new capabilities. Adding traits should define new >> operations with new semantics, not changing the semantics of existing >> operations. At least that's how it works for all other traits, and >> deviating from that is at least surprising. >> > > Hence the Opt-In Built-In Traits proposal > > > Maybe the syntax was just too heavy? >> > > Any syntax at all is too much. I am convinced of that. > > Patrick > > > _______________________________________________ > 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 dbau.pp at gmail.com Tue Jul 22 17:35:56 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Wed, 23 Jul 2014 10:35:56 +1000 Subject: [rust-dev] Mutable files In-Reply-To: <770508180427755615.880695troplin-bluewin.ch@news.gmane.org> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <756339830427669564.234822troplin-bluewin.ch@news.gmane.org> <53CD89F6.4050800@mozilla.com> <770508180427755615.880695troplin-bluewin.ch@news.gmane.org> Message-ID: <53CF036C.1070405@gmail.com> On 23/07/14 07:10, Tobias M?ller wrote: > >> ... in C++. Not in Rust. That's because, unlike C++, Rust is designed >> from the ground up to support moves and copies in a first class way. >> >>> It's just strange that you can change the semantic of an already existing >>> operation just by adding new capabilities. Adding traits should define new >>> operations with new semantics, not changing the semantics of existing >>> operations. At least that's how it works for all other traits, and >>> deviating from that is at least surprising. >> Hence the Opt-In Built-In Traits proposal > Opt-In built-In traits makes things a bit better but my point is still > valid. By adding Copy (implicitly or explicitly) you remove the possibility > of move semantics from the type. > Usually you don't work alone on a project and some coworker adding Copy to > a type that I expected to be Move may be fatal. > > No other trait removed works like that. You can't just add Copy to anything: the contents has to be Copy itself, and, you can't have a destructor on your type (i.e. a Drop implementation removes the possibility to be Copy). Thus, almost all types for which by-value uses *should* invalidate the source (i.e. "move semantics") are automatically not Copy anyway. The only way one can get a fatal error due to an incorrect Copy implementation is if the type with the impl is using `unsafe` code internally. In this case, that whole API needs to be considered very carefully anyway, ensuring correctness by avoiding Copy is just part of it. I'll also note that an implementation of Copy just states the a byte-copy of a value is also a semantic copy, it doesn't offer any control over how the copy is performed. At runtime, by-value use of a Copy type is essentially identical to a by-value use of a non-Copy type (both are memcpy's of the bytes), the only major difference is the compiler statically prevents further uses of the source for non-Copy ones. Huon From zwarich at mozilla.com Tue Jul 22 19:13:38 2014 From: zwarich at mozilla.com (Cameron Zwarich) Date: Tue, 22 Jul 2014 19:13:38 -0700 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: Message-ID: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> Even if we could do a size/alignment-passing implementation like Patrick describes, would be it even be appropriate? It wouldn?t make sense for a systems language to transparently switch to a dramatically less efficient implementation mechanism without the programmer?s involvement. Is there any place where an unbounded number of dictionaries at runtime is actually appropriate for solving a real problem in Rust? Cameron On Jul 22, 2014, at 10:16 AM, Lionel Parreaux wrote: > Hi, > > So traits seem to be quite similar to Haskell's classes, being also used for parametric polymorphism. Now, Haskell classes are usually implemented using runtime dictionary passing. In general, code cannot be specialized for every function call, since there may be an unbounded number of instances generated for it, as is explained in this reddit answer: http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju > > Knowing that Rust implements traits using monomorphization of code (much like C++ templates), I was curious about how it handled such cases, and tried this: > > struct W { > f: T > } > > trait Show { > fn show(&self) -> int; > } > > impl Show for int { > fn show(&self) -> int { 666 } > } > impl Show for W { > fn show(&self) -> int { self.f.show()+1 } > } > impl Clone for W { > fn clone(&self) -> W { W{f:self.f.clone()} } > } > > fn foo(s: &S, n: int) { > let w = W{f:s.clone()}; > if n > 0 { foo(&w, n-1); } > } > > fn main() { > foo(&W{f:42i},42); > } > > > It gave me an "error: reached the recursion limit during monomorphization", which... well, that's a possible solution :) > > I'm not sure whether this is a big problem in practice, but I was wondering if it would be possible to switch to some runtime mechanism in cases like this. Maybe we could make a special version of every generic functions, that takes a dictionary at runtime and that would be able to handle types unknown at compile-time. We would switch to this version when monomorphization does not work. It could also allow dynamic linking of libraries with generic functions, or it could be a way to compile some programs (or some parts of programs) much faster. > I was thinking about, for example, an IDE where generic function calls to types defined inside the files currently being edited use their dynamic version, so that recompile times can be virtually inexistent (like Java). On the other hand, the release build would of course monomorphize as much as possible to make the perf optimal. > > Now the question is: would this conform to the current semantic of monomorphization? Do special things happen during monomorphization that cannot be reproduced at runtime? > This is the case in C++ (and one of the reasons why C++ templates are so "bad"). Is it the case in Rust, which should already have all the required info (type bounds) before monomorphization? > > I apologize if this has already been discussed. I could not find many satisfying answers by googling. > > Cheers, > LP. > > > _______________________________________________ > 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 contact at urbanhafner.com Wed Jul 23 00:42:59 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Wed, 23 Jul 2014 09:42:59 +0200 Subject: [rust-dev] Debugging rust for a newbie Message-ID: Hey there, I'm still quite new to Rust. Until now I was able to fix all my bugs by writing tests and/or randomly adding lifetime parameters to keep the compiler happy. Now I've hit my first stack overflow. I assume it's due to the fact that I've screwed up the lifetimes and the objects live too long although I'm not even sure about that. Now my question is: How do I debug this? Is there a way to figure out how long objects live? Or how would one go about debugging this? Oh, if you're interested in the failing code: https://github.com/ujh/iomrascalai/pull/46 Cheers, Urban -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Wed Jul 23 01:02:42 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Wed, 23 Jul 2014 18:02:42 +1000 Subject: [rust-dev] Debugging rust for a newbie In-Reply-To: References: Message-ID: <53CF6C22.4050409@gmail.com> It is unlikely to be a lifetimes thing; far, far more likely to be a "normal" infinite recursion. The size of the stack frame of each function is fixed at compile time, so the way to blow the stack is by calling a lot of functions deeply, e.g. it's not possible to write a loop that places more and more objects on the stack (not in safe code, anyway). You can get a backtrace by running the test in a conventional debugger, e.g. `gdb --args ./tester produces_a_move`, then type `run`. When it hits the abort, gdb will freeze execution and you can run `backtrace` to see the function call stack, to see what is recursing deeply. You can make rustc emit debug info which makes gdb far more useful, by compiling with `-g` or, equivalently, `--debuginfo=2`. (Depending on your platform, 'lldb' may be better.) If all else fails, you can fall back to println debugging, e.g. fn gen_move(&self, ...) -> Move { println!("calling gen_move"); // ... } --- Just glancing over your code, it looks like there's mutual recursion between Playout::run and McEngine::gen_move: - McEngine::gen_move calls Playout::run https://github.com/ujh/iomrascalai/blob/88e09fdd/src/engine/mc/mod.rs#L82 - Playout::run calls Playout::gen_move https://github.com/ujh/iomrascalai/blob/88e09fdd/src/playout/mod.rs#L42 - Playout::gen_move calls McEngine::gen_move https://github.com/ujh/iomrascalai/blob/88e09fdd/src/playout/mod.rs#L49 Huon On 23/07/14 17:42, Urban Hafner wrote: > Hey there, > > I'm still quite new to Rust. Until now I was able to fix all my bugs > by writing tests and/or randomly adding lifetime parameters to keep > the compiler happy. Now I've hit my first stack overflow. I assume > it's due to the fact that I've screwed up the lifetimes and the > objects live too long although I'm not even sure about that. Now my > question is: How do I debug this? Is there a way to figure out how > long objects live? Or how would one go about debugging this? > > Oh, if you're interested in the failing code: > https://github.com/ujh/iomrascalai/pull/46 > > Cheers, > > Urban > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.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 contact at urbanhafner.com Wed Jul 23 01:13:23 2014 From: contact at urbanhafner.com (Urban Hafner) Date: Wed, 23 Jul 2014 10:13:23 +0200 Subject: [rust-dev] Debugging rust for a newbie In-Reply-To: <53CF6C22.4050409@gmail.com> References: <53CF6C22.4050409@gmail.com> Message-ID: Hey Huon, thanks for the help. The problem is really obvious now that you mention it! Thanks for the debugging tips however. Coming from Ruby all I ever use are print statements. So it's good to know how to do it! Urban On Wed, Jul 23, 2014 at 10:02 AM, Huon Wilson wrote: > It is unlikely to be a lifetimes thing; far, far more likely to be a > "normal" infinite recursion. The size of the stack frame of each function > is fixed at compile time, so the way to blow the stack is by calling a lot > of functions deeply, e.g. it's not possible to write a loop that places > more and more objects on the stack (not in safe code, anyway). > > You can get a backtrace by running the test in a conventional debugger, > e.g. `gdb --args ./tester produces_a_move`, then type `run`. When it hits > the abort, gdb will freeze execution and you can run `backtrace` to see the > function call stack, to see what is recursing deeply. > > You can make rustc emit debug info which makes gdb far more useful, by > compiling with `-g` or, equivalently, `--debuginfo=2`. (Depending on your > platform, 'lldb' may be better.) > > > If all else fails, you can fall back to println debugging, e.g. > > fn gen_move(&self, ...) -> Move { > println!("calling gen_move"); > > // ... > } > > --- > > Just glancing over your code, it looks like there's mutual recursion > between Playout::run and McEngine::gen_move: > > - McEngine::gen_move calls Playout::run > https://github.com/ujh/iomrascalai/blob/88e09fdd/src/engine/mc/mod.rs#L82 > - Playout::run calls Playout::gen_move > https://github.com/ujh/iomrascalai/blob/88e09fdd/src/playout/mod.rs#L42 > - Playout::gen_move calls McEngine::gen_move > https://github.com/ujh/iomrascalai/blob/88e09fdd/src/playout/mod.rs#L49 > > > Huon > > > > On 23/07/14 17:42, Urban Hafner wrote: > > Hey there, > > I'm still quite new to Rust. Until now I was able to fix all my bugs by > writing tests and/or randomly adding lifetime parameters to keep the > compiler happy. Now I've hit my first stack overflow. I assume it's due to > the fact that I've screwed up the lifetimes and the objects live too long > although I'm not even sure about that. Now my question is: How do I debug > this? Is there a way to figure out how long objects live? Or how would one > go about debugging this? > > Oh, if you're interested in the failing code: > https://github.com/ujh/iomrascalai/pull/46 > > Cheers, > > Urban > -- > Freelancer > > Available for hire for Ruby, Ruby on Rails, and JavaScript projects > > More at http://urbanhafner.com > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Freelancer Available for hire for Ruby, Ruby on Rails, and JavaScript projects More at http://urbanhafner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat.pryce at gmail.com Wed Jul 23 04:18:01 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Wed, 23 Jul 2014 12:18:01 +0100 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: Could you use RAII to call a lambda? On 22 July 2014 20:31, Vladimir Pouzanov wrote: > One note on why there's no after_each: > > You cannot really make sure that the epilogue is being called, so if you > need to do anything after your test case, use RAII in before_each. > > > On Tue, Jul 22, 2014 at 8:10 PM, Benjamin Gudehus > wrote: > >> Nice to see an RSpec-like test framework and Hamcrest assertions/matchers >> for Rust! >> >> >> On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko < >> errordeveloper at gmail.com> wrote: >> >>> Dude, that's pretty much rspec ;) sweet! >>> On 22 Jul 2014 20:07, "Vladimir Pouzanov" wrote: >>> >>>> I've just published a tiny test framework: shiny at >>>> https://github.com/farcaller/shiny. It's best used with hamcrest-rust. >>>> >>>> This library exists because I find it ugly to redefine all the >>>> initialisation code in every test case and I can't simply move it to a >>>> function due to problems with moving [T] out. >>>> >>>> Here's how shiny looks: >>>> >>>> #[cfg(test)] >>>> mod test { >>>> describe!( >>>> before_each { >>>> let awesome = true; >>>> } >>>> >>>> it "is awesome" { >>>> assert!(awesome); >>>> } >>>> >>>> it "injects before_each into all test cases" { >>>> let still_awesome = awesome; >>>> assert!(still_awesome); >>>> } >>>> ) >>>> } >>>> >>>> -- >>>> Sincerely, >>>> Vladimir "Farcaller" Pouzanov >>>> http://farcaller.net/ >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat.pryce at gmail.com Wed Jul 23 04:18:39 2014 From: nat.pryce at gmail.com (Nat Pryce) Date: Wed, 23 Jul 2014 12:18:39 +0100 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: It's great to see Hamcrest ported to Rust. On 22 July 2014 20:06, Vladimir Pouzanov wrote: > I've just published a tiny test framework: shiny at > https://github.com/farcaller/shiny. It's best used with hamcrest-rust. > > This library exists because I find it ugly to redefine all the > initialisation code in every test case and I can't simply move it to a > function due to problems with moving [T] out. > > Here's how shiny looks: > > #[cfg(test)] > mod test { > describe!( > before_each { > let awesome = true; > } > > it "is awesome" { > assert!(awesome); > } > > it "injects before_each into all test cases" { > let still_awesome = awesome; > assert!(still_awesome); > } > ) > } > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- http://www.natpryce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.parreaux at gmail.com Tue Jul 22 12:39:53 2014 From: lionel.parreaux at gmail.com (Lionel Parreaux) Date: Tue, 22 Jul 2014 21:39:53 +0200 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: Message-ID: Right, I had forgotten Rust had this convenient trait object feature. However, my question remains: does a function accepting an object always have the same behavior as a function that uses a generic parameter? If this was the case, as I proposed in my previous message, we could not only generate specialized monomorphic versions of generic functions, but also specialized *polymorphic* versions of them (using objects), transparently. This would allow writing generic functions only once, that can be used efficiently when possible/appropriate (by monomorphization), but are also usable dynamically. This property is not necessarily trivial, because of overloading for instance. I'm not sure how it works in Rust, but in C++, calling "foo(p)" and "foo(p)" with the same object p of type Student* may have different behaviors because of overloading resolution after template instantiation (and also because of template specialization). 2014-07-22 19:23 GMT+02:00 Corey Richardson : > You can avoid monomorphization by using "trait objects", which erase > the precise implementing type through a vtable + pointer. > > http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch > has some documentation. > > On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux > wrote: > > Hi, > > > > So traits seem to be quite similar to Haskell's classes, being also used > for > > parametric polymorphism. Now, Haskell classes are usually implemented > using > > runtime dictionary passing. In general, code cannot be specialized for > every > > function call, since there may be an unbounded number of instances > generated > > for it, as is explained in this reddit answer: > > > http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju > > > > Knowing that Rust implements traits using monomorphization of code (much > > like C++ templates), I was curious about how it handled such cases, and > > tried this: > > > > struct W { > > f: T > > } > > > > trait Show { > > fn show(&self) -> int; > > } > > > > impl Show for int { > > fn show(&self) -> int { 666 } > > } > > impl Show for W { > > fn show(&self) -> int { self.f.show()+1 } > > } > > impl Clone for W { > > fn clone(&self) -> W { W{f:self.f.clone()} } > > } > > > > fn foo(s: &S, n: int) { > > let w = W{f:s.clone()}; > > if n > 0 { foo(&w, n-1); } > > } > > > > fn main() { > > foo(&W{f:42i},42); > > } > > > > > > It gave me an "error: reached the recursion limit during > monomorphization", > > which... well, that's a possible solution :) > > > > I'm not sure whether this is a big problem in practice, but I was > wondering > > if it would be possible to switch to some runtime mechanism in cases like > > this. Maybe we could make a special version of every generic functions, > that > > takes a dictionary at runtime and that would be able to handle types > unknown > > at compile-time. We would switch to this version when monomorphization > does > > not work. It could also allow dynamic linking of libraries with generic > > functions, or it could be a way to compile some programs (or some parts > of > > programs) much faster. > > I was thinking about, for example, an IDE where generic function calls to > > types defined inside the files currently being edited use their dynamic > > version, so that recompile times can be virtually inexistent (like > Java). On > > the other hand, the release build would of course monomorphize as much as > > possible to make the perf optimal. > > > > Now the question is: would this conform to the current semantic of > > monomorphization? Do special things happen during monomorphization that > > cannot be reproduced at runtime? > > This is the case in C++ (and one of the reasons why C++ templates are so > > "bad"). Is it the case in Rust, which should already have all the > required > > info (type bounds) before monomorphization? > > > > I apologize if this has already been discussed. I could not find many > > satisfying answers by googling. > > > > Cheers, > > LP. > > > > > > > > _______________________________________________ > > 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 banderson at mozilla.com Wed Jul 23 10:27:48 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 23 Jul 2014 10:27:48 -0700 Subject: [rust-dev] A shiny test framework In-Reply-To: References: Message-ID: <53CFF094.8010009@mozilla.com> Awesome! I'm glad to see people extending Rust's testing infrastructure with more expressive frameworks (I assume this translates to `#[test]` fns under the hood?). On 07/22/2014 12:06 PM, Vladimir Pouzanov wrote: > I've just published a tiny test framework: shiny at > https://github.com/farcaller/shiny. It's best used with hamcrest-rust. > > This library exists because I find it ugly to redefine all the > initialisation code in every test case and I can't simply move it to a > function due to problems with moving [T] out. > > Here's how shiny looks: > > #[cfg(test)] > mod test { > describe!( > before_each { > let awesome = true; > } > > it "is awesome" { > assert!(awesome); > } > > it "injects before_each into all test cases" { > let still_awesome = awesome; > assert!(still_awesome); > } > ) > } > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > > _______________________________________________ > 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 Wed Jul 23 10:32:17 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Wed, 23 Jul 2014 13:32:17 -0400 Subject: [rust-dev] Using 'mod' for test code Message-ID: I'm having an issue with creating a separate testing file for a program I'm writing. I have a file called 'myprogram.rs', which imports complex numbers with the following extern crate num; use num::complex::Complex; and then defines a bunch of functions. I want to test these functions in a separate file. So I created 'testprogram.rs' and import the myprogram functions using the 'mod' keyword: mod myprogram; But when I try to compile test.rs with the --test flag, I get the following error for myprogram.rs: "unresolved import 'num::complex::Complex'. Did you mean 'self::num::complex'? What's going on here? How can I import my program to create a test suite. Also, is this the preferred way of creating a test suite (using the 'mod' keyword)? Or should I compile 'myprogram.rs' into a crate and import the crate into 'test.rs'? -------------- next part -------------- An HTML attachment was scrubbed... URL: From farcaller at gmail.com Wed Jul 23 10:42:48 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Wed, 23 Jul 2014 18:42:48 +0100 Subject: [rust-dev] A shiny test framework In-Reply-To: <53CFF094.8010009@mozilla.com> References: <53CFF094.8010009@mozilla.com> Message-ID: On Wed, Jul 23, 2014 at 6:27 PM, Brian Anderson wrote: > I assume this translates to `#[test]` fns under the hood? > Exactly. That actually complicates `context` support a bit, as shiny needs to create nested modules. That would require forwarding all the views into child modules (as they are transparent for end developer). -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Wed Jul 23 12:52:56 2014 From: diwic at ubuntu.com (David Henningsson) Date: Wed, 23 Jul 2014 21:52:56 +0200 Subject: [rust-dev] Opt-In Built-In Traits (was: Mutable files) In-Reply-To: <53CD4B11.60909@mozilla.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> Message-ID: <53D01298.2060004@ubuntu.com> On 2014-07-21 19:17, Patrick Walton wrote: > On 7/21/14 8:49 AM, Tobias M?ller wrote: >> Patrick Walton wrote: >>> On 7/20/14 8:12 PM, David Henningsson wrote: >>>> From a language design perspective, maybe it would be more >>>> intuitive to >>>> have different syntaxes for copy and move, like: >> >> As a rust newbie, that aspect aways makes me a bit nervous. Two quite >> different operations with the same syntax and and simply changing a >> detail in the struct can be enough to switch between the two. > > This is the reason for Opt-In Built-In Traits. > > * Causing a move when you thought you were copying results in a compiler > error. > > * Causing a copy when you thought you were moving is harmless, as any > implicit copy in Rust has *exactly the same runtime semantics* as a > move, except that the compiler prevents you from using the value again. > > Again, we had that world before. It was extremely annoying to write > "move" all over the place. Be careful what you wish for. I find these arguments compelling, but if what we want to accomplish is a conscious choice between copy and move every time somebody makes a new struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not first-class enough. Maybe the move vs copy should be done by using different keywords, a few brainstorming examples: * "datastruct" for copy, "struct" for move * "simplestruct" for copy, "complexstruct" for move * "struct" for copy, "class" or "object" for move ...etc. // David From ntypanski at gmail.com Wed Jul 23 13:10:29 2014 From: ntypanski at gmail.com (Nathan Typanski) Date: Wed, 23 Jul 2014 16:10:29 -0400 Subject: [rust-dev] Using 'mod' for test code In-Reply-To: References: Message-ID: Hey Allen, I think you've got it backwards. You shouldn't be importing the regular module from the test one, but hiding the test modules within the regular one - behind a `#[cfg(test)]` directive. To apply this to your example, in `myprogram.rs` you should have a line #[cfg(test)] mod testprogram; and then in the test file, put `#[test]` above your individual tests. Then you compile `myprogram.rs` and, when compiled with `--test`, it compiles in the test code. Another, arguably more common practice, is to write #[cfg(test)] mod tests { use super::{foo, bar}; #[test] fn test_foo_is_bar { assert_eq!(foo(), bar()); } } For more on testing, check out Have fun learning Rust! Nathan From erick.tryzelaar at gmail.com Wed Jul 23 14:21:50 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 23 Jul 2014 14:21:50 -0700 Subject: [rust-dev] Announcing the Rust Community Calendar Message-ID: Good afternoon Rustaceans! I just created a community calender for all the Rust events happening throughout the Rust community around the world. You can find it at: https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles It's pretty bare bones at the moment, so if you have something you would like added to the list, please let me know and I'll get it on the calendar. I'll also see if we can get this embedded on http://www.rust-lang.org/. Thanks, Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan.software at gmail.com Wed Jul 23 22:44:02 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Wed, 23 Jul 2014 22:44:02 -0700 Subject: [rust-dev] Announcing the Rust Community Calendar In-Reply-To: References: Message-ID: Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm. There's a event signup on Eventbrite. In August there will be pizza. :) On Jul 23, 2014 2:22 PM, "Erick Tryzelaar" wrote: > Good afternoon Rustaceans! > > I just created a community calender for all the Rust events happening > throughout the Rust community around the world. You can find it at: > > > https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles > > It's pretty bare bones at the moment, so if you have something you would > like added to the list, please let me know and I'll get it on the calendar. > I'll also see if we can get this embedded on http://www.rust-lang.org/. > > Thanks, > Erick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Jul 23 23:12:58 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 23 Jul 2014 23:12:58 -0700 Subject: [rust-dev] Announcing the Rust Community Calendar In-Reply-To: References: Message-ID: Added it to the calendar, and gave you write access so you can add future events yourself :) On Wed, Jul 23, 2014 at 10:44 PM, Paul Nathan wrote: > Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm. > > There's a event signup on Eventbrite. > > In August there will be pizza. :) > On Jul 23, 2014 2:22 PM, "Erick Tryzelaar" > wrote: > >> Good afternoon Rustaceans! >> >> I just created a community calender for all the Rust events happening >> throughout the Rust community around the world. You can find it at: >> >> >> https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles >> >> It's pretty bare bones at the moment, so if you have something you would >> like added to the list, please let me know and I'll get it on the calendar. >> I'll also see if we can get this embedded on http://www.rust-lang.org/. >> >> Thanks, >> Erick >> >> _______________________________________________ >> 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 nical.silva at gmail.com Wed Jul 23 23:57:31 2014 From: nical.silva at gmail.com (Nicolas Silva) Date: Thu, 24 Jul 2014 08:57:31 +0200 Subject: [rust-dev] Announcing the Rust Community Calendar In-Reply-To: References: Message-ID: The Paris meetups are the third Monday of every month at 7pm. Cheers, Nical On Thu, Jul 24, 2014 at 8:12 AM, Erick Tryzelaar wrote: > Added it to the calendar, and gave you write access so you can add future > events yourself :) > > > On Wed, Jul 23, 2014 at 10:44 PM, Paul Nathan > wrote: > >> Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm. >> >> There's a event signup on Eventbrite. >> >> In August there will be pizza. :) >> On Jul 23, 2014 2:22 PM, "Erick Tryzelaar" >> wrote: >> >>> Good afternoon Rustaceans! >>> >>> I just created a community calender for all the Rust events happening >>> throughout the Rust community around the world. You can find it at: >>> >>> >>> https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles >>> >>> It's pretty bare bones at the moment, so if you have something you would >>> like added to the list, please let me know and I'll get it on the calendar. >>> I'll also see if we can get this embedded on http://www.rust-lang.org/. >>> >>> Thanks, >>> Erick >>> >>> _______________________________________________ >>> 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 simon.sapin at exyr.org Thu Jul 24 00:57:02 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 24 Jul 2014 08:57:02 +0100 Subject: [rust-dev] Announcing the Rust Community Calendar In-Reply-To: References: Message-ID: <53D0BC4E.6070908@exyr.org> On 23/07/14 22:21, Erick Tryzelaar wrote: > Good afternoon Rustaceans! > > I just created a community calender for all the Rust events happening > throughout the Rust community around the world. You can find it at: > > https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles > > It's pretty bare bones at the moment, so if you have something you would > like added to the list, please let me know and I'll get it on the > calendar. I'll also see if we can get this embedded on > http://www.rust-lang.org/. It?s not on a regular schedule at this point, but the next London meetup is on August 14: http://www.meetup.com/Rust-London-User-Group/events/196222722/ -- Simon Sapin From simon.sapin at exyr.org Thu Jul 24 01:00:01 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 24 Jul 2014 09:00:01 +0100 Subject: [rust-dev] London Rust meetup: 2014-08-14 Message-ID: <53D0BD01.3090804@exyr.org> Hello Rustaceans, The next London meetup is on August 14. Come and say hi! Nick Cameron a.k.a nrc will be giving a talk on DST. http://www.meetup.com/Rust-London-User-Group/events/196222722/ We?re also looking for speakers for this or future events. Let me know if you?re interested! Cheers, -- Simon Sapin From errordeveloper at gmail.com Thu Jul 24 02:18:19 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Thu, 24 Jul 2014 10:18:19 +0100 Subject: [rust-dev] London Rust meetup: 2014-08-14 In-Reply-To: <53D0BD01.3090804@exyr.org> References: <53D0BD01.3090804@exyr.org> Message-ID: Hi Simon, I and @farcaller where thinking to prepare a talk on Zinc project (http://zinc.rs/). What length of the talks you guys do? Cheers, -- Ilya On 24 July 2014 09:00, Simon Sapin wrote: > Hello Rustaceans, > > The next London meetup is on August 14. Come and say hi! Nick Cameron a.k.a > nrc will be giving a talk on DST. > > http://www.meetup.com/Rust-London-User-Group/events/196222722/ > > We're also looking for speakers for this or future events. Let me know if > you're interested! > > Cheers, > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From simon.sapin at exyr.org Thu Jul 24 07:05:17 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 24 Jul 2014 15:05:17 +0100 Subject: [rust-dev] London Rust meetup: 2014-08-14 In-Reply-To: References: <53D0BD01.3090804@exyr.org> Message-ID: <53D1129D.8060607@exyr.org> On 24/07/14 10:18, Ilya Dmitrichenko wrote: > Hi Simon, > > I and @farcaller where thinking to prepare a talk on Zinc project > (http://zinc.rs/). That looks cool. Do you want to present on August 14? > What length of the talks you guys do? The length is flexible, this is only the second time we?re doing in this in London so we?re still figuring it all out. Just remember that the event is in the evening and that there may be another talk in the same event. To give a number that I totally just made up, anything up to 30 minutes sounds good. -- Simon Sapin From kevin at sb.org Thu Jul 24 07:30:20 2014 From: kevin at sb.org (Kevin Ballard) Date: Thu, 24 Jul 2014 07:30:20 -0700 Subject: [rust-dev] Opt-In Built-In Traits (was: Mutable files) In-Reply-To: <53D01298.2060004@ubuntu.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <53D01298.2060004@ubuntu.com> Message-ID: <1406212220.11512.145231837.2D6BB3C4@webmail.messagingengine.com> On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote: > > > On 2014-07-21 19:17, Patrick Walton wrote: > > On 7/21/14 8:49 AM, Tobias M?ller wrote: > >> Patrick Walton wrote: > >>> On 7/20/14 8:12 PM, David Henningsson wrote: > >>>> From a language design perspective, maybe it would be more > >>>> intuitive to > >>>> have different syntaxes for copy and move, like: > >> > >> As a rust newbie, that aspect aways makes me a bit nervous. Two quite > >> different operations with the same syntax and and simply changing a > >> detail in the struct can be enough to switch between the two. > > > > This is the reason for Opt-In Built-In Traits. > > > > * Causing a move when you thought you were copying results in a compiler > > error. > > > > * Causing a copy when you thought you were moving is harmless, as any > > implicit copy in Rust has *exactly the same runtime semantics* as a > > move, except that the compiler prevents you from using the value again. > > > > Again, we had that world before. It was extremely annoying to write > > "move" all over the place. Be careful what you wish for. > > I find these arguments compelling, but if what we want to accomplish is > a conscious choice between copy and move every time somebody makes a new > struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not > first-class enough. > > Maybe the move vs copy should be done by using different keywords, a few > brainstorming examples: > > * "datastruct" for copy, "struct" for move > * "simplestruct" for copy, "complexstruct" for move > * "struct" for copy, "class" or "object" for move What would this solve? Nobody who?s using a type is going to care about the keyword used to introduce the type, they?re only going to care about the behavior of the type. Using `datastruct` instead of `struct` will have zero impact on the people writing let x: Foo = y; Actually, the whole notion of having to intentionally describe on every struct whether you want it to be Copy is my biggest objection to opt-in traits. The API Stability / documentation aspect is great, but it does seem like a burden to people writing once-off structs. What I?d actually like to see is for private structs to infer things like Copy and for public structs to then require it to be explicitly stated. I don?t know how to do this in a way that?s not confusing though. -Kevin From thikonom at gmail.com Thu Jul 24 07:44:37 2014 From: thikonom at gmail.com (T.Ikonomou) Date: Thu, 24 Jul 2014 15:44:37 +0100 Subject: [rust-dev] London Rust meetup: 2014-08-14 In-Reply-To: <53D1129D.8060607@exyr.org> References: <53D0BD01.3090804@exyr.org> <53D1129D.8060607@exyr.org> Message-ID: Hey all, Sounds good ! If you wish to present at the event on August 14, then could you please let us know a title of the presentation and a brief description of what it will involve so as to let attenders know. Thank you, Theo On Thu, Jul 24, 2014 at 3:05 PM, Simon Sapin wrote: > On 24/07/14 10:18, Ilya Dmitrichenko wrote: > >> Hi Simon, >> >> I and @farcaller where thinking to prepare a talk on Zinc project >> (http://zinc.rs/). >> > > That looks cool. Do you want to present on August 14? > > > What length of the talks you guys do? >> > > The length is flexible, this is only the second time we?re doing in this > in London so we?re still figuring it all out. Just remember that the event > is in the evening and that there may be another talk in the same event. To > give a number that I totally just made up, anything up to 30 minutes sounds > good. > > -- > Simon Sapin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.parreaux at gmail.com Thu Jul 24 08:59:41 2014 From: lionel.parreaux at gmail.com (Lionel Parreaux) Date: Thu, 24 Jul 2014 17:59:41 +0200 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> Message-ID: Hi, Could you provide a link to Patrick's description of size/alignment-passing implementation? I'm interested in these things. Well, there could be a warning if the compiler switches to such an implementation. It's arguably still better than not compiling at all. However, I don't have enough experience with type classes to know whether such situations actually happen in the real world. But didn't Nawfel BGH give an example of that? I'm not an expert in embedded systems, but I know that in some embedded systems, especially when memory is scarce or when the instruction cache is small, code size does matter more than the number of instructions executed per function call. It would probably be useful to be able to use generic libraries but still tweak the amount of monomoprhization in order to control the size of the generated executable. I don't know if this is the case for Rust, but executable size is an endemic problem in C++ because of wild template instantiation. I can't pronounce myself about the suitability of features in the Rust language, but it may be worth noting that some convenient high-level features are already present in the language, like garbage collection. Also, even C compilers output code with dramatically varying efficiency depending on the chosen levels of optimization -- and sometimes small details can disable optimization opportunities. Cheers, LP. 2014-07-23 4:13 GMT+02:00 Cameron Zwarich : > Even if we could do a size/alignment-passing implementation like Patrick > describes, would be it even be appropriate? It wouldn?t make sense for a > systems language to transparently switch to a dramatically less efficient > implementation mechanism without the programmer?s involvement. > > Is there any place where an unbounded number of dictionaries at runtime is > actually appropriate for solving a real problem in Rust? > > Cameron > > On Jul 22, 2014, at 10:16 AM, Lionel Parreaux > wrote: > > Hi, > > So traits seem to be quite similar to Haskell's classes, being also used > for parametric polymorphism. Now, Haskell classes are usually implemented > using runtime dictionary passing. In general, code cannot be specialized > for every function call, since there may be an unbounded number of > instances generated for it, as is explained in this reddit answer: > http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju > > Knowing that Rust implements traits using monomorphization of code (much > like C++ templates), I was curious about how it handled such cases, and > tried this: > > struct W { > f: T > } > > trait Show { > fn show(&self) -> int; > } > > impl Show for int { > fn show(&self) -> int { 666 } > } > impl Show for W { > fn show(&self) -> int { self.f.show()+1 } > } > impl Clone for W { > fn clone(&self) -> W { W{f:self.f.clone()} } > } > > fn foo(s: &S, n: int) { > let w = W{f:s.clone()}; > if n > 0 { foo(&w, n-1); } > } > > fn main() { > foo(&W{f:42i},42); > } > > > It gave me an "error: reached the recursion limit during > monomorphization", which... well, that's a possible solution :) > > I'm not sure whether this is a big problem in practice, but I was > wondering if it would be possible to switch to some runtime mechanism in > cases like this. Maybe we could make a special version of every generic > functions, that takes a dictionary at runtime and that would be able to > handle types unknown at compile-time. We would switch to this version when > monomorphization does not work. It could also allow dynamic linking of > libraries with generic functions, or it could be a way to compile some > programs (or some parts of programs) much faster. > I was thinking about, for example, an IDE where generic function calls to > types defined inside the files currently being edited use their dynamic > version, so that recompile times can be virtually inexistent (like Java). > On the other hand, the release build would of course monomorphize as much > as possible to make the perf optimal. > > Now the question is: would this conform to the current semantic of > monomorphization? Do special things happen during monomorphization that > cannot be reproduced at runtime? > This is the case in C++ (and one of the reasons why C++ templates are so > "bad"). Is it the case in Rust, which should already have all the required > info (type bounds) before monomorphization? > > I apologize if this has already been discussed. I could not find many > satisfying answers by googling. > > Cheers, > LP. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Jul 24 14:54:18 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 24 Jul 2014 17:54:18 -0400 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> Message-ID: <53D1808A.4010904@gmail.com> On 24/07/14 11:59 AM, Lionel Parreaux wrote: > > I can't pronounce myself about the suitability of features in the Rust > language, but it may be worth noting that some convenient high-level > features are already present in the language, like garbage collection. There isn't an implementation of garbage collection. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From banderson at mozilla.com Thu Jul 24 14:59:58 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 24 Jul 2014 14:59:58 -0700 Subject: [rust-dev] London Rust meetup: 2014-08-14 In-Reply-To: References: <53D0BD01.3090804@exyr.org> Message-ID: <53D181DE.7080705@mozilla.com> I'm really looking forward to this! On 07/24/2014 02:18 AM, Ilya Dmitrichenko wrote: > Hi Simon, > > I and @farcaller where thinking to prepare a talk on Zinc project > (http://zinc.rs/). > > What length of the talks you guys do? > > Cheers, From remarcg at gmx.net Thu Jul 24 15:46:26 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 00:46:26 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts Message-ID: <1869939.PKr16frPY1@purple> Hello Rust folk! I am new to Rust, and I have doubts concerning current language concepts. One example: in module ::std::num function pow() is defined: pub fn pow>(mut base: T, mut exp: uint) -> T { if exp == 1 { base } else { let mut acc = one::(); while exp > 0 { if (exp & 1) == 1 { acc = acc * base; } base = base * base; exp = exp >> 1; } acc } } In general this implementation is ok, but not really usable with BigInt. Of course, the call ':.std::num::pow(a, 1000)', 'a' is a BigInt, works. But this implementation is not adequate for big integers. Firstly, too many memory allocations during the computation (a specialized version can avoid these memory allocations), secondly, for big integers a specialized function for squaring (base * base) has to be used, because squaring can be done quite more efficient than multiplication (with big integers). So this function is much too slow and has to be overloaded, but: 1. Overloading is not supported (even the archaic C++ is providing this). 2. The footprint 'base: T' is not 100% suitable, for big integers the function definition fn pow(base: &BigInt, mut exp: uint) -> BigInt would be more appropriate, because the argument 'base' needs not to be modified (or reassigned), and a call by reference (avoiding a superfluous memory allocation) is more efficient in this case. Of cource, a specialized version of pow() could be implemented in trait BigInt, but this is only a workaround. And if a user only knows ::std::num::pow(), he will use an inappropriate implementation without being aware of this. Probably in this case it might be a solution to move pow() into a trait, but I'm speaking about a general problem. Rust 1.0 will be released, and someone is developing a new module for version 1.1. But some of the functions in 1.0 are inadequate for the new module, how to solve this without changing the API in 1.1? I think that function overloading may help in some cases, but the problem with inappropriate footprints remains. In my opinion this thing with the footprints (reference or not if the real type is unknown - that's why the concept with 'const' in C++ exists) is a conceptual design issue, but probably I do not yet fully understand Rust. BTW: the functions next_power_of_two(), and checked_next_power_of_two() are only defined for primitives (trait Primitive), but should also be applicable for big integers, I think . C heers, Gregor -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Thu Jul 24 15:55:27 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 25 Jul 2014 08:55:27 +1000 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1869939.PKr16frPY1@purple> References: <1869939.PKr16frPY1@purple> Message-ID: <53D18EDF.5090701@gmail.com> On 25/07/14 08:46, Gregor Cramer wrote: > > Probably in this case it might be a solution to move pow() into a > trait, but > > I'm speaking about a general problem. Rust 1.0 will be released, and > someone > > is developing a new module for version 1.1. But some of the functions > in 1.0 > > are inadequate for the new module, how to solve this without changing > the API > > in 1.1? > 1.0 will not stabilise every function in every library; we have precise stability attributes[1] so that the compiler can warn or error if you are using functionality that is subject to change. The goal is to have the entirety of the standard library classified and marked appropriately for 1.0. [1]: http://doc.rust-lang.org/master/rust.html#stability Huon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcguire at crsr.net Thu Jul 24 16:21:23 2014 From: mcguire at crsr.net (Tommy M. McGuire) Date: Thu, 24 Jul 2014 18:21:23 -0500 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D18EDF.5090701@gmail.com> References: <1869939.PKr16frPY1@purple> <53D18EDF.5090701@gmail.com> Message-ID: <53D194F3.1090605@crsr.net> On 07/24/2014 05:55 PM, Huon Wilson wrote: > 1.0 will not stabilise every function in every library; we have precise > stability attributes[1] so that the compiler can warn or error if you > are using functionality that is subject to change. The goal is to have > the entirety of the standard library classified and marked appropriately > for 1.0. > > > [1]: http://doc.rust-lang.org/master/rust.html#stability How would that solve the general problem? What would the stability of pow() be if Gregor had not brought up the issue now? -- Tommy M. McGuire mcguire at crsr.net From pwalton at mozilla.com Thu Jul 24 16:27:15 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 24 Jul 2014 16:27:15 -0700 (PDT) Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1869939.PKr16frPY1@purple> References: <1869939.PKr16frPY1@purple> Message-ID: <1766534899.8342738.1406244435342.JavaMail.zimbra@mozilla.com> On 7/24/14 3:46 PM, Gregor Cramer wrote: > Probably in this case it might be a solution to move pow() into a trait, but > I'm speaking about a general problem. Rust 1.0 will be released, and someone > is developing a new module for version 1.1. But some of the functions in 1.0 > are inadequate for the new module, how to solve this without changing > the API If the signature is wrong and we mistakenly freeze it, we can just introduce a new function with a different name. > in 1.1? I think that function overloading may help in some cases, but the > problem with inappropriate footprints remains. In my opinion this > thing with the footprints (reference or not if the real type is unknown - > that's why the concept with 'const' in C++ exists) is a conceptual design > issue, but probably I do not yet fully understand Rust. Overloading only helps some simple cases, and adds more complexity than it's worth (IMO). The problem with C++ isn't that it doesn't have enough features. Rust is deliberately omitting some features from C++ that don't pull their weight. Overloading is one of them. Patrick From dbau.pp at gmail.com Thu Jul 24 16:28:19 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 25 Jul 2014 09:28:19 +1000 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D194F3.1090605@crsr.net> References: <1869939.PKr16frPY1@purple> <53D18EDF.5090701@gmail.com> <53D194F3.1090605@crsr.net> Message-ID: <53D19693.5030904@gmail.com> On 25/07/14 09:21, Tommy M. McGuire wrote: > On 07/24/2014 05:55 PM, Huon Wilson wrote: >> 1.0 will not stabilise every function in every library; we have precise >> stability attributes[1] so that the compiler can warn or error if you >> are using functionality that is subject to change. The goal is to have >> the entirety of the standard library classified and marked appropriately >> for 1.0. >> >> >> [1]: http://doc.rust-lang.org/master/rust.html#stability > How would that solve the general problem? What would the stability of > pow() be if Gregor had not brought up the issue now? > > I was just pointing out that we aren't required to solve any/every library issue before 1.0 (since the text I was quoting was rightfully concerned about backwards incompatible API changes), not that this isn't an issue. Huon From steve at steveklabnik.com Thu Jul 24 17:11:40 2014 From: steve at steveklabnik.com (Steve) Date: Fri, 25 Jul 2014 00:11:40 +0000 Subject: [rust-dev] Artisan Assitant Launch: Please Confirm Subscription Message-ID: <9656357.20140725001140.53d1a0bc4ed065.70074750@mail19.us4.mandrillapp.com> ** Please Confirm Subscription ------------------------------------------------------------ Yes, subscribe me to this list. (http://steveklabnik.us2.list-manage.com/subscribe/confirm?u=31556dd6d5e1f7d449288b7d9&id=3bc3472c3e&e=4b68f345fe) If you received this email by mistake, simply delete it. You won't be subscribed if you don't click the confirmation link above. For questions about this list, please contact: steve at steveklabnik.com (mailto:steve at steveklabnik.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Artisan_Assitant_Launch.vcf Type: text/x-vcard Size: 215 bytes Desc: not available URL: From steve at steveklabnik.com Thu Jul 24 17:12:11 2014 From: steve at steveklabnik.com (Steve) Date: Fri, 25 Jul 2014 00:12:11 +0000 Subject: [rust-dev] Artisan Assitant Launch: Subscription Confirmed Message-ID: <9656357.20140725001211.53d1a0db0e08f9.86986282@mail4.mcsignup.com> Your subscription to our list has been confirmed. For your records, here is a copy of the information you submitted to us... * Email Address: rust-dev at mozilla.org * First Name: * Last Name: If at any time you wish to stop receiving our emails, you can: unsubscribe here (http://steveklabnik.us2.list-manage1.com/unsubscribe?u=31556dd6d5e1f7d449288b7d9&id=3bc3472c3e&e=4b68f345fe) You may also contact us at: steve at steveklabnik.com (mailto:steve at steveklabnik.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Artisan_Assitant_Launch.vcf Type: text/x-vcard Size: 215 bytes Desc: not available URL: From steve at steveklabnik.com Thu Jul 24 18:21:04 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Thu, 24 Jul 2014 21:21:04 -0400 Subject: [rust-dev] Artisan Assitant Launch: Subscription Confirmed In-Reply-To: <9656357.20140725001211.53d1a0db0e08f9.86986282@mail4.mcsignup.com> References: <9656357.20140725001211.53d1a0db0e08f9.86986282@mail4.mcsignup.com> Message-ID: Sorry, all. I have a weekend project which has a mailchimp email signup on the home page, and apparently someone went and signed up rust-dev. What a weird coincidence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Thu Jul 24 23:30:43 2014 From: diwic at ubuntu.com (David Henningsson) Date: Fri, 25 Jul 2014 08:30:43 +0200 Subject: [rust-dev] Opt-In Built-In Traits In-Reply-To: <1406212220.11512.145231837.2D6BB3C4@webmail.messagingengine.com> References: <53CC6CEA.5070100@ubuntu.com> <53CC6DEB.40508@mozilla.com> <53CC7D67.6050400@ubuntu.com> <53CC8525.7030008@ubuntu.com> <53CC9168.4010601@mozilla.com> <1982800289427648976.393648address_is-invalid.invalid@news.gmane.org> <53CD4B11.60909@mozilla.com> <53D01298.2060004@ubuntu.com> <1406212220.11512.145231837.2D6BB3C4@webmail.messagingengine.com> Message-ID: <53D1F993.8010606@ubuntu.com> On 2014-07-24 16:30, Kevin Ballard wrote: > On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote: >> >> >> On 2014-07-21 19:17, Patrick Walton wrote: >>> On 7/21/14 8:49 AM, Tobias M?ller wrote: >>>> Patrick Walton wrote: >>>>> On 7/20/14 8:12 PM, David Henningsson wrote: >>>>>> From a language design perspective, maybe it would be more >>>>>> intuitive to >>>>>> have different syntaxes for copy and move, like: >>>> >>>> As a rust newbie, that aspect aways makes me a bit nervous. Two quite >>>> different operations with the same syntax and and simply changing a >>>> detail in the struct can be enough to switch between the two. >>> >>> This is the reason for Opt-In Built-In Traits. >>> >>> * Causing a move when you thought you were copying results in a compiler >>> error. >>> >>> * Causing a copy when you thought you were moving is harmless, as any >>> implicit copy in Rust has *exactly the same runtime semantics* as a >>> move, except that the compiler prevents you from using the value again. >>> >>> Again, we had that world before. It was extremely annoying to write >>> "move" all over the place. Be careful what you wish for. >> >> I find these arguments compelling, but if what we want to accomplish is >> a conscious choice between copy and move every time somebody makes a new >> struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not >> first-class enough. >> >> Maybe the move vs copy should be done by using different keywords, a few >> brainstorming examples: >> >> * "datastruct" for copy, "struct" for move >> * "simplestruct" for copy, "complexstruct" for move >> * "struct" for copy, "class" or "object" for move > > What would this solve? Nobody who?s using a type is going to care about > the keyword used to introduce the type, they?re only going to care about > the behavior of the type. Using `datastruct` instead of `struct` will > have zero impact on the people writing > > let x: Foo = y; > > Actually, the whole notion of having to intentionally describe on every > struct whether you want it to be Copy is my biggest objection to opt-in > traits. The API Stability / documentation aspect is great, but it does > seem like a burden to people writing once-off structs. Is it the typing or the decision that would be a burden? My idea was mostly to reduce the typing compared to writing "Deriving(Data)" all the time. > What I?d actually like to see is for private structs to infer things > like Copy and for public structs to then require it to be explicitly > stated. I don?t know how to do this in a way that?s not confusing > though. That's actually an interesting idea. Maybe something like this? struct foo1 {} /* Ok, copy or move is inferred */ #[Deriving(Data)] pub struct foo2 {} /* Ok, copy behavior advertised */ #[Deriving(NoCopy)] pub struct foo3 {} /* Ok, move behavior advertised */ pub struct foo4 {} /* Compile error, move or copy behavior must be explicitly stated */ // David From remarcg at gmx.net Fri Jul 25 03:47:03 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 12:47:03 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1766534899.8342738.1406244435342.JavaMail.zimbra@mozilla.com> References: <1869939.PKr16frPY1@purple> <1766534899.8342738.1406244435342.JavaMail.zimbra@mozilla.com> Message-ID: <1633841.mpM9ie7tDc@purple> Hi Patrick, > If the signature is wrong and we mistakenly freeze it, we can just introduce > a new function with a different name. But this is a severe design issue, to introduce new function names. This makes generic programming impossible. Now the user has to distinguish between the types, but this is the task of the compiler. > Overloading only helps some simple cases, and adds more complexity than it's > worth (IMO). Overloading is the only way to specialize functions, and this is the only way to allow generic programming. Without specializing we are back to the bad old days, where the user has to call the appropriate function for a specific object, but in a modern programming language the compiler is doing these things. > The problem with C++ isn't that it doesn't have enough features. Rust is > deliberately omitting some features from C++ that don't pull their weight. > Overloading is one of them. I think that some weights are unavoidable. And I cannot see serious drawbacks with function overloading, but I see serious drawbacks without: As I saw Rust the first time, I was impressed, and I decided to overwork the big integer module (I've already written a big integer library in C), because the current impementation is much too slow, it suffers from: 1. too many memory allocations 2. some algorithms are a bit naive. And at first I tried to specialize std::num::pow(), but I gave up immediately, because I cannot specialize. And without specializing this function I cannot realize a proper implementation and design, and I'm never doing half-baken things. So I gave up at all. The current design in Rust does not allow: 1. Generic programming, in current design of Rust the user has to know, which function to call for a specific object, and has to use switch (or match) statements to call it (and if he forget the right functions and uses std::num::pow(), his program will suffer). This is a programming style 30 years ago, as I started to write programs. 2. Uniform function signatures, currently the user has to decide about using a reference or not, but the compiler should decide. If the compiler is deciding, whether an argument is given by value or by reference, then the problem with the signature will vanish. And the compiler is better to decide than the user. One more advantage: the user must not know whether to use a reference or not when calling a function/method. One exception: a mutable argument, in this case a reference will be used explicitely by the user, when specifiying the signature, and when calling the function. One more drawbacks without overloading: The user defines two print methods: pub fn print(line : string) -> bool; pub fn print(line : string, max_line_length : uint) -> bool; Not possible, he has to use different names. An alternative definition would be: pub fn print(line : string) -> bool; pub fn print_with_maxlen(line : string, len : uint) -> bool; 30 years ago this was the normal way, but nowadays, it's a No-Go. The current status of Rust is: it does not allow proper software design. And that's bad, because a successor for C++ is needed. Of course, a successor of C++ does not mean: a better C++. It means, a completely new language conecept, like Rust. And it does not mean: avoid the good things of C++, like specialization of functions. Cheers, Gregor -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Fri Jul 25 04:43:23 2014 From: slabode at aim.com (SiegeLordEx) Date: Fri, 25 Jul 2014 07:43:23 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1869939.PKr16frPY1@purple> References: <1869939.PKr16frPY1@purple> Message-ID: <53D242DB.70108@aim.com> On 07/24/2014 06:46 PM, Gregor Cramer wrote: > 1. Overloading is not supported (even the archaic C++ is providing this). I should note that Rust provides a limited form of overloading via the trait-double dispatch trick: trait PowImpl { fn pow(self, exp: uint) -> Res; } fn pow>(t: T, exp: uint) -> Res { t.pow(exp) } impl PowImpl for int { fn pow(self, exp: uint) -> int { ... } } impl<'l> PowImpl for &'l BigInt { fn pow(self, exp: uint) -> BigInt { ... } } Note that this is not suitable for generic code, which is kind of an under-appreciated problem. Currently Rust places running generic code above writing efficient code, which is not a trade-off it should be making imo. In my matrix library I opted for making my types useless for generic code in the quest for efficiency, and I find it unfortunate that I had to do that. > > 2. The footprint 'base: T' is not 100% suitable, for big integers the > function > > definition > > fn pow(base: &BigInt, mut exp: uint) -> BigInt > > would be more appropriate, because the argument 'base' needs not to be > > modified (or reassigned), and a call by reference (avoiding a superfluous > > memory allocation) is more efficient in this case. > Yes, I concur on most of these points and I've brought up some related points before. The operator overloading technique used by Rust is antithetical to efficient generic code. The core numeric traits and functions are currently designed only with built-in types in mind, causing BigInt (and others, e.g. matrices) to suffer. I don't know how to fix these things, but perhaps auto-ref and ad-hoc operator overloading (it works for Haskell, why not for Rust?) would be part of the solution. Ultimately, I suspect that function overloading (the Rust trait double-dispatch trick above may be sufficient with auto-ref) will be of critical importance. This problem is very under-appreciated and I hope this aspect of the language is not stabilized by 1.0. If the relevant operator overload is removed from BigInt, then one temporary solution will emerge: you won't be able to call this pow function at all, and will be forced to call a specialized version. As long as the core is designed for built-in types only, BigInt should stop pretending to be one. I think this is what should be done in the interim. -SL From marijnh at gmail.com Fri Jul 25 05:06:26 2014 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 25 Jul 2014 14:06:26 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1633841.mpM9ie7tDc@purple> References: <1869939.PKr16frPY1@purple> <1766534899.8342738.1406244435342.JavaMail.zimbra@mozilla.com> <1633841.mpM9ie7tDc@purple> Message-ID: Hello Gregor, Firstly, blanket statements like "This makes generic programming impossible" and "it does not allow proper software design" are unneccesary hyperbole, and do not help the discussion in any way. Traits provide a more well-defined, easier to reason about alternative to overloading. They do require the author of an algorithm to decide ahead of time whether this algorithm needs to be specializeable, which I guess C++-style overloading does not. Whether that is a good or a bad thing is debatable, but it is not true that Rust lacks a feature for specialization. Best, Marijn From changchun.fan at qq.com Fri Jul 25 05:10:14 2014 From: changchun.fan at qq.com (=?gb18030?B?t7azpLS6?=) Date: Fri, 25 Jul 2014 20:10:14 +0800 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1633841.mpM9ie7tDc@purple> References: <1869939.PKr16frPY1@purple> <1766534899.8342738.1406244435342.JavaMail.zimbra@mozilla.com> <1633841.mpM9ie7tDc@purple> Message-ID: Hi all, I have an idea about data types here. We have two `product types` here, tuples and structs, but only one `sum types`, which is `enum`. The tuple's members have anonymous names. There is a missing type which is `sum type`with anonymous members. Why shouldn't we have another simpler `sum type` here. It can be defined like `type sum_type = int | &str | (int, &str)`. It is like `enum`, but the members are anonymous. Now, the function overloading is very obvious. `fn overload( arg : sum_type ) ` is just fine. And, IMHO, this design is much clearer than traditional overloading, more explicit. Apologize for my poor English. Feel free to ignore my proposal if it's silly. Thanks, Changchun ------------------ Original ------------------ From: "Gregor Cramer";; Date: Fri, Jul 25, 2014 06:47 PM To: "rust-dev"; Subject: Re: [rust-dev] std::num::pow() is inadequate / language concepts Hi Patrick, > If the signature is wrong and we mistakenly freeze it, we can just introduce > a new function with a different name. But this is a severe design issue, to introduce new function names. This makes generic programming impossible. Now the user has to distinguish between the types, but this is the task of the compiler. > Overloading only helps some simple cases, and adds more complexity than it's > worth (IMO). Overloading is the only way to specialize functions, and this is the only way to allow generic programming. Without specializing we are back to the bad old days, where the user has to call the appropriate function for a specific object, but in a modern programming language the compiler is doing these things. > The problem with C++ isn't that it doesn't have enough features. Rust is > deliberately omitting some features from C++ that don't pull their weight. > Overloading is one of them. I think that some weights are unavoidable. And I cannot see serious drawbacks with function overloading, but I see serious drawbacks without: As I saw Rust the first time, I was impressed, and I decided to overwork the big integer module (I've already written a big integer library in C), because the current impementation is much too slow, it suffers from: 1. too many memory allocations 2. some algorithms are a bit naive. And at first I tried to specialize std::num::pow(), but I gave up immediately, because I cannot specialize. And without specializing this function I cannot realize a proper implementation and design, and I'm never doing half-baken things. So I gave up at all. The current design in Rust does not allow: 1. Generic programming, in current design of Rust the user has to know, which function to call for a specific object, and has to use switch (or match) statements to call it (and if he forget the right functions and uses std::num::pow(), his program will suffer). This is a programming style 30 years ago, as I started to write programs. 2. Uniform function signatures, currently the user has to decide about using a reference or not, but the compiler should decide. If the compiler is deciding, whether an argument is given by value or by reference, then the problem with the signature will vanish. And the compiler is better to decide than the user. One more advantage: the user must not know whether to use a reference or not when calling a function/method. One exception: a mutable argument, in this case a reference will be used explicitely by the user, when specifiying the signature, and when calling the function. One more drawbacks without overloading: The user defines two print methods: pub fn print(line : string) -> bool; pub fn print(line : string, max_line_length : uint) -> bool; Not possible, he has to use different names. An alternative definition would be: pub fn print(line : string) -> bool; pub fn print_with_maxlen(line : string, len : uint) -> bool; 30 years ago this was the normal way, but nowadays, it's a No-Go. The current status of Rust is: it does not allow proper software design. And that's bad, because a successor for C++ is needed. Of course, a successor of C++ does not mean: a better C++. It means, a completely new language conecept, like Rust. And it does not mean: avoid the good things of C++, like specialization of functions. Cheers, Gregor -------------- next part -------------- An HTML attachment was scrubbed... URL: From remarcg at gmx.net Fri Jul 25 06:26:59 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 15:26:59 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1870008.zEzlFkSMpK@purple> References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> Message-ID: <9634576.BCoQrL1ygE@purple> Hi Marijn, > Firstly, blanket statements like "This makes generic programming > impossible" and "it does not allow proper software design" are > unneccesary hyperbole, and do not help the discussion in any way. You're not right, my statement wasn't blanket, it was my result after I tried to overwork the big integer library, and I have mentioned this: I gave up at all. (I'm doing software design and implementation since more than 30 years, and I never accept compromises, this is the way how to develop magnificient software). > Traits provide a more well-defined, easier to reason about alternative > to overloading. They do require the author of an algorithm to decide > ahead of time whether this algorithm needs to be specializeable, which > I guess C++-style overloading does not. Yes, the traits are great, I'm impressed, as I said before, and in fact Rust is really great, despite a few facts, otherwise I wouldn't subscribe to this mailing list. And my goal is to be constructive, don't worry if I'm a bit euphoric, such things happens. Nethertheless, it gave up to overwork the big integer libary because I cannot specialize std::num::pow(). There is no way to proceed with a proper design. > Whether that is a good or a > bad thing is debatable, but it is not true that Rust lacks a feature > for specialization. There is a lack in the current language concept, std::num::pow() is inadequate due to this language concept, and std::num::pow() is only one example for this fact. I will repeat the problem with signatures. Currently pow() is declared as following: pub fn pow>(mut base: T, mut exp: uint) -> T; That't 100% ok. The user will call this function in this way: pow(a) // a is i32 Perfect. Now I need a specialized function for BigInt: [#overload] pub fn pow(base: &BigInt, mut exp: uint) -> T; There's a problem (beside the missing overloading feature): the specialized version requires a reference. Same problem if I'm calling this function: pow(&a) // a is BigInt The user has to know how to call a function, depending on the type. But a proper function specialization would be: [#overload] pub fn pow(base: BigInt, mut exp: uint) -> T; And so the function call is as expected, like with other numeric types: pow(a) // a is BigInt But there is now a problem in this function definition, BigInt is given as a copy, and this is a software design issue (superfluous memory allocation). And this currently happens if the user is calling std::num::pow() with a numeric type like BigInt (apart from other performance penalties in pow()). That's what I've mentioned that the compiler should decide whether an argument is given by reference or by value. In this way the latter approach works. And in the case that a function willl modify an argument (in-out value), for example: fn mul_vec(acc : &mut [BigDigit], base: &mut [BigDigit], mut exp:uint) the call of this function would be: mul_vec(&a, &b, exp) This concept will not change, because here it has to be clear that an argument will be changed (furthermore the compiler should give a warning if a function is not changing a mutable argument). I think that this approach is even superior to the 'const' concept of C++, and it fit's with the great overall concept of Rust (especially with the owner/borrower concept). I try to show the problems if function specialization (overloading) is not supported. A stable software design is problematic. Adding a new module, which will use existing function declarations, is impossible in some cases. Currently I cannot implement a specialized version of pow() for BigInt, adding a new function for a different numeric type is only a hack, and moving this function into a trait is not solving the general problem, because pow() is only one example. (Beside: it's not my decision to move pow() into a trait.) Cheers, Gregor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfager at gmail.com Fri Jul 25 07:05:34 2014 From: jfager at gmail.com (Jason Fager) Date: Fri, 25 Jul 2014 10:05:34 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <9634576.BCoQrL1ygE@purple> References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: For the specific issue of exponentiation, you might be interested in https://github.com/rust-lang/rfcs/pull/172 On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer wrote: > Hi Marijn, > > > > > Firstly, blanket statements like "This makes generic programming > > > impossible" and "it does not allow proper software design" are > > > unneccesary hyperbole, and do not help the discussion in any way. > > > > You're not right, my statement wasn't blanket, it was my result > > after I tried to overwork the big integer library, and I have mentioned > this: > > I gave up at all. (I'm doing software design and implementation since > > more than 30 years, and I never accept compromises, this is the way > > how to develop magnificient software). > > > > > Traits provide a more well-defined, easier to reason about alternative > > > to overloading. They do require the author of an algorithm to decide > > > ahead of time whether this algorithm needs to be specializeable, which > > > I guess C++-style overloading does not. > > > > Yes, the traits are great, I'm impressed, as I said before, and in fact > Rust > > is really great, despite a few facts, otherwise I wouldn't subscribe to > > this mailing list. And my goal is to be constructive, don't worry if I'm > > a bit euphoric, such things happens. Nethertheless, it gave up to overwork > > the big integer libary because I cannot specialize std::num::pow(). There > is > > no way to proceed with a proper design. > > > > > Whether that is a good or a > > > bad thing is debatable, but it is not true that Rust lacks a feature > > > for specialization. > > > > There is a lack in the current language concept, std::num::pow() > > is inadequate due to this language concept, and std::num::pow() is > > only one example for this fact. > > > > I will repeat the problem with signatures. Currently pow() is declared > > as following: > > > > pub fn pow>(mut base: T, mut exp: uint) -> T; > > > > That't 100% ok. The user will call this function in this way: > > > > pow(a) // a is i32 > > > > Perfect. Now I need a specialized function for BigInt: > > > > [#overload] > > pub fn pow(base: &BigInt, mut exp: uint) -> T; > > > > There's a problem (beside the missing overloading feature): the > > specialized version requires a reference. Same problem if I'm > > calling this function: > > > > pow(&a) // a is BigInt > > > > The user has to know how to call a function, depending on the type. > > But a proper function specialization would be: > > > > [#overload] > > pub fn pow(base: BigInt, mut exp: uint) -> T; > > > > And so the function call is as expected, like with other numeric types: > > > > pow(a) // a is BigInt > > > > But there is now a problem in this function definition, BigInt is given as > > a copy, and this is a software design issue (superfluous memory > allocation). > > And this currently happens if the user is calling std::num::pow() with a > > numeric type like BigInt (apart from other performance penalties in pow()). > > > > That's what I've mentioned that the compiler should decide whether an > > argument is given by reference or by value. In this way the latter approach > > works. And in the case that a function willl modify an argument (in-out > > value), for example: > > > > fn mul_vec(acc : &mut [BigDigit], base: &mut [BigDigit], mut exp:uint) > > > > the call of this function would be: > > > > mul_vec(&a, &b, exp) > > > > This concept will not change, because here it has to be clear that an > argument > > will be changed (furthermore the compiler should give a warning if a > function > > is not changing a mutable argument). I think that this approach is even > > superior to the 'const' concept of C++, and it fit's with the great overall > > concept of Rust (especially with the owner/borrower concept). > > > > I try to show the problems if function specialization (overloading) is not > > supported. A stable software design is problematic. Adding a new module, > > which will use existing function declarations, is impossible in some cases. > > Currently I cannot implement a specialized version of pow() for BigInt, > adding > > a new function for a different numeric type is only a hack, and moving this > > function into a trait is not solving the general problem, because pow() is > > only one example. (Beside: it's not my decision to move pow() into a > trait.) > > > > Cheers, > > Gregor > > > _______________________________________________ > 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 thesaint1987 at googlemail.com Fri Jul 25 09:47:01 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Fri, 25 Jul 2014 18:47:01 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <9634576.BCoQrL1ygE@purple> References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: > I gave up at all. (I'm doing software design and implementation since > more than 30 years, and I never accept compromises, this is the way > how to develop magnificient software). Hum, I would almost strongly disagree. I would even go as far as saying that you won't develop any kind of reasonable software outside of academic environments without making a whole fairytale of compromises. In fact, everything is a compromise. Besides that, giving up just because you can't overload functions, in a language that is still evolving also sounds rather strange. More legit would be to mention the issue, ask how the designers of the language would solve it and maybe suggest what could be improved etc... > the big integer libary because I cannot specialize std::num::pow(). There is > no way to proceed with a proper design. Well, I guess you did nothing but C++ in the last 30 years then? Because I can't recall many languages that would allow this sort of thing. How would C# and Java's Math::Pow() would work out in this case? How would it work out in C? How would it work out in Python, JavaScript, etc... the list is ... quite long. The question is always about compromise. Shall rust include a language feature to make some things easier for the sake of introducing tons of problems as well? Java is about the least expressive language we have at the time (appears a bit like the greatest common denominator of all imperative languages) and I would say only few people are out there who would say that you can't do proper software design with it. It might not be a concise and pleasing as "GOOD C++ design is", but then again "GOOD C++ design" is very hard to archieve and thus begs the questions if it is even worth it to make a language that complicated so that magnificient (academic) design is possible at the cost of making the average (industrial) design horrible. > pub fn pow>(mut base: T, mut exp: uint) -> T; I agree this definition appears to be very strange to me. In more than one way. First it implies that the existing implementation works by somehow multiplying types with the expontential trick " a * a = b, b * b = c, c * c = a^6" etc... This is an unacceptable restriction for me, as this kind of evaluation might not be the best in many cases and we are talking about a standard library function after all. It should always allow the BEST implementation, not just some implementation. Here we clearly need a better concept. And this concept needs to be designed & defined. And you could start by doing this, instead of just giving up ;). From thesaint1987 at googlemail.com Fri Jul 25 09:53:58 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Fri, 25 Jul 2014 18:53:58 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: Sorry... I meant a^8 xD... And overlaoding is not a great concept in general, IMO. What Rust could do is copy template specialization. So that I can say: pub fn pow>(mut base: T, mut exp: uint) -> T; // uses the exponential trick pub fn pow(mut base: i64, mut exp: uint) -> i64; // uses some cool processor features if available pub fn pow(mut base: &BigInt, mut exp: uint) -> BigInt; // uses some mighty algorithm that is not naive ;) This avoids the horrible confusing of having functions acting totally different depending on parameter count. Of course there should still be the requirement in place that all specializations fulfill the original template contraints. And in the best case also need to fullfill some generic unitests that give a specification to ensure that the user is not confused by this sort of "overloading". On Fri, Jul 25, 2014 at 6:47 PM, Christoph Husse wrote: >> I gave up at all. (I'm doing software design and implementation since >> more than 30 years, and I never accept compromises, this is the way >> how to develop magnificient software). > > Hum, I would almost strongly disagree. I would even go as far as > saying that you won't develop any kind of reasonable software outside > of academic environments without making a whole fairytale of > compromises. In fact, everything is a compromise. Besides that, giving > up just because you can't overload functions, in a language that is > still evolving also sounds rather strange. More legit would be to > mention the issue, ask how the designers of the language would solve > it and maybe suggest what could be improved etc... > >> the big integer libary because I cannot specialize std::num::pow(). There is >> no way to proceed with a proper design. > > Well, I guess you did nothing but C++ in the last 30 years then? > Because I can't recall many languages that would allow this sort of > thing. How would C# and Java's Math::Pow() would work out in this > case? How would it work out in C? How would it work out in Python, > JavaScript, etc... the list is ... quite long. > > The question is always about compromise. Shall rust include a language > feature to make some things easier for the sake of introducing tons of > problems as well? > Java is about the least expressive language we have at the time > (appears a bit like the greatest common denominator of all imperative > languages) and I would say only few people are out there who would say > that you can't do proper software design with it. It might not be a > concise and pleasing as "GOOD C++ design is", but then again "GOOD C++ > design" is very hard to archieve and thus begs the questions if it is > even worth it to make a language that complicated so that magnificient > (academic) design is possible at the cost of making the average > (industrial) design horrible. > >> pub fn pow>(mut base: T, mut exp: uint) -> T; > > I agree this definition appears to be very strange to me. In more than > one way. First it implies that the existing implementation works by > somehow multiplying types with the expontential trick " a * a = b, b * > b = c, c * c = a^6" etc... > This is an unacceptable restriction for me, as this kind of evaluation > might not be the best in many cases and we are talking about a > standard library function after all. It should always allow the BEST > implementation, not just some implementation. > > Here we clearly need a better concept. And this concept needs to be > designed & defined. And you could start by doing this, instead of just > giving up ;). From pcwalton at mozilla.com Fri Jul 25 10:02:38 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 10:02:38 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <9634576.BCoQrL1ygE@purple> References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: <53D28DAE.1050201@mozilla.com> On 7/25/14 6:26 AM, Gregor Cramer wrote: > And so the function call is as expected, like with other numeric types: > > pow(a) // a is BigInt > > But there is now a problem in this function definition, BigInt is given as > a copy, and this is a software design issue (superfluous memory allocation). > And this currently happens if the user is calling std::num::pow() with a > numeric type like BigInt (apart from other performance penalties in pow()). That solution doesn't work for generic code, because Rust doesn't do ad-hoc templates like C++. A function that is generic over the bigint and int "pow" functions has to have one signature for "pow". Otherwise you could get errors during template instantiation time, which is something Rust strictly avoids. > That's what I've mentioned that the compiler should decide whether an > argument is given by reference or by value. That doesn't work. It would have numerous problems with the borrow check, etc. > I try to show the problems if function specialization (overloading) is not > supported. Sorry, but it's not convincing to me. Patrick From pcwalton at mozilla.com Fri Jul 25 10:04:37 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 10:04:37 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D242DB.70108@aim.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> Message-ID: <53D28E25.3060007@mozilla.com> On 7/25/14 4:43 AM, SiegeLordEx wrote: > Yes, I concur on most of these points and I've brought up some related > points before. The operator overloading technique used by Rust is > antithetical to efficient generic code. The core numeric traits and > functions are currently designed only with built-in types in mind, > causing BigInt (and others, e.g. matrices) to suffer. I don't know how > to fix these things, but perhaps auto-ref and ad-hoc operator > overloading (it works for Haskell, why not for Rust?) would be part of > the solution. Neither auto-ref or ad-hoc operator overloading would let you write a generic function that calls `pow` and works optimally with both bigints and ints. I think the only thing that would work is something like C++ ad-hoc templates, which is a road I don't want to go down. > Ultimately, I suspect that function overloading (the Rust > trait double-dispatch trick above may be sufficient with auto-ref) will > be of critical importance. This problem is very under-appreciated and I > hope this aspect of the language is not stabilized by 1.0. I don't think we should be trying to solve it. Patrick From jhaberman at gmail.com Fri Jul 25 10:10:20 2014 From: jhaberman at gmail.com (Josh Haberman) Date: Fri, 25 Jul 2014 10:10:20 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D28E25.3060007@mozilla.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> Message-ID: On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton wrote: > Neither auto-ref or ad-hoc operator overloading > would let you write a generic function that calls > `pow` and works optimally with both bigints and > ints. I think the only thing that would work is > something like C++ ad-hoc templates, which is > a road I don't want to go down. Could you explain what you mean by "ad-hoc templates", and how this differs from Rust's templates? From oscar at twitter.com Fri Jul 25 10:11:00 2014 From: oscar at twitter.com (Oscar Boykin) Date: Fri, 25 Jul 2014 07:11:00 -1000 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: Did I miss a point in this thread where using a typeclass/trait to implement exponentiation was dismissed? This function could be changed to: fn pow(base: T, exp: uint) -> T { base.pow(exp) } trait HasPow { fn pow(self: Self, exp: uint) -> Self } Or, just use HasPow in your code. Why is this not a solution? On Fri, Jul 25, 2014 at 6:53 AM, Christoph Husse < thesaint1987 at googlemail.com> wrote: > Sorry... I meant a^8 xD... > > And overlaoding is not a great concept in general, IMO. > What Rust could do is copy template specialization. So that I can say: > > pub fn pow>(mut base: T, mut exp: uint) -> T; // > uses the exponential trick > > pub fn pow(mut base: i64, mut exp: uint) -> i64; // uses some > cool processor features if available > > pub fn pow(mut base: &BigInt, mut exp: uint) -> BigInt; // > uses some mighty algorithm that is not naive ;) > > This avoids the horrible confusing of having functions acting totally > different depending on parameter count. Of course there should still > be the requirement in place that all specializations fulfill the > original template contraints. And in the best case also need to > fullfill some generic unitests that give a specification to ensure > that the user is not confused by this sort of "overloading". > > > On Fri, Jul 25, 2014 at 6:47 PM, Christoph Husse > wrote: > >> I gave up at all. (I'm doing software design and implementation since > >> more than 30 years, and I never accept compromises, this is the way > >> how to develop magnificient software). > > > > Hum, I would almost strongly disagree. I would even go as far as > > saying that you won't develop any kind of reasonable software outside > > of academic environments without making a whole fairytale of > > compromises. In fact, everything is a compromise. Besides that, giving > > up just because you can't overload functions, in a language that is > > still evolving also sounds rather strange. More legit would be to > > mention the issue, ask how the designers of the language would solve > > it and maybe suggest what could be improved etc... > > > >> the big integer libary because I cannot specialize std::num::pow(). > There is > >> no way to proceed with a proper design. > > > > Well, I guess you did nothing but C++ in the last 30 years then? > > Because I can't recall many languages that would allow this sort of > > thing. How would C# and Java's Math::Pow() would work out in this > > case? How would it work out in C? How would it work out in Python, > > JavaScript, etc... the list is ... quite long. > > > > The question is always about compromise. Shall rust include a language > > feature to make some things easier for the sake of introducing tons of > > problems as well? > > Java is about the least expressive language we have at the time > > (appears a bit like the greatest common denominator of all imperative > > languages) and I would say only few people are out there who would say > > that you can't do proper software design with it. It might not be a > > concise and pleasing as "GOOD C++ design is", but then again "GOOD C++ > > design" is very hard to archieve and thus begs the questions if it is > > even worth it to make a language that complicated so that magnificient > > (academic) design is possible at the cost of making the average > > (industrial) design horrible. > > > >> pub fn pow>(mut base: T, mut exp: uint) -> T; > > > > I agree this definition appears to be very strange to me. In more than > > one way. First it implies that the existing implementation works by > > somehow multiplying types with the expontential trick " a * a = b, b * > > b = c, c * c = a^6" etc... > > This is an unacceptable restriction for me, as this kind of evaluation > > might not be the best in many cases and we are talking about a > > standard library function after all. It should always allow the BEST > > implementation, not just some implementation. > > > > Here we clearly need a better concept. And this concept needs to be > > designed & defined. And you could start by doing this, instead of just > > giving up ;). > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Oscar Boykin :: @posco :: http://twitter.com/posco -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Fri Jul 25 10:30:56 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 10:30:56 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <1870008.zEzlFkSMpK@purple> <9634576.BCoQrL1ygE@purple> Message-ID: <53D29450.9070208@mozilla.com> On 7/25/14 10:11 AM, Oscar Boykin wrote: > Did I miss a point in this thread where using a typeclass/trait to > implement exponentiation was dismissed? > > This function could be changed to: > > fn pow(base: T, exp: uint) -> T { base.pow(exp) } > > trait HasPow { > fn pow(self: Self, exp: uint) -> Self > } > > Or, just use HasPow in your code. > > Why is this not a solution? Yes, I was about to bring this up. You might want to conceivably have different types for the parameters, which Associated Types would solve nicely. For the maximum genericity: trait Pow { type This; type Exp; type Result; fn pow(this: This, exp: Exp) -> Result; } You can then write functions that take Powable things: fn whatever(p: P) -> P { p.pow(p, 1) } Now the only restriction that is left is that all instances of `Pow` must have the same number of arguments. Presumably this is not too onerous. :) Patrick From pcwalton at mozilla.com Fri Jul 25 10:34:03 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 10:34:03 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> Message-ID: <53D2950B.8030705@mozilla.com> On 7/25/14 10:10 AM, Josh Haberman wrote: > On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton wrote: >> Neither auto-ref or ad-hoc operator overloading >> would let you write a generic function that calls >> `pow` and works optimally with both bigints and >> ints. I think the only thing that would work is >> something like C++ ad-hoc templates, which is >> a road I don't want to go down. > > Could you explain what you mean by "ad-hoc templates", and how this > differs from Rust's templates? In Rust you can never have type errors during template expansion. If a call to a generic/template typechecks properly, then the template is guaranteed to expand to valid Rust code with no type errors within it. This is done via the trait system, which is similar in spirit to the concept systems proposed for C++17 (the difference being that Rust *only* has concepts). The primary benefit of this setup is that the infamous template error messages in C++ are eliminated. There are a bunch of other secondary benefits as well: there is no need for the ADL hack, you can do things like overload on the return type, etc. Patrick From remarcg at gmx.net Fri Jul 25 12:36:22 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 21:36:22 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <9634576.BCoQrL1ygE@purple> Message-ID: <13926370.akbXqWDJnT@purple> > > I gave up at all. (I'm doing software design and implementation since > > more than 30 years, and I never accept compromises, this is the way > > how to develop magnificient software). > > Hum, I would almost strongly disagree I would even go as far as > saying that you won't develop any kind ... How can you disagree about what I'm doing? > Well, I guess you did nothing but C++ in the last 30 years then? > Because I can't recall many languages that would allow this sort of > thing. How would C# and Java's Math::Pow() would work out in this > case? How would it work out in C? How would it work out in Python, > JavaScript, etc... the list is ... quite long. I don't care about the capabilities of other languages, I don't use a language if it is not appropriate. > The question is always about compromise. Shall rust include a language > feature to make some things easier for the sake of introducing tons of > problems as well? No. Everyone is talking about tons of problems, but which ones? The most problematic language, with tons of problems, is C++. But even in C++ not overloading is the problem - and I have about 20 years experience with C++ - it is for example, to name just one, the implicit casting, because this makes overloading a bit problematic. > Java is about the least expressive language we have at the time > (appears a bit like the greatest common denominator of all imperative > languages) and I would say only few people are out there who would say > that you can't do proper software design with it. This depends on how your are doing software design. Impossible for me to use Java. > It might not be a > concise and pleasing as "GOOD C++ design is", but then again "GOOD C++ > design" is very hard to archieve and thus begs the questions if it is > even worth it to make a language that complicated so that magnificient > (academic) design is possible at the cost of making the average > (industrial) design horrible. I cannot see that overloading is horrible or complicated. It's another point that C++ is horrible and complicated. We have 2014, as I started with C++ it was the superior language, but software design has evolved, nowadays object oriented design is obscure, and that's in fact my own experience. But C++ already supported one ingenious feature: generic programming (but very low level). > > pub fn pow>(mut base: T, mut exp: uint) -> T; > > I agree this definition appears to be very strange to me. In more than > one way. First it implies that the existing implementation works by > somehow multiplying types with the expontential trick " a * a = b, b * > b = c, c * c = a^6" etc... > This is an unacceptable restriction for me, as this kind of evaluation > might not be the best in many cases and we are talking about a > standard library function after all. It should always allow the BEST > implementation, not just some implementation. > > Here we clearly need a better concept. And this concept needs to be > designed & defined. And you could start by doing this, instead of just > giving up ;). This means that I have to design at a lower level, before I start to implement the big number library. Probably I'll try it, I don't know yet. I don't know yet whether I will really use Rust. (BTW: "I gave up at all" does not mean forever, please be aware that I'm not a native English speaker.) In fact I'm looking for an alternative to C++, and Rust is still the most promising one, but Rust is not yet elaborated (I know that Rust is still pre-alpha). > And overlaoding is not a great concept in general, IMO. > What Rust could do is copy template specialization. So that I can say: > > pub fn pow>(mut base: T, mut exp: uint) -> T; // > uses the exponential trick > > pub fn pow(mut base: i64, mut exp: uint) -> i64; // uses some > cool processor features if available > > pub fn pow(mut base: &BigInt, mut exp: uint) -> BigInt; // > uses some mighty algorithm that is not naive Yes, that would possibly be one solution for overloading, Unfortunately the problem with the signature remains. It's absolutely clear for me that an overloading feature should not cause problems, this means that a design is required which suits perfectly with the principle design of Rust. -------------- next part -------------- An HTML attachment was scrubbed... URL: From remarcg at gmx.net Fri Jul 25 12:36:35 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 21:36:35 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> Message-ID: <2855009.OOfmFzoaJ3@purple> > Did I miss a point in this thread where using a typeclass/trait to > implement exponentiation was dismissed? > > This function could be changed to: > > fn pow(base: T, exp: uint) -> T { base.pow(exp) } > > trait HasPow { > fn pow(self: Self, exp: uint) -> Self > } > > Or, just use HasPow in your code. Yes, you missed a point, I've already pointed out in my initial mail that moving pow() into a trait (that's what your code is finally doing) is solving this special problem, but it is not solving a general problem with (other) functions. A new module may cause that an older function (which you cannot overload) is inadequate. This makes software instable. In the past (with some older programming languages) you did not have solutions for this, but Rust is 2014, programming and compiler techniques have evolved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Fri Jul 25 13:00:07 2014 From: comexk at gmail.com (comex) Date: Fri, 25 Jul 2014 16:00:07 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <13926370.akbXqWDJnT@purple> References: <1869939.PKr16frPY1@purple> <9634576.BCoQrL1ygE@purple> <13926370.akbXqWDJnT@purple> Message-ID: On Fri, Jul 25, 2014 at 3:36 PM, Gregor Cramer wrote: > I don't care about the capabilities of other languages, I don't use a > language if it is not appropriate. Appropriate for what? You seem to be claiming that stable code in general needs this feature, so that's consigning all of the languages listed to be inappropriate for virtually anything. But they're not, so their design decisions should be considered, although of course they're not necessarily right. > No. Everyone is talking about tons of problems, but which ones? > The most problematic language, with tons of problems, is C++. > But even in C++ not overloading is the problem - and I have about > 20 years experience with C++ - it is for example, to name just one, > the implicit casting, because this makes overloading a bit problematic. A few months ago I posted in a similar thread why I don't like overloading: https://mail.mozilla.org/pipermail/rust-dev/2014-May/009982.html Buy it or not, I don't think overloading is necessary, since most of the time operations with room for such efficiency improvements should be implemented either in traits or as ad-hoc methods. That is, I'd call this a bug in std::num::pow. And of course it's possible to change something to a trait after the fact without breaking API compatibility. From thesaint1987 at googlemail.com Fri Jul 25 13:04:06 2014 From: thesaint1987 at googlemail.com (Christoph Husse) Date: Fri, 25 Jul 2014 22:04:06 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <13926370.akbXqWDJnT@purple> References: <1869939.PKr16frPY1@purple> <9634576.BCoQrL1ygE@purple> <13926370.akbXqWDJnT@purple> Message-ID: > How can you disagree about what I'm doing? I don't. I disagree with that: " I never accept compromises, this is the way how to develop magnificient software" Because it's not. Unless you use magnificient only in academic context. > I don't care about the capabilities of other languages, I don't use a language if it is not appropriate. C++ is not appropiate for almost any task there is. I am using C++ quite a lot, because at my work, C++ is the right tool for the job. But there aren't many jobs for which this is true. > No. Everyone is talking about tons of problems, but which ones? I am sure some language designers can give you more insight. I lack the convincing arguments. > But even in C++ not overloading is the problem - and I have about It's not so much about wether or not overloading could be used in rust without causing really painful issues. The question is if overlaoding fits into the language's design principles. Overloading is not necessary. It's just one of many ways that lead to Rome. > This depends on how your are doing software design. Impossible for me to use Java. Some of the greatest minds in the industry use Java for excellent software design. People read code, most of the time. People need to work with code other people wrote most of the time. Agile projects need good tooling, speaking of refactoring, code coverage, code formatting, coding standards, build tools, packaging, dependency managment in particular. C++ gives you almost nothing in any of those. C++ is a huge pain in the ass in most regards. Unless you really need it to get the job done, it's the worst choice there is. A language is about more than just "what you consider beautiful, etc."... It's about wether it allows agile, fast paced development across diverse teams and average programmers can produce code anyone else can read without getting eye cancer. That does not apply to C++ at all. > I cannot see that overloading is horrible or complicated. It's another No, but it might be unnecessary. From remarcg at gmx.net Fri Jul 25 13:45:28 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 22:45:28 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <13926370.akbXqWDJnT@purple> Message-ID: <2616419.vjN64enspN@purple> > And of course it's possible to change something to a trait after the > fact without breaking API compatibility. How you are doing this? I'm in fact a newbie in Rust, and it's interesting that this can be done. std::num::pow() is a good example, I think. Suppose I already have a program which is using std::num::pow() with a self defined integer type. Now you are changing std::num::pow(), moving the functionality into a trait. And my program will still compile and work as before? -------------- next part -------------- An HTML attachment was scrubbed... URL: From smcarthur at mozilla.com Fri Jul 25 13:59:49 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Fri, 25 Jul 2014 13:59:49 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <2616419.vjN64enspN@purple> References: <1869939.PKr16frPY1@purple> <13926370.akbXqWDJnT@purple> <2616419.vjN64enspN@purple> Message-ID: On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer wrote: > How you are doing this? I'm in fact a newbie in Rust, and it's > interesting > > that this can be done. std::num::pow() is a good example, I think. > > Suppose I already have a program which is using std::num::pow() with a > > self defined integer type. Now you are changing std::num::pow(), moving > > the functionality into a trait. And my program will still compile and work > > as before? > I'd expect that std::num::pow() would gain a #[deprecated = "Use Pow trait"] attribute, and be removed after Rust's deprecation period (which pre-1.0 is pretty much a few commits later). -------------- next part -------------- An HTML attachment was scrubbed... URL: From remarcg at gmx.net Fri Jul 25 14:04:40 2014 From: remarcg at gmx.net (Gregor Cramer) Date: Fri, 25 Jul 2014 23:04:40 +0200 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <13926370.akbXqWDJnT@purple> Message-ID: <1417251.y2d5PWaTu1@purple> > I disagree with that: " I never accept compromises, this is > the way how to develop magnificient software" > Because it's not. Unless you use magnificient only in academic context. ????? I'm not doing academic things. > It's not so much about wether or not overloading could be used in rust > without causing really painful issues. The question is if overlaoding > fits into the language's design principles. I agree, if overloading does not fit at all, then it should not be done. > Overloading is not necessary. It's just one of many ways that lead to Rome. Yes, many ways are leading to Rome. One of the ways is easy to go, and is a joy. Another way is tedious or cumbersome. > A language is about more than just "what you consider beautiful, > etc."... It's about wether it allows agile, fast paced development > across diverse teams and average programmers can produce code anyone > else can read without getting eye cancer. Fast-paced development without generic programming? And overloading is supporting generic programming. > > I cannot see that overloading is horrible or complicated. It's another > > No, but it might be unnecessary. Possibly I'm wrong that overloading is neccessary in Rust, that's why I'm talking, I'm not a master in Rust programming. But fact is: as I stumbled over std::num::pow() I could see problems if not having overloading. And I repeat: std::num::pow() is only an example for a general problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhaberman at gmail.com Fri Jul 25 15:20:37 2014 From: jhaberman at gmail.com (Josh Haberman) Date: Fri, 25 Jul 2014 15:20:37 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D2950B.8030705@mozilla.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> <53D2950B.8030705@mozilla.com> Message-ID: On Fri, Jul 25, 2014 at 10:34 AM, Patrick Walton wrote: > On 7/25/14 10:10 AM, Josh Haberman wrote: > >> On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton >> wrote: >> >>> Neither auto-ref or ad-hoc operator overloading >>> would let you write a generic function that calls >>> `pow` and works optimally with both bigints and >>> ints. I think the only thing that would work is >>> something like C++ ad-hoc templates, which is >>> a road I don't want to go down. >>> >> >> Could you explain what you mean by "ad-hoc templates", and how this >> differs from Rust's templates? >> > > In Rust you can never have type errors during template expansion. If a > call to a generic/template typechecks properly, then the template is > guaranteed to expand to valid Rust code with no type errors within it. This > is done via the trait system, which is similar in spirit to the concept > systems proposed for C++17 (the difference being that Rust *only* has > concepts). > Got it. So the "ad hoc" part refers to having a template parameter, but not being able to check its capabilities/interface at template parsing/typechecking time, it sounds like? How does the trait/concept approach preclude template specialization? Each template specialization could be independently type-checked, but the most specialized one could be selected at instantiation time. Or is this considered "overloading" and discarded because of the extra complexity? I guess it could be complicated to define which was "most specialized." -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Fri Jul 25 15:22:27 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 15:22:27 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> <53D2950B.8030705@mozilla.com> Message-ID: <53D2D8A3.8030205@mozilla.com> On 7/25/14 3:20 PM, Josh Haberman wrote: > Got it. So the "ad hoc" part refers to having a template parameter, but > not being able to check its capabilities/interface at template > parsing/typechecking time, it sounds like? Right. (The term comes from "Making Ad-Hoc Polymorphism Less Ad-Hoc", which is the seminal paper on typeclasses.) > How does the trait/concept approach preclude template specialization? > Each template specialization could be independently type-checked, but > the most specialized one could be selected at instantiation time. Or is > this considered "overloading" and discarded because of the extra > complexity? I guess it could be complicated to define which was "most > specialized." Yeah, that's the complexity. Some GHC language extensions do allow something like template specialization, but it's considered very experimental. I'd like to see if things like associated types get us most of the way there without the difficulties of specialization. Patrick From lionel.parreaux at gmail.com Fri Jul 25 20:10:06 2014 From: lionel.parreaux at gmail.com (Lionel Parreaux) Date: Sat, 26 Jul 2014 05:10:06 +0200 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> Message-ID: Oh I'm sorry I completely missed your message, because I was not subscribed to the list. Thanks for the explanation. I do realize that this is the tough part, compared to a system like Haskell where everything is boxed. It's interesting to hear that this is how it was (meant to be) done in a previous version of Rust. Could you expand on the sources of the difficulties met trying to implement it? (Or just give me a pointer to some material about it.) I'm interested, because I'm working on a research language without GC and without boxed allocation semantics, so this kind of things come up. Cheers, LP. PS: I agree that the current system seems reasonable for what Rust targets. Patrick Walton Tue Jul 22 11:47:18 PDT 2014 > On 7/22/14 10:16 AM, Lionel Parreaux wrote: > > I'm not sure whether this is a big problem in practice, but I was > > wondering if it would be possible to switch to some runtime mechanism in > > cases like this. Maybe we could make a special version of every generic > > functions, that takes a dictionary at runtime and that would be able to > > handle types unknown at compile-time. We would switch to this version > > when monomorphization does not work. It could also allow dynamic linking > > of libraries with generic functions, or it could be a way to compile > > some programs (or some parts of programs) much faster. > > The hard part about doing that is not the dictionary passing. The hard > part is that generic types may have unknown size or alignment. In > Haskell this is not a problem because the language is garbage-collected > and lazy so values have a uniform representation. But in Rust this is > not true. > > Old Rust used to try to use runtime dictionary passing, where the > dictionary contained size and alignment information, and all > size/alignment info was computed at runtime for generics. I cannot > overstate how *fiendishly* complex this was. We never got all the bugs > out. In many cases, the amount of runtime code generated to compute size > and alignment outweighed the cost of just monomorphizing. > > I strongly feel that the current system, where you can use generic type > parameters to get monomorphization or trait objects to get dictionary > passing, is the sweet spot. > > Patrick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Fri Jul 25 20:26:24 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 20:26:24 -0700 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> Message-ID: <53D31FE0.1060707@mozilla.com> On 7/25/14 8:10 PM, Lionel Parreaux wrote: > Oh I'm sorry I completely missed your message, because I was not > subscribed to the list. > > Thanks for the explanation. I do realize that this is the tough part, > compared to a system like Haskell where everything is boxed. > > It's interesting to hear that this is how it was (meant to be) done in a > previous version of Rust. Could you expand on the sources of the > difficulties met trying to implement it? (Or just give me a pointer to > some material about it.) Basically it got really complicated when you had things like: fn f(x: T) { if ... { f((x,x,x)); } } Not only did we have to have the notion of a "type descriptor" which was passed at runtime, because of generics-constructed-out-of-other-generics we had to have the notion of a "derived type descriptor" which was a type descriptor constructed at runtime on the stack, which formed a singly linked list of type descriptors (so that you could find destructors for the original types). Additionally, the requirement that we have to follow C alignment rules meant that accessing field N of a struct was actually an O(n) operation, since there's no closed-form way to calculate alignment of a struct at length N. These two were the biggest problems. > I'm interested, because I'm working on a research language without GC > and without boxed allocation semantics, so this kind of things come up. Have you seen these notes from Greg Morrisett? http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt They were very helpful for us. I have a few minor quibbles (for example I don't think the hazards of infinite template instantiation via polymorphic recursion are that big of a deal in practice, whereas those notes seem to consider it a deal-breaker). What I do agree with is that the best way to do generics if you have non-uniform value representations is to JIT each template instantiation as you come to it (like .NET does). This is basically the best of all worlds. However, it requires a JIT; if you don't have a JIT, I think the best thing is what Rust currently does. Uniform value representations work well too (as OCaml shows), but of course you'll pay a performance cost for that. Patrick From pcwalton at mozilla.com Fri Jul 25 20:31:11 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 25 Jul 2014 20:31:11 -0700 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: <53D31FE0.1060707@mozilla.com> References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> <53D31FE0.1060707@mozilla.com> Message-ID: <53D320FF.2030004@mozilla.com> On 7/25/14 8:26 PM, Patrick Walton wrote: > Uniform value representations work well too (as > OCaml shows), but of course you'll pay a performance cost for that. Oh, note that Greg's notes are a little bit out of date when discussing the performance tradeoffs of uniform value representation. On 64 bit (and even on 32 bit) you can do NaN-boxed "fatvals" [1] (scroll down to "Mozilla's New JavaScript Value Representation") which avoid having to box every floating point value. Patrick [1] http://evilpie.github.io/sayrer-fatval-backup/cache.aspx.htm From rustphil at phildawes.net Sat Jul 26 02:39:46 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sat, 26 Jul 2014 10:39:46 +0100 Subject: [rust-dev] resolving 'str' Message-ID: Hello! I'm trying to make racer resolve '&str' types properly. I've read that the separation of type and value namespaces means you can refer both to the 'str' type and the 'str' module[1]. However I would have thought that the 'str' type lives in the type namespace, and according to the reference guide modules and types share the same namespace. How should racer resolve the type? Thanks v much, Phil [1] http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Sat Jul 26 05:54:24 2014 From: slabode at aim.com (SiegeLordEx) Date: Sat, 26 Jul 2014 08:54:24 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D28E25.3060007@mozilla.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> Message-ID: <53D3A500.6030409@aim.com> On 07/25/2014 01:04 PM, Patrick Walton wrote: > I don't think we should be trying to solve it. I don't agree. If this problem is truly appreciated, then you have to conclude that completely generic code is not possible in Rust, which means that Rust should not bless particular generic signatures (the operator overloading traits, the iterator trait, maybe a few others I can't think of right now) with special syntax because they can't possibly be efficient in all cases. While this doesn't matter for the pow function (the alternate function would just have a different path/name), it matters for the special syntaxes. When the Iterator is no longer enough for you (there was a case like this in IRC recently involving mutable windows), then you have to abandon the for loop which is a big syntactic change (right now it works because it is ad-hoc). Similarly, when the operator overloading traits are insufficient, then you have to abandon that sugar as well. One might say "well, don't use those traits then" but that's not what happens in practice. In practice, people want the syntax sugar and therefore are guided into inefficiency. Some of BigNum's operator overloads shouldn't exist because they are so inefficient, and yet they do because people expect BigNum to act (on a syntactic level) just like any other number. So I think this is a real problem with real solutions that don't require going down the ad-hoc template black hole. Part of the solution has to involve changing how the language syntax sugar works. The other part, however, involves libraries: if the generic functions in libnum expect types to act as built-in types (by requiring T: Mul etc), then BigNum should not act like a built in type; alternatively, the generic functions in libnum should be overloadable (via the double-dispatch trick). Maybe there's some other library-based pattern that would work as well. -SL From pcwalton at mozilla.com Sat Jul 26 09:56:13 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 26 Jul 2014 09:56:13 -0700 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D3A500.6030409@aim.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> <53D3A500.6030409@aim.com> Message-ID: <53D3DDAD.6040408@mozilla.com> On 7/26/14 5:54 AM, SiegeLordEx wrote: > While this doesn't matter for the pow function (the alternate function > would just have a different path/name), it matters for the special > syntaxes. When the Iterator is no longer enough for you (there was a > case like this in IRC recently involving mutable windows), then you have > to abandon the for loop which is a big syntactic change (right now it > works because it is ad-hoc). As of last week it's not anymore. > Similarly, when the operator overloading > traits are insufficient, then you have to abandon that sugar as well. > One might say "well, don't use those traits then" but that's not what > happens in practice. In practice, people want the syntax sugar and > therefore are guided into inefficiency. Some of BigNum's operator > overloads shouldn't exist because they are so inefficient, and yet they > do because people expect BigNum to act (on a syntactic level) just like > any other number. > > So I think this is a real problem with real solutions that don't require > going down the ad-hoc template black hole. Well, part of the problem here is that people are going to want to write generic functions that take addable values. If we start making `+` and friends overloadable/ad-hoc, then people are going to be surprised when they can't pass (say) bignums to functions that want addable things. Patrick From slabode at aim.com Sat Jul 26 10:56:04 2014 From: slabode at aim.com (SiegeLordEx) Date: Sat, 26 Jul 2014 13:56:04 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D3DDAD.6040408@mozilla.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> <53D3A500.6030409@aim.com> <53D3DDAD.6040408@mozilla.com> Message-ID: <53D3EBB4.9060002@aim.com> On 07/26/2014 12:56 PM, Patrick Walton wrote: > Well, part of the problem here is that people are going to want to write > generic functions that take addable values. If we start making `+` and > friends overloadable/ad-hoc, then people are going to be surprised when > they can't pass (say) bignums to functions that want addable things. The current Rust doesn't allow a complete lack of surprise. Either you will be surprised by the traits not being supported by every numeric type, or you will be surprised by the terrible performance of most types that implement Op. The core issue is that 'addable' (and other concepts/functions) cannot be expressed efficiently for all types in some unified way. -SL From danielmicay at gmail.com Sat Jul 26 11:40:24 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 26 Jul 2014 14:40:24 -0400 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <53D3DDAD.6040408@mozilla.com> References: <1869939.PKr16frPY1@purple> <53D242DB.70108@aim.com> <53D28E25.3060007@mozilla.com> <53D3A500.6030409@aim.com> <53D3DDAD.6040408@mozilla.com> Message-ID: <53D3F618.30906@gmail.com> On 26/07/14 12:56 PM, Patrick Walton wrote: > On 7/26/14 5:54 AM, SiegeLordEx wrote: >> While this doesn't matter for the pow function (the alternate function >> would just have a different path/name), it matters for the special >> syntaxes. When the Iterator is no longer enough for you (there was a >> case like this in IRC recently involving mutable windows), then you have >> to abandon the for loop which is a big syntactic change (right now it >> works because it is ad-hoc). > > As of last week it's not anymore. > >> Similarly, when the operator overloading >> traits are insufficient, then you have to abandon that sugar as well. >> One might say "well, don't use those traits then" but that's not what >> happens in practice. In practice, people want the syntax sugar and >> therefore are guided into inefficiency. Some of BigNum's operator >> overloads shouldn't exist because they are so inefficient, and yet they >> do because people expect BigNum to act (on a syntactic level) just like >> any other number. >> >> So I think this is a real problem with real solutions that don't require >> going down the ad-hoc template black hole. > > Well, part of the problem here is that people are going to want to write > generic functions that take addable values. If we start making `+` and > friends overloadable/ad-hoc, then people are going to be surprised when > they can't pass (say) bignums to functions that want addable things. > > Patrick We can start out with efficient generic code for bignums (meaning stuff like `op(&mut tmp, &a, &b)` in a loop with a reused temporary variable) and then add a "static" branch + other code for primitives as vector iterators already do for zero-size types. Ideally there would be a way of expressing it without relying on optimizations to remove a branch but the language is expressive enough other than that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From arielb1 at mail.tau.ac.il Sat Jul 26 22:15:46 2014 From: arielb1 at mail.tau.ac.il (Ariel Ben-Yehuda) Date: Sun, 27 Jul 2014 08:15:46 +0300 Subject: [rust-dev] std::num::pow() is inadequate / language concepts Message-ID: std::num::pow is not the most general exponentiation function but a second-rate utility function in the standard library - you don't have to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arielb1 at mail.tau.ac.il Sat Jul 26 22:29:21 2014 From: arielb1 at mail.tau.ac.il (Ariel Ben-Yehuda) Date: Sun, 27 Jul 2014 08:29:21 +0300 Subject: [rust-dev] std::num::pow() is inadequate / language concepts Message-ID: [The previous message got sent accidentally by gmail] However, for performance reasons, I think some kind of trait overloading would be nice. i.e., you should be able to do impl Trait for A { ... } overload impl Trait for A { //... } And when using (x : Trait) the items in the overload impl will be used instead of the items in the base impl (note that, except for associated types, overloaded traits won't participate in name resolution/type checking - so probably force associated types in the overload to be the same as the base). -------------- next part -------------- An HTML attachment was scrubbed... URL: From zo1980 at gmail.com Sun Jul 27 09:29:48 2014 From: zo1980 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBUw7N0aA==?=) Date: Sun, 27 Jul 2014 18:29:48 +0200 Subject: [rust-dev] This Week in Rust Message-ID: What happened to it? I can not live without it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.parreaux at gmail.com Sun Jul 27 09:36:06 2014 From: lionel.parreaux at gmail.com (Lionel Parreaux) Date: Sun, 27 Jul 2014 18:36:06 +0200 Subject: [rust-dev] Implementation of traits in Rust: could it be dynamic? In-Reply-To: <53D320FF.2030004@mozilla.com> References: <0D302ADA-283B-435E-AB0D-CABB78D66586@mozilla.com> <53D31FE0.1060707@mozilla.com> <53D320FF.2030004@mozilla.com> Message-ID: I see. Thanks for the links, Greg Morrisett's notes are a great survey of possible approaches to this problem. It is funny because I had also come to the conclusion that JIT was the neater solution, as long as JIT is available with the runtime... and you don't have to implement it -- I guess it's even more complex than doing runtime dictionary passing. Has there been experiments using LLVM's JIT to implement polymorphism in Rust? I'm not sure about the cost of JIT, though. Maybe it would not make sense in Rust. Well, at least there should still be the static monomorphization option. 2014-07-26 5:31 GMT+02:00 Patrick Walton : > On 7/25/14 8:26 PM, Patrick Walton wrote: > >> Uniform value representations work well too (as >> OCaml shows), but of course you'll pay a performance cost for that. >> > > Oh, note that Greg's notes are a little bit out of date when discussing > the performance tradeoffs of uniform value representation. On 64 bit (and > even on 32 bit) you can do NaN-boxed "fatvals" [1] (scroll down to > "Mozilla's New JavaScript Value Representation") which avoid having to box > every floating point value. > > Patrick > > [1] http://evilpie.github.io/sayrer-fatval-backup/cache.aspx.htm > > > _______________________________________________ > 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 lists at ncameron.org Sun Jul 27 09:41:41 2014 From: lists at ncameron.org (Nick Cameron) Date: Sun, 27 Jul 2014 18:41:41 +0200 Subject: [rust-dev] Older RFCs for discussion next week Message-ID: Hi, here are the recommendations for discussion at next weeks meetings. As usual, if you have comments on any of these RFCs, please add them to the discussion on the PR; please don't reply to this message. In the future the primary method of sending this message will be via our discourse instance at discuss.rust-lang.org (technical problems prevented that this week). Cheers, Nick Proposed for discussion at Rust meeting --------------------------------------- https://github.com/rust-lang/rfcs/pull/136 - Ban private items in public APIs - glaebhoerl Not much to add to the title. For example using a private struct as a type in a public function. We have a lint for part of this already. Apparently this is used as a hack for some kind of fine-grained privacy for traits. Seems like we should address that properly. Mostly negative feedback, but (I think) only because of the hacks it would break. Discuss again (previously discussed last week) https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis A lot of discussion, pretty much all about the details. General sentiment that we want this. Recommend we accept - is this the right RFC to accept, I've not really been keeping track - pnkfelix, pcwalton - is there something which supersedes this? I think this needs a small update to reflect some of the later comments. https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted - stevelabnik Loads of opinion in the thread (162 comments!). Note that Niko has an upcoming RFC (127, below) with the concept of unsafe/trusted traits where the keyword `trusted` makes a lot more sense than `unsafe`, so we could save a keyword here. https://github.com/rust-lang/rfcs/pull/127 - Opt-in builtin traits, take 2: default and negative impls - nmatsakis Unsafe (trusted) traits (see also 117, above) which express an invariant to the compiler and default impls - which must be opted out of, rather than in. https://github.com/rust-lang/rfcs/pull/132 - UFCS - nmatsakis Universal function call syntax. Use ::Foo syntax for specifying the trait as well as the concrete type for a function call. Previously discussed as an older RFC. https://github.com/rust-lang/rfcs/pull/135 - where clauses - nmatsakis Allow specifying bounds on type parameters in a where clause as well as inline. This is more expressive and neater in the presence of many type parameters or bounds. Mostly positive feedback. Some worries around having inline bounds and where clauses. Some worries about the 'multiple dispatch' part of the proposal. Proposed for discussion at triage --------------------------------- https://github.com/rust-lang/rfcs/issues/121 - some questions about the RFC process - pnkfelix These need answers for clarification on the process. https://github.com/rust-lang/rfcs/issues/158 - Should we track incomplete ideas here instead of in the rust issue tracker? - erikt I think the answer is 'use discourse'. We should make sure that is the answer, make it official in the thread and perhaps add some text to the RFC repo readme, then close. https://github.com/rust-lang/rfcs/pull/172 - Exponentiation syntax sugar - SiegeLord Sugar for the pow function. Backwards compatible. Recommend close and/or postpone. https://github.com/rust-lang/rfcs/pull/174 - value type parameters - zoxc Parameterise by values as well as types. Recommend postpone. https://github.com/rust-lang/rfcs/pull/175 - Field offsets - zoxc I don't understand very well what is proposed, sorry. Recommend postpone or close - not great motivation, doesn't seem to merit prioritisation before 1.0. Discussed and postponed for more feedback ----------------------------------------- https://github.com/rust-lang/rfcs/pull/101 - Allow multiple (fixed-size) subslices borrows in one pattern - krdln Allows matching several parts of a vec in one pattern. Adds `xs..n` syntax to match a fixed size slice (and changes variable sized slice pattern syntax to `xs..` from `..xs`). Not much feedback - all positive or corrected later to be positive. Seems like a small generalisation with no downsides. If we change the syntax as recommended for existing patterns (i.e., `..xs` to `xs..`) then the rest should be backwards compatible, I think. https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing - Kimundi Forbid or deprecate name collision of imported names. Positive feedback. Recommend: lets do this! Might need to tidy up the RFC, but nothing major (hopefully). Need to decide whether to depricate via a feature gate or just get rid. Would be good to assess how much damage this will cause. https://github.com/rust-lang/rfcs/pull/129 - refine the `asm!` extension - pczarn A string/format! based method of doing inline asm. Not much feedback. Seems like we could do better with our inline asm, not sure if this is the right approach. Recommend: probably close, but worth discussing first. Proposed for discussion at some point ------------------------------------- https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of tagged values - erikt Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against. erikt to update? Actions agreed -------------- https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt aturon to comment acrichto to close https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix + jclements to keep pushing on getting more explanation https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks huon has updated need more discussion on edge cases - see RFC - pnkfelix (and others) https://github.com/rust-lang/rfcs/pull/113 - Provide a common API across `Option` and the `Ok` and `Err` variants of `Result` - bjz Make Option and Result more consistent. Positive feedback for the idea, some discussion on the specifics. I believe this was discussed before and we were going to flesh it out a bit more. Could bjz and aturon update us on progress? To be closed, more RFCs coming from aturon. https://github.com/rust-lang/rfcs/pull/123 - Rename Share to Threadsafe - acrichto Rename share. Bit of a bikeshed here, some support also for `sync`, `concurrent`, etc. nmatsakis to merge https://github.com/rust-lang/rfcs/pull/130 - RFC to remove some special treatment of Box by borrow checker - nmatsakis Make Box a little bit more like a normal struct, but also make it less expressive. Removes the special ability for the borrow checker to distinguish parts of a boxed value. Pretty much no feedback. czwarich to implement and report back -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntypanski at gmail.com Sun Jul 27 09:46:04 2014 From: ntypanski at gmail.com (Nathan Typanski) Date: Sun, 27 Jul 2014 12:46:04 -0400 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: It's moved here , although there hasn't been an update since 15 July. Nathan From steve at steveklabnik.com Sun Jul 27 10:39:47 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Sun, 27 Jul 2014 13:39:47 -0400 Subject: [rust-dev] Older RFCs for discussion next week In-Reply-To: References: Message-ID: I closed 117, so it shouldn't be on the docket anymore. From corey at octayn.net Sun Jul 27 11:52:52 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 27 Jul 2014 11:52:52 -0700 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: Been super busy, but there's some good stuff in store: http://blog.octayn.net/blog/2014/06/09/future-of-twir/ On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski wrote: > It's moved here , although there hasn't been > an update since 15 July. > > Nathan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From corey at octayn.net Mon Jul 28 01:24:26 2014 From: corey at octayn.net (Corey Richardson) Date: Mon, 28 Jul 2014 01:24:26 -0700 Subject: [rust-dev] This Week in Rust In-Reply-To: <6280864.QLEB5IngVJ@tph-l13071> References: <6280864.QLEB5IngVJ@tph-l13071> Message-ID: Atom feed is in the same place it always has been: http://blog.octayn.net/atom.xml and On Mon, Jul 28, 2014 at 1:20 AM, Diggory Hardy wrote: > Any chance you can add RSS feeds on the new blog? > > On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote: >> Been super busy, but there's some good stuff in store: >> http://blog.octayn.net/blog/2014/06/09/future-of-twir/ >> >> On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski > wrote: >> > It's moved here , although there hasn't been >> > an update since 15 July. >> > >> > Nathan >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From jzinedine at gmail.com Mon Jul 28 02:12:43 2014 From: jzinedine at gmail.com (Jahangir Zinedine) Date: Mon, 28 Jul 2014 13:42:43 +0430 Subject: [rust-dev] This Week in Rust In-Reply-To: References: <6280864.QLEB5IngVJ@tph-l13071> Message-ID: Thanks Corey, It's a valuable source of information for anyone who is not actively involved in language development process. I've looked for something like it before, but haven't found it. Thanks, Jani On Mon, Jul 28, 2014 at 12:54 PM, Corey Richardson wrote: > Atom feed is in the same place it always has been: > http://blog.octayn.net/atom.xml and > > On Mon, Jul 28, 2014 at 1:20 AM, Diggory Hardy > wrote: > > Any chance you can add RSS feeds on the new blog? > > > > On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote: > >> Been super busy, but there's some good stuff in store: > >> http://blog.octayn.net/blog/2014/06/09/future-of-twir/ > >> > >> On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski > > wrote: > >> > It's moved here , although there hasn't been > >> > an update since 15 July. > >> > > >> > Nathan > >> > > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > > > > -- > http://octayn.net/ > _______________________________________________ > 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 diggory.hardy at unibas.ch Mon Jul 28 01:20:44 2014 From: diggory.hardy at unibas.ch (Diggory Hardy) Date: Mon, 28 Jul 2014 10:20:44 +0200 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: <6280864.QLEB5IngVJ@tph-l13071> Any chance you can add RSS feeds on the new blog? On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote: > Been super busy, but there's some good stuff in store: > http://blog.octayn.net/blog/2014/06/09/future-of-twir/ > > On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski wrote: > > It's moved here , although there hasn't been > > an update since 15 July. > > > > Nathan > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev From mneumann at ntecs.de Tue Jul 29 05:59:14 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Tue, 29 Jul 2014 14:59:14 +0200 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD Message-ID: <53D79AA2.3020507@ntecs.de> Hi all, I am happy to announce that I succeeded in porting Rust to the DragonFly operating system. [This article][1] describes `how` and might also be of interest to others porting Rust to NetBSD or OpenBSD. Within the next week I submit patches to the LLVM project (segmented stack support for DragonFly) and also to the rust repo itself. My `dragonfly` branch of the Rust repository can be found [here][2]. If someone is interested to try out early, I can provide some binaries until I set up some automatic builds. Regards, Michael [1]: http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/ [2]: https://github.com/mneumann/rust/tree/dragonfly From markus.pfeiffer at morphism.de Tue Jul 29 06:07:58 2014 From: markus.pfeiffer at morphism.de (Markus Pfeiffer) Date: Tue, 29 Jul 2014 13:07:58 +0000 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: <53D79AA2.3020507@ntecs.de> References: <53D79AA2.3020507@ntecs.de> Message-ID: <20140729130758.GE539043@karp.morphism.de> Hi Michael, great work, and thanks for doing this! *goes off to prod around rust* Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rlatham at gmail.com Tue Jul 29 11:37:12 2014 From: rlatham at gmail.com (Rob Latham) Date: Tue, 29 Jul 2014 13:37:12 -0500 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: <53D79AA2.3020507@ntecs.de> References: <53D79AA2.3020507@ntecs.de> Message-ID: "After trying to cross-compile Rust by specifying --target x86_64-pc-dragonfly-elf to Rust?s own configure script and spending numerous hours just to note that the build fails"... Howdy, fellow crazy cross-compiling person. Did you by any chance come across my message from a week or so ago? One response seemed likely to help you if you were encountering a specific kind of build failure: https://mail.mozilla.org/pipermail/rust-dev/2014-July/010827.html what other errors were you encountering with the --target approach? ==rob On Tue, Jul 29, 2014 at 7:59 AM, Michael Neumann wrote: > Hi all, > > I am happy to announce that I succeeded in porting Rust to the DragonFly > operating system. [This article][1] describes `how` and might also be of > interest to others porting Rust to NetBSD or OpenBSD. Within the next > week I submit patches to the LLVM project (segmented stack support for > DragonFly) and also to the rust repo itself. My `dragonfly` branch of > the Rust repository can be found [here][2]. > > If someone is interested to try out early, I can provide some binaries > until I set up some automatic builds. > > Regards, > > Michael > > [1]: http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/ > [2]: https://github.com/mneumann/rust/tree/dragonfly > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From alex at crichton.co Tue Jul 29 15:30:13 2014 From: alex at crichton.co (Alex Crichton) Date: Tue, 29 Jul 2014 15:30:13 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust Message-ID: Now that cargo is starting to become a larger part of the Rust ecosystem it's time for some of the crates as part of the standard distribution to move out of the main rust repository. This movement has been planned for quite some time now, and it has only recently become possible with the advent of cargo. Starting today, we'd like to evolve crates not needed by rustc itself outside of the compiler wherever possible. This will reduce cycle time on development of these libraries, allow them to develop independently from rustc, and hopefully allow them to be more focused in their target goals. The process of moving crates out of the standard distribution will be an ongoing and evolving one. We currently have the benefit of being able to move the entire distribution forward in one atomic step with everything in one repository, but this quickly becomes infeasible with many repositories. We plan to implement any necessary infrastructure to ensure that the crates move out of the rust repository maintain the same level of quality they currently have. To this extent, the current process for moving a crate out of the standard distribution will be as follows: 1. A member of the core team will be contacted to create the repository `rust-lang/$foo`. 2. A PR will be made against `rust-lang/$foo` with the current copy of the code from `rust-lang/rust`. This PR will be expected to have the following source structure: * Cargo.toml - a manifest to build this repo as a cargo package * .travis.yml - configuration to run automated tests on travis. A sample can be found for hexfloat [1] * LICENSE-{MIT,APACHE} - copied over from rust-lang/rust * src/ - the same source structure as the folder in rust-lang/rust 3. A PR will be made against `rust-lang/rust` which will flag the relevant library as `#[deprecated]` with a message pointing at `rust-lang/$foo` In order to ensure that these repositories continue to stay up to date, we will have the following process in place: 1. Each repository will be hooked up to Travis CI and will be built each night once the new nightlies are available. 2. A status page [2] is provided to get a quick glance at the status of all officially supported repositories. The amount of infrastructure around keeping these repositories up to date will likely change over time, but this is the current starting point for automation. [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml [2]: http://buildbot.rust-lang.org/travis/travis.html From thadguidry at gmail.com Tue Jul 29 15:45:22 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 29 Jul 2014 17:45:22 -0500 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: [snip] > 2. A status page [2] is provided to get a quick glance at the status of all > officially supported repositories. > > The amount of infrastructure around keeping these repositories up to date > will likely change over time, but this is the current starting point for > automation. > > [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml > [2]: http://buildbot.rust-lang.org/travis/travis.html > So going forward... Where can we look in source / folders / files ... to see what is an "officially supported repository" and what is not ? Let's say I don't want to have to look at the Travis view for that info, but just look at source to figure this out. -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at bharr.is Tue Jul 29 15:52:59 2014 From: mail at bharr.is (Ben Harris) Date: Wed, 30 Jul 2014 06:52:59 +0800 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: They are still "officially supported", but they will live in https://github.com/rust-lang/ instead of "with the Rust compiler". On 30 July 2014 06:45, Thad Guidry wrote: > [snip] > > >> 2. A status page [2] is provided to get a quick glance at the status of >> all >> officially supported repositories. >> >> The amount of infrastructure around keeping these repositories up to date >> will likely change over time, but this is the current starting point for >> automation. >> >> [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml >> [2]: http://buildbot.rust-lang.org/travis/travis.html >> > > So going forward... > > Where can we look in source / folders / files ... to see what is an > "officially supported repository" and what is not ? Let's say I don't want > to have to look at the Travis view for that info, but just look at source > to figure this out. > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > 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 alex at crichton.co Tue Jul 29 16:11:28 2014 From: alex at crichton.co (Alex Crichton) Date: Tue, 29 Jul 2014 16:11:28 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: Currently the threshold for being "officially supported" will be one of being in the rust-lang organization or being on the travis dashboard. At this time there are no plans to have an in-tree way to distinguish, although I suspect that a README with a description would likely suffice. On Tue, Jul 29, 2014 at 3:45 PM, Thad Guidry wrote: > [snip] > >> >> 2. A status page [2] is provided to get a quick glance at the status of >> all >> officially supported repositories. >> >> The amount of infrastructure around keeping these repositories up to date >> will likely change over time, but this is the current starting point for >> automation. >> >> [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml >> [2]: http://buildbot.rust-lang.org/travis/travis.html > > > So going forward... > > Where can we look in source / folders / files ... to see what is an > "officially supported repository" and what is not ? Let's say I don't want > to have to look at the Travis view for that info, but just look at source to > figure this out. > > -- > -Thad > +ThadGuidry > Thad on LinkedIn From erick.tryzelaar at gmail.com Tue Jul 29 16:19:18 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 29 Jul 2014 16:19:18 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: One additional way for us to say inside rust itself if a library is officially supported would be for us to the #[experimental] / #[unstable] / #[stable] / etc tags inside the https://github.com/rust-lang/ libraries. #[experimental] libraries may or may not survive, but #[unstable] and above will probably be around in one form or another. On Tue, Jul 29, 2014 at 4:11 PM, Alex Crichton wrote: > Currently the threshold for being "officially supported" will be one > of being in the rust-lang organization or being on the travis > dashboard. At this time there are no plans to have an in-tree way to > distinguish, although I suspect that a README with a description would > likely suffice. > > On Tue, Jul 29, 2014 at 3:45 PM, Thad Guidry wrote: > > [snip] > > > >> > >> 2. A status page [2] is provided to get a quick glance at the status of > >> all > >> officially supported repositories. > >> > >> The amount of infrastructure around keeping these repositories up to > date > >> will likely change over time, but this is the current starting point for > >> automation. > >> > >> [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml > >> [2]: http://buildbot.rust-lang.org/travis/travis.html > > > > > > So going forward... > > > > Where can we look in source / folders / files ... to see what is an > > "officially supported repository" and what is not ? Let's say I don't > want > > to have to look at the Travis view for that info, but just look at > source to > > figure this out. > > > > -- > > -Thad > > +ThadGuidry > > Thad on LinkedIn > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Tue Jul 29 17:53:33 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 29 Jul 2014 17:53:33 -0700 Subject: [rust-dev] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team Message-ID: Hello Rustillians! I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August 21, 2014, at Mozilla's San Francisco office: Please sign up here if you wish to attend: http://www.meetup.com/Rust-Bay-Area/events/191293242/ This is a unique meetup because we will be having the full Mozilla Rust team in town in attendance and speaking about what they've been working on. Here is our lineup of speakers: ? Alex Crichton: Cargo: forged in a crucible of Rust ? Niko Matsakis: TBD ? Patrick Walton - Explaining the Borrowcheck (or TBD). ? Aaron Turon: The intersection of new language features and libraries. If you cannot attend in person, we will have the talk livestreamed on Air Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As always, Mozilla will be graciously providing food and drink. I hope you can all make it! -Erick PS: The brand new San Francisco Rust Hacknights meetup group is also hosting a hacknight happening that same week on August 19th: http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ Don't miss out on it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Wed Jul 30 02:44:28 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 30 Jul 2014 10:44:28 +0100 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: <53D8BE7C.2070800@exyr.org> On 29/07/14 23:30, Alex Crichton wrote: > [...] > > We plan to implement any necessary infrastructure to ensure that the crates > move out of the rust repository maintain the same level of quality they > currently have. Will these crates? documentation be available online? In rust-url, rust-cssparser, and Servo, I have Travis-CI setup to generate documentation with rustdoc and, for successful builds on master, upload it to GitHub Pages. The end result looks like this: http://servo.github.io/rust-cssparser/cssparser/index.html See at the end of this email for how this works. Long term, I?d like Rust to have an official package index, like Python?s PyPI: https://pypi.python.org/ PyPI provides free hosting for documentation of Python projects. I?d like Rust to have something like this too. GitHub Pages works and exists now, but I?m not a fan of generated files in the source repository, even in a separate branch. > To this extent, the current process for moving a crate out of the standard > distribution will be as follows: > > 1. A member of the core team will be contacted to create the repository > `rust-lang/$foo`. > 2. A PR will be made against `rust-lang/$foo` I?ve just checked: GitHub does not allow forking (and therefore making PRs to) an empty repository, so the person creating the repository will have to at least check the "Initialize this repository with a README" checkbox to make a dummy first commit. > with the current copy of the > code from `rust-lang/rust`. This PR will be expected to have the > following source structure: > > * Cargo.toml - a manifest to build this repo as a cargo package > * .travis.yml - configuration to run automated tests on travis. A > sample can be found for hexfloat [1] > * LICENSE-{MIT,APACHE} - copied over from rust-lang/rust > * src/ - the same source structure as the folder in rust-lang/rust This should also include a README.md file containing at least of copy of the crate?s docstring. > 3. A PR will be made against `rust-lang/rust` which will flag the relevant > library as `#[deprecated]` with a message pointing at `rust-lang/$foo` > > In order to ensure that these repositories continue to stay up to date, we > will have the following process in place: > > 1. Each repository will be hooked up to Travis CI and will be built each > night once the new nightlies are available. How will this be achieve? http://www.rust-ci.org/ does it, but I?d like to see something more "official" and tied to the rust-lang.org binary nightlies rather than the Ubuntu PPA. > [...] Regarding documentation on GitHub pages mentioned earlier, the script doing it looks like this: https://github.com/servo/rust-cssparser/blob/331e5695dc/.travis.yml The ` References: <53D8BE7C.2070800@exyr.org> Message-ID: Ok, I got the basic going with a temporary for of `libsemver` here: - https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706 - https://github.com/errordeveloper/rust-libsemver Few questions: - should I bother with enabling OS X beta on Travis? - what naming convetion we gonna use? shall it be `rust-lib{name}`? On 30 July 2014 10:44, Simon Sapin wrote: > Long term, I'd like Rust to have an official package index, like Python's > PyPI: https://pypi.python.org/ I though Cargo had an early version of this... Although, I don't think this is even needed. People should just use git (or other SCM) in a decent fashion, with a branch policy and tagging. If you have a central index, it's a point of failure and you may end-up with bullshit like mirroring. > PyPI provides free hosting for documentation of Python projects. I'd like > Rust to have something like this too. GitHub Pages works and exists now, but > I'm not a fan of generated files in the source repository, even in a > separate branch. I think godoc.org (http://godoc.org/) is pretty sweet, although it doesn't handle revisions, as I can see. Well, neither does `go get`. Anyhow, I think rdoc.info (http://rdoc.info/) is probably the most extensive implementation of an auto-magic docs site. > I've just checked: GitHub does not allow forking (and therefore making PRs > to) an empty repository, so the person creating the repository will have to > at least check the "Initialize this repository with a README" checkbox to > make a dummy first commit. Yeah, could someone create empty repos for all the libs we agreed to pull out? > How will this be achieve? http://www.rust-ci.org/ does it, but I'd like to > see something more "official" and tied to the rust-lang.org binary nightlies > rather than the Ubuntu PPA. Hm... I think we should complete the splitting part, and then look back at this. Perhaps, in the library repos, we can create tags with revision of the compiler that it passed the test on. Crago, in turns, could pick lookup these tags and checkout the relevant version. How do people find this idea? Does Cargo even handle compiler versions at the moment? If not, it's certainly an important feature to add. > Regarding documentation on GitHub pages mentioned earlier, the script doing > it looks like this: > > https://github.com/servo/rust-cssparser/blob/331e5695dc/.travis.yml I pick some bit of yours into mine and we can hopefully come up with a simple template for everyone. From mneumann at ntecs.de Wed Jul 30 06:44:18 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Wed, 30 Jul 2014 15:44:18 +0200 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: References: <53D79AA2.3020507@ntecs.de> Message-ID: <53D8F6B2.9070203@ntecs.de> Am 29.07.2014 um 20:37 schrieb Rob Latham: > "After trying to cross-compile Rust by specifying --target > x86_64-pc-dragonfly-elf to Rust?s own configure script and spending > numerous hours just to note that the build fails"... > > Howdy, fellow crazy cross-compiling person. Did you by any chance > come across my message from a week or so ago? One response seemed > likely to help you if you were encountering a specific kind of build > failure: > > https://mail.mozilla.org/pipermail/rust-dev/2014-July/010827.html > > what other errors were you encountering with the --target approach? When building the related C libraries you also need to specify the --sysroot to point to the DragonFly tree, otherwise it's building the libraries targeted at DragonFly but with Linux header files, which clearly is *wrong*. Actually I wasn't able to cross-compile LLVM. Also when using the --target approach, I always had to wait for hours until it finished the Linux (host) build before it started to build the target. I think I was just waiting too much time for compiles to finish. If someone else figures out how to cross-compile to DragonFly with the --target approach I am happy to know :). Regards, Michael From rlatham at gmail.com Wed Jul 30 07:04:04 2014 From: rlatham at gmail.com (Rob Latham) Date: Wed, 30 Jul 2014 09:04:04 -0500 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: <53D8F6B2.9070203@ntecs.de> References: <53D79AA2.3020507@ntecs.de> <53D8F6B2.9070203@ntecs.de> Message-ID: On Wed, Jul 30, 2014 at 8:44 AM, Michael Neumann wrote: > Am 29.07.2014 um 20:37 schrieb Rob Latham: >> what other errors were you encountering with the --target approach? > > When building the related C libraries you also need to specify the > --sysroot to point to the DragonFly tree, otherwise it's building the > libraries targeted at DragonFly but with Linux header files, which > clearly is *wrong*. I'd set this up in mk/platform.mk. Check out how arm-apple-ios does it: CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null) CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK) -mios-version-min=7.0 CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS) https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158 > Actually I wasn't able to cross-compile LLVM. Also > when using the --target approach, I always had to wait for hours until > it finished the Linux (host) build before it started to build the > target. I think I was just waiting too much time for compiles to finish. > If someone else figures out how to cross-compile to DragonFly with the > --target approach I am happy to know :). I agree it takes a while. ccache is a big help but it still takes a while. ==rob From mneumann at ntecs.de Wed Jul 30 07:22:34 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Wed, 30 Jul 2014 16:22:34 +0200 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: References: <53D79AA2.3020507@ntecs.de> <53D8F6B2.9070203@ntecs.de> Message-ID: <53D8FFAA.9060709@ntecs.de> Am 30.07.2014 um 16:04 schrieb Rob Latham: > On Wed, Jul 30, 2014 at 8:44 AM, Michael Neumann wrote: >> Am 29.07.2014 um 20:37 schrieb Rob Latham: >>> what other errors were you encountering with the --target approach? >> >> When building the related C libraries you also need to specify the >> --sysroot to point to the DragonFly tree, otherwise it's building the >> libraries targeted at DragonFly but with Linux header files, which >> clearly is *wrong*. > > I'd set this up in mk/platform.mk. Check out how arm-apple-ios does it: > > CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null) > CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK) > -mios-version-min=7.0 > CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS) > > https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158 I tried this as you can see here [1]. But you have to consider that Mac OS X comes with an iphone SDK while Linux does not come with DragonFly "SDK" :D. I think no-one ever tried to cross-compile a program for DragonFly :). [1]: https://github.com/mneumann/rust/commit/ab1124980f97558af87b789a1c0772bfa7e23704 Regards, Michael From valerii.hiora at gmail.com Wed Jul 30 07:58:16 2014 From: valerii.hiora at gmail.com (Valerii Hiora) Date: Wed, 30 Jul 2014 17:58:16 +0300 Subject: [rust-dev] [ANN] Rust ported to DragonFlyBSD In-Reply-To: <53D8F6B2.9070203@ntecs.de> References: <53D79AA2.3020507@ntecs.de> <53D8F6B2.9070203@ntecs.de> Message-ID: <53D90808.9090007@gmail.com> Hi, > Also when using the --target approach, I always had to wait for hours > until it finished the Linux (host) build before it started to build > the target. Yep, `--target` approach can be extremely exhausting. One pretty useful dirty trick in this case is to build it once for host and play a lot with `touch -r`. It might be used to recompile only for target when you have changes in mk/* or src/lib*. For example, if you've changed src/libstd/somefile.rs, you can later on do: `touch -r src/libstd/lib.rs src/libstd/somefile.rs` If libstd was compiled successfully before it is required also to delete stamp: `rm build_dir/host_triple/stage2/lib/rustlib/target_triple/lib/stamp.std` and `make -j4` it again, just for target, no waiting for host :-) Used it a lot while porting for iOS and while this message is definitely late for Dragonfly - I hope it will be useful for others who might be interested in porting to platforms which are easier accessible through `--target` approach. -- Valerii -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From alex at crichton.co Wed Jul 30 07:59:53 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 30 Jul 2014 07:59:53 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: <53D8BE7C.2070800@exyr.org> References: <53D8BE7C.2070800@exyr.org> Message-ID: >> We plan to implement any necessary infrastructure to ensure that the >> crates >> move out of the rust repository maintain the same level of quality they >> currently have. > > > Will these crates? documentation be available online? At this time there are no plans for this, but we're certainly open to options! The need for these is a little less pressing now that `cargo doc` is implemented, but this is still a very important aspect to these crates. > Long term, I?d like Rust to have an official package index, like Python?s > PyPI: https://pypi.python.org/ We would as well! This will manifest itself in the form of a central package registry which cargo will also use for downloading remote packages and such. >> To this extent, the current process for moving a crate out of the standard >> distribution will be as follows: >> >> 1. A member of the core team will be contacted to create the repository >> `rust-lang/$foo`. >> 2. A PR will be made against `rust-lang/$foo` > > > I?ve just checked: GitHub does not allow forking (and therefore making PRs > to) an empty repository, so the person creating the repository will have to > at least check the "Initialize this repository with a README" checkbox to > make a dummy first commit. Aha, thanks! >> 3. A PR will be made against `rust-lang/rust` which will flag the relevant >> library as `#[deprecated]` with a message pointing at `rust-lang/$foo` >> >> In order to ensure that these repositories continue to stay up to date, we >> will have the following process in place: >> >> 1. Each repository will be hooked up to Travis CI and will be built each >> night once the new nightlies are available. > > > How will this be achieve? http://www.rust-ci.org/ does it, but I?d like to > see something more "official" and tied to the rust-lang.org binary nightlies > rather than the Ubuntu PPA. There's a cron job running which will trigger each build each night after the nightlies have finished building, and the .travis.yml script for these repos are all wired to nightlies rather than the PPA. From alex at crichton.co Wed Jul 30 08:03:57 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 30 Jul 2014 08:03:57 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: <53D8BE7C.2070800@exyr.org> Message-ID: > Ok, I got the basic going with a temporary for of `libsemver` here: > - https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706 > - https://github.com/errordeveloper/rust-libsemver Awesome! I've created a new repo for you to make a PR against: https://github.com/rust-lang/semver > - should I bother with enabling OS X beta on Travis? Not at this time. > - what naming convetion we gonna use? shall it be `rust-lib{name}`? rust-lang/{name} >> I've just checked: GitHub does not allow forking (and therefore making PRs >> to) an empty repository, so the person creating the repository will have to >> at least check the "Initialize this repository with a README" checkbox to >> make a dummy first commit. > > Yeah, could someone create empty repos for all the libs we agreed to pull out? This will be done on a case-by-case basis, feel free to just ping me or others on IRC and we'll make a repo! From niceguyneil at gmail.com Wed Jul 30 08:22:57 2014 From: niceguyneil at gmail.com (Neil LoBracco) Date: Wed, 30 Jul 2014 11:22:57 -0400 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: Message-ID: I'd like to suggest - assuming it's not implied - that all aforementioned PRs should preserve history to date, rather than just having a copy of the files as they are at present. Decent walkthrough using a subtree merge - http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository/17864475#17864475 -Neil On Tue, Jul 29, 2014 at 6:30 PM, Alex Crichton wrote: > Now that cargo is starting to become a larger part of the Rust ecosystem > it's time for some of the crates as part of the standard distribution to > move out of the main rust repository. This movement has been planned for > quite some time now, and it has only recently become possible with the > advent of cargo. > > Starting today, we'd like to evolve crates not needed by rustc itself > outside of the compiler wherever possible. This will reduce cycle time on > development of these libraries, allow them to develop independently from > rustc, and hopefully allow them to be more focused in their target goals. > > The process of moving crates out of the standard distribution will be an > ongoing and evolving one. We currently have the benefit of being able to > move the entire distribution forward in one atomic step with everything in > one repository, but this quickly becomes infeasible with many repositories. > We plan to implement any necessary infrastructure to ensure that the crates > move out of the rust repository maintain the same level of quality they > currently have. > > To this extent, the current process for moving a crate out of the standard > distribution will be as follows: > > 1. A member of the core team will be contacted to create the repository > `rust-lang/$foo`. > 2. A PR will be made against `rust-lang/$foo` with the current copy of the > code from `rust-lang/rust`. This PR will be expected to have the > following source structure: > > * Cargo.toml - a manifest to build this repo as a cargo package > * .travis.yml - configuration to run automated tests on travis. A > sample can be found for hexfloat [1] > * LICENSE-{MIT,APACHE} - copied over from rust-lang/rust > * src/ - the same source structure as the folder in rust-lang/rust > > 3. A PR will be made against `rust-lang/rust` which will flag the relevant > library as `#[deprecated]` with a message pointing at `rust-lang/$foo` > > In order to ensure that these repositories continue to stay up to date, we > will have the following process in place: > > 1. Each repository will be hooked up to Travis CI and will be built each > night once the new nightlies are available. > 2. A status page [2] is provided to get a quick glance at the status of all > officially supported repositories. > > The amount of infrastructure around keeping these repositories up to date > will likely change over time, but this is the current starting point for > automation. > > [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml > [2]: http://buildbot.rust-lang.org/travis/travis.html > _______________________________________________ > 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 simon.sapin at exyr.org Wed Jul 30 12:55:59 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 30 Jul 2014 20:55:59 +0100 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: References: <53D8BE7C.2070800@exyr.org> Message-ID: <53D94DCF.9060606@exyr.org> On 30/07/14 15:59, Alex Crichton wrote: >>> We plan to implement any necessary infrastructure to ensure that the >>> crates >>> move out of the rust repository maintain the same level of quality they >>> currently have. >> >> >> Will these crates? documentation be available online? > > At this time there are no plans for this, but we're certainly open to > options! This sounds like a significant regression :/ > The need for these is a little less pressing now that `cargo > doc` is implemented, but this is still a very important aspect to > these crates. Yeah, we can easily have Travis run `cargo doc`. The question is where to host the result. > There's a cron job running which will trigger each build each night > after the nightlies have finished building, and the .travis.yml script > for these repos are all wired to nightlies rather than the PPA. Could the source code for this cron job be published, with instructions on how to get API keys or whatever Travis wants? I tried https://github.com/patrickkettner/travis-ping , but only got a mysterious error messages and didn?t feel like debugging that code. -- Simon Sapin From pnathan.software at gmail.com Wed Jul 30 13:41:25 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Wed, 30 Jul 2014 15:41:25 -0500 Subject: [rust-dev] std::num::pow() is inadequate / language concepts In-Reply-To: <1869939.PKr16frPY1@purple> References: <1869939.PKr16frPY1@purple> Message-ID: Gregor, I think the simple answer is that if your function needs to be broadly extensible in the future and to have specialization, it needs to be designed in the trait fashion, per the remarks earlier. On Thu, Jul 24, 2014 at 5:46 PM, Gregor Cramer wrote: > Hello Rust folk! > > > > I am new to Rust, and I have doubts concerning current language concepts. > > > > One example: in module ::std::num function pow() is defined: > > > > pub fn pow>(mut base: T, mut exp: uint) -> T { > > if exp == 1 { base } > > else { > > let mut acc = one::(); > > while exp > 0 { > > if (exp & 1) == 1 { > > acc = acc * base; > > } > > base = base * base; > > exp = exp >> 1; > > } > > acc > > } > > } > > > > In general this implementation is ok, but not really usable with BigInt. Of > > course, the call ':.std::num::pow(a, 1000)', 'a' is a BigInt, works. But > this > > implementation is not adequate for big integers. Firstly, too many memory > > allocations during the computation (a specialized version can avoid these > > memory allocations), secondly, for big integers a specialized function for > > squaring (base * base) has to be used, because squaring can be done quite > > more efficient than multiplication (with big integers). So this function > is much > > too slow and has to be overloaded, but: > > > > 1. Overloading is not supported (even the archaic C++ is providing this). > > > > 2. The footprint 'base: T' is not 100% suitable, for big integers the > function > > definition > > fn pow(base: &BigInt, mut exp: uint) -> BigInt > > would be more appropriate, because the argument 'base' needs not to be > > modified (or reassigned), and a call by reference (avoiding a superfluous > > memory allocation) is more efficient in this case. > > > > Of cource, a specialized version of pow() could be implemented in trait > > BigInt, but this is only a workaround. And if a user only knows > > ::std::num::pow(), he will use an inappropriate implementation without > > being aware of this. > > > > Probably in this case it might be a solution to move pow() into a trait, > but > > I'm speaking about a general problem. Rust 1.0 will be released, and > someone > > is developing a new module for version 1.1. But some of the functions in > 1.0 > > are inadequate for the new module, how to solve this without changing the > API > > in 1.1? I think that function overloading may help in some cases, but the > > problem with inappropriate footprints remains. In my opinion this > > thing with the footprints (reference or not if the real type is unknown - > > that's why the concept with 'const' in C++ exists) is a conceptual design > > issue, but probably I do not yet fully understand Rust. > > > > BTW: the functions next_power_of_two(), and checked_next_power_of_two() > > are only defined for primitives (trait Primitive), but should also be > applicable for big integers, I think . > > > > C heers, > > Gregor > > _______________________________________________ > 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 errordeveloper at gmail.com Wed Jul 30 15:54:41 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Wed, 30 Jul 2014 23:54:41 +0100 Subject: [rust-dev] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team In-Reply-To: References: Message-ID: Are you guys filming it? On 30 July 2014 01:53, Erick Tryzelaar wrote: > Hello Rustillians! > > I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August > 21, 2014, at Mozilla's San Francisco office: Please sign up here if you wish > to attend: > > http://www.meetup.com/Rust-Bay-Area/events/191293242/ > > This is a unique meetup because we will be having the full Mozilla Rust team > in town in attendance and speaking about what they've been working on. Here > is our lineup of speakers: > > * Alex Crichton: Cargo: forged in a crucible of Rust > > * Niko Matsakis: TBD > > * Patrick Walton - Explaining the Borrowcheck (or TBD). > > * Aaron Turon: The intersection of new language features and libraries. > > If you cannot attend in person, we will have the talk livestreamed on Air > Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As > always, Mozilla will be graciously providing food and drink. > > I hope you can all make it! > > -Erick > > PS: The brand new San Francisco Rust Hacknights meetup group is also hosting > a hacknight happening that same week on August 19th: > > http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ > > Don't miss out on it! > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From erick.tryzelaar at gmail.com Wed Jul 30 16:12:18 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 30 Jul 2014 16:12:18 -0700 Subject: [rust-dev] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team In-Reply-To: References: Message-ID: We will be live streaming the August meetup. Tomorrow's meetup will be video taped then uploaded to Air Mozilla. On Wed, Jul 30, 2014 at 3:54 PM, Ilya Dmitrichenko wrote: > Are you guys filming it? > > On 30 July 2014 01:53, Erick Tryzelaar wrote: > > Hello Rustillians! > > > > I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August > > 21, 2014, at Mozilla's San Francisco office: Please sign up here if you > wish > > to attend: > > > > http://www.meetup.com/Rust-Bay-Area/events/191293242/ > > > > This is a unique meetup because we will be having the full Mozilla Rust > team > > in town in attendance and speaking about what they've been working on. > Here > > is our lineup of speakers: > > > > * Alex Crichton: Cargo: forged in a crucible of Rust > > > > * Niko Matsakis: TBD > > > > * Patrick Walton - Explaining the Borrowcheck (or TBD). > > > > * Aaron Turon: The intersection of new language features and libraries. > > > > If you cannot attend in person, we will have the talk livestreamed on Air > > Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As > > always, Mozilla will be graciously providing food and drink. > > > > I hope you can all make it! > > > > -Erick > > > > PS: The brand new San Francisco Rust Hacknights meetup group is also > hosting > > a hacknight happening that same week on August 19th: > > > > http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ > > > > Don't miss out on 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 troplin at bluewin.ch Wed Jul 30 18:08:37 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Thu, 31 Jul 2014 01:08:37 +0000 (UTC) Subject: [rust-dev] Place for discussions Message-ID: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> Hello, I'm following rust for quite a while, but the discussions are more and more distributed between different places. The mailing list was probably first, then with more user attention reddit and StackOverflow, and now the discourse forum. I understand that StackOverflow and Reddit are more for users, not developers, but the discourse forum seems mostly redundant. What's the reason for that split? Is the mailing list deprecated? Which one is the future? I for myself prefer the mailing list because of the gmane NNTP service, I can use my usual usenet software and have all my forums in one place. Tobi From eg1290+rg4 at gmail.com Wed Jul 30 19:15:16 2014 From: eg1290+rg4 at gmail.com (Evan G) Date: Wed, 30 Jul 2014 21:15:16 -0500 Subject: [rust-dev] Place for discussions In-Reply-To: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> References: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> Message-ID: Slightly OT, but there are user setting switches you can set in Discourse that will make it act more like an email list. On Jul 30, 2014 8:08 PM, "Tobias M?ller" wrote: > Hello, > > I'm following rust for quite a while, but the discussions are more and more > distributed between different places. > The mailing list was probably first, then with more user attention reddit > and StackOverflow, and now the discourse forum. > > I understand that StackOverflow and Reddit are more for users, not > developers, but the discourse forum seems mostly redundant. > > What's the reason for that split? Is the mailing list deprecated? Which one > is the future? > > I for myself prefer the mailing list because of the gmane NNTP service, I > can use my usual usenet software and have all my forums in one place. > > Tobi > > _______________________________________________ > 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 alex at crichton.co Thu Jul 31 07:39:37 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 31 Jul 2014 07:39:37 -0700 Subject: [rust-dev] Migrating libs out of rust-lang/rust In-Reply-To: <53D94DCF.9060606@exyr.org> References: <53D8BE7C.2070800@exyr.org> <53D94DCF.9060606@exyr.org> Message-ID: >> There's a cron job running which will trigger each build each night >> after the nightlies have finished building, and the .travis.yml script >> for these repos are all wired to nightlies rather than the PPA. > > > Could the source code for this cron job be published, with instructions on > how to get API keys or whatever Travis wants? I tried > https://github.com/patrickkettner/travis-ping , but only got a mysterious > error messages and didn?t feel like debugging that code. I've posted the scripts here: https://github.com/alexcrichton/bors-travis From simon.sapin at exyr.org Thu Jul 31 08:09:00 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Thu, 31 Jul 2014 16:09:00 +0100 Subject: [rust-dev] [ANN] rust-url Message-ID: <53DA5C0C.3070106@exyr.org> Hi Rustaceans, rustc comes with an `url` crate (previously a `extra::url` module) for parsing an serializing URLs. This crate is now deprecated: https://github.com/rust-lang/rust/commit/491bd299 The replacement is rust-url, which solves a number of issues that the old url crate had and adds some features that were missing: http://servo.github.io/rust-url/ rust-url is not distributed with rustc, but builds easily with Cargo. Please use the GitHub issue tracker for any feedback on the documentation, bugs, feature requests, etc. Cheers, -- Simon Sapin From banderson at mozilla.com Thu Jul 31 15:15:33 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 31 Jul 2014 15:15:33 -0700 Subject: [rust-dev] Place for discussions In-Reply-To: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> References: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> Message-ID: <53DAC005.50603@mozilla.com> Here's the current state of official project support for various forums: * discourse.rust-lang.org is for *discussion of the development of Rust itself*. It is maintained by Mozilla. * r/rust is for user discussion. It is maintained by the community. * rust-dev is for user discussion. It is maintained by Mozilla. It used to be for development discussion but none of the core developers like working there because the signal-to-noise is awful and it is unmoderatable. * stackoverflow is ultimately where we want users to go for help. Discourse is an *experiment* to see if it works better than mailing lists for having civil conversations. If it works, we may shut off the mailing list. It's not clear whether we would extend discourse to general Rust discussion or leave reddit and stackoverflow for that. On 07/30/2014 06:08 PM, Tobias M?ller wrote: > Hello, > > I'm following rust for quite a while, but the discussions are more and more > distributed between different places. > The mailing list was probably first, then with more user attention reddit > and StackOverflow, and now the discourse forum. > > I understand that StackOverflow and Reddit are more for users, not > developers, but the discourse forum seems mostly redundant. > > What's the reason for that split? Is the mailing list deprecated? Which one > is the future? > > I for myself prefer the mailing list because of the gmane NNTP service, I > can use my usual usenet software and have all my forums in one place. > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From banderson at mozilla.com Thu Jul 31 15:38:47 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 31 Jul 2014 15:38:47 -0700 Subject: [rust-dev] [ANN] rust-url In-Reply-To: <53DA5C0C.3070106@exyr.org> References: <53DA5C0C.3070106@exyr.org> Message-ID: <53DAC577.9080202@mozilla.com> Thanks, Simon! This is huge. Simon knows everything about web standards, and this is Servo's URL type, so it's going to be maintained and correct. The old url crate was originally written by me, without looking at any specs, in order to teach Servo able to open `http://www.google.com`. It wasn't the best (though other people improved it). Regards, Brian On 07/31/2014 08:09 AM, Simon Sapin wrote: > Hi Rustaceans, > > rustc comes with an `url` crate (previously a `extra::url` module) for > parsing an serializing URLs. This crate is now deprecated: > > https://github.com/rust-lang/rust/commit/491bd299 > > The replacement is rust-url, which solves a number of issues that the > old url crate had and adds some features that were missing: > > http://servo.github.io/rust-url/ > > rust-url is not distributed with rustc, but builds easily with Cargo. > > Please use the GitHub issue tracker for any feedback on the > documentation, bugs, feature requests, etc. > > Cheers, From me at kevincantu.org Thu Jul 31 15:59:54 2014 From: me at kevincantu.org (Kevin Cantu) Date: Thu, 31 Jul 2014 15:59:54 -0700 Subject: [rust-dev] Place for discussions In-Reply-To: <53DAC005.50603@mozilla.com> References: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> <53DAC005.50603@mozilla.com> Message-ID: That link didn't work for me, but this does: http://discuss.rust-lang.org/t/about-this-forum-please-read/6 Kevin :) On Thu, Jul 31, 2014 at 3:15 PM, Brian Anderson wrote: > Here's the current state of official project support for various forums: > > * discourse.rust-lang.org is for *discussion of the development of Rust > itself*. It is maintained by Mozilla. > * r/rust is for user discussion. It is maintained by the community. > * rust-dev is for user discussion. It is maintained by Mozilla. It used to > be for development discussion but none of the core developers like working > there because the signal-to-noise is awful and it is unmoderatable. > * stackoverflow is ultimately where we want users to go for help. > > Discourse is an *experiment* to see if it works better than mailing lists > for having civil conversations. If it works, we may shut off the mailing > list. It's not clear whether we would extend discourse to general Rust > discussion or leave reddit and stackoverflow for that. > > > > On 07/30/2014 06:08 PM, Tobias M?ller wrote: > >> Hello, >> >> I'm following rust for quite a while, but the discussions are more and >> more >> distributed between different places. >> The mailing list was probably first, then with more user attention reddit >> and StackOverflow, and now the discourse forum. >> >> I understand that StackOverflow and Reddit are more for users, not >> developers, but the discourse forum seems mostly redundant. >> >> What's the reason for that split? Is the mailing list deprecated? Which >> one >> is the future? >> >> I for myself prefer the mailing list because of the gmane NNTP service, I >> can use my usual usenet software and have all my forums in one place. >> >> Tobi >> >> _______________________________________________ >> 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 daniel.fath7 at gmail.com Thu Jul 31 16:08:50 2014 From: daniel.fath7 at gmail.com (Daniel Fath) Date: Fri, 1 Aug 2014 01:08:50 +0200 Subject: [rust-dev] [ANN] rust-url In-Reply-To: <53DAC577.9080202@mozilla.com> References: <53DA5C0C.3070106@exyr.org> <53DAC577.9080202@mozilla.com> Message-ID: Is rust-url compatible with rust-uri? And if not are there any plans to support URI specification with it? On Fri, Aug 1, 2014 at 12:38 AM, Brian Anderson wrote: > Thanks, Simon! > > This is huge. Simon knows everything about web standards, and this is > Servo's URL type, so it's going to be maintained and correct. > > The old url crate was originally written by me, without looking at any > specs, in order to teach Servo able to open `http://www.google.com`. It > wasn't the best (though other people improved it). > > Regards, > Brian > > > > On 07/31/2014 08:09 AM, Simon Sapin wrote: > >> Hi Rustaceans, >> >> rustc comes with an `url` crate (previously a `extra::url` module) for >> parsing an serializing URLs. This crate is now deprecated: >> >> https://github.com/rust-lang/rust/commit/491bd299 >> >> The replacement is rust-url, which solves a number of issues that the old >> url crate had and adds some features that were missing: >> >> http://servo.github.io/rust-url/ >> >> rust-url is not distributed with rustc, but builds easily with Cargo. >> >> Please use the GitHub issue tracker for any feedback on the >> documentation, bugs, feature requests, etc. >> >> Cheers, >> > > _______________________________________________ > 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 eg1290 at gmail.com Thu Jul 31 16:42:23 2014 From: eg1290 at gmail.com (Evan G) Date: Thu, 31 Jul 2014 18:42:23 -0500 Subject: [rust-dev] Place for discussions In-Reply-To: <53DAC005.50603@mozilla.com> References: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> <53DAC005.50603@mozilla.com> Message-ID: The correct link is http://discuss.rust-lang.org On Thu, Jul 31, 2014 at 5:15 PM, Brian Anderson wrote: > Here's the current state of official project support for various forums: > > * discourse.rust-lang.org is for *discussion of the development of Rust > itself*. It is maintained by Mozilla. > * r/rust is for user discussion. It is maintained by the community. > * rust-dev is for user discussion. It is maintained by Mozilla. It used to > be for development discussion but none of the core developers like working > there because the signal-to-noise is awful and it is unmoderatable. > * stackoverflow is ultimately where we want users to go for help. > > Discourse is an *experiment* to see if it works better than mailing lists > for having civil conversations. If it works, we may shut off the mailing > list. It's not clear whether we would extend discourse to general Rust > discussion or leave reddit and stackoverflow for that. > > > > On 07/30/2014 06:08 PM, Tobias M?ller wrote: > >> Hello, >> >> I'm following rust for quite a while, but the discussions are more and >> more >> distributed between different places. >> The mailing list was probably first, then with more user attention reddit >> and StackOverflow, and now the discourse forum. >> >> I understand that StackOverflow and Reddit are more for users, not >> developers, but the discourse forum seems mostly redundant. >> >> What's the reason for that split? Is the mailing list deprecated? Which >> one >> is the future? >> >> I for myself prefer the mailing list because of the gmane NNTP service, I >> can use my usual usenet software and have all my forums in one place. >> >> Tobi >> >> _______________________________________________ >> 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 wichard at vitalitystudios.com Thu Jul 31 17:15:21 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Thu, 31 Jul 2014 19:15:21 -0500 Subject: [rust-dev] [ANN] Rust Cross Support for PNaCl Message-ID: Ladies and Gentlemen, I am pleased to announce WIP-level cross support for le32-unknown-nacl targets, including x86_64-unknown-nacl (ie translated PNaCl modules). I say WIP because of a half-dozen number of caveats arising from either bugs in LLVM (though only w.r.t. PNaCl/NaCl; ie (x86_64|i686)-linux-gnu is unaffected relative to rust proper), restrictions of Pepper plugins, or idiosyncrasies of Newlib. Nonetheless, I've reached a MVP state and thus it is ready to be toyed with by the more courageous among you. PRs are welcome! Given the needed changes to LLVM and the addition of an extra dep (nacl-binutils), this fork is unlikely to be upstreamed. I'm not opposed in any way to upstreaming, however. The fork is located here . If you're curious as to what doesn't work, checkout the issue board. Rust bindings to parts of the Pepper API are located here (also a WIP). A simple "Hello, world!" is located here . Regards, Richard Diamond -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Jul 31 17:23:08 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 31 Jul 2014 17:23:08 -0700 Subject: [rust-dev] [ANN] Rust Cross Support for PNaCl In-Reply-To: References: Message-ID: <53DADDEC.8080806@mozilla.com> Neat! I'm particularly interested that you've ported Rust to newlib, which helps Rust with [this issue](https://github.com/rust-lang/rust/issues/7283). Do you have a complete working standard library that builds against newlib and not glibc? On 07/31/2014 05:15 PM, Richard Diamond wrote: > Ladies and Gentlemen, > > I am pleased to announce WIP-level cross support for le32-unknown-nacl > targets, including x86_64-unknown-nacl (ie translated PNaCl modules). > I say WIP because of a half-dozen number of caveats arising from > either bugs in LLVM (though only w.r.t. PNaCl/NaCl; ie > (x86_64|i686)-linux-gnu is unaffected relative to rust proper), > restrictions of Pepper plugins, or idiosyncrasies of Newlib. > Nonetheless, I've reached a MVP state and thus it is ready to be toyed > with by the more courageous among you. PRs are welcome! > > Given the needed changes to LLVM and the addition of an extra dep > (nacl-binutils), this fork is unlikely to be upstreamed. I'm not > opposed in any way to upstreaming, however. > > The fork is located here . If > you're curious as to what doesn't work, checkout the issue board. > Rust bindings to parts of the Pepper API are located here > (also a WIP). > A simple "Hello, world!" is located here > . > > Regards, > Richard Diamond > > > _______________________________________________ > 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 wichard at vitalitystudios.com Thu Jul 31 17:32:48 2014 From: wichard at vitalitystudios.com (Richard Diamond) Date: Thu, 31 Jul 2014 19:32:48 -0500 Subject: [rust-dev] [ANN] Rust Cross Support for PNaCl In-Reply-To: <53DADDEC.8080806@mozilla.com> References: <53DADDEC.8080806@mozilla.com> Message-ID: Yes, but currently only when target_os = "nacl", ie when one has targeted le32-unknown-nacl (otherwise it's just a matter of using --cfg "target_libc=\"newlib\""). I should note however, libuv is for the most part unable to use Newlib (last time I tried, it was a mess, even after much effort on my part to remove uses of glibc only functions). In fact, it is this reason libuv is disabled for PNaCl. Richard Diamond On Thu, Jul 31, 2014 at 7:23 PM, Brian Anderson wrote: > Neat! > > I'm particularly interested that you've ported Rust to newlib, which helps > Rust with [this issue](https://github.com/rust-lang/rust/issues/7283). Do > you have a complete working standard library that builds against newlib and > not glibc? > > > On 07/31/2014 05:15 PM, Richard Diamond wrote: > > Ladies and Gentlemen, > > I am pleased to announce WIP-level cross support for le32-unknown-nacl > targets, including x86_64-unknown-nacl (ie translated PNaCl modules). I say > WIP because of a half-dozen number of caveats arising from either bugs in > LLVM (though only w.r.t. PNaCl/NaCl; ie (x86_64|i686)-linux-gnu is > unaffected relative to rust proper), restrictions of Pepper plugins, or > idiosyncrasies of Newlib. Nonetheless, I've reached a MVP state and thus it > is ready to be toyed with by the more courageous among you. PRs are welcome! > > Given the needed changes to LLVM and the addition of an extra dep > (nacl-binutils), this fork is unlikely to be upstreamed. I'm not opposed in > any way to upstreaming, however. > > The fork is located here . If > you're curious as to what doesn't work, checkout the issue board. > Rust bindings to parts of the Pepper API are located here > (also a WIP). > A simple "Hello, world!" is located here > . > > Regards, > Richard Diamond > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://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 errordeveloper at gmail.com Thu Jul 31 22:19:15 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Fri, 1 Aug 2014 06:19:15 +0100 Subject: [rust-dev] [ANN] Rust Cross Support for PNaCl In-Reply-To: References: <53DADDEC.8080806@mozilla.com> Message-ID: On 1 August 2014 01:32, Richard Diamond wrote: > Yes, but currently only when target_os = "nacl", ie when one has targeted > le32-unknown-nacl (otherwise it's just a matter of using --cfg > "target_libc=\"newlib\""). I should note however, libuv is for the most part > unable to use Newlib (last time I tried, it was a mess, even after much > effort on my part to remove uses of glibc only functions). In fact, it is > this reason libuv is disabled for PNaCl. It'd would be helpful if you could point out what specific parts of libuv depend on glibc... We need to figure out how to move forward with this, whether it's fixable or rustuv crate would have to be disable when newlib is in in use. From errordeveloper at gmail.com Thu Jul 31 22:51:45 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Fri, 1 Aug 2014 06:51:45 +0100 Subject: [rust-dev] Place for discussions In-Reply-To: References: <927038759428461094.055756troplin-bluewin.ch@news.gmane.org> <53DAC005.50603@mozilla.com> Message-ID: I think the point of discourse is that it provides a far better user interface then the mailing list does. Mailing lists are pretty backward in this day an age. The basics are that you can tag discussions and use backticks to quote code etc. Other smart things you can probably implement is sorting based on which discussion has been more active on average response frequency in given period of time, and not just you mail client's "most recently replied to" kind of sorting. Cross-referencing with github issues/pulls would be great to have! On 1 August 2014 00:42, Evan G wrote: > The correct link is http://discuss.rust-lang.org > > > On Thu, Jul 31, 2014 at 5:15 PM, Brian Anderson > wrote: >> >> Here's the current state of official project support for various forums: >> >> * discourse.rust-lang.org is for *discussion of the development of Rust >> itself*. It is maintained by Mozilla. >> * r/rust is for user discussion. It is maintained by the community. >> * rust-dev is for user discussion. It is maintained by Mozilla. It used to >> be for development discussion but none of the core developers like working >> there because the signal-to-noise is awful and it is unmoderatable. >> * stackoverflow is ultimately where we want users to go for help. >> >> Discourse is an *experiment* to see if it works better than mailing lists >> for having civil conversations. If it works, we may shut off the mailing >> list. It's not clear whether we would extend discourse to general Rust >> discussion or leave reddit and stackoverflow for that. >> >> >> >> On 07/30/2014 06:08 PM, Tobias M?ller wrote: >>> >>> Hello, >>> >>> I'm following rust for quite a while, but the discussions are more and >>> more >>> distributed between different places. >>> The mailing list was probably first, then with more user attention reddit >>> and StackOverflow, and now the discourse forum. >>> >>> I understand that StackOverflow and Reddit are more for users, not >>> developers, but the discourse forum seems mostly redundant. >>> >>> What's the reason for that split? Is the mailing list deprecated? Which >>> one >>> is the future? >>> >>> I for myself prefer the mailing list because of the gmane NNTP service, I >>> can use my usual usenet software and have all my forums in one place. >>> >>> Tobi >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >