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

[Evan G]

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 Jesús Espino  wrote:

> Hi, I need a function that check the permissions of the current user
> in a file (this is the unix access function). In rust i can use the
> unsafe function libc::access, but I think must more sense to have it
> on the File Metadata object or MetadataExt.
>
> I'm thinking about make a pull request to rust with this function
> (calling libc::access) but I want to know if this approach is correct,
> and where to include it.
>
> Regards.
> ___
> 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] Rustaceans - Rust User Groups

[Evan G]

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 to contact the community team
> (we may set up a separate forum for event organizers &c)
>
>
> Thanks,
>
> -Manish Goregaokar
>
> On Tue, Aug 11, 2015 at 7:52 PM, Douglas Campos  wrote:
>
>> and where is this place you mention?
>>
>> On Tue, Aug 11, 2015 at 11:12 AM, Simon Flynn > > wrote:
>>
>>> Hi Rustaceans,
>>>
>>> With the rust-dev mailing list in a semi-abanandonded state, we have
>>> decided to
>>> create a new place where people can gather to talk all thing Rust, but in
>>> particular to help organize local meetups and other gatherings (e.g.
>>> conferences, open days etc).
>>>
>>> Rust on,
>>> Simon
>>>
>>> --
>>> Simon Flynn
>>> https://www.financejobs.co
>>> ___
>>> 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
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Evan G]

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, if you would prefer.

On Sun, May 31, 2015 at 8:09 AM Flavius Aspra  wrote:

> Hi
>
> What are the rationale for closing this mailing list?
>
> Old rusty hackers are used to MLs.
>
> Could you please point me to the discussion where this has been decided?
>
> Regards
> Flavius Aspra
> ___
> 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] Rust discourse visibility [Was: Tail call compatibility]

[Evan G]

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:

> That... breaks my workflow. Wouldn't it make much more sense to talk to
> people on the mailing list about killing the mailing list? It's like people
> went to the vim community to decide whether to cancel emacs development (or
> vice-versa)
>
> Tom
>
>
> El Dec 27, 2014, a las 12:02, "Clark Gaebel" 
> escribió:
>
> 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
>
> ___
> 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] Confusing way to declare a uint

[Evan G]

try `let i = 0i64` :D it just uses the platform to infer the width by
default. Because number literals show up very commonly throughout Rust
code, its important that we keep them short and unobtrusive by default
though, so its normally just recommended to use the short forum unless you
need a smaller/larger type for some reason.

more detail can be found in the rust reference:
http://doc.rust-lang.org/reference.html#number-literals

On Mon, Nov 3, 2014 at 3:37 PM, Jake Scott  wrote:

> I come from a C# background, so the literal syntax is all new to me. I
> know about type inference but I am being explicit to demonstrate what I
> think is a trap for young players :)
>
> let i: i32 = 0_i32; // uses 'i32' on both sides of the declaration
> let l: u64 = 0_u64; // uses 'u64' on both sides of the declaration
>
> let j: int = 0i; // uses '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 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 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: uint = 0u;
>>>>
>>>> Anyone else think that's not consistent?
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> 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] Confusing way to declare a uint

[Evan G]

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 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: uint = 0u;
>>
>> Anyone else think that's not consistent?
>>
>>
>>
>>
>> ___
>> 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] Confusing way to declare a uint

[Evan G]

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: uint = 0u;
>
> Anyone else think that's not consistent?
>
>
>
>
> ___
> 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] Many-to-many channels

[Evan G]

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 to
>> allow other threads to work?
>>
> I would think so, yes. From what I can tell, `std::comm` channels do
> blocking by using `std::task::deschedule`, along with some internal
> housekeeping that seems to be trying to avoid the situation whereby a woken
> task tries to grab some data that has already been `recv()`'d by someone
> else (although, I'm not sure how that would ever happen in a SPSC scenario).
>
>
> ___
> 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] Many-to-many channels

[Evan G]

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 12:21 PM, Calder Coalson 
> wrote:
>
>> That's exactly what I was looking for, thanks!
>>
>> Out of curiosity, why are Rust channels built on top of MPSC queues
>> rather than MPMC queues?
>>
>> On Sat, Oct 4, 2014 at 12:06 PM, Peter Marheine 
>> wrote:
>>
>>> Is there a particular reason you need a Channel rather than some other
>>> primitive? If not, sync::mpmc_bounded_queue will probably do what
>>> you're looking for.
>>
>>
>
> ___
> 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] Can macro use variable values?

[Evan G]

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, Sep 24, 2014 at 11:30 AM, John Clements
 wrote:
>
> On Sep 17, 2014, at 7:04 AM, Daneel Yaitskov  wrote:
>
>> Hi,
>>
>>
>> Does Rust macro have flow control based on a variable value?
>>
>> I didn't find such info here  http://doc.rust-lang.org/guide-macros.html.
>>
>> I'd like to get a macro expading a for loop.
>>
>> doTimes(3, println!(""))
>> =>
>> println!("")
>> println!("")
>> println!("”)
>
> Perhaps I’m misunderstanding you, but in general that’s impossible. 
> Specifically, variable varues aren’t known at runtime. So, for instance, if 
> you wrote
>
> doTimes(x, println!(“”))
>
> … there’s no way (in general) to know the value of ‘x’ until the program is 
> run.
>
> Is there some reason you can’t just use a function call, here?
>
> John Clements
>
> ___
> 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] On the use of unsafe

[Evan G]

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 intended to be used for anything other than memory safety.
>>
>> It’s also used to maintain invariants, such as the bytes inside a String
>> being valid UTF-8: String::push_bytes() is unsafe, but
>> String::push_str() is not.
>
> No, it's not used to maintain invariants unrelated to memory safety.
>
> Strings assume the contents are UTF-8 and violating that invariant would
> violate memory safety.
>
>
> ___
> 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] Rust Radio - an SDR framework

[Evan G]

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
> critiques and contributions are always welcome!
>
> ___
> 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] By-value variable captures landing soon

[Evan G]

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
>> the whole argument list, but I might have misunderstood.
>>
>
> If you need more fine-grained control, you can create references
> explicitly outside the closure, and capture those by-value along with the
> other values you'd like to capture by value.
>
> Patrick
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Evan G]

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 submitted a pull request to make captures in closures *by-value* by
>> default.
>>
>
> Oh, here's the pull request:
>
> https://github.com/rust-lang/rust/pull/16610
>
> And here's the relevant RFC:
>
> https://github.com/rust-lang/rfcs/blob/master/active/0038-
> capture-by-value.md
>
> Related, the unboxed closures RFC:
>
> https://github.com/rust-lang/rfcs/blob/master/active/0044-closures.md
>
> 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

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

[Evan G]

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 direction?
>
>
>
> ___
> 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] Place for discussions

[Evan G]

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:27 PM, Blaine Pace  wrote:

> Not to get the "+1!" ball rolling too far, but I find the mailing list the
> most convenient for keeping up with Rust development as well.
>
>
> On Fri, Aug 1, 2014 at 10:50 AM, Kevin Cantu  wrote:
>
>> Ditto.
>>
>> /me scratches neck beard
>>
>>
>> Kevin
>>
>>
>>
>>
>>
>> On Fri, Aug 1, 2014 at 9:51 AM, Steve Klabnik 
>> wrote:
>>
>>> I actually find mailing lists to have a perfectly serviceable UI, but
>>> I recognize that others don't.
>>>
>>> I'm just really an old man at heart...
>>> ___
>>> 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
>>
>>
>
>
> --
> Blaine Pace
>
>
> ___
> 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] Place for discussions

[Evan G]

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.
> * r/rust is for user discussion. It is maintained by the community.
> * rust-dev is for user discussion. It is maintained by Mozilla. It used to
> be for development discussion but none of the core developers like working
> there because the signal-to-noise is awful and it is unmoderatable.
> * stackoverflow is ultimately where we want users to go for help.
>
> Discourse is an *experiment* to see if it works better than mailing lists
> for having civil conversations. If it works, we may shut off the mailing
> list. It's not clear whether we would extend discourse to general Rust
> discussion or leave reddit and stackoverflow for that.
>
>
>
> On 07/30/2014 06: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.
>> The mailing list was probably first, then with more user attention reddit
>> and StackOverflow, and now the discourse forum.
>>
>> I understand that StackOverflow and Reddit are more for users, not
>> developers, but the discourse forum seems mostly redundant.
>>
>> What's the reason for that split? Is the mailing list deprecated? Which
>> one
>> is the future?
>>
>> I for myself prefer the mailing list because of the gmane NNTP service, I
>> can use my usual usenet software and have all my forums in one place.
>>
>> Tobi
>>
>> ___
>> 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] Place for discussions

[Evan G]

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.
> The mailing list was probably first, then with more user attention reddit
> and StackOverflow, and now the discourse forum.
>
> I understand that StackOverflow and Reddit are more for users, not
> developers, but the discourse forum seems mostly redundant.
>
> What's the reason for that split? Is the mailing list deprecated? Which one
> is the future?
>
> I for myself prefer the mailing list because of the gmane NNTP service, I
> can use my usual usenet software and have all my forums in one place.
>
> Tobi
>
> ___
> 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] robots.txt prevents Archive.org from storing old documentation

[Evan G]

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 for docs.rust-lang.org/ and once as the "new" entry for
docs.rust-lang.org/0.9/

At least that's how I'm understanding the situation. Also, if you're really
interested, all you have to do is a "git checkout 0.9" and run rustdoc.


On Mon, Jul 14, 2014 at 9:30 PM, Isaac Dupree <
m...@isaac.cedarswampstudios.org> wrote:

> On 07/14/2014 09:56 PM, Chris Morgan wrote:
> > On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson 
> wrote:
> >> Can somebody file an issue described exactly what we should do and cc
> me?
> >
> > Nothing. Absolutely nothing.
> >
> > robots.txt rules do not apply to historical data; if archive.org has
> > archived something, the introduction of a new Disallow rule will not
> > remove the contents of a previous scan.
>
> Although that is the robots.txt standard, archive.org does retroactively
> apply robots.txt Disallow rules to already-archived content.
> https://archive.org/about/exclude.php
>
> > It therefore has three months in which to make a scan of a release
> > before that release is marked obsolete with the introduction of a
> > Disallow directive.
> >
> > This is right and proper. Special casing a specific user agent is not
> > the right thing to do. The contents won’t be changing after the
> > release, anyway, so allowing archive.org to continue scanning it is a
> > complete waste of effort.
>
> It's my understanding that archive.org doesn't have the funding to
> reliably crawl everything on the Web promptly.  I agree with the
> principle that "Special casing a specific user agent is not the right
> thing to do." but I also support the Internet Archive's mission.
>
> Another option is a `X-Robots-Tag: noindex` HTTP header, which is more
> robust at banning indexing[1], and it allows archiving (vs.
> `X-Robots-Tag: noindex, noarchive` would disallow it).  It's likely less
> robust from the perspective of keeping our website serving that header
> consistently long-term though.  For HTML files, X-Robots-Tag can also go
> in a  tag in the head.
>
> -Isaac
>
> [1] (Google can still list a robots.txt-disallowed page as a search
> result if many sites it trusts link to that page)
>
> ___
> 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] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Evan G]

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
into /usr/bin.


On Fri, Jul 11, 2014 at 2:22 PM, Daniel Micay  wrote:

> On 11/07/14 03:15 PM, Alex Crichton wrote:
> >> LD_LIBRARY_PATH is not known about by many
> >
> > The install.sh script now recommends adding an entry to this variable
> > if it detects that this is necessary, so it's not *entirely* unknown.
> > This doesn't help, however, if it's considered a bad practice.
> >
> >> 1) Link dependencies of rustc statically to it?
> >
> > For plugins to work, we're required to link libstd and friends
> > dynamically to rustc, so sadly we're require to link rustc itself
> > dynamically.
> >
> >> 2) On Windows the folder of the executable is always searched for
> >> dependencies. Is this the case on Linux too? Then you could just let
> 'make
> >> install' copy everything next to rustc.
> >
> > I do not believe that this is this case for linux or OSX, only for
> windows.
>
> It's not acceptable to dump a bunch of libraries in /usr/bin or
> /usr/local/bin anyway.
>
>
> ___
> 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] Rust 0.11.0 Released

