I probably picked the exact wrong project for diving into rust, but
I'd like to teach rust how to build powerpc64-bgq-linux binaries.
I've got a powerpc64-bgq-linux toolchain. I added this stanza to
mk/platforms.mk, but cribbed from other platforms. Did I leave out
any important settings?
%
Hi Rob!
It's probably best to way until porting had been simplified.
Here is a ongoing discussion of this matter:
https://github.com/rust-lang/rfcs/pull/131
Cheers,
--
Ilya
On 20 Jul 2014 15:35, Rob Latham rlat...@gmail.com wrote:
I probably picked the exact wrong project for diving into
Hi Rob,
make: *** No rule to make target
`powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by
`powerpc64-bgq-linux/rt/libsmorestack.a'. Stop.
I don't know how to go about debugging this. Any ideas?
There is no way to debug this - you have to implement a couple of
functions
On Sun, Jul 13, 2014 at 10:37 PM, Nick Cameron li...@ncameron.org wrote:
Yes, this is the right place for meta-discussion.
I'll make sure to be stricter about commenting on the PRs in the future.
The aim of this email is only to summarise the discussion so far, it
shouldn't add new opinions
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question is: in example 2, why doesn't BufferedReader need file to
be mutable? After all,
That's right. `BufferedReader` takes the `Reader` it wraps by-value,
but the `read` method takes `mut self`. Moving something doesn't
require it to be stored in a mutable variable, but taking a `mut` to
it does.
On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson di...@ubuntu.com wrote:
Hi,
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question is: in example 2, why doesn't BufferedReader
On 2014-07-21 03:33, Patrick Walton wrote:
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question
Because Foo is a POD type (implements the Copy trait). Essentially, types that
can be copied by copying bits only (not allocating) are POD types, and all
others move.
This may be changed with the Opt-In Built-in Traits proposal so that POD types
must be specially declared to implement Copy
Some types are implicitly copyable. They implement the built-in trait Copy.
A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a collection of Copy types (e.g. struct Foo { a:
On 2014-07-21 04:43, Steven Fackler wrote:
Some types are implicitly copyable. They implement the built-in trait
Copy. A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
This wasn't very intuitive for me, so just throwing this
On 7/20/14 9:04 PM, Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
Also note that
13 matches
Mail list logo
