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 wrote: >> The mailing list is mostly dead BTW. Consider bringing this up on >> discuss.rust-lang.org instead. > This is the f

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.o

Re: [rust-dev] C interop puzzle

``` let v: Vec = ...;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 wrote: > Hi all, > First time on the mailing list! > I'm having trouble setting a raw void pointer in a stru

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 Sco

Re: [rust-dev] Inheritance / delegation

own. 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

Re: [rust-dev] Inheritance / delegation

icit, 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

Re: [rust-dev] Inheritance / delegation

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 } &g

Re: [rust-dev] Inheritance / delegation

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 Hennin

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 wrote: > On Mon, Sep 29, 2014 at 1:10 PM, Paul Colomiets wrote: >> Hi, >> >> On Mon, Sep 29, 2014 at 11:01 PM, Wink Saville wrote: >> > Nanomsg looks interesting and I'll take a closer look. But I'm >> inte

Re: [rust-dev] Timing vector inserts

gt; } >> >> 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

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 wrote: > On 25/09/14 03:17 PM, Fredrik Widlund wrote: >> http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ >> >> (disclaim

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 wrote: > http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/ > (disclaimer: *not* about comparing lan

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 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 erro

Re: [rust-dev] [ANN] Iobuf

ll 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" wrote: >> >> from_str is

Re: [rust-dev] [ANN] Iobuf

be possible if it's a string constant > in read-only member. > -Kevin >> On Sep 4, 2014, at 1:15 AM, Clark Gaebel wrote: >> >> I think you’re right! Thanks for pointing at UnsafeCell. That seems like >> exactly what I want. It has been fixed. >>

Re: [rust-dev] [ANN] Iobuf

edBuffer(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, a

[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 effici

[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 RingBuf>. The only allocations it does is for a single backing array of mem

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::()) Where adding a ~ to the end of an operator makes it check for overflow. This would certainly look nicer than stuff like

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 wrote: > Hi, > > Being a big fan of offline documentation I've prepared a fresh docset > for Dash (zeal, helm-dash, any other compatible software). > > H

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" wrote: > Dear List, > > > > I want to use strings as map keys, but couldn't find any mention of this >

Re: [rust-dev] Removing ~"foo"

Bonus: Box, Own, Heap would play nicer with allocators (in terms of syntax) than ~T. On Thu, Apr 24, 2014 at 11:52 AM, Bill Myers 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 co

Re: [rust-dev] Anyone in NYC?

#x27;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 >

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/pap

Re: [rust-dev] matching on a few bits in int

rovided 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 > wrote: > > I like this! Although I think that match might've been better written > `(val > >&

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 wrote: > There's one thing that I often have to deal in embedded code —

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) resu

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 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*? > _

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'

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 Tissa

Re: [rust-dev] Lightweight failure handling

gt; > 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 wrote: >

Re: [rust-dev] Lightweight failure handling

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 wrote: > The "main loop" of your

Re: [rust-dev] Lightweight failure handling

The "main loop" of your latency sensitive application. On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: > On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: > >> Can't you put that outside your inner loop? >> > &

Re: [rust-dev] Lightweight failure handling

Can't you put that outside your inner loop? On Mar 26, 2014 5:15 PM, "Phil Dawes" 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 res

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" 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 fo

Re: [rust-dev] Goto statement missing

Use tail call recursion for your FSMs. On Mar 23, 2014 11:57 AM, "Jérôme Bartand" 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 reada

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 wrote: > > > > On Tue

[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] 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" 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 pr

Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)

that can parse broken code, and is relatively minimal in work. - Clark On Wed, Mar 12, 2014 at 4:07 PM, Daniel Micay wrote: > On 12/03/14 03:52 PM, Clark Gaebel wrote: > > > > ​There is no accurate jump-to-definition, type retrieval, docstring > > retrieval or

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

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 wrote

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: ht

Re: [rust-dev] About RFC: "A 30 minute introduction to Rust"

wrote: > On Tue, Mar 4, 2014 at 6:52 AM, Clark Gaebel > 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

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 wrote: > On 04/03/14 04:04 PM, Clark Gaebel wrote: > > I like the current interface

Re: [rust-dev] More efficient for-loop

I like the current interface for iterators. :( Couldn't a similar transformation be done as a special-purpose optimization pass? On Tue, Mar 4, 2014 at 3:51 PM, Tommi wrote: > The problem: > > When you iterate over elements of an Iterator in a for-loop, you > effectively end up checking whether

Re: [rust-dev] Language to replace C

...and the garbage collector? On Tue, Mar 4, 2014 at 2:56 PM, John Mija wrote: > > El 04/03/14 19:51, Tony Arcieri escribió: > >> On Tue, Mar 4, 2014 at 11:43 AM, John Mija > > wrote: >> >> So, why don't use a simple language but safe like Go? >> >> >> Go isn't a

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

Re: [rust-dev] Alternative to Option types

As long as monadic bind is usually inlined away, I'll be happy. Needless closure allocation can add a performance argument against using HOFs. On Sun, Mar 2, 2014 at 12:46 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > indeed. I wonder how many rust idioms will change once HKT is so

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 wrote: > Hey, > > I’m not sure how people feel about Option types but there seem to be a > few hundred uses in the r

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 wrote: > > On 19/02/2014 21:12, Flaper87 wro

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 wrote: > >> On 1/2