Re: [rust-dev] Slow rustc startup on Windows

[Matthieu Monrocq]

Intriguing...

I googled a bit to check what this was about and found:

- pseudo-reloc.c, the part of mingw handling pseudo-relocations =>
http://www.oschina.net/code/explore/mingw-runtime-3.18-1/pseudo-reloc.c
- the patch for pseudo-reloc v2 support =>
http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/1953

At a glance I would say the problem is more on mingw side, however there
might be something that can be done on rust side to mitigate or work-around
the issue.

-- Matthieu



On Thu, Aug 29, 2013 at 9:35 PM, Vadim  wrote:

> ... is apparantly caused by pseudo-relocations 
> (#8859).
> Does anybody here know anything about that?
>
> ___
> 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] RFC: Stealing: lexically-scoped temporary violation of linearity

[Patrick Walton]

Hi everyone,

I've been tossing around an idea for a library utility designed to make 
unique pointers easier to use, especially for balanced binary search 
trees and the like. The core of the idea is that I conjecture it's safe 
to temporarily violate linearity *while the locations in question are 
borrowed*, as long as linearity is *dynamically* preserved once the 
borrow ends.


First off, let me motivate this with an example, showing that this 
generalizes "swap":


struct Test {
a: ~str,
b: ~str,
}

fn main() {
let mut test = Test {
a: ~"Burma",
b: ~"Shave",
};
{
let (a, a_loc) = steal(&mut test.a);
let (b, b_loc) = steal(&mut test.b);
println(a);   // prints "Burma"
println(b);   // prints "Shave"
a_loc.put_back(b);
b_loc.put_back(a);
}
println(test.a);  // prints "Shave"
println(test.b);  // prints "Burma"
}

Concretely, what "steal" does is that it takes a mutable borrow and 
returns two things: (1) a shallow copy of the referent, temporarily 
violating linearity; (2) a "stolen location" which must be filled with a 
value of the same type as the referent via the `put_back` method before 
the scope ends. If the scope ends (i.e. the borrow expires) without 
calling `put_back` on a stolen location, then task failure occurs. For 
example, this program fails (with the above definition of `Test`):


fn main() {
let mut test = Test {
a: ~"Burma",
b: ~"Shave",
};
{
let (a, a_loc) = steal(&mut test.a);
let (b, b_loc) = steal(&mut test.b);
a_loc.put_back(b);
} // dynamic failure: "b_loc" was not filled
}

The idea behind this is to allow complex "pointer rewirings" such as 
those that self-balancing binary search trees want to be expressed in a 
natural way without a tricky series of swaps.


The thing that initially seems questionable for soundness is that, while 
borrowed and while linearity is violated, the original value is still 
readable (although not immutably or mutably borrowable). I believe this 
is OK, even in the fact of LLVM alias optimizations, because while 
something is borrowed linearity is no longer guaranteed anyhow.


The implementation is quite small and simple and fits here:

struct Stolen<'self,T> {
priv location: &'self mut T,
}

#[unsafe_destructor]
impl<'self,T> Drop for Stolen<'self,T> {
fn drop(&self) {
fail!("stolen")
}
}

impl<'self,T> Stolen<'self,T> {
fn put_back(self, value: T) {
unsafe {
intrinsics::move_val_init(self.location, value);
cast::forget(self)
}
}
}

fn steal<'a,T>(value: &'a mut T) -> (T, Stolen<'a,T>) {
unsafe {
(cast::transmute_copy(value), Stolen {
location: value,
})
}
}

Thoughts? Does this seem useful? Are there soundness issues I didn't notice?

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

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

[Oren Ben-Kiki]

I just tested this in my code, it solved a sticky problem I had with
updating owned data nested deep inside a tree-ish container. My original
solution wasn't very nice (it just compromised on efficiency and copied too
much data around). The new code is shorter and more efficient (no copies!
yey!).

So, +1 for usefulness, and thanks!

I wish I could also attest to the correctness, but that is harder to
prove...



