Re: [rust-dev] libuv updated

[Tom Lee]

And those unfamiliar with git submodules (and/or a bit slow on the uptake
like myself!) will also want to:

cd src/libuv && git checkout master && git pull --rebase


*after* you've got graydon/libuv is in your .git/config -- otherwise it
continues to reference the last commit to joyent/libuv prior to Graydon's
fork. :)

(while I'm on the topic, is there a nicer way to ask git to do this for
you?)

Cheers,
Tom

On Thu, Feb 2, 2012 at 6:03 PM, Graydon Hoare  wrote:

> Hi,
>
> I've updated libuv. Normally this might not require mention but I had to
> make a couple hacks to get it working on mingw (they typically build on
> msvc) and this meant forking it to my own. Which meant changing the
> submodule URL. Turns out git caches the submodule URL. So you *might* need
> to change the submodule URLs in your .git/config to point to graydon/libuv
> rather than joyent/libuv.
>
> Let me know if you see any other breakage. I don't want to fall too far
> behind libuv. I've also un-cfg'ed all the tests on windows so we get proper
> library coverage there too. It's supposed to work on windows. That's part
> of the sales pitch :)
>
> -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] libuv updated

[Tom Lee]

Can't remember how I did the build, sorry. Is it supposed to happen as part
of a ./configure or something? It's possible I ran a make without running
configure.

In any case, the build left the libuv head pointing at the last joyent
commit. :(

Cheers, Tom
 On Feb 3, 2012 7:34 AM, "Graydon Hoare"  wrote:

> On 02/02/2012 11:01 PM, Tom Lee wrote:
>
>> And those unfamiliar with git submodules (and/or a bit slow on the
>> uptake like myself!) will also want to:
>>
>>cd src/libuv && git checkout master && git pull --rebase
>>
>>
>> /after/ you've got graydon/libuv is in your .git/config -- otherwise it
>> continues to reference the last commit to joyent/libuv prior to
>> Graydon's fork. :)
>>
>> (while I'm on the topic, is there a nicer way to ask git to do this for
>> you?)
>>
>
> I'm confused. As far as I know the submodule code in our configury
> *should* be doing this for you. Did it not?
>
> -Graydon
>
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Managed & owned boxes in Rust

[Tom Lee]

Hey folks,

Don't mean to spam, but I wrote a blog post last night about memory
management in Rust as I understand it, both based on my own experience with
the language so far and a few conversations on the #rust channel:

http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust-programming-language/

If anybody's up for giving it a read over, I'm really keen to know if I'm
"getting it" or if I'm still confused :) I think I'm essentially rewording
what's in the tutorial, but for some reason I struggled to digest the
details for a while.

I'm still not sure I understand why the exchange stack is exposed
syntactically if you can't directly use it to transfer ownership between
tasks (i.e. you still have to resort to pipes etc. which use the exchange
stack under the hood).

Appreciate any clarification or thoughts!

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

Re: [rust-dev] Managed & owned boxes in Rust

[Tom Lee]

Ah awesome. Thanks! I've updated the blog post with your explanation. :)

Cheers,
Tom

On Wed, Dec 5, 2012 at 6:07 PM, Niko Matsakis  wrote:

> Great article.  Regarding why ~[T] and ~T behave somewhat differently, the
> reason is that the size of [T] is not known to the compiler!  It's kind of
> like how in C, if you have T[3], that's a perfectly fine type, but T[] is
> sort of a degenerate type that gets converted to T* willy-nilly.  The
> reason is that the compiler can't really manipulate an "unknown number of
> T's in a row", which is what [T] (Rust) and T[] (C) represent.  As an
> example, it can't put such a value on the stack, since it doesn't know how
> much stack space to allocate (well, it can't put that on the stack without
> using alloca() or something similar).
>
>
> Niko
>
> Tom Lee wrote:
>
>> Hey folks,
>>
>> Don't mean to spam, but I wrote a blog post last night about memory
>> management in Rust as I understand it, both based on my own experience with
>> the language so far and a few conversations on the #rust channel:
>>
>> http://tomlee.co/2012/12/**managed-and-owned-boxes-in-**
>> the-rust-programming-language/<http://tomlee.co/2012/12/managed-and-owned-boxes-in-the-rust-programming-language/>
>>
>> If anybody's up for giving it a read over, I'm really keen to know if I'm
>> "getting it" or if I'm still confused :) I think I'm essentially rewording
>> what's in the tutorial, but for some reason I struggled to digest the
>> details for a while.
>>
>> I'm still not sure I understand why the exchange stack is exposed
>> syntactically if you can't directly use it to transfer ownership between
>> tasks (i.e. you still have to resort to pipes etc. which use the exchange
>> stack under the hood).
>>
>> Appreciate any clarification or thoughts!
>>
>> Cheers,
>> Tom
>> __**_
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Vectors, mutability & vec::dedup

[Tom Lee]

Hey folks,

So turns out I'm still struggling with types a little. This time it's
related to mutability & function signatures. Apologies in advance if I
screw up terminology. Take the following code, which prints out the
unique elements of a vector:

extern mod std;
use std;

fn main() {
  let mut values = ~["foo", "bar", "foo", "baz"];

  do std::sort::quick_sort(values) |x, y| { str::le(*x, *y) }
  vec::dedup(&mut values);

  for vec::each(values) |v| { io::println(*v) }
}

I got this to compile & execute after several false starts, largely
via some educated guesses, but I'm still not convinced I fully
understand why this appeases the angry statically typed rustc gods. If
you good folks could weigh in & help me out it would be much
appreciated!

1. let mut values = ~["foo", "bar", "foo", "baz"];

Alright, so this is telling me that 'values' can be reassigned to some
other value (i.e. 'values' is a mutable variable). As near as I can
tell, because the 'mut' is on the left hand side, this appears to have
no impact on the actual type of 'values' except that the variable
itself be assigned different values in the local scope. Is that
correct?

2. vec::dedup(&mut values);

Here is where things get messy to me for all sorts of reasons. Looking
at the signature of vec::dedup:
http://dl.rust-lang.org/doc/core/vec.html#function-dedup I can see
that vec::dedup accepts a mutable, borrowed pointer to a ~[T]. I
*think* so that we can dig into the guts of the vector e.g.:

let p = p as *mut T
// snip ...
let _dropped = move *ptr::mut_offset(p, next_to_read);
// snip ...
*ptr::mut_offset(p, last_written) = move
*ptr::mut_offset(p, next_to_read);

It looks like the 'move' operations here are directly modifying the
contents of the vector by moving data around in the vector. This
strikes me as kind of strange. I've allocated an immutable vector on
the exchange stack and so make the assumption that the contents of the
vector is in effect fixed. Is that assumption cast to the wind as soon
as I start working with a mutable, borrowed pointer to that same
vector?

Or is this just the consequence of a bit of a sleazy optimization,
where the function signature makes it *look* like we're going to
return the deduped result in 'v' when in fact we're modifying it
in-place?

I'm not sure there's a coherent question here, but I feel like I'm
missing something. Hopefully somebody can understand what I'm rambling
on about & shed some light :)

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

