On 07/02/2013 8:51 PM, Steve Klabnik wrote:
> Neat! I'm assuming this is based on how Mozilla works internally, yes?
No, just for rust. Much of mozilla runs off mercurial and bugzilla; some
projects are on github, some use their own testing bots, some just
manual testing. The tools vary from group
> Neat! I'm assuming this is based on how Mozilla works internally, yes?
>
> You may be interested in integrating it with the commit status API,
> like Travis has: https://github.com/blog/1227-commit-status-api
In case you missed, it already does.
___
Ru
Neat! I'm assuming this is based on how Mozilla works internally, yes?
You may be interested in integrating it with the commit status API,
like Travis has: https://github.com/blog/1227-commit-status-api
___
Rust-dev mailing list
Rust-dev@mozilla.org
http
Hi,
Many on the IRC channel (or those watching the commit stream) will have
noticed we've recently enabled an "auto-merge" robot (named "bors"[1]).
This slightly changes the path for merging code into our repository.
For the most part no changes are required to people submitting pull
requests: ke
John Clements wrote:
Nice example. Just to make things completely absolutely clear: IIUC, you're saying that changing
the (&'b mut self) argument to the next function into, e.g., (&'c mut self) --that is, a
"free" lifetime (and I forget whether a binding site is required for this)--makes the
c
On Feb 5, 2013, at 8:02 PM, Niko Matsakis wrote:
> This is indeed what I mean and yes it can go wrong. Let me spell out what
> happens with the Iterator example, it's a bit involved and took me some time
> to fully appreciate. To begin, today you have the following annotations on
> the `next(
