Re: [rust-dev] impl num::Zero and std::ops::Add error
On 10 Apr 2014, at 07:53, Kevin Ballard ke...@sb.org wrote: On Apr 9, 2014, at 9:50 PM, Tommi Tissari rusty.ga...@icloud.com wrote: On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote: FWIW, my point about range is it relies on One being the number 1, rather than being the multiplicative identity. AFAIK there's nothing special about 1 in a ring outside of its status as a multiplicative identity. Certainly it's not considered some special value for addition. Another problem with std::iter::range is that it requires too much from its argument type A by saying A must implement AddA, A while it only returns a forward iterator. Perhaps, in order to make a more sensible implementation of iter::range, a new concept, a trait, is needed to be able to specify that a certain type T implements a method 'increment' that modifies a variable of type T from value x to value y such that: 1) x y 2) there is no valid value z of type T satisfying x z y For integral types there would an implementation of this trait in stdlib with 'increment' doing x += 1; Then, a natural extension to this trait would be a trait that has a method 'advance(n: uint)' that would, at constant time, conceptually call the 'increment' method n times. Then there would also be a 'decrement' method for going the other direction. There probably needs to be some other use cases for this new trait to carry its weight though. This trait would disallow range(0f32, 10f32) because there are quite a lot of valid values z of type f32 satisfying 0f32 z 1f32. -Kevin The trait wouldn't disallow, but it would change the meaning of such range. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] impl num::Zero and std::ops::Add error
On Apr 9, 2014, at 11:25 PM, Tommi Tissari rusty.ga...@icloud.com wrote: On 10 Apr 2014, at 07:55, Corey Richardson co...@octayn.net wrote: range doesn't return a forward iterator. RangeA also implements DoubleEndedIterator. Ok, I didn't realize that. But it still should't require AddA, A when all it needs is a way to get to the next and previous values. Any such trait for this would really need to be designed expressly for Range, and then reimplemented for every single numeric type. -Kevin smime.p7s Description: S/MIME cryptographic signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] impl num::Zero and std::ops::Add error
A nice side-effect of using such a trait as a bound to the range argument type A is that the meaning of iter::range(a, b) would become coherent (same regardless of A) and more intuitive: returns a DoubleEndedIterator to all the possible (and valid) values of type A in [a, b) in ascending order. On 10 Apr 2014, at 09:27, Kevin Ballard ke...@sb.org wrote: On Apr 9, 2014, at 11:25 PM, Tommi Tissari rusty.ga...@icloud.com wrote: On 10 Apr 2014, at 07:55, Corey Richardson co...@octayn.net wrote: range doesn't return a forward iterator. RangeA also implements DoubleEndedIterator. Ok, I didn't realize that. But it still should't require AddA, A when all it needs is a way to get to the next and previous values. Any such trait for this would really need to be designed expressly for Range, and then reimplemented for every single numeric type. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some help needed in Vector of enum conversion
I trying to do some polymorphism with trait and object and I have some
problems.
At the beginning I want to store different types of object that
implement the same trait (Base) in a Vec. To do this I use the enum
pattern. If the enum contains only struct, I manage to iter the Vec for
the different types.
code:
enum BaseImpl{
FirstThinkImpl(FirstThink),
SecondThinkImpl(SecondThink),
}
What I would like to do is to have a generic method to add like
addMyBaseTrait( ~Base) to add all the struct that implement Base to the
vector and to have a specific method that add a specific struct
addSecondStruct(~SecondStruct). The enum is changed to:
enum BaseImpl{
FirstThinkImpl(~Base),
SecondThinkImpl(~SecondThink),
}
With this enum has have problem to iter the vector. I didn't find a way
to iter all the vector and return Base or ~Base:
this code
impl'a Iterator'a ~Base for BaseItems'a {
fn next(mut self) - Option'a ~Base{
match self.iter.next() {
Some(ref baseimpl) = {
Some(match ***baseimpl{
FirstThinkImpl(ref first) = first,
SecondThinkImpl(ref second)= 'a (*second as ~Base),
})
},
None = None,
}
}
}
generate an error borrowed value does not live long enough
SecondThinkImpl(ref second)= 'a (*second as ~Base), which is logic so
I try not to borrow with this code:
SecondThinkImpl(ref second)= second as 'a ~Base,
and I have the error non-scalar cast: `~SecondThink` as `'a
~Baseno-bounds`
Perhaps there is no way. I didn't find any.
What I see with all my test is that a trait must be use as a reference
to be stored but object reference can't be cast to a reference trait and
trait can't be cast to an object. So it seems that tray is useful to
pass or return parameters to method but not to store data.
Philippe
Le 09/04/2014 21:53, Philippe Delrieu a écrit :
I find a solution by removing the ~ to Base trait.
The code
//(First and Second think as defined earlier)
enum BaseImpl{
FirstThinkImpl(FirstThink),
SecondThinkImpl(SecondThink),
}
struct Container{
nodeList: Vec~BaseImpl,
}
impl'a Container{
fn iter_base('a self) - BaseItems'a {
let iter = self.nodeList.iter();
BaseItems{ iter : iter }
}
}
struct BaseItems'a {
iter : Items'a, ~BaseImpl
}
impl'a Iterator'a Base for BaseItems'a {
fn next(mut self) - Option'a Base{
match self.iter.next() {
Some(ref baseimpl) = {
Some(match ***baseimpl{
FirstThinkImpl(ref first) = first as 'a Base,
SecondThinkImpl(ref second)= second as 'a Base,
})
},
None = None,
}
}
}
Now it compile.
So I try to define a mutable iterator like the immuable and with
similar code I have again the lifetime compile error :
struct BaseMutItems'a {
iter : MutItems'a, ~BaseImpl
}
impl'a Iterator'a mut Base for BaseMutItems'a {
fn next(mut self) - Option'a mut Base {
match self.iter.next() {
Some(ref mut baseimpl) = {
Some(match ***baseimpl{
FirstThinkImpl(ref mut first) = first as 'a mut
Base,
SecondThinkImpl(ref mut second)= second as 'a
mut Base,
})
},
None = None,
}
}
}
error :
test_enum.rs:125:36: 125:49 error: lifetime of `baseimpl` is too short
to guarantee its contents can be safely reborrowed
test_enum.rs:125 FirstThinkImpl(ref mut first) =
first as 'a mut Base,
I can't see what's going wrong.
I put all the code if someone want to test :
use std::iter::Iterator;
use std::slice::{Items, MutItems};
trait Base{
fn set_something(mut self);
fn isSecondThink(self) - bool;
}
struct FirstThink{
count1: int,
}
impl Base for FirstThink{
fn set_something(mut self){println!(ici First count:{:?},
self.count1); self.count1+=1;}
fn isSecondThink(self) - bool {false}
}
struct SecondThink{
count2: int,
}
impl Base for SecondThink{
fn set_something(mut self){println!(ici Second count:{:?},
self.count2); self.count2+=1;}
fn isSecondThink(self) - bool {true}
}
enum BaseImpl{
FirstThinkImpl(FirstThink),
SecondThinkImpl(SecondThink),
}
fn some_second_process(think: mut SecondThink){
think.set_something();
}
struct Container{
nodeList: Vec~BaseImpl,
}
impl'a Container{
fn add_FirstThink(mut self, think: FirstThink){
self.nodeList.push(~FirstThinkImpl(think));
}
fn add_SecondThink(mut self, think: SecondThink){
self.nodeList.push(~SecondThinkImpl(think));
}
fn iter_base('a self) - BaseItems'a {
let iter = self.nodeList.iter();
BaseItems{ iter : iter }
}
fn iter_second('a self) - SecondItems'a {
Re: [rust-dev] impl num::Zero and std::ops::Add error
Actually, I'd like to reiterate my original view that num::Zero should be renamed to AdditiveIdentity (bear with me) based on the fact that when mathematicians use the symbol 0 to denote additive identity, the symbol 0 is not read zero, but as additive identity. All the reasoning above applies to renaming num::One to MultiplicativeIdentity as well (as it pertains to symbol 1 denoting multiplicative identity). If those names are too long, the shortened AddIdentity and MulIdentity could be used instead. On 10 Apr 2014, at 00:06, Tommi Tissari rusty.ga...@icloud.com wrote: On 09 Apr 2014, at 23:42, Kevin Ballard ke...@sb.org wrote: The number 0 is the additive identity for numbers. But informally, the additive identity for other things can be called zero without problem. Ok, so it seems. From http://en.m.wikipedia.org/wiki/Identity_(mathematics) The number 0 is the additive identity (identity element for the binary operation of addition) for integers, real numbers, and complex numbers. For every number a, including 0 itself, In a more general context, when a binary operation is denoted with + and has an identity, this identity is commonly denoted by the symbol 0 (zero) and called an additive identity. ___ 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] does not fulfill `Send` error since last pull request
Since my last today gill fetch I have this error:
error: instantiating a type parameter with an incompatible type
`~BaseImpl`, which does not fulfill `Send`
for this code :
trait Base{}
struct SecondThink{
count2: int,
}
enum BaseImpl{
FirstThinkImpl(~Base),
SecondThinkImpl(~SecondThink),
}
let (newchan, newport): (SenderBaseImpl, ReceiverBaseImpl) =
channel(); -- error here
^~~
The Send behavior has changed? Is it permanent and if yes is there a
work around?
Philippe
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] does not fulfill `Send` error since last pull request
Your BaseImpl enum isn't necessarily Send because it contains a trait
object (~Base). The typechecker doesn't know what type is behind this
trait object, so it doesn't know whether it's send or not. To make the
BaseImpl type Send again, you can change the definition to:
enum BaseImpl {
FirstThinkImpl(~Base:Send), // note the :Send
SecondThinkImpl(~SecondThink),
}
This error message should get much better with opt-in bounds [1] as it
will point exactly at what's not Send.
[1] -
https://github.com/rust-lang/rfcs/blob/master/active/0003-opt-in-builtin-traits.md
as
On Thu, Apr 10, 2014 at 11:23 AM, Philippe Delrieu
philippe.delr...@free.fr wrote:
Since my last today gill fetch I have this error:
error: instantiating a type parameter with an incompatible type `~BaseImpl`,
which does not fulfill `Send`
for this code :
trait Base{}
struct SecondThink{
count2: int,
}
enum BaseImpl{
FirstThinkImpl(~Base),
SecondThinkImpl(~SecondThink),
}
let (newchan, newport): (SenderBaseImpl, ReceiverBaseImpl) = channel();
-- error here
^~~
The Send behavior has changed? Is it permanent and if yes is there a work
around?
Philippe
___
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] About Rust programming language.
Thank you for your interest, but this is not a constructive topic for this venue. On 04/10/2014 11:35 AM, Jason Long wrote: Hello Folks. How are you? I want to know something about Rust language and Is it C killer? I mean is that in the future is it a replacement for C? Cheers. ___ 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] Debugging with Rust 0.11 nightly
-g, or --debuginfo (0|1|2) will generate debuginfo. -g means --debuginfo 2. see rustc --help for more details. On Thu, Apr 10, 2014 at 8:13 AM, Artella Coding artella.cod...@googlemail.com wrote: Previously I would have debugged using the command rustc -Z debug-info example.rs. However with Rust 0.11 nightly it does not work. What do I replace the above command with? Thanks. ___ 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] About Rust programming language.
Sorry for the curt response. The answer is that Rust is suitable for many of the same tasks as C. Thank you. Please do not have this discussion here. On 04/10/2014 11:58 AM, Brian Anderson wrote: Thank you for your interest, but this is not a constructive topic for this venue. On 04/10/2014 11:35 AM, Jason Long wrote: Hello Folks. How are you? I want to know something about Rust language and Is it C killer? I mean is that in the future is it a replacement for C? Cheers. ___ 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] About Rust programming language.
Much better 2nd response, Brian. More like a salesman. You want to pull them in ... not push them away :-) On Thu, Apr 10, 2014 at 2:01 PM, Brian Anderson bander...@mozilla.comwrote: Sorry for the curt response. The answer is that Rust is suitable for many of the same tasks as C. Thank you. Please do not have this discussion here. On 04/10/2014 11:58 AM, Brian Anderson wrote: Thank you for your interest, but this is not a constructive topic for this venue. On 04/10/2014 11:35 AM, Jason Long wrote: Hello Folks. How are you? I want to know something about Rust language and Is it C killer? I mean is that in the future is it a replacement for C? Cheers. ___ 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 -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Rust windows bots have transitioned to mingw-w64
After a long time coming, the Rust windows bots are now running an up-to-date mingw-w64 toolchain. This was a very easy transition thanks to the efforts of our windows devs, including Vadim, Thad, and klutzy. The practical impact of this is that windows developers should prefer the mingw-w64 toolchain to the old mingw toolchain. This is the toolchain we will be supporting on Windows for the immediate future. I've updated the [windows instructions] and the [getting started] page slightly, but there's a lot of information there that I don't fully understand. I'd appreciate if some of the more experienced windows devs could go over them and make sure they are accurate. The next step will be to add 64-bit windows bots and snapshots. [windows instructions]: https://github.com/mozilla/rust/wiki/Using-Rust-on-Windows [getting started]: https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Anyone in NYC?
So this is happening now: http://www.meetup.com/nyccpp/events/168545012/ It's the C++ meetup, but I'll be giving a short talk on rust. Please RSVP before it fills up! - Clark On Wed, Mar 26, 2014 at 10:30 PM, Carter Schonwald carter.schonw...@gmail.com wrote: I'm in NYC. ya'll should come to the nyc haskell hackathon, there'll be lots of folks there who enjoy strongly typed systemsy code, tis april 4-6, all welcome! www.haskell.org/haskellwiki/Hac_NYC On Wed, Mar 19, 2014 at 9:40 PM, Andrew Morrow andrew.c.mor...@gmail.comwrote: On Mar 18, 2014, at 8:27 PM, Clark Gaebel cg.wowus...@gmail.com wrote: I'm not sure if we have enough people for a reasonable-sized meetup, but I wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to give a short sales pitch presentation if you make this happen. - Clark Hi Clark - I'm sure we can find a way to make that work. The nyccpp meetup has three upcoming talks, but I think those are best left as single topic given the content. But I'd like to get a fourth talk on the calendar and I think a short rust sales pitch would be well received. Let's take this off list and see what we can put together. Thanks, Andrew ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust windows bots have transitioned to mingw-w64
Ra Ra Ooo La La ! Good work team ! (looking forward to the 64-bit snapshots) On Thu, Apr 10, 2014 at 7:05 PM, Brian Anderson bander...@mozilla.comwrote: After a long time coming, the Rust windows bots are now running an up-to-date mingw-w64 toolchain. This was a very easy transition thanks to the efforts of our windows devs, including Vadim, Thad, and klutzy. The practical impact of this is that windows developers should prefer the mingw-w64 toolchain to the old mingw toolchain. This is the toolchain we will be supporting on Windows for the immediate future. I've updated the [windows instructions] and the [getting started] page slightly, but there's a lot of information there that I don't fully understand. I'd appreciate if some of the more experienced windows devs could go over them and make sure they are accurate. The next step will be to add 64-bit windows bots and snapshots. [windows instructions]: https://github.com/mozilla/ rust/wiki/Using-Rust-on-Windows [getting started]: https://github.com/mozilla/rust/wiki/Note-getting- started-developing-Rust ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] does not fulfill `Send` error since last pull request
On Thu, Apr 10, 2014 at 2:28 PM, Alex Crichton a...@crichton.co wrote: [1] - https://github.com/rust-lang/rfcs/blob/master/active/0003-opt-in-builtin-traits.md Off topic, but sigh... first private fields, now this to add even more verbosity to declaring a struct, which really should be a very low friction thing. Not the end of the world but I don't like it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