Re: [rust-dev] Vectors, mutability & vec::dedup

[Tom Lee]

Alright, brace yourself for more stupid questions, Graydon. :)

On Thu, Dec 13, 2012 at 10:52 AM, Graydon Hoare  wrote:

> On 12-12-13 12:17 AM, Tom Lee wrote:
>
> > It looks like the 'move' operations here are directly modifying the
> > contents of the vector by moving data around in the vector. This
> > strikes me as kind of strange. I've allocated an immutable vector on
> > the exchange stack and so make the assumption that the contents of the
> > vector is in effect fixed. Is that assumption cast to the wind as soon
> > as I start working with a mutable, borrowed pointer to that same
> > vector?
>
> More or less. Mutability "inherits" (not sure I love that term, but it's
> what we're using) along the ownership path to a memory cell.


I'm still not sure I grok the terminology, sorry. :) Specifically, I'm not
sure what you mean by an "ownership path". Presumably ownership relates to
something like this:

// 1. x "owns" the memory on the RHS, and so the RHS "inherits" the
mutability of x?

let mut x = ~[1, 2, 3];


So here, though the data type of the RHS is immutable, the underlying
memory is *not* because the "owner" of that memory is mutable?

So while --
> operationally -- you and I both know that there's a difference between:
>
>// "Mutating a cell in a vector"
>foo[0] = 1
>
> and
>
>// "Mutating the vector variable"
>foo = [1] + foo[1..]
>
> The _observational_ difference, on an owned value (i.e. you're the only
> person who can even see the vector in question) is really just that the
> latter would do a bunch of allocation, copying and freeing, and wind up
> pointing to a different place containing exactly the same result. From
> the perspective of the surrounding code, if it's not actually paying
> attention to pointer values, those two lines are identical.



So after much struggling with library idiom evaluation, we decided that
> differentiating the two in the type system was more cost than benefit --
> it meant we had to have two different paths for a lot of code that
> differed only in where the obligatory word 'mut' showed up -- and
> rearranged mutability so that it "inherits" through the ownership path.
> That brings with it the significant benefit that we can often toggle the
> mutability from the entire datatype by assigning it to a read-only or
> read-write owner.


Are you talking about something like this?

// x is the owner & thus the underlying memory is mutable.
let mut x = ~[1, 2, 3];
x[0] = 10;   // ok, x[0] is reassigned

// y is the owner & the underlying memory is now immutable.
let y = move x;
y[0] = 10;   // compile time error: y is immutable.



Okay, I think that answers a few of my questions. I'm guessing when you
talk about mutability being "inherited" here, you're referring to the fact
the type system will enforce things like borrowed pointers? Something like:

let mut x = ~[1, 2, 3];
foo(&mut x);   // ok: x is mutable, mutable borrowed pointer

let mut y = ~[4, 5, 6];
foo(&mut y);   // compile error: y is immutable, but we want a
mutable borrowed pointer


I think that makes sense. The only question I'd have here is why we need to
be specific about whether the borrowed pointer is immutable or not?
Couldn't it be inferred from the underlying variable? What do we gain by
being explicit?

> Or is this just the consequence of a bit of a sleazy optimization,
> > where the function signature makes it *look* like we're going to
> > return the deduped result in 'v' when in fact we're modifying it
> > in-place?
>
> More or less. One person's sleazy optimization is another person's
> essential one. De-dupe might be a bit surprising but for a lot of
> operations (mostly vector operations -- it's the "arbitrary size" type
> after all), doing them "in place" is the difference between acceptable
> performance and "ugh, I'll just go do this in C". Our goal is to
> minimize the number of cases where users feel they have to switch to C
> "for performance reasons".
>

Argh, I just spent another hour being confused because I was somehow
looking at what must have been an old implementation of vec::dedup with a
type signature that implied no mutability at all. :)

