Re: [rust-dev] Is it possible to implement "extension methods" on existing traits?

2014-04-05 Thread Patrick Walton

Try this:

On 4/5/14 1:55 PM, Frank Huang wrote:

impl MySerialization for T {
   fn write_my_string(&mut self, s: &str) -> IoResult<()> {
 ...
   }
}

impl StructToBeSerialized {
   fn save_to(&self, mut writer: &mut io::Writer) -> io::IoResult<()> {
 try!(writer.write_my_string(self.string_field_1)); // error at this
line
   }
}


This error will probably go away with DST.

Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Is it possible to implement "extension methods" on existing traits?

2014-04-05 Thread Sean McArthur
I can't say why the "immutable argument" error is happening, but there's
another error in that function. You're using a `Writer`, but Writer doesn't
have `write_my_string`, only `MySerialization` does. I'd write that like
this:

fn save_to(&self, writer: &mut T) -> io::IoResult<()> {
  writer.write_my_string(self.string_field_1) // don't need try!, since
you're returning an IoResult
}


On Sat, Apr 5, 2014 at 1:55 PM, Frank Huang  wrote:

> Thanks for the quick response, Steven! Having done what you suggested, I'm
> now getting the following error (for serializing a larger struct in which
> some fields are strings):
>
> impl MySerialization for T {
>   fn write_my_string(&mut self, s: &str) -> IoResult<()> {
> ...
>   }
> }
>
> impl StructToBeSerialized {
>   fn save_to(&self, writer: &mut io::Writer) -> io::IoResult<()> {
> try!(writer.write_my_string(self.string_field_1)); // error at this
> line
>   }
> }
>
> The error is at the indicated line and it says: cannot borrow immutable
> argument `writer` as mutable. However, the function argument writer to
> save_to is a &mut io::Writer, which would seem to be mutable to me. Would
> you happen to know what's going wrong with this code?
>
> Thanks again!
> Frank
>
>
>
>
> On Sat, Apr 5, 2014 at 1:17 PM, Steven Fackler  wrote:
>
>> You can do it like this:
>>
>> impl MySerialization for T {
>> ...
>> }
>>
>> Steven Fackler
>>
>>
>> On Sat, Apr 5, 2014 at 12:57 PM, Frank Huang  wrote:
>>
>>> Hello everyone,
>>>
>>> I have a question about making "extension methods" on something like
>>> io::Writer. Basically, I have a data format that requires strings to be
>>> serialized as an 8-byte length header and then the string bytes themselves.
>>> Instead of having to type writer.write_u64(...); writer.write_str(...);
>>> over and over again, I would like to implement some "extension methods" or
>>> something like that on io::Writer, like the following pseudocode:
>>>
>>> trait MySerialization {
>>>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()>;
>>> }
>>>
>>> impl MySerialization for io::Writer {
>>>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()> {
>>> try!(self.write_u64(s.len());
>>> self.write_str(s);
>>>   }
>>> }
>>>
>>> However, this of course doesn't work, because I can't implement a trait
>>> for a trait. Rustc says: "reference to trait `io::Writer` where a type is
>>> expected; try `@io::Writer`, `~io::Writer`, or `&io::Writer`", however when
>>> I try "&io::Writer" as suggested, rustc complains about lifetimes. Is this
>>> sort of thing possible in Rust?
>>>
>>> Thanks for your help!
>>> - Frank
>>>
>>> ___
>>> 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] Is it possible to implement "extension methods" on existing traits?

2014-04-05 Thread Frank Huang
Thanks for the quick response, Steven! Having done what you suggested, I'm
now getting the following error (for serializing a larger struct in which
some fields are strings):

impl MySerialization for T {
  fn write_my_string(&mut self, s: &str) -> IoResult<()> {
...
  }
}

impl StructToBeSerialized {
  fn save_to(&self, writer: &mut io::Writer) -> io::IoResult<()> {
try!(writer.write_my_string(self.string_field_1)); // error at this line
  }
}

The error is at the indicated line and it says: cannot borrow immutable
argument `writer` as mutable. However, the function argument writer to
save_to is a &mut io::Writer, which would seem to be mutable to me. Would
you happen to know what's going wrong with this code?

Thanks again!
Frank




On Sat, Apr 5, 2014 at 1:17 PM, Steven Fackler  wrote:

> You can do it like this:
>
> impl MySerialization for T {
> ...
> }
>
> Steven Fackler
>
>
> On Sat, Apr 5, 2014 at 12:57 PM, Frank Huang  wrote:
>
>> Hello everyone,
>>
>> I have a question about making "extension methods" on something like
>> io::Writer. Basically, I have a data format that requires strings to be
>> serialized as an 8-byte length header and then the string bytes themselves.
>> Instead of having to type writer.write_u64(...); writer.write_str(...);
>> over and over again, I would like to implement some "extension methods" or
>> something like that on io::Writer, like the following pseudocode:
>>
>> trait MySerialization {
>>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()>;
>> }
>>
>> impl MySerialization for io::Writer {
>>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()> {
>> try!(self.write_u64(s.len());
>> self.write_str(s);
>>   }
>> }
>>
>> However, this of course doesn't work, because I can't implement a trait
>> for a trait. Rustc says: "reference to trait `io::Writer` where a type is
>> expected; try `@io::Writer`, `~io::Writer`, or `&io::Writer`", however when
>> I try "&io::Writer" as suggested, rustc complains about lifetimes. Is this
>> sort of thing possible in Rust?
>>
>> Thanks for your help!
>> - Frank
>>
>> ___
>> 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] Some help needed in Vector of enum conversion

2014-04-05 Thread Philippe Delrieu

Very good idea. The vector don't have to be modified so it'll work.

Thank you for the advice. I make a try an I'll post the result.

Philippe

Le 05/04/2014 21:59, Rodrigo Rivas a écrit :

On Fri, Apr 4, 2014 at 10:41 PM, Philippe Delrieu
 wrote:

Hello,

I've some problem to find a solution for something I want to do with a
vector of enum. This is an example of what I want to do:

trait Base{
   fn set_something(&mut self);
}

struct FirstThink;

impl Base for FirstThink{
   fn set_something(&mut self){}
}

struct SecondThink;
impl Base for SecondThink{
   fn set_something(&mut self){}
}

enum BaseImpl{
 FirstThinkImpl(~FirstThink),
 SecondThinkImpl(~SecondThink),
}

fn some_process(list: &mut Vec<&mut ~Base>){
 for think in list.mut_iter()   {
 think.set_something();
 }
}

struct Container{
 nodeList: Vec<~BaseImpl>,
}

impl 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 do_some_process(&mut self, fct: fn(&mut Vec<&mut ~Base>)){
  I didn't find a simple  way to convert the Vec<~BaseImpl> to a &mut
Vec<&mut ~Base>
  to do the call
fct(self.nodeList);

 }
}

I use the enum pattern to have only one collection of object that impl Base
but sometime I have to do specific processing depending if the Base is a
FirstThink or SecondThink (not in the example). I use the match as follow

match think {
 FirstThinkImpl(first) => do specific first,
 SecondThinkImpl(second)=> do specific second,
});

Perhaps there is a better way to do. Any suggestions would  be appreciated.

I think that would be better if the `fct` function take an
`std::iter::Iterator<&mut ~Base>` instead of a `Vec`. Naturally, you
will not be able to modify the vector, only to iterate through it. But
if `fct` is allowed to modify the vector your requirements are
impossible in the first place!

Then you can write a simple adaptor:

impl std::iter::Iterator<&mut ~Base> for Container {
 // left as an exercise to the reader ;-)
}



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Is it possible to implement "extension methods" on existing traits?

2014-04-05 Thread Steven Fackler
You can do it like this:

impl MySerialization for T {
...
}

Steven Fackler


On Sat, Apr 5, 2014 at 12:57 PM, Frank Huang  wrote:

> Hello everyone,
>
> I have a question about making "extension methods" on something like
> io::Writer. Basically, I have a data format that requires strings to be
> serialized as an 8-byte length header and then the string bytes themselves.
> Instead of having to type writer.write_u64(...); writer.write_str(...);
> over and over again, I would like to implement some "extension methods" or
> something like that on io::Writer, like the following pseudocode:
>
> trait MySerialization {
>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()>;
> }
>
> impl MySerialization for io::Writer {
>   fn write_my_string(&mut self, s: &str) -> io::IoResult<()> {
> try!(self.write_u64(s.len());
> self.write_str(s);
>   }
> }
>
> However, this of course doesn't work, because I can't implement a trait
> for a trait. Rustc says: "reference to trait `io::Writer` where a type is
> expected; try `@io::Writer`, `~io::Writer`, or `&io::Writer`", however when
> I try "&io::Writer" as suggested, rustc complains about lifetimes. Is this
> sort of thing possible in Rust?
>
> Thanks for your help!
> - Frank
>
> ___
> 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] Some help needed in Vector of enum conversion

2014-04-05 Thread Rodrigo Rivas
On Fri, Apr 4, 2014 at 10:41 PM, Philippe Delrieu
 wrote:
> Hello,
>
> I've some problem to find a solution for something I want to do with a
> vector of enum. This is an example of what I want to do:
>
> trait Base{
>   fn set_something(&mut self);
> }
>
> struct FirstThink;
>
> impl Base for FirstThink{
>   fn set_something(&mut self){}
> }
>
> struct SecondThink;
> impl Base for SecondThink{
>   fn set_something(&mut self){}
> }
>
> enum BaseImpl{
> FirstThinkImpl(~FirstThink),
> SecondThinkImpl(~SecondThink),
> }
>
> fn some_process(list: &mut Vec<&mut ~Base>){
> for think in list.mut_iter()   {
> think.set_something();
> }
> }
>
> struct Container{
> nodeList: Vec<~BaseImpl>,
> }
>
> impl 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 do_some_process(&mut self, fct: fn(&mut Vec<&mut ~Base>)){
>  I didn't find a simple  way to convert the Vec<~BaseImpl> to a &mut
> Vec<&mut ~Base>
>  to do the call
>fct(self.nodeList);
>
> }
> }
>
> I use the enum pattern to have only one collection of object that impl Base
> but sometime I have to do specific processing depending if the Base is a
> FirstThink or SecondThink (not in the example). I use the match as follow
>
> match think {
> FirstThinkImpl(first) => do specific first,
> SecondThinkImpl(second)=> do specific second,
> });
>
> Perhaps there is a better way to do. Any suggestions would  be appreciated.

I think that would be better if the `fct` function take an
`std::iter::Iterator<&mut ~Base>` instead of a `Vec`. Naturally, you
will not be able to modify the vector, only to iterate through it. But
if `fct` is allowed to modify the vector your requirements are
impossible in the first place!

Then you can write a simple adaptor:

impl std::iter::Iterator<&mut ~Base> for Container {
// left as an exercise to the reader ;-)
}

-- 
Rodrigo
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Is it possible to implement "extension methods" on existing traits?

2014-04-05 Thread Frank Huang
Hello everyone,

I have a question about making "extension methods" on something like
io::Writer. Basically, I have a data format that requires strings to be
serialized as an 8-byte length header and then the string bytes themselves.
Instead of having to type writer.write_u64(...); writer.write_str(...);
over and over again, I would like to implement some "extension methods" or
something like that on io::Writer, like the following pseudocode:

trait MySerialization {
  fn write_my_string(&mut self, s: &str) -> io::IoResult<()>;
}