On Sat, Aug 31, 2013 at 1:39 AM, Patrick Walton  wrote:

> Hi everyone,
>
> I've been tossing around an idea for a library utility designed to make
> unique pointers easier to use, especially for balanced binary search trees
> and the like. The core of the idea is that I conjecture it's safe to
> temporarily violate linearity *while the locations in question are
> borrowed*, as long as linearity is *dynamically* preserved once the borrow
> ends.
>
> First off, let me motivate this with an example, showing that this
> generalizes "swap":
>
> struct Test {
> a: ~str,
> b: ~str,
> }
>
> fn main() {
> let mut test = Test {
> a: ~"Burma",
> b: ~"Shave",
> };
> {
> let (a, a_loc) = steal(&mut test.a);
> let (b, b_loc) = steal(&mut test.b);
> println(a);   // prints "Burma"
> println(b);   // prints "Shave"
> a_loc.put_back(b);
> b_loc.put_back(a);
> }
> println(test.a);  // prints "Shave"
> println(test.b);  // prints "Burma"
> }
>
> Concretely, what "steal" does is that it takes a mutable borrow and
> returns two things: (1) a shallow copy of the referent, temporarily
> violating linearity; (2) a "stolen location" which must be filled with a
> value of the same type as the referent via the `put_back` method before the
> scope ends. If the scope ends (i.e. the borrow expires) without calling
> `put_back` on a stolen location, then task failure occurs. For example,
> this program fails (with the above definition of `Test`):
>
> fn main() {
> let mut test = Test {
> a: ~"Burma",
> b: ~"Shave",
> };
> {
> let (a, a_loc) = steal(&mut test.a);
> let (b, b_loc) = steal(&mut test.b);
> a_loc.put_back(b);
> } // dynamic failure: "b_loc" was not filled
> }
>
> The idea behind this is to allow complex "pointer rewirings" such as those
> that self-balancing binary search trees want to be expressed in a natural
> way without a tricky series of swaps.
>
> The thing that initially seems questionable for soundness is that, while
> borrowed and while linearity is violated, the original value is still
> readable (although not immutably or mutably borrowable). I believe this is
> OK, even in the fact of LLVM alias optimizations, because while something
> is borrowed linearity is no longer guaranteed anyhow.
>
> The implementation is quite small and simple and fits here:
>
> struct Stolen<'self,T> {
> priv location: &'self mut T,
> }
>
> #[unsafe_destructor]
> impl<'self,T> Drop for Stolen<'self,T> {
> fn drop(&self) {
> fail!("stolen")
> }
> }
>
> impl<'self,T> Stolen<'self,T> {
> fn put_back(self, value: T) {
> unsafe {
> intrinsics::move_val_init(**self.location, value);
> cast::forget(self)
> }
> }
> }
>
> fn steal<'a,T>(value: &'a mut T) -> (T, Stolen<'a,T>) {
> unsafe {
> (cast::transmute_copy(value), Stolen {
> location: value,
> })
> }
> }
>
> Thoughts? Does this seem useful? Are there soundness issues I didn't
> notice?
>
> Patrick
> __**_
> 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] changing roles

[Graydon Hoare]

Hi,

As I'm sure many of you who know me are aware, my role as technical lead 
on Rust has been quite draining over the years. Both to myself and to 
those I've worked with, it just isn't a great fit for me.


In recognition of this, I am stepping aside to work elsewhere in the 
organization, and Brian will be assuming the role of technical lead of Rust.


Brian is one of the most skilled, judicious, professional and productive 
developers I've ever worked with. Along with the exceptional skill and 
dedication of the rest of the Rust team, I have complete confidence in 
the remaining path to a successful 1.x series of what has shaped up to 
be an excellent language.


It has been a rare pleasure and privilege to work with the Rust team, 
both those inside Mozilla and in the broader community.


Thanks,

-Graydon

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

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

[Patrick Walton]

On 8/30/13 3:39 PM, Patrick Walton wrote:

