Re: [rust-dev] Mutable files
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 these rules, far from being "complex", end up making the language much simpler than C++, as copy (or D-like postblit) constructors are not required. All Rust types, if they are copyable at all, can be copied by simply moving bits around. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
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 out (feel free
to ignore if it has already been discussed :-) )
From a language design perspective, maybe it would be more intuitive to
have different syntaxes for copy and move, like:
There used to be a unary move operator. This was a huge pain.
match move x {
Some(move y) => foo(move z);
}
And so on. I don't want to go back to that world.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
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 collection of Copy types (e.g. struct Foo { a: int, b: &'static str }).
In addition, if a type implements Drop, it is no longer Copy.
Steven Fackler
Cool, thanks for the answer. These restrictions seem somewhat complex.
This wasn't very intuitive for me, so just throwing this out (feel free
to ignore if it has already been discussed :-) )
From a language design perspective, maybe it would be more intuitive to
have different syntaxes for copy and move, like:
let mut g = f; /* Copies from f to g, error if f is a non-Copy type */
let mut g <- f; /* Moves from f to g, error if trying to use f afterwards */
Or in the File/BufferedReader example, this would be something like:
let f = File::open(filename);
let mut reader = BufferedReader::new(<- f); /* Bye bye f! */
I'm also afraid that if a library struct decides to change between a
copy and non-copy type, this would cause subtle errors in users of that
library that expected the other type. But if the compiler is guaranteed
to catch all such errors even with today's handling, maybe that is not
too much to worry about.
On Sun, Jul 20, 2014 at 7:39 PM, David Henningsson mailto:di...@ubuntu.com>> wrote:
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 is: in example 2, why doesn't BufferedReader
need "file" to
be mutable? After all, BufferedReader ends up calling
file.read(), which
needs a mutable reference to the file.
It looks like I'm able to "bypass" the mutability
requirement, just
because I wrap the file inside a BufferedReader?
Because `BufferedReader::new` moves `file` and takes ownership
of it.
(You can see this if you try to use `file` again: the compiler will
prevent you.) Mutability is inherited through ownership in Rust:
that
is, the current owner determines the mutability of a piece of
data. So,
the mutability of `reader` determines the mutability of the `File`
object at the time you try to read, and the mutability
restriction is
satisfied.
Thanks for the quick answer!
I did two more examples to try to understand when things are moved:
3)
struct Dummy {
foo: int,
bar: int
}
let f = Dummy {foo: 10, bar: 5};
let mut g = f; // Here the assignment copies..?
println!("{}", f.foo + g.foo); // Ok
4)
let f = File::open(filename);
let mut g = f; // Here the assignment moves..?
f.tell(); // Fails - use of moved value
How come that the assignment moves in example 4), and copies in
example 3)?
// David
_
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] Mutable files
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: int, b: &'static str }).
In addition, if a type implements Drop, it is no longer Copy.
Steven Fackler
On Sun, Jul 20, 2014 at 7:39 PM, David Henningsson wrote:
>
>
> 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 is: in example 2, why doesn't BufferedReader need "file" to
>>> be mutable? After all, BufferedReader ends up calling file.read(), which
>>> needs a mutable reference to the file.
>>>
>>> It looks like I'm able to "bypass" the mutability requirement, just
>>> because I wrap the file inside a BufferedReader?
>>>
>>
>> Because `BufferedReader::new` moves `file` and takes ownership of it.
>> (You can see this if you try to use `file` again: the compiler will
>> prevent you.) Mutability is inherited through ownership in Rust: that
>> is, the current owner determines the mutability of a piece of data. So,
>> the mutability of `reader` determines the mutability of the `File`
>> object at the time you try to read, and the mutability restriction is
>> satisfied.
>>
>
> Thanks for the quick answer!
>
> I did two more examples to try to understand when things are moved:
>
> 3)
> struct Dummy {
> foo: int,
> bar: int
> }
>
> let f = Dummy {foo: 10, bar: 5};
> let mut g = f; // Here the assignment copies..?
> println!("{}", f.foo + g.foo); // Ok
>
> 4)
>
> let f = File::open(filename);
> let mut g = f; // Here the assignment moves..?
> f.tell(); // Fails - use of moved value
>
> How come that the assignment moves in example 4), and copies in example 3)?
>
> // David
>
> ___
> 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] Mutable files
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 before they will copy.
Patrick
On July 20, 2014 7:39:35 PM PDT, David Henningsson wrote:
>
>
>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 is: in example 2, why doesn't BufferedReader need "file"
>to
>>> be mutable? After all, BufferedReader ends up calling file.read(),
>which
>>> needs a mutable reference to the file.
>>>
>>> It looks like I'm able to "bypass" the mutability requirement, just
>>> because I wrap the file inside a BufferedReader?
>>
>> Because `BufferedReader::new` moves `file` and takes ownership of it.
>> (You can see this if you try to use `file` again: the compiler will
>> prevent you.) Mutability is inherited through ownership in Rust: that
>> is, the current owner determines the mutability of a piece of data.
>So,
>> the mutability of `reader` determines the mutability of the `File`
>> object at the time you try to read, and the mutability restriction is
>> satisfied.
>
>Thanks for the quick answer!
>
>I did two more examples to try to understand when things are moved:
>
>3)
>struct Dummy {
> foo: int,
> bar: int
>}
>
>let f = Dummy {foo: 10, bar: 5};
>let mut g = f; // Here the assignment copies..?
>println!("{}", f.foo + g.foo); // Ok
>
>4)
>
>let f = File::open(filename);
>let mut g = f; // Here the assignment moves..?
>f.tell(); // Fails - use of moved value
>
>How come that the assignment moves in example 4), and copies in example
>3)?
>
>// David
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
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 is: in example 2, why doesn't BufferedReader need "file" to
be mutable? After all, BufferedReader ends up calling file.read(), which
needs a mutable reference to the file.
It looks like I'm able to "bypass" the mutability requirement, just
because I wrap the file inside a BufferedReader?
Because `BufferedReader::new` moves `file` and takes ownership of it.
(You can see this if you try to use `file` again: the compiler will
prevent you.) Mutability is inherited through ownership in Rust: that
is, the current owner determines the mutability of a piece of data. So,
the mutability of `reader` determines the mutability of the `File`
object at the time you try to read, and the mutability restriction is
satisfied.
Thanks for the quick answer!
I did two more examples to try to understand when things are moved:
3)
struct Dummy {
foo: int,
bar: int
}
let f = Dummy {foo: 10, bar: 5};
let mut g = f; // Here the assignment copies..?
println!("{}", f.foo + g.foo); // Ok
4)
let f = File::open(filename);
let mut g = f; // Here the assignment moves..?
f.tell(); // Fails - use of moved value
How come that the assignment moves in example 4), and copies in example 3)?
// David
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
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 need "file" to be mutable? After all, BufferedReader ends up calling file.read(), which needs a mutable reference to the file. It looks like I'm able to "bypass" the mutability requirement, just because I wrap the file inside a BufferedReader? Because `BufferedReader::new` moves `file` and takes ownership of it. (You can see this if you try to use `file` again: the compiler will prevent you.) Mutability is inherited through ownership in Rust: that is, the current owner determines the mutability of a piece of data. So, the mutability of `reader` determines the mutability of the `File` object at the time you try to read, and the mutability restriction is satisfied. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutable files
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 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 need "file" to be > mutable? After all, BufferedReader ends up calling file.read(), which needs > a mutable reference to the file. > > It looks like I'm able to "bypass" the mutability requirement, just because > I wrap the file inside a BufferedReader? > > // David > ___ > 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] Mutable files
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, BufferedReader ends up calling file.read(), which needs a mutable reference to the file. It looks like I'm able to "bypass" the mutability requirement, just because I wrap the file inside a BufferedReader? // David ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Next week's older RFCs
On Sun, Jul 13, 2014 at 10:37 PM, Nick Cameron 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 or comments beyond applying our 'rules' for > accepting PRs in the most uncontroversial manner. Obviously that is kind of > a fuzzy statement, but I think you are right that here I didn't quite stick > to that. Sorry. > Yes, this sounds sensible to me. Thanks for explaining. > > In general, I agree with your last point, but it takes considerable time > and energy to have an active role and that is in limited supply, so it is > always a trade off on whether any particular person gets involved with a > particular RFC. Having said that, the vast majority of the discussion for > an RFC should always be happening on the RFC. > > I can really, really sympathize with the limited time and energy problem, because I have it as well. Following that line of thought, we should consider the fact that most contributors have even less time and energy, and aren't compensated for it. As such, any steps, even incremental, in the direction of a more engaged and collaborative process, as opposed to just an ultimate accept/postpone/reject decision, would be very much appreciated. Cheers > > Cheers, Nick > > > On Mon, Jul 14, 2014 at 2:29 AM, Gábor Lehel wrote: > >> On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: >> >>> https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce >>> universal quantification - glaebhoerl >>> Use `for` rather than `<...>` syntax for type-parametric items. >>> Not much feedback, some discussion. >>> Recommend close - we're not up for changing the syntax of Rust in >>> such a fundamental way at this stage and want to keep with the >>> curly-brace-language heritage. >>> >> >> (Thank you for sending these e-mails. I've responded to the substantive >> aspects of this at the PR, as requested, but for the "meta" aspects >> pertaining to process, I hope that replying to the e-mail is acceptable.) >> >> If I may file a small protest: It feels wrong to me that the first time I >> hear of this concern is in a recommendation to the meeting group to close >> the PR because of it. (Which is not to mention that it's based on a basic >> misunderstanding of the proposal.) Would it be possible to always raise a >> particular concern in the comments on a PR before using it as justification >> to close, or recommend closing, that PR? >> >> (In general, I think it would be beneficial if the people who get to >> decide the fate of PRs took a more active role in discussing and shaping >> them, instead of staying aloof before handing down an opinion at some >> point.) >> >> > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] adding a new cross-compile target
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 which are required by Rust runtime and are architecture-dependent. They live in src/rt/arch/$ARCH_NAME$ Functions (files) are: morestack (morestack.S) - it is a vestige from segmented stack time. Back then it allocated a new stack segment once were wasn't enough space in the current one. Nowadays it just calls rust_stack_exhausted function. record_sp_limit (record_sp.S) - should store stack limit for current task (usually it uses platform specific thread local storage). get_sp_limit (record_sp.S) - should return stack limit for current task (reads from the same platform-specific thread local storage) rust_swap_registers (_context.S) - I'm not sure about this one, but I assume it allows correct register restoration in case of green task switches. rust_bootstrap_green_task (_context.S) - again, not sure, but I assume it initializes green task. Note, that all stack-related functions (morestack, record_sp_limit, get_sp_limit) should be actually compatible with LLVM segmented stack prologue (in your case consult $LLVM/lib/target/PowerPC/PPCFrameLowering.cpp, emitPrologue and emitEpilogue methods, may be a couple of others). For a reference implementations (and much more additional comments) see src/rt/arch/i386/*.S -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] adding a new cross-compile target
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" wrote: > 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? > > % git diff > diff --git a/mk/platform.mk b/mk/platform.mk > index d1ec7c65..f1272eaa 100644 > --- a/mk/platform.mk > +++ b/mk/platform.mk > @@ -580,6 +580,19 @@ CFG_LDPATH_x86_64-unknown-freebsd := > CFG_RUN_x86_64-unknown-freebsd=$(2) > CFG_RUN_TARG_x86_64-unknown-freebsd=$(call > CFG_RUN_x86_64-unknown-freebsd,,$(2)) > > +# powerpc64-bgq-linux configuration > +CC_powerpc64-bgq-linux=powerpc64-bgq-linux-gcc > +CXX_powerpc64-bgq-linux=powerpc64-bgq-linux-g++ > +CPP_powerpc64-bgq-linux=powerpc64-bgq-linux-cpp > +AR_powerpc64-bgq-linux=powerpc64-bgq-linux-ar > +CFG_LIB_NAME_powerpc64-bgq-linux=libs$(1).so > +CFG_STATIC_LIB_NAME_powerpc64-bgq-linux=libs$(1).a > +CFG_LIB_GLOB_powerpc64-bgq-linux=lib$(1)-*.so > +CFG_CFLAGS_powerpc64-bgq-linux := $(CFLAGS) > +CFG_GCCISH_CFLAGS_powerpc64-bgq-linux := -Wall -Werror -g -fPIC $(CFLAGS) > +CFG_UNIXY_powerpc64-bgq-linux := 1 > +CFG_RUN_powerpc64-bgq-linux = > +CFG_RUN_TARG_powerpc64-bgq-linux = > > I can configure ok: > > ../configure --target=powerpc64-bgq-linux > --prefix=/sandbox/robl/rust-master > > But build progresses pretty far, hanging up here: > > [...] > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libfourcc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhexfloat > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex_macros > 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? > > thanks > ==rob > ___ > 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] adding a new cross-compile target
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? % git diff diff --git a/mk/platform.mk b/mk/platform.mk index d1ec7c65..f1272eaa 100644 --- a/mk/platform.mk +++ b/mk/platform.mk @@ -580,6 +580,19 @@ CFG_LDPATH_x86_64-unknown-freebsd := CFG_RUN_x86_64-unknown-freebsd=$(2) CFG_RUN_TARG_x86_64-unknown-freebsd=$(call CFG_RUN_x86_64-unknown-freebsd,,$(2)) +# powerpc64-bgq-linux configuration +CC_powerpc64-bgq-linux=powerpc64-bgq-linux-gcc +CXX_powerpc64-bgq-linux=powerpc64-bgq-linux-g++ +CPP_powerpc64-bgq-linux=powerpc64-bgq-linux-cpp +AR_powerpc64-bgq-linux=powerpc64-bgq-linux-ar +CFG_LIB_NAME_powerpc64-bgq-linux=libs$(1).so +CFG_STATIC_LIB_NAME_powerpc64-bgq-linux=libs$(1).a +CFG_LIB_GLOB_powerpc64-bgq-linux=lib$(1)-*.so +CFG_CFLAGS_powerpc64-bgq-linux := $(CFLAGS) +CFG_GCCISH_CFLAGS_powerpc64-bgq-linux := -Wall -Werror -g -fPIC $(CFLAGS) +CFG_UNIXY_powerpc64-bgq-linux := 1 +CFG_RUN_powerpc64-bgq-linux = +CFG_RUN_TARG_powerpc64-bgq-linux = I can configure ok: ../configure --target=powerpc64-bgq-linux --prefix=/sandbox/robl/rust-master But build progresses pretty far, hanging up here: [...] rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libfourcc rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhexfloat rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex_macros 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? thanks ==rob ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