[Evan G]

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" compared to "0.10". This
> looks like a preparation for "0.11.1", ... . Are you starting to support
> these releases with bug-eliminations?
>
> ___
> 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] Support for Literate Rust

[Evan G]

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.


On Sun, Jun 29, 2014 at 2:30 PM, Nathan Typanski 
wrote:

> Literate Rust (.lrs)
> 
>
> I'm wondering if anyone else here has had the thought of supporting
> literate programming in Rust. For those who don't know what this is
> about, a language with good support for the concept is Haskell [1],
> which normally uses bird-style (>) for code blocks. I would propose a
> file extension (.lrs, most likely) that's dedicated to literate
> usage.
>
> If there's some decent feedback for this, and people seem to enjoy it,
> then I will do more research and write a RFC.
>
> [1]: 
>
> ## Who would benefit from this
>
> ### Schools teaching Rust
>
> Universities teaching Rust would be one of my first bets as a user for
> Literate Rust. While literate programming is sometimes too far a
> stretch from reality for production code (which is both a good and bad
> thing), pedagogical gains for literate programming are huge - you can
> run the same code that's teaching you about the language or the
> concept. Essays and writings that feature the code are
> indistinguishable from valid Rust code.
>
> ### Documentation/books/etc.
>
> Another use is general documentation, books about Rust, etc. where
> there are real benefits to having valid code all the way through them.
> When walking through a sample project, the sample project is also the
> code that produced it. This makes documentation easier, since you're
> more able to ensure that your examples compile properly and actually
> run when the compiler updates, etc.
>
> There's also a mental shift when doing literate programming, versus
> just ///'ing within code and whatnot: your primary thought process
> becomes thinking and communicating with the reader, rather than
> working on the code. You focus more on the text and ensuring that it
> makes sense.
>
> ## How this could work with Rustdoc for APIs
>
> API documentation in a literate program would be included as before,
> in rustdoc comments in the output. The internal comments should be the
> default for text, not external API.
>
> As an example, here's some code taken from
> src/libstd/collections/hashmap.rs, and interpreted in a literate style:
>
> > /// Does not initialize the buckets. The caller should ensure they,
> > /// at the very least, set every hash to EMPTY_BUCKET.
> > unsafe fn new_uninitialized(capacity: uint) -> RawTable {
> > let hashes_size = capacity.checked_mul(&size_of::())
> >   .expect("capacity overflow");
> > let keys_size = capacity.checked_mul(&size_of::< K >())
> > .expect("capacity overflow");
> > let vals_size = capacity.checked_mul(&size_of::< V >())
> > .expect("capacity overflow");
> >
>
> Allocating hashmaps is a little tricky. We need to allocate three
> arrays, but since we know their sizes and alignments up front,
> we just allocate a single array, and then have the subarrays
> point into it.
>
> This is great in theory, but in practice getting the alignment
> right is a little subtle. Therefore, calculating offsets has been
> factored out into a different function.
>
> > let (malloc_alignment, hash_offset, keys_offset, vals_offset,
> size) =
> > calculate_offsets(
> > hashes_size, min_align_of::(),
> > keys_size,   min_align_of::< K >(),
> > vals_size,   min_align_of::< V >());
>
> The non-bird text (without the >) is what would normally go in the
> comments for the code. In this case, since it's an API, the thing you
> actually want in your regular documentation is still the rustdoc api
> comments (///), but with the option of generating a literate
> presentation of the code (perhaps by autoconversion to pandoc?) where
> you read the internal comments instead of the API docs as the main
> source of writing.
>
> In other words, literate files can serve as a guide to *developers* of
> the code, not necessarily just to users. Though for non-API material,
> it's useful for both.
>
> ## Editor updates
>
> - Emacs and Vim plugins would have to be updated to understand the new
>   extension, and actually behave properly when editing one of these
>   files. Probably we should have conditional syntax highlighting
>   depending on the block type that we're working on.
>
> ## Rustc
>
> Rustc would need to be able to interpret and understand literate Rust
> code just as well as it can regular code, so that they can link to one
> another without an additional step - otherwise this isn't useful. I
> sho

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

[Evan G]

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.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Evan G]

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 it doesn't mean you should force it on
others.


On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel 
wrote:

> > 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
>
> This is a mistaken assumption. Systems programming exists on the extreme
> end of the programming spectrum where edge cases are the norm, not the
> exception, and where 80/20 does not apply. If you don't require absolute
> speed, why are you using Rust?
>
>
> On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq <
> matthieu.monr...@gmail.com> 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 ?
>>
>> 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.
>>
>> This way we can have our cake and eat it too... or am I missing something
>> ?
>>
>> -- Matthieu
>>
>>
>>
>> On Sun, Jun 22, 2014 at 5:45 AM, comex  wrote:
>>
>>> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay 
>>> wrote:
>>> >> Er... since when?  Many single-byte opcodes in x86-64 corresponding to
>>> >> deprecated x86 instructions are currently undefined.
>>> >
>>> > http://ref.x86asm.net/coder64.html
>>> >
>>> > I don't see enough gaps here for the necessary instructions.
>>>
>>> You can see a significant number of invalid one-byte entries, 06, 07,
>>> 0e, 1e, 1f, etc.  The simplest addition would just be to resurrect
>>> INTO and make it efficient - assuming signed 64 and 32 bit integers
>>> are good enough for most use cases.  Alternatively, it could be two
>>> one-byte instructions to add an unsigned version (perhaps a waste of
>>> precious slots) or a two-byte instruction which could perhaps allow
>>> trapping on any condition.  Am I missing something?
>>> ___
>>> 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
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] GADT

[Evan G]

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 appealing for version 1.0 of
> the language. You should have a different way to specify capture. I send a
> mail reading this also.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] GADT

[Evan G]

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 in production enviroments with production code

*Therefore, *get the language in a state that's as minimal as possible, so
things can be added, but not removed.


On Wed, Jun 4, 2014 at 11:54 PM, Suminda Dharmasena 
wrote:

> Hi,
>
> My thinking is that not to be too premature to get to version 1.0.
>
> My feeling is that there are still quite a few areas where the language
> syntax and features can evolve before version 1.0
>
> Suminda
>
> ___
> 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] Detection of early end for Take

[Evan G]

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 find that I need to detect whether I'm getting None from a Take
> iterator because I've read all of the elements I expected or because the
> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing
> some data from the network and want to detect an early EOM.)
>
>
> This seems like it might be only me, so I'm posing this to the list: if
> there was a function Take::is_done(&self) -> bool, which returned whether
> or not the Take had returned as many elements as it could, would that be
> generally useful?
>
> I'm happy to submit a PR but want to check that this is appropriate for
> the standard library.
>
>
>
> Thanks
>
> Andrew
>
>
>
> --
> Andrew Poelstra
> Mathematics Department, University of Texas at Austin
> Email: apoelstra at wpsoftware.net
> Web:   http://www.wpsoftware.net/andrew
>
> "If they had taught a class on how to be the kind of citizen Dick Cheney
>  worries about, I would have finished high school."   --Edward Snowden
>
>
> ___
> 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] Rust by example

[Evan G]

> 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 custom domains
On Apr 26, 2014 8:23 AM, "Steve Klabnik"  wrote:

> If you move a repo, GitHub will automatically redirect it.
> https://github.com/blog/1508-repository-redirects-are-here
>
> So just delete the new one, then transfer the old one. :magic:
> ___
> 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] Rust by example

