Re: [rust-dev] Where to include "access" unix function in Rust API

Hey! Not sure how you got here, but this mailing list is shut down in favor of the rust forum . Feel free to ask your questions there! it looks like you may be looking for https://doc.rust-lang.org/std/fs/struct.Permissions.html though. On Sat, Nov 14, 2015 at 4:29 PM

Re: [rust-dev] Rustaceans - Rust User Groups

I think what Douglas was trying to say is that Simon forgot to include whatever link he was going to put in the email. On Tue, Aug 11, 2015 at 1:18 PM Manish Goregaokar wrote: > users.rust-lang.org is usually good enough for this. You can also email > rust-commun...@googlegroups.com if you want

Re: [rust-dev] Rationale for closing this mailing list

The mailing list is not closed, which is why you can still use it to ask this question. It is merely dead, as conversation split into the two forums, users.rust-lang.org and internal.rust-lang.org. There are configuration options you can set in Discourse to make it work more like a mailing list, i

Re: [rust-dev] Rust discourse visibility [Was: Tail call compatibility]

A little hyperbolic, considering we're all the same rust community. And as far as I know you can set discourse up to work like a mailing list (i.e. email me for every post, email me even if you've seen me recently, don't batch emails, stuff like that) On Sat Dec 27 2014 at 11:54:41 AM wrote: > T

Re: [rust-dev] Confusing way to declare a uint

;int' and 'i' which is different on both sides of > the declaration > > > > > > > > > On Tue, Nov 4, 2014 at 9:27 AM, Evan G wrote: > >> Also, because you have the type information in the variable, there's no >> need to redundantly includ

Re: [rust-dev] Confusing way to declare a uint

Also, because you have the type information in the variable, there's no need to redundantly include it by making it an unsigned number literal—rust can infer that information. On Mon, Nov 3, 2014 at 3:25 PM, Evan G wrote: > Not consistent with what? The syntax for number literals

Re: [rust-dev] Confusing way to declare a uint

Not consistent with what? The syntax for number literals is taken directly from C/C++, and is used by many other languages. On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott wrote: > I was trying to declare a uint using this: > let a: uint = 0_uint; > > But the correct way to declare it is: > let a: ui

Re: [rust-dev] Many-to-many channels

Ahh that makes sense. Thanks both of you. I had an inkling that it was more complicated then I thought, but I wasn't sure. On Sat, Oct 4, 2014 at 6:22 PM, Zaven Muradyan wrote: > On 10/04/2014 01:37 PM, Sean McArthur wrote: > >> Wouldn't that just make the process burn cpu, instead of being able

Re: [rust-dev] Many-to-many channels

Couldn't you just implement that with a loop and a match statement? On Sat, Oct 4, 2014 at 4:25 PM, Calder Coalson wrote: > On closer inspection, mpmc_bounded_queues aren't quite what I want. I > want consumers to block if the queue is empty rather than returning None. > > On Sat, Oct 4, 2014 at

Re: [rust-dev] Can macro use variable values?

The thought is that you should be able to do it with static variables (ones that are known at compile time, like his example) This is known as Compile Time Function Evaluation, I know there's been some work on it, and you can probably search the RFCs to figure out the status currently. On Wed, Se

Re: [rust-dev] On the use of unsafe

Personally, I feel "safety" generalizes pretty well to "any concept that should be called out explicitly as unsafe"--not just memory safety. On Sun, Sep 21, 2014 at 4:12 PM, Daniel Micay wrote: > On 21/09/14 05:57 AM, Simon Sapin wrote: >> On 21/09/14 07:34, Daniel Micay wrote: >>> It's not inten

Re: [rust-dev] Rust Radio - an SDR framework

This is so cool! SDR are awesome. On Thu, Sep 11, 2014 at 8:56 AM, Allen Welkie wrote: > If anyone is interested in software defined radios, I'm starting a project > called Rust Radio (very similar to GNU Radio). Take a look at > https://github.com/awelkie/rustradio. It's still pretty new, but >

Re: [rust-dev] By-value variable captures landing soon

That makes sense. Thanks. On Tue, Aug 19, 2014 at 3:43 PM, Patrick Walton wrote: > On 8/19/14 1:39 PM, Evan G wrote: > >> Is there a way to capture some variables by-value, and others >> by-reference? The 'ref' syntax you talked about seemed to be only for >&

Re: [rust-dev] By-value variable captures landing soon

Is there a way to capture some variables by-value, and others by-reference? The 'ref' syntax you talked about seemed to be only for the whole argument list, but I might have misunderstood. On Aug 19, 2014 3:07 PM, "Patrick Walton" wrote: > On 8/19/14 1:05 PM, Patrick Walton wrote: > >> I've submi

Re: [rust-dev] Accessing Rustup.sh Securely

The rust documentation is generated from the rust repo and source code. On Sun, Aug 3, 2014 at 2:52 PM, Bryce Fisher-Fleig wrote: > Pardon my slowness -- I'm having trouble figuring out where the repo for > doc.rust-lang.org is located so I can make a PR. Can someone point me in > the right dir

Re: [rust-dev] Place for discussions

Has anyone here tried using the Discourse instance in a mailing-list like setup? I know this is one of the target audiences for Discourse installs, there has been some work put in to make this happen, and some communities have started migrating mailman lists to discourse. On Fri, Aug 1, 2014 at 3

Re: [rust-dev] Place for discussions

The correct link is http://discuss.rust-lang.org On Thu, Jul 31, 2014 at 5:15 PM, Brian Anderson wrote: > Here's the current state of official project support for various forums: > > * discourse.rust-lang.org is for *discussion of the development of Rust > itself*. It is maintained by Mozilla.

Re: [rust-dev] Place for discussions

Slightly OT, but there are user setting switches you can set in Discourse that will make it act more like an email list. On Jul 30, 2014 8:08 PM, "Tobias Müller" wrote: > Hello, > > I'm following rust for quite a while, but the discussions are more and more > distributed between different places.

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

Its not about "special casing a user agent" its about archiving duplicate copies of old documents. Right now, everything is crawled off of the current docs, and none of the archived docs are allowed. with this change, the IA would store multiple copies of old documentation—once as the "old" entry f

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

I believe the thought was for when we *can't* modify things like /usr/bin, because the user isn't an administrator. Obviously if we were installing things where they were supposed to go, we wouldn't have a problem finding libraries, would we now? So no-one's proposing we dump a bunch of libraries i

Re: [rust-dev] Rust 0.11.0 Released

I think its just so we parse as a proper semantic version. I know I ran into a problem yesterday where Cargo had to have an extra .0 in my version number to understand my version declaration. On Wed, Jul 2, 2014 at 4:50 PM, Zoltán Tóth wrote: > A new number appeared in the version "0.11.0" comp

Re: [rust-dev] Support for Literate Rust

I'm not sure if this is exactly what you're looking for, but rust already has support for running code examples in documentation. If I remember correctly, all of the code examples in the guide are currently run and tested as part of make test, so this is at least part way towards what you want. O

Re: [rust-dev] Integer overflow, round -2147483648

I don't think I was ever "Railing against the incorrectness of overflow semantics"? I was just pointing out that your (imo pretty hostile?) message about "If you don't require absolute speed, why are you using Rust?" doesn't really ring true. Most C++ programmers don't even require absolute speed.

Re: [rust-dev] Integer overflow, round -2147483648

Because of memory safety? Because you want low-level control without absolute speed? Because of a small memory footprint? Because of having a good async story without giving up a lot of speed? There are plenty of other features to Rust then "absolute speed". Just because that's *your* usecase for

Re: [rust-dev] GADT

I'm pretty sure closure*s are *on the list to be addressed before 1.0 See https://github.com/mozilla/rust/issues?milestone=20&page=1&state=open for a good idea of our roadmap is before 1.0 On Thu, Jun 5, 2014 at 12:09 AM, Suminda Dharmasena wrote: > Some features like 2 closure syntaxes is not

Re: [rust-dev] GADT

The thought-process is (as I know it) A) Taking things out is hard, and breaks code B) 1.0 should be stable, and supported without breakage for a long time C) Adding things is pretty easy, and doesn't break code D) A stable release should happen as soon as is reasonable, to get Rust used and tested

Re: [rust-dev] Detection of early end for Take

Instead of using a for statement, try looping over a custom iterator that returns an Enum. On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra wrote: > Hi guys, > > > Take is an iterator adaptor which cuts off the contained iterator after > some number of elements, always returning None. > > I fi

Re: [rust-dev] Rust by example

> There is one caveat with the new > redirect support worth noting: > GitHub Pages sites are not > automatically redirected when their > repositories are renamed at this > time. Renaming a Pages repository > will continue to break any existing > links to content hosted on the > github.io domain or

Re: [rust-dev] Rust by example

You could just do a quick js redirect... It'd be used for like 2 days, as people read this thread before scrolling down to the bottom. On Apr 25, 2014 10:41 PM, "Jorge Aparicio" wrote: > Hi Daniel, > > It would be great to have the site under (http://rustbyexample.github.io)! > I > got two questi

Re: [rust-dev] Why mod.rs files?

Sublime does this automatically. On Thu, Apr 17, 2014 at 10:56 AM, Niko Matsakis wrote: > On Thu, Apr 17, 2014 at 05:39:15PM +0300, Tommi wrote: > > ...but why not map such modules to files and folders as the following: > > > > foo.rs > > foo/lut.rs > > bar.rs > > bar/lut.rs > > > > ...and have

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

11. True? val[6..7] type syntax would be really cool, and definitely would set rust apart, but so many people are already comfortable with writing bitfields as shifts and masks that we probably want to support that use case well first, and then look at extending it. On Fri, Mar 28, 2014 at 9:5

Re: [rust-dev] Compiling with no bounds checking for vectors?

We don't WANT that though. Haven't you been reading? If we need that flag to perform as well as C++, we'll have failed in our mission. We don't just want to make a safe language: we want to make one safe, fast, and concurrent. Also, as Daniel pointed out, the stdlib already relies heavily on safety