Re: [rust-dev] Tail call compatibility
The abi is allowed to change post 1.0. If it wasn't, we'd be stuck with cdecl forever and that sucks. I've only seen fastcall used for intracrate leaf calls. Servo and rustc are the two biggest rust projects. The mailing list is mostly dead BTW. Consider bringing this up on discuss.rust-lang.org instead. If you plan on playing with calling convention, aatch and I (cgaebel) have been considering a rust-specific one. You should drop by on irc some time if it interests you! Happy to help, - Clark On Sat, Dec 27, 2014 at 11:39 AM, Andrea Canciani ranm...@gmail.com wrote: I tried to collect as much information as possible from IRC and from the Web about TCO in Rust. The most recent (and authoritative) reference I can find is https://github.com/rust-lang/meeting-minutes/blob/e3c325c7e30331cb43e0c5b68f35070f211ee4cb/weekly-meetings/2014-05-20.md#tail-calls The decision seems to be that it is an interesting feature, but that it should be postponed for a future release. To me this looks like a good point, but I'm worried about potential backward-compatibility hazards. In particular, the be keyword has been removed from the language and the proposed alternative (become) has never been introduced. Wouldn't it be easier to ensure backward compatibility if the become keyword was at reserved in rust 1.0? Another thing I'm worried about is callee vs. caller cleanup of the call stack. Changing the rust calling convention post-1.0 would break the ABI, so it would be very inconvenient. On IRC I was told that rustc was already using the LLVM fastcall calling convention, but https://github.com/rust-lang/rust/blob/master/src/librustc_trans/trans/base.rs#L310 seems to indicate that the C calling convention is used instead. In several posts on the TCO, one of the points against supporting TCO was that it involves using a slower calling convention, but I was unable to find any benchmark to support that statement. Where can I find some discussions about the [dis]advantages of the different calling conventions and what design choices led to the current one? I would like to evaluate the performance (speed, code size) impact of changing the calling convention. What would be the best way to do this? Is there any well-known benchmark for changes that affect the overall behavior of the compiler? I would assume that rustc itself is probably one of the most interesting real-world applications written in rust right now. Otherwise, is the compiler shootout challenge sufficiently interesting for this purpose? Andrea___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust discourse visibility [Was: Tail call compatibility]
There was a thread about it on... Discourse! http://discuss.rust-lang.org/t/is-it-time-to-kill-the-mailing-list/611/36 On Sat, Dec 27, 2014 at 11:53 AM, Tomi Pieviläinen tomi.pievilai...@iki.fi wrote: The mailing list is mostly dead BTW. Consider bringing this up on discuss.rust-lang.org instead. This is the first time I've heard of that. I checked that it isn't even linked on the homepage, but the mailing list and IRC are. Have I missed something, or should the discourse then be linked instead of or at least in addition of the mailing list? -- Tomi Pieviläinen, +358 400 487 504 A: Because it disrupts the natural way of thinking. Q: Why is top posting frowned upon? ___ 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] C interop puzzle
```
let v: Vecu8 = ...;let repr = v.as_slice().repr();
ProtobufObj {
data: repr.data,
size: repr.len
}
```
should do the trick.
On Tue, Nov 25, 2014 at 2:06 PM, Connor Doyle con...@mesosphere.io
wrote:
Hi all,
First time on the mailing list!
I'm having trouble setting a raw void pointer in a struct using a recent (72
hrs) nightly.
I'd like to address the underlying bytes for a Vecu8 I have in-hand.
The FFI guide is a little thin in this area, glad to add detail once I figure
out how this is done.
For reference, here is the target struct:
extern crate libc;
#[repr(C)]
pub struct ProtobufObj {
pub data: *mut libc::c_void,
pub size: libc::size_t,
}
Thanks,
--
Connor
___
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] Help needed with lifetimes.. (I'm new to rust)
`clean_number` inside the function `clean` is destructed, and a slice into the
destructed String is returned. You’re probably looking for the `MaybeOwned`
enum in the standard library to do what you want:
http://is.gd/QvkESn
Regards,
- Clark
On Mon, Oct 20, 2014 at 12:57 PM, Jake Scott jake@gmail.com wrote:
Can someone give me a hand, I'm getting the following lifetime error:
error: clean_number does not live long enough
Short url: http://is.gd/VIzHMS
This is the code:
#![feature(phase)]
#[phase(plugin)]
extern crate regex_macros;
extern crate regex;
use regex::Regex;
static ALPHA_REGEX: Regex = regex!(r[a-zA-Z]);
static NUMBER_REGEX: Regex = regex!(r[^0-9]);
fn main() {
let number = number(ads(123) 456-7890);
println!({}, number);
}
fn number'a(number: 'a str) - 'a str {
let clean_number = clean(number);
clean_number
}
fn clean'a(number: 'a str) - 'a str {
if ALPHA_REGEX.is_match(number) {
00;
}
let clean_number: String = NUMBER_REGEX.replace(number, );
return clean_number.as_slice();
}___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Inheritance / delegation
Rust is not a replacement for java, it’s a replacement for C and C++.
To solve little “puzzles” like this, i tend to ask myself “how would I do this
in C”, and then write that code in rust. Building inheritance trees is
generally the wrong way of approaching problems. In cases where it does apply,
you can still do it, but be gentle. Try not to lean on them as your primary
means of abstraction.
Anyhow, on to your actual problem.
Something which might be worth trying is implementing `DerefCircle` and
`DerefMutCircle` for your pancake, then having a `DListBoxDerefCircle`
(or just use a normal , if you want that).
Then you can call all your circle traits after a quick call to `.deref()`, AND
your `DList` will free everything properly.
But again, there’s probably a simpler solution that doesn’t involve
“inheritance” that you should consider. Maybe a DList of enums? Maybe just a
Vecuint in this case? Think about how you’d do it in C.
Regards,
- Clark
On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson di...@ubuntu.com
wrote:
Hmm, right. The as_* could probably useful to write a macro for.
Coming from the C/Java side of things I have to figure out how this
works in a bigger context, e g a DList or other structure owning objects
implementing HasArea. This seems to compile, e g:
impl Pancake {
fn as_box_circle(self) - BoxCircle { box self.circle }
}
fn make_pancake(dl: mut DListBoxHasArea) {
let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64
}, is_tasty: true };
dl.push(p.as_box_circle());
}
But I'd assume that make_pancake would now make a copy of the pancake's
circle, rather than taking ownership of the entire pancake, right? The
pancake then gets dropped at function return.
In this simple example perhaps this does not make that much of a
difference though, but if you imagine a C struct like:
struct list {
list *next;
circle *data;
}
You can now put a pointer to a pancake as data, use it as a circle, and
when you finally free the list and the data that goes with it, the
entire pancake will be freed. This you cannot do in rust...or can you?
On 2014-10-17 07:59, Clark Gaebel wrote:
impl Pancake {
fn as_circle(self) - Circle { self.circle }
fn as_mut_circle(mut self) - mut Circle { mut self.circle }
}
The compiler will optimize trivial functions, except cross-crate. In
those cases, use an #[inline] annotation.
On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson di...@ubuntu.com
mailto:di...@ubuntu.com wrote:
This is probably a previously asked question, but I couldn't find
it on
Google, so...
Let's extend the Circle example from the guide a little:
struct Circle {
x:f64,
y:f64,
radius:f64,
}
trait HasArea {
fn area(self)- f64;
}
impl HasArea for Circle {
fn area(self)- f64 {
std::f64::consts::PI * (self.radius * self.radius)
}
}
struct Pancake {
circle: Circle,
is_tasty: bool,
}
...now, what is the easiest way I can implement HasArea for
Pancake? I
could do this:
impl HasArea for Pancake {
fn area(self) - f64 { self.circle.area() }
}
...but that means a lot of boiler-plate code, especially if
HasArea has
many methods. Hopefully rust will just inline/optimise the
redirection
away in most cases to avoid the runtime cost, but is there a
smarter or
more idiomatic way of doing this?
// 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] Inheritance / delegation
Such a structure should be possible with DST (a very new feature), but I
haven’t kept up to date enough to know how to use it properly. In your example,
where you just embed a slice instead of having the struct itself
dynamically-sized, try:
```
struct Bag {
price: int,
items: Vecint,
}
enum Shopping {
InBag(Bag),
InCart(/* … */),
}
impl Shopping {
fn new(price: int, items: Vecint) - Shopping {
InBag(Bag {
price: price,
items: items,
})
}
}
```
If you want to avoid the vector, and associated allocation, just use a slice
instead. It’ll require some lifetime annotations, though:
```
struct Bag‘a {
price: int,
items: ’a [int],
}
enum Shopping‘a {
InBag(Bag‘a),
InCart(/* … */),
}
impl‘a Shopping‘a {
fn new(price: int, items: ’a [int]) - Shopping‘a {
InBag(Bag {
price: price,
items: items,
})
}
}
```
Regards,
- Clark
On Fri, Oct 17, 2014 at 11:51 AM, David Henningsson di...@ubuntu.com
wrote:
Thanks for the answer. Deref is a new one for me, looks interesting by
means of abstraction.
I'm also coming from the C camp but I'm not sure how to write the code
that I want in rust. Yet. :-)
E g, here's one, somewhat related, C example that I'm not sure how to do
in Rust:
struct bag {
int price;
int nitems;
int []items;
};
struct cart { /* ... */ };
struct shopping {
int kind; /* 0 means bag, 1 means cart */
union {
struct bag bag;
struct cart cart;
}
}
struct shopping* make_shopping_bag(int price, int nitems, int *items)
{
struct shopping* result = malloc(sizeof(shopping)+nitems*sizeof(int));
result.kind = 0;
result.bag.price = price;
result.bag.nitems = nitems;
memcpy(result.bag.items, nitems*sizeof(int));
}
So, the bag struct would probably look like this in Rust:
struct Bag 'a {
price: int,
weights: 'a [int],
}
1) It feels like weights: [int] would be more like the way I want
it, and the declaration compiles, but i can't initialize the struct or
have it as a local variable because its size is now unkown. Even though
a static initialization like let b = Bag { price: 10, weights: [3,5,7]
} would be trivial to calculate the total size of, the compiler seems
not to be able to do this.
2) I'm not sure why this lifetime has to be explicit, should default
to same lifetime as parent struct IMO.
3) And when I try to do like:
enum Shopping {
InBag(Bag),
InCart( /* ... */ ),
}
I get an error: error: wrong number of lifetime parameters: expected 1,
found 0. I've tried both InBag('a Bag) and InBag(Bag + 'a) but that
ends up with other errors instead...so no idea on what to do about that?
On 2014-10-17 18:37, Clark Gaebel wrote:
Rust is not a replacement for java, it’s a replacement for C and C++.
To solve little “puzzles” like this, i tend to ask myself “how would I
do this in C”, and then write that code in rust. Building inheritance
trees is generally the wrong way of approaching problems. In cases
where it does apply, you can still do it, but be gentle. Try not to
lean on them as your primary means of abstraction.
Anyhow, on to your actual problem.
Something which might be worth trying is implementing `DerefCircle`
and `DerefMutCircle` for your pancake, then having a
`DListBoxDerefCircle` (or just use a normal , if you want that).
Then you can call all your circle traits after a quick call to
`.deref()`, AND your `DList` will free everything properly.
But again, there’s probably a simpler solution that doesn’t involve
“inheritance” that you should consider. Maybe a DList of enums? Maybe
just a Vecuint in this case? Think about how you’d do it in C.
Regards,
- Clark
On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson di...@ubuntu.com
mailto:di...@ubuntu.com wrote:
Hmm, right. The as_* could probably useful to write a macro for.
Coming from the C/Java side of things I have to figure out how this
works in a bigger context, e g a DList or other structure owning
objects
implementing HasArea. This seems to compile, e g:
impl Pancake {
fn as_box_circle(self) - BoxCircle { box self.circle }
}
fn make_pancake(dl: mut DListBoxHasArea) {
let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64
}, is_tasty: true };
dl.push(p.as_box_circle());
}
But I'd assume that make_pancake would now make a copy of the
pancake's
circle, rather than taking ownership of the entire pancake, right?
The
pancake then gets dropped at function return.
In this simple example perhaps this does not make that much of a
difference though, but if you imagine a C struct like:
struct list {
list *next;
circle *data;
}
You can now put a pointer to a pancake as data, use it as a
circle, and
when you finally
Re: [rust-dev] Inheritance / delegation
Oooh fun you’ve hit your first rustc bug! Great!
https://github.com/rust-lang/rust/issues/17178
Niko is already working on this, so a fix is coming soon. Both of those
constructions should have failed. The correct way to fix this is:
```
let weights = [ 3,5,7 ];
let b = InBag(Bag { price: 10, weights: weights.as_slice() });
```
On Fri, Oct 17, 2014 at 12:30 PM, David Henningsson di...@ubuntu.com
wrote:
First, big thanks to both of you, Ben and Clark, for helping out. :-)
Thanks for the hint on the lifetime syntax - it's a bit hard to grasp,
sometimes it's Foo'a, sometimes it's 'a [Foo], and I've seen
examples with Foo+'a too. But maybe this all makes sense when I'm more
used to the language.
As for how long the pointed-to data is alive for, I think it makes sense
to default to the same lifetime as parent struct or enum, if the
lifetime is not explicitly specified.
Btw, for some reason this does not work:
let s = InBag(Bag { price: 10, weights: [3, 5, 7] }); /* fails with
borrowed value does not live long enough and consider using a `let`
binding to increase its lifetime */
But the below does, and can be used as a workaround:
let b = Bag { price: 10, weights: [3, 5, 7] };
let s = InBag(b);
I'm sure there's an explanation to why, but if it can be fixed so that
the compiler interprets the first as being equivalent to the second it
would be nice.
On 2014-10-17 21:01, Ben Foppa wrote:
Your struct has a fixed size - a reference is a pointer. Which is why
it requires a lifetime - how long is the pointed-to data alive for?
And so you need to tell it - in your enum example, you need to say
Bag'a (for some defined 'a). For example, Bag'static means the
pointed-to data lives as long as the program.
On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson di...@ubuntu.com
mailto:di...@ubuntu.com wrote:
Thanks for the answer. Deref is a new one for me, looks
interesting by means of abstraction.
I'm also coming from the C camp but I'm not sure how to write the
code that I want in rust. Yet. :-)
E g, here's one, somewhat related, C example that I'm not sure how
to do in Rust:
struct bag {
int price;
int nitems;
int []items;
};
struct cart { /* ... */ };
struct shopping {
int kind; /* 0 means bag, 1 means cart */
union {
struct bag bag;
struct cart cart;
}
}
struct shopping* make_shopping_bag(int price, int nitems, int *items)
{
struct shopping* result =
malloc(sizeof(shopping)+nitems*sizeof(int));
result.kind = 0;
result.bag.price = price;
result.bag.nitems = nitems;
memcpy(result.bag.items, nitems*sizeof(int));
}
So, the bag struct would probably look like this in Rust:
struct Bag 'a {
price: int,
weights: 'a [int],
}
1) It feels like weights: [int] would be more like the way I
want it, and the declaration compiles, but i can't initialize the
struct or have it as a local variable because its size is now
unkown. Even though a static initialization like let b = Bag {
price: 10, weights: [3,5,7] } would be trivial to calculate the
total size of, the compiler seems not to be able to do this.
2) I'm not sure why this lifetime has to be explicit, should
default to same lifetime as parent struct IMO.
3) And when I try to do like:
enum Shopping {
InBag(Bag),
InCart( /* ... */ ),
}
I get an error: error: wrong number of lifetime parameters:
expected 1, found 0. I've tried both InBag('a Bag) and
InBag(Bag + 'a) but that ends up with other errors instead...so
no idea on what to do about that?
On 2014-10-17 18:37, Clark Gaebel wrote:
Rust is not a replacement for java, it’s a replacement for C and C++.
To solve little “puzzles” like this, i tend to ask myself “how
would I do this in C”, and then write that code in rust. Building
inheritance trees is generally the wrong way of approaching
problems. In cases where it does apply, you can still do it, but
be gentle. Try not to lean on them as your primary means of
abstraction.
Anyhow, on to your actual problem.
Something which might be worth trying is implementing
`DerefCircle` and `DerefMutCircle` for your pancake, then
having a `DListBoxDerefCircle` (or just use a normal , if
you want that).
Then you can call all your circle traits after a quick call to
`.deref()`, AND your `DList` will free everything properly.
But again, there’s probably a simpler solution that doesn’t
involve “inheritance” that you should consider. Maybe a DList of
enums? Maybe just a Vecuint in this case? Think about how you’d
do it in C.
Regards,
- Clark
On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson
Re: [rust-dev] Async Message passing.
These are the semantics of a boxed value. On Mon, Sep 29, 2014 at 9:47 PM, Wink Saville w...@saville.com wrote: On Mon, Sep 29, 2014 at 1:10 PM, Paul Colomiets p...@colomiets.name wrote: Hi, On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville w...@saville.com wrote: Nanomsg looks interesting and I'll take a closer look. But I'm interested in a pure rust implementation of async messaging because I'd like to create an embedded OS using rust and not use C if possible. I think even if there will be nanomsg implementation in pure rust, that would probably require rust stdlib, which is usually not used for embedded purposes, right? I been thinking about the problem and one of the questions I have is how to transfer ownership of a pointer from one entity to another. Not borrow but actually transfer ownership. So if I allocated a Message in one entity then send it to another I want the receiver to free the Message. Does the rust ownership model allow ownership to be transferred? Sure, you can just send Vec of bytes or any other rust object though the channel (just like almost any rust object). And semantics is just like you described. You can also use ArcVecu8 that allows to use that message in several places simultaneously (e.g. if you want publish-subscribe) I'd rather not use a channel as channels appear to only work between tasks. I'd like to have the transfer semantics work between any two entities. For instance, I'd like to have a queue between two entities and transfer a reference via the queue from A to B. .i.e. allocate a Message in A then place the Message on a queue. A would no longer have a reference to the Message and the only reference would be the one in the queue. Then when B retrieved the message from the queue B would have the only reference. Finally, when B went out of scope, the message would be freed. Is that possible as the language is currently defined, if so could I be pointed to an example or documentation? Paul ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Timing vector inserts
I sent a pull request, but the tl;dr of it is that the rust version was run without optimizations turned on. On Thu, Sep 25, 2014 at 12:17 PM, Fredrik Widlund fredrik.widl...@gmail.com wrote: http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ (disclaimer: *not* about comparing languages and claiming language X is better than language Y) Kind regards, Fredrik Widlund___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Timing vector inserts
You’re also timing two pushes, as opposed to a push and an array write in the C version. On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay danielmi...@gmail.com wrote: On 25/09/14 03:17 PM, Fredrik Widlund wrote: http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ (disclaimer: *not* about comparing languages and claiming language X is better than language Y) Kind regards, Fredrik Widlund https://github.com/jemalloc/jemalloc/issues/126___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Timing vector inserts
Another problem I noticed is that the elements in the vector in the rust code
are `uint` (which on most systems is 64-bit) and in the C code you’re inserting
`int`s (32-bits on most systems).
That’s not really a fair contest.
- Clark
On Thu, Sep 25, 2014 at 6:26 PM, François-Xavier Bourlet
bomb...@gmail.com wrote:
and hitting reply-all is better...
quick update: the implementation with unsafe ptr is not slower. I
just have too many cores + power-boost to get a clean benchmark every
time.
Running the benchs with n=1 billions (instead of 100 millions) gives me:
== vector_grow_c.csv ==
10,5.084604
== vector_grow_rust.csv ==
10,5.217096
== vector_grow_rust2.csv ==
10,4.912147 (yes, getting rid of the second push works!)
$ rustc --version
rustc 0.12.0-pre-nightly (0e784e168 2014-09-16 23:26:11 +)
$ gcc --version
gcc (GCC) 4.9.1
On Thu, Sep 25, 2014 at 6:18 PM, François-Xavier Bourlet
bomb...@gmail.com wrote:
On my machine I get:
C: 1,0.509391
rust: 1,0.466069
So rust is faster for me.
For fun, I tried to write the rust version using unsafe and
pre-allocation to remove the second push:
let mut m = Vec::from_fn(101, |_| 0);
let pm = m.as_mut_ptr();
let mut m_idx = 1i;
let t = time::precise_time_ns();
for _i in iter::range_step(0, n, n/100) {
for j in range(0, n/100) {
v.push(j);
}
unsafe {
ptr::write(pm.offset(m_idx as int), time::precise_time_ns() - t);
}
m_idx += 1;
}
But I get a little slower result (maybe I am doing something wrong
with the unsafe and ptr):
rust2: 1,0.472749
And just to be sure, I tested getting rid of iterators (using manual
while loop instead) and this changed nothing (as expected).
my 2 cents
On Thu, Sep 25, 2014 at 4:05 PM, Clark Gaebel cg.wowus...@gmail.com wrote:
You’re also timing two pushes, as opposed to a push and an array write in
the C version.
On Thu, Sep 25, 2014 at 3:59 PM, Daniel Micay danielmi...@gmail.com wrote:
signature.asc
___
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] iterate over pairs and why no multiple mutable references
You can use a Vec for this.— Sent from Mailbox On Fri, Sep 19, 2014 at 1:14 AM, Manish Goregaokar manishsm...@gmail.com wrote: Iterator invalidation is a common memory safety issue where you have two references being simultaneously used -- one mutable, one immutable. With multiple mutable references worse errors can happen. -Manish Goregaokar On Fri, Sep 19, 2014 at 1:09 PM, silvio silvio.fris...@gmail.com wrote: Hi Rust, I've recently tried to investigate rust's claim of being fast and had a look at debian shootout. A particular program I took a looked at is the n-body problem in which you have to loop over pairs of bodies to calculate their gravitational attraction. What struck me as strange was the number of indexing operations. bodies[i] bodies[j] bodies[i] bodies[j] ... Now I don't know if the compiler is smart enough to optimize this away. However, it seems generally impossible to make references. let mut body_i = bodies.someMethod(i) let mut body_j = bodies.someMethod(j) So how is this usually done? Why are multiple mutable references to the same object not allowed. To achieve safe memory you only need to guarantee that different threads don't write/read from/to the same memory location at the same time and that is handled via ownership. (borrowed) references don't have ownership. Additionally, you need to ensure that all references not only mut are not usable anymore until you can transfer ownership. So, I don't understand why mut and not mut are treated differently. An other small thing. I read that you should always return a type directly. fn foo(args) - big_struct Does this mean that all return values are secretly pointers passed to the function except for things that fit into registers? regards silvio ___ 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] [ANN] Iobuf
from_str is only used to construct read-only Iobufs, which do not support
writing into the buffer. Also, if you modify the string, it should invalidate
the Iobuf since the lifetime is bound to the borrowed reference of the string.
- Clark
On Thu, Sep 4, 2014 at 8:36 PM, Kevin Ballard ke...@sb.org wrote:
I’m still seeing bad transmutes.
fn from_str'a(s: 'a str) - RawIobuf'a {
unsafe {
let bytes: mut [u8] = mem::transmute(s.as_bytes());
RawIobuf::of_buf(BorrowedBuffer(bytes))
}
}
This is taking a `str`, converting to `[u8]`, and then transmuting to `mut
[u8]`. Besides being undefined, I have to assume it's also possible for other
code later on to end up attempting to actually mutate this data, which will
either a) be really bad, or b) not even be possible if it's a string constant
in read-only member.
-Kevin
On Sep 4, 2014, at 1:15 AM, Clark Gaebel cg.wowus...@gmail.com wrote:
I think you’re right! Thanks for pointing at UnsafeCell. That seems like
exactly what I want. It has been fixed.
Thanks a ton for the catch!
- Clark
On Thu, Sep 4, 2014 at 12:46 AM, Vladimir Matveev dpx.infin...@gmail.com
wrote:
Hi!
I’ve noticed this piece of code in your library:
#[inline]
fn as_mut_slice(self) - mut [u8] {
unsafe {
match self {
OwnedBuffer(ref v) = {
let mut_v: mut Vecu8 = mem::transmute(v);
mut_v.as_mut_slice()
},
BorrowedBuffer(ref s) = {
let mut_s: mut mut [u8] = mem::transmute(s);
mut_s.as_mut_slice()
},
}
}
}
I was under impression that transmuting to mut is undefined behavior in
Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong?
On 04 сент. 2014 г., at 9:17, Clark Gaebel cg.wowus...@gmail.com wrote:
Hey everyone!
Have you ever needed to communicate with the outside world from a rust
application? Do you need to send data through a network interface, or
touch a disk? Then you need Iobufs!
An Iobuf is a nifty abstraction over an array of bytes, which makes
writing things like highly efficient zero-copy speculative network
protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to
do the heavy lifting.
https://github.com/cgaebel/iobuf
Enjoy,
- Clark
___
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 mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Iobuf
It just seems weird to me that transmuting to a raw::Sliceu8, and then casting the data ptr to a *mut u8 when I need it is safer than just using the ’a mut [u8] directly. But alas, I’ll fix it. - Clark On Fri, Sep 5, 2014 at 2:55 AM, Kevin Ballard ke...@sb.org wrote: It's still undefined behavior to construct the mut reference like that, even if it's never actually mutated. I think you need to ditch mut and start using *mut instead. -Kevin On Sep 4, 2014, at 11:55 PM, Clark Gaebel cg.wowus...@gmail.com wrote: from_str is only used to construct read-only Iobufs, which do not support writing into the buffer. Also, if you modify the string, it should invalidate the Iobuf since the lifetime is bound to the borrowed reference of the string. - Clark On Thu, Sep 4, 2014 at 8:36 PM, Kevin Ballard ke...@sb.org wrote: smime.p7s ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Iobuf
I think you’re right! Thanks for pointing at UnsafeCell. That seems like
exactly what I want. It has been fixed.
Thanks a ton for the catch!
- Clark
On Thu, Sep 4, 2014 at 12:46 AM, Vladimir Matveev dpx.infin...@gmail.com
wrote:
Hi!
I’ve noticed this piece of code in your library:
#[inline]
fn as_mut_slice(self) - mut [u8] {
unsafe {
match self {
OwnedBuffer(ref v) = {
let mut_v: mut Vecu8 = mem::transmute(v);
mut_v.as_mut_slice()
},
BorrowedBuffer(ref s) = {
let mut_s: mut mut [u8] = mem::transmute(s);
mut_s.as_mut_slice()
},
}
}
}
I was under impression that transmuting to mut is undefined behavior in
Rust, and you need to use RefCell (or UnsafeCell) for this. Am I wrong?
On 04 сент. 2014 г., at 9:17, Clark Gaebel cg.wowus...@gmail.com wrote:
Hey everyone!
Have you ever needed to communicate with the outside world from a rust
application? Do you need to send data through a network interface, or touch
a disk? Then you need Iobufs!
An Iobuf is a nifty abstraction over an array of bytes, which makes writing
things like highly efficient zero-copy speculative network protocol parsers
easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy
lifting.
https://github.com/cgaebel/iobuf
Enjoy,
- Clark
___
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] [ANN] Iobuf
Hey everyone! Have you ever needed to communicate with the outside world from a rust application? Do you need to send data through a network interface, or touch a disk? Then you need Iobufs! An Iobuf is a nifty abstraction over an array of bytes, which makes writing things like highly efficient zero-copy speculative network protocol parsers easy! Any time I need to do I/O, I reach for an Iobuf to do the heavy lifting. https://github.com/cgaebel/iobuf Enjoy, - Clark___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [announce] CloQ
Hi rust-dev! I would like to announce the release of a library I just wrote called CloQ: a queue of closures [1]. It lets you store unboxed closures in a queue, and pop them out to run later. Think of it as a less box-y RingBufBoxFn|FnMut|FnOnce. The only allocations it does is for a single backing array of memory, and the only dependencies are on liballoc and libcore (and libtest for testing). I hope this helps people looking to make performant schedulers when unboxed closures are fully complete. Have fun! - Clark [1] https://github.com/cgaebel/cloq ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Integer overflow, round -2147483648
I think a reasonable middle ground is to have checked operators that look a little funny. Kind of like swift, but in reverse: malloc((number_of_elements +~ 12) *~ size_of::int()) Where adding a ~ to the end of an operator makes it check for overflow. This would certainly look nicer than stuff like: malloc(number_of_elements.checked_add(12).checked_mul(size_of::int())) lying around in low level data structures code. It also keeps the default fast, which is very important. - Clark On Sun, Jun 22, 2014 at 6:25 PM, Daniel Micay danielmi...@gmail.com wrote: On 22/06/14 06:37 AM, Matthieu Monrocq wrote: I am not a fan of having wrap-around and non-wrap-around types, because whether you use wrap-around arithmetic or not is, in the end, an implementation detail, and having to switch types left and right whenever going from one mode to the other is going to be a lot of boilerplate. Instead, why not take the same road than swift and map +, -, * and / to non-wrap-around operators and declare new (more verbose) operators for the rare case where performance matters or wrap-around is the right semantics ? That's the wrong default for a performance-centric language. Even though Rust is a performance conscious language (since it aims at displacing C and C++), the 80/20 rule still applies and most of Rust code should not require absolute speed; so let's make it convenient to write safe code and prevent newcomers from shooting themselves in the foot by providing safety by default, and for those who profiled their applications or are writing hashing algorithms *also* provide the necessary escape hatches. Reducing performance of programs making heavy use of integer arithmetic by 50%+ is unacceptable. This way we can have our cake and eat it too... or am I missing something ? No one will use the language after seeing that it's slower than Java by default. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Nightly docs for Dash
Whoa this is cool stuff. I'll have you know it's useful to at least one person! - Clark On Fri, Jun 13, 2014 at 9:55 PM, Valerii Hiora valerii.hi...@gmail.com wrote: Hi, Being a big fan of offline documentation I've prepared a fresh docset for Dash (zeal, helm-dash, any other compatible software). Here is the link for subscription: dash-feed://https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fnet. vhbit.rust-doc%2FRustNightly.xml It's a beta and has a couple of known issues in it. If there would be enough interest - it could be also integrated with existing buildbots. -- Valerii ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] strings in sets/maps
str and string are equivalent, so use the _equiv version of functions
you need. I'll send a patch to better-document this common use case later
today.
On 2014-06-06 9:40 AM, Diggory Hardy li...@dhardy.name wrote:
Dear List,
I want to use strings as map keys, but couldn't find any mention of this
in my understanding common use-case. The following works but as far as I
understand requires a copy of the potential key to be made to call
`contains()`, is this correct?
let mut set: HashSetString = HashSet::new();
set.insert( x.into_string() );
println!( set contains x: {}, set.contains( x.into_string() ) );
Note: I would normally be storing/testing str types with non-static
lifetime, but I don't think this makes a difference.
I notice that HashSetstr also works (if lifetimes of the inserted
strings are sufficient).
Regards,
Diggory Hardy
___
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] Removing ~foo
Bonus: BoxT, OwnT, HeapT would play nicer with allocators (in terms of syntax) than ~T. On Thu, Apr 24, 2014 at 11:52 AM, Bill Myers bill_my...@outlook.com wrote: Something like this will work, yes. It'll probably look more like: Box::new(*x) This will be described in some of the RFCs that are coming up soon. Awesome! We should really get rid of the ~T syntax in favor of FooT (where Foo = Box, Own, Heap, etc.), since it is deceptively simple for something that should in fact be rarely used. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Anyone in NYC?
So this is happening now: http://www.meetup.com/nyccpp/events/168545012/ It's the C++ meetup, but I'll be giving a short talk on rust. Please RSVP before it fills up! - Clark On Wed, Mar 26, 2014 at 10:30 PM, Carter Schonwald carter.schonw...@gmail.com wrote: I'm in NYC. ya'll should come to the nyc haskell hackathon, there'll be lots of folks there who enjoy strongly typed systemsy code, tis april 4-6, all welcome! www.haskell.org/haskellwiki/Hac_NYC On Wed, Mar 19, 2014 at 9:40 PM, Andrew Morrow andrew.c.mor...@gmail.comwrote: On Mar 18, 2014, at 8:27 PM, Clark Gaebel cg.wowus...@gmail.com wrote: I'm not sure if we have enough people for a reasonable-sized meetup, but I wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to give a short sales pitch presentation if you make this happen. - Clark Hi Clark - I'm sure we can find a way to make that work. The nyccpp meetup has three upcoming talks, but I think those are best left as single topic given the content. But I'd like to get a fourth talk on the calendar and I think a short rust sales pitch would be well received. Let's take this off list and see what we can put together. Thanks, Andrew ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Reminder: ~[T] is not going away
Passing the size to free is currently in a C++14 proposal [1]. It's pretty useful (makes free no slower, might make it faster) and in most code, the size is available on free. I'm not sure it would should be mandatory, but it's definitely useful. [1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3536.html On Wed, Apr 2, 2014 at 3:13 PM, comex com...@gmail.com wrote: On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote: Without a size parameter to `free`, an allocator needs to track the size of allocations manually. It increases the memory overhead, along with adding bookkeeping overhead. Not by very much... If a chunk's header is stored externally, like tcmalloc and Linux slub, there is virtually no memory overhead at the cost of free involving a quick hash table lookup on the address; if it's stored internally, like jemalloc, the overhead is just possibly some page-size-remainder wastage, and free just masks the pointer. Either way, if chunks are ever going to be freed, you need some kind of header to count free slots. I guess knowing the size would help the fast path for free be really simple and even inlined, since it could just swap a fixed thread-local variable. But is that really worth hanging language features on, one way or the other? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
A good plus for rust here is that in general, the idiomatic way to access
arrays in a loop doesn't use bounds checking. For example, to write a dot
product in c++ you'd do this:
double dot(const double* x, const double* y, int len) {
double result = 0.0;
for(int i = 0; i len; ++i)
result += x[i]*y[i];
return result;
}
This isn't very safe, and you don't pay for bounds checks. Fair enough. Now
in rust:
fn dot(x: Vecdouble, y: Vecdouble) - double {
x.iter().zip(y.iter()).fold(0.0, |k, (x, y)| k + x*y)
}
That's safe, and doesn't bounds check. Potential slowness of the closure
aside, this should be just as efficient. In general, your loops won't
directly index arrays.
- Clark
On Fri, Mar 28, 2014 at 8:31 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/28/14 5:25 AM, Tommi wrote:
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but
on a per-operation basis. Having it as a compiler option is too much of a
sledgehammer: often you want some non-performance-critical bounds to be
checked in the name of safety, while you want some bounds checks to be
turned off.
One other argument I can give for a sledgehammer feature like this
is that it can be used as a marketing tool against people who are
worried about performance. You can say to those people: Look, if, at
the end of the day, you decide that you'd rather take raw speed over
safety, then there's this compiler flag you can use to disable all
runtime memory safety checking in your code and get performance on
par with C++.
Well, people who would be persuaded by that would probably also want the
borrow check off, and might want the mutability restrictions off too. It
just wouldn't be the same language.
It might be interesting to try to design a systems language with no regard
for safety and the other modern/functional programming goodies that Rust
has (concepts/traits, algebraic data types, a module system), but Rust just
isn't that language. Safety-by-default is core to its design.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] matching on a few bits in int
I like this! Although I think that match might've been better written `(val
6) 0b11`, but it'd be really nice for the compiler to catch those type
of errors!
- Clark
On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov farcal...@gmail.comwrote:
There's one thing that I often have to deal in embedded code — doing match
on a few bits from an I/O register, which is commonly u32:
let val : u32 = ...;
match (val 0b11) 6 {
0b00 = ...,
0b01 = ...,
0b10 = ...,
_ = {}
}
You can clearly see two problems here: I need to provide a catch-all
match, even if the code guarantees a limited set of values; also I lost
0b11, and there's no warning due to catch all.
Is it possible to make rustc aware of such cases?
What would be totally awesome is some kind of [] operator for ints, that
would extract bits, like that:
match val[6..7] { ... }
Is that something of interest to community? I would be willing to write an
RFC for that, and possibly extend the compiler.
--
Sincerely,
Vladimir Farcaller Pouzanov
http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] matching on a few bits in int
I think it's a great little feature that would set rust apart in the
embedded development space, and perfectly viable to be a compiler feature.
It's not for everyone, but the people that would find it useful would find
it REALLY useful. Rust might even find a niche in safety critical software.
- Clark
On Fri, Mar 28, 2014 at 9:56 AM, Peter Marheine pe...@taricorp.net wrote:
While potentially useful, I don't think this use case is common enough
to warrant being a core feature. This sounds like a good use case for
a macro, though. Something like:
match bitfield!(val, 6..7) {
0b00 = ...,
0b01 = ...,
0b10 = ...,
0b11 = ...
}
could expand to
match (val 6) ((1 2) - 1) {
0b00 = ...,
...
_ = unreachable!()
}
wherein the bitfield! macro either emits either an arbitrary-sized
type (I'm not sure how feasible this is-- LLVM allows arbitrary-width
integers, but I don't know how that would work with rustc) or is able
to verify on its own that the provided patterns are exhaustive for a
n-bit value (in which case the macro must contain the match block as
well).
On Fri, Mar 28, 2014 at 8:04 AM, Clark Gaebel cgae...@uwaterloo.ca
wrote:
I like this! Although I think that match might've been better written
`(val
6) 0b11`, but it'd be really nice for the compiler to catch those
type
of errors!
- Clark
On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov farcal...@gmail.com
wrote:
There's one thing that I often have to deal in embedded code — doing
match
on a few bits from an I/O register, which is commonly u32:
let val : u32 = ...;
match (val 0b11) 6 {
0b00 = ...,
0b01 = ...,
0b10 = ...,
_ = {}
}
You can clearly see two problems here: I need to provide a catch-all
match, even if the code guarantees a limited set of values; also I lost
0b11, and there's no warning due to catch all.
Is it possible to make rustc aware of such cases?
What would be totally awesome is some kind of [] operator for ints, that
would extract bits, like that:
match val[6..7] { ... }
Is that something of interest to community? I would be willing to write
an
RFC for that, and possibly extend the compiler.
--
Sincerely,
Vladimir Farcaller Pouzanov
http://farcaller.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Peter Marheine
Don't Panic
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lightweight failure handling
aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
and hope dearly I haven't committed a social faux pas.
That's interesting. You're kinda looking for exception handling in rust!
Unfortunately the language seems pretty principled in its opinion that
failure should be handled at the task boundary exclusively, and this is a
pretty heavyweight opinion.
This wouldn't be so bad if people would stop fail!ing everywhere! I'm
personally very against the seemingly growing trend of people doing things
like calling unwrap() on options instead of propagating errors up. This
makes accidental failure far, far more common than it should be.
I hope when higher-kinded-types and unboxed closures land, people will
start using a monadic interface to results and options, as this will
hopefully make error propagation less painful. We'll see.
As for your specific case, I don't really have an answer. Is just don't
call fail! an option? Maybe an automatically-inferred #[will_not_fail]
annotation has a place in the world...
- Clark
On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes rustp...@phildawes.net wrote:
Hi Clark,
Thanks for the clarification.
To follow your example, there are multiple 'process_msg()' steps, and if
one fails I don't want it to take down the whole loop.
Cheers,
Phil
On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel cg.wowus...@gmail.comwrote:
Sorry, was on my phone. Hopefully some sample code will better illustrate
what I'm thinking:
loop {
let result : ResultFoo, () = task::try(proc() {
loop {
recv_msg(); // begin latency sensitive part
process_msg();
send_msg (); // end latency sensitive part
}
});
if result.is_ok() {
return result;
} else {
continue;
}
}
This way, you only pay for the try if you have a failure (which should
hopefully be infrequently), and you get nice task isolation!
On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel cg.wowus...@gmail.comwrote:
The main loop of your latency sensitive application.
On Mar 26, 2014 5:56 PM, Phil Dawes rustp...@phildawes.net wrote:
On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel cg.wowus...@gmail.comwrote:
Can't you put that outside your inner loop?
Sorry Clark, you've lost me. Which inner loop?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
If you want sharp scissors, use unsafe indexing. You generally don't need it everywhere, just in your inner loop. Profile, then optimize. Rust gives you the tools needed to optimize where things get hot, but we also like safety by default. - Clark On Thu, Mar 27, 2014 at 10:31 PM, Tommi Tissari rusty.ga...@icloud.comwrote: On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote: forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. I rather feel like Rust lets me use only dull scissors so that I don't accidentally cut myself. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
But I still enjoy the peace of mind that they bring. If I actually need a
piece of code to be manually checked, covered in tests, and benchmarked to
be fast, I'll do that. Then I'll switch to unsafe accesses in my hot paths.
I'm not sure I'm comfortable with people just arbitrarily switching off
bounds checking to exchange an unnoticeable 3% (ballpark) performance
increase for unknown security attack vectors.
For example, do you really want your entire application to be at risk just
because you didn't want bounds checking in some logging code that's never
touch in your fast-paths? That just seems silly to me.
- Clark
On Thu, Mar 27, 2014 at 11:48 PM, Daniel Micay danielmi...@gmail.comwrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity. This
is clear in the design of lifetimes. For example, consider this generic
function:
fn foo'a, T(x: 'a [T]) - 'a T { ... }
The compiler substitutes in the type parameter `T` and generates a
specialized function. However, lifetimes are simply erased after
type-checking - they can simply become 'static without any changes to
the compiled code.
While I'm trying to argue that the programmer should be *free* to test
how fast his code would run without bounds checking, just for the hell of
it. You want to enforce best practices while I want to allow freedom to
choose.
It's not simply a best practice. It's part of Rust's safety contract,
which is a fundamental part of the language. It influences most aspects
of the language's design.
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety boundaries
completely by making `unsafe` and lifetimes a no-op in order to be a
true superset of Rust.
In Frust, indexing slices is considered an unsafe operation. Very little
existing Rust code will compile under Frust, and some previously safe
checked indexing inside existing `unsafe` blocks will cause silent
memory corruption.
I'm not sure which of these dialects you're proposing, but either one
would require a new set of buildbots to run the tests again. Both the
Crust and Frust languages would require many changes to the
documentation and code of the Rust libraries too.
You're free to fork the language if you want to fundamentally change the
basic semantics of the language. I hope it's clear why this isn't going
to be acceptable upstream.
In D, if you put the label safe in the beginning of each module and
compile it with safe flag (and not with noboundscheck flag), then it is
memory safe barring compiler bugs. It doesn't allow you to use pointer
arithmetic or unsafe casts or call unsafe functions, but that's hardly what
I'd call a *crippled* subset of the language.
D doesn't even let you use ranges (iterators) in safe code. There are
barely any safe functions here, and that's true of most of the standard
library:
http://dlang.org/phobos/std_range.html
But the point was that D has a memory safe subset and a noboundscheck
flag which obviously makes the compilation *not* memory safe. And I was
wondering why can't rust have this flag too.
Rust is a memory safe language with a crippled unsafe subset. D is an
unsafe language with a crippled safe subset. Something that may make
sense in the language design for D does not necessarily make sense in
Rust. If you want D, then please go ahead and use D.
In Rust, bounds check failures are not currently viewed as a logic
error. They are a normal runtime failure that can be handled at a task
boundary. You're going to need to convince us to consider them a logic
error *before* you bring the option of a subset of Rust without logic
error checks to the table. The standard library (and others) currently
rely on this being a failure to guarantee safety elsewhere. Take away
this check and there is no safety even in code without array indexing.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] New Rust binary installers and nightlies
Oh hush at least it's https. ...oh wait. :( On Fri, Mar 28, 2014 at 12:05 AM, György Andrasek jur...@gmail.com wrote: curl -s http://www.rust-lang.org/rustup.sh | sudo sh Can we please not recommend people pipe random text from across the internet into a fricking *root shell*? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lightweight failure handling
Can't you put that outside your inner loop?
On Mar 26, 2014 5:15 PM, Phil Dawes rustp...@phildawes.net wrote:
Hello everyone!
I'm interested in using rust for latency sensitive applications. What's
the cheapest way to achieve isolation in a native rt environment?
I'd like to do something like:
let result: ResultFoo, () = task::try(proc() {
... potentually failing code ...
});
but as cheaply as possible and without spawning a thread. Should I attempt
to implement a new type of task that runs immediately in the same OS thread
or is there another way to achieve the same isolation?
Many thanks,
Phil
___
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] Lightweight failure handling
Sorry, was on my phone. Hopefully some sample code will better illustrate
what I'm thinking:
loop {
let result : ResultFoo, () = task::try(proc() {
loop {
recv_msg(); // begin latency sensitive part
process_msg();
send_msg (); // end latency sensitive part
}
});
if result.is_ok() {
return result;
} else {
continue;
}
}
This way, you only pay for the try if you have a failure (which should
hopefully be infrequently), and you get nice task isolation!
On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel cg.wowus...@gmail.com wrote:
The main loop of your latency sensitive application.
On Mar 26, 2014 5:56 PM, Phil Dawes rustp...@phildawes.net wrote:
On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel cg.wowus...@gmail.comwrote:
Can't you put that outside your inner loop?
Sorry Clark, you've lost me. Which inner loop?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Goto statement missing
Use tail call recursion for your FSMs. On Mar 23, 2014 11:57 AM, Jérôme Bartand moije...@gmail.com wrote: Hello fellow Rustians, I noticed that there is no goto statement in Rust yet. Gotos are very useful e.g. for writing FSMs or for code generation and can, if used sensibly, often make code more readable than code with traditional control structures and temporary variables. Can we please have a goto statement in Rust? Please no stupid remarks like goto fail or go to statement considered harmful or similar (the Apple bug was not caused by the goto and Rust has unreachable code detection). Thanks ___ 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] Goto statement missing
I think the biggest case for gotos is jumping out of nested loops. Does rust have a nice way of doing that yet? On Mar 23, 2014 11:57 AM, Jérôme Bartand moije...@gmail.com wrote: Hello fellow Rustians, I noticed that there is no goto statement in Rust yet. Gotos are very useful e.g. for writing FSMs or for code generation and can, if used sensibly, often make code more readable than code with traditional control structures and temporary variables. Can we please have a goto statement in Rust? Please no stupid remarks like goto fail or go to statement considered harmful or similar (the Apple bug was not caused by the goto and Rust has unreachable code detection). Thanks ___ 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] Anyone in NYC?
I'm not sure if we have enough people for a reasonable-sized meetup, but I wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to give a short sales pitch presentation if you make this happen. - Clark On Tue, Mar 18, 2014 at 8:22 PM, Andrew C. Morrow andrew.c.mor...@gmail.com wrote: On Tue, Mar 18, 2014 at 6:31 PM, Patrick Walton pcwal...@mozilla.comwrote: On 3/18/14 3:31 PM, Andrew C. Morrow wrote: I work at MongoDB and we often host technology meetups, including the NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC office. Perhaps we can offer space for an NYC Rust meetup sometime? Or maybe have an NYC C++ meetup about Rust? Let me know if there is interest. That would be awesome. :) Patrick Great! Someone from the NYC Rust community who wants to organize the event should email me privately and we can coordinate from there. Andrew ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Anyone in NYC?
Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone out there? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? With these two things, it should be relatively easy to read code with or without glob imports. On Wed, Mar 12, 2014 at 2:57 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 06:38 AM, Huon Wilson wrote: Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon I think it's still pretty bad. It makes it *very* hard to read the code because it's not clear where the names are coming from. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)
Honestly, I like the 98% solution of grab metadata from every other module in the project except the one you're editing, and use 'text that appears before' completion (or similar heuristics) for things in the module you're editing. It doesn't require a compiler that can parse broken code, and is relatively minimal in work. - Clark On Wed, Mar 12, 2014 at 4:07 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)
Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) On Mar 12, 2014 4:53 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 04:11 PM, Clark Gaebel wrote: Honestly, I like the 98% solution of grab metadata from every other module in the project except the one you're editing, and use 'text that appears before' completion (or similar heuristics) for things in the module you're editing. It doesn't require a compiler that can parse broken code, and is relatively minimal in work. How do you find the type of the value you're trying to complete a method on, like `foo.btab`? You need to be able to identify the type and the in-scope traits. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
I like virtual functions. They're not for everything, and stylistically, traits are almost always a better solution. However, they can be nice to reduce code bloat. See how the LLVM devs managed to share a good amount of code for their SmallVector class thanks to the magic of virtual functions: http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVector.html Not sure if it deserves a whole keyword, but a way to do this efficiently would be nice. - Clark On Tue, Mar 11, 2014 at 3:51 PM, Maciej Piechotka uzytkown...@gmail.comwrote: On Tue, 2014-03-11 at 14:37 -0500, Evan G wrote: ... Why didn't they just extend Number? (Or, at worst, that was a bad design decision on Oracle's part, by choosing to make the Float class final) Either way, I don't see how that's a fault of the language. I don't remember - maybe they had, but it wouldn't solved the problem. And Float is final - and even if it hadn't been it wouldn't solve the problem at all. Assume that Float is not final and they did extended Number. - Platform P provides interface PI and object PO (say Number and Float) - Component A provided and required interface AI and object AO extending PO and implementing AI and PI - Component B provided and required interface BI and object AO extending PO and implementing BI and PI Now you cannot pass object AO to component B as it requires BI. You need either: - Provide adapter from AI to BI (or other way round) which implements AI, BI and PI - Each time convert from AO to BO when you transfer between interfaces In proposed interface there would be only second option due to single inheritance. On the other hand with traits: - Platform P provides interface PI and object PO - Component A provides and requires interface AI and implements AI for PO (there is no need for adding AI as PO is 'open' for trait implementation) - Component B provides and requires interface BI and implements BI for PO (there is no need for adding BI as PO is 'open' for trait implementation) The user needs to do: - Nothing. Everything works out of the box And before you ask - component A and B were 2 different libraries for which the Oracle interfaces were insufficient. Best regards On Tue, Mar 11, 2014 at 2:35 PM, Maciej Piechotka uzytkown...@gmail.com wrote: On Tue, 2014-03-11 at 19:09 +, Bill Myers wrote: I see a proposal to add virtual struct and virtual fn in the workweek meeting notes, which appears to add an exact copy of Java's OO system to Rust. I think however that this should be carefully considered, and preferably not added at all (or failing that, feature gated and discouraged). The core problem of virtual functions (shared by Java's classes, etc.) is that rather than exposing a single public API, they expose two: the API formed by public functions, and the API formed by virtual functions to be overridden by subclasses, and the second API is exposed in an inflexible and unclean way. A much better way of allowing to override part of a struct's behavior is by defining a trait with the overridable functionality, and allowing to pass in an implementation of the trait to the base class, while also providing a default implementation if desired. Another way is to have the subclass implement all the traits that the base class implements, include a field of the base class type, and then direct all non-overridden functionality to the base class (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all non-implemented trait functions by calling the same function on the base class field). These approaches can be combined, as the first approach allows to change the inside behavior of the base class, while the second one allows to put extra behavior around the base class code. The fact that OO using virtual functions (as opposed to traits) is a bad design is one of the crucial steps forward of the design of languages like Go and current Rust compared to earlier OO languages, and Rust should not go backwards on this. Here is a list of issues with virtual functions: 1. Incentive for bad documentation Usually there is no documentation for how virtual functions are supposed to be overridden, and it as awkward to add it since it needs to be mixed with the documentation on how to use the struct 2. Mishmashing multiple unrelated APIs With traits, you could pass in multiple objects to implement
Re: [rust-dev] About RFC: A 30 minute introduction to Rust
As someone looking strongly at rust for things i normally use c++ for, I'm not switching for memory safety. When I need real performance (i.e. When I'm likely to switch to c++), i frequently do a lot of unsafe things in either language. I was sold on rust because it's a syntactically lightweight, fast-building c++, with a real type system (adts!) and hygenic macros. On Mar 4, 2014 2:00 AM, Nathan Myers n...@cantrip.org wrote: On 03/03/2014 09:18 PM, Kevin Ballard wrote: On Mar 3, 2014, at 8:44 PM, Nathan Myers n...@cantrip.org wrote: There are certainly cases in either language where nothing but a pointer will do. The problem here is to present examples that are simple enough for presentation, not contrived, and where Rust has the clear advantage in safety and (ideally) clarity. For such examples I'm going to insist on a competent C++ coder if we are not to drive away our best potential converts. You seem to be arguing that C++ written correctly by a highly-skilled C++ coder is just as good as Rust code, and therefore the inherent safety of Rust does not give it an advantage over C++. And that's ridiculous. That would be a ridiculous position to argue, and this would be a ridiculous place to argue it. Maybe try reading the preceding paragraph again? My concern is that the examples presented in tutorials must be compelling to skilled C++ programmers. If we fail to win them over, the whole project will have been a waste of time. The most skilled C++ programmers know all too well what mistakes show up over and over again. They have lots of experience with proposed solutions that fail. C++ is mature enough now that some are looking for the language that can pick up where C++ leaves off. They wonder if Rust might become that language. (It manifestly is not that language yet.) They are who will need to initiate new, important projects that risk using it, and they are who will explain what it doesn't do well enough yet, and how to fix it -- but only if we can keep their already heavily-oversubscribed interest in the first 30 minutes. A silly example is deadly. Nathan Myers ___ 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] Language to replace C
...and the garbage collector? On Tue, Mar 4, 2014 at 2:56 PM, John Mija jon...@proinbox.com wrote: El 04/03/14 19:51, Tony Arcieri escribió: On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com mailto:jon...@proinbox.com wrote: So, why don't use a simple language but safe like Go? Go isn't a systems programming language. Go is a low-level managed language with a mandatory runtime and garbage collector. Sure! The idea would be to use a modified version of Go where were removed all elements related to the runtime like select, defer, channels, etc. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] More efficient for-loop
That works for the 90% case (pointer/reference types), but it'd be nice to have something more generic that works for everything. - Clark On Tue, Mar 4, 2014 at 4:08 PM, Daniel Micay danielmi...@gmail.com wrote: On 04/03/14 04:04 PM, Clark Gaebel wrote: I like the current interface for iterators. :( Couldn't a similar transformation be done as a special-purpose optimization pass? The check is already eliminated by LLVM in most cases. The exceptions are caused by a fixable limitation: https://github.com/mozilla/rust/issues/9546 -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About RFC: A 30 minute introduction to Rust
This is getting off topic but... C++ has legitimate reasons (no modules, no jit) why it can't be fast-building. Rust has much less. I really hope one day a JIT will be supported to get REALLY fast turnaround times during development. - Clark On Tue, Mar 4, 2014 at 9:31 PM, comex com...@gmail.com wrote: On Tue, Mar 4, 2014 at 6:52 AM, Clark Gaebel cg.wowus...@gmail.com wrote: fast-building If only that were actually true... -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Alternative to Option types
I, for one, would really like to see rust steal named and optional
arguments from OCaml. They're a huge boon to code readability.
On Tue, Feb 25, 2014 at 10:24 PM, Aran Donohue a...@fb.com wrote:
Hey,
I’m not sure how people feel about Option types but there seem to be a
few hundred uses in the rust codebase. Wanted to share an idea we use in
our custom type system (“Hack”) at Facebook to make it a bit nicer to
safely deal with null references. We don’t use Option types directly. I
don’t think this adds any theoretical power or new possible efficiency
gains, it’s mostly for making the code a bit simpler.
Type declarations prefixed with a question mark represent references
which might be null. So ‘?Foo' is somewhat like a shorthand for
'OptionFoo’.
function demo(?Car $maybe_car, Car $car) {…}
We use these like possibly-null pointers. Usually you write an if
statement prior to using a value.
function demo(?Car $maybe_car, Car $car) {
$car-start();
if($maybe_car) { $maybe_car-start(); }
}
Sometimes we use these in combination with a special function
“invariant, an assertion function that throws an exception if a condition
is not met:
function demo(?Car $car) {
invariant($car, ‘Expected non-null car for the demo’);
$car-start();
}
If you forget to check for null one way or the other, the type-checker
complains. This is a static, ahead-of-time check.
function demo(?Car $car) {
$car-start(); // error
}
There are some natural annoying edge cases to be covered.
class Smash {
private ?Car $car;
function demo() {
if ($this-car) {
$this-smashCar();
$this-car-start(); // error
}
}
}
A downside of this approach vs. Option is that code written using
pattern matching over Option is more easily upgraded to code using pattern
matching over Result (or something else).
Anyway, we like this feature and I’d be happy to see it adopted
elsewhere. Tossing it out there as I don’t know anything about the Rust
compiler or how language design decisions get made for it :)
-Aran
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Improving our patch review and approval process (Hopefully)
As an alternative to arbitrary code running on the buildbot, there could
be a b+ which means please try building this which core contributors can
comment with after a quick skim through the patch.
On Wed, Feb 19, 2014 at 3:38 PM, Felix S. Klock II pnkfe...@mozilla.comwrote:
On 19/02/2014 21:12, Flaper87 wrote:
2. Approval Process
[...] For example, requiring 2 r+ from 2 different reviewers instead of
1. This might seem a bit drastic now, however as the number of contributors
grows, this will help with making sure that patches are reviewed at least
by 2 core reviewers and they get enough attention.
I mentioned this on the #rust-internals irc channel but I figured I should
broadcast it here as well:
regarding fractional r+, someone I was talking to recently described their
employer's process, where the first reviewer (who I think is perhaps part
of a priveleged subgroup) assigned the patch with the number of reviewers
it needs so that it isn't a flat every patch needs two reviewers but
instead, someone says this looks like something big/hairy enough that it
needs K reviewers
just something to consider, if we're going to look into strengthening our
review process.
Cheers,
-Felix
On 19/02/2014 21:12, Flaper87 wrote:
Hi all,
I'd like to share some thoughts with regard to our current test and
approval process. Let me break this thoughts into 2 separate sections:
1. Testing:
Currently, all patches are being tested after they are approved. However,
I think it would be of great benefit for contributors - and reviewers - to
test patches before and after they're approved. Testing the patches before
approval will allow folks proposing patches - although they're expected to
test the patches before submitting them - and reviewers to know that the
patch is indeed mergeable. Furthermore, it will help spotting corner cases,
regressions that would benefit from a good discussion while the PR is hot.
I think we don't need to run all jobs, perhaps just Windows, OSx and
Linux should be enough for a first test phase. It would also be nice to run
lint checks, stability checks etc. IIRC, GH's API should allow us to notify
this checks failures.
2. Approval Process
I'm very happy about how patches are reviewed. The time a patch waits
before receiving the first comment is almost 0 seconds and we are spread in
many patches. If we think someone else should take a look at some patch, we
always make sure to mention that person.
I think the language would benefit from a more strict approval process.
For example, requiring 2 r+ from 2 different reviewers instead of 1. This
might seem a bit drastic now, however as the number of contributors grows,
this will help with making sure that patches are reviewed at least by 2
core reviewers and they get enough attention.
I think both of these points are very important now that we're moving
towards 1.0 and the community keeps growing.
Thoughts? Feedback?
--
Flavio (@flaper87) Percoco
http://www.flaper87.com
http://github.com/FlaPer87
___
Rust-dev mailing
listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] let mut - var
'let mut' signals a let binding to a mutable variable...? On Wed, Jan 29, 2014 at 10:26 PM, Samuel Williams space.ship.travel...@gmail.com wrote: Interesting - so if there is no difference, what is the point of let mut ? On 30 January 2014 16:21, Patrick Walton pcwal...@mozilla.com wrote: On 1/29/14 7:20 PM, Samuel Williams wrote: What about constant folding? Surely let mut x = 10 is easier for the compiler to optimise? In less advanced compilers, that may be true. But Rust internally converts everything to SSA, so there is no difference. 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 -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