impl MySerialization for io::Writer {
  fn write_my_string(&mut self, s: &str) -> io::IoResult<()> {
try!(self.write_u64(s.len());
self.write_str(s);
  }
}

However, this of course doesn't work, because I can't implement a trait for
a trait. Rustc says: "reference to trait `io::Writer` where a type is
expected; try `@io::Writer`, `~io::Writer`, or `&io::Writer`", however when
I try "&io::Writer" as suggested, rustc complains about lifetimes. Is this
sort of thing possible in Rust?

Thanks for your help!
- Frank
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Daniel Micay
On 05/04/14 09:23 AM, Simon Sapin wrote:
> On 05/04/2014 14:14, Corey Richardson wrote:
>> Sure, same thing as a C-style array, minus the fact that we don't have
>> Index implemented for unsafe ptrs.
> 
> Sure, but that difference is the important part. It’s idiomatic C to
> pretend that a pointer is like an array, but not in Rust.

I wouldn't say it's not idiomatic in Rust, it's simply a missing feature
for raw pointers along with pointer arithmetic operators. There were
previously operator overloads, but I had to remove them when switching
to inbounds pointer arithmetic since it no longer satisfies the safety
requirement of the traits. It can and should be added back to the
compiler, just without trait implementations.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Simon Sapin

On 05/04/2014 14:14, Corey Richardson wrote:

Sure, same thing as a C-style array, minus the fact that we don't have
Index implemented for unsafe ptrs.


Sure, but that difference is the important part. It’s idiomatic C to 
pretend that a pointer is like an array, but not in Rust.


--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Corey Richardson
Sure, same thing as a C-style array, minus the fact that we don't have
Index implemented for unsafe ptrs.

On Sat, Apr 5, 2014 at 9:07 AM, Simon Sapin  wrote:
> On 05/04/2014 12:00, Corey Richardson wrote:
>>
>> A C-style array is written `*T`, much like in C (note: I'm not saying
>> `T*` and `T[]` are the same type, I know they aren't)
>
>
> *T in Rust is not an array, it is a raw pointer. It may happen to point to
> the start of an array that you could unsafely access with .offset() and
> ptr::read(), but you can not index it like an array.
>
> --
> Simon Sapin



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Simon Sapin

On 05/04/2014 13:28, Vladimir Pouzanov wrote:

Also tried defining something along the lines of *[extern unsafe fn()],
but I guess size is also required in this case.


This will probably work once we have DST, but it will result in a 
fixed-size pointer to an array, rather than the actual array like 
[extern unsafe fn(), ..4] whose size is proportional to the number of 
elements.


DST: https://github.com/mozilla/rust/issues/6308

--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Simon Sapin

On 05/04/2014 12:00, Corey Richardson wrote:

A C-style array is written `*T`, much like in C (note: I'm not saying
`T*` and `T[]` are the same type, I know they aren't)


*T in Rust is not an array, it is a raw pointer. It may happen to point 
to the start of an array that you could unsafely access with .offset() 
and ptr::read(), but you can not index it like an array.


--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Vladimir Pouzanov
Ended up specifying array size as per Simon's suggestion:

#[link_section=".isr_vector_temp"]
#[no_mangle]
pub static ISRVectors: [extern unsafe fn(), ..4] = [
  _stack_base,
  main,
  isr_nmi,
  isr_hardfault,
];

Given that table size is an architecture-dependent time constant, it also
adds a tiny bit of verification that all ISRs are defined.

Also tried defining something along the lines of *[extern unsafe fn()], but
I guess size is also required in this case.

Thanks all!



On Sat, Apr 5, 2014 at 12:00 PM, Corey Richardson  wrote:

> A C-style array is written `*T`, much like in C (note: I'm not saying
> `T*` and `T[]` are the same type, I know they aren't)
>
> On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin  wrote:
> > On 05/04/2014 11:39, Vladimir Pouzanov wrote:
> >>
> >> The problem is that &[extern unsafe fn()] results in 8 bytes, pointer to
> >> the actual array and its size. Is there any way I can get a plain
> >> C-style array in rust?
> >
> >
> > If the size is known as compile-time you can use:
> >
> > static table: [extern unsafe fn(), ..2] = [foo, bar];
> >
> > --
> > Simon Sapin
> >
> > ___
> > 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
>



-- 
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Corey Richardson
A C-style array is written `*T`, much like in C (note: I'm not saying
`T*` and `T[]` are the same type, I know they aren't)

On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin  wrote:
> On 05/04/2014 11:39, Vladimir Pouzanov wrote:
>>
>> The problem is that &[extern unsafe fn()] results in 8 bytes, pointer to
>> the actual array and its size. Is there any way I can get a plain
>> C-style array in rust?
>
>
> If the size is known as compile-time you can use:
>
> static table: [extern unsafe fn(), ..2] = [foo, bar];
>
> --
> Simon Sapin
>
> ___
> 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] Building a static array of pointers

2014-04-05 Thread Simon Sapin

On 05/04/2014 11:39, Vladimir Pouzanov wrote:

The problem is that &[extern unsafe fn()] results in 8 bytes, pointer to
the actual array and its size. Is there any way I can get a plain
C-style array in rust?


If the size is known as compile-time you can use:

static table: [extern unsafe fn(), ..2] = [foo, bar];

--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Vladimir Pouzanov
The problem is that &[extern unsafe fn()] results in 8 bytes, pointer to
the actual array and its size. Is there any way I can get a plain C-style
array in rust?


On Fri, Apr 4, 2014 at 9:06 PM, Alex Crichton  wrote:

> As you've discovered in bug #13325, dealing with external constants in
> static expressions is sometimes a little tricky. I would avoid casting
> for now (as happens in the bug) in favor of stronger types. For
> example, this compiles and runs for me:
>
> extern {
> fn foo();
> fn bar();
> }
>
> static table: &'static [extern unsafe fn()] = &[foo, bar];
>
> pub mod test {
> #[no_mangle] pub extern fn foo() { println!("foo"); }
> #[no_mangle] pub extern fn bar() { println!("bar"); }
> }
>
> fn main() {
> for f in table.iter() {
> unsafe { (*f)(); }
> }
> }
>
> Note that in rust, a value of type `extern fn()` cannot be null, but
> `Option` can indeed be null. You'll probably want
> something along the lines of:
>
> #[link_section = ".isr_vector"]
> pub static ISR_VECTOR_TABLE: [Option, ..N] =
> [Some(...), None, Some(...), ...];
>
> On Fri, Apr 4, 2014 at 12:53 PM, Vladimir Pouzanov 
> wrote:
> > Is it possible to port the following C code to rust?
> >
> > __attribute__ ((section(".isr_vector")))
> > void (* const isr_vector_table[])(void) = {
> > &_stack_base,
> > main, // Reset
> > isr_nmi,  // NMI
> > isr_hardfault,// Hard Fault
> > 0,// CM3 Memory Management Fault
> > 0,// CM3 Bus Fault
> > 0,// CM3 Usage Fault
> > &_boot_checksum,  // NXP Checksum code
> > 0,// Reserved
> > 0,// Reserved
> > 0,// Reserved
> > isr_svcall,   // SVCall
> > 0,// Reserved for debug
> > 0,// Reserved
> > isr_pendsv,   // PendSV
> > isr_systick,  // SysTick
> > };
> >
> > here main and isr_* are rust external functions, and _stack_base is
> defined
> > as
> >
> >   extern void _stack_base()
> >
> > and gets loaded from linker script.
> >
> > Also, is it possible to make a weak symbol in rust or somehow emulate it?
> > Weak symbols are used in C code to provide the following functionality:
> > isr_* functions are stubs with default implementation (morse out id code
> > with led, loop forever), but if any of those requires actual code, than
> it
> > is overrides the weak "morse-blinking" function symbol.
> >
> > --
> > Sincerely,
> > Vladimir "Farcaller" Pouzanov
> > http://farcaller.net/
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>



-- 
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] TotalOrd and cmp::max

2014-04-05 Thread Rémi Fontan
ok, got it.

thanks

Rémi


On Sat, Apr 5, 2014 at 9:34 PM, Huon Wilson  wrote:

>  Floating point numbers don't have a total ordering (all of these are
> false: NaN < NaN, NaN == NaN, NaN > NaN).
>
> Use the floating-point specific method, `self.a.max(self.b)`.
>
>
> Huon
>
>
> On 05/04/14 19:30, Rémi Fontan wrote:
>
> Hi,
>
>  when compiling following code with rust 0.10 I get following error:
>
>  use std::cmp;
> struct vec2d { a:f32, b:f32 }
> impl vec2d {
>  pub fn max(&self) -> f32 {
> cmp::max(self.a, self.b)
> }
> }
>
>  test.rs:6:9: 6:17 error: failed to find an implementation of trait
> std::cmp::TotalOrd for f32
> test.rs:6 cmp::max(self.a, self.b)
>   ^~~~
> make: *** [test-test] Error 101
>
>
>  have I missed something?
>
>
>  cheers,
>
> Rémi
>
>  --
> Rémi Fontan : remifon...@yahoo.fr
> mobile: +64 21 855 351
> 93 Otaki Street, Miramar 6022
> Wellington, New Zealand
>
>
> ___
> Rust-dev mailing 
> listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>


-- 
Rémi Fontan : remifon...@yahoo.fr
mobile: +64 21 855 351
93 Otaki Street, Miramar 6022
Wellington, New Zealand
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] TotalOrd and cmp::max

2014-04-05 Thread Huon Wilson
Floating point numbers don't have a total ordering (all of these are 
false: NaN < NaN, NaN == NaN, NaN > NaN).


Use the floating-point specific method, `self.a.max(self.b)`.


Huon

On 05/04/14 19:30, Rémi Fontan wrote:

Hi,

when compiling following code with rust 0.10 I get following error:

use std::cmp;
struct vec2d { a:f32, b:f32 }
impl vec2d {
pub fn max(&self) -> f32 {
cmp::max(self.a, self.b)
}
}

test.rs:6:9: 6:17 error: failed to find an implementation of trait 
std::cmp::TotalOrd for f32

test.rs:6  cmp::max(self.a, self.b)
^~~~
make: *** [test-test] Error 101


have I missed something?


cheers,

Rémi


--
Rémi Fontan : remifon...@yahoo.fr 
mobile: +64 21 855 351
93 Otaki Street, Miramar 6022
Wellington, New Zealand


___
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] TotalOrd and cmp::max

2014-04-05 Thread Rémi Fontan
Hi,

when compiling following code with rust 0.10 I get following error:

use std::cmp;
struct vec2d { a:f32, b:f32 }
impl vec2d {
pub fn max(&self) -> f32 {
cmp::max(self.a, self.b)
}
}

test.rs:6:9: 6:17 error: failed to find an implementation of trait
std::cmp::TotalOrd for f32
test.rs:6 cmp::max(self.a, self.b)
  ^~~~
make: *** [test-test] Error 101


have I missed something?


cheers,

Rémi

-- 
Rémi Fontan : remifon...@yahoo.fr
mobile: +64 21 855 351
93 Otaki Street, Miramar 6022
Wellington, New Zealand
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev