[rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
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/119000593564 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
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 fantix.k...@gmail.com 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/119000593564 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
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 co...@octayn.net 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 fantix.k...@gmail.com 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/119000593564 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Cargo multiple targets
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 = [ i...@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 = [ i...@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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cargo multiple targets
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 = [ i...@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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cargo multiple targets
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.gesem...@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 = [ i...@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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cargo multiple targets
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 cont...@bitpuffin.com 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.gesem...@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 = [ i...@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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cargo multiple targets
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 dpx.infin...@gmail.com 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 cont...@bitpuffin.com 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.gesem...@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 = [ i...@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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] ref binding for parameters of functions?
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: Vecint) {...}
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@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] conflicting implementations for trait
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 st...@steveklabnik.com
wrote:
You cannot.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] ref binding for parameters of functions?
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
s.gesem...@gmail.com 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: Vecint) {...}
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@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] ref binding for parameters of functions?
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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
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 fantix.k...@gmail.com 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 co...@octayn.net 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 fantix.k...@gmail.com 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/119000593564 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rust 0.11.0 Released
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 VecT 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 BoxT type. * @T has been removed from the language. This type is superseded by the standard library's std::gc::GcT 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.
Re: [rust-dev] Partial meeting agenda - older RFCs
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 li...@ncameron.org 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
Re: [rust-dev] Partial meeting agenda - older RFCs
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 glaebho...@gmail.com 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 li...@ncameron.org 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
Re: [rust-dev] Partial meeting agenda - older RFCs
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 li...@ncameron.org
mailto:li...@ncameron.org 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
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus
See also the discussion on IRC: https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232page=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 slab...@aim.com 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Partial meeting agenda - older RFCs
On Thu, Jul 3, 2014 at 6:19 AM, Gábor Lehel glaebho...@gmail.com 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 li...@ncameron.org 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
Re: [rust-dev] Partial meeting agenda - older RFCs
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 glaebho...@gmail.com 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 li...@ncameron.org 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
Re: [rust-dev] Rust 0.11.0 Released
Well done! 1.0 draws closer every day. I'm giddy with anticipation. On Wed, Jul 2, 2014 at 2:07 PM, Alex Crichton a...@crichton.co 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 VecT 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 BoxT type. * @T has been removed from the language. This type is superseded by the standard library's std::gc::GcT 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
Re: [rust-dev] Rust 0.11.0 Released
Congrat and thank for the good work! On Wed, Jul 2, 2014 at 8:07 PM, Alex Crichton a...@crichton.co wrote: Mozilla and the Rust community are pleased to announce version 0.11.0 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.11.0 Released
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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point)
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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point)
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 m...@carllerche.com 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Met with a terrible fate
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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.11.0 Released
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 zo1...@gmail.com 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.11.0 Released
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 zo1...@gmail.com 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Met with a terrible fate
Hi! Anything in the std lib that touches the runtime (task spawning and concurrency stuff, i/o, probably `GcT` 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Met with a terrible fate
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 cont...@bitpuffin.com 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] box syntax question
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: boxGc, 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] box syntax question
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 os...@twitter.com 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: boxGc, 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] box syntax question
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 co...@octayn.net 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 os...@twitter.com 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: boxGc, 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@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