Thoughts? Does this seem useful? Are there soundness issues I didn't
notice?


Brian pointed out a massive soundness hole in this, unfortunately. The 
problem is that you can read from the original locations; the right to 
read is not "shut off" during the borrow. I think the fix would have to 
be to replace this with some sort of "generalized swap" operation.


Patrick

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

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

[Oren Ben-Kiki]

Sigh, I guess it was too good to be true :-(

I'd settle for the ability to say: update_in_place(foo.owned_pointer,
&fn(~T) -> ~T) - surely this would be safe?

Speaking of which, a secondary problem I encountered when doing this sort
of thing, is the "Once function" issue listed in
https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQ.

Wouldn't it be possible to say, for example, that ~fn can only be invoked
once to resolve this issue?


On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton  wrote:

> On 8/30/13 3:39 PM, Patrick Walton wrote:
>
>> Thoughts? Does this seem useful? Are there soundness issues I didn't
>> notice?
>>
>
> Brian pointed out a massive soundness hole in this, unfortunately. The
> problem is that you can read from the original locations; the right to read
> is not "shut off" during the borrow. I think the fix would have to be to
> replace this with some sort of "generalized swap" operation.
>
>
> Patrick
>
> __**_
> 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] changing roles

[Corey Richardson]

Will you still be working on the Rust project, or elsewhere in Mozilla?

On Fri, Aug 30, 2013 at 8:05 PM, Graydon Hoare  wrote:
> Hi,
>
> As I'm sure many of you who know me are aware, my role as technical lead on
> Rust has been quite draining over the years. Both to myself and to those
> I've worked with, it just isn't a great fit for me.
>
> In recognition of this, I am stepping aside to work elsewhere in the
> organization, and Brian will be assuming the role of technical lead of Rust.
>
> Brian is one of the most skilled, judicious, professional and productive
> developers I've ever worked with. Along with the exceptional skill and
> dedication of the rest of the Rust team, I have complete confidence in the
> remaining path to a successful 1.x series of what has shaped up to be an
> excellent language.
>
> It has been a rare pleasure and privilege to work with the Rust team, both
> those inside Mozilla and in the broader community.
>
> Thanks,
>
> -Graydon
>
> ___
> 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] changing roles

[Brian Anderson]

On 08/30/2013 05:05 PM, Graydon Hoare wrote:

Hi,

As I'm sure many of you who know me are aware, my role as technical 
lead on Rust has been quite draining over the years. Both to myself 
and to those I've worked with, it just isn't a great fit for me.


In recognition of this, I am stepping aside to work elsewhere in the 
organization, and Brian will be assuming the role of technical lead of 
Rust.


This news is bittersweet to say the least. The language that you 
invented and that I adore has come so very far under your leadership, 
and I hope that we can continue to build on the example you have set.


It's been an enriching experience working with you, Graydon, and I wish 
you the best on your next project.


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

Re: [rust-dev] changing roles

[Thad Guidry]

Graydon,

So what does not drain you ?  What kicks you into high gear and keeps you
salivating for more ?

Many of us do not know you personally, and knowing a bit more about what
really interests you, would open a few of our eyes on the list.

(thanks for your efforts)


On Fri, Aug 30, 2013 at 8:57 PM, Brian Anderson wrote:

> On 08/30/2013 05:05 PM, Graydon Hoare wrote:
>
>> Hi,
>>
>> As I'm sure many of you who know me are aware, my role as technical lead
>> on Rust has been quite draining over the years. Both to myself and to those
>> I've worked with, it just isn't a great fit for me.
>>
>> In recognition of this, I am stepping aside to work elsewhere in the
>> organization, and Brian will be assuming the role of technical lead of Rust.
>>
>
> This news is bittersweet to say the least. The language that you invented
> and that I adore has come so very far under your leadership, and I hope
> that we can continue to build on the example you have set.
>
> It's been an enriching experience working with you, Graydon, and I wish
> you the best on your next project.
>
> -Brian
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>



-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev