Re: [rust-dev] Mutiplexing I/O within a task
I'm also interesting in some pointers on the best way to achieve this. -- Daniel Fagnan @TheHydroImpulse http://hydrocodedesign.com M: (780) 983-4997 On Sat, Jul 5, 2014 at 9:07 AM, Nat Pryce wrote: > I've been trying to write tasks that wait for both I/O and channel > communication. I've been told that, to maximise communication performance, > channels do not support selecting of both channels and I/O objects. > Therefore a program should signal to a task that is waiting for I/O over > another I/O object, such as a pipe, not by sending a message over a > channel. Fair enough. > > What API should I use to wait for multiple I/O objects within a task? Is > there a runtime-independent API for this? > > And if I write my own I/O abstractions, for example around eventfd on > Linux, what traits (platform specific traits, I imagine) should I implement > to make them work with the runtime-independent I/O select API? > > Sorry if this is already covered in the documentation. I've searched but > not found anything obvious. > > Any help much appreciated. > > --Nat > > > ___ > 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] Partial meeting agenda - older RFCs
I never thought a change like the one I proposed would be accepted. That
was until a few people also supported the idea so it was a shot in the dark.
My motivation for the rfc was the supposed elimination of the ambiguities
that the current syntax has. I mistakenly overlooked the conflict with the
array syntax.
I still think [] is better than <> , but for Rust, there's no convincing
objective argument for such a change. Thus, if the rfc was kept open, it
would be subjective argument leading to nowhere. I definitely don't want to
participate in such argument, because it becomes a waste of time.
I'm convinced that the current syntax needs to stay because we simply don't
get any tangible benefits.
So I closed the rfc.
On Jul 2, 2014 12:19 PM, "Gábor Lehel" wrote:
> Thanks, this is a good step, as is delaying taking actions by a day as
> proposed in the meeting itself.
>
>
> If you have any suggestions for how this regular email or the process in
>> general could be improved, please let us know.
>
>
> Most fundamentally, what I'm wondering is, why do most of the things
> discussed at the meetings need to be discussed separately in the first
> place?
>
> Why not have those discussions directly in the comments for the respective
> RFC PRs? Up to and including leaving comments like "we suggest closing
> this, because {justification}, unless someone convinces us otherwise", "we
> suggest merging this because {justification}", and so on. In an ideal
> world, the meetings could merely ratify the decisions which were already
> evident from the PR discussions themselves. This could also help avoid
> situations where the two discussions end up disjoint in some way, e.g.
> according to this week's meeting notes @pcwalton and @aturon essentially
> recapitulated the exact same debate about the lifetime elision "self rule"
> at the meeting which @aturon and I had previously gone through in the PR
> comments.
>
>
> From the proposed-for-discussion list:
>
> https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for
>> prefix-style type parameter lists - ben0x539
>> Sugary syntax for putting a group of type parameters and their bounds
>> before a group of functions. Motivation is our often unwieldly lists of
>> type parameters.
>> Not much feedback, but mostly positive. Generally for the motivation,
>> rather than the solution.
>> Recommend close in deference to RFC 135 (where clauses) which solve
>> the motivating problem here, along with other issues.
>>
>
> The two are complementary, not substitutive. 122 allows factoring out type
> parameter lists for multiple declarations. 135 allows writing them
> differently.
>
>
> From the meeting itself, because it concerns process:
>
>>
>>- nrc: Do we want to keep this open? It's the <> to [] changes.
>>- acrichto: It's so new, I don't think we should close it.
>>- nrc: Even so, if we're not going to do it, I don't think we should
>>keep it open.
>>
>> I don't see what could have been gained by closing it. Potential
> scenarios if it's left open:
>
> (1) Participants end up convincing each other than the change is not
> worth doing. (This is what ended up happening in this case.)
> (2) Contrary to expectations, a consensus emerges in favor of the change.
> Maybe there is some factor that hadn't been taken into account previously,
> or the arguments of one side end up convincing the other. I think this
> might be useful information to have learned. Then you can evaluate the
> decision on the merits.
>
> Whereas if it's closed early:
>
> (3) People are left with the opinions they already had, and now might
> also have the impression that Mozilla has heavy-handedly shut down the
> debate.
>
> I mean, possibly leave a comment like "Just so you know, we are extremely
> unlikely to do this, but feel free to keep discussing", but I think that
> was clear to everyone at the outset. I just don't see what could have been
> gained by preventing the discussion from playing itself out.
>
> Cheers,
> Gábor
>
>
>
> On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron wrote:
>
>> Hi all, there have recently been some calls to be more open about the
>> Rust meetings, in particular to publish the agenda beforehand. The agenda
>> setting has been quite informal, often not coming together until the
>> meeting starts. Not to say that we won't publish an agenda in the future,
>> but that it is not as easy as it might seem. However, as a step towards
>> that, I will be mailing out the part of the agenda that is set in advance
>> which is the set of (usually older) RFCs where discussion has mostly ceased
>> and where we feel we can make a decision on progress. This email is a
>> relatively new convention in any case. It has been sent to most meeting
>> attendees at the start of the week. From now on, I'll send it to the
>> mailing list instead. If you have comments on the RFCs, please comment on
>> the RFC PR itself, please do not reply to the mailing list.
>>
>> Some expl
Re: [rust-dev] Rust's documentation is about to drastically improve
Oops, forgot to reply to all. RustByExample is not an official documentation source. The manual is severally outdated and should not be used. So there's the curated docs, and generated ones. -- Daniel Fagnan @TheHydroImpulse http://hydrocodedesign.com M: (780) 983-4997 On Wed, Jun 18, 2014 at 10:52 AM, Zoltán Tóth wrote: > One long-standing problem of mine with the docs is that they are split to > multiple sources: tutorial, manual, RustByExample, RustForC++Programmers, > ... . Would be nice to have one central starting location and a strict > hierarchy of links from the center to a searched topic, and then being able > to find every kind of info about the topic there. > > ___ > 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] A few random questions
> With things like try! and the various helper methods on Result/Option, passing errors around is supposed to be easier than in other languages. I haven't done much with it, so I don't know how well it works. I can attest to it working quite well. > What would be Rust alternative, except passing the errors all around parser? Doesn't it grow parser code by at least 50%? I'm actually writing the next version of "Practicality With Rust" covering error handling, as that's a popular request for new comers coming from exception-based, or -1 based languages. The `try!` macro, along with functions like `map_err()` allow you to implement custom error and result types similar to `IoError` and `IoResult`, respectively. [Cargo currently does this, too.]( https://github.com/carlhuda/cargo/blob/master/src/cargo/util/result.rs) -- Daniel Fagnan @TheHydroImpulse http://hydrocodedesign.com M: (780) 983-4997 On Thu, May 29, 2014 at 12:45 PM, comex wrote: > On Thu, May 29, 2014 at 2:32 PM, Oleg Eterevsky > wrote: > > What would be Rust alternative, except passing the errors all around > > parser? Doesn't it grow parser code by at least 50%? > > With things like try! and the various helper methods on Result/Option, > passing errors around is supposed to be easier than in other > languages. I haven't done much with it, so I don't know how well it > works. > > You can also spawn a task for the parser, since the internal parser > data structures don't need to be kept around after failure or > anything; as mentioned in a previous post, a better way to do this > synchronously on the same thread might be added. > > Of course, depending on what you're parsing, you may want to continue > after errors to report further problems, in which case the exception > version wouldn't work 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
[rust-dev] Glob crate?
Writing it here to gauge an interest of the community for a glob crate. If
it seems people are liking the idea, I'll write an RFC for it and send a PR.
I'm guessing the majority of the folks here already know what it is, as
it's pretty universal and used heavily in unix-based environments.
(One *could* use a simple regex, but the interface wouldn't be the most
ideal)
Something like:
```rust
use glob::Glob;
fn main() {
let fn globber = Glob::new(r"foo/**/*.rs");
let list = vec!["foo/hello.rs", "foo/foo2/woot.rs"];
match globber.match(list.get(0)) {
// ...
}
// Or you could match all and you would get a Result> where
// the contents of the vector are only the matched occurrences.
globber.match_all(list);
}
```
Thoughts?
--
Daniel Fagnan
Titan Analytics Inc.
www.titananalytics.com
M: (780) 983-4997
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Splitting The Tutorial/Guides
I'm proposing that we split the tutorial & guides into a much better system. There's a few problems with the current system: * The tutorial is a massive page that seems to have everything stuffed into it.. * Other guides are hard to notice (I sure didn't see the links at the bottom right away). * Other guides aren't made as important as the tutorial. * The user flow is kinda ineffective. I don't think splatting a bunch of the features in a single page is a great starter. I'm thinking that something like [Julia's docs]( http://docs.julialang.org/en/release-0.2/manual/) would serve us better. It would allow us to properly guide the user through each topic separately, instead of having a giant page that one could get overwhelmed reading. Another example is [Github's docs](https://developer.github.com/v3/) Because this is curated docs, there's some flexibility in what we're able to do. Github, for example, uses [Nanoc](http://nanoc.ws/), which is like Jekyll but way more powerful. We could include the ability to compile the nanoc site in the Makefile and we could have rustdoc to still parse the markdown and ensure the examples are correct. This would allow us the opportunity to properly guide the user through each element of Rust and we could split things into sections, such as `Introduction`, `Advanced`, etc... Within the introduction, we could have the 30-minute introduction, along with other material. Thoughts? -- Daniel Fagnan Titan Analytics Inc. www.titananalytics.com M: (780) 983-4997 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust by example
> It would be great to have the site under (http://rustbyexample.github.io) Awesome. I added you as an owner to the organization. > Would I need to transfer the repo to the organization for this? (I suppose > yes) Yes. I deleted my previous repo there, so you can just transfer it to a `rustbyexample.github.io` repo (it has to be that name for Github to pick it up). > Could/should we make the original site redirect to the organization site? (I > wouldn't want people to hit 404 errors) You could just redirect it to the new site afterwards. Shouldn’t be a big deal. Let me know if you have any questions, Daniel On Apr 25, 2014, at 9: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
Re: [rust-dev] Rust by example
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
Re: [rust-dev] Regexp lib
http://commandcenter.blogspot.ca/2011/08/regular-expressions-in-lexing-and.html I can’t seem to find another blog post talking about it (I thought it was Rob Pike who wrote it), but regular expressions are the wrong choice for lexers. I used to be so dependent on regular expressions until I found out how much easier it is to write it by hand. -Daniel On Mar 27, 2014, at 4:41 AM, Stephane Wirtel wrote: > Thanks for your feedback, I was looking for a re lib with named group because > I wanted to implement a minimalist lexer. > > I think I will implement my own lexer by hand without the regex. > > Thanks > >> On 27 mars 2014, at 10:47 AM, Corey Richardson wrote: >> >> There is a ton of discussion on https://github.com/mozilla/rust/issues/3591 >> >>> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath wrote: >>> Hi Stephane, >>> >>> I think there are few libraries, but I'm unsure how complete they are, >>> searching Github for Rust regex yields all possible candidates. >>> >>> Here is the one that seems the most recent >>> https://github.com/ferristseng/regex-rust >>> >>> Sincerely, >>> Daniel >>> >>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel wrote: Hi all, Do you know a lib for the regular expressions? Thank you Stephane ___ 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 >> >> >> >> -- >> http://octayn.net/ > ___ > 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