[Evan G]

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 questions though:
>
> * Would I need to transfer the repo to the organization for this? (I
> suppose
>   yes)
> * Could/should we make the original site redirect to the organization
> site? (I
>   wouldn't want people to hit 404 errors)
>
> (First time dealing with github pages and github organizations)
>
> On Fri, Apr 25, 2014 at 08:51:41PM -0600, Daniel Fagnan wrote:
> > Awesome work! I actually had an initial rust by example site going (
> http://rustbyexample.github.io/), but I just forgot about it and didn’t
> continue it. This version looks so much better! I’d be happy to give you
> the organization github `rustbyexamples` if you want.
> >
> > Cheers,
> > Daniel
> >
> > On Apr 25, 2014, at 8:25 PM, Jorge Aparicio  wrote:
> >
> > > Hello fellow Rusticans,
> > >
> > > I'm pleased to announce the Rust by example website [1], which is a
> Rust
> > > version of the Go by example website [2], aimed at explaining rustic
> concepts
> > > and giving an overview of the Rust distribution libraries with
> examples.
> > >
> > > Although the website is still a WIP, it already contains 30+ examples
> ranging
> > > from the classic Hello World to a simple client server program,
> covering core
> > > concepts like ownership, borrowing, generics, traits, tasks, etc.
> > >
> > > Be sure to drop by the main repo [3], and let me know what you think
> and/or of
> > > any idea you have to improve it!
> > >
> > > Cheers,
> > >
> > > Jorge Aparicio
> > >
> > > [1] http://japaric.github.io/rust-by-example
> > > [2] https://gobyexample.com
> > > [3] https://github.com/japaric/rust-by-example
> > > ___
> > > 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] Why mod.rs files?

[Evan G]

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 each module informatively named.
>
> This used to be our system and we found it very confusing in practice.
> Basically the code that was logically related to subsystem `foo` was
> divided between two directories, and that caused mental discord. I
> can't exactly explain *why*, but it certainly did, and hence we were
> unhappy enough to switch over to the current system.
>
> Note that you can use the `#[path=...]` attribute to override the
> defaults if you choose.
>
>
> Niko
>
> [1] If you are using emacs, I strongly suggest enabling the uniquify
> settings .  Otherwise you get
> useless buffer names like `mod.rs<2>` rather than `foo/mod.rs` and so
> on. I would hope that vim and SublimeText2 and whatever new-fangled
> editors people are using these days have similar options.
> ___
> 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] matching on a few bits in int

[Evan G]

Whoops, I accidentally sent this to Peter instead of the whole list...

This doesn't even need to be a very hard feature to implement, or require
any new syntax. All that needs to happen is for the compiler to know that "&
0b11" means the only viable options are 00, 01, 10, and 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:55 AM, Evan G  wrote:

> This doesn't even need to be a very hard feature to implement, or require
> any new syntax. All that needs to happen is for the compiler to know that "&
> 0b11" means the only viable options are 00, 01, 10, and 11. True?
>
> val[6..7] type syntax would be really cool, and def 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:43 AM, Peter Marheine wrote:
>
>> On Fri, Mar 28, 2014 at 9:30 AM, Jared Forsyth 
>> wrote:
>> > Is rust's macro system powerful enough to do calculations, such that you
>> > would be able to guarantee that the provided patterns were exhaustive?
>> > From what I've seen, the macro system can mostly just do syntax
>> expansion -
>> > not logic, etc.
>>
>> I haven't had occasion to work with the macro system at all, but it
>> looks like you're correct now that I've reviewed the docs further.
>>
>> Reimplementing exhaustiveness checking in custom code is an ugly idea
>> to me in itself. It looks like the requirement here is actually that
>> the compiler must allow us to represent arbitrary-width integers. With
>> that, we get exhaustiveness checking on bitfields for "free", and the
>> only question is bikeshedding exactly how a user may go about
>> extracting a bitfield.
>> ___
>> 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] Compiling with no bounds checking for vectors?

[Evan G]

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
guarantees, and breaking those would mean you wouldn't be able to use a
large percentage of the stdlib functions, and be stuck writing your own.
On Mar 28, 2014 7:25 AM, "Tommi"  wrote:

> On 28 Mar 2014, at 05:56, Patrick Walton  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++".
>
> ___
> 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