Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
Yes, in the end I decided to implement .data section copy over from flash to ram to get vtables :-) On Tue, Apr 8, 2014 at 7:34 PM, Corey Richardson wrote: > `&'static SPI` is going to be a trait object (with dynamic dispatch). > The error it's giving is that `&SPI` (the trait object) doesn't >

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Corey Richardson
`&'static SPI` is going to be a trait object (with dynamic dispatch). The error it's giving is that `&SPI` (the trait object) doesn't implement `SPI` (the trait). You would have to explicitly implement `SPI` for `&SPI`. I'm not really sure how to solve this without using trait objects; you seem to

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
That actually worked much better than I expected inlining everything and getting rid of vtables (I don't have support for .data section at the moment :-) ). I can't say the syntax is very clear to me, but I can get used to it. Still, one more question remains. I have a "debug output" concept, whic

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Corey Richardson
You don't use bounds in the struct, you put them in the impl. So you would instead say struct LCD { spi: S, ... } and then: impl LCD { ... } On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov wrote: > I might have found an unsupported case. > > Consider the following: > > trait SPI {

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Vladimir Pouzanov
I might have found an unsupported case. Consider the following: trait SPI { ... } struct McuSPI; impl SPI for McuSPI { ... } struct LCD { spi: &SPI, ... } This code results in a dynamic dispatch to SPI, as "trait bounds are not allowed in structure definitions". Is it in any way possible t

Re: [rust-dev] impl num::Zero and std::ops::Add error

2014-04-08 Thread Kevin Ballard
On Apr 7, 2014, at 1:02 AM, Tommi Tissari wrote: > On 07 Apr 2014, at 08:44, Nicholas Radford wrote: > >> I think the original question was, why does the zero trait require the add >> trait. >> > If that was the original question, then my answer would be that > std::num::Zero requires the Ad

Re: [rust-dev] matching on a few bits in int

2014-04-08 Thread Vladimir Pouzanov
Awesome use of unreachable! On Tue, Apr 8, 2014 at 4:53 PM, Peter Marheine wrote: > I had a go at building a macro to do this sort of thing, and it turned > out to be easier than I expected. > > https://gist.github.com/tari/10144385 > > Use like this: > let x = match_bitfield!(do_something(

Re: [rust-dev] matching on a few bits in int

2014-04-08 Thread Peter Marheine
I had a go at building a macro to do this sort of thing, and it turned out to be easier than I expected. https://gist.github.com/tari/10144385 Use like this: let x = match_bitfield!(do_something(), bits 4 to 8 { 0 => DivideBy1, 1 => DivideBy2, 2 => DivideBy4, _

Re: [rust-dev] Tagged integral & floating-point types

2014-04-08 Thread Tommi Tissari
I just realized that this 'Invalid' trait is also a prime example of why traits must be able to specify their items as private. Obviously that 'invalid' static method / constant should not be part of the public interface. Heck, the sole reason for the existence of the type could be that it prote