Oh I totally get that, I only say "sleazy" because my understanding of
'mut' at the time was flawed (or I was looking at the wrong code again :)).
Makes perfect sense now.


> > I'm not sure there's a coherent question here, but I feel like I'm
> > missing something. Hopefully so

[rust-dev] glue_fns, shims & tydescs

[Tom Lee]

Hey Rustlers,

I'm fighting with issue #6575
<https://github.com/mozilla/rust/issues/6575> which
involves the removal of a useless function parameter emitted during the
trans phase. I've got a WIP available
here<https://github.com/thomaslee/rust/commit/issue-6575>if anybody's
interested, though it does right now is segfault. :) I
*think *the segfault is the result of me getting something silly wrong &
somehow the stack is getting messed up in the process (and/or something is
getting prematurely collected).

In any case, all this digging around is leaving me with some questions that
may or may not be useful to getting this thing to stop segfaulting & start
doing something useful.

Can anybody out there offer some clarification about the following?

   - What are glue_fns and why are they necessary? How/why do they differ
   from shim_fns (used to invoke foreign functions)?

   - What's the purpose of *visit_glue* in the type_desc struct? The others
   seem largely obvious (take/drop doing some sort of refcounting, free to
   clean up, but visit ... ?)

   - Where are type_descs/tydescs written? The stack? The heap(s)? (i.e.
   anything that can be a GC root?) Where in the source code does this happen?

   - What exactly is a "safe point" wrt the garbage collector?

Appreciate any insight!

Thanks,
Tom


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] glue_fns, shims & tydescs

[Tom Lee]

Thanks for the info guys, very helpful. Folks following along at home may
be interested in seeing where & how compiler writes out the set of tydescs:

https://github.com/mozilla/rust/blob/1393c3a3f438c896083405dca501c8cf05767c65/src/librustc/middle/trans/glue.rs#L766

I had assumed for some reason that they were local to some unit of
execution -- didn't realize that they were global (although that should
have been obvious, thinking about it).

Cheers,
Tom


On Thu, May 23, 2013 at 11:14 AM, Graydon Hoare  wrote:

> On 23/05/2013 3:33 AM, Tom Lee wrote:
>
>  Can anybody out there offer some clarification about the following?
>>
>>   * What are glue_fns and why are they necessary? How/why do they differ
>>
>> from shim_fns (used to invoke foreign functions)?
>>
>
> Glue functions are invoked by the compiler when types are dropped or
> copied. They manage the lifecycle of the type, and are ubiquitous and
> compiler-generated. They have nothing to do with shim functions aside from
> them both being compiler-generated (and too-numerous for our taste!)
>
>* What's the purpose of /visit_glue/ in the type_desc struct? The
>>
>> others seem largely obvious (take/drop doing some sort of
>> refcounting, free to clean up, but visit ... ?)
>>
>
> Visit is for reflection. See core::reflect (renamed last night to
> std::reflect).
>
>* Where are type_descs/tydescs written? The stack? The heap(s)? (i.e.
>>
>> anything that can be a GC root?) Where in the source code does this
>> happen?
>>
>
> They're global constant static data. Compiler-generated.
>
>* What exactly is a "safe point" wrt the garbage collector?
>>
>
> The name refers to the idea (in many GCs) of a place in a code-sequence at
> which the compiler has to spill references back to stack locations or
> otherwise arrive at a state properly described by metadata / frame maps,
> such that it can find all roots. It's only relevant in a precise GC. Since
> the current strategy for GC is conservative (presently _everywhere_, though
> this will eventually be limited to just-the-stack) there's on such need:
> the GC just spills all registers on entry and treats them as possible-roots
> like very other word on the stack.
>
> If you see the term in our code, it's residue from the most recent
> experiment with precise GC, which has been (for the time being) abandoned.
>
> -Graydon
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] glue_fns, shims & tydescs

[Tom Lee]

Oh & I'm glad to see that stuff go, Niko. I've been in & around that code
recently.

In fact, it seems your changes here may be headed for a bunch of conflicts
with my work on https://github.com/mozilla/rust/issues/6575 -- perhaps I
should defer doing more work until these changes land. Any ETA on that?
Cheers,
Tom



On Thu, May 23, 2013 at 6:33 PM, Niko Matsakis  wrote:

> Shim functions are an artifact of how we compiled foreign functions.
> They are explained a comment in .  They are not long
> for this world, though: https://github.com/mozilla/rust/pull/6661
>
>
> Niko
>
> On Thu, May 23, 2013 at 03:33:24AM -0700, Tom Lee wrote:
> > Hey Rustlers,
> >
> > I'm fighting with issue #6575
> > <https://github.com/mozilla/rust/issues/6575> which
> > involves the removal of a useless function parameter emitted during the
> > trans phase. I've got a WIP available
> > here<https://github.com/thomaslee/rust/commit/issue-6575>if anybody's
> > interested, though it does right now is segfault. :) I
> > *think *the segfault is the result of me getting something silly wrong &
> > somehow the stack is getting messed up in the process (and/or something
> is
> > getting prematurely collected).
> >
> > In any case, all this digging around is leaving me with some questions
> that
> > may or may not be useful to getting this thing to stop segfaulting &
> start
> > doing something useful.
> >
> > Can anybody out there offer some clarification about the following?
> >
> >- What are glue_fns and why are they necessary? How/why do they differ
> >from shim_fns (used to invoke foreign functions)?
> >
> >- What's the purpose of *visit_glue* in the type_desc struct? The
> others
> >seem largely obvious (take/drop doing some sort of refcounting, free
> to
> >clean up, but visit ... ?)
> >
> >- Where are type_descs/tydescs written? The stack? The heap(s)? (i.e.
> >anything that can be a GC root?) Where in the source code does this
> happen?
> >
> >- What exactly is a "safe point" wrt the garbage collector?
> >
> > Appreciate any insight!
> >
> > Thanks,
> > Tom
> >
> >
> > --
> > *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Anybody in PDX for some Rust-ing?

[Tom Lee]

Hey folks,

Since the folks in San Francisco seem to be trying to arrange some sort of
meetup, I can't help but wonder if there's any similar interest in good ol'
Portland, OR? Meetup, hackathon, whatever.

My employer's tends to be pretty generous wrt hosting tech events, but if I
can get some sort of indication of interest it'd help me make my case. :)

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Anybody in PDX for some Rust-ing?

[Tom Lee]

Sounds awesome Tim. Either way, let me know when you're in town -- I'm not
attending OSBridge, but it'd be good to put a face to the name.

If there's interest in a PDX Rust meetup for either June or July, all the
better.

Cheers,
Tom


On Fri, May 24, 2013 at 10:10 PM, Tim Chevalier wrote:

> On Fri, May 24, 2013 at 10:06 PM, Tom Lee  wrote:
> > Hey folks,
> >
> > Since the folks in San Francisco seem to be trying to arrange some sort
> of
> > meetup, I can't help but wonder if there's any similar interest in good
> ol'
> > Portland, OR? Meetup, hackathon, whatever.
> >
> > My employer's tends to be pretty generous wrt hosting tech events, but
> if I
> > can get some sort of indication of interest it'd help me make my case. :)
> >
>
> FYI, I'm giving a talk at Open Source Bridge in Portland on (I think)
> June 19, and I'll be around for a few days before/after. Other Rust
> team members (but not me) will be at OSCON in July. If a meetup
> happened to be when I was in town, I'd be happy to show up!
>
> Cheers,
> Tim
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "Not a riot, it's a rebellion." -- Boots Riley
> "Attention Bros and Trolls: When I call out your spew, I'm not angry,
> I'm defiant." -- Reg Braithwaite
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Traits & "mod"

[Tom Lee]

Hey folks,

A work colleague is trying to pick up some Rust & we were both
surprised by the following:

// some_mod.rs

pub trait SomeTrait {
pub fn foo(&self) -> ~str;
}

pub struct SomeStruct {
name: ~str
}

impl SomeTrait for SomeStruct {
pub fn foo(&self) -> ~str {
self.name.clone()
}
}

impl SomeStruct {
pub fn new(name: &str) -> SomeStruct {
SomeStruct { name: name.to_owned() }
}
}

// some_use.rs

mod some_mod;

fn main() {

  let inst = some_mod::SomeStruct::new("test");

  println(inst.foo());

}


This fails with a compile error because the compiler can't "see"
some_mod::SomeTrait in the scope of some_use.rs:

some_use.rs:5:4: 6:1 error: type `some_mod::SomeStruct` does not
implement any method in scope named `foo`
some_use.rs:5 inst.foo()
some_use.rs:6 }

This is fixed by adding "use some_mod::SomeTrait" at the start of
some_use.rs. It's as though traits need to be in the same scope as
code that expects to make use of their behaviour (where I'd expect the
behaviour would be associated with the implementation for the "self"
type).

My question is: is this intended behaviour? If not, what's the
expected behaviour & is there an outstanding issue for this?

Appreciate any clarification!

Cheers,
Tom

--
Tom Lee / http://tomlee.co / @tglee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm]

[Tom Lee]

Mozilla's own Tim Chevalier is giving a preview of his OSBridge talk,
"Rust: A Friendly Introduction" later this month. Should you be in
town the evening of June 17th, please drop by!

Full details on Calagator: http://calagator.org/events/1250464376

More about Tim's talk: http://opensourcebridge.org/sessions/970

Hope to see you there!

Cheers,
Tom

--
Tom Lee / http://tomlee.co / @tglee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "Rust: A Friendly Introduction" in Portland, OR [June 17th, 6pm]

[Tom Lee]

I'm told we don't have A/V equipment on-site, but if somebody else
attending wants to bring along the equipment (& assuming Tim's okay
with the idea) I don't see why not.

In any case, his talk at OSBridge a few days later may well be recorded?

Cheers,
Tom

On Fri, Jun 7, 2013 at 4:53 AM, Corey Richardson  wrote:
> On Fri, Jun 7, 2013 at 2:20 AM, Tom Lee  wrote:
>> Mozilla's own Tim Chevalier is giving a preview of his OSBridge talk,
>> "Rust: A Friendly Introduction" later this month. Should you be in
>> town the evening of June 17th, please drop by!
>>
>
> Will this be recorded?



-- 
Tom Lee / http://tomlee.co / @tglee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust 0.7 prerelease testing

[Tom Lee]

LGTM on latest Debian Testing:

Linux desktop 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux

Didn't run the full test suite, but a few simple smoke tests are looking good.

Cheers,
Tom

On Tue, Jul 2, 2013 at 8:14 PM, Brian Anderson  wrote:
> Oh look at this! It's a 0.7 release candidate!
>
> http://static.rust-lang.org/dist/rust-0.7.tar.gz
> sha256: 0b88b8a4489382e0a69214eaab88e2e7c316ec33c164af0d3b53630b17590df0
> http://static.rust-lang.org/dist/rust-0.7-install.exe
> sha256: 919fb016611888a139c8b451c8553b7695fe85596ad45764b8d4656a47c2e0f6
>
> This is _not_ a signed release, just a candidate. If you have some spare
> cycles please give this an install and report whether it does what you
> expect. We want to prove that the install works on platforms we tend to
> support (OS X 10.6+, various Linuxes, and Windows 7 & 2008) and the compiler
> generally behaves as expected, considering the various known issues. Testing
> on under-represented platforms is particularly welcome. Note that I've heard
> that Rust doesn't currently work on Mac OS 10.9, but further confirmation
> couldn't hurt.
>
> -Brian
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



-- 
Tom Lee / http://tomlee.co / @tglee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Portland, OR Friday 6:30pm: Patrick Walton & Jack Moffitt talk sprocketnes & Servo

[Tom Lee]

Hey all,

If you're in Portland, OR this week -- as many are for OSCON --
Patrick Walton & Jack Moffitt are taking some time out of their
schedules to talk Rust this Friday evening, 26th of July @ 6:30pm:

http://calagator.org/events/1250464569

All welcome, feel free to pop in & say hi -- elevators should be open
from around 6:15pm.

We'll be supplying beer & pizza. There's also plenty of soda if you're
not alcohol-ly inclined. Any other questions, feel free to ping me at
this address.

Otherwise, see you there!

Cheers,
Tom

-- 
Tom Lee / http://tomlee.co / @tglee
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Java versus .NET style for acronyms in type names

[Tom Lee]

Bikeshedding is right ;)

I'm probably a weirdo but I like the Java style when the type name is the
acronym in its entirety, but the .NET style when you mix it up with other
stuff.

e.g. I prefer GC<> to Gc<>, but then I prefer SimpleHttpServer to
SimpleHTTPServer :P

Guess I'm +0.5 on both?



On Fri, Aug 2, 2013 at 6:28 PM, Patrick Walton  wrote:

> Hi everyone,
>
> Brendan Eich emailed me expressing a preference for `GC<>` over `Gc<>`. I
> think now is as good a time as any to have the bikeshedding debate :)
>
> I've noticed two styles for acronyms in type names: Java style
> (HTTPServer) versus .NET style (HttpServer). Currently we are usually using
> .NET style, but inconsistently (e.g. ARC). We never really decided.
>
> Here are a few examples of types in each style:
>
> * Java style: GC, ARC, SimpleHTTPServer, XMLHTTPRequest.
>
> * .NET style: Gc, Arc, SimpleHttpServer, XmlHttpRequest.
>
> I slightly prefer Java style myself because I think "GC" looks better than
> "Gc", because Web APIs use Java style, and because Python does (e.g.
> SimpleHTTPServer) and in general we've been following PEP 8. But I don't
> feel strongly on this issue.
>
> Thoughts/straw poll?
>
> Patrick
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Java versus .NET style for acronyms in type names

[Tom Lee]

Agreed -- I don't particularly care, so long as it's consistent.

I guess wrt camel-casing acronyms, it'd be nice to avoid stuff like
HttpURLConnection<http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html>which
uses some bastardry of capitalization to avoid the unfortunate
situation where there are two acronyms are side-by-side.

Anyway. Bring on the dictator(s). :)



On Fri, Aug 2, 2013 at 7:47 PM, Aaron Dandy  wrote:

> That is an interesting but complicated idea. Ogre caps when an acronym is
> alone, camel when acronyms are adjacent.
>
> GC<>
> BFG<>
> BfgGc<>
>
> I feel like this is the sort of thing we should not decide collaboratively
> but instead should have beaten into us by a glorious dictator. I'm not sure
> this discussion will get us far as we are not the first to discuss it.
>
> --
> Date: Fri, 2 Aug 2013 19:38:44 -0700
> From: rust-...@tomlee.co
> To: rust-dev@mozilla.org
> Subject: Re: [rust-dev] Java versus .NET style for acronyms in type names
>
>
> Bikeshedding is right ;)
>
> I'm probably a weirdo but I like the Java style when the type name is the
> acronym in its entirety, but the .NET style when you mix it up with other
> stuff.
>
> e.g. I prefer GC<> to Gc<>, but then I prefer SimpleHttpServer to
> SimpleHTTPServer :P
>
> Guess I'm +0.5 on both?
>
>
>
> On Fri, Aug 2, 2013 at 6:28 PM, Patrick Walton wrote:
>
> Hi everyone,
>
> Brendan Eich emailed me expressing a preference for `GC<>` over `Gc<>`. I
> think now is as good a time as any to have the bikeshedding debate :)
>
> I've noticed two styles for acronyms in type names: Java style
> (HTTPServer) versus .NET style (HttpServer). Currently we are usually using
> .NET style, but inconsistently (e.g. ARC). We never really decided.
>
> Here are a few examples of types in each style:
>
> * Java style: GC, ARC, SimpleHTTPServer, XMLHTTPRequest.
>
> * .NET style: Gc, Arc, SimpleHttpServer, XmlHttpRequest.
>
> I slightly prefer Java style myself because I think "GC" looks better than
> "Gc", because Web APIs use Java style, and because Python does (e.g.
> SimpleHTTPServer) and in general we've been following PEP 8. But I don't
> feel strongly on this issue.
>
> Thoughts/straw poll?
>
> Patrick
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>
> ___ 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
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Adding "else" on "for" loops, like Python

[Tom Lee]

I'm a big Python user, but I'm -1 on for..else -- mostly because of the
choice of the "else" keyword.

The issue is that it's downright misleading. You don't look at the 'else'
clause and think "oh, I don't know what that means" & go look up the docs
like you might with other unfamiliar parts of a new language. You make
assumptions because of 'else's familiar semantics elsewhere in the language
(i.e. "else" implies that the block is executed when the test fails). In
the case of for..else those assumptions don't hold, and invariably lead to
bugs.

For this reason I never bothered to memorize the *real* behavior of
for..else in Python, and never missed it. It's just asking for trouble.

Call me a curmudgeon, but I think your code will be more explicit if you
declare a mut bool & check its state post-`break`. :)

Cheers,
Tom


On Sat, Aug 10, 2013 at 11:22 AM, Michael Woerister <
michaelwoeris...@gmail.com> wrote:

> On 08/10/2013 07:24 PM, Paul Nathan wrote:
>
>> On 8/10/13 7:10 AM, Simon Sapin wrote:
>>
>>> Hi,
>>>
>>> Now that the for loop is based on external iterators, can we reconsider
>>> "for-else"?
>>>
>>> Proposal:
>>>
>>>  for i in iter {
>>>  // ...
>>>  } else {
>>>  // ...
>>>  }
>>>
>>> The optional else block is executed when the for loop stops without
>>> exhausting the iterator, ie. when "break" is used.
>>>
>>>  I spent quite some time in Python, delving into as much of the language
>> as I could, and for-else was not something I used. It actually caused me
>> a bug due to a mis-indented if block in the for loop.
>>
>> I would suggest that perhaps for-else belongs as a macro construct for a
>> while to test adoption; if it proves useful and strongly adhered to, it
>> could be moved into the core language?
>>
> +1 for a macro approach.
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Adding "else" on "for" loops, like Python

[Tom Lee]

To be clear: should that `if` test be "if not converged" ?


On Sun, Aug 11, 2013 at 1:18 AM, Jens Nockert  wrote:

> I wouldn't call myself a Python programmer, but I have written a lot of
> Python and I know quite a few that do use and love the "for-else" construct.
>
> The most common (if not only?) usage that I have seen is something like
>
>   for i in xrange(…):
> some-algorithm…
> if coverged:
>   break
>   else:
> fail!("Did not converge!")
>
> While cool and all, I cannot think that it has many use-cases outside of
> this. A macro is probably sufficient.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Adding "else" on "for" loops, like Python

[Tom Lee]

On Sun, Aug 11, 2013 at 1:06 PM, Simon Sapin  wrote:

> Le 11/08/2013 06:53, Tom Lee a écrit :
>
>  I think your code will be more explicit if you declare a mut bool &
>> check its state post-`break`. :)
>>
>
> Resorting to boolean flags to cope with insufficient control flow feels
> like Basic, which makes me sad :(
>
>
:) I can appreciate that, but I'm still not really convinced that this
"problem" deserves more syntax.

That said, I might hate for..else less if it used something other than the
'else' keyword. *shrug*
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Adding "else" on "for" loops, like Python

[Tom Lee]

On Sun, Aug 11, 2013 at 1:27 PM, Patrick Walton  wrote:

> On 8/12/13 8:25 AM, Tom Lee wrote:
>
>> :) I can appreciate that, but I'm still not really convinced that this
>> "problem" deserves more syntax.
>>
>> That said, I might hate for..else less if it used something other than
>> the 'else' keyword. *shrug*
>>
>
> It seems to me that a big benefit of macros in Rust is to make
> less-commonly-used syntax still usable and reasonably convenient without
> having to build it into the compiler. "for/else" may be a perfect use case
> here.
>
>
You're right. I keep forgetting the macro proposal when I come back to read
this thread.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Adding "else" on "for" loops, like Python

[Tom Lee]

On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert  wrote:

>
> On 12 Aug 2013, at 00:09, Tom Lee  wrote:
>
> Anyway, this sort of confusion is exactly why I don't like for..else. But
> then maybe I'm the only one that's confused here. :)
>
>
> Obviously you were not the only one, since there was a long thread without
> clarification.
>
> While I think it is reasonably clear (since I am used to it), I don't
> think it is more clear than something like (in faux pyrust)
>
> let iterations = xrange(100);
>
> for i in iterations {
>   …
>   if converged {
> break;
>   }
> }
>
> if iterations.finished() {
>   fail!("Oh noes, it did not converge");
> }
>
>
I really like this. There's no room for confusion here.


> And I most certainly don't think for-else is more clear than a good macro
> implementation of a similar pattern.
>
> What I am worried about is that we add more edge-cases to syntax. The more
> syntax we add, the more likely it is that people will just use a subset and
> then be really confused when someone uses something special (break out of
> ifs in JS anyone?)
>
>
>
I think we agree on all of this.

Cheers,
Tom


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] What form should the official Rust binary installers for Unixes take?

[Tom Lee]

Hey Brian,

Not sure I understand the last paragraph of your email (do you or do you
not want to encourage distro-specific installation? :)), but my two cents:

I do some packaging work for the Debian project & expressed some interest
in helping out with the Rust packaging for Debian. Last I heard, there were
a couple of blockers there preventing us from including Rust as a
first-class citizen (and some of those issues also impacted the packaging
for Fedora). These were non-trivial at the time, but perhaps that's
changed. I've cced Luca Bruno in since I think he's been keeping a closer
eye on the details.

Relevant link on the wiki:
https://github.com/mozilla/rust/wiki/Note-packaging

At a glance, most of those tickets still seem to be open. Pushing to
address these issues in Rust and upstream would go a long way to getting
first-class support for Rust in Debian and Fedora -- and in turn Ubuntu,
RHEL, et al. Helping us work through some of the thornier issues would be a
huge help. I'm sure you'd see a lot of support from the community wrt
making this happen, but frankly many of the issues involved seem to be the
sort of thing where we need some guidance from members on the core team
and/or a strong push upstream to projects like libuv and llvm.

In the absence of a first-class package for Debian, I'd personally prefer a
sane build from source before a custom installer on Linux (something that
Rust does a pretty good job of as of the time of writing this).

Cheers,
Tom



On Mon, Feb 10, 2014 at 5:12 PM, Brian Anderson wrote:

> Thanks for the replies, everyone. Here are my current takeaways:
>
> * Don't create Linux distro-specific packages, let the various communities
> deal with it
> * Don't create a networked installer
>
> So here's what I'm thinking we do now. These are the install methods we
> would be promoting on the home page:
>
> * Mac: .pkg file
> * Linux: standalone, cross-distro installer
> * Windows: use the installer we've already got
>
> I'm worried that, if we keep out of the packaging business, but those
> packages end up being peoples' preferred way to get Rust, then the web page
> would be advocating the worst ways to get Rust. It seems like we'll need to
> put a link to 'alternate installation methods' on the homepage to link
> people to homebrew, macports, ubuntu, arch, etc. packages, emphasizing that
> they are unsupported.
>
>
>
>
> On 02/06/2014 04:35 PM, Brian Anderson wrote:
>
>> Hey.
>>
>> One of my goals for 0.10 is to make the Rust installation and upgrade
>> experience better. My personal ambitions are to make Rust installable with
>> a single shell command, distribute binaries, not source, and to have both
>> nightlies and point releases.
>>
>> Since we're already able to create highly-compatible snapshot compilers,
>> it should be relatively easy to extend our snapshot procedure to produce
>> complete binaries, installable via a cross-platform shell script. This
>> would require the least amount of effort and maintenance because we don't
>> need to use any specific package managers or add new bots, and a single
>> installer can work on all Linuxes.
>>
>> We can also attempt to package Rust with various of the most common
>> package managers: homebrew, macports, dpkg, rpm. There community-maintained
>> packages for some of these already, so we don't necessarily need to
>> redevelop from scratch if we just want to adopt one or all of them as
>> official packages. We could also create a GUI installer for OS X, but I'm
>> not sure how important that is.
>>
>> What shall we do?
>>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] PDX-Rust meetup tomorrow

[Tom Lee]

Hey folks,

Per the subject, there's a Rust meetup in Portland, OR tomorrow night from
6:30pm. Details here:

http://calagator.org/events/1250465822

I'm waiting on a speaker to get back to me, so the topic is still
unfortunately TBA. If our speaker falls through, I'll slap together an 11th
hour walk-through of some Rust compiler internals. Should be fun either way!

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Slides from PDX-Rust talk RE: compiler internals

[Tom Lee]

Hey Ike,

Glad you found the slides useful! If I had to guess I imagine it's hard to
justify documenting things at the file + function/method level in any huge
amount of detail given that the compiler changes pretty rapidly. Or at
least, it has in the past -- it's certainly seems to have stabilized a lot
over recent months.

That said, I can't imagine the core folks would object to somebody
documenting this stuff more formally in an area like the hacking guide if
there's not a better source for it. It's interesting stuff for newbies --
especially folks interested in (but new to) compiler construction in
general. It's often tough to associate the stuff in text books with
real-world examples. :)

Happy to help out if there's interest.

Cheers,
Tom


On Mon, Mar 31, 2014 at 6:24 AM, Isaac Hollander McCreery <
ihmccre...@gmail.com> wrote:

> All,
>
> Tom, thank you!  I was looking for something like this in the READMEs and
> wiki, but couldn't find anything that seemed to start at the beginning and
> give clear signposts for where to find things.
>
> With that in mind, did I miss something?  If not, maybe I could convert
> these into markdown and we could put them up somewhere visible in the Wiki?
>  Here's what I could find that's online right now in the same ballpark:
>
> - https://github.com/mozilla/rust/blob/master/src/librustc/README.txt
> - https://github.com/mozilla/rust/wiki/Note-rustc-hacking-guide
>
> What do you all think?
>
> Thanks for all the great work you do,
> Ike
>
>
> On Sat, Mar 29, 2014 at 5:06 PM, Tom Lee  wrote:
>
>> Hey folks,
>>
>> Here are the slides from a presentation I gave at PDX-Rust earlier this
>> week.
>>
>> The talk itself was a little rough, but I think the notes outlined in the
>> slides might be useful for anybody looking to start poking around inside
>> the Rust compiler. Happy to clarify anything if the slides are unclear!
>>
>> http://www.slideshare.net/thomaslee/rust-march2014-32891901
>>
>> PDF attached to this email if you're allergic to slideshare. :)
>>
>> Huge thanks to Brian A. for some extremely helpful last-minute
>> fact-checking on short notice.
>>
>> Cheers,
>> Tom
>>
>> --
>> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>>
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] A More Detailed Tour of the Rust Compiler

[Tom Lee]

Hey folks,

I took the slides from my talk at last week's PDX-Rust meetup & slapped
together a blog post that covers some of the innards of the Rust compiler
in a little more detail:

http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/

It kind of reads somewhere between a high level overview and a detailed
look at compiler innards, but hopefully it's useful to somebody out there.

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev