From oren at ben-kiki.org Tue Oct 1 00:23:21 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Tue, 1 Oct 2013 10:23:21 +0300 Subject: [rust-dev] The new format! In-Reply-To: <524A6C0A.3060707@gmail.com> References: <524A67D6.5090709@gmail.com> <524A6C0A.3060707@gmail.com> Message-ID: Yes, both suggestions sound very reasonable. It would also eliminate the need for the Str trait altogether (since the Default fmt function would avoid the allocation). So there would really be no need for most format specifiers, except stuff like controlling the base of integers, etc. On Tue, Oct 1, 2013 at 9:30 AM, Huon Wilson wrote: > I think we should just replace ToStr and the #[deriving] with Default and > a default method .to_str() on that trait, since ToStr's current design > makes it very allocation-heavy (it has to allocate a new ~str for each > subfield, rather than just appending to a common buffer as using the new > format infrastructure would allow). > > > Also, not directly related to this exact discussion, but we could probably > cope with having fewer format specifiers, e.g. format!("{:b}", true) could > just be format!("{}", true), and similarly for `c`. (and even `s` itself!) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dteller at mozilla.com Tue Oct 1 00:39:10 2013 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Tue, 01 Oct 2013 09:39:10 +0200 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: References: Message-ID: <524A7C1E.80005@mozilla.com> On 10/1/13 1:46 AM, Erick Tryzelaar wrote: > Good afternoon all, > > We've got a bunch of the Rust community going to the Mozilla Summit > events this weekend. It'd be great if we could meet for dinner one of > the evenings. If you are going, which city will you be in? Would one day > work better than another? I'll be in Santa Clara, CA, and I'm free all > the evenings. > > -e I'll be in Brussels. Cheers, Yoric -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From dteller at mozilla.com Tue Oct 1 02:17:14 2013 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Tue, 01 Oct 2013 11:17:14 +0200 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: References: Message-ID: <524A931A.5020606@mozilla.com> I opened a public pad for this info: http://bloc-notes.parinux.org/p/Rust-dev_at_Mozilla_Summit See you in Brussels, David On 10/1/13 1:46 AM, Erick Tryzelaar wrote: > Good afternoon all, > > We've got a bunch of the Rust community going to the Mozilla Summit > events this weekend. It'd be great if we could meet for dinner one of > the evenings. If you are going, which city will you be in? Would one day > work better than another? I'll be in Santa Clara, CA, and I'm free all > the evenings. > > -e > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From yati.sagade at gmail.com Tue Oct 1 02:28:16 2013 From: yati.sagade at gmail.com (yati sagade) Date: Tue, 1 Oct 2013 14:58:16 +0530 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: <524A931A.5020606@mozilla.com> References: <524A931A.5020606@mozilla.com> Message-ID: See you folks in Santa Clara :) On Tue, Oct 1, 2013 at 2:47 PM, David Rajchenbach-Teller < dteller at mozilla.com> wrote: > I opened a public pad for this info: > > http://bloc-notes.parinux.org/p/Rust-dev_at_Mozilla_Summit > > See you in Brussels, > David > > On 10/1/13 1:46 AM, Erick Tryzelaar wrote: > > Good afternoon all, > > > > We've got a bunch of the Rust community going to the Mozilla Summit > > events this weekend. It'd be great if we could meet for dinner one of > > the evenings. If you are going, which city will you be in? Would one day > > work better than another? I'll be in Santa Clara, CA, and I'm free all > > the evenings. > > > > -e > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Yati Sagade Software Engineer at mquotient Twitter: @yati_itay | Github: yati-sagade Organizing member of TEDx EasternMetropolitanBypass http://www.ted.com/tedx/events/4933 https://www.facebook.com/pages/TEDx-EasternMetropolitanBypass/337763226244869 -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Tue Oct 1 03:15:16 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 1 Oct 2013 06:15:16 -0400 Subject: [rust-dev] Crate-scoped non-trait implementations In-Reply-To: References: <8D08A1C9948B1B4-1FC4-1D421@webmail-d154.sysops.aol.com> Message-ID: <20131001101452.GA592@Mr-Bennet> It is not clear to me how to apply lexical-based privacy rules to method calls, though I am not opposed. How can we determine if the module where the method is declared is exported? I guess that the idea is simply to climb the module hierarchy, checking that each module between the declaration of the method and some ancestor of the call site is declared as public? It is however also possible for modules to be publicly exported via `pub use` (that was part of the original design of the module system, to permit `pub use` to present a set of "public modules" that is different from the private module hierarchy). Related thread: https://github.com/mozilla/rust/issues/8215#issuecomment-25420622 Niko On Mon, Sep 30, 2013 at 02:36:01PM -0700, Alex Crichton wrote: > From what I've seen, privacy is tricky enough as-is, so I think we > should try to avoid new rules and new keywords. That being said, this > may be possible by just actually applying the rules to implementations > as-is. > > Currently, I believe the privacy of a method is calculated by: "is the > method itself private or not?" and that's it. Arguably we should be > looking at the ancestry of methods as well. If we look at all > ancestors, then you could have pub fns inside priv modules which would > only be usable to your own crate (because they're in your ancestry). > > I'm not sure if the privacy of functions and methods is a relic of a > buggy implementation or performed on purpose, though, so I'd want to > talk it over a bit more before we decide to do something like this. I > do agree, though, that it would be nice to have private functions > scoped to a chunk of the module hierarchy instead of perhaps just one > module. > > On Fri, Sep 27, 2013 at 9:44 PM, SiegeLord wrote: > > Given the proposed privacy resolution rules ( > > https://github.com/mozilla/rust/issues/8215#issuecomment-24762188 ) there > > exists a concept of crate-scope for items: these can be used within the > > implementation of the crate, but are inaccessible from other crates. This is > > easy to do by introducing a private module: > > > > mod private > > { > > pub fn crate_scoped_fn(); > > pub trait CrateScopedTrait; > > pub struct CrateScopedStruct; > > } > > > > It's not clear to me whether or not this is possible (or whether it should > > be) for non-trait implementations. Right now, if I do this: > > > > pub struct S; > > mod private > > { > > impl super::S > > { > > pub fn new() -> super::S { super::S } > > pub fn crate_local_api(&self) -> {} > > } > > } > > > > I find that the associated function can't be used at all within a crate or > > cross crate (issue #9584), while the method resolves in both cases, but does > > not link cross-crate. What should happen in this case? I'd prefer for the > > function and method to resolve within a crate, but not cross crate. > > > > Notably, this is not how trait implementations work today, as those are > > resolved by looking at the location/privacy of the trait and not the > > implementation. I think crate-scoped methods and associated functions are > > very useful though, and it's worthwhile to have a different rule for them. > > > > Or maybe there should be an explicit keyword for the crate scope and not > > bother with these bizarre privacy rules. Or maybe I am missing an alternate > > way to accomplish this? > > > > -SL > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From paul at colomiets.name Tue Oct 1 03:57:57 2013 From: paul at colomiets.name (Paul Colomiets) Date: Tue, 1 Oct 2013 13:57:57 +0300 Subject: [rust-dev] The new format! In-Reply-To: References: Message-ID: Hi, On Tue, Oct 1, 2013 at 9:13 AM, Oren Ben-Kiki wrote: > I know, this is pretty horrible... what is the "right thing" here? Using > {:s} and keep calling .to_str() everywhere? > Not sure if that helps. But in python there are conversion specifiers "{!s}" and "{!r}" which convert to string explicitly, then you can apply ":s" formatting even if the object that is being formatted is not an string e.g.: "{!s:10s}".format(10). So I suggest using conversion specifier to call ".to_str()". -- Paul From danoctavian91 at gmail.com Tue Oct 1 06:43:47 2013 From: danoctavian91 at gmail.com (Dan Cristian Octavian) Date: Tue, 1 Oct 2013 06:43:47 -0700 Subject: [rust-dev] master's project work on rust - ideas Message-ID: Hello, I will be working on my master's degree individual project this year and I was very interested in picking up a Rust-related project. The purpose of this email is to ask for suggestions/proposals for Rust related work that could be done in the context of such a project. I've been following the rust project for quite a while, but didn't find the time to contribute. I noticed that the task to build the interpreter was picked up in a similar fashion. One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. Other ideas I had are in the style of build X (library/kernel/etc.) with Rust. I don't know how relevant this is. Please let me know if you have suggestions. Many thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue Oct 1 07:35:08 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 1 Oct 2013 10:35:08 -0400 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: References: <524A931A.5020606@mozilla.com> Message-ID: I'll be in Toronto! On Tue, Oct 1, 2013 at 5:28 AM, yati sagade wrote: > See you folks in Santa Clara :) > > > On Tue, Oct 1, 2013 at 2:47 PM, David Rajchenbach-Teller < > dteller at mozilla.com> wrote: > >> I opened a public pad for this info: >> >> http://bloc-notes.parinux.org/p/Rust-dev_at_Mozilla_Summit >> >> See you in Brussels, >> David >> >> On 10/1/13 1:46 AM, Erick Tryzelaar wrote: >> > Good afternoon all, >> > >> > We've got a bunch of the Rust community going to the Mozilla Summit >> > events this weekend. It'd be great if we could meet for dinner one of >> > the evenings. If you are going, which city will you be in? Would one day >> > work better than another? I'll be in Santa Clara, CA, and I'm free all >> > the evenings. >> > >> > -e >> > >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> >> >> -- >> David Rajchenbach-Teller, PhD >> Performance Team, Mozilla >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > Yati Sagade > > Software Engineer at mquotient > > > Twitter: @yati_itay | Github: yati-sagade > > Organizing member of TEDx EasternMetropolitanBypass > http://www.ted.com/tedx/events/4933 > > https://www.facebook.com/pages/TEDx-EasternMetropolitanBypass/337763226244869 > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.e.aten at gmail.com Tue Oct 1 07:41:41 2013 From: j.e.aten at gmail.com (Jason E. Aten) Date: Tue, 1 Oct 2013 07:41:41 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian < danoctavian91 at gmail.com> wrote: > One of my first thoughts when I saw the Rust project was to make it > runtimeless. Shortly after that was achieved rather trivially with zero.rs. > I don't know if any major improvement can be done there. > I'm relatively new to Rust, but making Rust runtimeless is not-yet done if I understand the situation; and still seems a worth goal. Then Rust could be used in embedded situations (no OS, so no pre-emption, and cooperative task switching required) or just single-thread only mode. https://github.com/mozilla/rust/issues/9373 https://github.com/mozilla/rust/issues/9568 The new runtime still lacks stdin, so there might be plenty to do there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue Oct 1 07:45:24 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 1 Oct 2013 10:45:24 -0400 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: We've got just the thing for you! Our bug tracker has a tag for "interesting projects": https://github.com/mozilla/rust/issues?labels=A-an-interesting-project Many of these features are things that we'd love to have, but that none of the official developers have time to complete for 1.0. Some of them are rather ambitious, others less so. >From skimming, here are some that stand out: https://github.com/mozilla/rust/issues/7746 https://github.com/mozilla/rust/issues/6750 https://github.com/mozilla/rust/issues/5853 https://github.com/mozilla/rust/issues/3591 (the interesting bit of this one would be compiling regexes to state machines at compile time) https://github.com/mozilla/rust/issues/2235 On Tue, Oct 1, 2013 at 9:43 AM, Dan Cristian Octavian < danoctavian91 at gmail.com> wrote: > Hello, > > I will be working on my master's degree individual project this year and I > was very interested in picking up a Rust-related project. > > The purpose of this email is to ask for suggestions/proposals for Rust > related work that could be done in the context of such a project. > > I've been following the rust project for quite a while, but didn't find > the time to contribute. I noticed that the task to build the interpreter > was picked up in a similar fashion. > > One of my first thoughts when I saw the Rust project was to make it > runtimeless. Shortly after that was achieved rather trivially with zero.rs. > I don't know if any major improvement can be done there. > > Other ideas I had are in the style of build X (library/kernel/etc.) with > Rust. I don't know how relevant this is. > > Please let me know if you have suggestions. > > Many thanks, > > Dan > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Oct 1 11:40:09 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 01 Oct 2013 11:40:09 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: <524B1709.30406@mozilla.com> On 10/01/2013 07:41 AM, Jason E. Aten wrote: > On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian > > wrote: > > One of my first thoughts when I saw the Rust project was to make > it runtimeless. Shortly after that was achieved rather trivially > with zero.rs . I don't know if any major > improvement can be done there. > > > I'm relatively new to Rust, but making Rust runtimeless is not-yet > done if I understand the situation; and still seems a worth goal. This is true, and I believe 'runtimeless' is a misnomer. Rust needs some amount of support at runtime in order to support some features that are key to the language - allocation, unwinding, logging, task-local data in particular, but also key methods on strings and vectors, etc. that you really wouldn't want to live without. The current efforts around zero.rs let you run without a runtime, but not utilize the full language. The real goal here is to factor libstd into subsystems that can be implemented or excluded from the build independently to support different environments. Just understanding the requirements here is a major effort, and I imagine that designing std in such a way that it can run properly on various embedded systems, while not being very difficult to maintain will take a long time and much iteration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmcallister at mozilla.com Tue Oct 1 11:53:41 2013 From: kmcallister at mozilla.com (Keegan McAllister) Date: Tue, 1 Oct 2013 11:53:41 -0700 (PDT) Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: <524B1709.30406@mozilla.com> References: <524B1709.30406@mozilla.com> Message-ID: <831043186.1642667.1380653621161.JavaMail.zimbra@mozilla.com> fwiw zero.rs is now obsolete. Instead you can put #[no_std]; on your crate and then implement just the lang items you use. Here's strcat's example: http://ix.io/8fH keegan ----- Original Message ----- From: "Brian Anderson" To: rust-dev at mozilla.org Sent: Tuesday, October 1, 2013 11:40:09 AM Subject: Re: [rust-dev] master's project work on rust - ideas On 10/01/2013 07:41 AM, Jason E. Aten wrote: On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian < danoctavian91 at gmail.com > wrote: One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs . I don't know if any major improvement can be done there. I'm relatively new to Rust, but making Rust runtimeless is not-yet done if I understand the situation; and still seems a worth goal. This is true, and I believe 'runtimeless' is a misnomer. Rust needs some amount of support at runtime in order to support some features that are key to the language - allocation, unwinding, logging, task-local data in particular, but also key methods on strings and vectors, etc. that you really wouldn't want to live without. The current efforts around zero.rs let you run without a runtime, but not utilize the full language. The real goal here is to factor libstd into subsystems that can be implemented or excluded from the build independently to support different environments. Just understanding the requirements here is a major effort, and I imagine that designing std in such a way that it can run properly on various embedded systems, while not being very difficult to maintain will take a long time and much iteration. _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev From alex at crichton.co Tue Oct 1 12:07:26 2013 From: alex at crichton.co (Alex Crichton) Date: Tue, 1 Oct 2013 12:07:26 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: > One of my first thoughts when I saw the Rust project was to make it > runtimeless. Shortly after that was achieved rather trivially with zero.rs. > I don't know if any major improvement can be done there. As others have said, I don't believe that Rust is currently at the point of being "runtimeless". In addition to what Brian mentioned about not being able to use core-language features easily (vectors, strings, convenient I/O), the story of stacks is also a little sad in runtimeless rust. Currently a "runtimeless" program is still forced to link to librustrt along with our own libmorestack to provide the __morestack function needed by LLVM's segmented stacks. It always seemed a little silly to me that "runtimeless" rust still links to the runtime... Various bits of discussion can be found on https://github.com/mozilla/rust/pull/8955 https://github.com/mozilla/rust/issues/8345 But in summary the story of how stacks are allocated is currently not sufficient for writing something like a kernel module or a kernel itself. I do believe that this is certainly within the realm of possibility, but it certainly needs to be done carefully. I'm not sure if it's too small of a master's project, but I personally consider this to be a fairly substantial undertaking to get right. The various modes discussed in those two issues would be useful to have. This also may not be limited to a runtimeless rust, because the current stack situation is a bit in flux with rust currently. Our segmented stacks are disabled in the new runtime (not implemented yet) and there's some unease about the fixed_stack_segment macro and how it can be more useful. For reference, here's some issues: Runtimeless rust: https://github.com/mozilla/rust/issues/3608 newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 revised stack attributes: https://github.com/mozilla/rust/issues/8822 From j.e.aten at gmail.com Tue Oct 1 12:13:00 2013 From: j.e.aten at gmail.com (Jason E. Aten) Date: Tue, 1 Oct 2013 12:13:00 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: <524B1709.30406@mozilla.com> References: <524B1709.30406@mozilla.com> Message-ID: On Tue, Oct 1, 2013 at 11:40 AM, Brian Anderson wrote: > On 10/01/2013 07:41 AM, Jason E. Aten wrote: > > On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian < > danoctavian91 at gmail.com> wrote: > >> One of my first thoughts when I saw the Rust project was to make it >> runtimeless. Shortly after that was achieved rather trivially with >> zero.rs. I don't know if any major improvement can be done there. >> > > I'm relatively new to Rust, but making Rust runtimeless is not-yet done > if I understand the situation; and still seems a worth[while] goal. > > > This is true, and I believe 'runtimeless' is a misnomer. Rust needs some > amount of support at runtime in order to support some features that are key > to the language - allocation, unwinding, logging, task-local data in > particular, but also key methods on strings and vectors, etc. that you > really wouldn't want to live without. The current efforts around zero.rslet you run without a runtime, but not utilize the full language. The real > goal here is to factor libstd into subsystems that can be implemented or > excluded from the build independently to support different environments. > Just understanding the requirements here is a major effort, and I imagine > that designing std in such a way that it can run properly on various > embedded systems, while not being very difficult to maintain will take a > long time and much iteration. > Seems about the right size/scope of a project for a masters. Not-trivial. But doable with 6-9 months of part-time work, no? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Oct 1 12:21:25 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 1 Oct 2013 15:21:25 -0400 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: <524B1709.30406@mozilla.com> References: <524B1709.30406@mozilla.com> Message-ID: On Tue, Oct 1, 2013 at 2:40 PM, Brian Anderson wrote: > On 10/01/2013 07:41 AM, Jason E. Aten wrote: > > On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian < > danoctavian91 at gmail.com> wrote: > >> One of my first thoughts when I saw the Rust project was to make it >> runtimeless. Shortly after that was achieved rather trivially with >> zero.rs. I don't know if any major improvement can be done there. >> > > I'm relatively new to Rust, but making Rust runtimeless is not-yet done > if I understand the situation; and still seems a worth goal. > > > This is true, and I believe 'runtimeless' is a misnomer. Rust needs some > amount of support at runtime in order to support some features that are key > to the language - allocation, unwinding, logging, task-local data in > particular, but also key methods on strings and vectors, etc. that you > really wouldn't want to live without. The current efforts around zero.rslet you run without a runtime, but not utilize the full language. The real > goal here is to factor libstd into subsystems that can be implemented or > excluded from the build independently to support different environments. > Just understanding the requirements here is a major effort, and I imagine > that designing std in such a way that it can run properly on various > embedded systems, while not being very difficult to maintain will take a > long time and much iteration. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > A minimal application now looks like this: #[no_std]; #[start] fn main(_: int, _: **u8) -> int { 0 } There's no need for zero.rs anymore since you're now able to define the `#[lang]` items on an as-needed basis. You can even compile mixed C/C++/Rust programs with link-time optimization by using `clang`. It's a pain not having the standard library, but with a few intrinsics wrapped it's still a nicer language than C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.e.aten at gmail.com Tue Oct 1 12:25:38 2013 From: j.e.aten at gmail.com (Jason E. Aten) Date: Tue, 1 Oct 2013 12:25:38 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: <524B1709.30406@mozilla.com> Message-ID: On Tue, Oct 1, 2013 at 12:21 PM, Daniel Micay wrote: > A minimal application now looks like this: > >> >> #[no_std]; >> >> #[start] >> fn main(_: int, _: **u8) -> int { 0 } >> >> There's no need for zero.rs anymore since you're now able to define the >> `#[lang]` items on an as-needed basis. You can even compile mixed >> C/C++/Rust programs with link-time optimization by using `clang`. >> >> It's a pain not having the standard library, but with a few intrinsics >> wrapped it's still a nicer language than C. >> > Whoa. Interesting. The mixed C++/Rust part is quite intriguing. Could you demonstrate how you would mix C++ and Rust with clang? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Oct 1 12:28:59 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 1 Oct 2013 15:28:59 -0400 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: <524B1709.30406@mozilla.com> Message-ID: On Tue, Oct 1, 2013 at 3:25 PM, Jason E. Aten wrote: > On Tue, Oct 1, 2013 at 12:21 PM, Daniel Micay wrote: > >> A minimal application now looks like this: >> >>> >>> #[no_std]; >>> >>> #[start] >>> fn main(_: int, _: **u8) -> int { 0 } >>> >>> There's no need for zero.rs anymore since you're now able to define the >>> `#[lang]` items on an as-needed basis. You can even compile mixed >>> C/C++/Rust programs with link-time optimization by using `clang`. >>> >>> It's a pain not having the standard library, but with a few intrinsics >>> wrapped it's still a nicer language than C. >>> >> > Whoa. Interesting. The mixed C++/Rust part is quite intriguing. Could you > demonstrate how you would mix C++ and Rust with clang? > > You use `rustc` to output LLVM IR (with --emit-llvm) and then compile with `clang -flto -O3 foo.cc foo.bc` (you need a version close to Rust's LLVM, 3.3 won't understand the readnone/readonly parameter attributes). If you're calling the Rust functions from C++ or the C++ functions from Rust you do need to mark them as extern "C". It means you can have inlining and whole program optimization between Rust and C/C++ though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue Oct 1 14:28:43 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 1 Oct 2013 17:28:43 -0400 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: <524B1709.30406@mozilla.com> Message-ID: > You use `rustc` to output LLVM IR (with --emit-llvm) and then compile with `clang -flto -O3 foo.cc foo.bc` (you need a version close to Rust's LLVM, 3.3 won't understand the readnone/readonly parameter attributes). If you're calling the Rust functions from C++ or the C++ functions from Rust you do need to mark them as extern "C". It means you can have inlining and whole program optimization between Rust and C/C++ though. This sounds absolutely fascinating. I'd love to see someone write up a blog post with example code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Oct 1 14:59:10 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 01 Oct 2013 14:59:10 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: <524B1709.30406@mozilla.com> Message-ID: <524B45AE.4030206@mozilla.com> On 10/01/2013 12:13 PM, Jason E. Aten wrote: > On Tue, Oct 1, 2013 at 11:40 AM, Brian Anderson > wrote: > > On 10/01/2013 07:41 AM, Jason E. Aten wrote: >> On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian >> > wrote: >> >> One of my first thoughts when I saw the Rust project was to >> make it runtimeless. Shortly after that was achieved rather >> trivially with zero.rs . I don't know if any >> major improvement can be done there. >> >> >> I'm relatively new to Rust, but making Rust runtimeless is >> not-yet done if I understand the situation; and still seems a >> worth[while] goal. > > This is true, and I believe 'runtimeless' is a misnomer. Rust > needs some amount of support at runtime in order to support some > features that are key to the language - allocation, unwinding, > logging, task-local data in particular, but also key methods on > strings and vectors, etc. that you really wouldn't want to live > without. The current efforts around zero.rs let > you run without a runtime, but not utilize the full language. The > real goal here is to factor libstd into subsystems that can be > implemented or excluded from the build independently to support > different environments. Just understanding the requirements here > is a major effort, and I imagine that designing std in such a way > that it can run properly on various embedded systems, while not > being very difficult to maintain will take a long time and much > iteration. > > > Seems about the right size/scope of a project for a masters. > Not-trivial. But doable with 6-9 months of part-time work, no? Possibly, yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Tue Oct 1 23:51:17 2013 From: corey at octayn.net (Corey Richardson) Date: Wed, 2 Oct 2013 02:51:17 -0400 Subject: [rust-dev] "Go 1.1 Function Calls" Message-ID: Saw this on HN: https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub I haven't been following the recent closure discussions much, but what Go is doing might be relevant? From masklinn at masklinn.net Wed Oct 2 00:42:28 2013 From: masklinn at masklinn.net (Masklinn) Date: Wed, 2 Oct 2013 09:42:28 +0200 Subject: [rust-dev] "Go 1.1 Function Calls" In-Reply-To: References: Message-ID: <340A7E2E-5D60-471D-9D31-3F0E02732714@masklinn.net> On 2013-10-02, at 08:51 , Corey Richardson wrote: > Saw this on HN: > https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub > > I haven't been following the recent closure discussions much, but what > Go is doing might be relevant? FWIW, various commenters have noted that this looks like standard closure conversion, which I would expect Rust's team to already be aware of. The only interesting parts would be go's implementation details, and I'm not sure they're of much relevance to Rust. From niko at alum.mit.edu Wed Oct 2 03:12:40 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 2 Oct 2013 06:12:40 -0400 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: <524A157A.3030105@mozilla.com> References: <524A157A.3030105@mozilla.com> Message-ID: <20131002101240.GB12997@Mr-Bennet> On Mon, Sep 30, 2013 at 05:21:14PM -0700, Brian Anderson wrote: > I'm in Brussels. Me too. From niko at alum.mit.edu Wed Oct 2 03:20:37 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 2 Oct 2013 06:20:37 -0400 Subject: [rust-dev] "Go 1.1 Function Calls" In-Reply-To: References: Message-ID: <20131002102037.GC12997@Mr-Bennet> Thanks for the link. I don't think it's too relevant: this is basically an implementation detail for how one chooses to attach the data to a closure pointer. We've opted to make closure "pointers" two words, one for the environment and one for the code pointer. Go seems to be moving to a one word representation where you point to the environment and the environment points to the code. This has some advantages (pointers are smaller) but also some disadvantages (you can't convert a top-level function into a closure without allocation). Niko On Wed, Oct 02, 2013 at 02:51:17AM -0400, Corey Richardson wrote: > Saw this on HN: > https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub > > I haven't been following the recent closure discussions much, but what > Go is doing might be relevant? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Wed Oct 2 04:33:14 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 2 Oct 2013 07:33:14 -0400 Subject: [rust-dev] "Go 1.1 Function Calls" In-Reply-To: <20131002102037.GC12997@Mr-Bennet> References: <20131002102037.GC12997@Mr-Bennet> Message-ID: On Wed, Oct 2, 2013 at 6:20 AM, Niko Matsakis wrote: > Thanks for the link. I don't think it's too relevant: this is > basically an implementation detail for how one chooses to attach the > data to a closure pointer. We've opted to make closure "pointers" two > words, one for the environment and one for the code pointer. Go seems > to be moving to a one word representation where you point to the > environment and the environment points to the code. This has some > advantages (pointers are smaller) but also some disadvantages (you > can't convert a top-level function into a closure without allocation). > > > Niko It seems a global constant would be enough rather than doing an allocation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.e.aten at gmail.com Wed Oct 2 06:46:44 2013 From: j.e.aten at gmail.com (Jason E. Aten) Date: Wed, 2 Oct 2013 06:46:44 -0700 Subject: [rust-dev] Connecting at the Mozilla Summit In-Reply-To: <20131002101240.GB12997@Mr-Bennet> References: <524A157A.3030105@mozilla.com> <20131002101240.GB12997@Mr-Bennet> Message-ID: I'm not a Mozilla employee, but I do live 10 minutes from Santa Clara and would be interested in meeting Rust community folks at summit-related events that are open to non-employees. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.e.aten at gmail.com Wed Oct 2 08:16:22 2013 From: j.e.aten at gmail.com (Jason E. Aten) Date: Wed, 2 Oct 2013 08:16:22 -0700 Subject: [rust-dev] what is stable, what is likely to change, in Rust Message-ID: If I'm standing on the moon, looking at Earth, and watching the sunrise across the globe,I see that there is a daylight line that moves continuously, with darkness on one side and light on the other. This is a metaphor for development. Realizing that the line may not be sharp, and is moving continuously, I'd still like to understand which parts of Rust are currently mostly stable, and which parts are likely to change in the near and somewhat near future. Thanks for your thoughts. Jason -- Jason E. Aten, Ph.D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Oct 2 10:10:21 2013 From: alex at crichton.co (Alex Crichton) Date: Wed, 2 Oct 2013 10:10:21 -0700 Subject: [rust-dev] what is stable, what is likely to change, in Rust In-Reply-To: References: Message-ID: It is my understanding that there aren't a whole lot of portions of the libraries/compiler which are 100% guaranteed to not change from here on out. There are still fairly large language changes in flight (dynamically sized types, closure reform, etc.) which could have large impacts on how the language is used. In addition to a the language stabilizing, there's also the factor of libraries stabilizing. Huon's recent work on adding stability attributes is a fantastic step in this direction though. As Rust moves forward, the general strategy for us is to first enforce usage of the stability attributes to prevent regressions in terms of stability (stable functions calling unstable ones, etc.). After these safeguards are in place, the plan is to closely scrutinize the core modules of libstd. From the inside out, interfaces will be pruned/refactored and flagged as #[stable]. Once an interface is #[stable], the idea is to be very reluctant to accept modifications to existing functions, and functions/modules flagged as such can be thought of as being "backwards compatible" for the time being at least. That being said, I've got a fairly large side project which has been compiling just fine (without modifications) for nearly a month now which is truly a record for rust. The rate of change in the language is far less than it used to be, and library APIs are settling down a little but, but they're still predominately in flux. As usual, Rust is not currently in a "backwards compatible" state for nearly its entire surface area (except for maybe the program "fn main() {}"), but it's certainly a major goal to achieve this within a reasonable time frame. On Wed, Oct 2, 2013 at 8:16 AM, Jason E. Aten wrote: > If I'm standing on the moon, looking at Earth, and watching the sunrise > across the globe,I see that there is a daylight line that moves > continuously, with darkness on one side and light on the other. This is a > metaphor for development. > > Realizing that the line may not be sharp, and is moving continuously, I'd > still like to understand which parts of Rust are currently mostly stable, > and which parts are likely to change in the near and somewhat near future. > > Thanks for your thoughts. > > > Jason > > -- > Jason E. Aten, Ph.D. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pwalton at mozilla.com Wed Oct 2 10:12:10 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 02 Oct 2013 10:12:10 -0700 Subject: [rust-dev] "Go 1.1 Function Calls" In-Reply-To: References: <20131002102037.GC12997@Mr-Bennet> Message-ID: <524C53EA.4080305@mozilla.com> On 10/2/13 4:33 AM, Daniel Micay wrote: > It seems a global constant would be enough rather than doing an allocation. Only for &fn though, since those never get freed. For ~fn we would still need the allocation, so you don't try to call free() on a global constant. (We could do some address space checking to make it work, I guess, but it seems not worth the trouble.) Patrick From oren at ben-kiki.org Wed Oct 2 10:17:40 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Wed, 2 Oct 2013 20:17:40 +0300 Subject: [rust-dev] what is stable, what is likely to change, in Rust In-Reply-To: References: Message-ID: Is there any published roadmap for the "reasonable time frame"? The last quotes I saw when searching were ancient and optimistically hoped that Rust will hit 1.0 by the end of this year :-). Is there a goal of reaching 1.0 at some rough time frame or is Rust going for "it will be done when it is done"? I'm not pushing for either, they both have their dis/advantages - but it would be nice to be explicit about it either way. On Wed, Oct 2, 2013 at 8:10 PM, Alex Crichton wrote: > It is my understanding that there aren't a whole lot of portions of > the libraries/compiler which are 100% guaranteed to not change from > here on out. There are still fairly large language changes in flight > (dynamically sized types, closure reform, etc.) which could have large > impacts on how the language is used. > > In addition to a the language stabilizing, there's also the factor of > libraries stabilizing. Huon's recent work on adding stability > attributes is a fantastic step in this direction though. As Rust moves > forward, the general strategy for us is to first enforce usage of the > stability attributes to prevent regressions in terms of stability > (stable functions calling unstable ones, etc.). After these safeguards > are in place, the plan is to closely scrutinize the core modules of > libstd. From the inside out, interfaces will be pruned/refactored and > flagged as #[stable]. Once an interface is #[stable], the idea is to > be very reluctant to accept modifications to existing functions, and > functions/modules flagged as such can be thought of as being > "backwards compatible" for the time being at least. > > That being said, I've got a fairly large side project which has been > compiling just fine (without modifications) for nearly a month now > which is truly a record for rust. The rate of change in the language > is far less than it used to be, and library APIs are settling down a > little but, but they're still predominately in flux. As usual, Rust is > not currently in a "backwards compatible" state for nearly its entire > surface area (except for maybe the program "fn main() {}"), but it's > certainly a major goal to achieve this within a reasonable time frame. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Wed Oct 2 10:22:20 2013 From: jon.mb at proinbox.com (John Mija) Date: Wed, 02 Oct 2013 18:22:20 +0100 Subject: [rust-dev] Minimal raytracer In-Reply-To: <1015EEFD-4645-4CB5-8151-13FD2B0DC4FA@sb.org> References: <52412EC5.30704@proinbox.com> <5241990A.4070203@gmail.com> <5241C6F1.40102@proinbox.com> <650572A0-BEA5-4009-BB60-9998DDB76233@naml.us> <5242089A.4000403@gmail.com> <1015EEFD-4645-4CB5-8151-13FD2B0DC4FA@sb.org> Message-ID: <524C564C.2010109@proinbox.com> Interesting post about how the author with the help of the Go community has got better performance than C++ version. "After optimizations, the Go ray tracer was 8.4 % faster than a functionally equivalent C++ version when rendering a 4.2 MegaPixel image using a single thread. With multi-threading enabled, the performance gap widened to 76.2 % on a 8 Core machine." https://kidoman.com/programming/go-getter.html El 24/09/13 23:20, Kevin Ballard escribi?: > I ran them myself. Incidentally, the Rust version is absurdly slow if I > don't specify an optimization level. Here's what I got: > > Clang (-O3): 7.99s real > Go (improved version): 9.68s real > Go (original version): 16.73s real > Rust (--opt-level=3): 13.03s real > > (I ran each case 3 times and took the median) > > So if we discard the algorithmically-improved Go, then we get > > 1) C++: 7.99s > 2) Rust: 13.02s > 3) Go: 16.73s > > I'm curious as to what difference using gccgo would make, but I didn't > try (as I don't have GCC). > > -Kevin > > On Sep 24, 2013, at 2:48 PM, Huon Wilson > wrote: > >> On 25/09/13 04:13, Tim Kuehn wrote: >>> To make it a "fair" fight, I converted the Go and C++ versions to >>> trace "Rust" instead. These are my results on my Macbook Pro: >>> >>> === RUST === >>> $ rustc -O bin.rs >>> $ time ./bin > rrays.ppm >>> >>> real0m14.472s >>> user0m14.102s >>> sys0m0.365s >>> >>> === GO === >>> $ go build main.go >>> $ time ./main > grays.ppm >>> >>> real0m13.928s >>> user0m13.914s >>> sys0m0.020s >>> >>> === C++ === >>> $ gcc -O crays.cpp >>> $ time ./a.out > crays.ppm >>> >>> real0m10.800s >>> user0m10.794s >>> sys0m0.005s >>> >>> === RANKINGS === >>> 1) C++ : 10.8s >>> 2) Go : 13.9s >>> 3) Rust : 14.5s >>> >>> >> >> This surprises me a lot (the fact that Go is (1) faster than Rust, (2) >> it's only 20% slower than C++, compared to 150+% originally), so I >> investigated, and found that the Go is "cheating" with an algorithmic >> improvement: >> https://github.com/kid0m4n/gorays/commit/249f229ba8c769c38d7dc018acfdf29cc86d6e43 >> >> If it's possible, could we re-run the benchmarks with the commit >> before that? >> >> Huon >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pwalton at mozilla.com Wed Oct 2 10:33:23 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 02 Oct 2013 10:33:23 -0700 Subject: [rust-dev] Minimal raytracer In-Reply-To: <524C564C.2010109@proinbox.com> References: <52412EC5.30704@proinbox.com> <5241990A.4070203@gmail.com> <5241C6F1.40102@proinbox.com> <650572A0-BEA5-4009-BB60-9998DDB76233@naml.us> <5242089A.4000403@gmail.com> <1015EEFD-4645-4CB5-8151-13FD2B0DC4FA@sb.org> <524C564C.2010109@proinbox.com> Message-ID: <524C58E3.5020004@mozilla.com> On 10/2/13 10:22 AM, John Mija wrote: > Interesting post about how the author with the help of the Go community > has got better performance than C++ version. > > "After optimizations, the Go ray tracer was 8.4 % faster than a > functionally equivalent C++ version when rendering a 4.2 MegaPixel image > using a single thread. With multi-threading enabled, the performance gap > widened to 76.2 % on a 8 Core machine." > > https://kidoman.com/programming/go-getter.html The only honest conclusion of this exercise that I can see is that a program with a superior algorithm compiled with a non-optimizing compiler (6g/8g) can beat a naive program compiled with an optimizing compiler (GCC). That's not an interesting conclusion. Patrick From leefhuo at gmail.com Wed Oct 2 19:50:31 2013 From: leefhuo at gmail.com (leef huo) Date: Thu, 3 Oct 2013 10:50:31 +0800 Subject: [rust-dev] about unicode problem Message-ID: I want to print "hello world, ????"(Chinese)to the console, but the result is garbled(messy code), the following code where the problem is? fn main() { let s=~"hello,????"; println(s); } Should output:hello,???? but it print " hello,?????? " to the console. OS : windows rust : 0.8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Wed Oct 2 19:51:33 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Thu, 03 Oct 2013 12:51:33 +1000 Subject: [rust-dev] about unicode problem In-Reply-To: References: Message-ID: <524CDBB5.1060508@gmail.com> On 03/10/13 12:50, leef huo wrote: > I want to print "hello world, ??"(Chinese)to the console, but the > result is garbled(messy code), the following code where the problem is? > fn main() { > let s=~"hello,??"; > println(s); > } > Should output:hello,?? > > but it print " hello,??? " to the console. > Is the file saved as UTF-8, and is your console using UTF-8? Rust essentially only supports UTF-8 for strings at the moment. Huon -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at chrismorgan.info Wed Oct 2 20:24:14 2013 From: me at chrismorgan.info (Chris Morgan) Date: Thu, 3 Oct 2013 13:24:14 +1000 Subject: [rust-dev] about unicode problem In-Reply-To: References: Message-ID: When you're using Command Prompt, you're basically stuck. It doesn't have any meaningful Unicode support. See also http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how On Thu, Oct 3, 2013 at 12:50 PM, leef huo wrote: > I want to print "hello world, ????"(Chinese)to the console, but the result is > garbled(messy code), the following code where the problem is? > fn main() { > let s=~"hello,????"; > println(s); > } > Should output:hello,???? > > but it print " hello,?????? " to the console. > > OS : windows > rust : 0.8 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From corey at octayn.net Wed Oct 2 23:57:52 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 3 Oct 2013 02:57:52 -0400 Subject: [rust-dev] "Continuous Documentation" Message-ID: Hey all, As of https://github.com/alexcrichton/rust/commit/d06043ba0b4f0ed871e5374aa0d6b37fa170dfc6, rustdoc will have cross-crate hyperlinking again. As part of my "torture my CPU as much as possible" initiative, I'd like to extend an offer to every library author that if they want fully interhyperlinked documentation, I'd be willing to setup a little VM that does so, pulling daily and using the rust-git package strcat provides. If you want in on the action, send me an email with a link to your repo. This is an interim step towards https://github.com/mozilla/rust/issues/1642 From corey at octayn.net Thu Oct 3 00:06:26 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 3 Oct 2013 03:06:26 -0400 Subject: [rust-dev] "Continuous Documentation" In-Reply-To: References: Message-ID: Additionally, I can set it up so that when a build *fails*, it opens (at most one) an issue with the build log and the rustc SHA. Should help make maintaining libraries more effortless. On Thu, Oct 3, 2013 at 2:57 AM, Corey Richardson wrote: > Hey all, > > As of https://github.com/alexcrichton/rust/commit/d06043ba0b4f0ed871e5374aa0d6b37fa170dfc6, > rustdoc will have cross-crate hyperlinking again. As part of my > "torture my CPU as much as possible" initiative, I'd like to extend an > offer to every library author that if they want fully interhyperlinked > documentation, I'd be willing to setup a little VM that does so, > pulling daily and using the rust-git package strcat provides. > > If you want in on the action, send me an email with a link to your repo. > > This is an interim step towards https://github.com/mozilla/rust/issues/1642 From smadhueagle at outlook.com Thu Oct 3 01:46:10 2013 From: smadhueagle at outlook.com (Madhu Srinivasan) Date: Thu, 3 Oct 2013 08:46:10 +0000 Subject: [rust-dev] rustpkg behavior In-Reply-To: References: , Message-ID: Thanks Tim! I appreciate your response. I'll try out your suggestions. Madhu > Date: Mon, 30 Sep 2013 18:11:36 -0700 > Subject: Re: [rust-dev] rustpkg behavior > From: catamorphism at gmail.com > To: smadhueagle at outlook.com > CC: rust-dev at mozilla.org > > On Thu, Sep 19, 2013 at 3:19 PM, Madhu Srinivasan > wrote: > > hi fellow rusters, > > > > I understand that rustpkg is under heavy development and not complete. > > Having said that, I'd like to know if the following error (w.r.t. rustpkg > > finding external crates and linking correctly with them) is within it's > > normal operating parameters :). > > > > The rust code in question: https://github.com/smadhueagle/rustlings > > (It is a series of example rust programs) > > The external crate that it refers to: https://github.com/smadhueagle/rustils > > > > Following the steps in Readme.md on the rustlings repo and building the > > simplespawn crate results in the following error: > > > > kl-13572:rustlings smadhueagle$ rustpkg build simplespawn > > WARNING: The Rust package manager is experimental and may be unstable > > task failed at 'Unhandled condition: nonexistent_package: > > (package_id::PkgId{path: std::path::PosixPath{is_absolute: false, > > components: ~[~"rustils"]}, short_name: ~"rustils", version: NoVersion}, > > ~"supplied path for package dir does not exist, and couldn't interpret it as > > a URL fragment")', /private/tmp/rust-nVcw/src/libstd/condition.rs:43 > > task failed at 'killed by linked failure', > > /private/tmp/rust-nVcw/src/libstd/rt/kill.rs:627 > > Sorry for overlooking this email until now. The issue here is that you > need to either write: > > extern mod rustils = "github.com/smadhueagle/rustils"; > > instead of `extern mod rustils;`, in the code that uses it (and in > this case you don't need the `rustpkg install` step), or set your > RUST_PATH to: > > $TOP/rustlings/.rust/github.com/smadhueagle/rustils-0.1 > > where $TOP is the directory that contains the `rustlings` directory. > > I tested the latter option with rustpkg as built from 7ddcd2, and it worked. > > Feel free to ask again here if you have more questions (and I'll try > to answer them sooner :-) > > Cheers, > Tim > > > > > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Being queer is not about a right to privacy; it is about the freedom > to be public, to just be who we are." -- anonymous, June 1990 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cadencemarseille at gmail.com Thu Oct 3 05:32:10 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Thu, 3 Oct 2013 08:32:10 -0400 Subject: [rust-dev] `extern mod` declarations Message-ID: Hello, I just switched over the rust-pcreproject's directory structure to a rustpkg workspace (as documented at http://static.rust-lang.org/doc/master/rustpkg.html). Now I am trying to run a simple Rust program using the pcre module, but I am experiencing some trouble. Both: extern mod pcre; and: extern mod pcre = "github.com/cadencemarseille/rust-pcre"; result in the error message: error: can't find crate for `pcre` To compile, I need to supply an -L flag to the full rustpkg library output folder like so: rustc -L ~/.rust/pcre/lib/x86_64-apple-darwin -o pcredemo~ pcredemo.rs How do I set up my local dev env so that this "just works"? Cadence -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Oct 3 09:31:00 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 3 Oct 2013 12:31:00 -0400 Subject: [rust-dev] `extern mod` declarations In-Reply-To: References: Message-ID: It looks like you setup your workspace wrong. A quick fix is: cd ~/.rust; rustpkg init; cd src; mkdir -p github.com/cadencemarseille; cd github.com/cadencemarseille; git clone https://github.com/cadencemarseille/rust-pcre.git; rustpkg build rust-pcre; On Thu, Oct 3, 2013 at 8:32 AM, Cadence Marseille wrote: > Hello, > > I just switched over the rust-pcre project's directory structure to a > rustpkg workspace (as documented at > http://static.rust-lang.org/doc/master/rustpkg.html). Now I am trying to > run a simple Rust program using the pcre module, but I am experiencing some > trouble. > > Both: > > extern mod pcre; > > and: > > extern mod pcre = "github.com/cadencemarseille/rust-pcre"; > > result in the error message: > error: can't find crate for `pcre` > > To compile, I need to supply an -L flag to the full rustpkg library output > folder like so: > > rustc -L ~/.rust/pcre/lib/x86_64-apple-darwin -o pcredemo~ pcredemo.rs > > How do I set up my local dev env so that this "just works"? > > Cadence > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From jhaberkucharsky at cmu.edu Thu Oct 3 12:06:44 2013 From: jhaberkucharsky at cmu.edu (Jesse Haber-Kucharsky) Date: Thu, 3 Oct 2013 15:06:44 -0400 Subject: [rust-dev] `extern mod` declarations In-Reply-To: References: Message-ID: Cadence, If the library's main source file is in src/pcre/lib.rs and the the demo application's main source file is in src/pcredemo/main.rs, then I believe that executing "rustpkg install pcre" and then "rustpkg install pcrememo" will build and install the library and executable into the "lib" and "bin" directories, respectively. >From within src/pcredemo/main.rs, you should be able to write "extern mod pcre" and everything will be found correctly. I wrote a very small Rust tcp server to figure this out for myself which also consists of a workspace with multiple packages. You may find it useful as an example for managing the rustpkg layout: https://github.com/hakuch/LampShade (assuming that I'm following the recommended conventions correctly). -- Jesse On Thu, Oct 3, 2013 at 12:31 PM, Corey Richardson wrote: > It looks like you setup your workspace wrong. A quick fix is: > > cd ~/.rust; rustpkg init; cd src; mkdir -p > github.com/cadencemarseille; cd github.com/cadencemarseille; git clone > https://github.com/cadencemarseille/rust-pcre.git; rustpkg build > rust-pcre; > > > > On Thu, Oct 3, 2013 at 8:32 AM, Cadence Marseille > wrote: > > Hello, > > > > I just switched over the rust-pcre project's directory structure to a > > rustpkg workspace (as documented at > > http://static.rust-lang.org/doc/master/rustpkg.html). Now I am trying > to > > run a simple Rust program using the pcre module, but I am experiencing > some > > trouble. > > > > Both: > > > > extern mod pcre; > > > > and: > > > > extern mod pcre = "github.com/cadencemarseille/rust-pcre"; > > > > result in the error message: > > error: can't find crate for `pcre` > > > > To compile, I need to supply an -L flag to the full rustpkg library > output > > folder like so: > > > > rustc -L ~/.rust/pcre/lib/x86_64-apple-darwin -o pcredemo~ pcredemo.rs > > > > How do I set up my local dev env so that this "just works"? > > > > Cadence > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgorbe at slackito.com Thu Oct 3 12:22:05 2013 From: jgorbe at slackito.com (Jorge Gorbe) Date: Thu, 03 Oct 2013 21:22:05 +0200 Subject: [rust-dev] Library for reading/writing Zip files Message-ID: <524DC3DD.3030801@slackito.com> Hi everyone, I'm writing a library for reading and writing Zip archives in Rust, as a learning project, and I would love to hear what you think about it. https://github.com/slackito/zip At the moment, the only things you can do with it are listing the contents of an archive and extract files from it (as long as they are either uncompressed or deflated, the flate module came in handy :D), but I'm planning on adding write support soon, and then decide if I want to support more advanced features such as ZIP64, more compression methods, etc, or move to another thing. As I said, I'm learning Rust as I code this, so any kind of feedback is welcome. Regards, Jorge From thadguidry at gmail.com Thu Oct 3 12:25:51 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 3 Oct 2013 14:25:51 -0500 Subject: [rust-dev] Library for reading/writing Zip files In-Reply-To: <524DC3DD.3030801@slackito.com> References: <524DC3DD.3030801@slackito.com> Message-ID: If an LZO library is not done already, that would be a good next step. -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Oct 3 12:26:44 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 3 Oct 2013 15:26:44 -0400 Subject: [rust-dev] Library for reading/writing Zip files In-Reply-To: References: <524DC3DD.3030801@slackito.com> Message-ID: I had bindings to LZO and LZ4 at one point, but they were ad-hoc and that branch is long gone. On Thu, Oct 3, 2013 at 3:25 PM, Thad Guidry wrote: > If an LZO library is not done already, that would be a good next step. > > -- > -Thad > Thad on Freebase.com > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From alex at crichton.co Thu Oct 3 12:42:15 2013 From: alex at crichton.co (Alex Crichton) Date: Thu, 3 Oct 2013 12:42:15 -0700 Subject: [rust-dev] Library for reading/writing Zip files In-Reply-To: <524DC3DD.3030801@slackito.com> References: <524DC3DD.3030801@slackito.com> Message-ID: That's pretty awesome! I love seeing bindings and utilities starting to get written for rust. Perhaps some sort of wiki-style page is in order for keeping track of all these libraries... It'd be cool if opening an archive would behave like a filesystem where I could do something like: let zip = ZipReader::new(...); let filea = zip.open_reader(Path("my/awesome/file.txt")); let fileb = zip.open_reader(Path("my/other/awesome/file.txt")); Right now open_reader requires &mut self which prevents more than one borrow at a time, but perhaps that could become &self. Also, I've always found writing tests to be an excellent way of test-driving a library, and it's even easier to run them now that fgilcher from reddit set up a nightly ppa for rust! Travis-ci integrates excellently with github and http://www.reddit.com/r/rust/comments/1ni84a/running_rust_tests_on_travis_ci/ has all the good details. As soon as I saw that I put my own splay tree implementation in rust on travis and it worked beautifully! First we get rustpkg awesomeness, then we get travis awesomeness, and now we're getting awesome projects like this. It's like Christmas is coming early! On Thu, Oct 3, 2013 at 12:22 PM, Jorge Gorbe wrote: > Hi everyone, > > I'm writing a library for reading and writing Zip archives in Rust, as a > learning project, and I would love to hear what you think about it. > > https://github.com/slackito/zip > > At the moment, the only things you can do with it are listing the contents > of an archive and extract files from it (as long as they are either > uncompressed or deflated, the flate module came in handy :D), but I'm > planning on adding write support soon, and then decide if I want to support > more advanced features such as ZIP64, more compression methods, etc, or move > to another thing. > > As I said, I'm learning Rust as I code this, so any kind of feedback is > welcome. > > Regards, > Jorge > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Thu Oct 3 15:07:37 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 3 Oct 2013 15:07:37 -0700 Subject: [rust-dev] Rust Meetup/Dinner in Mountain View on 10/14 Message-ID: Hey all! I'm happy to announce the first San Francisco Bay Area Rust meetup at the Tied House on Columbus Day, Monday, October 14th, at 7pm: http://www.meetup.com/Rust-Bay-Area/events/143328072/ I hope you can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at chrismorgan.info Thu Oct 3 20:04:47 2013 From: me at chrismorgan.info (Chris Morgan) Date: Fri, 4 Oct 2013 13:04:47 +1000 Subject: [rust-dev] about unicode problem In-Reply-To: References: Message-ID: No, there really is nothing we can do about it while you continue to use Command Prompt. Using a different shell is the only way to get it to work properly. (And that itself may potentially introduce other issues.) [Note also that you need to reply to all for your response to be on the list. You sent it just to me.] On Fri, Oct 4, 2013 at 11:36 AM, leef huo wrote: > Chris Morgan , thanks . > After change the windows code page to 65001,and use Lucida console fonts, > there was a slight improvement, the output becomes: > but still have problems,it is not entirely correct. > > Are there a solution now or in the future that makes the rust code(unicode) > in the default windows command line to work properly? > > > On Thu, Oct 3, 2013 at 11:24 AM, Chris Morgan wrote: >> >> When you're using Command Prompt, you're basically stuck. It doesn't >> have any meaningful Unicode support. >> >> See also >> http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how >> >> On Thu, Oct 3, 2013 at 12:50 PM, leef huo wrote: >> > I want to print "hello world, ????"(Chinese)to the console, but the result >> > is >> > garbled(messy code), the following code where the problem is? >> > fn main() { >> > let s=~"hello,????"; >> > println(s); >> > } >> > Should output:hello,???? >> > >> > but it print " hello,?????? " to the console. >> > >> > OS : windows >> > rust : 0.8 >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > > > From me at kevincantu.org Thu Oct 3 21:07:34 2013 From: me at kevincantu.org (Kevin Cantu) Date: Thu, 3 Oct 2013 21:07:34 -0700 Subject: [rust-dev] Rust Meetup/Dinner in Mountain View on 10/14 In-Reply-To: References: Message-ID: Also, in the spirit of this [1] and this [2], if you want a hand, just let me know and I'm sure we can work something out! Kevin [1] http://conway.rutgers.edu/~ccshan/wiki/blog/posts/haskell2013/ [2] http://auntiepixelante.com/?p=2152 On Thu, Oct 3, 2013 at 3:07 PM, Erick Tryzelaar wrote: > Hey all! > > I'm happy to announce the first San Francisco Bay Area Rust meetup at the > Tied House on Columbus Day, Monday, October 14th, at 7pm: > > http://www.meetup.com/Rust-Bay-Area/events/143328072/ > > I hope you can make it! > > -Erick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From cadencemarseille at gmail.com Fri Oct 4 04:39:55 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Fri, 4 Oct 2013 07:39:55 -0400 Subject: [rust-dev] `extern mod` declarations In-Reply-To: References: Message-ID: Hello Corey, Thank you for these instructions. The only thing I did differently is instead of the last step: cd ~ rustpkg install 'github.com/cadencemarseille/rust-pcre' Then I can import via extern mod pcre = " github.com/cadencemarseille/rust-pcre"; Cadence On Thu, Oct 3, 2013 at 12:31 PM, Corey Richardson wrote: > It looks like you setup your workspace wrong. A quick fix is: > > cd ~/.rust; rustpkg init; cd src; mkdir -p > github.com/cadencemarseille; cd github.com/cadencemarseille; git clone > https://github.com/cadencemarseille/rust-pcre.git; rustpkg build > rust-pcre; > > > > On Thu, Oct 3, 2013 at 8:32 AM, Cadence Marseille > wrote: > > Hello, > > > > I just switched over the rust-pcre project's directory structure to a > > rustpkg workspace (as documented at > > http://static.rust-lang.org/doc/master/rustpkg.html). Now I am trying > to > > run a simple Rust program using the pcre module, but I am experiencing > some > > trouble. > > > > Both: > > > > extern mod pcre; > > > > and: > > > > extern mod pcre = "github.com/cadencemarseille/rust-pcre"; > > > > result in the error message: > > error: can't find crate for `pcre` > > > > To compile, I need to supply an -L flag to the full rustpkg library > output > > folder like so: > > > > rustc -L ~/.rust/pcre/lib/x86_64-apple-darwin -o pcredemo~ pcredemo.rs > > > > How do I set up my local dev env so that this "just works"? > > > > Cadence > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cadencemarseille at gmail.com Fri Oct 4 04:40:43 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Fri, 4 Oct 2013 07:40:43 -0400 Subject: [rust-dev] `extern mod` declarations In-Reply-To: References: Message-ID: Thanks, Jesse. I will definitely check it out. Cadence On Thu, Oct 3, 2013 at 3:06 PM, Jesse Haber-Kucharsky < jhaberkucharsky at cmu.edu> wrote: > Cadence, > > If the library's main source file is in src/pcre/lib.rs and the the demo > application's main source file is in src/pcredemo/main.rs, then I believe > that executing "rustpkg install pcre" and then "rustpkg install pcrememo" > will build and install the library and executable into the "lib" and "bin" > directories, respectively. > > From within src/pcredemo/main.rs, you should be able to write "extern mod > pcre" and everything will be found correctly. > > I wrote a very small Rust tcp server to figure this out for myself which > also consists of a workspace with multiple packages. You may find it useful > as an example for managing the rustpkg layout: > https://github.com/hakuch/LampShade (assuming that I'm following the > recommended conventions correctly). > -- > Jesse > > > On Thu, Oct 3, 2013 at 12:31 PM, Corey Richardson wrote: > >> It looks like you setup your workspace wrong. A quick fix is: >> >> cd ~/.rust; rustpkg init; cd src; mkdir -p >> github.com/cadencemarseille; cd github.com/cadencemarseille; git clone >> https://github.com/cadencemarseille/rust-pcre.git; rustpkg build >> rust-pcre; >> >> >> >> On Thu, Oct 3, 2013 at 8:32 AM, Cadence Marseille >> wrote: >> > Hello, >> > >> > I just switched over the rust-pcre project's directory structure to a >> > rustpkg workspace (as documented at >> > http://static.rust-lang.org/doc/master/rustpkg.html). Now I am trying >> to >> > run a simple Rust program using the pcre module, but I am experiencing >> some >> > trouble. >> > >> > Both: >> > >> > extern mod pcre; >> > >> > and: >> > >> > extern mod pcre = "github.com/cadencemarseille/rust-pcre"; >> > >> > result in the error message: >> > error: can't find crate for `pcre` >> > >> > To compile, I need to supply an -L flag to the full rustpkg library >> output >> > folder like so: >> > >> > rustc -L ~/.rust/pcre/lib/x86_64-apple-darwin -o pcredemo~ pcredemo.rs >> > >> > How do I set up my local dev env so that this "just works"? >> > >> > Cadence >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Fri Oct 4 05:50:50 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 04 Oct 2013 05:50:50 -0700 Subject: [rust-dev] Rust Meetup/Dinner in Mountain View on 10/14 In-Reply-To: References: Message-ID: <524EB9AA.9080201@mozilla.com> On 10/03/2013 03:07 PM, Erick Tryzelaar wrote: > Hey all! > > I'm happy to announce the first San Francisco Bay Area Rust meetup at > the Tied House on Columbus Day, Monday, October 14th, at 7pm: Thanks for organizing this, Erick! I'm looking forward to it. From eric.sampson at gmail.com Fri Oct 4 04:49:13 2013 From: eric.sampson at gmail.com (Eric Sampson) Date: Fri, 4 Oct 2013 06:49:13 -0500 Subject: [rust-dev] Assistance with compiling rust on OSX Message-ID: Hi all, I'm trying to get up and running with rust on OSX 10.8, and am running into the following error: $VERBOSE=1 make cfg: build triple x86_64-apple-darwin cfg: host triples x86_64-apple-darwin cfg: target triples x86_64-apple-darwin cfg: enabling more debugging (CFG_ENABLE_DEBUG) cfg: host for x86_64-apple-darwin is x86_64 cfg: os for x86_64-apple-darwin is apple-darwin cfg: using gcc cfg: no pandoc found, omitting docs cfg: no node found, omitting docs cfg: no llnextgen found, omitting grammar-verification cfg: no pandoc found, omitting library doc build make -C x86_64-apple-darwin/rt/stage0/libuv CFLAGS=" -DRUST_DEBUG -fno-omit-frame-pointer -DUSE_UTF8 -O2 -m64 -fPIC " LDFLAGS=" -m64 -fPIC" CC="gcc" CXX="g++" AR="ar" builddir="." BUILDTYPE=Release NO_LOAD=" run-benchmarks.target.mk run-tests.target.mk uv_dtrace_header.target.mk uv_dtrace_provider.target.mk" V=1 make[1]: Nothing to be done for `all'. g++ -o x86_64-apple-darwin/rt/stage0/librustrt.dylib -dynamiclib -pthread -framework CoreServices -Wl,-no_compact_unwind -m64 -Wl,-exported_symbols_list,x86_64-apple-darwin/rt/rustrt.darwin.def x86_64-apple-darwin/rt/stage0/sync/lock_and_signal.o x86_64-apple-darwin/rt/stage0/sync/rust_thread.o x86_64-apple-darwin/rt/stage0/rust_builtin.o x86_64-apple-darwin/rt/stage0/rust_rng.o x86_64-apple-darwin/rt/stage0/rust_upcall.o x86_64-apple-darwin/rt/stage0/rust_uv.o x86_64-apple-darwin/rt/stage0/miniz.o x86_64-apple-darwin/rt/stage0/memory_region.o x86_64-apple-darwin/rt/stage0/boxed_region.o x86_64-apple-darwin/rt/stage0/arch/x86_64/context.o x86_64-apple-darwin/rt/stage0/arch/x86_64/gpr.o x86_64-apple-darwin/rt/stage0/rust_android_dummy.o x86_64-apple-darwin/rt/stage0/rust_test_helpers.o x86_64-apple-darwin/rt/stage0/linenoise/linenoise.o x86_64-apple-darwin/rt/stage0/linenoise/utf8.o x86_64-apple-darwin/rt/stage0/sundown/src/autolink.o x86_64-apple-darwin/rt/stage0/sundown/src/buffer.o x86_64-apple-darwin/rt/stage0/sundown/src/stack.o x86_64-apple-darwin/rt/stage0/sundown/src/markdown.o x86_64-apple-darwin/rt/stage0/sundown/html/houdini_href_e.o x86_64-apple-darwin/rt/stage0/sundown/html/houdini_html_e.o x86_64-apple-darwin/rt/stage0/sundown/html/html_smartypants.o x86_64-apple-darwin/rt/stage0/sundown/html/html.o x86_64-apple-darwin/rt/stage0/arch/x86_64/_context.o x86_64-apple-darwin/rt/stage0/arch/x86_64/ccall.o x86_64-apple-darwin/rt/stage0/arch/x86_64/record_sp.o x86_64-apple-darwin/rt/stage0/jemalloc/lib/libjemalloc_pic.a x86_64-apple-darwin/rt/stage0/libuv/libuv.a -Wl,-install_name, at rpath/librustrt.dylib i686-apple-darwin11-llvm-g++-4.2: x86_64-apple-darwin/rt/stage0/libuv/libuv.a: No such file or directory make: *** [x86_64-apple-darwin/rt/stage0/librustrt.dylib] Error 1 I tried doing a 'make clean', but that didn't help. Here's the compiler info I'm using: $cc --version Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix Thanks in advance for your help :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Fri Oct 4 13:17:31 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 4 Oct 2013 16:17:31 -0400 Subject: [rust-dev] Automatically generated Rust documentation Message-ID: Hi all, A followup to my previous email: I have it up and going. The docs are at http://docs.octayn.net/. If you want your library documented, send a PR to https://github.com/cmr/docs. The program it uses to drive the process is https://github.com/cmr/doc_builder. From bklooste at gmail.com Sat Oct 5 19:52:37 2013 From: bklooste at gmail.com (Bennie Kloosteman) Date: Sun, 6 Oct 2013 10:52:37 +0800 Subject: [rust-dev] about unicode problem In-Reply-To: References: Message-ID: Windows only has 1 shell and it works with other products eg C# and Java so i think this is a bug .. The command shell ( and windows itself) supports Unicode but it must be usc2 not utf8 , the stack overflow response is not correct as it asumes Unicode = utf8. So if you convert to utf16 ( or even better USC2) which should be done on any windows runtime to be compliant it should be ok. As i said C# and java output is ( mostly) correct but they use utf-16 which is close to USC2 . USC2 cant display a few newer Chinese characters. Ben On Fri, Oct 4, 2013 at 11:04 AM, Chris Morgan wrote: > No, there really is nothing we can do about it while you continue to > use Command Prompt. Using a different shell is the only way to get it > to work properly. (And that itself may potentially introduce other > issues.) > > [Note also that you need to reply to all for your response to be on > the list. You sent it just to me.] > > On Fri, Oct 4, 2013 at 11:36 AM, leef huo wrote: > > Chris Morgan , thanks . > > After change the windows code page to 65001,and use Lucida console fonts, > > there was a slight improvement, the output becomes: > > but still have problems,it is not entirely correct. > > > > Are there a solution now or in the future that makes the rust > code(unicode) > > in the default windows command line to work properly? > > > > > > On Thu, Oct 3, 2013 at 11:24 AM, Chris Morgan > wrote: > >> > >> When you're using Command Prompt, you're basically stuck. It doesn't > >> have any meaningful Unicode support. > >> > >> See also > >> > http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how > >> > >> On Thu, Oct 3, 2013 at 12:50 PM, leef huo wrote: > >> > I want to print "hello world, ????"(Chinese)to the console, but the > result > >> > is > >> > garbled(messy code), the following code where the problem is? > >> > fn main() { > >> > let s=~"hello,????"; > >> > println(s); > >> > } > >> > Should output:hello,???? > >> > > >> > but it print " hello,?????? " to the console. > >> > > >> > OS : windows > >> > rust : 0.8 > >> > > >> > _______________________________________________ > >> > Rust-dev mailing list > >> > Rust-dev at mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Sat Oct 5 21:54:19 2013 From: martindemello at gmail.com (Martin DeMello) Date: Sat, 5 Oct 2013 21:54:19 -0700 Subject: [rust-dev] Introducing wxRust In-Reply-To: References: Message-ID: I took a closer look, and now think bindgen may not be the way to go for this. The wxc layer uses a bunch of custom C macros to provide extra information to binding generators, and generating bindings from the preprocessed C source throws all that information away. Might be worth taking a closer look at what the Haskell bindings are doing with the wxc headers and trying to reproduce that in wxRust. martin On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft wrote: > I tried rust-bindgen finally, and it worked excellently. Great work!! > > Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup, > I tried commit 3d49dbbbb7bcc0cf63b43a16a6cf52480fa9b752 and some tweak. > > And some arguments are needed, for my project: > > $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h > `wx-config --cflags` --include stdint.h --include time.h > > ../wxRust/generated.rs > > bindgen is C mode as default like clang or gcc are, so I understand it > requires `-x c++` option, > but I don't know why I have to explicitly include stdint.h and time.h > for size_t and uint8_t. > Do you have another recommended options? > > My codegen.py just handles functions, so handling for other > definitions benefits. > So I want adopt rust-bindgen to generate extern fn part of my binding > for long-term plan. > > Despite I know its Clang requirement changed for bitwidth support, but > as a Mac developer, I don't want to install the Clang 3.3 only for rust-bindgen, > especially I don't want add a new prerequisite to my library. > Are there a posibility of optional Clang 3.1 support (without bitwidth support)? > > > > 2013/9/26 Martin DeMello : >> no, but it might be feasible to add. not sure if it'd fall within the >> scope of bindgen or not, but at least bindgen could emit some sort of >> serialised data structure that would make generating the next level >> binding easier. >> >> martin >> >> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft wrote: >>> Oh, I didn't know that project, thank you for information. I'll try it. >>> BTW, I chose to make own parser and generator to generate not only extern fn >>> decls but also next-level wrapper such as: >>> >>> trait Frame { >>> pub fn show(&self) { >>> unsafe { >>> wxFrame_Show(self.handle()); >>> } >>> } >>> } >>> >>> or so, would bindgen helps this use case? (c.f. parsed data accessible or >>> so.) >>> >>> Did you try using bindgen on the wxc header file? If there were bits >>> it couldn't handle, I'd be interested in helping fix that. >>> >>> martin >>> >>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft >>> wrote: >>>> Hello, everyone. >>>> >>>> I would like to introduce my experimental project, wxRust. >>>> Which is a wxWidgets binding for Rust. >>>> >>>> https://github.com/kenz-gelsoft/wxRust >>>> >>>> This binding is based on the wxHaskell especially its "wxc"*1 >>>> C-Language wxWidgets binding part. >>>> >>>> Currently, it just converts wxc's header file to `extern fn`s and >>>> export them as a rust library. >>>> >>>> Test program has just started working which opens a wxFrame >>>> by calling wxc's C interface from extern fn. >>>> >>>> Current state is pre-alpha experimental state, there's no stable API, >>>> hard to use, but announced here for someone planning similar project. >>>> >>>> I'm planning for next generating simple OOP style wrapper as rust >>>> traits for each classes from wxc's header. >>>> >>>> There is many problems to tackle, for example how it can work >>>> with multitask or, library users can write wx GUI programs easier. >>>> Any helps or feedbacks are welcome. >>>> >>>> *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status] >>>> >>>> >>>> Thanks, >>>> -- >>>> KENZ >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> From corey at octayn.net Sat Oct 5 22:14:13 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 6 Oct 2013 01:14:13 -0400 Subject: [rust-dev] about unicode problem In-Reply-To: References: Message-ID: Yes, decoding the UTF-8 to UTF-16 should mostly work. On Sat, Oct 5, 2013 at 10:52 PM, Bennie Kloosteman wrote: > Windows only has 1 shell and it works with other products eg C# and Java so > i think this is a bug .. > > The command shell ( and windows itself) supports Unicode but it must be > usc2 not utf8 , the stack overflow response is not correct as it asumes > Unicode = utf8. > So if you convert to utf16 ( or even better USC2) which should be done on > any windows runtime to be compliant it should be ok. > > As i said C# and java output is ( mostly) correct but they use utf-16 which > is close to USC2 . USC2 cant display a few newer Chinese characters. > > Ben > > > On Fri, Oct 4, 2013 at 11:04 AM, Chris Morgan wrote: >> >> No, there really is nothing we can do about it while you continue to >> use Command Prompt. Using a different shell is the only way to get it >> to work properly. (And that itself may potentially introduce other >> issues.) >> >> [Note also that you need to reply to all for your response to be on >> the list. You sent it just to me.] >> >> On Fri, Oct 4, 2013 at 11:36 AM, leef huo wrote: >> > Chris Morgan , thanks . >> > After change the windows code page to 65001,and use Lucida console >> > fonts, >> > there was a slight improvement, the output becomes: >> > but still have problems,it is not entirely correct. >> > >> > Are there a solution now or in the future that makes the rust >> > code(unicode) >> > in the default windows command line to work properly? >> > >> > >> > On Thu, Oct 3, 2013 at 11:24 AM, Chris Morgan >> > wrote: >> >> >> >> When you're using Command Prompt, you're basically stuck. It doesn't >> >> have any meaningful Unicode support. >> >> >> >> See also >> >> >> >> http://stackoverflow.com/questions/388490/unicode-characters-in-windows-command-line-how >> >> >> >> On Thu, Oct 3, 2013 at 12:50 PM, leef huo wrote: >> >> > I want to print "hello world, ??"(Chinese)to the console, but the >> >> > result >> >> > is >> >> > garbled(messy code), the following code where the problem is? >> >> > fn main() { >> >> > let s=~"hello,??"; >> >> > println(s); >> >> > } >> >> > Should output:hello,?? >> >> > >> >> > but it print " hello,??? " to the console. >> >> > >> >> > OS : windows >> >> > rust : 0.8 >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > Rust-dev at mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> > >> > >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From martindemello at gmail.com Sun Oct 6 00:44:09 2013 From: martindemello at gmail.com (Martin DeMello) Date: Sun, 6 Oct 2013 00:44:09 -0700 Subject: [rust-dev] Introducing wxRust In-Reply-To: References: Message-ID: After thinking about it some more, I realised that bindgen works perfectly for generating the low-level C layer, and that the custom codegen can then just handle the OOP layer on top of it. I did a quick hack here, and after a few signature changes it all just worked: https://github.com/martindemello/wxRust/commits/bindgen martin On Sat, Oct 5, 2013 at 9:54 PM, Martin DeMello wrote: > I took a closer look, and now think bindgen may not be the way to go > for this. The wxc layer uses a bunch of custom C macros to provide > extra information to binding generators, and generating bindings from > the preprocessed C source throws all that information away. Might be > worth taking a closer look at what the Haskell bindings are doing with > the wxc headers and trying to reproduce that in wxRust. > > martin > > On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft wrote: >> I tried rust-bindgen finally, and it worked excellently. Great work!! >> >> Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup, >> I tried commit 3d49dbbbb7bcc0cf63b43a16a6cf52480fa9b752 and some tweak. >> >> And some arguments are needed, for my project: >> >> $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h >> `wx-config --cflags` --include stdint.h --include time.h > >> ../wxRust/generated.rs >> >> bindgen is C mode as default like clang or gcc are, so I understand it >> requires `-x c++` option, >> but I don't know why I have to explicitly include stdint.h and time.h >> for size_t and uint8_t. >> Do you have another recommended options? >> >> My codegen.py just handles functions, so handling for other >> definitions benefits. >> So I want adopt rust-bindgen to generate extern fn part of my binding >> for long-term plan. >> >> Despite I know its Clang requirement changed for bitwidth support, but >> as a Mac developer, I don't want to install the Clang 3.3 only for rust-bindgen, >> especially I don't want add a new prerequisite to my library. >> Are there a posibility of optional Clang 3.1 support (without bitwidth support)? >> >> >> >> 2013/9/26 Martin DeMello : >>> no, but it might be feasible to add. not sure if it'd fall within the >>> scope of bindgen or not, but at least bindgen could emit some sort of >>> serialised data structure that would make generating the next level >>> binding easier. >>> >>> martin >>> >>> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft wrote: >>>> Oh, I didn't know that project, thank you for information. I'll try it. >>>> BTW, I chose to make own parser and generator to generate not only extern fn >>>> decls but also next-level wrapper such as: >>>> >>>> trait Frame { >>>> pub fn show(&self) { >>>> unsafe { >>>> wxFrame_Show(self.handle()); >>>> } >>>> } >>>> } >>>> >>>> or so, would bindgen helps this use case? (c.f. parsed data accessible or >>>> so.) >>>> >>>> Did you try using bindgen on the wxc header file? If there were bits >>>> it couldn't handle, I'd be interested in helping fix that. >>>> >>>> martin >>>> >>>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft >>>> wrote: >>>>> Hello, everyone. >>>>> >>>>> I would like to introduce my experimental project, wxRust. >>>>> Which is a wxWidgets binding for Rust. >>>>> >>>>> https://github.com/kenz-gelsoft/wxRust >>>>> >>>>> This binding is based on the wxHaskell especially its "wxc"*1 >>>>> C-Language wxWidgets binding part. >>>>> >>>>> Currently, it just converts wxc's header file to `extern fn`s and >>>>> export them as a rust library. >>>>> >>>>> Test program has just started working which opens a wxFrame >>>>> by calling wxc's C interface from extern fn. >>>>> >>>>> Current state is pre-alpha experimental state, there's no stable API, >>>>> hard to use, but announced here for someone planning similar project. >>>>> >>>>> I'm planning for next generating simple OOP style wrapper as rust >>>>> traits for each classes from wxc's header. >>>>> >>>>> There is many problems to tackle, for example how it can work >>>>> with multitask or, library users can write wx GUI programs easier. >>>>> Any helps or feedbacks are welcome. >>>>> >>>>> *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status] >>>>> >>>>> >>>>> Thanks, >>>>> -- >>>>> KENZ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> From remifontan at yahoo.fr Sun Oct 6 02:09:23 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Sun, 6 Oct 2013 22:09:23 +1300 Subject: [rust-dev] clone and template Message-ID: Hi, I have just moved some of my code from 0.6 to rust 0.8 and was surprisingly not too difficult, great! however I noticed while converting copy to clone that I have to use a lot of explicit calls to ".clone()" in my templated code. In non templated code, the compiler is apparently more forgiving. Here' s a simple example to illustrate my point. Do you understand why I must write the initialisation of the list as "data:[a.clone(), a.clone(), a.clone()] " in the templated code and not simply "data:[a, a, a]". As T implements the clone trait, I was hoping the compiler would automatically clone when required. struct mystruct { data : [float, ..3] } impl mystruct { pub fn new(a:float) -> mystruct { mystruct{ data:[a, a, a] } } } struct mytmplstruct { data : [T, ..3] } impl mytmplstruct { pub fn new(a:T) -> mytmplstruct { mytmplstruct{ data:[a.clone(), a.clone(), a.clone()] } } } #[test] fn test_structs() { let m1 = mystruct::new(1.234f); let m2 = mytmplstruct::new(1.234f); } cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Oct 6 03:35:45 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 6 Oct 2013 06:35:45 -0400 Subject: [rust-dev] clone and template In-Reply-To: References: Message-ID: On Sun, Oct 6, 2013 at 5:09 AM, R?mi Fontan wrote: > Hi, > > I have just moved some of my code from 0.6 to rust 0.8 and was > surprisingly not too difficult, great! > > however I noticed while converting copy to clone that I have to use a lot > of explicit calls to ".clone()" in my templated code. In non templated > code, the compiler is apparently more forgiving. > > Here' s a simple example to illustrate my point. Do you understand why I > must write the initialisation of the list as "data:[a.clone(), a.clone(), > a.clone()] " in the templated code and not simply "data:[a, a, a]". As T > implements the clone trait, I was hoping the compiler would automatically > clone when required. > > struct mystruct { > data : [float, ..3] > } > > impl mystruct { > pub fn new(a:float) -> mystruct { > mystruct{ data:[a, a, a] } > } > } > > struct mytmplstruct { > data : [T, ..3] > } > > impl mytmplstruct { > > pub fn new(a:T) -> mytmplstruct { > mytmplstruct{ data:[a.clone(), a.clone(), a.clone()] } > } > } > > #[test] > fn test_structs() { > let m1 = mystruct::new(1.234f); > let m2 = mytmplstruct::new(1.234f); > } > > > cheers, > > R?mi > The `Clone` trait is entirely a library feature, so the compiler will never automatically generate calls to it. Rust has by-value assignment, passing and returning built into the language, but for some types (anything with a destructor, &fn or &mut) it moves ownership. In a generic function, it is always assumed to move ownership, as there is no trait associated with whether types move or not. I don't think it would be useful to have one, because `Clone` is much more generic. One minor nitpick is that with `[a.clone(), a.clone(), a.clone()]` you're not taking advantage of the existing value you have. You can move the value you do own into the array after the 2 clones. Otherwise, there's not much point in taking it by-value (although you do want that, if you would otherwise need to make at least one more copy). -------------- next part -------------- An HTML attachment was scrubbed... URL: From cadencemarseille at gmail.com Sun Oct 6 10:57:01 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Sun, 6 Oct 2013 13:57:01 -0400 Subject: [rust-dev] How to write a rustpkg package script (pkg.rs) Message-ID: Hello, To fix issue #1 of rust-pcre, I am working on a package script that will automatically determine the proper link_args to use and build the rust-pcre wrapper using those link args. For a while I was encountering the following error: task failed at 'called `Result::unwrap()` on `Err` value: error opening /usr/local/rustpkg_db.json: Permission denied', /private/tmp/-DSIK/rust-0.8/src/libstd/result.rs:109 Command return code = 101 task failed at 'Error running custom build command', /private/tmp/-DSIK/rust-0.8/src/librustpkg/rustpkg.rs:410 but I am working around this issue by copying a rustpkg_db.json file to /usr/local. I believe that I have a working "install" command implementation: https://github.com/cadencemarseille/rust-pcre/blob/master/src/pcre/pkg.rs However, rustpkg is still failing with: Running program (configs): /Users/cadencemarseille/Projects/rust-pcre/build/x86_64-apple-darwin/pcre/pkg /usr/local configs Command return code = 101 task failed at 'Error running custom build command', /private/tmp/-DSIK/rust-0.8/src/librustpkg/rustpkg.rs:410 I think that I now need to write a "configs" command, but I don't know what this is supposed to do. What do I need to do for "configs"? Cadence -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Sun Oct 6 11:57:42 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun, 6 Oct 2013 14:57:42 -0400 Subject: [rust-dev] Bug report HOWTO Message-ID: Hi all-- I thought it was worth it to write up a wiki page with guidelines for submitting Rust bugs: https://github.com/mozilla/rust/wiki/HOWTO-submit-a-RUST-bug-report Please edit and improve! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From mike at zwobble.org Sun Oct 6 12:03:51 2013 From: mike at zwobble.org (Michael Williamson) Date: Sun, 6 Oct 2013 20:03:51 +0100 Subject: [rust-dev] Creating a generic assert_equal function Message-ID: <20131006200351.4a377508@mwilliamson.workgroup> Hello, As an exercise, I was trying to create a generic assert_equal function. I came up with this: #[cfg(test)] mod tests { #[test] fn incorrect_output() { let output = ~"Hello"; assert_equal("Hi", output); } fn assert_equal(expected: &T, actual: &T) { assert!(expected == actual, "expected %s, was %s", expected.to_str(), actual.to_str()); } } However, attempting to compile this using rustc 0.8 results in an error: $ rustc assert_equal.rs --test -o tests assert_equal.rs:6:21: 6:25 error: mismatched types: expected `&` but found `&'static str` (expected &-ptr but found &'static str) assert_equal.rs:6 assert_equal("Hi", output); ^~~~ assert_equal.rs:6:27: 6:33 error: mismatched types: expected `&` but found `~str` (expected &-ptr but found ~str) assert_equal.rs:6 assert_equal("Hi", output); ^~~~~~ assert_equal.rs:6:8: 6:20 error: cannot determine a type for this bounded type parameter: unconstrained type assert_equal.rs:6 assert_equal("Hi", output); ^~~~~~~~~~~~ Replacing assert_equal with a specialised definition for strings results in an error-free compilation: fn assert_equal(expected: &str, actual: &str) { assert!(expected == actual, "expected %s, was %s", expected.to_str(), actual.to_str()); } How would I go about creating fixing the generic version of assert_equal, or am I barking up completely the wrong tree? Many thanks, and apologies if I'm sending this to the wrong list! Michael From pwalton at mozilla.com Sun Oct 6 12:05:39 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 06 Oct 2013 12:05:39 -0700 Subject: [rust-dev] Creating a generic assert_equal function In-Reply-To: <20131006200351.4a377508@mwilliamson.workgroup> References: <20131006200351.4a377508@mwilliamson.workgroup> Message-ID: <5251B483.1030405@mozilla.com> On 10/6/13 12:03 PM, Michael Williamson wrote: > Hello, > > As an exercise, I was trying to create a generic assert_equal function. > I came up with this: &str is not &T, because we don't have dynamically sized types yet. This should be fixed before 1.0. Patrick From kenz.gelsoft at gmail.com Sun Oct 6 12:12:23 2013 From: kenz.gelsoft at gmail.com (KENZ gelsoft) Date: Mon, 7 Oct 2013 04:12:23 +0900 Subject: [rust-dev] Introducing wxRust In-Reply-To: References: Message-ID: Martin, Yes. bindgen should be able to be used for wxc wrapping. Rust-ish OOP layer is a separate work. Recently I have very few time to try that. So your hack is very helpful! I'll take a closer look of that when I can work on this again. Thanks! 2013/10/6 Martin DeMello : > After thinking about it some more, I realised that bindgen works > perfectly for generating the low-level C layer, and that the custom > codegen can then just handle the OOP layer on top of it. > > I did a quick hack here, and after a few signature changes it all just > worked: https://github.com/martindemello/wxRust/commits/bindgen > > martin > > On Sat, Oct 5, 2013 at 9:54 PM, Martin DeMello wrote: >> I took a closer look, and now think bindgen may not be the way to go >> for this. The wxc layer uses a bunch of custom C macros to provide >> extra information to binding generators, and generating bindings from >> the preprocessed C source throws all that information away. Might be >> worth taking a closer look at what the Haskell bindings are doing with >> the wxc headers and trying to reproduce that in wxRust. >> >> martin >> >> On Fri, Sep 27, 2013 at 8:51 PM, KENZ gelsoft wrote: >>> I tried rust-bindgen finally, and it worked excellently. Great work!! >>> >>> Since it requires Clang 3.3 which doesn't exist on OS X 10.8 setup, >>> I tried commit 3d49dbbbb7bcc0cf63b43a16a6cf52480fa9b752 and some tweak. >>> >>> And some arguments are needed, for my project: >>> >>> $ ./bindgen -x c++ ../wxRust/wxHaskell/wxc/src/include/wxc.h >>> `wx-config --cflags` --include stdint.h --include time.h > >>> ../wxRust/generated.rs >>> >>> bindgen is C mode as default like clang or gcc are, so I understand it >>> requires `-x c++` option, >>> but I don't know why I have to explicitly include stdint.h and time.h >>> for size_t and uint8_t. >>> Do you have another recommended options? >>> >>> My codegen.py just handles functions, so handling for other >>> definitions benefits. >>> So I want adopt rust-bindgen to generate extern fn part of my binding >>> for long-term plan. >>> >>> Despite I know its Clang requirement changed for bitwidth support, but >>> as a Mac developer, I don't want to install the Clang 3.3 only for rust-bindgen, >>> especially I don't want add a new prerequisite to my library. >>> Are there a posibility of optional Clang 3.1 support (without bitwidth support)? >>> >>> >>> >>> 2013/9/26 Martin DeMello : >>>> no, but it might be feasible to add. not sure if it'd fall within the >>>> scope of bindgen or not, but at least bindgen could emit some sort of >>>> serialised data structure that would make generating the next level >>>> binding easier. >>>> >>>> martin >>>> >>>> On Wed, Sep 25, 2013 at 4:49 PM, KENZ gelsoft wrote: >>>>> Oh, I didn't know that project, thank you for information. I'll try it. >>>>> BTW, I chose to make own parser and generator to generate not only extern fn >>>>> decls but also next-level wrapper such as: >>>>> >>>>> trait Frame { >>>>> pub fn show(&self) { >>>>> unsafe { >>>>> wxFrame_Show(self.handle()); >>>>> } >>>>> } >>>>> } >>>>> >>>>> or so, would bindgen helps this use case? (c.f. parsed data accessible or >>>>> so.) >>>>> >>>>> Did you try using bindgen on the wxc header file? If there were bits >>>>> it couldn't handle, I'd be interested in helping fix that. >>>>> >>>>> martin >>>>> >>>>> On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft >>>>> wrote: >>>>>> Hello, everyone. >>>>>> >>>>>> I would like to introduce my experimental project, wxRust. >>>>>> Which is a wxWidgets binding for Rust. >>>>>> >>>>>> https://github.com/kenz-gelsoft/wxRust >>>>>> >>>>>> This binding is based on the wxHaskell especially its "wxc"*1 >>>>>> C-Language wxWidgets binding part. >>>>>> >>>>>> Currently, it just converts wxc's header file to `extern fn`s and >>>>>> export them as a rust library. >>>>>> >>>>>> Test program has just started working which opens a wxFrame >>>>>> by calling wxc's C interface from extern fn. >>>>>> >>>>>> Current state is pre-alpha experimental state, there's no stable API, >>>>>> hard to use, but announced here for someone planning similar project. >>>>>> >>>>>> I'm planning for next generating simple OOP style wrapper as rust >>>>>> traits for each classes from wxc's header. >>>>>> >>>>>> There is many problems to tackle, for example how it can work >>>>>> with multitask or, library users can write wx GUI programs easier. >>>>>> Any helps or feedbacks are welcome. >>>>>> >>>>>> *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status] >>>>>> >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> KENZ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> Rust-dev at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>>> From alex at crichton.co Sun Oct 6 15:39:27 2013 From: alex at crichton.co (Alex Crichton) Date: Sun, 6 Oct 2013 15:39:27 -0700 Subject: [rust-dev] Bug report HOWTO In-Reply-To: References: Message-ID: I think this is a fantastic idea. We may even want to entertain the idea of moving the mentioned URL on an ICE to this page instead. It looks like github also throws up a banner about "guidelines for contributing" which point to CONTRIBUTING.md, so perhaps it should also be included in that file so it's surfaced while a bug is being opened? On Sun, Oct 6, 2013 at 11:57 AM, Tim Chevalier wrote: > Hi all-- > > I thought it was worth it to write up a wiki page with guidelines for > submitting Rust bugs: > > https://github.com/mozilla/rust/wiki/HOWTO-submit-a-RUST-bug-report > > Please edit and improve! > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Being queer is not about a right to privacy; it is about the freedom > to be public, to just be who we are." -- anonymous, June 1990 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From steve at steveklabnik.com Sun Oct 6 16:04:56 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Sun, 6 Oct 2013 16:04:56 -0700 Subject: [rust-dev] Bug report HOWTO In-Reply-To: References: Message-ID: Yup, if we put this in CONTRIBUTING, it'll show up when making a new issue. Not like anyone reads them, but increasing the chances for no cost seems good. From corey at octayn.net Sun Oct 6 17:31:54 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 6 Oct 2013 20:31:54 -0400 Subject: [rust-dev] This (and Last) Week in Rust Message-ID: Last week, content from http://cmr.github.io/blog/2013/09/30/this-week-in-rust/ -- Welcome to another issue of *This Week in Rust*! This week saw the release of 0.8, the removal of `@fn`, and a bunch of other changes. The tutorial has been updated significantly, surrounding pointers and boxes, so you should re-read those sections if you're still feeling shaky on when you should use which. # What's cooking on master? There were 79 PRs merged this week. ## Breaking changes - `printf!` and `printfln!` have been [removed](https://github.com/mozilla/rust/pull/9550). - `continue` is now a keyword, a [synonym for `loop`](https://github.com/mozilla/rust/pull/9504), preceeding `loop`'s removal (https://github.com/mozilla/rust/issues/9467) - Item visibility is [properly encoded in metadata](https://github.com/mozilla/rust/pull/9432), so code which used private items that may have worked before is now rejected. - Char literals which should have been escaped [are now rejected when they aren't escpated](https://github.com/mozilla/rust/pull/9335). - `impl Foo for T;` is now [disallowed](https://github.com/mozilla/rust/pull/9336). Use `impl Foo for T {}`. - `@fn` has been [removed from the language](https://github.com/mozilla/rust/pull/9310). Replace it with `@Trait` objects, if you really need `@fn` (you probably don't). - `start` [no longer takes a crate map](https://github.com/mozilla/rust/pull/9301). - Some more keywords have been [reserved](https://github.com/mozilla/rust/pull/9389): `alignof`, `offsetof`, and `sizeof`. ## Everything else - A ton of documentation work was put in this week. The box section of the tutorial has been [rewritten](https://github.com/mozilla/rust/pull/9589), and there's a new [rustpkg tutorial](https://github.com/mozilla/rust/pull/9439) too. The module tutorial saw the file section [extended](https://github.com/mozilla/rust/pull/9398). There was a bunch of module documentation updated/added too. - rustdoc(_ng) also saw a lot of work. It [completely replaced](https://github.com/mozilla/rust/pull/9402) the old rustdoc, as well as seeing a [lot](https://github.com/mozilla/rust/pull/9577) of [fixes](https://github.com/mozilla/rust/pull/9475). Huge thanks to Alex Crichton for all the work with it! - `std::vec` has seen some [nice changes](https://github.com/mozilla/rust/pull/9583) to `connect_vec` and `concat_vec` (they were really awful before). - `rustpkg test` is [implemented](https://github.com/mozilla/rust/pull/9549). - `type_use` has been [removed](https://github.com/mozilla/rust/pull/9538). This did some nasty things and LLVM's `mergefunc` pass will do a better job of the same optimization (once it's enabled). - `with_c_str` is now [optimized](https://github.com/mozilla/rust/pull/9352) to be allocation-free for short vectors. - The logging system, when using the new formatting code (so `debug2` etc) is [allocation-free](https://github.com/mozilla/rust/pull/9261). - `std::rand` has seen some [cleanup](https://github.com/mozilla/rust/pull/9362), in preparation for its overhaul. # Weekly Meeting The [weekly meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-09-24) discussed a bunch of things, the main things of importance to me being: - `loop` -> `continue` - Allowing nested comments # Announcements - [wxRust](https://github.com/kenz-gelsoft/wxRust) - A binding to the wxWidgets toolkit. - [widmann](http://www.reddit.com/r/rust/comments/1neu74/the_start_of_a_sinatra_clone/) \- A Sinatra clone - [gl-rs](http://www.reddit.com/r/rust/comments/1nab2s/rustdev_opengl_glrs_updated_with_command_line/) has been updated to generate only bindings for a select version / set of extensions. - [Debugging Rust in Eclipse](http://www.reddit.com/r/rust/comments/1n8y5b/debugging_rust_in_eclipse/) \- Michael Woerister's final GSoC post. He did really great work this summer! - [Rust for Rubyists](https://github.com/steveklabnik/rust_for_rubyists) has been open sourced! - The [Claymore](https://code.google.com/p/claymore-game/) project has just come to my attention. Apparently it has been going on for quite some time. There are some screenshots at . - [rustenstein3d](https://github.com/JeremyLetang/rustenstein3D/) - a Wolfenstein3D engine - [clio](https://github.com/eevee/clio), a roguelike. This one also slipped under my radar for a while. - [rust-gmp](https://github.com/thestinger/rust-gmp) has been updated for 0.8/master. - [rustdoc_ng](https://github.com/cmr/rustdoc_ng), being merged into mainline, has concluded as a project. - And, of course, the [0.8 release](http://www.reddit.com/r/rust/comments/1n7q8v/08_released/) discussion on reddit. -- This Week, content from http://cmr.github.io/blog/2013/10/06/this-week-in-rust/ --- layout: post title: "This Week in Rust" date: 2013-10-06 18:25 comments: true categories: rust programming this-week-in-rust --- Welcome to another issue of *This Week in Rust*. # What's cooking on master? Only 63 PRs were merged this week. Currently in the queue is the massive privacy change, the path rewrite, enum descriminant shrinking, a `rand` rework, a lock-free scheduler message queue, and libuv signal bindings. ## Breaking Changes - `float` has been [removed from the language](https://github.com/mozilla/rust/pull/9519). - `loop` has been [removed](https://github.com/mozilla/rust/pull/9665). The transition to `continue` is complete. - A macro ignoring tokens now [throws an error](https://github.com/mozilla/rust/pull/9673) rather than silently ignoring it. - `IntConvertible` has been [replaced](https://github.com/mozilla/rust/pull/9250) with `ToPrimitive` and `FromPrimitive`. This also heralds the ability to derive to/from int methods on enums. ## Everything Else - `rustpkg` can [fetch remote packages again](https://github.com/mozilla/rust/pull/9741). - A bunch of unsafe code surrounding logging [has been remove](https://github.com/mozilla/rust/pull/9593). - A bunch of work was done to make more things immediate. A [bugfix](https://github.com/mozilla/rust/pull/9643), [small tuples](https://github.com/mozilla/rust/pull/9656), [small enums](https://github.com/mozilla/rust/pull/9677), and [unit/C-like enums](https://github.com/mozilla/rust/pull/9699). - A bunch of work went into decreasing our memory usage. The massive spike at the beginning [has been fixed](https://github.com/mozilla/rust/pull/9612). The tcx (type context, holds the result of *all* compiler analysis) is also free'd before translation now, reducing memory usage by a good [500+ MB](https://github.com/mozilla/rust/pull/9686). Another cache during constant evaluation [reduces memory usage by 200MB](https://github.com/mozilla/rust/pull/9722). - We're now [bundling our dependencies](https://github.com/mozilla/rust/pull/9662) on Windows, making it easier to bootstrap and to setup a working Rust environment. - All of the really old obsolete syntax checkers [have been removed](https://github.com/mozilla/rust/pull/9712). - Hyperlinking between crates is [now reimplemented](https://github.com/mozilla/rust/pull/9691) in rustdoc. - Gearing up for its removal, [all `fmt!` usage in the compiler has been removed](https://github.com/mozilla/rust/pull/9599). # Weekly Meeting The [weekly meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-10-01) discussed a bunch of proposed changes, including rustpkg submodules, removing float (which has already happened), raw string literals (which have a patch almost finished), and the changes to the Option API. # Announcements - [ncurses-rs](https://github.com/jeaye/ncurses-rs) - a safe wrapper that keeps the same ncurses interface you know and "love", but more rustic. - [The Rusticon](https://github.com/mozilla/rust/wiki/The%20Rusticon) - A living glossary of Rust terms. - [A production use of Rust!](http://www.reddit.com/r/rust/comments/1nqzth/zeromq_helping_us_block_malicious_domains_in_real/) - [Understanding the Servo Strategy](http://www.reddit.com/r/rust/comments/1ntnvf/understanding_the_servo_strategy/) \- The Servo presentation given at the various Mozilla Summits - [Dynamic Typing implemented as a library](http://www.reddit.com/r/rust/comments/1nmarr/dynamic_typing_implemented_as_library_code/) \- a pretty cool use of our reflection. - [Running Rust Tests on Travis CI](http://www.reddit.com/r/rust/comments/1ni84a/running_rust_tests_on_travis_ci/). - [Rust bindings for FUSE](http://www.reddit.com/r/rust/comments/1ngqgr/rust_bindings_for_fuse_filesystem_in_userspace/) # Meetups Haven't had a meetup section in a long time, but two are forming! - [Francisco Bay Area](http://www.meetup.com/Rust-Bay-Area/) - [Rust Sk?ne (Lund, Sweden)](http://www.meetup.com/rust-skane/) From eric.sampson at gmail.com Sun Oct 6 19:28:09 2013 From: eric.sampson at gmail.com (Eric Sampson) Date: Sun, 6 Oct 2013 21:28:09 -0500 Subject: [rust-dev] Assistance with compiling rust on OSX In-Reply-To: References: Message-ID: Just to close the loop on this issue, I did some Googling and was able to determine that the problem was a result of gyp not playing nice when only the Xcode Command Line Tools are installed rather than the entire Xcode environment. Here is the gyp issue in question: https://code.google.com/p/gyp/issues/detail?id=292 The following thread was what led me to figure out that this was the issue, and the solution described in the linked comment fixed the issue for me (applying the proposed patch attached to gyp issue 292 to the gyp code shipped with Rust) https://github.com/joyent/node/issues/3681#issuecomment-23140289 Thanks to the folks that emailed me with some debugging suggestions, sorry that I wasn't able to respond back earlier :) Best, Eric On Fri, Oct 4, 2013 at 6:49 AM, Eric Sampson wrote: > Hi all, I'm trying to get up and running with rust on OSX 10.8, and am > running into the following error: > > $VERBOSE=1 make > cfg: build triple x86_64-apple-darwin > cfg: host triples x86_64-apple-darwin > cfg: target triples x86_64-apple-darwin > cfg: enabling more debugging (CFG_ENABLE_DEBUG) > cfg: host for x86_64-apple-darwin is x86_64 > cfg: os for x86_64-apple-darwin is apple-darwin > cfg: using gcc > cfg: no pandoc found, omitting docs > cfg: no node found, omitting docs > cfg: no llnextgen found, omitting grammar-verification > cfg: no pandoc found, omitting library doc build > make -C x86_64-apple-darwin/rt/stage0/libuv CFLAGS=" -DRUST_DEBUG > -fno-omit-frame-pointer -DUSE_UTF8 -O2 -m64 -fPIC " LDFLAGS=" -m64 -fPIC" > CC="gcc" CXX="g++" AR="ar" builddir="." BUILDTYPE=Release NO_LOAD=" > run-benchmarks.target.mk run-tests.target.mk uv_dtrace_header.target.mk > uv_dtrace_provider.target.mk" V=1 > make[1]: Nothing to be done for `all'. > g++ -o x86_64-apple-darwin/rt/stage0/librustrt.dylib -dynamiclib -pthread > -framework CoreServices -Wl,-no_compact_unwind -m64 > -Wl,-exported_symbols_list,x86_64-apple-darwin/rt/rustrt.darwin.def > x86_64-apple-darwin/rt/stage0/sync/lock_and_signal.o > x86_64-apple-darwin/rt/stage0/sync/rust_thread.o > x86_64-apple-darwin/rt/stage0/rust_builtin.o > x86_64-apple-darwin/rt/stage0/rust_rng.o > x86_64-apple-darwin/rt/stage0/rust_upcall.o > x86_64-apple-darwin/rt/stage0/rust_uv.o > x86_64-apple-darwin/rt/stage0/miniz.o > x86_64-apple-darwin/rt/stage0/memory_region.o > x86_64-apple-darwin/rt/stage0/boxed_region.o > x86_64-apple-darwin/rt/stage0/arch/x86_64/context.o > x86_64-apple-darwin/rt/stage0/arch/x86_64/gpr.o > x86_64-apple-darwin/rt/stage0/rust_android_dummy.o > x86_64-apple-darwin/rt/stage0/rust_test_helpers.o > x86_64-apple-darwin/rt/stage0/linenoise/linenoise.o > x86_64-apple-darwin/rt/stage0/linenoise/utf8.o > x86_64-apple-darwin/rt/stage0/sundown/src/autolink.o > x86_64-apple-darwin/rt/stage0/sundown/src/buffer.o > x86_64-apple-darwin/rt/stage0/sundown/src/stack.o > x86_64-apple-darwin/rt/stage0/sundown/src/markdown.o > x86_64-apple-darwin/rt/stage0/sundown/html/houdini_href_e.o > x86_64-apple-darwin/rt/stage0/sundown/html/houdini_html_e.o > x86_64-apple-darwin/rt/stage0/sundown/html/html_smartypants.o > x86_64-apple-darwin/rt/stage0/sundown/html/html.o > x86_64-apple-darwin/rt/stage0/arch/x86_64/_context.o > x86_64-apple-darwin/rt/stage0/arch/x86_64/ccall.o > x86_64-apple-darwin/rt/stage0/arch/x86_64/record_sp.o > x86_64-apple-darwin/rt/stage0/jemalloc/lib/libjemalloc_pic.a > x86_64-apple-darwin/rt/stage0/libuv/libuv.a > -Wl,-install_name, at rpath/librustrt.dylib > i686-apple-darwin11-llvm-g++-4.2: > x86_64-apple-darwin/rt/stage0/libuv/libuv.a: No such file or directory > make: *** [x86_64-apple-darwin/rt/stage0/librustrt.dylib] Error 1 > > I tried doing a 'make clean', but that didn't help. > > Here's the compiler info I'm using: > $cc --version > Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn) > Target: x86_64-apple-darwin12.5.0 > Thread model: posix > > Thanks in advance for your help :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.sampson at gmail.com Sun Oct 6 19:35:57 2013 From: eric.sampson at gmail.com (Eric Sampson) Date: Sun, 6 Oct 2013 21:35:57 -0500 Subject: [rust-dev] Assistance with compiling rust on OSX In-Reply-To: References: Message-ID: Oh yeah, in order to remove an error message I was getting when trying to compile using only the Xcode Command Line Tools, I also had to stub out xcrun as described in this link: http://sector7g.be/posts/mountain-lion-dealing-with-xcrun On Sun, Oct 6, 2013 at 9:28 PM, Eric Sampson wrote: > Just to close the loop on this issue, I did some Googling and was able to > determine that the problem was a result of gyp not playing nice when only > the Xcode Command Line Tools are installed rather than the entire Xcode > environment. > > Here is the gyp issue in question: > https://code.google.com/p/gyp/issues/detail?id=292 > > The following thread was what led me to figure out that this was the > issue, and the solution described in the linked comment fixed the issue for > me (applying the proposed patch attached to gyp issue 292 to the gyp code > shipped with Rust) > https://github.com/joyent/node/issues/3681#issuecomment-23140289 > > Thanks to the folks that emailed me with some debugging suggestions, sorry > that I wasn't able to respond back earlier :) > > Best, > Eric > > > > > On Fri, Oct 4, 2013 at 6:49 AM, Eric Sampson wrote: > >> Hi all, I'm trying to get up and running with rust on OSX 10.8, and am >> running into the following error: >> >> $VERBOSE=1 make >> cfg: build triple x86_64-apple-darwin >> cfg: host triples x86_64-apple-darwin >> cfg: target triples x86_64-apple-darwin >> cfg: enabling more debugging (CFG_ENABLE_DEBUG) >> cfg: host for x86_64-apple-darwin is x86_64 >> cfg: os for x86_64-apple-darwin is apple-darwin >> cfg: using gcc >> cfg: no pandoc found, omitting docs >> cfg: no node found, omitting docs >> cfg: no llnextgen found, omitting grammar-verification >> cfg: no pandoc found, omitting library doc build >> make -C x86_64-apple-darwin/rt/stage0/libuv CFLAGS=" -DRUST_DEBUG >> -fno-omit-frame-pointer -DUSE_UTF8 -O2 -m64 -fPIC " LDFLAGS=" -m64 -fPIC" >> CC="gcc" CXX="g++" AR="ar" builddir="." BUILDTYPE=Release NO_LOAD=" >> run-benchmarks.target.mk run-tests.target.mk uv_dtrace_header.target.mk >> uv_dtrace_provider.target.mk" V=1 >> make[1]: Nothing to be done for `all'. >> g++ -o x86_64-apple-darwin/rt/stage0/librustrt.dylib -dynamiclib >> -pthread -framework CoreServices -Wl,-no_compact_unwind -m64 >> -Wl,-exported_symbols_list,x86_64-apple-darwin/rt/rustrt.darwin.def >> x86_64-apple-darwin/rt/stage0/sync/lock_and_signal.o >> x86_64-apple-darwin/rt/stage0/sync/rust_thread.o >> x86_64-apple-darwin/rt/stage0/rust_builtin.o >> x86_64-apple-darwin/rt/stage0/rust_rng.o >> x86_64-apple-darwin/rt/stage0/rust_upcall.o >> x86_64-apple-darwin/rt/stage0/rust_uv.o >> x86_64-apple-darwin/rt/stage0/miniz.o >> x86_64-apple-darwin/rt/stage0/memory_region.o >> x86_64-apple-darwin/rt/stage0/boxed_region.o >> x86_64-apple-darwin/rt/stage0/arch/x86_64/context.o >> x86_64-apple-darwin/rt/stage0/arch/x86_64/gpr.o >> x86_64-apple-darwin/rt/stage0/rust_android_dummy.o >> x86_64-apple-darwin/rt/stage0/rust_test_helpers.o >> x86_64-apple-darwin/rt/stage0/linenoise/linenoise.o >> x86_64-apple-darwin/rt/stage0/linenoise/utf8.o >> x86_64-apple-darwin/rt/stage0/sundown/src/autolink.o >> x86_64-apple-darwin/rt/stage0/sundown/src/buffer.o >> x86_64-apple-darwin/rt/stage0/sundown/src/stack.o >> x86_64-apple-darwin/rt/stage0/sundown/src/markdown.o >> x86_64-apple-darwin/rt/stage0/sundown/html/houdini_href_e.o >> x86_64-apple-darwin/rt/stage0/sundown/html/houdini_html_e.o >> x86_64-apple-darwin/rt/stage0/sundown/html/html_smartypants.o >> x86_64-apple-darwin/rt/stage0/sundown/html/html.o >> x86_64-apple-darwin/rt/stage0/arch/x86_64/_context.o >> x86_64-apple-darwin/rt/stage0/arch/x86_64/ccall.o >> x86_64-apple-darwin/rt/stage0/arch/x86_64/record_sp.o >> x86_64-apple-darwin/rt/stage0/jemalloc/lib/libjemalloc_pic.a >> x86_64-apple-darwin/rt/stage0/libuv/libuv.a >> -Wl,-install_name, at rpath/librustrt.dylib >> i686-apple-darwin11-llvm-g++-4.2: >> x86_64-apple-darwin/rt/stage0/libuv/libuv.a: No such file or directory >> make: *** [x86_64-apple-darwin/rt/stage0/librustrt.dylib] Error 1 >> >> I tried doing a 'make clean', but that didn't help. >> >> Here's the compiler info I'm using: >> $cc --version >> Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn) >> Target: x86_64-apple-darwin12.5.0 >> Thread model: posix >> >> Thanks in advance for your help :) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at jakub.cc Mon Oct 7 06:48:50 2013 From: jakub at jakub.cc (Jakub Wieczorek) Date: Mon, 7 Oct 2013 14:48:50 +0100 Subject: [rust-dev] Creating a generic assert_equal function In-Reply-To: <20131006200351.4a377508@mwilliamson.workgroup> References: <20131006200351.4a377508@mwilliamson.workgroup> Message-ID: Hi Michael, Another way would be to make assert_equal work with all types and use the repr module to print out pretty representations of objects being compared. To give you an example: https://github.com/jakub-/a8282cf2/blob/master/src/matchers.rs#L24 Regards, Jakub On Oct 6, 2013, at 20:03, Michael Williamson wrote: > Hello, > > As an exercise, I was trying to create a generic assert_equal function. > I came up with this: > > > #[cfg(test)] > mod tests { > #[test] > fn incorrect_output() { > let output = ~"Hello"; > assert_equal("Hi", output); > } > > fn assert_equal(expected: &T, actual: &T) { > assert!(expected == actual, "expected %s, was %s", expected.to_str(), actual.to_str()); > } > } > > > However, attempting to compile this using rustc 0.8 results in an error: > > > $ rustc assert_equal.rs --test -o tests > assert_equal.rs:6:21: 6:25 error: mismatched types: expected `&` but found `&'static str` (expected &-ptr but found &'static str) > assert_equal.rs:6 assert_equal("Hi", output); > ^~~~ > assert_equal.rs:6:27: 6:33 error: mismatched types: expected `&` but found `~str` (expected &-ptr but found ~str) > assert_equal.rs:6 assert_equal("Hi", output); > ^~~~~~ > assert_equal.rs:6:8: 6:20 error: cannot determine a type for this bounded type parameter: unconstrained type > assert_equal.rs:6 assert_equal("Hi", output); > ^~~~~~~~~~~~ > > > Replacing assert_equal with a specialised definition for strings > results in an error-free compilation: > > > fn assert_equal(expected: &str, actual: &str) { > assert!(expected == actual, "expected %s, was %s", expected.to_str(), actual.to_str()); > } > > > How would I go about creating fixing the generic version of > assert_equal, or am I barking up completely the wrong tree? > > Many thanks, and apologies if I'm sending this to the wrong list! > > Michael > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From remifontan at yahoo.fr Tue Oct 8 02:08:57 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Tue, 8 Oct 2013 22:08:57 +1300 Subject: [rust-dev] clone and template In-Reply-To: References: Message-ID: thanks for clear explanation, it all make sense now. I noticed that if I add something to "a" then I do not need to call the clone method; so something like this would compile [a + num::Zero::zero(), a + num::Zero::zero(), a] I guess that the addition does generate a copy. R?mi On Sun, Oct 6, 2013 at 11:35 PM, Daniel Micay wrote: > On Sun, Oct 6, 2013 at 5:09 AM, R?mi Fontan wrote: > >> Hi, >> >> I have just moved some of my code from 0.6 to rust 0.8 and was >> surprisingly not too difficult, great! >> >> however I noticed while converting copy to clone that I have to use a lot >> of explicit calls to ".clone()" in my templated code. In non templated >> code, the compiler is apparently more forgiving. >> >> Here' s a simple example to illustrate my point. Do you understand why I >> must write the initialisation of the list as "data:[a.clone(), a.clone(), >> a.clone()] " in the templated code and not simply "data:[a, a, a]". As T >> implements the clone trait, I was hoping the compiler would automatically >> clone when required. >> >> struct mystruct { >> data : [float, ..3] >> } >> >> impl mystruct { >> pub fn new(a:float) -> mystruct { >> mystruct{ data:[a, a, a] } >> } >> } >> >> struct mytmplstruct { >> data : [T, ..3] >> } >> >> impl mytmplstruct { >> >> pub fn new(a:T) -> mytmplstruct { >> mytmplstruct{ data:[a.clone(), a.clone(), a.clone()] } >> } >> } >> >> #[test] >> fn test_structs() { >> let m1 = mystruct::new(1.234f); >> let m2 = mytmplstruct::new(1.234f); >> } >> >> >> cheers, >> >> R?mi >> > > The `Clone` trait is entirely a library feature, so the compiler will > never automatically generate calls to it. Rust has by-value assignment, > passing and returning built into the language, but for some types (anything > with a destructor, &fn or &mut) it moves ownership. > > In a generic function, it is always assumed to move ownership, as there is > no trait associated with whether types move or not. I don't think it would > be useful to have one, because `Clone` is much more generic. > > One minor nitpick is that with `[a.clone(), a.clone(), a.clone()]` you're > not taking advantage of the existing value you have. You can move the value > you do own into the array after the 2 clones. Otherwise, there's not much > point in taking it by-value (although you do want that, if you would > otherwise need to make at least one more copy). > -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmcallister at mozilla.com Tue Oct 8 14:55:36 2013 From: kmcallister at mozilla.com (Keegan McAllister) Date: Tue, 8 Oct 2013 14:55:36 -0700 (PDT) Subject: [rust-dev] Mixed C++/Rust libraries with user-friendly LTO In-Reply-To: <2136656583.2563646.1381265606177.JavaMail.zimbra@mozilla.com> Message-ID: <688307022.2575148.1381269336328.JavaMail.zimbra@mozilla.com> I was excited to see the recent work [1] regarding link-time optimization between C or C++ and Rust code. In Servo we access JavaScript objects through small C++ functions [2] declared as extern "C". It would be great if the code for these accessors (which depends on the C++ ABI and the contents of the SpiderMonkey header files) could be inlined into Rust functions. The main problem I see with the approach described in [1] is that it requires a special build process for the whole Rust program. One compiles Rust to LLVM bytecode and then links using clang. So my question is: how can we make a mixed C++/Rust library which exposes LTO for the C++ components, and yet can be used like any other Rust library crate? I suppose we would have to compile the C++ with clang and then store the resulting LLVM bytecode as metadata in the library crate's shared object. Does rustc already do inlining from LLVM bytecode stored as metadata, or does it store Rust ASTs only? I would be interested to hear any thoughts regarding this project, in particular estimates of how difficult or time-consuming it would be. Thanks, keegan [1] https://github.com/mozilla/rust/wiki/Mixed-language-link-time-optimization [2] https://github.com/mozilla-servo/rust-mozjs/blob/master/jsglue.cpp#L269 From cadencemarseille at gmail.com Wed Oct 9 04:34:18 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Wed, 9 Oct 2013 07:34:18 -0400 Subject: [rust-dev] How to write a rustpkg package script (pkg.rs) In-Reply-To: References: Message-ID: I ended up adding a no-op "configs" implementation in cadencemarseille/rust-pcre at 59beca8. Looking through the rustpkg.rs source, I think that the intent of the "configs" command is generate "cfgs" (a la --cfg options passed to rustc) when compiling Rust code using the crate, similar to the config.h header file that is generated by the configure script and which contains all of the HAVE_* macros? Is this correct? One thing that would be neat is if there were a tool similar to Autoconf that could automatically generate the package script. I am actually considering working on such a tool, perhaps called Autopkg. In order to do this, one very useful rustpkg::api function would be a way to build a library with a list of configs. Currently in rust-pcre's package script for example, I use the api::build_lib() function: api::build_lib(sysroot_path, workspace_path, ~"pcre", rustpkg::version::ExactRevision(~"0.1"), Path("mod.rs")); If I could pass a config to signify whether the system's libpcre has the pcre_free_study() function, then I could tailor the wrapper to libpcre versions older than 8.20 using #[cfg(have_pcre_free_study)]. In the current system, a package script would have to generate all Rust files having such #[cfg(...)] lines and basically do what rustc does. On Sun, Oct 6, 2013 at 1:57 PM, Cadence Marseille < cadencemarseille at gmail.com> wrote: > Hello, > > To fix issue #1 of rust-pcre, > I am working on a package script that will automatically determine the > proper link_args to use and build the rust-pcre wrapper using those link > args. > > For a while I was encountering the following error: > task failed at 'called `Result::unwrap()` on `Err` value: error > opening /usr/local/rustpkg_db.json: Permission denied', > /private/tmp/-DSIK/rust-0.8/src/libstd/result.rs:109 > Command return code = 101 > task failed at 'Error running custom build command', > /private/tmp/-DSIK/rust-0.8/src/librustpkg/rustpkg.rs:410 > > but I am working around this issue by copying a rustpkg_db.json file to > /usr/local. > > I believe that I have a working "install" command implementation: > https://github.com/cadencemarseille/rust-pcre/blob/master/src/pcre/pkg.rs > However, rustpkg is still failing with: > Running program (configs): > /Users/cadencemarseille/Projects/rust-pcre/build/x86_64-apple-darwin/pcre/pkg > /usr/local configs > Command return code = 101 > task failed at 'Error running custom build command', > /private/tmp/-DSIK/rust-0.8/src/librustpkg/rustpkg.rs:410 > > I think that I now need to write a "configs" command, but I don't know > what this is supposed to do. > > What do I need to do for "configs"? > > Cadence > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobbyholley at gmail.com Wed Oct 9 02:31:42 2013 From: bobbyholley at gmail.com (Bobby Holley) Date: Wed, 9 Oct 2013 11:31:42 +0200 Subject: [rust-dev] Mutability Overloads Message-ID: Hi, I've recently started hacking a bit on Servo. I'm new to Rust, and so I'm complaining about the first thing that bit me. :-) In the Servo DOM, we've got this trait called |CacheableWrapper|, which I've recently renamed to |Reflectable|. This trait is implemented by most DOM objects, and is the mechanism by which we reach the JS reflection of a rust object. The |Reflectable| trait has the following method: |fn reflector(&mut self) -> &mut Reflector;|. Reflector has two methods: pub fn get_jsobject(&self) -> *JSObject pub fn set_jsobject(&mut self, object: *JSObject) If I have some immutable Rust DOM object, it would be great if I could invoke something like the following: dom_object.reflector().get_ jsobject(). But currently, I have to force the thing to be mutable just to access the Reflector, even if, eventually, I just want to invoke an immutable method on the resulting Reflector. I would love to be able to declare a companion |fn reflector(&self) -> &Reflector;|, but Rust doesn't seem to support function overloads. Ms2ger suggests adding mut_reflector variants of all the methods we might want to invoke in a mutable fashion. But this kind of name-mangling seems like a workaround for a problem that the language should solve, especially given the heavy emphasis on immutability. Are there any plans for dealing with this problem in the language? If not, are we designing things wrong in Servo, or should Rust programs prepend |mut_| to any mutable method that might conceivably have an immutable variant? It seems like we could also solve this problem by ditching the reflector() getter and accessing the |reflector| property directly. But I don't see a way to make that work with Traits. Cheers, bholley From sylvestre at debian.org Wed Oct 9 05:20:11 2013 From: sylvestre at debian.org (Sylvestre Ledru) Date: Wed, 09 Oct 2013 14:20:11 +0200 Subject: [rust-dev] LLVM at FOSDEM 2014 - Call for papers and participation Message-ID: <525549FB.9010405@debian.org> Since rust is using LLVM, some developers might be interested by the following message (and a talk about rust itself would be much appreciated). CALL FOR PAPERS / PARTICIPATION At FOSDEM 2014, LLVM will for the first time participate with a dedicated devroom. Complementing the upcoming Euro LLVM 2014, the devroom at FOSDEM provides a great opportunity for core LLVM developers and the wider open source community to get together, connect and discuss. As possibly the largest European Open Source Conference, FOSDEM takes place in Brussels and attracts with more than 400 lectures every year over 5000 hackers - many core contributors of the worlds leading open source projects. = Call for Speakers, Posters, Demos = We invite academic, industrial and hobbyist speakers to present their work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. We are looking for: 1. Keynote speakers. 2. Technical presentations (30 minutes plus questions and discussion) related to development of LLVM, Clang etc. 3. Presentations about the use of LLVM, Clang in commercial or academic projects as well as in the open source world. 4. Tutorials 5. Lightning talks (5 minutes) The deadline for receiving submissions is December 1st, 2013. Speakers will be notified of acceptance or rejection by the 15th of December. Proposals that are not sufficiently detailed (talks lacking a comprehensive abstract for example) are likely to be rejected. Please create an account on the FOSDEM interface ( https://penta.fosdem.org/user/new_account ) and submit your proposal ( https://penta.fosdem.org/submission/FOSDEM14/event/new ). Please make sure you select "LLVM devroom" as the "Track". = Registration = FOSDEM does not require any registration and is free of charge. However, we advise to arrive early in the devroom in case of important affluence. = Organisation = The mailing list llvm-devroom at lists.fosdem.org can be used to discuss issues of general interest related to the conference organization. = Financial Support = There may be a possibility of limited funding to help students or contributors who could not otherwise attend the conference. This will depend on overall sponsorship and companies' interest in supporting the event. If you need funding to attend the meeting, or can help sponsor, please tell us on llvm-devroom at lists.fosdem.org. = About LLVM = LLVM is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyse and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or "idle-time" (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. Besides LLVM, several projects have been developed on top of it like lang, LLDB, Polly or VMKit. For more information, please visit http://llvm.org/ or the conference webpage at http://llvm.org/devmtg/2014-02/ Tobias Grosser & Sylvestre Ledru From pwalton at mozilla.com Wed Oct 9 10:37:13 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 09 Oct 2013 10:37:13 -0700 Subject: [rust-dev] Mutability Overloads In-Reply-To: References: Message-ID: <52559449.9010303@mozilla.com> On 10/9/13 2:31 AM, Bobby Holley wrote: > Ms2ger suggests adding mut_reflector variants of all the methods we > might want to invoke in a mutable fashion. But this kind of > name-mangling seems like a workaround for a problem that the language > should solve, especially given the heavy emphasis on immutability. > > Are there any plans for dealing with this problem in the language? If > not, are we designing things wrong in Servo, or should Rust programs > prepend |mut_| to any mutable method that might conceivably have an > immutable variant? In general prepending `mut_` is the way we've been going. Solving this in the language would be tricky. We'd have to be careful with C++-style overloading because `&mut self` is coercible to `&self` via reborrowing. Thus `fn reflector(&self) -> &Reflector` would typecheck even if you have an `&mut Self` instance. Perhaps the right thing would be something like mutability variables: `fn reflector(&M self) -> &M Reflector`. Of course then integrating a pointer of unknown mutability introduces borrow check issues similar to those we have with `&const`. So my answer is: Yes, it's unfortunate, but we'd have to think carefully about how to fix it without breaking the soundness of the language (and while keeping the language easy to reason about). Patrick From banderson at mozilla.com Wed Oct 9 12:19:32 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 09 Oct 2013 12:19:32 -0700 Subject: [rust-dev] Mixed C++/Rust libraries with user-friendly LTO In-Reply-To: <688307022.2575148.1381269336328.JavaMail.zimbra@mozilla.com> References: <688307022.2575148.1381269336328.JavaMail.zimbra@mozilla.com> Message-ID: <5255AC44.5070006@mozilla.com> On 10/08/2013 02:55 PM, Keegan McAllister wrote: > I was excited to see the recent work [1] regarding link-time optimization between C or C++ and Rust code. In Servo we access JavaScript objects through small C++ functions [2] declared as extern "C". It would be great if the code for these accessors (which depends on the C++ ABI and the contents of the SpiderMonkey header files) could be inlined into Rust functions. > > The main problem I see with the approach described in [1] is that it requires a special build process for the whole Rust program. One compiles Rust to LLVM bytecode and then links using clang. So my question is: how can we make a mixed C++/Rust library which exposes LTO for the C++ components, and yet can be used like any other Rust library crate? I suppose we would have to compile the C++ with clang and then store the resulting LLVM bytecode as metadata in the library crate's shared object. Does rustc already do inlining from LLVM bytecode stored as metadata, or does it store Rust ASTs only? > > I would be interested to hear any thoughts regarding this project, in particular estimates of how difficult or time-consuming it would be. It seems to me like Servo's use case *could* be solved by simply accepting some arbitrary IR on the command line to merge into the LLVM module, without worrying about storing it in metadata. As long as none of the Rust that calls into C was generic or inlined then the C would get properly inlined. For the generic and inlined bits of Rust you could simply pass the IR again to the crate that does the generic instantiation. That sounds pretty trivial to do. From niko at alum.mit.edu Wed Oct 9 14:04:39 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 9 Oct 2013 17:04:39 -0400 Subject: [rust-dev] Mutability Overloads In-Reply-To: <52559449.9010303@mozilla.com> References: <52559449.9010303@mozilla.com> Message-ID: <20131009210439.GA3101@Mr-Bennet> On Wed, Oct 09, 2013 at 10:37:13AM -0700, Patrick Walton wrote: > Perhaps the right thing would be something like mutability > variables: `fn reflector(&M self) -> &M Reflector`. Of > course then integrating a pointer of unknown mutability introduces > borrow check issues similar to those we have with `&const`. I don't think it would be as bad. In the case of &const, we had to fear others mutating the data under your feet. In the case of &M, the data is either immutable or only mutable via the pointer you have, so it should be less painful. But I don't claim to have thought deeply about this. Niko From slabode at aim.com Wed Oct 9 15:26:47 2013 From: slabode at aim.com (SiegeLord) Date: Wed, 09 Oct 2013 18:26:47 -0400 Subject: [rust-dev] New privacy rules and crate-local scope Message-ID: <5255D827.1040608@aim.com> I'll start right away with an example. Consider this crate that could have been written using the old privacy rules: pub mod mod_a { pub struct S { priv m: int; } impl S { pub fn pub_api(&self) -> int { self.m } } mod internal { use super::S; impl S { /* This one doesn't actually work due to bugs */ pub fn crate_api_1() -> S { S{m: 0} } } pub fn crate_api_2() -> S { S{m: 0} } } } Under the old privacy rules, items were accessible within a crate if they were pub'd, regardless of the intervening privacy. Note that crate_api_1() and crate_api_2() can only be used within the crate. Under the new privacy rules, this sort of looks like this: mod internal { pub struct S { priv m: int; } impl S { pub fn pub_api(&self) -> int { self.m } } pub fn crate_api_2() -> S { S{m: 0} } } pub mod mod_a { pub use internal::S; } The general idea is that you have a top-level, private module which contains the crate-scoped API. Note that I don't think you can even write crate_api_1 anymore. Also note how the public API moved inside the internal module: in fact, pretty much everything is now placed inside it, and the public API is now re-exported elsewhere (reminiscent of the old export lists). If you weren't planning to have crate-local API, then you'd really have to restructure your code to support it... so much so, that it might be prudent to code as if you had crate-scoped API even if you don't (yet). Is my analysis incorrect? Is there a way to write crate_api_1 (i.e. a crate-scoped method) ? Is there a way to avoid moving the entire code base inside the 'internal' mod? One last note... since the new privacy rules don't mention crates, this problem becomes a bit more general, i.e. it's very tricky to isolate a particular API to a sub-tree of modules. I feel like it's almost simpler to just make everything public and rely on documentation or place everything in a single module. -SL From alex at crichton.co Wed Oct 9 20:48:39 2013 From: alex at crichton.co (Alex Crichton) Date: Wed, 9 Oct 2013 20:48:39 -0700 Subject: [rust-dev] New privacy rules and crate-local scope In-Reply-To: <5255D827.1040608@aim.com> References: <5255D827.1040608@aim.com> Message-ID: As I think was mentioned on IRC, sadly there wasn't a set of well defined privacy rules in place beforehand. What I've been able to gather is that they were a rough approximation of what was desired at one point in time, but more pressing matters led to them never really getting refined to where they were well documented and well tested. What you've described above is all correct and intended behavior. I can imagine that it's difficult to port old libraries using the old behavior, but the idea of the new rules is to as naturally as possibly expose the visibility of an item. As an an ancestor of an item, you would naturally be known to expect how your parents were implemented (because you probably implemented them), so it's perfectly find for you to reach into their private items. Otherwise, you're never expected to have knowledge of the implementation details, so all private items are hidden from you otherwise. You're correct that one of the consequences is that any crate-local apis must be rooted at the top of the crate. It's not true that they all need to be in one module, however, they can all be in separate private sibling modules. >From redoing the rules, I came to much prefer this idea of visibility to different rules for inter and intra crate apis. Noe only do the same set of rules apply for all types of visibility everywhere, but I also think that these apis are more expressive. Now the rule of thumb is basically "make it public if this is an api for a parent consumer". I realize that privacy has been a tricky topic in the history of rust, and I tried my best to write up as much documentation as I could on the topic in the manual, but if there's anything you think needs clarification, please let me know! It would be a shame common practice to be "make everything public" and then read up on whether it should actually be public or not. That being said, if the new system is indeed more of a pain then it's worth, then we're still pre-1.0 so we have a little wiggle room to tweak things as we see fit. On Wed, Oct 9, 2013 at 3:26 PM, SiegeLord wrote: > I'll start right away with an example. Consider this crate that could have > been written using the old privacy rules: > > pub mod mod_a > { > pub struct S { priv m: int; } > > impl S > { > pub fn pub_api(&self) -> int { self.m } > } > > mod internal > { > use super::S; > impl S > { > /* This one doesn't actually work due to bugs */ > pub fn crate_api_1() -> S { S{m: 0} } > } > > pub fn crate_api_2() -> S { S{m: 0} } > } > } > > Under the old privacy rules, items were accessible within a crate if they > were pub'd, regardless of the intervening privacy. Note that crate_api_1() > and crate_api_2() can only be used within the crate. Under the new privacy > rules, this sort of looks like this: > > mod internal > { > pub struct S { priv m: int; } > > impl S > { > pub fn pub_api(&self) -> int { self.m } > } > > pub fn crate_api_2() -> S { S{m: 0} } > } > > pub mod mod_a > { > pub use internal::S; > } > > The general idea is that you have a top-level, private module which contains > the crate-scoped API. Note that I don't think you can even write crate_api_1 > anymore. Also note how the public API moved inside the internal module: in > fact, pretty much everything is now placed inside it, and the public API is > now re-exported elsewhere (reminiscent of the old export lists). If you > weren't planning to have crate-local API, then you'd really have to > restructure your code to support it... so much so, that it might be prudent > to code as if you had crate-scoped API even if you don't (yet). > > Is my analysis incorrect? Is there a way to write crate_api_1 (i.e. a > crate-scoped method) ? Is there a way to avoid moving the entire code base > inside the 'internal' mod? > > One last note... since the new privacy rules don't mention crates, this > problem becomes a bit more general, i.e. it's very tricky to isolate a > particular API to a sub-tree of modules. I feel like it's almost simpler to > just make everything public and rely on documentation or place everything in > a single module. > > -SL > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From slabode at aim.com Wed Oct 9 21:58:40 2013 From: slabode at aim.com (SiegeLord) Date: Thu, 10 Oct 2013 00:58:40 -0400 Subject: [rust-dev] New privacy rules and crate-local scope In-Reply-To: References: <5255D827.1040608@aim.com> Message-ID: <52563400.2050803@aim.com> On 10/09/2013 11:48 PM, Alex Crichton wrote: > What you've described above is all correct and intended behavior. I > can imagine that it's difficult to port old libraries using the old > behavior, but the idea of the new rules is to as naturally as possibly > expose the visibility of an item. It wasn't so much that I was balking at the prospect of rewriting my code, as it was that the rewrite was ending up so voluminous and roundabout. That said, I think I came up with a solution that seems to resonate a bit better with me: pub use mod_a = internal::mod_a::external; mod internal { pub mod mod_a { pub struct S { priv m: int } pub mod external { pub use super::S; impl super::S { pub fn pub_api(&self) -> int { self.m } } } pub fn crate_api_2() -> S { S{m: 0} } } } It seems to be a pleasant inversion of what was done with the old approximate rules, except that you have to root the entire module tree in a private module to establish the visibility wall (which is still unfortunate as far as documentation goes). -SL From bobbyholley at gmail.com Thu Oct 10 04:56:40 2013 From: bobbyholley at gmail.com (Bobby Holley) Date: Thu, 10 Oct 2013 13:56:40 +0200 Subject: [rust-dev] Mutability Overloads In-Reply-To: <52559449.9010303@mozilla.com> References: <52559449.9010303@mozilla.com> Message-ID: On Wed, Oct 9, 2013 at 7:37 PM, Patrick Walton wrote: > Perhaps the right thing would be > something like mutability variables: `fn reflector(&M self) -> > &M Reflector`. Something like this, if it could be made to work, would be fine with me. I'm mostly interested in reducing boilerplate and repeated code. For now, I'm adding mut_ variants. See: https://github.com/mozilla/servo/commit/9d04be98e56f93c5ddfe6c1113707644b8ede413 From andrei at ci.ufpb.br Thu Oct 10 15:32:24 2013 From: andrei at ci.ufpb.br (=?ISO-8859-1?Q?Andrei_de_Ara=FAjo_Formiga?=) Date: Thu, 10 Oct 2013 19:32:24 -0300 Subject: [rust-dev] New privacy rules and crate-local scope In-Reply-To: <52563400.2050803@aim.com> References: <5255D827.1040608@aim.com> <52563400.2050803@aim.com> Message-ID: Maybe I'm misunderstanding something, but you don't need to put everything inside the private module. There's even an example in the manual that does something like this: // this is the crate root mod internal { pub fn internal_1() { } } pub mod external { // public functions here will be available outside the crate 2013/10/10 SiegeLord > On 10/09/2013 11:48 PM, Alex Crichton wrote: > >> What you've described above is all correct and intended behavior. I >> can imagine that it's difficult to port old libraries using the old >> behavior, but the idea of the new rules is to as naturally as possibly >> expose the visibility of an item. >> > > It wasn't so much that I was balking at the prospect of rewriting my code, > as it was that the rewrite was ending up so voluminous and roundabout. That > said, I think I came up with a solution that seems to resonate a bit better > with me: > > pub use mod_a = internal::mod_a::external; > > mod internal > > { > pub mod mod_a > { > pub struct S { priv m: int } > > pub mod external > { > pub use super::S; > impl super::S > > { > pub fn pub_api(&self) -> int { self.m } > } > } > > pub fn crate_api_2() -> S { S{m: 0} } > } > } > > It seems to be a pleasant inversion of what was done with the old > approximate rules, except that you have to root the entire module tree in a > private module to establish the visibility wall (which is still unfortunate > as far as documentation goes). > > > -SL > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrei at ci.ufpb.br Thu Oct 10 15:33:28 2013 From: andrei at ci.ufpb.br (=?ISO-8859-1?Q?Andrei_de_Ara=FAjo_Formiga?=) Date: Thu, 10 Oct 2013 19:33:28 -0300 Subject: [rust-dev] New privacy rules and crate-local scope In-Reply-To: References: <5255D827.1040608@aim.com> <52563400.2050803@aim.com> Message-ID: (hit send by mistake) Maybe I'm misunderstanding something, but you don't need to put everything inside the private module. There's even an example in the manual that does something like this: // this is the crate root mod internal { pub fn internal_1() { } } pub mod external { // public functions here will be available outside the crate use internal; // pub functions in internal are now usable here pub fn pub_api_1() { internal::internal_1() } } 2013/10/10 Andrei de Ara?jo Formiga > Maybe I'm misunderstanding something, but you don't need to put everything > inside the private module. There's even an example in the manual that does > something like this: > > // this is the crate root > mod internal > { > pub fn internal_1() { } > } > > pub mod external > { > // public functions here will be available outside the crate > > > > 2013/10/10 SiegeLord > >> On 10/09/2013 11:48 PM, Alex Crichton wrote: >> >>> What you've described above is all correct and intended behavior. I >>> can imagine that it's difficult to port old libraries using the old >>> behavior, but the idea of the new rules is to as naturally as possibly >>> expose the visibility of an item. >>> >> >> It wasn't so much that I was balking at the prospect of rewriting my >> code, as it was that the rewrite was ending up so voluminous and >> roundabout. That said, I think I came up with a solution that seems to >> resonate a bit better with me: >> >> pub use mod_a = internal::mod_a::external; >> >> mod internal >> >> { >> pub mod mod_a >> { >> pub struct S { priv m: int } >> >> pub mod external >> { >> pub use super::S; >> impl super::S >> >> { >> pub fn pub_api(&self) -> int { self.m } >> } >> } >> >> pub fn crate_api_2() -> S { S{m: 0} } >> } >> } >> >> It seems to be a pleasant inversion of what was done with the old >> approximate rules, except that you have to root the entire module tree in a >> private module to establish the visibility wall (which is still unfortunate >> as far as documentation goes). >> >> >> -SL >> ______________________________**_________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/**listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Thu Oct 10 15:40:49 2013 From: slabode at aim.com (SiegeLord) Date: Thu, 10 Oct 2013 18:40:49 -0400 Subject: [rust-dev] New privacy rules and crate-local scope In-Reply-To: References: <5255D827.1040608@aim.com> <52563400.2050803@aim.com> Message-ID: <52572CF1.1050808@aim.com> On 10/10/2013 06:33 PM, Andrei de Ara?jo Formiga wrote: > (hit send by mistake) > > Maybe I'm misunderstanding something, but you don't need to put > everything inside the private module. There's even an example in the > manual that does something like this: > > // this is the crate root > mod internal > { > pub fn internal_1() { } > } > > pub mod external > { > // public functions here will be available outside the crate > > use internal; // pub functions in internal are now usable here > > pub fn pub_api_1() { internal::internal_1() } > } The external API may need to access private implementation. Writing an internal API just so that the external API can access that implementation seems even more disruptive than sticking everything into a private module. E.g. in my example you'd have to write an accessor for the member m of struct S. -SL From banderson at mozilla.com Thu Oct 10 21:17:00 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 10 Oct 2013 21:17:00 -0700 Subject: [rust-dev] Refactoring the milestones on the issue tracker Message-ID: <52577BBC.8050808@mozilla.com> Hey, Rustlings! During the bug triage meeting today we decided to make a few changes to how our milestones on GitHub are organized in order to be better oriented towards our goals for the near future. Recently the core team has been putting a lot of thought into what it's going to take to get a major, stable release of Rust finished, and it's become clear that the way we've been organizing the milestones is not representative of the actual work we believe must be done. We previously triaged the entire set of issues into 5 categories: well-defined, backwards compatible, well-covered, feature complete, and production ready. It's not clear though how useful this exercise was; certainly figuring out the set of issues with backwards-compatibility implications was important, but it appears both that the scope of all these milestones together is much greater than anything we can accomplish in a reasonable timeframe, and also that there were many issues triaged into the backwards-compatible milestone that don't necessarily need to be resolved. In the end, this scheme did not well capture the actual work that we need to do. For reference this approach was previously described here: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003668.html Today we're simplifying our triage scheme in the following ways: * The previous 'maturity milestones' have been converted to 'P' (priority) tags on the issue tracker: P-backcompat-lang, P-backcompat-libs, P-high, and P-low; and all of the previously triaged issues have been tagged. Converting from milestones to tags emphasizes that these are simply categories, not singular goals that occur in any specific order, and the naming emphasizes that what we mostly care about for completing a major release is backwards compatibility of the language and libraries. * We now have an upcoming [milestone] called "first major release". This is tentatively Rust 1.0 and is intended to represent the complete set of work that we need to do to get a major release out of the door. Unlike our typical point releases, this will be a feature-based release. * We'll keep the [nomination] process intact, but instead of triaging bugs into maturity milestones, they will be given P-tags and possibly assigned to the first major release milestone. The [criteria] for nomination is still the same as for the previous maturity milestones. [milestone]: https://github.com/mozilla/rust/issues/milestones [nomination]: https://github.com/mozilla/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage [criteria]: https://github.com/mozilla/rust/wiki/Note-priority-issue-criteria In the past few weeks we've already triaged all the "well-defined" and "backwards compatible" issues to determine the subset to move into the "first major release" milestone. The remaining issues from the maturity milestones are temporarily tagged P-high-untriaged and will be re-triaged to determine which belong on the release milestone. It's not clear where the P-low tag fits into the triage process yet, but conceivably we'll expand triage to include all bugs in the future, not just 'nominated' bugs, giving all bugs a P-tag. OK, I hope that's clear, relatively simple, and not too objectionable to anybody. As to the actual criteria for what is in-scope and what is out-of-scope for the first major release of Rust, I'd like to hold off that discussion a little longer. Some time soon we'll have another thread to discuss release plans in more detail. Regards, Brian From corey at octayn.net Sun Oct 13 00:31:01 2013 From: corey at octayn.net (Corey Richardson) Date: Sun, 13 Oct 2013 03:31:01 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Welcome to another issue of *This Week in Rust*. This week introduces raw string literals, the removal of the `rust` tool, feature gating, and the privacy overhaul. # What's cooking on master? Only 51 PRs were merged this week, though the ones that were were fairly large. ## Breaking changes - Visibility and privacy have been defined, and the new semantics are slightly incompatible with the old. The details are [here](https://github.com/mozilla/rust/pull/9735). - Feature gating has been [added to the compiler](https://github.com/mozilla/rust/pull/9703). This allows us to mask language features that we don't want to commit to for 1.0. The compiler will tell you when you are using an "experimental" feature. The current experimentals are glob imports, macro definitions, and struct-like variants in enums. This is an important step forward for 1.0 which, [apparently](http://www.reddit.com/r/rust/comments/1o90f9/fn_types_in_rust_take_3/ccq8qev), is right around the corner. - The `rust` tool [has been removed](https://github.com/mozilla/rust/pull/9785). - `Option`'s API has been [massively simplified](https://github.com/mozilla/rust/pull/9359), and changed to be composable. - Strings are [no longer allowed to be modified in safe code](https://github.com/mozilla/rust/pull/9750). Things like `let s = ~"abcdefg"; s[4] = 0x99;` are now rejected. This is because it allows one to create invalid (non-UTF8) string values. - `extra::rc` has [graduated to `std::rc`](https://github.com/mozilla/rust/pull/9794). - `extra::tempfile::mkdtemp` [has been replaced with an RAII wrapper](https://github.com/mozilla/rust/pull/9802). - `std::rand` [has been improved](https://github.com/mozilla/rust/pull/9695), but changes the public API of Rng a bit. - `IntConvertible` has been removed in favor of [`ToPrimitive` and `FromPrimitive`](https://github.com/mozilla/rust/pull/9250), which can be derived for enums, making interacting with C APIs substantially more [DRY](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself). ## Other changes - [Raw strings](https://github.com/mozilla/rust/pull/9674) are now supported. The basic syntax is `r"Foo"`, but also `r###"Foo"###`, for arbitrary nesting of raw strings. - rustpkg's remote fetching [is fixed](https://github.com/mozilla/rust/pull/9741), but [other problems](https://github.com/mozilla/rust/issues/9482) prevent it from being fully usable right now. - debuginfo namespace handling [has been unified](https://github.com/mozilla/rust/pull/9658), and marks the ability to build all of Rust (libstd, libextra, compiler and tools) with debuginfo, which is very awesome. - Small structs [are immediate](https://github.com/mozilla/rust/pull/9759). - When there are unbalanced delimiters, [the opening delimiters leading up to it](https://github.com/mozilla/rust/pull/9756) are printed, avoiding the "Expected a }, saw EOF at line 9001" problem. - libuv and jemalloc are only [built once, rather than once per stage](https://github.com/mozilla/rust/pull/9772). - Macros [now take attributes](https://github.com/mozilla/rust/pull/9753) and, in turn, can be documented. - In the opposite direction, [macros can now expand to items with attributes](https://github.com/mozilla/rust/pull/9783). - There were some [minor logging changes](https://github.com/mozilla/rust/pull/9664), the biggest result of which is that inlined functions won't be logged by the modules they're inlined into. - [`std::rt::io::native` has been implemented](https://github.com/mozilla/rust/pull/9749). The idea of this is to live in `std::io::native` and to use the OS's native APIs rather than libuv, and also to not require the scheduler or any other runtime support. - rustpkg [marks checked out repos as read-only](https://github.com/mozilla/rust/pull/9732), to prevent modifications. # Weekly Meeting The [weekly meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-10-08) discussed some administrative things, the removal of crypto code, the removal of the `rust` tool, and functions. # Announcements etc - [rust-fuse](http://www.reddit.com/r/rust/comments/1o35ns/fuse_userspace_library_in_rust/) \- a FUSE userspace library in Rust. This is pure Rust, not using libfuse. - [ears](http://www.reddit.com/r/rust/comments/1o46cv/ears_a_simple_library_for_playing_sounds/) \- a simple library for playing sounds. - [rustic](https://github.com/pcmattman/rustic) - another operating system project. - [Refactoring the milestones on the issue tracker](https://mail.mozilla.org/pipermail/rust-dev/2013-October/005981.html). - [Fn Types in Rust, Take 3](http://smallcultfollowing.com/babysteps/blog/2013/10/10/fn-types-in-rust/) \- another attempt at tackling the problems with closures. - mcpherrin in `#rust` says "Hello, everyone!" From banderson at mozilla.com Mon Oct 14 15:29:02 2013 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 14 Oct 2013 15:29:02 -0700 Subject: [rust-dev] Improvements to the Rust code of conduct Message-ID: <525C702E.9020803@mozilla.com> Hey Rusties! We've got a truly delightful community here, and as we grow we want to keep it that way. Today we're making two small additions to our [code of conduct] to fill in some gaps. The relevant changes are: * To bullet 6 we've added, "in particular, we don't tolerate behavior that excludes people in socially marginalized groups." * A new bullet has been added that says: "Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the Rust core team immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back." This last point emphasizes that there is recourse for anybody who feels like they are being mistreated by other community members. Thanks, and keep being awesome. -Brian [code of conduct]: https://github.com/mozilla/rust/wiki/Note-development-policy#conduct From catamorphism at gmail.com Tue Oct 15 11:28:15 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue, 15 Oct 2013 11:28:15 -0700 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available Message-ID: Hi all, The audio recording for my June 2013 talk at Open Source Bridge, "Rust: A Friendly Introduction", is now available: http://opensourcebridge.org/sessions/970 As far as I know, there was no video recording, but the slides are linked from: http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From zokier at gmail.com Tue Oct 15 12:53:13 2013 From: zokier at gmail.com (Torste Aikio) Date: Tue, 15 Oct 2013 22:53:13 +0300 Subject: [rust-dev] type `&~A:Send` does not implement any method in scope named `a` Message-ID: This code gives "error: type `&~A:Send` does not implement any method in scope named `a`" when compiled with rustc 0.9-pre (c8e77d5 2013-10-14 07:26:47 -0700). trait A { fn a(); } struct B; impl A for B { fn a() { println!("a()"); } } struct C { av: ~[~A] } impl C { fn process(&self) { for a in self.av.iter() { a.a(); // <-- error here } } } fn main() { let c = C { av: ~[~B as ~A] }; c.process(); } Could someone explain why and how to work around the issue? /Torste Aikio ps. I hope this is right place to ask From jeaye at arrownext.com Tue Oct 15 13:40:54 2013 From: jeaye at arrownext.com (Jeaye) Date: Tue, 15 Oct 2013 13:40:54 -0700 Subject: [rust-dev] type `&~A:Send` does not implement any method in scope named `a` In-Reply-To: References: Message-ID: <20131015204054.GA1085@arrow.hsd1.ca.comcast.net> > trait A { > fn a(); > } > Could someone explain why and how to work around the issue? Your function `a` is being treated as a method (member function), but it does not take `&self` or `&mut self` as the first argument. From m.fletcher at theplanet.ca Tue Oct 15 19:40:34 2013 From: m.fletcher at theplanet.ca (Michael Fletcher) Date: Tue, 15 Oct 2013 20:40:34 -0600 Subject: [rust-dev] Cannot find Trait Implementation Message-ID: <525DFCA2.1050604@theplanet.ca> Hi I am having problems getting a simple program to compile and i am out of ideas. > problem.rs:13:27: 13:46 error: failed to find an implementation of trait std::rt::io::Reader for @std::rt::io::net::tcp::TcpStream > problem.rs:13 let buffered_reader = @BufferedReader::new(stream); Is there any magic to how a trait impl is located? Is there any specific tracing I could enable? Is there a way to dump the symbols out of libstd? ---- cut use std::rt::io::Reader; use std::rt::io::net::ip::SocketAddr; use std::rt::io::net::ip::Ipv4Addr; use std::rt::io::net::tcp::TcpStream; use std::rt::io::buffered::BufferedReader; fn main() { let ip = Ipv4Addr(192, 168, 0, 113); let addr = SocketAddr{ip:ip, port:80}; let mut stream = @TcpStream::connect(addr).unwrap(); // problem.rs:13:27: 13:46 error: failed to find an implementation of trait std::rt::io::Reader for @std::rt::io::net::tcp::TcpStream // problem.rs:13 let buffered_reader = @BufferedReader::new(stream); let buffered_reader = @BufferedReader::new(stream); } ---- end cut From micah at micahchalmer.net Tue Oct 15 19:52:28 2013 From: micah at micahchalmer.net (Micah Chalmer) Date: Tue, 15 Oct 2013 22:52:28 -0400 Subject: [rust-dev] Cannot find Trait Implementation In-Reply-To: <525DFCA2.1050604@theplanet.ca> References: <525DFCA2.1050604@theplanet.ca> Message-ID: <81823743-527B-48DC-8C4F-48D8A7FB67D5@micahchalmer.net> It's looking for a Reader impl for @TcpStream, which does not exist. The implementation is for TcpStream (no @). BufferedReader needs to own its underlying stream, and therefore takes it by value, not as a shared box. If you take out the @ when you declare the stream variable it'll compile (with some warnings that are pretty self-explanatory.) -Micah On Oct 15, 2013, at 10:40 PM, Michael Fletcher wrote: > Hi > > I am having problems getting a simple program to compile and i am out of ideas. > > > problem.rs:13:27: 13:46 error: failed to find an implementation of trait std::rt::io::Reader for @std::rt::io::net::tcp::TcpStream > > problem.rs:13 let buffered_reader = @BufferedReader::new(stream); > > Is there any magic to how a trait impl is located? Is there any specific tracing I could enable? Is there a way to dump the symbols out of libstd? > > > ---- cut > use std::rt::io::Reader; > use std::rt::io::net::ip::SocketAddr; > use std::rt::io::net::ip::Ipv4Addr; > use std::rt::io::net::tcp::TcpStream; > use std::rt::io::buffered::BufferedReader; > > fn main() { > let ip = Ipv4Addr(192, 168, 0, 113); > let addr = SocketAddr{ip:ip, port:80}; > let mut stream = @TcpStream::connect(addr).unwrap(); > > // problem.rs:13:27: 13:46 error: failed to find an implementation of trait std::rt::io::Reader for @std::rt::io::net::tcp::TcpStream > // problem.rs:13 let buffered_reader = @BufferedReader::new(stream); > let buffered_reader = @BufferedReader::new(stream); > } > ---- end cut > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From zargony at zargony.com Wed Oct 16 04:25:49 2013 From: zargony at zargony.com (Andreas Neuhaus) Date: Wed, 16 Oct 2013 13:25:49 +0200 Subject: [rust-dev] How to manage multiple interacting I/O streams? Message-ID: <1F51D034-97BE-4AAB-80D2-9E52EB8AF628@zargony.com> Hi everybody, after using Rust for the last few months to get used to it (I really love it), I recently started to play around with the new I/O, especially the networking stuff. I'd say that I'm familiar with how std::rt.:io, std::task and std::comm works. However I'm not sure how I should handle multiple I/O streams. Let's say I'm building a simple chat server where people can connect on a TCP port, set a name and broadcast messages to everyone else. For each accepted incoming stream, I'd spawn a new task and pass the stream to it. Or actually I'd create a struct Connection that contains the stream and connection related information, like the user's name. Every child task would run a loop that reads a line from its stream and processes it. It should either broadcast to all other connections or do something else like setting the name. How can one connection write stuff to the others if it doesn't know about them? If I use a chan/port for every connection to report text to be broadcasted back to the main task, the broadcast needs to take place in the main task. But the main task can not hold a list of connections since every connection has moved to its own task where the reading loop takes place. There could be a second chan/port for every connection that allows the main task to send something to a connection, but how would a connection's task be supposed to recv from the port when it's generally waiting to read from the stream most time? I'm also unsure how the main task should be able to iterate all connection, e.g. if somebody wants to list all connected users. I'd appreciate any hint on how this can be done the Rust-way. (I thereby want to prevent using @-boxes at all) Thanks, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Oct 16 11:02:18 2013 From: alex at crichton.co (Alex Crichton) Date: Wed, 16 Oct 2013 11:02:18 -0700 Subject: [rust-dev] Should I/O use conditions? Message-ID: There have been some recent grumblings [1] about the use of conditions in the new runtime's I/O system. It was decided awhile back [2] that we'd try out the use of conditions for error handling in the new runtime. This has manifested itself in the `io_error` and `read_error` conditions inside of the `rt::io` module. I've done some recent work [3][4] in removing std::io, and I've personally found the use of conditions a little painful. Here's a few of the problems that I ran into: * Do you catch io_error or read_error? Catching both is really painful, and remembering which one to catch is sometimes more painful. This could be alleviated by having a read_error raise on an io_error if there is no handler registered, so this is certainly not a show stopper. * If you want to catch an error, it's pretty ergonomically painful let mut err = None; let ret = do io::io_error::cond.trap(|e| err = Some(e)).inside { // some i/o operation }; match err { None => {} // yay we succeeded Some(e) {} // oh no, an error! } This seems like a lot of verbage for doing something as simple as checking to see whether an i/o operation resulted in an error or not. * Using closures prevents certain kinds of movements between values. This is a known limitation of closures today and may be alleviated by the closure redesign, however. This isn't quite a show stopper, but it is another pain point. * The "blanket error condition" isn't really being used for what I thought conditions were intended for, which is somehow continuing the work at the raise site using the result of the condition. Because the io error conditions both return (), then there's not really anything you can do but hope to squirrel away the conditions somewhere. These various reasons have added to the pain points when dealing with error handling in the new runtime. I certainly don't think that we should remove conditions entirely (they're an effective error handling system for many purposes), but for the use case of simply reporting errors I don't feel that they're quite appropriate. All that being said, we're not making much progress without an idea of where to possibly go next. Right now, the current idea is to create an Error trait and have I/O operations return Result instead of Option. This would mean that Reader/Writer and other associated traits would be defined for Result where T: Trait (so you could still chain operations easily), and you could very easily check for an I/O error. This is all still pretty early-stage, though, and we certainly haven't committed to anything just yet. I wanted to canvas everyone to see what others' opinions are about using conditions for error handling. I'm certainly not the only use-case so far! [1] https://github.com/mozilla/rust/issues/9795 [2] https://mail.mozilla.org/pipermail/rust-dev/2013-April/003746.html [3] https://github.com/mozilla/rust/pull/9749 [4] https://github.com/mozilla/rust/pull/9888 From pwalton at mozilla.com Wed Oct 16 11:16:44 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 16 Oct 2013 11:16:44 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: Message-ID: <525ED80C.8060501@mozilla.com> On 10/16/13 11:02 AM, Alex Crichton wrote: > All that being said, we're not making much progress without an idea of where to > possibly go next. Right now, the current idea is to create an Error trait and > have I/O operations return Result instead of Option. This would > mean that Reader/Writer and other associated traits would be defined for > Result where T: Trait (so you could still chain operations easily), > and you could very easily check for an I/O error. +1 for the use of Result. Yay monads! Patrick From kevin at sb.org Wed Oct 16 11:20:21 2013 From: kevin at sb.org (Kevin Ballard) Date: Wed, 16 Oct 2013 11:20:21 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <525ED80C.8060501@mozilla.com> References: <525ED80C.8060501@mozilla.com> Message-ID: +1 here too. I agree with what Alex said about conditions. They're useful for when you can actually recover from the error gracefully, but for generic error reporting they're kind of a PITA. -Kevin On Oct 16, 2013, at 11:16 AM, Patrick Walton wrote: > On 10/16/13 11:02 AM, Alex Crichton wrote: >> All that being said, we're not making much progress without an idea of where to >> possibly go next. Right now, the current idea is to create an Error trait and >> have I/O operations return Result instead of Option. This would >> mean that Reader/Writer and other associated traits would be defined for >> Result where T: Trait (so you could still chain operations easily), >> and you could very easily check for an I/O error. > > +1 for the use of Result. Yay monads! > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From sfackler at gmail.com Wed Oct 16 12:54:24 2013 From: sfackler at gmail.com (Steven Fackler) Date: Wed, 16 Oct 2013 12:54:24 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525ED80C.8060501@mozilla.com> Message-ID: +1 on getting rid of IO conditions. I'd be okay with a Result based API. If we change it over, we should have a tutorial that goes over how to deal with Results to make it less painful for people (e.g. using or_return! macros). I'm not a huge fan of implementing Reader for Result, etc. One thing that I've tried that I kind of like is having separate `foo` and `try_foo` methods, where `try_foo` returns a Result and `foo` is a wrapper around `try_foo` that fails with a good error message if `foo` returned Err. It makes it more explicit to users of the API what's going to happen, and when failure will occur if there's an error. A failed Result can hang around for a long time before any methods are called on it. It can also allow for slightly better failure messages. For example, if `prepare` fails, its error message can print the query string without having to copy it into a new ~str. In the IO case, you could keep this cost free to implement by having `Reader` contain a default implementation for `read` and only require users to implement `try_read`. See http://docs.octayn.net/postgres/struct.PostgresConnection.html for some examples. Steven Fackler On Wed, Oct 16, 2013 at 11:20 AM, Kevin Ballard wrote: > +1 here too. I agree with what Alex said about conditions. They're useful > for when you can actually recover from the error gracefully, but for > generic error reporting they're kind of a PITA. > > -Kevin > > On Oct 16, 2013, at 11:16 AM, Patrick Walton wrote: > > > On 10/16/13 11:02 AM, Alex Crichton wrote: > >> All that being said, we're not making much progress without an idea of > where to > >> possibly go next. Right now, the current idea is to create an Error > trait and > >> have I/O operations return Result instead of Option. This > would > >> mean that Reader/Writer and other associated traits would be defined for > >> Result where T: Trait (so you could still chain operations > easily), > >> and you could very easily check for an I/O error. > > > > +1 for the use of Result. Yay monads! > > > > Patrick > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Wed Oct 16 13:44:16 2013 From: bill_myers at outlook.com (Bill Myers) Date: Wed, 16 Oct 2013 20:44:16 +0000 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: Message-ID: What about the idea of making Result cause task failure if it is destroyed in the error case? (as opposed to destructuring it) This just needs a simple language change to add an attribute that would be applied on Result to declare that it's OK to destructure it and cause drop() to not be called. In addition, maybe some EH syntax sugar like the one I proposed in http://www.mail-archive.com/rust-dev at mozilla.org/msg04093.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Wed Oct 16 14:12:50 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 16 Oct 2013 14:12:50 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: Message-ID: <525F0152.4090403@mozilla.com> On 10/16/13 1:44 PM, Bill Myers wrote: > What about the idea of making Result cause task failure if it is > destroyed in the error case? (as opposed to destructuring it) For a long time now I've been wanting to make unused non-unit return values a warning. I think this would be a perfect time to do that... Patrick From kevin at sb.org Wed Oct 16 14:53:55 2013 From: kevin at sb.org (Kevin Ballard) Date: Wed, 16 Oct 2013 14:53:55 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <525F0152.4090403@mozilla.com> References: <525F0152.4090403@mozilla.com> Message-ID: <8160EA50-30B5-4016-B541-2935C4244B1D@sb.org> This seems rather heavy-weight to me. I?d much prefer if such a thing was opt-in, e.g. by a function attribute that says the return value must be handled. -Kevin On Oct 16, 2013, at 2:12 PM, Patrick Walton wrote: > On 10/16/13 1:44 PM, Bill Myers wrote: >> What about the idea of making Result cause task failure if it is >> destroyed in the error case? (as opposed to destructuring it) > > For a long time now I've been wanting to make unused non-unit return values a warning. I think this would be a perfect time to do that... > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From me at chrismorgan.info Wed Oct 16 15:31:06 2013 From: me at chrismorgan.info (Chris Morgan) Date: Thu, 17 Oct 2013 09:31:06 +1100 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <525F0152.4090403@mozilla.com> References: <525F0152.4090403@mozilla.com> Message-ID: On Oct 17, 2013 8:12 AM, "Patrick Walton" wrote: > For a long time now I've been wanting to make unused non-unit return values a warning. I think this would be a perfect time to do that... I would love this to be the case. It's the biggest problem I had with Go's error handling: that it's far too easy to just ignore a return value accidentally. (Truth to tell, the problem is far worse in Go because for some reason they decided you could take not all of the return values, e.g. for a func returning (T, err), `t = f()` will silently discard the err; this has been a decision that has baffled me; I'm glad we have generics and Result and tuples-as-real-types to fix that bad idiom!) Truly explicit is better than implicit. I have three remaining questions on this feature: 1. Is there a functional difference between the lines `let _ = f()` and `let _foo = f()` (assuming no usage of the variable)? These will probably become common if this check is in place. 2. When will Drop happen? I suspect this would make it happen at the end of the callee block, whereas silent ignoring probably before returning execution to the callee? 3. Would such a thing be able to be overridden with something along the lines of #[allow(unused_return_values)]? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Wed Oct 16 15:38:01 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 16 Oct 2013 15:38:01 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> Message-ID: <525F1549.5060304@mozilla.com> On 10/16/13 3:31 PM, Chris Morgan wrote: > 1. Is there a functional difference between the lines `let _ = f()` and > `let _foo = f()` (assuming no usage of the variable)? These will > probably become common if this check is in place. There's no difference except that "let _" runs the destructor immediately whereas "let _foo" runs the destructor at the end of the block. (This is admittedly subtle.) > 2. When will Drop happen? I suspect this would make it happen at the end > of the callee block, whereas silent ignoring probably before returning > execution to the callee? See above. > 3. Would such a thing be able to be overridden with something along the > lines of #[allow(unused_return_values)]? Yes, and on a per-callee basis as well. (Lots of C functions want return values to be ignorable, so this should be able to be specified.) Patrick From cadencemarseille at gmail.com Wed Oct 16 16:10:05 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Wed, 16 Oct 2013 19:10:05 -0400 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: References: Message-ID: Hi Tim, Thanks for posting these. I haven't listened to the audio, but I read through the slides and I like your presentation. For me, it is a good reminder of why Rust is so cool. I don't know about other users (survey time, anyone? [?]), but my background is mostly C++ and Java. The notes about C++ vs. Rust are helpful. Cadence On Tue, Oct 15, 2013 at 2:28 PM, Tim Chevalier wrote: > Hi all, > > The audio recording for my June 2013 talk at Open Source Bridge, > "Rust: A Friendly Introduction", is now available: > > http://opensourcebridge.org/sessions/970 > > As far as I know, there was no video recording, but the slides are linked > from: > > http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction > > Cheers, > Tim > > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Being queer is not about a right to privacy; it is about the freedom > to be public, to just be who we are." -- anonymous, June 1990 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 330.gif Type: image/gif Size: 96 bytes Desc: not available URL: From loebel.marvin at gmail.com Wed Oct 16 16:10:26 2013 From: loebel.marvin at gmail.com (=?ISO-8859-1?Q?Marvin_L=F6bel?=) Date: Thu, 17 Oct 2013 01:10:26 +0200 Subject: [rust-dev] Proposal for macro invocation sugar Message-ID: <525F1CE2.1020008@gmail.com> Hello! I was thinking a bit about macros, and I had an idea for a kind of syntactic sugar that might be useful to have. I also posted this to the issue tracker at https://github.com/mozilla/rust/issues/9894. # Current situation Right now, rust knows about two kinds of macro invocation: IDENT!(...) IDENT! IDENT (...) The latter one is just used by `macro_rules!` right now, and seems kinda out of place because of that. Additionally, just being restricted to `IDENT!(...)` means that, while you can define macros just fine, the resulting invocation syntax often looks a bit weird because of the need for the outer `()` pair. For example, if you want to write some kind of custom `match` macro you ideally want a syntax like `macro! EXPR { CASES... }`, but in practice are forced to decide between redundant, deeply nested brackets or weird syntax if you want to reduce the brackets: ~~~ my_match!( foo().bar().baz() { case 1 => ... case 2 => ... ... } ) my_match!(foo().bar().baz() cases: case 1 => ... case 2 => ... ... ) ~~~ # Proposal We can't just allow macros to accept different syntax like `IDENT! EXPR ( ... )`, because it would create ambiguity in the parser, but it occurred to me that we _can_ provide syntactic sugar for transforming 'nicer looking' variants into the regular `IDENT!(...)` syntax. Basically, I'm thinking of leveraging the bang in a macro invocation to annotate how many following bracket pairs to group into one regular macro invocation: ~~~ IDENT!! (...) (...) => desugaring => IDENT!((...) (...)) IDENT!!! (...) (...) (...) => desugaring => IDENT!((...) (...) (...)) ... etc ~~~ The number of bangs could become confusing fast, but I don't expect that macros with more than two bracket groups are going to be common. And because it would just be sugar, you could always write it as the regular form. # Advantages There are a number of advantages I see with this proposal: 1. The two macro invocation forms can be folded into one: ~~~ IDENT!(...) => IDENT!(...) IDENT! IDENT (...) => IDENT!! (IDENT) (...) == IDENT!((IDENT) (...)) ~~~ 2. Custom syntax can become nicer looking, especially for control structures. Looking at the `my_match` example: ~~~ my_match!! (foo().bar().baz()) { case 1 => ... case 2 => ... ... } ~~~ ... which looks more natural than any the two options outlined above. 3. It's pure syntactic sugar, which means it's easy to implement and reason about. All `libsyntax` needs to do is to consume a list of bracket-counted token trees equal to the number of bangs, and introduce an artificial outer bracket pair if the number is higher than one. 4. It's just invocation sugar, which means there is no difference between defining a macro that uses this vs one that doesn't - you just declare them all assuming the explicit outer `()` pair. # Potential issues The possible issues I can see with this are confusing error messages if the number of bangs is wrong, and uncertainty about which brackets belong to a macro invocation and which are regular rust code if their contents become big and/or their number become high. However, in theory rust might be able to provide good error messages for the first one, because if the macro name is right you'd get an `No rules expected this ...` error, and there could be some heuristics for recognizing cases where the user has do add/remove bangs to match the macro definition. And the second one can likely be managed by syntax highlighting, and by the usual convention of not abusing the syntax to the point where it becomes illegible. # Backwards compatibility Adding this sugar would be backwards compatible because it doesn't change any existing macro syntax, however if `IDENT! IDENT (...)` ends up obsolete through this, that would break existing uses of `macro_rules!` - but macros are behind a feature flag anyway at this point, so it wouldn't matter as much. From oren at ben-kiki.org Wed Oct 16 21:30:03 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Thu, 17 Oct 2013 07:30:03 +0300 Subject: [rust-dev] Proposal for macro invocation sugar In-Reply-To: <525F1CE2.1020008@gmail.com> References: <525F1CE2.1020008@gmail.com> Message-ID: In general I'd favor anything that would help with https://github.com/mozilla/rust/issues/9358 - that is, allow more eDSL-ish macros. Writing `foo!!(...) { ... }` has the cost of the extra `!` but that really isn't too bad. That said, I wonder why do macro invocations require the outer set of parenthesis? Since a macro is expressed in terms of parser rules (expressions, identifiers, tokens, etc.), isn't it unambiguous to allow macros to be invoked without the outer `()`? E.g.: macro_rules! foo ( (bar: $expr :<: baz: $expr) => ..., ) Today, one would use it as in `f(foo!(1 :<: 2), 3)`. But suppose one could somehow indicate the outer `()` were never to be used for this macro (say writing `syntax_rules!` instead of `macro_rules!`, or by some other extension of the `macro_rules!` notation), then parsing `f(foo! 1 :<: 2, 3)` would be unambiguous - assuming we (1) strictly use greedy parsing of $expr etc. and (2) always expand a later macro before parsing and expanding earlier macros, where later and earlier are in source text order. This strategy makes irrelevant the issue of determining the nesting of such macros while "doing the right thing" with a simple deterministic rule. This would probably be more complex to implement than the multiple-`!` proposal, but would allow for more generic patterns. For example, allowing to omit the outer `()` would allow invoking `my_match! pattern => action`; if I understand it correctly, using `!!` would only allow for writing `my_match!! pattern action`. At any rate, this is just as an idea - like I said, I'd like anything that would allow me to write `foo!(...) { ... }` (or `foo!!(...) { ... }`, or something along these lines). Writing `foo!(..., { ... })` just seems ugly to me... On Thu, Oct 17, 2013 at 2:10 AM, Marvin L?bel wrote: > Hello! I was thinking a bit about macros, and I had an idea for a kind of > syntactic sugar that might be useful to have. I also posted this to the > issue tracker at https://github.com/mozilla/**rust/issues/9894 > . > > # Current situation > > Right now, rust knows about two kinds of macro invocation: > > IDENT!(...) > IDENT! IDENT (...) > > The latter one is just used by `macro_rules!` right now, and seems kinda > out of place because of that. > > Additionally, just being restricted to `IDENT!(...)` means that, while you > can define macros just fine, the resulting invocation syntax often looks a > bit weird because of the need for the outer `()` pair. > > For example, if you want to write some kind of custom `match` macro you > ideally want a syntax like `macro! EXPR { CASES... }`, but in practice are > forced to decide between redundant, deeply nested brackets or weird syntax > if you want to reduce the brackets: > > ~~~ > my_match!( > foo().bar().baz() { > case 1 => ... > case 2 => ... > ... > } > ) > > my_match!(foo().bar().baz() cases: > case 1 => ... > case 2 => ... > ... > ) > ~~~ > > # Proposal > > We can't just allow macros to accept different syntax like `IDENT! EXPR ( > ... )`, because it would create ambiguity in the parser, but it occurred to > me that we _can_ provide syntactic sugar for transforming 'nicer looking' > variants into the regular `IDENT!(...)` syntax. > > Basically, I'm thinking of leveraging the bang in a macro invocation to > annotate how many following bracket pairs to group into one regular macro > invocation: > > ~~~ > IDENT!! (...) (...) => desugaring => IDENT!((...) (...)) > IDENT!!! (...) (...) (...) => desugaring => IDENT!((...) (...) (...)) > ... etc > ~~~ > > The number of bangs could become confusing fast, but I don't expect that > macros with more than two bracket groups are going to be common. And > because it would just be sugar, you could always write it as the regular > form. > > # Advantages > > There are a number of advantages I see with this proposal: > > 1. The two macro invocation forms can be folded into one: > ~~~ > IDENT!(...) => IDENT!(...) > IDENT! IDENT (...) => IDENT!! (IDENT) (...) == IDENT!((IDENT) (...)) > ~~~ > > 2. Custom syntax can become nicer looking, especially for control > structures. > Looking at the `my_match` example: > ~~~ > my_match!! (foo().bar().baz()) { > case 1 => ... > case 2 => ... > ... > } > ~~~ > ... which looks more natural than any the two options outlined above. > > 3. It's pure syntactic sugar, which means it's easy to implement and > reason about. > All `libsyntax` needs to do is to consume a list of bracket-counted > token trees > equal to the number of bangs, and introduce an artificial outer bracket > pair if > the number is higher than one. > > 4. It's just invocation sugar, which means there is no difference between > defining a > macro that uses this vs one that doesn't - you just declare them all > assuming the > explicit outer `()` pair. > > # Potential issues > > The possible issues I can see with this are confusing error messages if > the number of bangs is wrong, and uncertainty about which brackets belong > to a macro invocation and which are regular rust code if their contents > become big and/or their number become high. > > However, in theory rust might be able to provide good error messages for > the first one, because if the macro name is right you'd get an `No rules > expected this ...` error, and there could be some heuristics for > recognizing cases where the user has do add/remove bangs to match the macro > definition. > > And the second one can likely be managed by syntax highlighting, and by > the usual convention of not abusing the syntax to the point where it > becomes illegible. > > # Backwards compatibility > > Adding this sugar would be backwards compatible because it doesn't change > any existing macro syntax, however if `IDENT! IDENT (...)` ends up obsolete > through this, that would break existing uses of `macro_rules!` - but macros > are behind a feature flag anyway at this point, so it wouldn't matter as > much. > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Wed Oct 16 23:03:20 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Thu, 17 Oct 2013 02:03:20 -0400 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> Message-ID: On Wednesday, 16 October 2013, Chris Morgan wrote: > > I would love this to be the case. It's the biggest problem I had with Go's > error handling: that it's far too easy to just ignore a return value > accidentally. (Truth to tell, the problem is far worse in Go because for > some reason they decided you could take not all of the return values, e.g. > for a func returning (T, err), `t = f()` will silently discard the err; > this has been a decision that has baffled me > It baffles me too, so it's good that Go doesn't actually let you do this :P. You have to either ignore all return values, or explicitly ignore any you don't want using _. You might be thinking of the comma-ok notation for certain built-in expressions... -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Wed Oct 16 23:06:38 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 16 Oct 2013 23:06:38 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <525F1549.5060304@mozilla.com> References: <525F0152.4090403@mozilla.com> <525F1549.5060304@mozilla.com> Message-ID: On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote: > There's no difference except that "let _" runs the destructor immediately > whereas "let _foo" runs the destructor at the end of the block. (This is > admittedly subtle.) > > I tried the following code snippet, but nothing got printed out. What am I missing? -- cut -- struct S; impl Drop for S { fn drop(&mut self) { println("drop"); } } fn main() { let _ = S; } --end cut -- Replacing `let _` with `let _s` printed "drop" as expected. Thanks -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Oct 16 23:08:34 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 17 Oct 2013 02:08:34 -0400 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <525F1549.5060304@mozilla.com> Message-ID: On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet wrote: > > > On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote: > >> There's no difference except that "let _" runs the destructor immediately >> whereas "let _foo" runs the destructor at the end of the block. (This is >> admittedly subtle.) >> >> > > I tried the following code snippet, but nothing got printed out. What am I > missing? > > -- cut -- > > struct S; > > impl Drop for S { > fn drop(&mut self) { > println("drop"); > } > } > > fn main() { > let _ = S; > } > > > --end cut -- > > Replacing `let _` with `let _s` printed "drop" as expected. > > Thanks > > -- > Ziad > https://github.com/mozilla/rust/issues/6892 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Wed Oct 16 23:13:25 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 16 Oct 2013 23:13:25 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <525F1549.5060304@mozilla.com> Message-ID: Thanks for the quick response :) -- Ziad On Wed, Oct 16, 2013 at 11:08 PM, Daniel Micay wrote: > On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet wrote: > >> >> >> On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote: >> >>> There's no difference except that "let _" runs the destructor >>> immediately whereas "let _foo" runs the destructor at the end of the block. >>> (This is admittedly subtle.) >>> >>> >> >> I tried the following code snippet, but nothing got printed out. What am >> I missing? >> >> -- cut -- >> >> struct S; >> >> impl Drop for S { >> fn drop(&mut self) { >> println("drop"); >> } >> } >> >> fn main() { >> let _ = S; >> } >> >> >> --end cut -- >> >> Replacing `let _` with `let _s` printed "drop" as expected. >> >> Thanks >> >> -- >> Ziad >> > > https://github.com/mozilla/rust/issues/6892 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loebel.marvin at gmail.com Wed Oct 16 23:29:24 2013 From: loebel.marvin at gmail.com (=?ISO-8859-1?Q?Marvin_L=F6bel?=) Date: Thu, 17 Oct 2013 08:29:24 +0200 Subject: [rust-dev] Proposal for macro invocation sugar In-Reply-To: References: <525F1CE2.1020008@gmail.com> Message-ID: <525F83C4.2060107@gmail.com> As I understand it, there is a high incentive to have macros be tokenizable and parseable without needing to expand them - it's a necessarily if we ever want importable macros (Can't resolve macro imports if you can't parse the source). Hence the requirement to have explicit brackets and the need to have properly nested and paired brackets in them. On 10/17/2013 06:30 AM, Oren Ben-Kiki wrote: > In general I'd favor anything that would help with > https://github.com/mozilla/rust/issues/9358 - that is, allow more > eDSL-ish macros. Writing `foo!!(...) { ... }` has the cost of the > extra `!` but that really isn't too bad. > > That said, I wonder why do macro invocations require the outer set of > parenthesis? Since a macro is expressed in terms of parser rules > (expressions, identifiers, tokens, etc.), isn't it unambiguous to > allow macros to be invoked without the outer `()`? E.g.: > > macro_rules! foo ( > (bar: $expr :<: baz: $expr) => ..., > ) > > Today, one would use it as in `f(foo!(1 :<: 2), 3)`. But suppose one > could somehow indicate the outer `()` were never to be used for this > macro (say writing `syntax_rules!` instead of `macro_rules!`, or by > some other extension of the `macro_rules!` notation), then parsing > `f(foo! 1 :<: 2, 3)` would be unambiguous - assuming we (1) strictly > use greedy parsing of $expr etc. and (2) always expand a later macro > before parsing and expanding earlier macros, where later and earlier > are in source text order. This strategy makes irrelevant the issue of > determining the nesting of such macros while "doing the right thing" > with a simple deterministic rule. > > This would probably be more complex to implement than the multiple-`!` > proposal, but would allow for more generic patterns. For example, > allowing to omit the outer `()` would allow invoking `my_match! > pattern => action`; if I understand it correctly, using `!!` would > only allow for writing `my_match!! pattern action`. > > At any rate, this is just as an idea - like I said, I'd like anything > that would allow me to write `foo!(...) { ... }` (or `foo!!(...) { ... > }`, or something along these lines). Writing `foo!(..., { ... })` just > seems ugly to me... > > > On Thu, Oct 17, 2013 at 2:10 AM, Marvin L?bel > wrote: > > Hello! I was thinking a bit about macros, and I had an idea for a > kind of syntactic sugar that might be useful to have. I also > posted this to the issue tracker at > https://github.com/mozilla/rust/issues/9894. > > # Current situation > > Right now, rust knows about two kinds of macro invocation: > > IDENT!(...) > IDENT! IDENT (...) > > The latter one is just used by `macro_rules!` right now, and seems > kinda out of place because of that. > > Additionally, just being restricted to `IDENT!(...)` means that, > while you can define macros just fine, the resulting invocation > syntax often looks a bit weird because of the need for the outer > `()` pair. > > For example, if you want to write some kind of custom `match` > macro you ideally want a syntax like `macro! EXPR { CASES... }`, > but in practice are forced to decide between redundant, deeply > nested brackets or weird syntax if you want to reduce the brackets: > > ~~~ > my_match!( > foo().bar().baz() { > case 1 => ... > case 2 => ... > ... > } > ) > > my_match!(foo().bar().baz() cases: > case 1 => ... > case 2 => ... > ... > ) > ~~~ > > # Proposal > > We can't just allow macros to accept different syntax like `IDENT! > EXPR ( ... )`, because it would create ambiguity in the parser, > but it occurred to me that we _can_ provide syntactic sugar for > transforming 'nicer looking' variants into the regular > `IDENT!(...)` syntax. > > Basically, I'm thinking of leveraging the bang in a macro > invocation to annotate how many following bracket pairs to group > into one regular macro invocation: > > ~~~ > IDENT!! (...) (...) => desugaring => IDENT!((...) (...)) > IDENT!!! (...) (...) (...) => desugaring => IDENT!((...) (...) (...)) > ... etc > ~~~ > > The number of bangs could become confusing fast, but I don't > expect that macros with more than two bracket groups are going to > be common. And because it would just be sugar, you could always > write it as the regular form. > > # Advantages > > There are a number of advantages I see with this proposal: > > 1. The two macro invocation forms can be folded into one: > ~~~ > IDENT!(...) => IDENT!(...) > IDENT! IDENT (...) => IDENT!! (IDENT) (...) == IDENT!((IDENT) > (...)) > ~~~ > > 2. Custom syntax can become nicer looking, especially for control > structures. > Looking at the `my_match` example: > ~~~ > my_match!! (foo().bar().baz()) { > case 1 => ... > case 2 => ... > ... > } > ~~~ > ... which looks more natural than any the two options outlined > above. > > 3. It's pure syntactic sugar, which means it's easy to implement > and reason about. > All `libsyntax` needs to do is to consume a list of > bracket-counted token trees > equal to the number of bangs, and introduce an artificial outer > bracket pair if > the number is higher than one. > > 4. It's just invocation sugar, which means there is no difference > between defining a > macro that uses this vs one that doesn't - you just declare > them all assuming the > explicit outer `()` pair. > > # Potential issues > > The possible issues I can see with this are confusing error > messages if the number of bangs is wrong, and uncertainty about > which brackets belong to a macro invocation and which are regular > rust code if their contents become big and/or their number become > high. > > However, in theory rust might be able to provide good error > messages for the first one, because if the macro name is right > you'd get an `No rules expected this ...` error, and there could > be some heuristics for recognizing cases where the user has do > add/remove bangs to match the macro definition. > > And the second one can likely be managed by syntax highlighting, > and by the usual convention of not abusing the syntax to the point > where it becomes illegible. > > # Backwards compatibility > > Adding this sugar would be backwards compatible because it doesn't > change any existing macro syntax, however if `IDENT! IDENT (...)` > ends up obsolete through this, that would break existing uses of > `macro_rules!` - but macros are behind a feature flag anyway at > this point, so it wouldn't matter as much. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Thu Oct 17 05:24:49 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Thu, 17 Oct 2013 15:24:49 +0300 Subject: [rust-dev] Proposal for macro invocation sugar In-Reply-To: <525F83C4.2060107@gmail.com> References: <525F1CE2.1020008@gmail.com> <525F83C4.2060107@gmail.com> Message-ID: That does make sense. Well, this still leaves the `foo!!` proposal as viable, and a possible solution for https://github.com/mozilla/rust/issues/9358 - so, +1 for that. On Thu, Oct 17, 2013 at 9:29 AM, Marvin L?bel wrote: > As I understand it, there is a high incentive to have macros be > tokenizable and parseable without needing to expand them - it's a > necessarily if we ever want importable macros (Can't resolve macro imports > if you can't parse the source). > Hence the requirement to have explicit brackets and the need to have > properly nested and paired brackets in them. > > > On 10/17/2013 06:30 AM, Oren Ben-Kiki wrote: > > In general I'd favor anything that would help with > https://github.com/mozilla/rust/issues/9358 - that is, allow more > eDSL-ish macros. Writing `foo!!(...) { ... }` has the cost of the extra `!` > but that really isn't too bad. > > That said, I wonder why do macro invocations require the outer set of > parenthesis? Since a macro is expressed in terms of parser rules > (expressions, identifiers, tokens, etc.), isn't it unambiguous to allow > macros to be invoked without the outer `()`? E.g.: > > macro_rules! foo ( > (bar: $expr :<: baz: $expr) => ..., > ) > > Today, one would use it as in `f(foo!(1 :<: 2), 3)`. But suppose one > could somehow indicate the outer `()` were never to be used for this macro > (say writing `syntax_rules!` instead of `macro_rules!`, or by some other > extension of the `macro_rules!` notation), then parsing `f(foo! 1 :<: 2, > 3)` would be unambiguous - assuming we (1) strictly use greedy parsing of > $expr etc. and (2) always expand a later macro before parsing and expanding > earlier macros, where later and earlier are in source text order. This > strategy makes irrelevant the issue of determining the nesting of such > macros while "doing the right thing" with a simple deterministic rule. > > This would probably be more complex to implement than the multiple-`!` > proposal, but would allow for more generic patterns. For example, allowing > to omit the outer `()` would allow invoking `my_match! pattern => action`; > if I understand it correctly, using `!!` would only allow for writing > `my_match!! pattern action`. > > At any rate, this is just as an idea - like I said, I'd like anything > that would allow me to write `foo!(...) { ... }` (or `foo!!(...) { ... }`, > or something along these lines). Writing `foo!(..., { ... })` just seems > ugly to me... > > > On Thu, Oct 17, 2013 at 2:10 AM, Marvin L?bel wrote: > >> Hello! I was thinking a bit about macros, and I had an idea for a kind of >> syntactic sugar that might be useful to have. I also posted this to the >> issue tracker at https://github.com/mozilla/rust/issues/9894. >> >> # Current situation >> >> Right now, rust knows about two kinds of macro invocation: >> >> IDENT!(...) >> IDENT! IDENT (...) >> >> The latter one is just used by `macro_rules!` right now, and seems kinda >> out of place because of that. >> >> Additionally, just being restricted to `IDENT!(...)` means that, while >> you can define macros just fine, the resulting invocation syntax often >> looks a bit weird because of the need for the outer `()` pair. >> >> For example, if you want to write some kind of custom `match` macro you >> ideally want a syntax like `macro! EXPR { CASES... }`, but in practice are >> forced to decide between redundant, deeply nested brackets or weird syntax >> if you want to reduce the brackets: >> >> ~~~ >> my_match!( >> foo().bar().baz() { >> case 1 => ... >> case 2 => ... >> ... >> } >> ) >> >> my_match!(foo().bar().baz() cases: >> case 1 => ... >> case 2 => ... >> ... >> ) >> ~~~ >> >> # Proposal >> >> We can't just allow macros to accept different syntax like `IDENT! EXPR ( >> ... )`, because it would create ambiguity in the parser, but it occurred to >> me that we _can_ provide syntactic sugar for transforming 'nicer looking' >> variants into the regular `IDENT!(...)` syntax. >> >> Basically, I'm thinking of leveraging the bang in a macro invocation to >> annotate how many following bracket pairs to group into one regular macro >> invocation: >> >> ~~~ >> IDENT!! (...) (...) => desugaring => IDENT!((...) (...)) >> IDENT!!! (...) (...) (...) => desugaring => IDENT!((...) (...) (...)) >> ... etc >> ~~~ >> >> The number of bangs could become confusing fast, but I don't expect that >> macros with more than two bracket groups are going to be common. And >> because it would just be sugar, you could always write it as the regular >> form. >> >> # Advantages >> >> There are a number of advantages I see with this proposal: >> >> 1. The two macro invocation forms can be folded into one: >> ~~~ >> IDENT!(...) => IDENT!(...) >> IDENT! IDENT (...) => IDENT!! (IDENT) (...) == IDENT!((IDENT) (...)) >> ~~~ >> >> 2. Custom syntax can become nicer looking, especially for control >> structures. >> Looking at the `my_match` example: >> ~~~ >> my_match!! (foo().bar().baz()) { >> case 1 => ... >> case 2 => ... >> ... >> } >> ~~~ >> ... which looks more natural than any the two options outlined above. >> >> 3. It's pure syntactic sugar, which means it's easy to implement and >> reason about. >> All `libsyntax` needs to do is to consume a list of bracket-counted >> token trees >> equal to the number of bangs, and introduce an artificial outer >> bracket pair if >> the number is higher than one. >> >> 4. It's just invocation sugar, which means there is no difference between >> defining a >> macro that uses this vs one that doesn't - you just declare them all >> assuming the >> explicit outer `()` pair. >> >> # Potential issues >> >> The possible issues I can see with this are confusing error messages if >> the number of bangs is wrong, and uncertainty about which brackets belong >> to a macro invocation and which are regular rust code if their contents >> become big and/or their number become high. >> >> However, in theory rust might be able to provide good error messages for >> the first one, because if the macro name is right you'd get an `No rules >> expected this ...` error, and there could be some heuristics for >> recognizing cases where the user has do add/remove bangs to match the macro >> definition. >> >> And the second one can likely be managed by syntax highlighting, and by >> the usual convention of not abusing the syntax to the point where it >> becomes illegible. >> >> # Backwards compatibility >> >> Adding this sugar would be backwards compatible because it doesn't change >> any existing macro syntax, however if `IDENT! IDENT (...)` ends up obsolete >> through this, that would break existing uses of `macro_rules!` - but macros >> are behind a feature flag anyway at this point, so it wouldn't matter as >> much. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From platt.nicholas at gmail.com Thu Oct 17 10:52:18 2013 From: platt.nicholas at gmail.com (Nicholas Platt) Date: Thu, 17 Oct 2013 13:52:18 -0400 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: References: Message-ID: I found it pretty easy to manually keep the slides and audio in sync. It wasn't possible to hear the questions, but your answers generally made it clear what was asked. Does anyone know of other available/upcoming talks on Rust? On Wed, Oct 16, 2013 at 7:10 PM, Cadence Marseille < cadencemarseille at gmail.com> wrote: > Hi Tim, > > Thanks for posting these. I haven't listened to the audio, but I read > through the slides and I like your presentation. For me, it is a good > reminder of why Rust is so cool. > > I don't know about other users (survey time, anyone? [?]), but my > background is mostly C++ and Java. The notes about C++ vs. Rust are > helpful. > > Cadence > > > On Tue, Oct 15, 2013 at 2:28 PM, Tim Chevalier wrote: > >> Hi all, >> >> The audio recording for my June 2013 talk at Open Source Bridge, >> "Rust: A Friendly Introduction", is now available: >> >> http://opensourcebridge.org/sessions/970 >> >> As far as I know, there was no video recording, but the slides are linked >> from: >> >> http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction >> >> Cheers, >> Tim >> >> >> -- >> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt >> "Being queer is not about a right to privacy; it is about the freedom >> to be public, to just be who we are." -- anonymous, June 1990 >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danoctavian91 at gmail.com Thu Oct 17 11:04:29 2013 From: danoctavian91 at gmail.com (Dan Cristian Octavian) Date: Thu, 17 Oct 2013 11:04:29 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: Hello, I've spend some time looking at proposed master's projects by my uni to understand how this one compares and to understand the time resources that I have available (roughly 3 months of solid work and roughly 3 months of part-time during term-time work until project submission deadline, of course i could continue working afterwards to get things done ): Correct me if I'm wrong on the following: the main issues about runtimeless rust are: * supporting std functionality (to various degrees depending on the environment) * the stacks issue One of my concerns is that suppose I choose to do this, it's part of an active development effort and the aforementioned issues seem to be connected to many other problems (the stack problem) and it's kind of hard to just crop a big issue out and say "yup this is a standalone project, you go do it". I am just worried I will have a hard time saying "I've done this" and I will only be able to say "I've been a contributor to Rust for a while working mainly on this" and that doesn't add up to be a master's project. I would really like to work on this, though. Do you think it can be formulated as a set of targets that are useful to the Rust project (they are actually used) and at the same time constitute a valid master's project? Would picking an issue that is milestoned for after 1.0 release be a good cure for this problem since their are not as interconnected with currently developed features? I've browsed through the interesting-project tagged issues. Aside from runtimeless I was interested in the following: compile time stack size https://github.com/mozilla/rust/issues/4389 proper REPL https://github.com/mozilla/rust/issues/9898 parallel multi-crate compiler driver https://github.com/mozilla/rust/issues/3431 sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 But there's also the issue of having something sizeable enough. Again any suggestions welcome. Many thanks, Dan On Tue, Oct 1, 2013 at 12:07 PM, Alex Crichton wrote: > > One of my first thoughts when I saw the Rust project was to make it > > runtimeless. Shortly after that was achieved rather trivially with > zero.rs. > > I don't know if any major improvement can be done there. > > As others have said, I don't believe that Rust is currently at the > point of being "runtimeless". In addition to what Brian mentioned > about not being able to use core-language features easily (vectors, > strings, convenient I/O), the story of stacks is also a little sad in > runtimeless rust. Currently a "runtimeless" program is still forced to > link to librustrt along with our own libmorestack to provide the > __morestack function needed by LLVM's segmented stacks. It always > seemed a little silly to me that "runtimeless" rust still links to the > runtime... > > Various bits of discussion can be found on > > https://github.com/mozilla/rust/pull/8955 > https://github.com/mozilla/rust/issues/8345 > > But in summary the story of how stacks are allocated is currently not > sufficient for writing something like a kernel module or a kernel > itself. I do believe that this is certainly within the realm of > possibility, but it certainly needs to be done carefully. I'm not sure > if it's too small of a master's project, but I personally consider > this to be a fairly substantial undertaking to get right. The various > modes discussed in those two issues would be useful to have. > > This also may not be limited to a runtimeless rust, because the > current stack situation is a bit in flux with rust currently. Our > segmented stacks are disabled in the new runtime (not implemented yet) > and there's some unease about the fixed_stack_segment macro and how it > can be more useful. > > For reference, here's some issues: > > Runtimeless rust: https://github.com/mozilla/rust/issues/3608 > newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 > revised stack attributes: https://github.com/mozilla/rust/issues/8822 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Oct 17 11:25:58 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 17 Oct 2013 11:25:58 -0700 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: References: Message-ID: <52602BB6.2050003@mozilla.com> On 10/17/2013 10:52 AM, Nicholas Platt wrote: > I found it pretty easy to manually keep the slides and audio in sync. > It wasn't possible to hear the questions, but your answers generally > made it clear what was asked. > > Does anyone know of other available/upcoming talks on Rust? Here are all the existing recorded presentations I'm aware of: https://github.com/mozilla/rust/wiki/Docs#presentations There were two Rust talks this year at OSCon, but I don't think there are available recordings. There will be one by Niko this year at linux.conf.au, and there may be one at codemesh.io. > > > On Wed, Oct 16, 2013 at 7:10 PM, Cadence Marseille > > wrote: > > Hi Tim, > > Thanks for posting these. I haven't listened to the audio, but I > read through the slides and I like your presentation. For me, it > is a good reminder of why Rust is so cool. > > I don't know about other users (survey time, anyone? ), but my > background is mostly C++ and Java. The notes about C++ vs. Rust > are helpful. > > Cadence > > > On Tue, Oct 15, 2013 at 2:28 PM, Tim Chevalier > > wrote: > > Hi all, > > The audio recording for my June 2013 talk at Open Source Bridge, > "Rust: A Friendly Introduction", is now available: > > http://opensourcebridge.org/sessions/970 > > As far as I know, there was no video recording, but the slides > are linked from: > > http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction > > Cheers, > Tim > > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, > never in doubt > "Being queer is not about a right to privacy; it is about the > freedom > to be public, to just be who we are." -- anonymous, June 1990 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Thu Oct 17 11:54:54 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 17 Oct 2013 20:54:54 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: (Chris Morgan's message of "Thu, 17 Oct 2013 09:31:06 +1100") References: <525F0152.4090403@mozilla.com> Message-ID: <87fvrzwww1.fsf@mid.deneb.enyo.de> * Chris Morgan: > I would love this to be the case. It's the biggest problem I had with Go's > error handling: that it's far too easy to just ignore a return value > accidentally. I did an informal study some time ago, and it does not appear to be that common a mistake. (I was biased and tried to prove that the current state of affairs what bad, but the results weren't convincing.) It only happens when there are no results whatsoever. If there are results that need processing, programmers do some form of error handling or threading. There is, however, one major design blunder. Some of the I/O interfaces (Reader, ReaderAt etc.) do not follow the rest of the standard library in treating the result/error return as a sum type. In the rest of the library, you have to check the error first because it is often not possible to see from the result itself that it is part of an error (say, the value 0 from an string-to-inter parsing routine). With I/O, you have to check the result first because some of the interfaces are specified to return both data and an error. Here's an example for io.Reader: Rust shouldn't have this problem if it uses a proper sum type, and even with Go the language, it would have been possible to avoid this mess with a better choice in Go the library. From pwalton at mozilla.com Thu Oct 17 11:57:25 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 17 Oct 2013 11:57:25 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <87fvrzwww1.fsf@mid.deneb.enyo.de> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> Message-ID: <52603315.7030705@mozilla.com> On 10/17/13 11:54 AM, Florian Weimer wrote: > * Chris Morgan: > >> I would love this to be the case. It's the biggest problem I had with Go's >> error handling: that it's far too easy to just ignore a return value >> accidentally. > > I did an informal study some time ago, and it does not appear to be > that common a mistake. (I was biased and tried to prove that the > current state of affairs what bad, but the results weren't > convincing.) It only happens when there are no results whatsoever. > If there are results that need processing, programmers do some form of > error handling or threading. On the other hand, Cindy Rubio-Gonz?lez's work shows that in the Linux kernel, forgetting to handle error codes is *extremely* common. http://www.eecs.berkeley.edu/~rubio/ I don't see anything fundamentally different with Go's approach that will lead to a different outcome. Patrick From fw at deneb.enyo.de Thu Oct 17 12:45:54 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 17 Oct 2013 21:45:54 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <52603315.7030705@mozilla.com> (Patrick Walton's message of "Thu, 17 Oct 2013 11:57:25 -0700") References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> Message-ID: <87wqlbvfyl.fsf@mid.deneb.enyo.de> * Patrick Walton: > On the other hand, Cindy Rubio-Gonz?lez's work shows that in the Linux > kernel, forgetting to handle error codes is *extremely* common. > > http://www.eecs.berkeley.edu/~rubio/ > > I don't see anything fundamentally different with Go's approach that > will lead to a different outcome. The kernel usually passes results by storing them in an existing object because allocation by the callee is less efficient and impossible in many contexts. Go has garbage collection, and returning a new object and an error return value is the more common style. The result-plus-error case has a much better chance of being handled correctly. Go also has exceptions (for signaling certain errors). I'm not sure if it deals with memory allocation failures gracefully. If it doesn't, that would eliminate a fair chunk of kernel error handling, too. So in short, Go is quite different. :-) From pwalton at mozilla.com Thu Oct 17 12:59:03 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 17 Oct 2013 12:59:03 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <87wqlbvfyl.fsf@mid.deneb.enyo.de> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> Message-ID: <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> You make a good case that it happens less in Go, but I'm still not sold on Go's error handling, given that it's fundamentally built on a model that's known to be error-prone. We know that the flaw of error-code-based systems without checked returns is that you can forget to handle errors. Go makes this harder in many situations, but it has known holes when the function returns nothing but an error or the function is invoked only for its side effects. I don't see any reason why we should deliberately go with a system with known flaws and failure modes when there are better alternatives available. In other words: Why bet, as Go did, that the failure case won't happen much in practice when we can adopt an error-handling strategy that rules it out entirely? Florian Weimer wrote: >* Patrick Walton: > >> On the other hand, Cindy Rubio-Gonz?lez's work shows that in the >Linux >> kernel, forgetting to handle error codes is *extremely* common. >> >> http://www.eecs.berkeley.edu/~rubio/ >> >> I don't see anything fundamentally different with Go's approach that >> will lead to a different outcome. > >The kernel usually passes results by storing them in an existing >object because allocation by the callee is less efficient and >impossible in many contexts. Go has garbage collection, and returning >a new object and an error return value is the more common style. The >result-plus-error case has a much better chance of being handled >correctly. > >Go also has exceptions (for signaling certain errors). I'm not sure >if it deals with memory allocation failures gracefully. If it >doesn't, that would eliminate a fair chunk of kernel error handling, >too. > >So in short, Go is quite different. :-) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From earlz at lastyearswishes.com Thu Oct 17 13:15:31 2013 From: earlz at lastyearswishes.com (Jordan Earls) Date: Thu, 17 Oct 2013 16:15:31 -0400 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: <52602BB6.2050003@mozilla.com> References: <52602BB6.2050003@mozilla.com> Message-ID: A conference I plan to attend is having some kind of introductory talk about Rust. They are usually pretty good about recording and then making the recording available online as well. http://codemash.org/sessions On Thu, Oct 17, 2013 at 2:25 PM, Brian Anderson wrote: > On 10/17/2013 10:52 AM, Nicholas Platt wrote: > > I found it pretty easy to manually keep the slides and audio in sync. It > wasn't possible to hear the questions, but your answers generally made it > clear what was asked. > > Does anyone know of other available/upcoming talks on Rust? > > > Here are all the existing recorded presentations I'm aware of: > https://github.com/mozilla/rust/wiki/Docs#presentations > > There were two Rust talks this year at OSCon, but I don't think there are > available recordings. There will be one by Niko this year at linux.conf.au, > and there may be one at codemesh.io. > > > > > On Wed, Oct 16, 2013 at 7:10 PM, Cadence Marseille < > cadencemarseille at gmail.com> wrote: > >> Hi Tim, >> >> Thanks for posting these. I haven't listened to the audio, but I read >> through the slides and I like your presentation. For me, it is a good >> reminder of why Rust is so cool. >> >> I don't know about other users (survey time, anyone? [?]), but my >> background is mostly C++ and Java. The notes about C++ vs. Rust are >> helpful. >> >> Cadence >> >> >> On Tue, Oct 15, 2013 at 2:28 PM, Tim Chevalier wrote: >> >>> Hi all, >>> >>> The audio recording for my June 2013 talk at Open Source Bridge, >>> "Rust: A Friendly Introduction", is now available: >>> >>> http://opensourcebridge.org/sessions/970 >>> >>> As far as I know, there was no video recording, but the slides are >>> linked from: >>> >>> http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction >>> >>> Cheers, >>> Tim >>> >>> >>> -- >>> Tim Chevalier * http://catamorphism.org/ * Often in error, never in >>> doubt >>> "Being queer is not about a right to privacy; it is about the freedom >>> to be public, to just be who we are." -- anonymous, June 1990 >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.sampson at gmail.com Thu Oct 17 13:55:49 2013 From: eric.sampson at gmail.com (Eric Sampson) Date: Thu, 17 Oct 2013 15:55:49 -0500 Subject: [rust-dev] master's project work on rust - ideas Message-ID: > > > Message: 3 > Date: Thu, 17 Oct 2013 11:04:29 -0700 > From: Dan Cristian Octavian > To: Alex Crichton > Cc: "rust-dev at mozilla.org" > Subject: Re: [rust-dev] master's project work on rust - ideas > Message-ID: > 2r_TDrQxHLF9gy2HD4kAQi8G7pDB_knt34gE6z8sN2tg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > (snip) > > Would picking an issue that is milestoned for after 1.0 release be a good > cure for this problem since their are not as interconnected with currently > developed features? I've browsed through the interesting-project tagged > issues. Aside from runtimeless I was interested in the following: > > compile time stack size https://github.com/mozilla/rust/issues/4389 > proper REPL https://github.com/mozilla/rust/issues/9898 > parallel multi-crate compiler driver > https://github.com/mozilla/rust/issues/3431 > sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 > > But there's also the issue of having something sizeable enough. > Again any suggestions welcome. > > Many thanks, > > Dan > Hi Dan, my vote is probably not worth much, but I'd love to see Rust end up with a great REPL! -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Oct 17 15:09:30 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 17 Oct 2013 15:09:30 -0700 Subject: [rust-dev] Continuous integration for Rust with Travis CI Message-ID: <5260601A.2080407@mozilla.com> Greetings, Rusticians! Today I want to point out something very cool that may not have hit your radar yet. As a budding Rust package maintainer you are probably aware of how much effort it can take to keep up with our fast-moving little language. Now there is a tool that can help! The incomparable Hans J?rgen Hoel has made Rust nightly builds for Ubuntu work with [Travis CI] and, beyond that, created a dashboard solely for tracking the build status of Rust projects. [Rust CI] is a super cool project that I expect to play a big role in our community as Rust matures. Configuring your packages to work with Travis CI and Rust CI is very simple, and I highly recommend it. I've also added a (very sparse) page on [continuous integration] to the wiki that I hope we can fill out as the story unfolds. Regards, Brian [Travis CI]: https://travis-ci.org/ [Rust CI]: http://hiho.io/rust-ci/ [continuous integration]: https://github.com/mozilla/rust/wiki/Doc-continuous-integration From igor at mir2.org Thu Oct 17 17:18:01 2013 From: igor at mir2.org (Igor Bukanov) Date: Fri, 18 Oct 2013 02:18:01 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: To make discussion about a way to handle IO errors less generic consider a hypothetical program that that reads some configuration files that have include statements and suppose that one of the included files could not be read due to bad permissions. Ideally a user should receive a message like that include statement in file foo.conf line 123 could not be processed due to bad permissions. In the real world, especially if the permission problem would not be anticipated by the developer, a typical program I suppose would behave like: C - program terminates with an abort message about permission problems. The message may include the name of the file, but there would be no information about the location of that include statement or even that the error happened during parsing of config files. Java and Python - a stack trace will be generated with error message similar to the C case. To the developer the stack trace tells that it was generated during parsing of the include statement, but the user will have no clue. Go - I have not used the language, but my general impression is that no error will be generated. Instead the file will be read as an empty string. The question is can Rust provide such error handling so the ideal scenario can be implemented with minimal efforts? >From a personal experience in Java the solution was to pass an extra Reporter interface parameter into most of the parser and IO supporting libraries and stop using exceptions. Various program components then implemented that interface to add information about error location and conditions. The Reporter interface also provided a way to query about the current error status. Surprisingly with this setup besides the extra reporter parameter the source was not clattered with return status checks as the code style became to report errors, but still return sensible defaults (like reading the file as empty string). This way the caller can proceed as if error would not happen, but the report would not be lost. As an added benefit reporting several errors became trivial. On 17 October 2013 21:59, Patrick Walton wrote: > You make a good case that it happens less in Go, but I'm still not sold on > Go's error handling, given that it's fundamentally built on a model that's > known to be error-prone. We know that the flaw of error-code-based systems > without checked returns is that you can forget to handle errors. Go makes > this harder in many situations, but it has known holes when the function > returns nothing but an error or the function is invoked only for its side > effects. I don't see any reason why we should deliberately go with a system > with known flaws and failure modes when there are better alternatives > available. > > In other words: Why bet, as Go did, that the failure case won't happen much > in practice when we can adopt an error-handling strategy that rules it out > entirely? > > Florian Weimer wrote: >> >> * Patrick Walton: >> >> >>> On the other hand, Cindy Rubio-Gonz?lez's work shows that in the Linux >>> kernel, forgetting to handle error codes is *extremely* common. >>> >>> http://www.eecs.berkeley.edu/~rubio/ >>> >>> I don't see anything fundamentally different with Go's approach that >>> will lead to a different outcome. >> >> >> The kernel usually passes results by storing them in an existing >> object because allocation by the callee is less efficient and >> impossible in many contexts. Go has garbage collection, and returning >> a new object and an error return value is the more common style. The >> result-plus-error case has a much better chance of being handled >> correctly. >> >> Go also has exceptions (for signaling certain errors). I'm not sur >> e >> if it deals with memory allocation failures gracefully. If it >> doesn't, that would eliminate a fair chunk of kernel error handling, >> too. >> >> So in short, Go is quite different. :-) > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From steven099 at gmail.com Thu Oct 17 20:29:38 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Thu, 17 Oct 2013 23:29:38 -0400 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: On Thursday, October 17, 2013, Igor Bukanov wrote: > > Go - I have not used the language, but my general impression is that > no error will be generated. Instead the file will be read as an empty > string. > Go encodes the error as a value which can be either treated as a string or programmatically inspected to determine the correct response and returns it along with an invalid file handle. If the code doesn't actually specifically handle permission problems, it will usually create a new error value embedding the original error along with some context about what it was doing when it got the error. This new error can then be used as a failure value or passed up the stack, or it may be logged (potentially in combination with one of the other two options). This means that, even if the developer didn't anticipate permissions issues, the error will likely contain all the relevant information, such as what line of the configuration file was being processed as well as what file failed to open and why. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Thu Oct 17 21:40:43 2013 From: igor at mir2.org (Igor Bukanov) Date: Fri, 18 Oct 2013 06:40:43 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: So the Go style is to call a function, check if the was an error, update the error object (or create a new wrapping the old one) with extra information relevant to the current call stack frame and propagate the updated error object to the caller. If done consistently, this could indeed provide very-user friendly error messages. But it does clutter the code with if checks and does not allow to recover so multiple errors could not be reported. In the above example the developer, before calling a parser library, may want to say that IO errors should be recovered from, so they could be reported together with other problems like syntax violations. I do not see how the Go style could be adopted to that. In its design the caller cannot influence the error propagation paths in the callee and its stack subframes. On 18 October 2013 05:29, Steven Blenkinsop wrote: > On Thursday, October 17, 2013, Igor Bukanov wrote: >> >> >> Go - I have not used the language, but my general impression is that >> no error will be generated. Instead the file will be read as an empty >> string. > > > Go encodes the error as a value which can be either treated as a string or > programmatically inspected to determine the correct response and returns it > along with an invalid file handle. If the code doesn't actually specifically > handle permission problems, it will usually create a new error value > embedding the original error along with some context about what it was doing > when it got the error. This new error can then be used as a failure value or > passed up the stack, or it may be logged (potentially in combination with > one of the other two options). This means that, even if the developer didn't > anticipate permissions issues, the error will likely contain all the > relevant information, such as what line of the configuration file was being > processed as well as what file failed to open and why. From steve at steveklabnik.com Thu Oct 17 22:11:53 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Fri, 18 Oct 2013 07:11:53 +0200 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: References: <52602BB6.2050003@mozilla.com> Message-ID: <8A20128D-51D9-41D7-9E60-D3CC2A5DA324@steveklabnik.com> I gave a talk at RuPy last week, and while they accepted my CodeMash proposal, I am giving it serious thought given the recent.... situation. Which I don't want to drag this list into. But I am probably doing it. I'll let everyone know once video is up. From pnathan at vandals.uidaho.edu Fri Oct 18 00:25:02 2013 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Fri, 18 Oct 2013 00:25:02 -0700 Subject: [rust-dev] How much RAM does a 0.8 build take? Message-ID: <5260E24E.7090900@vandals.uidaho.edu> Hi, I have a 3GB Linux x64 machine that I've done occasional rust builds on and I found it failing tonight: task failed at 'failure in fork: Cannot allocate memory', /home/rustbuild/src/rust-buildbot/slave/snap3-linux/build/src/libstd/run.rs:672 Is this to be expected? To be fair, I am using the machine for other things at the time - compiling, internet browsing, etc. -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x6494196F.asc Type: application/pgp-keys Size: 3174 bytes Desc: not available URL: From alex at crichton.co Fri Oct 18 00:30:47 2013 From: alex at crichton.co (Alex Crichton) Date: Fri, 18 Oct 2013 00:30:47 -0700 Subject: [rust-dev] How much RAM does a 0.8 build take? In-Reply-To: <5260E24E.7090900@vandals.uidaho.edu> References: <5260E24E.7090900@vandals.uidaho.edu> Message-ID: I forget what the memory usage was when 0.8 was cut, but around that time the compiler peaked at about 2.2 GB of memory. At this time, it would then fork to invoke the linker, which is the most common cause of the out of memory issues we've been seeing. For things like VMs, I've seen 4GB work pretty much all the time. That being said, work went into recently reducing the peak, so now we peak at around 1.4GB instead, so if you compile on master with 3 GB of memory you may not see the failure. Data brought to you by the awesome folks managing http://huonw.github.io/isrustfastyet/mem/ :) On Fri, Oct 18, 2013 at 12:25 AM, Paul Nathan wrote: > Hi, > > I have a 3GB Linux x64 machine that I've done occasional rust builds > on and I found it failing tonight: > > > task failed at 'failure in fork: Cannot allocate memory', > /home/rustbuild/src/rust-buildbot/slave/snap3-linux/build/src/libstd/run.rs:672 > > Is this to be expected? > > To be fair, I am using the machine for other things at the time - > compiling, internet browsing, etc. > > -- > Regards, > Paul > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From ncm at cantrip.org Fri Oct 18 00:47:44 2013 From: ncm at cantrip.org (Nathan Myers) Date: Fri, 18 Oct 2013 00:47:44 -0700 Subject: [rust-dev] Does Rust ever sleep? Message-ID: <5260E7A0.5080200@cantrip.org> Does Rust ever sleep? This is a rhetorical question, conceivably related to the Neil Young album, or to the possibility of a project motto, or maybe about whether the Rust runtime really runs programs in parallel, with as many true OS-level threads as cores. Nathan Myers ncm at cantrip.org From j.boggiano at seld.be Fri Oct 18 01:21:57 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Fri, 18 Oct 2013 10:21:57 +0200 Subject: [rust-dev] LLVM at FOSDEM 2014 - Call for papers and participation In-Reply-To: <525549FB.9010405@debian.org> References: <525549FB.9010405@debian.org> Message-ID: Kind of sad nobody else seemed interested in this. I unfortunately don't know enough about rust internals to make any sensible contribution to a LLVM track, but I plan on going to FOSDEM this year so if anyone else is going I'd be happy to say hi! Cheers On Wed, Oct 9, 2013 at 2:20 PM, Sylvestre Ledru wrote: > Since rust is using LLVM, some developers might be interested by the > following message (and a talk about rust itself would be > much appreciated). > > CALL FOR PAPERS / PARTICIPATION > > At FOSDEM 2014, LLVM will for the first time participate with a > dedicated devroom. Complementing the upcoming Euro LLVM 2014, the > devroom at FOSDEM provides a great opportunity for core LLVM developers > and the wider open source community to get together, connect and discuss. > > As possibly the largest European Open Source Conference, FOSDEM takes > place in Brussels and attracts with more than 400 lectures every year > over 5000 hackers - many core contributors of the worlds leading open > source projects. > > > = Call for Speakers, Posters, Demos = > > We invite academic, industrial and hobbyist speakers to present their > work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. > > We are looking for: > > 1. Keynote speakers. > 2. Technical presentations (30 minutes plus questions and discussion) > related to development of LLVM, Clang etc. > 3. Presentations about the use of LLVM, Clang in commercial or > academic projects as well as in the open source world. > 4. Tutorials > 5. Lightning talks (5 minutes) > > The deadline for receiving submissions is December 1st, 2013. Speakers > will be notified of acceptance or rejection by the 15th of December. > Proposals that are not sufficiently detailed (talks lacking a > comprehensive abstract for example) are likely to be rejected. > > Please create an account on the FOSDEM interface ( > https://penta.fosdem.org/user/new_account ) and submit your proposal > ( https://penta.fosdem.org/submission/FOSDEM14/event/new ). > Please make sure you select "LLVM devroom" as the "Track". > > > = Registration = > > FOSDEM does not require any registration and is free of charge. However, > we advise to arrive early in the devroom in case of important affluence. > > > = Organisation = > > The mailing list llvm-devroom at lists.fosdem.org can be used to discuss > issues of general interest related to the conference organization. > > > = Financial Support = > > There may be a possibility of limited funding to help students or > contributors who could not otherwise attend the conference. This will > depend on overall sponsorship and companies' interest in supporting the > event. > > If you need funding to attend the meeting, or can help sponsor, please > tell us on llvm-devroom at lists.fosdem.org. > > > = About LLVM = > > LLVM is a collection of libraries and tools that make it easy to build > compilers, optimizers, Just-In-Time code generators, and many other > compiler-related programs. LLVM uses a single, language-independent > virtual instruction set both as an offline code representation (to > communicate code between compiler phases and to run-time systems) and as > the compiler internal representation (to analyse and transform > programs). This persistent code representation allows a common set of > sophisticated compiler techniques to be applied at compile-time, > link-time, install-time, run-time, or "idle-time" (between program runs). > > The strengths of the LLVM infrastructure are its extremely simple design > (which makes it easy to understand and use), source-language > independence, powerful mid-level optimizer, automated compiler debugging > support, extensibility, and its stability and reliability. LLVM is > currently being used to host a wide variety of academic research > projects and commercial projects. > > Besides LLVM, several projects have been developed on top of it like > lang, LLDB, Polly or VMKit. > > For more information, please visit http://llvm.org/ or the conference > webpage at http://llvm.org/devmtg/2014-02/ > > > Tobias Grosser & Sylvestre Ledru > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- Jordi Boggiano @seldaek - http://nelm.io/jordi From leo.testard at gmail.com Fri Oct 18 02:28:23 2013 From: leo.testard at gmail.com (=?iso-8859-1?Q?L=E9o_Testard?=) Date: Fri, 18 Oct 2013 11:28:23 +0200 Subject: [rust-dev] #rust-osdev Message-ID: Hello, A new channel appeared on IRC today following a discussion about exo and microkernels on #rust. This chan is #rust-osdev and is about... guess what... OS development with Rust. That's it. We will discuss how to use Rust for OS development : how to compile and run Rust code without the runtime, how to make it boot on the hardware, how to link it with C or assembly, how to implement some things with Rust, etc. etc. and many other fun things I created a wiki page (https://github.com/mozilla/rust/wiki/Operating-system-development) that will reference resources, projects, etc. It's quite empty for now but I hope it will be filled soon :) Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jack at metajack.im Fri Oct 18 09:09:24 2013 From: jack at metajack.im (Jack Moffitt) Date: Fri, 18 Oct 2013 10:09:24 -0600 Subject: [rust-dev] mutable vs. functional APIs Message-ID: In the latest Rust upgrade for Servo, I noticed that the path API is now mutate-in-place instead of return a new path. It used to be that path.push("foo") gave you a new path with an extra component, but now path.push("foo") returns () and mutates the path in place. I liked the old API better. I realize this is probably more consistent with std::vec, and consistency is good. I thought I'd bring this up to see what other people thought as a lot of the APIs are getting rewritten lately and I haven't seen any concrete guidelines on what they should be. If we decide that both API styles are good to have, what should the naming convention be for the functional vs. mutable ones? Ruby, Scheme, and Clojure use `!` to denote the in-place mutation ones, but that syntax is for macros in rust. jack. From kevin at sb.org Fri Oct 18 09:46:47 2013 From: kevin at sb.org (Kevin Ballard) Date: Fri, 18 Oct 2013 09:46:47 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: <2BC8149F-E2E5-44A1-B0FE-B9325CBFFAD1@sb.org> The new Path API still has a "return a new path" set of APIs. They're just named differently. For example, the old path.push("foo") is now path.join("foo"). And all the path.set_*() mutating methods have variants path.with_*() that return a new path. -Kevin On Oct 18, 2013, at 9:09 AM, Jack Moffitt wrote: > In the latest Rust upgrade for Servo, I noticed that the path API is > now mutate-in-place instead of return a new path. It used to be that > path.push("foo") gave you a new path with an extra component, but now > path.push("foo") returns () and mutates the path in place. > > I liked the old API better. I realize this is probably more consistent > with std::vec, and consistency is good. I thought I'd bring this up to > see what other people thought as a lot of the APIs are getting > rewritten lately and I haven't seen any concrete guidelines on what > they should be. > > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > > jack. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From hatahet at gmail.com Fri Oct 18 10:23:15 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Fri, 18 Oct 2013 10:23:15 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: What about using Result types as mentioned here, but introducing some syntactic sugar to make chaining them easier? Something like Haskell's or Scala's "do" syntax: do ( a <- x // x and y are Results b <- y ) { /* do stuff with 'a' and 'b' */ } else { /* First Err is returned. Handle here. */ } -- Ziad On Thu, Oct 17, 2013 at 9:40 PM, Igor Bukanov wrote: > So the Go style is to call a function, check if the was an error, > update the error object (or create a new wrapping the old one) with > extra information relevant to the current call stack frame and > propagate the updated error object to the caller. If done > consistently, this could indeed provide very-user friendly error > messages. But it does clutter the code with if checks and does not > allow to recover so multiple errors could not be reported. > > In the above example the developer, before calling a parser library, > may want to say that IO errors should be recovered from, so they could > be reported together with other problems like syntax violations. I do > not see how the Go style could be adopted to that. In its design the > caller cannot influence the error propagation paths in the callee and > its stack subframes. > > On 18 October 2013 05:29, Steven Blenkinsop wrote: > > On Thursday, October 17, 2013, Igor Bukanov wrote: > >> > >> > >> Go - I have not used the language, but my general impression is that > >> no error will be generated. Instead the file will be read as an empty > >> string. > > > > > > Go encodes the error as a value which can be either treated as a string > or > > programmatically inspected to determine the correct response and returns > it > > along with an invalid file handle. If the code doesn't actually > specifically > > handle permission problems, it will usually create a new error value > > embedding the original error along with some context about what it was > doing > > when it got the error. This new error can then be used as a failure > value or > > passed up the stack, or it may be logged (potentially in combination with > > one of the other two options). This means that, even if the developer > didn't > > anticipate permissions issues, the error will likely contain all the > > relevant information, such as what line of the configuration file was > being > > processed as well as what file failed to open and why. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpet at google.com Fri Oct 18 10:54:23 2013 From: jpet at google.com (Jeff Petkau) Date: Fri, 18 Oct 2013 10:54:23 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: On my code (disclaimer: only toy projects to learn Rust so far), I've been pretty happy with a "mut_" prefix for mutable versions. newthing = oldthing.push(foo") anything.mut_push(foo") x = bagofun.sort() bagosadness.mut_sort() etc. Advantages: - consistent meaning with the 'mut' keyword. - works with pretty much any name. - makes mutable versions just a bit uglier than immutable code. Disadvantages: - If an API is inherently mutable, it gets pretty noisy. - A bit ugly, probably turns off newcomers. - If the compiler warns on ignoring return values, and mutating methods return (), then a convention might be unnecessary. --Jeff On Fri, Oct 18, 2013 at 9:09 AM, Jack Moffitt wrote: > In the latest Rust upgrade for Servo, I noticed that the path API is > now mutate-in-place instead of return a new path. It used to be that > path.push("foo") gave you a new path with an extra component, but now > path.push("foo") returns () and mutates the path in place. > > I liked the old API better. I realize this is probably more consistent > with std::vec, and consistency is good. I thought I'd bring this up to > see what other people thought as a lot of the APIs are getting > rewritten lately and I haven't seen any concrete guidelines on what > they should be. > > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > > jack. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Fri Oct 18 10:55:08 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Fri, 18 Oct 2013 10:55:08 -0700 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: I came across this blog post which may be relevant: https://coderwall.com/p/kokm7w -- Ziad On Fri, Oct 18, 2013 at 10:23 AM, Ziad Hatahet wrote: > What about using Result types as mentioned here, but introducing some > syntactic sugar to make chaining them easier? Something like Haskell's or > Scala's "do" syntax: > > do ( > a <- x // x and y are Results > b <- y > ) { /* do stuff with 'a' and 'b' */ } > else { > /* First Err is returned. Handle here. */ > } > > > > -- > Ziad > > > On Thu, Oct 17, 2013 at 9:40 PM, Igor Bukanov wrote: > >> So the Go style is to call a function, check if the was an error, >> update the error object (or create a new wrapping the old one) with >> extra information relevant to the current call stack frame and >> propagate the updated error object to the caller. If done >> consistently, this could indeed provide very-user friendly error >> messages. But it does clutter the code with if checks and does not >> allow to recover so multiple errors could not be reported. >> >> In the above example the developer, before calling a parser library, >> may want to say that IO errors should be recovered from, so they could >> be reported together with other problems like syntax violations. I do >> not see how the Go style could be adopted to that. In its design the >> caller cannot influence the error propagation paths in the callee and >> its stack subframes. >> >> On 18 October 2013 05:29, Steven Blenkinsop wrote: >> > On Thursday, October 17, 2013, Igor Bukanov wrote: >> >> >> >> >> >> Go - I have not used the language, but my general impression is that >> >> no error will be generated. Instead the file will be read as an empty >> >> string. >> > >> > >> > Go encodes the error as a value which can be either treated as a string >> or >> > programmatically inspected to determine the correct response and >> returns it >> > along with an invalid file handle. If the code doesn't actually >> specifically >> > handle permission problems, it will usually create a new error value >> > embedding the original error along with some context about what it was >> doing >> > when it got the error. This new error can then be used as a failure >> value or >> > passed up the stack, or it may be logged (potentially in combination >> with >> > one of the other two options). This means that, even if the developer >> didn't >> > anticipate permissions issues, the error will likely contain all the >> > relevant information, such as what line of the configuration file was >> being >> > processed as well as what file failed to open and why. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Oct 18 11:14:39 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 18 Oct 2013 14:14:39 -0400 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt wrote: > In the latest Rust upgrade for Servo, I noticed that the path API is > now mutate-in-place instead of return a new path. It used to be that > path.push("foo") gave you a new path with an extra component, but now > path.push("foo") returns () and mutates the path in place. > > I liked the old API better. I realize this is probably more consistent > with std::vec, and consistency is good. I thought I'd bring this up to > see what other people thought as a lot of the APIs are getting > rewritten lately and I haven't seen any concrete guidelines on what > they should be. > > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > > jack. > I think an immutable version should only be exposed if it's as efficient as operating in-place. For containers, I really don't want to have APIs that exist only to make allocating a whole new container and copying over more convenient. It's harder to write efficient code when inefficient code looks more idiomatic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Fri Oct 18 12:17:36 2013 From: kevin at sb.org (Kevin Ballard) Date: Fri, 18 Oct 2013 12:17:36 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: <90F950B8-674A-47F6-BBA3-DF9E7C9D9C4B@sb.org> On Oct 18, 2013, at 11:14 AM, Daniel Micay wrote: > On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt wrote: > In the latest Rust upgrade for Servo, I noticed that the path API is > now mutate-in-place instead of return a new path. It used to be that > path.push("foo") gave you a new path with an extra component, but now > path.push("foo") returns () and mutates the path in place. > > I liked the old API better. I realize this is probably more consistent > with std::vec, and consistency is good. I thought I'd bring this up to > see what other people thought as a lot of the APIs are getting > rewritten lately and I haven't seen any concrete guidelines on what > they should be. > > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > > jack. > > I think an immutable version should only be exposed if it's as efficient as operating in-place. For containers, I really don't want to have APIs that exist only to make allocating a whole new container and copying over more convenient. It's harder to write efficient code when inefficient code looks more idiomatic. I agree wholeheartedly with this. Path needed to preserve the convenient ?functional update? methods, because creating new paths based on existing immutable ones is rather common. But the APIs are definitely not more convenient than the mutation ones, just as convenient. Regarding Jeff?s suggestion for a mut_ prefix, that really only makes sense to me when returning some form of &mut value. Although that would typically be .as_mut_foo() rather than .mut_foo(). In general, I think method names should make it reasonably obvious whether it?s mutating or not without having to use ?mut_?. In the case of Path, the name .push() has a long history of mutating the receiver, so Path.push() mutates. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Fri Oct 18 12:34:25 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 18 Oct 2013 21:34:25 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification Message-ID: Hi list, This is meant as a followup to an earlier thread[1] on the subject and the related ticket[2]. [1]: http://thread.gmane.org/gmane.comp.lang.rust.devel/2622/ [2]: https://github.com/mozilla/rust/issues/6974 The idea in those earlier discussions is that methods could also be called using function syntax, supplying `self` as the first argument, so instead of `self_arg.method(arg)`, you could write `method(self_arg, arg)`. I'm wondering if this could be taken a couple steps further to simplify the whole story regarding functions, methods, traits, and impls. The idea is that the distiction between functions and methods would be erased almost completely, and methods (now being just functions) would be imported explicitly. It would involve the following pieces: - If the first argument of a top-level `fn` is named `self`, it can be called using method syntax. So if you have `fn foo(self: &MyType, n: int) { .. }` at the top level, you can write `object_of_my_type.foo(123)`. You can also still call it using function syntax: `foo(object_of_my_type, 123)`. - Anonymous `impl`s could then be removed in favor of such top-level `fn`s. Alternately, they could be kept as syntactic sugar for the same thing. - Just as the distinction between functions and anonymous-impl methods would be erased, the distinction between trait methods and associated functions would also be erased. A function declared inside a trait would exist in module scope, just like top-level `fn`s. Just like other functions, you could call it using method syntax if the first argument is named `self`, or using function syntax either way. - The existing syntax for `self` arguments could then be removed. Alternately, it could be kept as syntactic sugar (`?self` becoming `self: ?T`, where `?` is any sigil or none). - Now that everything is a top-level `fn`, they would be imported explicitly, like they (and all other things) already are. Here we can remove the restriction on methods needing to be declared in the same module/crate as their `self` type. - Functions can be called using method syntax only if they are declared in, or imported into, the current scope directly. In other words, if you could call them using function syntax unqualified. - If a method call is ambiguous, you would have the following options to resolve it: (a) Tweak your imports so that only the method you want is in scope. (b) Import the method under a different name instead. (c) Use function call syntax instead with an explicit module qualifier. Again, more or less the same options you have with any non-method item in the current language. Disadvantages of this scheme: - More typing. (Explicit imports for one; if sugar is removed, then that as well.) Advantages: - Simplicity and transparency. The special rules and language constructs for declaring and importing methods would go away. Methods would work the same way as other things do. - Correspondingly, you would also have better control over which methods are imported and invoked. - You could declare methods for any type in any crate or module, without having to create extraneous traits, which I feel is a wart in the current language. Traits could then be used for abstraction only, which I feel is their correct purpose. - Because methods would just be module-scope functions, they could be referred to as values (e.g. as arguments to higher-order functions) without a lambda shim. - I was confused at one point because `&self` looks a lot like a pattern match, but is not one. That could go away. - The current difficulties with generic methods (`impl T { .. }` in the current language) might, or might not, be reduced. (I don't know of any similar issues with generic top-level functions, but they might resurface if called as methods). - The significance of the argument named `self` could also potentially be removed, instead allowing the first argument to be used as the self-argument in a method call, no matter what it's called. This would allow for pattern matching on the self-argument in the definition of the method, which is currently not possible. Hope this is helpful or interesting, G?bor -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Fri Oct 18 12:56:13 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 18 Oct 2013 21:56:13 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> (Patrick Walton's message of "Thu, 17 Oct 2013 12:59:03 -0700") References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: <87ob6mqroi.fsf@mid.deneb.enyo.de> * Patrick Walton: > In other words: Why bet, as Go did, that the failure case won't > happen much in practice when we can adopt an error-handling strategy > that rules it out entirely? Uh-oh, I thought that Rust has ruled out error handling constructs based on implicit control flow? :-) But seriously, *this* particular issue is pretty well addressed by (unchecked) exceptions. They definitely encourage developers not to neglect error propagation. From banderson at mozilla.com Fri Oct 18 14:14:26 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 18 Oct 2013 14:14:26 -0700 Subject: [rust-dev] Rust and Servo internships with the GNOME Outreach Program for Women Message-ID: <5261A4B2.4000500@mozilla.com> Hello, This year, the Rust and Servo projects are participating in the GNOME Outreach Program for Women (OPW). OPW is an opportunity for women to take on a paid, full-time, three-month internship working on one of several open-source projects. Interns can be located anywhere in the world and will primarily work from home; some funding will be available to travel to meet with the project mentors for a brief period of time. This is the third time that Mozilla has participated as a source of project mentors, but it's the first time that the Rust and Servo projects specifically have participated. We're very excited about this and encourage you to apply if you're a woman who's interested in Rust. (OPW is an inclusive program: as per their information for applicants, "This program is open to anyone who is a female assigned at birth and anyone who identifies as a woman, genderqueer, genderfluid, or genderfree regardless of gender presentation or assigned sex at birth. Participants must be at least 18 years old at the start date of the internship.") If you're not eligible, please spread the word to any eligible individuals you know who have any interest in Rust or Servo. No previous experience with Rust is required, but we do request some experience with C and systems programming, and of course people who have previously used Rust may make faster progress. The deadline to apply is November 11. The details are available at: https://wiki.mozilla.org/GNOME_Outreach_December2013 (specific to Mozilla) https://wiki.gnome.org/OutreachProgramForWomen (applying to OPW) If you are not a woman, but interested in an internship working on Rust, never fear! If you are currently enrolled in an undergraduate or graduate program, you can apply for an internship at Mozilla Research for the winter, spring, or summer term. (Note that OPW is open to both students and non-students.) We will be announcing this program to the mailing list as well as soon as the details are finalized. If you have any questions, please join #opw on irc.mozilla.org and/or contact Tim Chevalier (tchevalier at mozilla.com, tjc on IRC) (Rust contact person) or Lars Bergstrom (lbergstrom at mozilla.com, lbergstrom on IRC) (Servo contact person). From fw at deneb.enyo.de Fri Oct 18 14:20:32 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 18 Oct 2013 23:20:32 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: (Igor Bukanov's message of "Fri, 18 Oct 2013 06:40:43 +0200") References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> Message-ID: <87vc0umg2n.fsf@mid.deneb.enyo.de> * Igor Bukanov: > So the Go style is to call a function, check if the was an error, > update the error object (or create a new wrapping the old one) with > extra information relevant to the current call stack frame and > propagate the updated error object to the caller. It's more common to simply return the object. Due to some obscure feature of Go's type system, error values have to be interfaces and cannot be struct types, so I have not seen anyone trying to updating an existing error. Wrapping might happen, but there is no general chaining mechanism like there is in Java. From banderson at mozilla.com Fri Oct 18 14:38:57 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 18 Oct 2013 14:38:57 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: <5261AA71.1080403@mozilla.com> On 10/18/2013 11:14 AM, Daniel Micay wrote: > On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt > wrote: > > In the latest Rust upgrade for Servo, I noticed that the path API is > now mutate-in-place instead of return a new path. It used to be that > path.push("foo") gave you a new path with an extra component, but now > path.push("foo") returns () and mutates the path in place. > > I liked the old API better. I realize this is probably more consistent > with std::vec, and consistency is good. I thought I'd bring this up to > see what other people thought as a lot of the APIs are getting > rewritten lately and I haven't seen any concrete guidelines on what > they should be. > > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > > jack. > > > I think an immutable version should only be exposed if it's as > efficient as operating in-place. For containers, I really don't want > to have APIs that exist only to make allocating a whole new container > and copying over more convenient. It's harder to write efficient code > when inefficient code looks more idiomatic. Efficiency isn't the only design consideration and not always the most important, even in Rust. I imagine that path manipulation is not a performance bottleneck for most applications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Fri Oct 18 14:49:54 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 18 Oct 2013 23:49:54 +0200 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 6:09 PM, Jack Moffitt wrote: > If we decide that both API styles are good to have, what should the > naming convention be for the functional vs. mutable ones? Ruby, > Scheme, and Clojure use `!` to denote the in-place mutation ones, but > that syntax is for macros in rust. > FWIW, the convention in many other APIs is that the return-modified-copy versions use past participle. So e.g. the modify-in-place method would be called `foo.frobulate()`, while the "functional" one would be called `foo.frobulated()`. I think this is nice, but it can get a bit more difficult with arguments. (If the mutating method is called `foo.append(bar)`, what's the other one? `foo.appended(bar)`? `foo.with_appended(bar)`? Something else?) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Fri Oct 18 15:01:22 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Sat, 19 Oct 2013 00:01:22 +0200 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: To be clear, '!' doesn't mean mutation, it means 'dangerous.' For example, some methods return nil on error, and the bang version throws an excption on error. Sometimes, mutation is dangerous, though... ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhm456 at gmail.com Fri Oct 18 16:37:22 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Fri, 18 Oct 2013 16:37:22 -0700 Subject: [rust-dev] real-time programming? usability? Message-ID: Hello! While reading the Rust tutorial I'm really excited to see a new programming language that can replace C/C++ for performance-critical programming. C/C++ is very entrenched but extremely tricky and getting more complicated with each revision. The world needs a replacement that's not so perilous -- before it causes big disasters. I'd like to suggest some (hopefully useful) ideas. (1) Rust has great potential for *real-time programming* as well as secure programming. Perhaps this just needs a library call to fork "real-time threads" that never do garbage collection. ("Real-time" means predictably meeting time deadlines, e.g. in avionics, video capture, medical x-ray, and robotics. Speed is important but the crucial point is reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time optimizers are bad for predictability.) Maybe Rust already has this. What determines whether a thread-local managed heap uses reference counting? Ref-counting may be OK in a real-time thread if it doesn't deallocate a variable-length chain of nodes at an inconvenient time. (2) I'd like to see programming language designers follow other domains by doing usability testing. As Alan Kay said, "The users are not like us." If you're a language designer or implementer, you can be sure that few language users will have your deep understanding of it. Few programmers read the entire language reference manual or even learn all the core semantics. E.g. what percent of Java programmers know about "precise exceptions" and their implications for optimization? What percent can declare bounded generic types? What percent understand "volatile" and lock ordering? Many real-time programs are *safety-critical*, which has more or less the same language needs as security-critical: fewer failure modes, easy to understand and reason about, less error-prone, easier to learn, easier to document. We could measure this for a language by the number of traps, pitfalls, and puzzlers books. There are shelves of such books for C++ and one puzzlers book for Java. Can Rust get it down to a one-pager? Rust eliminates many C++ failure modes, including memory access errors and octal constants that look like decimals. Could it systematically eliminate the failure modes listed in C++ traps & pitfalls books? Some examples: - Make the everyday int and uint types portable, that is, produce the same results on all platforms. int size does matter when it varies between 16 and 64 bits. If Rust needs an integer type that?s the size of a pointer, call it intptr_t and only use it for that special case. - Security holes happen whenever a program does exploitably unexpected things. When the unexpected results happen in rarely-tested cases like integer overflow, it?s bad for security. So consider arbitrary precision int. - Use postfix syntax for pointer dereference, like in Pascal: (~rect).area() becomes rect~.area() . That reads left-to-right with nary a precedence mistake. While Rust?s auto-dereference feature and type checker will sometimes catch that mistake, it's better to just fix the failure mode. All security holes in the field got past the type checker and unit tests. - Don?t let ; default its second operand. Require an explicit value, even if (). That fixes an opportunity to goof that might be frequent among programmers used to ending every statement with a ;. - AIUI, let mut x, y defines 2 mutable variables but |mut x, y| defines mutable x and immutable y. This is harder to learn and easier to goof. - Drop C-compatible struct layout support? Is such a goal practical considering that C struct layouts vary by CPU, compiler, and compiler switches (enum size, pointer size, integer alignment, bit-field padding, etc.)? C can?t reliably pass a struct to a dynamically-loaded module (that has burned me) or to another computer (that, too). A better approach is a library like Protocol Buffers or Cap?n Proto. Thanks for listening! -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Fri Oct 18 16:47:09 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 19 Oct 2013 10:47:09 +1100 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: <5261C87D.1030808@gmail.com> On 19/10/13 10:37, Jerry Morrison wrote: > > * Use postfix syntax for pointer dereference, like in Pascal: > (~rect).area() becomes rect~.area() . That reads left-to-right > with nary a precedence mistake. > > While Rust?s auto-dereference feature and type checker will > sometimes catch that mistake, it's better to just fix the failure > mode. All security holes in the field got past the type checker > and unit tests. > Do you realise that `~rect` means "create an owned box [a pointer] that contains `rect`" and isn't not a dereference in Rust? (That is performed by `*rect`.) > > * Don?t let ; default its second operand. Require an explicit value, > even if (). That fixes an opportunity to goof that might be > frequent among programmers used to ending every statement with a ;. > `;` isn't a binary operator, and anyway `a; b` doesn't affect the behaviour of `b` at all. Could you describe what you mean a little more? (Also the type system means that writing `fn foo() -> int { 1; }` (with the extra & incorrect semicolon) is caught immediately.) > * AIUI, let mut x, y defines 2 mutable variables but |mut x, y| > defines mutable x and immutable y. This is harder to learn and > easier to goof. > `let mut x, y` doesn't exist at the moment precisely because of the confusion; one has to write `let mut x; let mut y;`. (Relatedly There is a proposal to make `mut ` a valid pattern, so that `let (mut x, y)` is valid: https://github.com/mozilla/rust/issues/9792 ) > > Thanks for listening! > > -- > Jerry > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Fri Oct 18 17:59:58 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Fri, 18 Oct 2013 20:59:58 -0400 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <87vc0umg2n.fsf@mid.deneb.enyo.de> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> <87vc0umg2n.fsf@mid.deneb.enyo.de> Message-ID: On Friday, 18 October 2013, Florian Weimer wrote: > > > It's more common to simply return the object. > Only in toy programs, or where there is no meaningful additional context. > Due to some obscure feature of Go's type system, error values have to > be interfaces and cannot be struct types Struct types can be put in interfaces and extracted using type assertions, such as the error returned by os.Open. However the general case is to use textual errors. > , so I have not seen anyone > trying to updating an existing error. Wrapping might happen, but > there is no general chaining mechanism like there is in Java. > The default is fmt.Errorf for textual errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Oct 18 18:13:05 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 18 Oct 2013 21:13:05 -0400 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: > > > (1) Rust has great potential for *real-time programming* as well as > secure programming. Perhaps this just needs a library call to fork > "real-time threads" that never do garbage collection. ("Real-time" means > predictably meeting time deadlines, e.g. in avionics, video capture, > medical x-ray, and robotics. Speed is important but the crucial point is > reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time > optimizers are bad for predictability.) Maybe Rust already has this. What > determines whether a thread-local managed heap uses reference counting? > Ref-counting may be OK in a real-time thread if it doesn't deallocate a > variable-length chain of nodes at an inconvenient time. > Rust leaves memory allocation up to the user as much as C++. Most code can simply use unboxed values and lightweight references, with occasional usage of owned boxes (single-owner heap allocations, with lifetime tied to scope). If you need shared ownership, it's available via the `Rc`/`RcMut` types. Every split of ownership is explicit via a `clone` call since moves are the default. There will be a task-local garbage collector providing garbage collected pointers, but it still needs to be implemented. The standard library implements N:M concurrency and exposes a blocking API for asynchronous I/O. I don't think it would be suitable for a real-time application, but you can avoid the standard library: https://github.com/thestinger/rust-core Some examples: > > - Make the everyday int and uint types portable, that is, produce the > same results on all platforms. int size does matter when it varies > between 16 and 64 bits. If Rust needs an integer type that?s the size of a > pointer, call it intptr_t and only use it for that special case. > > There are fixed-size integers and floats and then the pointer-sized integers. I agree that renaming the pointer-size ones to `intptr`/`uintptr` would be great. I just filed https://github.com/mozilla/rust/issues/9940about this, so feel free to voice support there :). > > - Security holes happen whenever a program does exploitably unexpected > things. When the unexpected results happen in rarely-tested cases like > integer overflow, it?s bad for security. So consider arbitrary precision > int. > > A relatively slow big integer type exists in the standard library. There are two issues blocking it from being as first-class as the built-in types: * https://github.com/mozilla/rust/issues/4169 * https://github.com/mozilla/rust/issues/6023 > > > - AIUI, let mut x, y defines 2 mutable variables but |mut x, y| defines mutable > x and immutable y. This is harder to learn and easier to goof. > > This syntax has been removed. The `mut` keyword will eventually be usable on variable bindings in patterns, like `let mut x = 5` or `let (x, mut y) = (1, 2). > > > - Drop C-compatible struct layout support? Is such a goal practical > considering that C struct layouts vary by CPU, compiler, and compiler > switches (enum size, pointer size, integer alignment, bit-field padding, > etc.)? C can?t reliably pass a struct to a dynamically-loaded module (that > has burned me) or to another computer (that, too). A better approach is a > library like Protocol Buffers or Cap?n Proto. > > The `struct` layout must be compatible with the platform ABI. There's no way around the need to be interoperable with existing kernels, libraries and languages, and it needs to be efficient. Rust doesn't provide any guarantees for `enum` layout, and doesn't implement bit fields. The guarantee is not intended to be used directly for serialization. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qwertie256 at gmail.com Fri Oct 18 18:36:17 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Fri, 18 Oct 2013 19:36:17 -0600 Subject: [rust-dev] real-time programming? usability? Message-ID: > > * Use postfix syntax for pointer dereference, like in Pascal: > > (~rect).area() becomes rect~.area() . That reads left-to-right > > with nary a precedence mistake. > > > > While Rust?s auto-dereference feature and type checker will > > sometimes catch that mistake, it's better to just fix the failure > > mode. All security holes in the field got past the type checker > > and unit tests. > > > > Do you realise that `~rect` means "create an owned box [a pointer] that > contains `rect`" and isn't not a dereference in Rust? (That is performed > by `*rect`.) > > I would add that if pointer dereference were a suffix operator, it would have to be changed from * to (e.g.) ~. Why? Because if foo* means "dereference foo" then it becomes ambiguous whether "foo * - bar" means (foo*)-bar "dereference foo and subtract bar" or foo*(-bar) "multiply foo by negated bar". Due to this ambiguity, it is difficult for a language to simultaneously have 1. Operators that can be prefix or infix, and 2. Operators that can be infix or suffix. To avoid the ambiguity, one can introduce an operator like ~ that is prefix or suffix but never infix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ercerden at gmail.com Fri Oct 18 20:43:38 2013 From: ercerden at gmail.com (Ercan Erden) Date: Fri, 18 Oct 2013 23:43:38 -0400 Subject: [rust-dev] New Arch Linux Packages Message-ID: Hi, I recently added rust-http, rust-mustache and rust-sqlite to AUR for Arch Linux users. These should make some web development related stuff easier. I'll add more packages soon. Links to github pages of the packages: rust-http : https://github.com/chris-morgan/rust-http rust-mustache : https://github.com/erickt/rust-mustache rust-sqlite : https://github.com/linuxfood/rustsqlite If you're not familiar with AUR and AUR helpers see the relevant wiki pages: https://wiki.archlinux.org/index.php/Arch_User_Repository https://wiki.archlinux.org/index.php/AUR_Helpers From jhm456 at gmail.com Fri Oct 18 21:27:28 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Fri, 18 Oct 2013 21:27:28 -0700 Subject: [rust-dev] real-time programming? usability? In-Reply-To: <5261C87D.1030808@gmail.com> References: <5261C87D.1030808@gmail.com> Message-ID: On Fri, Oct 18, 2013 at 4:47 PM, Huon Wilson wrote: > On 19/10/13 10:37, Jerry Morrison wrote: > > > > - Use postfix syntax for pointer dereference, like in Pascal: > (~rect).area() becomes rect~.area() . That reads left-to-right with > nary a precedence mistake. > > While Rust?s auto-dereference feature and type checker will sometimes > catch that mistake, it's better to just fix the failure mode. All security > holes in the field got past the type checker and unit tests. > > > Do you realise that `~rect` means "create an owned box [a pointer] that > contains `rect`" and isn't not a dereference in Rust? (That is performed by > `*rect`.) > Ah! Thanks. I had the mistaken impression that one had to use the same dereference operator for each kind of pointer. > > > - Don?t let ; default its second operand. Require an explicit value, > even if (). That fixes an opportunity to goof that might be frequent > among programmers used to ending every statement with a ;. > > > `;` isn't a binary operator, and anyway `a; b` doesn't affect the > behaviour of `b` at all. Could you describe what you mean a little more? > > (Also the type system means that writing `fn foo() -> int { 1; }` (with > the extra & incorrect semicolon) is caught immediately.) > Yes, I'm thinking of, say, { 1; } as a function body or a match clause. If the type checker always catches a stray (;) when it matters [no problem with { (); } ], then great. No bugs there. I found it difficult to explain Rust's (;) to a programmer used to statement syntax. He said he couldn't look at a line and say "it's wrong" if it either has a (;) (like Ruby, Python, Go) or if it doesn't have one (C, C++). My solution was to explain it like C's (,) sequence operator but it can be infix or postfix [meaning { 1; () } ]. > > - AIUI, let mut x, y defines 2 mutable variables but |mut x, y| defines mutable > x and immutable y. This is harder to learn and easier to goof. > > > `let mut x, y` doesn't exist at the moment precisely because of the > confusion; one has to write `let mut x; let mut y;`. (Relatedly There is a > proposal to make `mut ` a valid pattern, so that `let (mut x, y)` is > valid: https://github.com/mozilla/rust/issues/9792 ) > > > Thanks for listening! > > -- > Jerry > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhm456 at gmail.com Fri Oct 18 21:45:29 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Fri, 18 Oct 2013 21:45:29 -0700 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay wrote: > On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: >> >> >> (1) Rust has great potential for *real-time programming* as well as >> secure programming. Perhaps this just needs a library call to fork >> "real-time threads" that never do garbage collection. ("Real-time" means >> predictably meeting time deadlines, e.g. in avionics, video capture, >> medical x-ray, and robotics. Speed is important but the crucial point is >> reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time >> optimizers are bad for predictability.) Maybe Rust already has this. What >> determines whether a thread-local managed heap uses reference counting? >> Ref-counting may be OK in a real-time thread if it doesn't deallocate a >> variable-length chain of nodes at an inconvenient time. >> > > Rust leaves memory allocation up to the user as much as C++. Most code can > simply use unboxed values and lightweight references, with occasional usage > of owned boxes (single-owner heap allocations, with lifetime tied to scope). > Ideally, forking a real-time thread could ensure that (1) no GC pauses the thread just to find out there's no garbage to collect, and (2) something would catch the mistake if it ever calls code (directly or indirectly) that evolves to using GC memory. > If you need shared ownership, it's available via the `Rc`/`RcMut` types. > Every split of ownership is explicit via a `clone` call since moves are the > default. There will be a task-local garbage collector providing garbage > collected pointers, but it still needs to be implemented. > Sounds good, although I don't understand the details. Does the program pick between GC allocation and ref counting allocation via the choice of pointer sigils? Via the choice of library calls? > The standard library implements N:M concurrency and exposes a blocking API > for asynchronous I/O. I don't think it would be suitable for a real-time > application, but you can avoid the standard library: > https://github.com/thestinger/rust-core > What's N:M concurrency? > > Some examples: >> >> - Make the everyday int and uint types portable, that is, produce the >> same results on all platforms. int size does matter when it varies >> between 16 and 64 bits. If Rust needs an integer type that?s the size of a >> pointer, call it intptr_t and only use it for that special case. >> >> There are fixed-size integers and floats and then the pointer-sized > integers. I agree that renaming the pointer-size ones to `intptr`/`uintptr` > would be great. I just filed https://github.com/mozilla/rust/issues/9940about this, so feel free to voice support there :). > Will do. > > >> >> - Security holes happen whenever a program >> does exploitably unexpected things. When the unexpected results happen in >> rarely-tested cases like integer overflow, it?s bad for security. So >> consider arbitrary precision int. >> >> A relatively slow big integer type exists in the standard library. There > are two issues blocking it from being as first-class as the built-in types: > > * https://github.com/mozilla/rust/issues/4169 > * https://github.com/mozilla/rust/issues/6023 > >> >> >> - AIUI, let mut x, y defines 2 mutable variables but |mut x, y| defines mutable >> x and immutable y. This is harder to learn and easier to goof. >> >> This syntax has been removed. The `mut` keyword will eventually be usable > on variable bindings in patterns, like `let mut x = 5` or `let (x, mut y) = > (1, 2). > >> >> >> - Drop C-compatible struct layout support? Is such a goal practical >> considering that C struct layouts vary by CPU, compiler, and compiler >> switches (enum size, pointer size, integer alignment, bit-field padding, >> etc.)? C can?t reliably pass a struct to a dynamically-loaded module (that >> has burned me) or to another computer (that, too). A better approach is a >> library like Protocol Buffers or Cap?n Proto. >> >> The `struct` layout must be compatible with the platform ABI. There's no > way around the need to be interoperable with existing kernels, libraries > and languages, and it needs to be efficient. Rust doesn't provide any > guarantees for `enum` layout, and doesn't implement bit fields. The > guarantee is not intended to be used directly for serialization. > Ah. It focuses on the core cases. A case that crashed on me was calling libjpeg.so when compiled with a gcc switch that set small enums. A student put that switch in the make file because he got burned by enum sizes when calling the OS on a Chumby. -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Oct 18 23:02:43 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 19 Oct 2013 02:02:43 -0400 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 12:45 AM, Jerry Morrison wrote: > > On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay wrote: > >> On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: >>> >>> >>> (1) Rust has great potential for *real-time programming* as well as >>> secure programming. Perhaps this just needs a library call to fork >>> "real-time threads" that never do garbage collection. ("Real-time" means >>> predictably meeting time deadlines, e.g. in avionics, video capture, >>> medical x-ray, and robotics. Speed is important but the crucial point is >>> reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time >>> optimizers are bad for predictability.) Maybe Rust already has this. What >>> determines whether a thread-local managed heap uses reference counting? >>> Ref-counting may be OK in a real-time thread if it doesn't deallocate a >>> variable-length chain of nodes at an inconvenient time. >>> >> >> Rust leaves memory allocation up to the user as much as C++. Most code >> can simply use unboxed values and lightweight references, with occasional >> usage of owned boxes (single-owner heap allocations, with lifetime tied to >> scope). >> > > Ideally, forking a real-time thread could ensure that (1) no GC pauses the > thread just to find out there's no garbage to collect, and (2) something > would catch the mistake if it ever calls code (directly or indirectly) that > evolves to using GC memory. > Rust doesn't currently have a way to forbid features only in some parts of the code but not others. Avoiding garbage collection as a hard requirement will likely mean using rust-core (or whatever it evolves to, maybe a special profile of the standard library). If you need shared ownership, it's available via the `Rc`/`RcMut` types. >> Every split of ownership is explicit via a `clone` call since moves are the >> default. There will be a task-local garbage collector providing garbage >> collected pointers, but it still needs to be implemented. >> > > Sounds good, although I don't understand the details. Does the program > pick between GC allocation and ref counting allocation via the choice of > pointer sigils? Via the choice of library calls? > Reference counting is implemented as a library type, so you would make a reference counted allocation with `Rc::new(value)` and make an explicit reference count with `box.clone()` (the implementation: https://github.com/mozilla/rust/blob/master/src/libstd/rc.rs). There are managed pointers sigils for garbage collection (@, @mut) but I think consensus is trending towards replacing the syntax with a type similar to `Rc` allowing cycles and implicit copies. The compiler support could be exposed via attributes hooks like the operator traits, rather than syntax. > The standard library implements N:M concurrency and exposes a blocking API > for asynchronous I/O. I don't think it would be suitable for a real-time > application, but you can avoid the standard library: > https://github.com/thestinger/rust-core > What's N:M concurrency? > The concurrency model implemented in the standard library treats real threads as schedulers, and maps cooperatively scheduled tasks onto them. If the task doesn't make calls to functions with yields, it will monopolize a scheduler thread. It's a very good model for I/O or for high throughput on many CPU-bound batch jobs (https://www.threadingbuildingblocks.org/), but it's not going to be suitable for real-time needs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Fri Oct 18 23:08:47 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Fri, 18 Oct 2013 23:08:47 -0700 Subject: [rust-dev] Strange behavior about Writer trait Message-ID: I run into the following problem (the code below is a toy example). ``` use std::io::Writer; // Makes no difference if added/removed. trait PrintWithSpice { fn print(&self, writer: &Writer, spice: bool); } struct Bar { bar: ~PrintWithSpice, } impl Bar { pub fn print(&self, writer: &Writer) { self.bar.print(writer, false); Bar::print_via_borrowed(writer, &self.bar); } fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) { // Invoking the `print` function via the borrowed pointer to the `PrintWithSpice` trait: // Works fine, as expected.. data.print(writer, true); } } struct Foo { foo: bool } impl PrintWithSpice for Foo { fn print(&self, writer: &Writer, spice: bool) { // Invoking the `write_str` function via the borrowed pointer to the `Writer` trait: // error: failed to find an implementation of trait std::io::Writer for &std::io::Writer // What is going on? writer.write_str(format!("foo: {:b} spice: {:b}", self.foo, spice)); } } ``` I didn't understand what the compiler is complaining about. "failed to find an implementation of Foo for &Foo"? A Foo is a Foo, no? Calling a function via a borrowed pointer to a trait should just work (it does a few lines above). After digging I discovered what the compiler really meant (I think). The `write_str` method is defined for `WriterUtils` rather than for `Writer`. So, if I replace `Writer` by `WriterUtil` in the above code, it compiles fine. So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am using that instead of `Writer` all over my code. I can see doing that as a workaround, but it doesn't smell right to me. So: * Why is the compiler complaining about not finding an implementation for `Writer` when the method I invoke is from `WriterUtil`? * Since there is an `impl for WriterUtil`, shouldn't the compiler be "sufficiently smart" to deduce that the code is valid in the 1st place? * Until the compiler is "sufficiently smart" (or, if there is a good reason why it would never be), shouldn't we rename `Writer` to `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so `&Writer` would become more usable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Fri Oct 18 23:27:28 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 19 Oct 2013 09:27:28 +0300 Subject: [rust-dev] Strange behavior about Writer trait In-Reply-To: References: Message-ID: Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, but I can't cast any @Writer (such as `io::stdout()`) to it. I guess I should just use `@Writer` everywhere for now :-( This raises the question of how come the compiler is smart enough to figure out a `@Writer` has the trait `WriterUtil`, but isn't smart enough to figure out a `&Writer` has the trait... On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote: > I run into the following problem (the code below is a toy example). > > ``` > use std::io::Writer; // Makes no difference if added/removed. > > trait PrintWithSpice { > fn print(&self, writer: &Writer, spice: bool); > } > > struct Bar { > bar: ~PrintWithSpice, > } > > impl Bar { > pub fn print(&self, writer: &Writer) { > self.bar.print(writer, false); > Bar::print_via_borrowed(writer, &self.bar); > } > > fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) { > // Invoking the `print` function via the borrowed pointer to the > `PrintWithSpice` trait: > // Works fine, as expected.. > data.print(writer, true); > } > } > > struct Foo { > foo: bool > } > > impl PrintWithSpice for Foo { > fn print(&self, writer: &Writer, spice: bool) { > // Invoking the `write_str` function via the borrowed pointer to > the `Writer` trait: > // error: failed to find an implementation of trait > std::io::Writer for &std::io::Writer > // What is going on? > writer.write_str(format!("foo: {:b} spice: {:b}", self.foo, > spice)); > } > } > ``` > > I didn't understand what the compiler is complaining about. "failed to > find an implementation of Foo for &Foo"? A Foo is a Foo, no? > Calling a function via a borrowed pointer to a trait should just work (it > does a few lines above). > > After digging I discovered what the compiler really meant (I think). The > `write_str` method is defined for `WriterUtils` rather than for `Writer`. > So, if I replace `Writer` by `WriterUtil` in the above code, it compiles > fine. > > So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am > using that instead of `Writer` all over my code. I can see doing that as a > workaround, but it doesn't smell right to me. > > So: > > * Why is the compiler complaining about not finding an implementation for > `Writer` when the method I invoke is from `WriterUtil`? > > * Since there is an `impl for WriterUtil`, shouldn't the > compiler be "sufficiently smart" to deduce that the code is valid in the > 1st place? > > * Until the compiler is "sufficiently smart" (or, if there is a good > reason why it would never be), shouldn't we rename `Writer` to > `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so > `&Writer` would become more usable? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Fri Oct 18 23:29:18 2013 From: sfackler at gmail.com (Steven Fackler) Date: Fri, 18 Oct 2013 23:29:18 -0700 Subject: [rust-dev] Strange behavior about Writer trait In-Reply-To: References: Message-ID: If T is a trait, its trait objects ~T, @T and &T do not implement T. There is an implementation of Writer for @Writer, but not for ~Writer or &Writer which is why you're seeing that error. Steven Fackler On Fri, Oct 18, 2013 at 11:27 PM, Oren Ben-Kiki wrote: > Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, but > I can't cast any @Writer (such as `io::stdout()`) to it. I guess I should > just use `@Writer` everywhere for now :-( > > This raises the question of how come the compiler is smart enough to > figure out a `@Writer` has the trait `WriterUtil`, but isn't smart enough > to figure out a `&Writer` has the trait... > > > On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote: > >> I run into the following problem (the code below is a toy example). >> >> ``` >> use std::io::Writer; // Makes no difference if added/removed. >> >> trait PrintWithSpice { >> fn print(&self, writer: &Writer, spice: bool); >> } >> >> struct Bar { >> bar: ~PrintWithSpice, >> } >> >> impl Bar { >> pub fn print(&self, writer: &Writer) { >> self.bar.print(writer, false); >> Bar::print_via_borrowed(writer, &self.bar); >> } >> >> fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) { >> // Invoking the `print` function via the borrowed pointer to the >> `PrintWithSpice` trait: >> // Works fine, as expected.. >> data.print(writer, true); >> } >> } >> >> struct Foo { >> foo: bool >> } >> >> impl PrintWithSpice for Foo { >> fn print(&self, writer: &Writer, spice: bool) { >> // Invoking the `write_str` function via the borrowed pointer to >> the `Writer` trait: >> // error: failed to find an implementation of trait >> std::io::Writer for &std::io::Writer >> // What is going on? >> writer.write_str(format!("foo: {:b} spice: {:b}", self.foo, >> spice)); >> } >> } >> ``` >> >> I didn't understand what the compiler is complaining about. "failed to >> find an implementation of Foo for &Foo"? A Foo is a Foo, no? >> Calling a function via a borrowed pointer to a trait should just work (it >> does a few lines above). >> >> After digging I discovered what the compiler really meant (I think). The >> `write_str` method is defined for `WriterUtils` rather than for `Writer`. >> So, if I replace `Writer` by `WriterUtil` in the above code, it compiles >> fine. >> >> So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am >> using that instead of `Writer` all over my code. I can see doing that as a >> workaround, but it doesn't smell right to me. >> >> So: >> >> * Why is the compiler complaining about not finding an implementation for >> `Writer` when the method I invoke is from `WriterUtil`? >> >> * Since there is an `impl for WriterUtil`, shouldn't the >> compiler be "sufficiently smart" to deduce that the code is valid in the >> 1st place? >> >> * Until the compiler is "sufficiently smart" (or, if there is a good >> reason why it would never be), shouldn't we rename `Writer` to >> `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so >> `&Writer` would become more usable? >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Fri Oct 18 23:47:07 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 19 Oct 2013 09:47:07 +0300 Subject: [rust-dev] Strange behavior about Writer trait In-Reply-To: References: Message-ID: Hmmm.... That sounds strange. Shouldn't `obj: &T` allow me to invoke `obj.method_of_T()`? For example, how did I manage to invoke the `data.print(...)` method via the borrowed `data: &PrintWithSpice` pointer? Automatic dereference? And if so, why didn't it work for `Writer` as well? On Sat, Oct 19, 2013 at 9:29 AM, Steven Fackler wrote: > If T is a trait, its trait objects ~T, @T and &T do not implement T. There > is an implementation of Writer for @Writer, but not for ~Writer or &Writer > which is why you're seeing that error. > > Steven Fackler > > > On Fri, Oct 18, 2013 at 11:27 PM, Oren Ben-Kiki wrote: > >> Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, but >> I can't cast any @Writer (such as `io::stdout()`) to it. I guess I should >> just use `@Writer` everywhere for now :-( >> >> This raises the question of how come the compiler is smart enough to >> figure out a `@Writer` has the trait `WriterUtil`, but isn't smart enough >> to figure out a `&Writer` has the trait... >> >> >> On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote: >> >>> I run into the following problem (the code below is a toy example). >>> >>> ``` >>> use std::io::Writer; // Makes no difference if added/removed. >>> >>> trait PrintWithSpice { >>> fn print(&self, writer: &Writer, spice: bool); >>> } >>> >>> struct Bar { >>> bar: ~PrintWithSpice, >>> } >>> >>> impl Bar { >>> pub fn print(&self, writer: &Writer) { >>> self.bar.print(writer, false); >>> Bar::print_via_borrowed(writer, &self.bar); >>> } >>> >>> fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) { >>> // Invoking the `print` function via the borrowed pointer to the >>> `PrintWithSpice` trait: >>> // Works fine, as expected.. >>> data.print(writer, true); >>> } >>> } >>> >>> struct Foo { >>> foo: bool >>> } >>> >>> impl PrintWithSpice for Foo { >>> fn print(&self, writer: &Writer, spice: bool) { >>> // Invoking the `write_str` function via the borrowed pointer to >>> the `Writer` trait: >>> // error: failed to find an implementation of trait >>> std::io::Writer for &std::io::Writer >>> // What is going on? >>> writer.write_str(format!("foo: {:b} spice: {:b}", self.foo, >>> spice)); >>> } >>> } >>> ``` >>> >>> I didn't understand what the compiler is complaining about. "failed to >>> find an implementation of Foo for &Foo"? A Foo is a Foo, no? >>> Calling a function via a borrowed pointer to a trait should just work (it >>> does a few lines above). >>> >>> After digging I discovered what the compiler really meant (I think). The >>> `write_str` method is defined for `WriterUtils` rather than for `Writer`. >>> So, if I replace `Writer` by `WriterUtil` in the above code, it compiles >>> fine. >>> >>> So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am >>> using that instead of `Writer` all over my code. I can see doing that as a >>> workaround, but it doesn't smell right to me. >>> >>> So: >>> >>> * Why is the compiler complaining about not finding an implementation >>> for `Writer` when the method I invoke is from `WriterUtil`? >>> >>> * Since there is an `impl for WriterUtil`, shouldn't the >>> compiler be "sufficiently smart" to deduce that the code is valid in the >>> 1st place? >>> >>> * Until the compiler is "sufficiently smart" (or, if there is a good >>> reason why it would never be), shouldn't we rename `Writer` to >>> `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so >>> `&Writer` would become more usable? >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sat Oct 19 05:47:57 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sat, 19 Oct 2013 14:47:57 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 9:34 PM, G?bor Lehel wrote: > Hi list, > > This is meant as a followup to an earlier thread[1] on the subject and the > related ticket[2]. > > [1]: http://thread.gmane.org/gmane.comp.lang.rust.devel/2622/ > [2]: https://github.com/mozilla/rust/issues/6974 > > The idea in those earlier discussions is that methods could also be called > using function syntax, supplying `self` as the first argument, so instead > of `self_arg.method(arg)`, you could write `method(self_arg, arg)`. I'm > wondering if this could be taken a couple steps further to simplify the > whole story regarding functions, methods, traits, and impls. The idea is > that the distiction between functions and methods would be erased almost > completely, and methods (now being just functions) would be imported > explicitly. > > It would involve the following pieces: > > - If the first argument of a top-level `fn` is named `self`, it can be > called using method syntax. So if you have `fn foo(self: &MyType, n: int) > { .. }` at the top level, you can write `object_of_my_type.foo(123)`. You > can also still call it using function syntax: `foo(object_of_my_type, 123)`. > I see no reason for the restriction of "self". Why not simply say that any function can be called with "first_arg.func(...)" style ? Regarding the idea in general, I like the elegance that such harmonization brings. -- Matthieu > > - Anonymous `impl`s could then be removed in favor of such top-level > `fn`s. Alternately, they could be kept as syntactic sugar for the same > thing. > > - Just as the distinction between functions and anonymous-impl methods > would be erased, the distinction between trait methods and associated > functions would also be erased. A function declared inside a trait would > exist in module scope, just like top-level `fn`s. Just like other > functions, you could call it using method syntax if the first argument is > named `self`, or using function syntax either way. > > - The existing syntax for `self` arguments could then be removed. > Alternately, it could be kept as syntactic sugar (`?self` becoming `self: > ?T`, where `?` is any sigil or none). > > - Now that everything is a top-level `fn`, they would be imported > explicitly, like they (and all other things) already are. Here we can > remove the restriction on methods needing to be declared in the same > module/crate as their `self` type. > > - Functions can be called using method syntax only if they are declared > in, or imported into, the current scope directly. In other words, if you > could call them using function syntax unqualified. > > - If a method call is ambiguous, you would have the following options to > resolve it: > > (a) Tweak your imports so that only the method you want is in scope. > > (b) Import the method under a different name instead. > > (c) Use function call syntax instead with an explicit module qualifier. > > Again, more or less the same options you have with any non-method item in > the current language. > > > Disadvantages of this scheme: > > - More typing. (Explicit imports for one; if sugar is removed, then that > as well.) > > > Advantages: > > - Simplicity and transparency. The special rules and language constructs > for declaring and importing methods would go away. Methods would work the > same way as other things do. > > - Correspondingly, you would also have better control over which methods > are imported and invoked. > > - You could declare methods for any type in any crate or module, without > having to create extraneous traits, which I feel is a wart in the current > language. Traits could then be used for abstraction only, which I feel is > their correct purpose. > > - Because methods would just be module-scope functions, they could be > referred to as values (e.g. as arguments to higher-order functions) without > a lambda shim. > > - I was confused at one point because `&self` looks a lot like a pattern > match, but is not one. That could go away. > > - The current difficulties with generic methods (`impl T { .. }` > in the current language) might, or might not, be reduced. (I don't know of > any similar issues with generic top-level functions, but they might > resurface if called as methods). > > - The significance of the argument named `self` could also potentially be > removed, instead allowing the first argument to be used as the > self-argument in a method call, no matter what it's called. This would > allow for pattern matching on the self-argument in the definition of the > method, which is currently not possible. > > > Hope this is helpful or interesting, > G?bor > > -- > Your ship was destroyed in a monadic eruption. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Sat Oct 19 07:08:50 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 19 Oct 2013 17:08:50 +0300 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: Interesting idea; in that case, one could string together any series of functions - basically, `.` would become the equivalent of `|>` (or whatever other name you want to call it). That is, instead of writing `baz(bar(foo(x), y), z)` one could write `foo(x).bar(y).baz(z)`. This would make it easier to write things in functional style, using the same syntax as the object style. It could be viewed as the natural complement for the `do` keyword, which adds a last block parameter to the end of the function. I'm less certain about giving up `impl Foo { ... }`, though - that is useful for logically grouping, documenting and accessing functions (as in `Foo::foo(...)`). But it seems we don't have to give it up, just make it optional? On Sat, Oct 19, 2013 at 3:47 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > I see no reason for the restriction of "self". Why not simply say that any > function can be called with "first_arg.func(...)" style ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Sat Oct 19 09:32:39 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 19 Oct 2013 18:32:39 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: (Steven Blenkinsop's message of "Fri, 18 Oct 2013 20:59:58 -0400") References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> <87vc0umg2n.fsf@mid.deneb.enyo.de> Message-ID: <87mwm59q6w.fsf@mid.deneb.enyo.de> * Steven Blenkinsop: > On Friday, 18 October 2013, Florian Weimer wrote: >> It's more common to simply return the object. >> > > Only in toy programs, or where there is no meaningful additional > context. Sure, but it's a shame that the call stack is discarded if there isn't meaningful context. >> Due to some obscure feature of Go's type system, error values have to >> be interfaces and cannot be struct types > Struct types can be put in interfaces and extracted using type assertions, > such as the error returned by os.Open. However the general case is to use > textual errors. The problem is that if err is of type "error", "err != nil" is true after the assignment of a pointer value to err. So the usual error checking idiom doesn't work if your function returns a pointer-to-struct (that implements the "error" interface) instead of a (relatively opaque) "error" interface value. Or put differently, if you put a typed null pointer into an interface value, the interface value keeps the type information and is therefore no longer equal to nil. >> , so I have not seen anyone >> trying to updating an existing error. Wrapping might happen, but >> there is no general chaining mechanism like there is in Java. k> > The default is fmt.Errorf for textual errors. That's not a chaining mechanism. From eric.sampson at gmail.com Sat Oct 19 09:42:15 2013 From: eric.sampson at gmail.com (Eric Sampson) Date: Sat, 19 Oct 2013 11:42:15 -0500 Subject: [rust-dev] mutable vs. functional APIs Message-ID: > Date: Fri, 18 Oct 2013 10:54:23 -0700 > From: Jeff Petkau > > > > On my code (disclaimer: only toy projects to learn Rust so far), I've been > pretty happy with a "mut_" prefix for mutable versions. > > newthing = oldthing.push(foo") > anything.mut_push(foo") > > x = bagofun.sort() > bagosadness.mut_sort() > > etc. > > Advantages: > - consistent meaning with the 'mut' keyword. > - works with pretty much any name. > - makes mutable versions just a bit uglier than immutable code. > > Disadvantages: > - If an API is inherently mutable, it gets pretty noisy. > - A bit ugly, probably turns off newcomers. > - If the compiler warns on ignoring return values, and mutating methods > return (), then a convention might be unnecessary. > > --Jeff > > What about establishing a convention that mutable methods start with an uppercase letter while non-mutating methods start with a lowercase letter? It would be lightweight in terms of character count/looks and at the same time give mutable methods a slight visual emphasis, which makes sense I think. I know this convention is already used by Traits, but when I looked through some code with the above proposal in mind it would be easy to distinguish between these two uses of the same convention due to the differing contexts they're used in. -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Sat Oct 19 10:11:20 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Sat, 19 Oct 2013 13:11:20 -0400 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <87mwm59q6w.fsf@mid.deneb.enyo.de> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> <87vc0umg2n.fsf@mid.deneb.enyo.de> <87mwm59q6w.fsf@mid.deneb.enyo.de> Message-ID: On Saturday, 19 October 2013, Florian Weimer wrote: > > The problem is that if err is of type "error", "err != nil" is true > after the assignment of a pointer value to err. So the usual error > checking idiom doesn't work if your function returns a > pointer-to-struct (that implements the "error" interface) instead of a > (relatively opaque) "error" interface value. Don't do that. Return an error, not a naked error implementation. If people want to inspect it rather than treat it as a string, they'll do a type assertion rather than just a nil check. Rust doesn't have type assertions, however I feel this could be handled satisfactorily by using concrete error types in Rust. Also, the whole nil vs nil thing is irrelevant to Rust. > Or put differently, if you put a typed null pointer into an interface > value, the interface value keeps the type information and is therefore > no longer equal to nil. Don't do that. Return either a nil error or a valid value of your error type. Seriously, the nil interface vs nil contents thing is only a tripping point for novices who don't understand what interfaces are, it's not something you run into once you've familiarized yourself with the language. This wouldn't be an issue in Rust, since people would really have to go out of their way to conflate an Err(None) with an Ok(v). That's not a chaining mechanism. > You're going to need to explain what you mean by this, then, and how it would apply to Rust. Note that if it's something very particular to how Go code is written, it's probably not constructive here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From platt.nicholas at gmail.com Sat Oct 19 06:11:20 2013 From: platt.nicholas at gmail.com (Nicholas Platt) Date: Sat, 19 Oct 2013 09:11:20 -0400 Subject: [rust-dev] #rust-osdev In-Reply-To: References: Message-ID: This is right up my alley for interest, but I'm not often on IRC. Will they be logged somewhere? On Fri, Oct 18, 2013 at 5:28 AM, L?o Testard wrote: > Hello, > > A new channel appeared on IRC today following a discussion about exo and > microkernels on #rust. > This chan is #rust-osdev and is about... guess what... OS development with > Rust. That's it. > > We will discuss how to use Rust for OS development : how to compile and > run Rust code without the > runtime, how to make it boot on the hardware, how to link it with C or > assembly, how to implement some > things with Rust, etc. etc. and many other fun things > > I created a wiki page ( > https://github.com/mozilla/rust/wiki/Operating-system-development) > that will reference resources, projects, etc. It's quite empty for now but > I hope it will be filled soon :) > > Leo > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Sat Oct 19 12:43:43 2013 From: igor at mir2.org (Igor Bukanov) Date: Sat, 19 Oct 2013 21:43:43 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: <87vc0umg2n.fsf@mid.deneb.enyo.de> References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> <87vc0umg2n.fsf@mid.deneb.enyo.de> Message-ID: This is how we implemented error handling in Java. We defined an abstract class ErrorSink like in: class ErrorSink { void addError(String s); boolean hasError(s); // few more methods to add extra attributes like line, file, column etc of errors } A default implementation of the class just throws in the addError method, but the requirement for addError callers is to assume that method would not throw and try to recover or return some sensible value. For example, a method like readFileAsString in case of IOException reported that and returned an empty string. A configuration parser that calls readFileAsString to read included files has a custom implementation of ErrorSink that does not throw but rather adds all errors on the list. At the end of parsing all those errors plus all syntax violations was converted into a new detailed report with proper line numbers etc and reported to the original sink. This has number of benefits. All unexpected errors like dns failure when reading URL are nicely formated showing the error origin. Various low-level helpers like a date parser do not need to worry about including proper context in the error message as that was responsibility of the caller. This allowed to reuse the same parser in GUI dialogs for a date input showing short and very informative tooltip when user typed invalid date. It was trivial to add warnings to the system extending the ErrorSink with an addWarning method and turn those warnings into hard errors at runtime during testing via simple throw. The callers would not need to check for errors at the every method call. The biggest drawback was the need to pass ErrorSink to a lot of methods or store that as a member of many classes. We experimented with using Java's thread locals instead, but that was rather inflexible and inefficient. I wonder why such error reporting is not used in other programs or languages. On 18 October 2013 23:20, Florian Weimer wrote: > * Igor Bukanov: > >> So the Go style is to call a function, check if the was an error, >> update the error object (or create a new wrapping the old one) with >> extra information relevant to the current call stack frame and >> propagate the updated error object to the caller. > > It's more common to simply return the object. > > Due to some obscure feature of Go's type system, error values have to > be interfaces and cannot be struct types, so I have not seen anyone > trying to updating an existing error. Wrapping might happen, but > there is no general chaining mechanism like there is in Java. From illissius at gmail.com Sat Oct 19 13:32:46 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sat, 19 Oct 2013 22:32:46 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 4:08 PM, Oren Ben-Kiki wrote: > > I'm less certain about giving up `impl Foo { ... }`, though - that is > useful for logically grouping, documenting and accessing functions (as in > `Foo::foo(...)`). But it seems we don't have to give it up, just make it > optional? > Interesting point. I think this argues in favor of removing anonymous `impl`s, even as sugar. I was focused on normal ("selfish") methods in my previous letter, rather than "static" ("selfless") ones. You could still achieve much the same effect, if you wanted to, by writing: struct Foo { .. } fn get_thing(self: &Foo) -> Bar { .. } // for `some_foo.get_thing()` syntax mod Foo { fn new() -> Foo { .. } // for `Foo::new()` syntax } Rust already allows this trickery: the type and module are imported together when you write `use some_mod::Foo`. Keeping this seems fine, and making it more explicit (relative to `impl`) seems like a good thing. What you lose is that in the case of a generic type, you would have to write the generic-bits for each function, which is the "more typing" disadvantage from earlier. I think losing the `impl` sugar is a small price to pay for the simplification of the language. Modules would be modules and types would be types. Append to the "advantages" list: - The complexity related to (possibly-generic) types in paths would go away On Sat, Oct 19, 2013 at 3:47 PM, Matthieu Monrocq < > matthieu.monrocq at gmail.com> wrote: > >> I see no reason for the restriction of "self". Why not simply say that >> any function can be called with "first_arg.func(...)" style ? >> > Yeah, as I mentioned in the last bullet of the previous letter, you could do this. I don't think it makes much difference either way and don't have a strong opinion. In favor of explicit `self` is that it's, well, explicit: "you can and should call this using method syntax". I can imagine there might be function signatures where using method syntax wouldn't make sense (though you might say, "then don't use it", and I would be inclined to agree). A non-method function (one without a `self` arg) also wouldn't cause ambiguity if it were in scope at the same time as you were calling another method with the same name. In favor of always allowing method syntax on the first argument is that you could destructure it in the definition, e.g. `fn area((x, y): (int, int)) -> int { x * y }`, and still call the function using method syntax. They're all pretty minor. -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sat Oct 19 13:52:23 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 19 Oct 2013 13:52:23 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> I think it's unfortunately too late to overhaul the language like this. This will require redesigns of all Rust code in existence. I do like unified function/method call syntax, but I think it can be done in a backwards compatible way. Patrick "G?bor Lehel" wrote: >On Sat, Oct 19, 2013 at 4:08 PM, Oren Ben-Kiki >wrote: > >> >> I'm less certain about giving up `impl Foo { ... }`, though - that is >> useful for logically grouping, documenting and accessing functions >(as in >> `Foo::foo(...)`). But it seems we don't have to give it up, just make >it >> optional? >> > >Interesting point. I think this argues in favor of removing anonymous >`impl`s, even as sugar. I was focused on normal ("selfish") methods in >my >previous letter, rather than "static" ("selfless") ones. You could >still >achieve much the same effect, if you wanted to, by writing: > > struct Foo { .. } > > fn get_thing(self: &Foo) -> Bar { .. } // for `some_foo.get_thing()` >syntax > > mod Foo { > fn new() -> Foo { .. } // for `Foo::new()` syntax > } > >Rust already allows this trickery: the type and module are imported >together when you write `use some_mod::Foo`. Keeping this seems fine, >and >making it more explicit (relative to `impl`) seems like a good thing. >What >you lose is that in the case of a generic type, you would have to write >the >generic-bits for each function, which is the "more typing" disadvantage >from earlier. I think losing the `impl` sugar is a small price to pay >for >the simplification of the language. Modules would be modules and types >would be types. Append to the "advantages" list: > >- The complexity related to (possibly-generic) types in paths would go >away > > >On Sat, Oct 19, 2013 at 3:47 PM, Matthieu Monrocq < >> matthieu.monrocq at gmail.com> wrote: >> >>> I see no reason for the restriction of "self". Why not simply say >that >>> any function can be called with "first_arg.func(...)" style ? >>> >> >Yeah, as I mentioned in the last bullet of the previous letter, you >could >do this. I don't think it makes much difference either way and don't >have a >strong opinion. > >In favor of explicit `self` is that it's, well, explicit: "you can and >should call this using method syntax". I can imagine there might be >function signatures where using method syntax wouldn't make sense >(though >you might say, "then don't use it", and I would be inclined to agree). >A >non-method function (one without a `self` arg) also wouldn't cause >ambiguity if it were in scope at the same time as you were calling >another >method with the same name. > >In favor of always allowing method syntax on the first argument is that >you >could destructure it in the definition, e.g. `fn area((x, y): (int, >int)) >-> int { x * y }`, and still call the function using method syntax. > >They're all pretty minor. > >-- >Your ship was destroyed in a monadic eruption. > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhm456 at gmail.com Sat Oct 19 14:33:10 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Sat, 19 Oct 2013 14:33:10 -0700 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Fri, Oct 18, 2013 at 11:02 PM, Daniel Micay wrote: > On Sat, Oct 19, 2013 at 12:45 AM, Jerry Morrison wrote: > >> >> On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay wrote: >> >>> On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: >>>> >>>> >>>> (1) Rust has great potential for *real-time programming* as well as >>>> secure programming. Perhaps this just needs a library call to fork >>>> "real-time threads" that never do garbage collection. ("Real-time" means >>>> predictably meeting time deadlines, e.g. in avionics, video capture, >>>> medical x-ray, and robotics. Speed is important but the crucial point is >>>> reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time >>>> optimizers are bad for predictability.) Maybe Rust already has this. What >>>> determines whether a thread-local managed heap uses reference counting? >>>> Ref-counting may be OK in a real-time thread if it doesn't deallocate a >>>> variable-length chain of nodes at an inconvenient time. >>>> >>> >>> Rust leaves memory allocation up to the user as much as C++. Most code >>> can simply use unboxed values and lightweight references, with occasional >>> usage of owned boxes (single-owner heap allocations, with lifetime tied to >>> scope). >>> >> >> Ideally, forking a real-time thread could ensure that (1) no GC pauses >> the thread just to find out there's no garbage to collect, and (2) >> something would catch the mistake if it ever calls code (directly or >> indirectly) that evolves to using GC memory. >> > > Rust doesn't currently have a way to forbid features only in some parts of > the code but not others. Avoiding garbage collection as a hard requirement > will likely mean using rust-core (or whatever it evolves to, maybe a > special profile of the standard library). > So with a suitable library, real-time threads can avoid garbage collection pauses. Can it enforce linking to this library for all the code it calls, or else arrange for the standard GC memory allocator to fail!() if it accidentally called? > If you need shared ownership, it's available via the `Rc`/`RcMut` >>> types. Every split of ownership is explicit via a `clone` call since moves >>> are the default. There will be a task-local garbage collector providing >>> garbage collected pointers, but it still needs to be implemented. >>> >> >> Sounds good, although I don't understand the details. Does the program >> pick between GC allocation and ref counting allocation via the choice of >> pointer sigils? Via the choice of library calls? >> > > Reference counting is implemented as a library type, so you would make a > reference counted allocation with `Rc::new(value)` and make an explicit > reference count with `box.clone()` (the implementation: > https://github.com/mozilla/rust/blob/master/src/libstd/rc.rs). > > There are managed pointers sigils for garbage collection (@, @mut) but I > think consensus is trending towards replacing the syntax with a type > similar to `Rc` allowing cycles and implicit copies. The compiler support > could be exposed via attributes hooks like the operator traits, rather than > syntax. > Nice. > >> The standard library implements N:M concurrency and exposes a blocking >> API for asynchronous I/O. I don't think it would be suitable for a >> real-time application, but you can avoid the standard library: >> https://github.com/thestinger/rust-core >> > > What's N:M concurrency? >> > > The concurrency model implemented in the standard library treats real > threads as schedulers, and maps cooperatively scheduled tasks onto them. If > the task doesn't make calls to functions with yields, it will monopolize a > scheduler thread. > > It's a very good model for I/O or for high throughput on many CPU-bound > batch jobs (https://www.threadingbuildingblocks.org/), but it's not going > to be suitable for real-time needs. > Thanks. That makes sense. -- Jerry @1fish2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Sat Oct 19 14:36:42 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat, 19 Oct 2013 14:36:42 -0700 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 2:33 PM, Jerry Morrison wrote: > > So with a suitable library, real-time threads can avoid garbage collection > pauses. Can it enforce linking to this library for all the code it calls, or > else arrange for the standard GC memory allocator to fail!() if it > accidentally called? There's no dynamic checking needed; you just need to include the #[deny(managed_heap_memory)] attribute in the crate file. (There's also a way to do the same thing with a command-line flag.) This will result in a compile-time failure if any code might use garbage collection (including code in external libraries that's called by your code). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From hatahet at gmail.com Sat Oct 19 14:36:23 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sat, 19 Oct 2013 14:36:23 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sat, Oct 19, 2013 at 1:52 PM, Patrick Walton wrote: > I think it's unfortunately too late to overhaul the language like this. > This will require redesigns of all Rust code in existence. > > I do like unified function/method call syntax, but I think it can be done > in a backwards compatible way. > > What do you have in mind at the moment? Implementing UFCS while still keeping the `impl` syntax around for structs? What about for primitive types, e.g. would `fn double(a: int) -> { 2*a }` be callable as `2.double()`, without breaking backward compatibility? Thanks -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhm456 at gmail.com Sat Oct 19 14:43:03 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Sat, 19 Oct 2013 14:43:03 -0700 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 2:36 PM, Tim Chevalier wrote: > On Sat, Oct 19, 2013 at 2:33 PM, Jerry Morrison wrote: > > > > So with a suitable library, real-time threads can avoid garbage > collection > > pauses. Can it enforce linking to this library for all the code it > calls, or > > else arrange for the standard GC memory allocator to fail!() if it > > accidentally called? > > There's no dynamic checking needed; you just need to include the > #[deny(managed_heap_memory)] attribute in the crate file. (There's > also a way to do the same thing with a command-line flag.) This will > result in a compile-time failure if any code might use garbage > collection (including code in external libraries that's called by your > code). > > Cheers, > Tim > Fantastic. Thanks, Tim! For a program with some real-time threads plus other code like UI, I assume the other code can be in a crate that allows managed_heap_memory. -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sat Oct 19 14:46:07 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 19 Oct 2013 14:46:07 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: <6bbf4077-88db-4a89-a955-cf700f93d628@email.android.com> I was thinking not. The dot operator should still have special name lookup rules: it searches through associated impls and all traits in scope. It cannot call anything that is not attached to an impl. This does make functions and methods somewhat less unified, but it makes methods feel more like OO methods from a scoping POV. I feel the draws of methods are not only that they switch the order of the receiver and action but also that they allow functions associated with a type to be called without explicitly importing their names. Patrick Ziad Hatahet wrote: >On Sat, Oct 19, 2013 at 1:52 PM, Patrick Walton >wrote: > >> I think it's unfortunately too late to overhaul the language like >this. >> This will require redesigns of all Rust code in existence. >> >> I do like unified function/method call syntax, but I think it can be >done >> in a backwards compatible way. >> >> >What do you have in mind at the moment? Implementing UFCS while still >keeping the `impl` syntax around for structs? What about for primitive >types, e.g. would `fn double(a: int) -> { 2*a }` be callable as >`2.double()`, without breaking backward compatibility? > >Thanks > > >-- >Ziad -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Oct 19 14:53:55 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 19 Oct 2013 17:53:55 -0400 Subject: [rust-dev] real-time programming? usability? In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 5:43 PM, Jerry Morrison wrote: > > On Sat, Oct 19, 2013 at 2:36 PM, Tim Chevalier wrote: > >> On Sat, Oct 19, 2013 at 2:33 PM, Jerry Morrison wrote: >> > >> > So with a suitable library, real-time threads can avoid garbage >> collection >> > pauses. Can it enforce linking to this library for all the code it >> calls, or >> > else arrange for the standard GC memory allocator to fail!() if it >> > accidentally called? >> >> There's no dynamic checking needed; you just need to include the >> #[deny(managed_heap_memory)] attribute in the crate file. (There's >> also a way to do the same thing with a command-line flag.) This will >> result in a compile-time failure if any code might use garbage >> collection (including code in external libraries that's called by your >> code). >> >> Cheers, >> Tim >> > > Fantastic. Thanks, Tim! > > For a program with some real-time threads plus other code like UI, I > assume the other code can be in a crate that allows managed_heap_memory. > > -- > Jerry > The `managed_heap_memory` lint will prevent using any types containing managed pointers, but won't strictly prevent calling code using garbage collection. In a `#[no_std]` codebase, the compiler will prevent using managed pointers unless the hooks for them are defined. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Sat Oct 19 15:10:43 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Sat, 19 Oct 2013 18:10:43 -0400 Subject: [rust-dev] Strange behavior about Writer trait In-Reply-To: References: Message-ID: Consider this program: """ trait AdderIncr { fn add(&self, x: Self) -> Self; fn incr(&mut self); } impl AdderIncr for int { fn add(&self, x: int) -> int { *self + x } fn incr(&mut self) { *self += 1; } } fn incrAdd(x: &mut AdderIncr, y: &mut AdderIncr) { x.incr(); x.add(y); } fn main() {} """ It fails to compile: """ Documents/test.rs:13:1: 13:10 error: cannot call a method whose type contains a self-type through an object Documents/test.rs:13 x.add(y); ^~~~~~~~~ """ The Self type is meaningless in object methods, since I have no way to ensure that y has the same underlying type as x. Thus, only a subset of the methods of a trait are available on the corresponding object, which means that objects can't automatically implement their corresponding trait. That means any impls that implement a trait for all types that implement AdderIncr, for example, won't implement that trait for &AdderIncr, since &AdderIncr doesn't implement AdderIncr. On Sat, Oct 19, 2013 at 2:47 AM, Oren Ben-Kiki wrote: > Hmmm.... That sounds strange. Shouldn't `obj: &T` allow me to invoke > `obj.method_of_T()`? > > For example, how did I manage to invoke the `data.print(...)` method via > the borrowed `data: &PrintWithSpice` pointer? Automatic dereference? And if > so, why didn't it work for `Writer` as well? > > On Sat, Oct 19, 2013 at 9:29 AM, Steven Fackler wrote: > >> If T is a trait, its trait objects ~T, @T and &T do not implement T. >> There is an implementation of Writer for @Writer, but not for ~Writer or >> &Writer which is why you're seeing that error. >> >> Steven Fackler >> >> >> On Fri, Oct 18, 2013 at 11:27 PM, Oren Ben-Kiki wrote: >> >>> Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, >>> but I can't cast any @Writer (such as `io::stdout()`) to it. I guess I >>> should just use `@Writer` everywhere for now :-( >>> >>> This raises the question of how come the compiler is smart enough to >>> figure out a `@Writer` has the trait `WriterUtil`, but isn't smart enough >>> to figure out a `&Writer` has the trait... >>> >>> >>> On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote: >>> >>>> I run into the following problem (the code below is a toy example). >>>> >>>> ``` >>>> use std::io::Writer; // Makes no difference if added/removed. >>>> >>>> trait PrintWithSpice { >>>> fn print(&self, writer: &Writer, spice: bool); >>>> } >>>> >>>> struct Bar { >>>> bar: ~PrintWithSpice, >>>> } >>>> >>>> impl Bar { >>>> pub fn print(&self, writer: &Writer) { >>>> self.bar.print(writer, false); >>>> Bar::print_via_borrowed(writer, &self.bar); >>>> } >>>> >>>> fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) { >>>> // Invoking the `print` function via the borrowed pointer to >>>> the `PrintWithSpice` trait: >>>> // Works fine, as expected.. >>>> data.print(writer, true); >>>> } >>>> } >>>> >>>> struct Foo { >>>> foo: bool >>>> } >>>> >>>> impl PrintWithSpice for Foo { >>>> fn print(&self, writer: &Writer, spice: bool) { >>>> // Invoking the `write_str` function via the borrowed pointer >>>> to the `Writer` trait: >>>> // error: failed to find an implementation of trait >>>> std::io::Writer for &std::io::Writer >>>> // What is going on? >>>> writer.write_str(format!("foo: {:b} spice: {:b}", self.foo, >>>> spice)); >>>> } >>>> } >>>> ``` >>>> >>>> I didn't understand what the compiler is complaining about. "failed to >>>> find an implementation of Foo for &Foo"? A Foo is a Foo, no? >>>> Calling a function via a borrowed pointer to a trait should just work (it >>>> does a few lines above). >>>> >>>> After digging I discovered what the compiler really meant (I think). >>>> The `write_str` method is defined for `WriterUtils` rather than for >>>> `Writer`. So, if I replace `Writer` by `WriterUtil` in the above code, it >>>> compiles fine. >>>> >>>> So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am >>>> using that instead of `Writer` all over my code. I can see doing that as a >>>> workaround, but it doesn't smell right to me. >>>> >>>> So: >>>> >>>> * Why is the compiler complaining about not finding an implementation >>>> for `Writer` when the method I invoke is from `WriterUtil`? >>>> >>>> * Since there is an `impl for WriterUtil`, shouldn't the >>>> compiler be "sufficiently smart" to deduce that the code is valid in the >>>> 1st place? >>>> >>>> * Until the compiler is "sufficiently smart" (or, if there is a good >>>> reason why it would never be), shouldn't we rename `Writer` to >>>> `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so >>>> `&Writer` would become more usable? >>>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qwertie256 at gmail.com Sat Oct 19 16:35:39 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Sat, 19 Oct 2013 17:35:39 -0600 Subject: [rust-dev] Unified function/method call syntax and further simplification Message-ID: > > > This is meant as a followup to an earlier thread[1] on the subject and > the > > related ticket[2]. > > > > [1]: http://thread.gmane.org/gmane.comp.lang.rust.devel/2622/ > > [2]: https://github.com/mozilla/rust/issues/6974 > > > > The idea in those earlier discussions is that methods could also be > called > > using function syntax, supplying `self` as the first argument, so instead > > of `self_arg.method(arg)`, you could write `method(self_arg, arg)`. I'm > > wondering if this could be taken a couple steps further to simplify the > > whole story regarding functions, methods, traits, and impls. The idea is > > that the distiction between functions and methods would be erased almost > > completely, and methods (now being just functions) would be imported > > explicitly. > > > > It would involve the following pieces: > > > > - If the first argument of a top-level `fn` is named `self`, it can be > > called using method syntax. So if you have `fn foo(self: &MyType, n: int) > > { .. }` at the top level, you can write `object_of_my_type.foo(123)`. You > > can also still call it using function syntax: `foo(object_of_my_type, > 123)`. > > > > I see no reason for the restriction of "self". Why not simply say that any > function can be called with "first_arg.func(...)" style ? > D has that rule (which they call UFCS), and I find it confusing sometimes. When a function is declared with function syntax and it makes sense or "feels right" that it "should" be a function, my mind is not expecting to see method syntax and I may have trouble figuring out later what an apparent method call refers to, even if I've seen the function declaration. Mind you it is worse in D than Rust, because in D, function declarations can be hidden inside what they call "eponymous templates", which has stumped me in the past. In any case, wouldn't it help narrow down searches if you could search for "fn foo(self" instead of only "fn foo"? (again though, Rust is not as bad for searching as the C-family languages that have no "fn" keyword.) In C# it's nice that I can find all the so-called extension methods by searching for "(this ". -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Sat Oct 19 16:51:42 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sat, 19 Oct 2013 16:51:42 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: On Sat, Oct 19, 2013 at 4:35 PM, David Piepgrass wrote: > In C# it's nice that I can find all the so-called extension methods by >> searching for "(this ". >> >> Aren't `impl`s in Rust somewhat similar to extension methods in C#? For instance: trait Doubler { fn double(&self) -> Self; } impl Doubler for int { fn double(&self) -> int { *self * 2 } } Then you can call 5.double(). -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Oct 19 19:26:47 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 19 Oct 2013 22:26:47 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Welcome to another issue of *This Week in Rust*, a weekly summary of Rust's progress and happenings in the community. # What's cooking in master? 48 PRs were merged this week. ## Breaking changes - Slices are now represented as [number of elements, not number of bytes](https://github.com/mozilla/rust/pull/9885). - `fmt!` has been [completely removed](https://github.com/mozilla/rust/pull/9919). - Some fields in `std::comm` [have been made private](https://github.com/mozilla/rust/pull/9935). - `std::sys::refcount` [has been moved](https://github.com/mozilla/rust/pull/9922) to `std::managed::refcount`. - [A bunch of functions](https://github.com/mozilla/rust/pull/9896/files#diff-69196c6d2488bf8d5b3471084e854407L22) have moved from `std::sys` to `std::mem`. - `once fn` is [now a feature gate](https://github.com/mozilla/rust/pull/9863) rather than a `-Z` flag. - `Path` has been [completely rewritten](https://github.com/mozilla/rust/pull/9655). - `extra::flatpipes` [has been removed](https://github.com/mozilla/rust/pull/9886). ## Other changes - `jemalloc` has been [removed from the runtime](https://github.com/mozilla/rust/pull/9933). The [associated issue](https://github.com/mozilla/rust/issues/9925) is quite scary. - `rustdoc` [struct field visibility](https://github.com/mozilla/rust/pull/9946) is now corrected (it stripped fields where it should not have). - `rustdoc` also [uses the actual privacy rules](https://github.com/mozilla/rust/pull/9941) to strip methods. - `format!` now gives [much better](https://github.com/mozilla/rust/pull/9932) error messages for invalid format strings. - The `fmt::Default` trait, used for default formatting with `format!`, is [now documented](https://github.com/mozilla/rust/pull/9938). - `include_bin!` has been optimized, and the `k-nucleotides` benchmark now compiles [187x faster](https://github.com/mozilla/rust/pull/9851). - Vectors now have [`starts_with` and `ends_with` methods](https://github.com/mozilla/rust/pull/9907), which take slices. - An `abort` intrinsic [has been added](https://github.com/mozilla/rust/pull/9860). - Vectors now have a [`get_opt` method](https://github.com/mozilla/rust/pull/9608). ## New contributors A new section for new contributors! The new contributors this week are (as reported by git): - Chris Sainty - Eduard Burtescu - Erik Lyon - Harry Marr - S?bastien Chauvel - Vijay Korapaty - Ziad Hatahet - chitra # Weekly Meeting The [weekly meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-10-15) discussed removing rusti, changing the attribute syntax, destructors in statics, and more multi-crate packages with rustpkg. # Announcements etc - Rust (and Servo) are participating in the [GNOME Outreach Program for Women](https://groups.google.com/forum/#!topic/mozilla.dev.servo/7kX_E0FlfkA). A bunch of people have already come into IRC about it. - [is getting full Rust support](https://github.com/kytrinyx/exercism.io/pull/866). This is a very cool resource, and could help a lot getting newcomers acclimated. - [Unified Function/method Call Syntax and further simplification](https://mail.mozilla.org/pipermail/rust-dev/2013-October/006034.html). - [Safe Memory Management in Cyclone](http://www.reddit.com/r/rust/comments/1osbq2/safe_manual_memory_management_in_cyclone_research/). - [Audio](http://opensourcebridge.org/sessions/970) from Tim's talk in June is finally available! - An [OSdev](https://github.com/mozilla/rust/wiki/Operating-system-development) community has sprung up! The channel is `#rust-osdev`. - [Should I/O use conditions?](http://www.reddit.com/r/rust/comments/1omw47/should_io_use_conditions/). - [Pointers in Rust: A Guide](http://www.reddit.com/r/rust/comments/1opo36/pointers_in_rust_a_guide/). - I am on a [Rust hiatus](http://cmr.github.io/blog/2013/10/14/rust-hiatus/), for the time being. TWiR will still be happening, as you are reading it right now. - [rust-core](https://github.com/thestinger/rust-core) - A stub standard library. From steven099 at gmail.com Sat Oct 19 20:26:35 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Sat, 19 Oct 2013 23:26:35 -0400 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: Message-ID: On Saturday, October 19, 2013, Ziad Hatahet wrote: > On Sat, Oct 19, 2013 at 4:35 PM, David Piepgrass > > wrote: > >> In C# it's nice that I can find all the so-called extension methods by >>> searching for "(this ". >>> >>> > > Aren't `impl`s in Rust somewhat similar to extension methods in C#? > Loosely, if you ignore that each impl overloads an abstract interface (trait) over the Self type, and that you can constrain a type parameter based on whether there's an overload of a certain abstract interface for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Sun Oct 20 00:26:41 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sun, 20 Oct 2013 10:26:41 +0300 Subject: [rust-dev] Strange behavior about Writer trait In-Reply-To: References: Message-ID: I'm not sure I follow. Assuming that the trait `T` has no method that uses `Self`, then any `impl` requiring `T` should happily accept an `&T` / `@T`. Why penalize non-self-referential traits (like `Writer`), just because some traits (like `AdderIncr`) are self-referential? On Sun, Oct 20, 2013 at 1:10 AM, Steven Blenkinsop wrote: > Consider this program: > > """ > trait AdderIncr { > fn add(&self, x: Self) -> Self; > fn incr(&mut self); > } > > impl AdderIncr for int { > fn add(&self, x: int) -> int { *self + x } > fn incr(&mut self) { *self += 1; } > } > > fn incrAdd(x: &mut AdderIncr, y: &mut AdderIncr) { > x.incr(); > x.add(y); > } > > fn main() {} > """ > > It fails to compile: > > """ > Documents/test.rs:13:1: 13:10 error: cannot call a method whose type > contains a self-type through an object > Documents/test.rs:13 x.add(y); > ^~~~~~~~~ > """ > > The Self type is meaningless in object methods, since I have no way to > ensure that y has the same underlying type as x. Thus, only a subset of the > methods of a trait are available on the corresponding object, which means > that objects can't automatically implement their corresponding trait. > > That means any impls that implement a trait for all types that implement > AdderIncr, for example, won't implement that trait for &AdderIncr, since > &AdderIncr doesn't implement AdderIncr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 05:28:41 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 14:28:41 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton wrote: > I think it's unfortunately too late to overhaul the language like this. > This will require redesigns of all Rust code in existence. > > I do like unified function/method call syntax, but I think it can be done > in a backwards compatible way. > This is up to you and the rest of the Rust team, of course. But in my very humble opinion, it feels shortsighted to impose backwards compatibility constraints at this point. All Rust code in existence is still (hopefully!) a negligibly small fraction of the code that is yet to be written. I know there's a desire to get 1.0 out the door as soon as possible, and I understand it (I want to be using Rust instead of C++, too!), but if Rust is still in use years or decades from now, decisions made now about the design of the language will echo far louder than whether it was released a few months earlier or later. I think it would be unfortunate to start suffering a C++-like fate sooner than absolutely necessary. That was a general argument, and it only matters if something is considered a good idea on the merits. In this case, it seems we disagree about that: On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton wrote: > I was thinking not. The dot operator should still have special name lookup > rules: it searches through associated impls and all traits in scope. It > cannot call anything that is not attached to an impl. > > This does make functions and methods somewhat less unified, but it makes > methods feel more like OO methods from a scoping POV. I feel the draws of > methods are not only that they switch the order of the receiver and action > but also that they allow functions associated with a type to be called > without explicitly importing their names. > Aha. That's exactly the thing I don't like, and thought would be beneficial to change. It's different from everything else for no great reason (is being like OO a great reason?), and carries baggage with warts and thorny issues in it. (Needing special language constructs to write methods; normal `fn`s feel like second-class citizens; can't selectively or rename-import methods; can't write method-syntax functions in a different crate without introducing spurious abstraction boundaries; the whole `impl T { fn(&self) }` versus `impl &T { fn(self) }` ugliness; traits and generic types in paths raise awkward questions; ...) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 20 07:56:37 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 07:56:37 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: It's different from everything else because it's a non-overlapping feature :) But yes, I think being like OO is reason enough to do it. If we didn't have that, then you'd have to import every method you call. I think that that would turn off far too many programmers coming from mainstream languages. Almost every mainstream language I can think of that has methods at all does name lookup this way. (The main exception in the OO world would be pure multimethod-based systems, but they aren't mainstream and I personally question whether they can be in part because of this very issue.) Rust was designed to be a multiparadigm language, supporting both functional and OO style, and this feature is an extremely common part of object-oriented programming. If it helps, this feature is not without precedent. The "search through associated methods" behavior is the same as Go and similar to Objective-C, with its @interface/@implementation divide. The "search through traits in scope" behavior is similar to Scala and C# extension methods. I don't see the things you mention as warts. They're just consequences of, well, having methods in the OO sense. Nearly all of these "warts" show up in other object-oriented languages too. Maybe they're warts of object-oriented programming in general and illustrate that OO is a bad idea, but as I mentioned before Rust is designed to support OO. I shouldn't have been so absolute about not changing stuff--we can and will change things--but I don't see having to import every method as a positive change. We discussed it years ago and concluded that it was a non-starter due to the burden it would impose on everyone. Patrick "G?bor Lehel" wrote: >On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton >wrote: > >> I think it's unfortunately too late to overhaul the language like >this. >> This will require redesigns of all Rust code in existence. >> >> I do like unified function/method call syntax, but I think it can be >done >> in a backwards compatible way. >> > >This is up to you and the rest of the Rust team, of course. But in my >very >humble opinion, it feels shortsighted to impose backwards compatibility >constraints at this point. All Rust code in existence is still >(hopefully!) >a negligibly small fraction of the code that is yet to be written. I >know >there's a desire to get 1.0 out the door as soon as possible, and I >understand it (I want to be using Rust instead of C++, too!), but if >Rust >is still in use years or decades from now, decisions made now about the >design of the language will echo far louder than whether it was >released a >few months earlier or later. I think it would be unfortunate to start >suffering a C++-like fate sooner than absolutely necessary. > >That was a general argument, and it only matters if something is >considered >a good idea on the merits. In this case, it seems we disagree about >that: > >On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton >wrote: > >> I was thinking not. The dot operator should still have special name >lookup >> rules: it searches through associated impls and all traits in scope. >It >> cannot call anything that is not attached to an impl. >> >> This does make functions and methods somewhat less unified, but it >makes >> methods feel more like OO methods from a scoping POV. I feel the >draws of >> methods are not only that they switch the order of the receiver and >action >> but also that they allow functions associated with a type to be >called >> without explicitly importing their names. >> > >Aha. That's exactly the thing I don't like, and thought would be >beneficial >to change. It's different from everything else for no great reason (is >being like OO a great reason?), and carries baggage with warts and >thorny >issues in it. (Needing special language constructs to write methods; >normal >`fn`s feel like second-class citizens; can't selectively or >rename-import >methods; can't write method-syntax functions in a different crate >without >introducing spurious abstraction boundaries; the whole `impl T { >fn(&self) >}` versus `impl &T { fn(self) }` ugliness; traits and generic types in >paths raise awkward questions; ...) > >-- >Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Sun Oct 20 08:11:59 2013 From: marijnh at gmail.com (Marijn Haverbeke) Date: Sun, 20 Oct 2013 17:11:59 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: I want to add that we did initially have a scheme where you have to import every impl you used (not every method), and that this was abandoned because it was burdensome and, in typical situations, completely redundant. Another problem with this proposal seems that it does away with the possibility of explicitly grouping a bunch of methods that make up the implementation of an interface. Implementing interfaces go-style, by just happening to have implemented all the methods that make up the interface, seems inappropriate for a language where interfaces aren't structural. So I very much agree with Patrick. Some aspects of this proposal are attractive, but it breaks some essential properties of the way methods currently work (and probably can't be adjusted to work around that without losing most of it attraction). Best, Marijn From oren at ben-kiki.org Sun Oct 20 08:52:35 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sun, 20 Oct 2013 18:52:35 +0300 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: Coming from a functional programming perspective, it would still be very nice indeed to easily pipeline a series of functions (not methods). The current method of requiring defining a new trait (with possibly just one impl!) just to be able to use the `.` syntax means discouraging functional style in favor of OO style. If it is "impossible" to allow for `foo.bar(baz)` to be the same as `bar(foo, baz)`, without giving up on the OO-like behavior (is it, really?), is there any chance of introducing a whole new operator (such as `|>`) to do the trick (as in `foo |> bar(baz)`)? See for example Elixir, which provides both a magic `.` OO-ish "method dispatch" and also a function-ish pipelining `|>` operator. On Sun, Oct 20, 2013 at 6:11 PM, Marijn Haverbeke wrote: > I want to add that we did initially have a scheme where you have to > import every impl you used (not every method), and that this was > abandoned because it was burdensome and, in typical situations, > completely redundant. > > Another problem with this proposal seems that it does away with the > possibility of explicitly grouping a bunch of methods that make up the > implementation of an interface. Implementing interfaces go-style, by > just happening to have implemented all the methods that make up the > interface, seems inappropriate for a language where interfaces aren't > structural. > > So I very much agree with Patrick. Some aspects of this proposal are > attractive, but it breaks some essential properties of the way methods > currently work (and probably can't be adjusted to work around that > without losing most of it attraction). > > Best, > Marijn > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 10:22:24 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 19:22:24 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 4:56 PM, Patrick Walton wrote: > I don't see the things you mention as warts. They're just consequences of, > well, having methods in the OO sense. Nearly all of these "warts" show up > in other object-oriented languages too. Maybe they're warts of > object-oriented programming in general and illustrate that OO is a bad > idea, but as I mentioned before Rust is designed to support OO. > OO for me was always more tied in with virtual methods than with how methods are scoped. But either way - I think this is basically my view. :) The only part of it I like is dot syntax. -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Sun Oct 20 10:29:14 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 20 Oct 2013 19:29:14 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: It seems to me that maybe there are several concepts/changes that are discussed at once, and it would be possible to nitpick. Personally, when I think of unifying calls, I only think of having "foo.bar(baz)" being strictly equivalent to "bar(foo, baz)"; nothing more than a syntax trick in a way. And thus: + I do not see any reason not to keep a special "associated method" look-up, though instead it would be tied to the first parameter of the function rather than limited to method-like calls + I do not see any reason not to keep automatically exporting/importing all methods whose first parameter is that of an exported/imported type or trait + I do not see any reason to move from explicit trait implementation to structural and automatic trait implementation (and I would consider it harmful) Thus I am wondering: - if I am missing something fundamental in the proposal by Gabor Lehel (I am not completely accustomed with the Rust terminology/idioms) - if such a simple "syntax sugar" could make its way into the language -- Matthieu On Sun, Oct 20, 2013 at 7:22 PM, G?bor Lehel wrote: > On Sun, Oct 20, 2013 at 4:56 PM, Patrick Walton wrote: > >> I don't see the things you mention as warts. They're just consequences >> of, well, having methods in the OO sense. Nearly all of these "warts" show >> up in other object-oriented languages too. Maybe they're warts of >> object-oriented programming in general and illustrate that OO is a bad >> idea, but as I mentioned before Rust is designed to support OO. >> > > OO for me was always more tied in with virtual methods than with how > methods are scoped. But either way - I think this is basically my view. :) > The only part of it I like is dot syntax. > > -- > Your ship was destroyed in a monadic eruption. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 10:31:05 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 19:31:05 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke wrote: > Another problem with this proposal seems that it does away with the > possibility of explicitly grouping a bunch of methods that make up the > implementation of an interface. Implementing interfaces go-style, by > just happening to have implemented all the methods that make up the > interface, seems inappropriate for a language where interfaces aren't > structural. > No, I completely agree with you here. Traits are awesome and if anyone wants to remove them, I will fight them with forks. The only difference in my proposal is how their methods would be scoped: they would be under the enclosing module, rather than the trait itself being a kind of module. Basically the Haskell model. (Except Haskell's module system is weaker than Rust's.) So I very much agree with Patrick. Some aspects of this proposal are > attractive, but it breaks some essential properties of the way methods > currently work (and probably can't be adjusted to work around that > without losing most of it attraction). > The main cost would be having to import methods explicitly (or using a glob), as Patrick notes. -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 10:55:46 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 19:55:46 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 7:31 PM, G?bor Lehel wrote: > So I very much agree with Patrick. Some aspects of this proposal are >> attractive, but it breaks some essential properties of the way methods >> currently work (and probably can't be adjusted to work around that >> without losing most of it attraction). >> > > The main cost would be having to import methods explicitly (or using a > glob), as Patrick notes. > Now I'm wondering, though: going with my proposal, if the module structure were just a little bit more fine-grained, I think you could achieve basically the same effect as the current system, if you wanted to. If the convention were to use a module to enclose a type together with its methods (which is already the case in many places), and you did a glob import of that module, you would get what you have now: the type and its methods would all come into scope. Except you could still import selectively, if you wanted to, or do things any other way, if you wanted to, and all of the "warts" I mentioned would still disappear. In a different crate, you could similarly create a module of "extension methods", which could be imported together or selectively, if you wanted to. I don't want to push this too hard if it's past the point of being productive, but I'm now even more convinced that this would be a beneficial change. Types should be types, grouping and scoping should be done with modules (Rust's modules are very capable), and traits should be used for type-based abstraction. I think it would work great. -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 20 10:59:34 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 10:59:34 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: <81d82982-6443-448c-b951-feba47cb2378@email.android.com> Isn't #1 basically what argument-dependent lookup (Koenig lookup) is trying to do in C++? I'm very nervous of going down that road. Patrick Matthieu Monrocq wrote: >It seems to me that maybe there are several concepts/changes that are >discussed at once, and it would be possible to nitpick. > >Personally, when I think of unifying calls, I only think of having >"foo.bar(baz)" being strictly equivalent to "bar(foo, baz)"; nothing >more >than a syntax trick in a way. And thus: > >+ I do not see any reason not to keep a special "associated method" >look-up, though instead it would be tied to the first parameter of the >function rather than limited to method-like calls > >+ I do not see any reason not to keep automatically exporting/importing >all >methods whose first parameter is that of an exported/imported type or >trait > >+ I do not see any reason to move from explicit trait implementation to >structural and automatic trait implementation (and I would consider it >harmful) > > >Thus I am wondering: > >- if I am missing something fundamental in the proposal by Gabor Lehel >(I >am not completely accustomed with the Rust terminology/idioms) > >- if such a simple "syntax sugar" could make its way into the language > >-- Matthieu > > > >On Sun, Oct 20, 2013 at 7:22 PM, G?bor Lehel >wrote: > >> On Sun, Oct 20, 2013 at 4:56 PM, Patrick Walton >wrote: >> >>> I don't see the things you mention as warts. They're just >consequences >>> of, well, having methods in the OO sense. Nearly all of these >"warts" show >>> up in other object-oriented languages too. Maybe they're warts of >>> object-oriented programming in general and illustrate that OO is a >bad >>> idea, but as I mentioned before Rust is designed to support OO. >>> >> >> OO for me was always more tied in with virtual methods than with how >> methods are scoped. But either way - I think this is basically my >view. :) >> The only part of it I like is dot syntax. >> >> -- >> Your ship was destroyed in a monadic eruption. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 20 11:01:16 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 11:01:16 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: What would happen if two types defined a method called, say, "foo", and the importing module glob imported them both? Patrick "G?bor Lehel" wrote: >On Sun, Oct 20, 2013 at 7:31 PM, G?bor Lehel >wrote: > >> So I very much agree with Patrick. Some aspects of this proposal are >>> attractive, but it breaks some essential properties of the way >methods >>> currently work (and probably can't be adjusted to work around that >>> without losing most of it attraction). >>> >> >> The main cost would be having to import methods explicitly (or using >a >> glob), as Patrick notes. >> > >Now I'm wondering, though: going with my proposal, if the module >structure >were just a little bit more fine-grained, I think you could achieve >basically the same effect as the current system, if you wanted to. If >the >convention were to use a module to enclose a type together with its >methods >(which is already the case in many places), and you did a glob import >of >that module, you would get what you have now: the type and its methods >would all come into scope. Except you could still import selectively, >if >you wanted to, or do things any other way, if you wanted to, and all of >the >"warts" I mentioned would still disappear. In a different crate, you >could >similarly create a module of "extension methods", which could be >imported >together or selectively, if you wanted to. > >I don't want to push this too hard if it's past the point of being >productive, but I'm now even more convinced that this would be a >beneficial >change. Types should be types, grouping and scoping should be done with >modules (Rust's modules are very capable), and traits should be used >for >type-based abstraction. I think it would work great. > >-- >Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 11:11:01 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 20:11:01 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 8:01 PM, Patrick Walton wrote: > What would happen if two types defined a method called, say, "foo", and > the importing module glob imported them both? > Here's the part where I have to say that I'm not intimately familiar with how Rust's existing method lookup works. But I don't see why it would necessarily have to work any differently from the way it does now. If you use dot syntax, it would try to do type-based name resolution (i.e. use the method in scope whose self-type matches), autoborrowing, autoreferencing, and whatever else it currently does to try to get an unambiguous match. If that fails, *then* you would have the option of tweaking your imports, `use`ing the method under a different name, or switching to function syntax and adding an explicit module qualifier (along with explicit borrowing and whatever). -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 20 11:16:28 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 11:16:28 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: But then it seems strange to require that the methods be imported at all, if you're going to do single-dispatch type-based resolution on them anyway. What we could do, perhaps, is add a third source of methods that the dot operator searches: functions in scope. This would allow methods to be attached anywhere to pre-existing types in an ad-hoc basis. I'm a bit nervous about complicating our already-complicated method lookup further, but maybe it makes sense to reduce the number of FooMethods traits people have to write, as well as to accommodate function chaining patterns. Patrick "G?bor Lehel" wrote: >On Sun, Oct 20, 2013 at 8:01 PM, Patrick Walton >wrote: > >> What would happen if two types defined a method called, say, "foo", >and >> the importing module glob imported them both? >> > >Here's the part where I have to say that I'm not intimately familiar >with >how Rust's existing method lookup works. But I don't see why it would >necessarily have to work any differently from the way it does now. If >you >use dot syntax, it would try to do type-based name resolution (i.e. use >the >method in scope whose self-type matches), autoborrowing, >autoreferencing, >and whatever else it currently does to try to get an unambiguous match. >If >that fails, *then* you would have the option of tweaking your imports, >`use`ing the method under a different name, or switching to function >syntax >and adding an explicit module qualifier (along with explicit borrowing >and >whatever). > >-- >Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 11:20:32 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 20:20:32 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 7:31 PM, G?bor Lehel wrote: > On Sun, Oct 20, 2013 at 5:11 PM, Marijn Haverbeke wrote: > >> Another problem with this proposal seems that it does away with the >> possibility of explicitly grouping a bunch of methods that make up the >> implementation of an interface. Implementing interfaces go-style, by >> just happening to have implemented all the methods that make up the >> interface, seems inappropriate for a language where interfaces aren't >> structural. >> > > No, I completely agree with you here. Traits are awesome and if anyone > wants to remove them, I will fight them with forks. The only difference in > my proposal is how their methods would be scoped: they would be under the > enclosing module, rather than the trait itself being a kind of module. > Basically the Haskell model. (Except Haskell's module system is weaker than > Rust's.) > Sorry, I think I might have misread the question, which I now believe was not about traits, but about impls. Basically, only anonymous `impl`s would go away. Trait impls would stay. But trait impls wouldn't have an effect on scoping. (Trait methods would be scoped under the module enclosing the trait, `impl`s would only affect for which types there exists an implementation for them. You can' t currently choose whether or not to export or import a trait impl, and you would continue to not be able to do that.) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 11:36:10 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 20 Oct 2013 20:36:10 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton wrote: > But then it seems strange to require that the methods be imported at all, > if you're going to do single-dispatch type-based resolution on them anyway. > Well, it would do type-based resolution based on the methods which you import :). You would still be the one doing the importing, instead of it happening by magic. You could also /not/ import one or more of them, if you wanted to, which you can currently only do on a per-trait granularity. And the rest of the design would still be much cleaner. (Again, leaving to modules what can be done with modules.) But FWIW, I think this is mostly orthogonal. If you use dot syntax, method lookup happens [somehow]. If it fails, you can do the other things. Maybe method lookup happens with type-based resolution, as it does now. Or maybe it requires that the name itself be unambiguous (which is simpler and dumber), as with functions. That's not really the part I care about. The part I care about is the separation of concerns. > What we could do, perhaps, is add a third source of methods that the dot > operator searches: functions in scope. This would allow methods to be > attached anywhere to pre-existing types in an ad-hoc basis. I'm a bit > nervous about complicating our already-complicated method lookup further, > but maybe it makes sense to reduce the number of FooMethods traits people > have to write, as well as to accommodate function chaining patterns. > I still can't speak to the method resolution code :), but I think this would be a positive step. (Requiring the explicit `self` argument would probably make sense, if this were to happen.) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.j.kuehn at gmail.com Sun Oct 20 11:06:51 2013 From: timothy.j.kuehn at gmail.com (Tim Kuehn) Date: Sun, 20 Oct 2013 11:06:51 -0700 Subject: [rust-dev] Unified function/method call syntax and further Message-ID: <-3272830698175511297@unknownmsgid> simplification MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7823106168118235853==" --===============7823106168118235853== Content-Type: multipart/alternative; boundary="----4SVSQE8L3ECYN7Z8RACUF07S828YYG" ------4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I haven't been completely following this discussion as it's a bit over my head, but if two different types define a method of the same name, it seems to me that there'd be no ambiguity. Java allows function overloading; wouldn't this sort of be similar? From: Patrick Walton Sent: =E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM To: G=C3=A1bor Lehel; Marijn Haverbeke Cc: rust-dev at mozilla.org Subject: Re: [rust-dev] Unified function/method call syntax and further simplification What would happen if two types defined a method called, say, "foo", and the= importing module glob imported them both? Patrick "G=C3=A1bor Lehel" wrote: >On Sun, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel >wrote: > >> So I very much agree with Patrick. Some aspects of this proposal are >>> attractive, but it breaks some essential properties of the way >methods >>> currently work (and probably can't be adjusted to work around that >>> without losing most of it attraction). >>> >> >> The main cost would be having to import methods explicitly (or using >a >> glob), as Patrick notes. >> > >Now I'm wondering, though: going with my proposal, if the module >structure >were just a little bit more fine-grained, I think you could achieve >basically the same effect as the current system, if you wanted to. If >the >convention were to use a module to enclose a type together with its >methods >(which is already the case in many places), and you did a glob import >of >that module, you would get what you have now: the type and its methods >would all come into scope. Except you could still import selectively, >if >you wanted to, or do things any other way, if you wanted to, and all of >the >"warts" I mentioned would still disappear. In a different crate, you >could >similarly create a module of "extension methods", which could be >imported >together or selectively, if you wanted to. > >I don't want to push this too hard if it's past the point of being >productive, but I'm now even more convinced that this would be a >beneficial >change. Types should be types, grouping and scoping should be done with >modules (Rust's modules are very capable), and traits should be used >for >type-based abstraction. I think it would work great. > >--=20 >Your ship was destroyed in a monadic eruption. --=20 Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I haven't b= een completely following this discussion as it's a bit over my head, but if= two different types define a method of the same name, it seems to me that = there'd be no ambiguity. Java allows function overloading; wouldn't this so= rt of be similar?

From: Patrick Walton
Sent: =E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM
To:
G=C3=A1bor Lehel; Marijn Haverbeke
Cc= : <= A href=3D"mailto:rust-dev at mozilla.org">rust-dev at mozilla.org
<= SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT= : bold">Subject: Re: [rust-dev] Unified function/method call syntax and furthe= r simplification

What would happen if two types defined a method called, say, "foo&quo= t;, and the importing module glob imported them both?

Patrick

"G=C3=A1bor Lehel" <= illissius at gmail.com> wrote:
On S= un, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel <illissius at gmail.com&g= t; wrote:
So I very much agree with Patrick. Some aspects of this proposal are
attractive, but it breaks some essential properties of the way methods
currently work (and probably can't be adjusted to work around that
without losing most of it attraction).

The main cost would be having to import methods exp= licitly (or using a glob), as Patrick notes.
<= /blockquote>

Now I'm wondering, though: going with my proposal= , if the module structure were just a little bit more fine-grained, I think= you could achieve basically the same effect as the current system, if you = wanted to. If the convention were to use a module to enclose a type togethe= r with its methods (which is already the case in many places), and you did = a glob import of that module, you would get what you have now: the type and= its methods would all come into scope. Except you could still import selec= tively, if you wanted to, or do things any other way, if you wanted to, and= all of the "warts" I mentioned would still disappear. In a diffe= rent crate, you could similarly create a module of "extension methods&= quot;, which could be imported together or selectively, if you wanted to.
I don't want to push this too hard if it's past th= e point of being productive, but I'm now even more convinced that this = would be a beneficial change. Types should be types, grouping and scoping s= hould be done with modules (Rust's modules are very capable), and trait= s should be used for type-based abstraction. I think it would work great.
--
Your ship was destroyed in a monadic eruption.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<= /html> ------4SVSQE8L3ECYN7Z8RACUF07S828YYG-- --===============7823106168118235853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev --===============7823106168118235853==-- From n.nethercote at gmail.com Sun Oct 20 00:40:15 2013 From: n.nethercote at gmail.com (Nicholas Nethercote) Date: Sun, 20 Oct 2013 18:40:15 +1100 Subject: [rust-dev] [dev-servo] Rust and Servo internships with the GNOME Outreach Program for Women In-Reply-To: <5261A4B2.4000500@mozilla.com> References: <5261A4B2.4000500@mozilla.com> Message-ID: On Sat, Oct 19, 2013 at 8:14 AM, Brian Anderson wrote: > > This year, the Rust and Servo projects are participating in the GNOME > Outreach Program for Women (OPW). Nice to hear. Nick From pwalton at mozilla.com Sun Oct 20 12:38:53 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 12:38:53 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: I guess I just don't see the value in requiring imports of names when there can be no ambiguity and they're defined in one place (the impl of the type, defined in the same place as the type itself). One person's "magic" is another person's "smart compiler". I'm not convinced that this is solving a real problem. The "search all traits in scope" behavior strikes me as far more magical than this. Doing type-based lookup without imports, if the names all had to be defined in one place, seems like a bog-standard language feature to me. It's probably easier to list languages that *don't* have this feature in some form than to list languages that do, honestly... Patrick "G?bor Lehel" wrote: >On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton >wrote: > >> But then it seems strange to require that the methods be imported at >all, >> if you're going to do single-dispatch type-based resolution on them >anyway. >> > >Well, it would do type-based resolution based on the methods which you >import :). You would still be the one doing the importing, instead of >it >happening by magic. You could also /not/ import one or more of them, if >you >wanted to, which you can currently only do on a per-trait granularity. >And >the rest of the design would still be much cleaner. (Again, leaving to >modules what can be done with modules.) > >But FWIW, I think this is mostly orthogonal. If you use dot syntax, >method >lookup happens [somehow]. If it fails, you can do the other things. >Maybe >method lookup happens with type-based resolution, as it does now. Or >maybe >it requires that the name itself be unambiguous (which is simpler and >dumber), as with functions. That's not really the part I care about. >The >part I care about is the separation of concerns. > > > >> What we could do, perhaps, is add a third source of methods that the >dot >> operator searches: functions in scope. This would allow methods to be >> attached anywhere to pre-existing types in an ad-hoc basis. I'm a bit >> nervous about complicating our already-complicated method lookup >further, >> but maybe it makes sense to reduce the number of FooMethods traits >people >> have to write, as well as to accommodate function chaining patterns. >> > >I still can't speak to the method resolution code :), but I think this >would be a positive step. (Requiring the explicit `self` argument would >probably make sense, if this were to happen.) > >-- >Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eperso.mail at gmail.com Sun Oct 20 13:01:18 2013 From: eperso.mail at gmail.com (Guillaume HERVIER) Date: Sun, 20 Oct 2013 22:01:18 +0200 Subject: [rust-dev] Default arguments and keyword arguments Message-ID: <5264368E.3030301@gmail.com> Hi, I was reading an issue on Rust repo about functions default arguments and keyword arguments, and I saw that it didn't advanced yet. So, after asking in #rust IRC chan, I decided to create a pad about this issue to let people talk and arguing about this feature request. The goal of this pad is to have a spec to propose, and so, re-opening the issue. The issue URL is: https://github.com/mozilla/rust/issues/6973 And the pad URL: https://pad.riseup.net/p/hvbg6dQQnEe7 Cordially, Guillaume (aka KokaKiwi) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From pwalton at mozilla.com Sun Oct 20 13:25:13 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 13:25:13 -0700 Subject: [rust-dev] Default arguments and keyword arguments In-Reply-To: <5264368E.3030301@gmail.com> References: <5264368E.3030301@gmail.com> Message-ID: +1 to the Etherpad idea. It's a lot easier to collaborate there than a GitHub issue. Patrick Guillaume HERVIER wrote: >Hi, > >I was reading an issue on Rust repo about functions default arguments >and keyword arguments, and I saw that it didn't advanced yet. >So, after asking in #rust IRC chan, I decided to create a pad about >this >issue to let people talk and arguing about this feature request. > >The goal of this pad is to have a spec to propose, and so, re-opening >the issue. > >The issue URL is: https://github.com/mozilla/rust/issues/6973 >And the pad URL: https://pad.riseup.net/p/hvbg6dQQnEe7 > >Cordially, >Guillaume (aka KokaKiwi) > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Sun Oct 20 15:31:43 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Mon, 21 Oct 2013 00:31:43 +0200 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 9:38 PM, Patrick Walton wrote: > I guess I just don't see the value in requiring imports of names when > there can be no ambiguity and they're defined in one place (the impl of the > type, defined in the same place as the type itself). One person's "magic" > is another person's "smart compiler". > A big part of the motivation would be to allow declaring methods anywhere, without using traits, and then "they're defined in one place" stops being true. For that to be workable you need to have control over imports. (Luckily with top-level functions, you already do.) > I'm not convinced that this is solving a real problem. > It's not "solving a real problem" so much as simplifying the whole thing. Despite having used the word, my beef with the current system is not so much that it's magical. It's that it's completely unnecessary. With nothing more than a simple syntax rule and the existing module system, you can recover all of the expressive power of the current system, and more. Compare: -- Design 1 -- - You can declare functions using `fn`. - Functions in the current scope can be called using dot syntax with the first argument as the receiver. (Optionally: only if the first argument is named `self`.) - The module system can be used to group types, functions, and other items, import them together, selectively, or under different names, and resolve ambiguities between them. -- Design 2 -- - Anonymous `impl` blocks can be used to associate methods with a type. - Methods are scoped under and imported together with their type or trait. - Because of this, an anonymous `impl` can only be declared in the same module as its type. - If you want to declare a method somewhere else, declare an auxiliary trait and implement it for that type. - For a method to be called with dot syntax, it has to be declared using special `self`, `&self`, `~self`, (or so forth) syntax, which only works with the built-in pointer types. Such a method can't be called with function syntax. - If you want a self-type other than one of the built-in pointers, write an `impl` specifically for that type. - Types and traits are like modules in some ways (you can use them in a path), but not others (you can't `use` from them). - There are special rules and/or syntax for dealing with traits, generic types, and optionally their type arguments in paths. - In addition to methods, you can also declare top-level functions with `fn`. These can only be called with function syntax. - The module system can be used to group, import, rename, and resolve ambiguities between types, functions, and other items except for methods. Which one feels like the tighter design? With some extensions (methods can be called with function syntax, in-scope functions are also considered during method lookup), Design 2 could close the expressiveness gap versus Design 1. But the simplicity gap would remain. > The "search all traits in scope" behavior strikes me as far more magical > than this. > All of that said, maybe I'm insufficiently worked up about the method lookup rules. :) Searching trait impls does sound a little bit scary. What about, as a less scary in-between solution, while not throwing the baby out with the bathwater, attempting to unify the type of the receiver with the types of the first (`self`) arguments of the functions of the given name in the current scope, but *not* looking at trait impls? And if there's a unique match (modulo autoborrowing and such) it's selected, otherwise an error is reported. Whether appropriate trait impls exist would be checked after a method is selected. This means that if you have a trait method or function in scope which is generic in its self-type, and any other function which also matches the type of the receiver, it would lead to ambiguity. But as (in my proposal) you would no longer have to use traits to implement extension methods, this would hopefully be a less common occurrence. Again though, I think this can and should be considered as a separate matter. It could be done inside the current system, I think, if you wanted to. The differences in the context of my proposal are the aforementioned not having to use traits for extension methods, and that you would have more ways to resolve an ambiguity. It's probably easier to list languages that *don't* have this feature in > some form than to list languages that do, honestly... > That's because all of the mainstream languages follow misguided OO ideas, and most of the others copy them. :-) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 20 16:07:50 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 20 Oct 2013 16:07:50 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: <366b7220-33fc-4f4e-b819-3189279ac686@email.android.com> Maximum conceptual simplicity has never been a design goal of Rust. If we wanted maximum simplicity we would just eliminate the dot operator entirely and use explicit existential types for trait objects like Haskell. I know that the dot operator is additional unnecessary complexity. No argument there. The thing is that the lookup rules are complexity I think we should buy into because of the convenience and familiarity we get from them. We tried explicit implementation importing, as well as having no dot operator at all, in early versions of Rust. That language was a lot less convenient and limited than Rust of today. The dot operator is there to allow object-oriented programming, including type-based method lookup. If you find OO distasteful, then you should be able to avoid use of the dot operator and still program Rust without loss of functionality (well, first-class trait objects excepted). That is what I had in mind with UMCS. As for some of the specifics in your list, I'd like to fix them. For example, I was going to bring up allowing custom smart pointer self types, as well as allowing "use" from impls, at a meeting soon. In general I have been thinking that type implementations and traits should be considered modules and should admit everything that can appear in a module. Patrick "G?bor Lehel" wrote: >On Sun, Oct 20, 2013 at 9:38 PM, Patrick Walton >wrote: > >> I guess I just don't see the value in requiring imports of names when >> there can be no ambiguity and they're defined in one place (the impl >of the >> type, defined in the same place as the type itself). One person's >"magic" >> is another person's "smart compiler". >> > >A big part of the motivation would be to allow declaring methods >anywhere, >without using traits, and then "they're defined in one place" stops >being >true. For that to be workable you need to have control over imports. >(Luckily with top-level functions, you already do.) > > > >> I'm not convinced that this is solving a real problem. >> > >It's not "solving a real problem" so much as simplifying the whole >thing. >Despite having used the word, my beef with the current system is not so >much that it's magical. It's that it's completely unnecessary. With >nothing >more than a simple syntax rule and the existing module system, you can >recover all of the expressive power of the current system, and more. > >Compare: > > >-- Design 1 -- > > - You can declare functions using `fn`. > >- Functions in the current scope can be called using dot syntax with >the >first argument as the receiver. (Optionally: only if the first argument >is >named `self`.) > > - The module system can be used to group types, functions, and other >items, import them together, selectively, or under different names, and >resolve ambiguities between them. > > >-- Design 2 -- > >- Anonymous `impl` blocks can be used to associate methods with a type. > >- Methods are scoped under and imported together with their type or >trait. > >- Because of this, an anonymous `impl` can only be declared in the same >module as its type. > > - If you want to declare a method somewhere else, declare an auxiliary >trait and implement it for that type. > >- For a method to be called with dot syntax, it has to be declared >using >special `self`, `&self`, `~self`, (or so forth) syntax, which only >works >with the built-in pointer types. Such a method can't be called with >function syntax. > >- If you want a self-type other than one of the built-in pointers, >write >an `impl` specifically for that type. > >- Types and traits are like modules in some ways (you can use them in a >path), but not others (you can't `use` from them). > >- There are special rules and/or syntax for dealing with traits, >generic >types, and optionally their type arguments in paths. > >- In addition to methods, you can also declare top-level functions with >`fn`. These can only be called with function syntax. > > - The module system can be used to group, import, rename, and resolve >ambiguities between types, functions, and other items except for >methods. > >Which one feels like the tighter design? > >With some extensions (methods can be called with function syntax, >in-scope >functions are also considered during method lookup), Design 2 could >close >the expressiveness gap versus Design 1. But the simplicity gap would >remain. > > > >> The "search all traits in scope" behavior strikes me as far more >magical >> than this. >> > >All of that said, maybe I'm insufficiently worked up about the method >lookup rules. :) Searching trait impls does sound a little bit scary. >What >about, as a less scary in-between solution, while not throwing the baby >out >with the bathwater, attempting to unify the type of the receiver with >the >types of the first (`self`) arguments of the functions of the given >name in >the current scope, but *not* looking at trait impls? And if there's a >unique match (modulo autoborrowing and such) it's selected, otherwise >an >error is reported. Whether appropriate trait impls exist would be >checked >after a method is selected. This means that if you have a trait method >or >function in scope which is generic in its self-type, and any other >function >which also matches the type of the receiver, it would lead to >ambiguity. >But as (in my proposal) you would no longer have to use traits to >implement >extension methods, this would hopefully be a less common occurrence. > >Again though, I think this can and should be considered as a separate >matter. It could be done inside the current system, I think, if you >wanted >to. The differences in the context of my proposal are the >aforementioned >not having to use traits for extension methods, and that you would have >more ways to resolve an ambiguity. > > >It's probably easier to list languages that *don't* have this feature >in >> some form than to list languages that do, honestly... >> > >That's because all of the mainstream languages follow misguided OO >ideas, >and most of the others copy them. :-) > > >-- >Your ship was destroyed in a monadic eruption. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Sun Oct 20 23:01:44 2013 From: igor at mir2.org (Igor Bukanov) Date: Mon, 21 Oct 2013 08:01:44 +0200 Subject: [rust-dev] Rust compiler running on ARM? Message-ID: What is the current status of ARM support in Rust? In particularly I am interested in running the compiler on an ARM Chromebook. From corey at octayn.net Mon Oct 21 00:42:09 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 03:42:09 -0400 Subject: [rust-dev] Rust compiler running on ARM? In-Reply-To: References: Message-ID: I've yet to see or hear of a rustc running native on ARM, though it shouldn't be impossible to cross-build rustc for native ARM: we can already target ARM just fine. On Mon, Oct 21, 2013 at 2:01 AM, Igor Bukanov wrote: > What is the current status of ARM support in Rust? In particularly I > am interested in running the compiler on an ARM Chromebook. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Mon Oct 21 07:30:02 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 10:30:02 -0400 Subject: [rust-dev] On Stack Safety Message-ID: I've written a blog post about stack safety and a proposal for how I think it should be implemented in Rust: http://cmr.github.io/blog/2013/10/21/on-stack-safety/ Thoughts, comments? I'm going to implement this after my (ill-kept) hiatus if there's consensus that this is a good idea. From pwalton at mozilla.com Mon Oct 21 08:48:45 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 21 Oct 2013 08:48:45 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: This seems generally on the right track. A couple of thoughts: * I can pretty much guarantee you that that simple of a static analysis to determine stack size is going to fail on any reasonable program. I would just leave it out. If you're feeling ambitious, you could implement it as an LLVM pass to eliminate stack bounds checks on recursion-free leaves of the call graph. (LLVM is the right place to do it, as it can make these decisions post-inlining, and also knows the exact amount of stack space each function takes up.) * Why not have the crate-level stack checking attribute be a function-level attribute instead? That way you could implement "tainting" easily: just require that any function tagged with "no stack check" be marked unsafe. Overall, this is great--I like this direction :) Patrick Corey Richardson wrote: >I've written a blog post about stack safety and a proposal for how I >think it should be implemented in Rust: >http://cmr.github.io/blog/2013/10/21/on-stack-safety/ > >Thoughts, comments? I'm going to implement this after my (ill-kept) >hiatus if there's consensus that this is a good idea. >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Oct 21 09:11:50 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 12:11:50 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton wrote: > This seems generally on the right track. A couple of thoughts: > > * I can pretty much guarantee you that that simple of a static analysis to > determine stack size is going to fail on any reasonable program. I would > just leave it out. If you're feeling ambitious, you could implement it as an > LLVM pass to eliminate stack bounds checks on recursion-free leaves of the > call graph. (LLVM is the right place to do it, as it can make these > decisions post-inlining, and also knows the exact amount of stack space each > function takes up.) > Yep. It's mostly for the case where recursion and dynamic dispatch is going to be denied, which seems to be the case for some embedded/realtime contexts, afaict from the available research. > * Why not have the crate-level stack checking attribute be a function-level > attribute instead? That way you could implement "tainting" easily: just > require that any function tagged with "no stack check" be marked unsafe. > It's not obvious to me that one could have multiple functions in a crate, each having a different stack safety strategy, working at once. No stack check on a function level would be easy to implement though, yes. From alex at crichton.co Mon Oct 21 09:28:13 2013 From: alex at crichton.co (Alex Crichton) Date: Mon, 21 Oct 2013 09:28:13 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: It's great to see progress in this area! I know that this has been a tricky topic in the past, and it would be awesome to get things sorted out. One thing I would keep in mind is that pretty much any strategy (except the no safety one) involves changes in LLVM. I think we all hope to one day use "clean upstream LLVM" as opposed to maintaining our own fork. This sounds like it's functionality which would certainly be desirable from LLVM's point of view, but it may be worth checking up with them occasionally to ensure so. Recently they're not big fans of the idea of a "no-split-stack" attribute, which I thought was a given. Another thing to consider is that in a runtime-constrained context, you're probably not going to want to use the default implementation of the "stack safety mechanism" in place. Right now this means that you probably don't want libmorestack.a and it's __morestack strategy. This also means that any implementor of a stack-safety strategy needs to be aware of the ABI of stack management. Currently this means that maintainers of a __morestack strategy need to be aware of where the TLS slot is on all platforms, and this doesn't necessarily map well to something like a kernel module. All this really means though is that it probably needs to be configurable from LLVM's point of view (hard), or it should be documented if we expect implementations of __morestack other than our own. It's awesome to see work in this area, and I can't wait for the pull request! On Mon, Oct 21, 2013 at 7:30 AM, Corey Richardson wrote: > I've written a blog post about stack safety and a proposal for how I > think it should be implemented in Rust: > http://cmr.github.io/blog/2013/10/21/on-stack-safety/ > > Thoughts, comments? I'm going to implement this after my (ill-kept) > hiatus if there's consensus that this is a good idea. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Mon Oct 21 09:38:00 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 12:38:00 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: On Mon, Oct 21, 2013 at 12:28 PM, Alex Crichton wrote: > It's great to see progress in this area! I know that this has been a > tricky topic in the past, and it would be awesome to get things sorted > out. > > One thing I would keep in mind is that pretty much any strategy > (except the no safety one) involves changes in LLVM. The only change I can see necessary is querying the maximum stack frame size (for guard zones). Daniel mentioned this in IRC yesterday. > I think we all > hope to one day use "clean upstream LLVM" as opposed to maintaining > our own fork. This sounds like it's functionality which would > certainly be desirable from LLVM's point of view, but it may be worth > checking up with them occasionally to ensure so. Recently they're not > big fans of the idea of a "no-split-stack" attribute, which I thought > was a given. > > Another thing to consider is that in a runtime-constrained context, > you're probably not going to want to use the default implementation of > the "stack safety mechanism" in place. Right now this means that you > probably don't want libmorestack.a and it's __morestack strategy. So the crate would use a different value for `#[stack_safety="...];`, rather than `#[stack_safety="segmented"];` The idea isn't to enable different implementations of __morestack, the idea is to enable entirely different concepts of stack safety entirely. From kevin at sb.org Mon Oct 21 10:08:36 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 21 Oct 2013 10:08:36 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: On Oct 21, 2013, at 9:11 AM, Corey Richardson wrote: > On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton wrote: >> This seems generally on the right track. A couple of thoughts: >> >> * I can pretty much guarantee you that that simple of a static analysis to >> determine stack size is going to fail on any reasonable program. I would >> just leave it out. If you're feeling ambitious, you could implement it as an >> LLVM pass to eliminate stack bounds checks on recursion-free leaves of the >> call graph. (LLVM is the right place to do it, as it can make these >> decisions post-inlining, and also knows the exact amount of stack space each >> function takes up.) >> > > Yep. It's mostly for the case where recursion and dynamic dispatch is > going to be denied, which seems to be the case for some > embedded/realtime contexts, afaict from the available research. It seems to me that trying to determine max stack size is incompatible with dynamic linking. So even if you disallow recursion, any function that calls a function outside of its own crate is not going to be able to trust its calculated max stack size. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From corey at octayn.net Mon Oct 21 10:13:50 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 13:13:50 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: On Mon, Oct 21, 2013 at 1:08 PM, Kevin Ballard wrote: > On Oct 21, 2013, at 9:11 AM, Corey Richardson wrote: > >> On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton wrote: >>> This seems generally on the right track. A couple of thoughts: >>> >>> * I can pretty much guarantee you that that simple of a static analysis to >>> determine stack size is going to fail on any reasonable program. I would >>> just leave it out. If you're feeling ambitious, you could implement it as an >>> LLVM pass to eliminate stack bounds checks on recursion-free leaves of the >>> call graph. (LLVM is the right place to do it, as it can make these >>> decisions post-inlining, and also knows the exact amount of stack space each >>> function takes up.) >>> >> >> Yep. It's mostly for the case where recursion and dynamic dispatch is >> going to be denied, which seems to be the case for some >> embedded/realtime contexts, afaict from the available research. > > It seems to me that trying to determine max stack size is incompatible with dynamic linking. So even if you disallow recursion, any function that calls a function outside of its own crate is not going to be able to trust its calculated max stack size. The stack limit would be in the crate metadata, but I can see how it'd be possible to violate safety with this. But in the cases you'd want this analysis, you wouldn't be using dynamic linking anyway. From oren at ben-kiki.org Mon Oct 21 10:47:24 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 21 Oct 2013 10:47:24 -0700 Subject: [rust-dev] What does `once fn` mean? Message-ID: I have code which (greatly simplified) boiled down to: ``` fn attempt_1(action: &fn() -> T) -> T { action() } fn call_attempt_1() -> ~str { let mut index = 0; let string = ~"str"; do attempt_1 { // No problem here. We have a stack closure. index += 1; // Error: cannot move out of captured outer variable // Makes sense. Compiler can't tell the action will only be invoked // once. string } } ``` So, I heard there are things called `once fn`, which seem to be what I need. Even though the compiler warned me away from them, I thought I'd give them a try in the spirit of investigation: ``` fn attempt_2(action: &once fn() -> T) -> T { action() } fn call_attempt_2() -> ~str { let mut index = 0; let string = ~"str"; do attempt_2 { // Error: cannot assign to immutable captured outer variable in a heap closure // It seems that `&once fn` is a _heap_ closure? Makes no sense... It // would have made sense if it was an `~once fn`, but there's no way // that `action_2` should be able to store somewhere a reference to an // `&once fn`, so a stack closure should be fine! index += 1; string } } ``` So, obviously `once fn` doesn't do what I expected it to do, which is to simply assert "this fn is only called once". It seems it does that but also carries some extra baggage of also saying "force me to be a heap closure". It isn't clear to me _why_ these two should be conflated - after all, one could just say `~once fn` if one wanted a heap closure. Can someone enlighten me on this? At any rate, I then resorted to: ``` fn attempt_2(action: &fn() -> T) -> T { action() } fn call_attempt_2() -> ~str { let mut index = 0; let string = ~"str"; let string_cell = Cell::new(string); do attempt_1 { // No problem here. We have a stack closure. index += 1; // Dynamic assertion that the action is only invoked once. Costs in // both extra ugly source code lines and in run-time overhead. string_cell.take() } } ``` So, this works, but boy is it ugly, not to mention inefficient Can someone suggest a better way to achieve this, and shed some light on the status of the `once fn` construct in general? Thanks, Oren Ben-Kiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Mon Oct 21 12:13:33 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Oct 2013 21:13:33 +0200 Subject: [rust-dev] Should I/O use conditions? In-Reply-To: (Steven Blenkinsop's message of "Sat, 19 Oct 2013 13:11:20 -0400") References: <525F0152.4090403@mozilla.com> <87fvrzwww1.fsf@mid.deneb.enyo.de> <52603315.7030705@mozilla.com> <87wqlbvfyl.fsf@mid.deneb.enyo.de> <0d73c5f2-7b68-4e40-a4d4-4a13d04a3634@email.android.com> <87vc0umg2n.fsf@mid.deneb.enyo.de> <87mwm59q6w.fsf@mid.deneb.enyo.de> Message-ID: <87li1m4eua.fsf@mid.deneb.enyo.de> * Steven Blenkinsop: > On Saturday, 19 October 2013, Florian Weimer wrote: > >> >> The problem is that if err is of type "error", "err != nil" is true >> after the assignment of a pointer value to err. So the usual error >> checking idiom doesn't work if your function returns a >> pointer-to-struct (that implements the "error" interface) instead of a >> (relatively opaque) "error" interface value. > Don't do that. Return an error, not a naked error implementation. If people > want to inspect it rather than treat it as a string, they'll do a type > assertion rather than just a nil check. Then the Go-level interface doesn't tell the programmer that the type assertion continues working (i.e., that there is something to which the caller can attach its extra information). > Don't do that. Return either a nil error or a valid value of your error > type. Seriously, the nil interface vs nil contents thing is only a tripping > point for novices who don't understand what interfaces are, it's not > something you run into once you've familiarized yourself with the language. We'll see if that's true once we've got at analyzer that flags this. :-) > That's not a chaining mechanism. > > You're going to need to explain what you mean by this, then, and how it > would apply to Rust. Note that if it's something very particular to how Go > code is written, it's probably not constructive here. Java exceptions have a getCause() mechanism which returns another exception. When you've got a piece of got that needs to provide further context to exceptions that might be thrown by lower layers, it can at a catch-all exception handler (well, usually for Exception, not Throwable, so it's not quite catch-all) and throw a new exception, specifying the existing exception as a cuase. Traceback printing uses this information and suppresses identical parts of the call stack, which often results in fairly useful output, without resorting to more elaborate debugging mechanisms. In contrast, I'm worried that error value threading (even when done properly, not swallowing any errors) destroys potentially valuable information about the context while the stack is (manually) unwound, leaving little more than a bare error message when it's finally reported or logged. From fw at deneb.enyo.de Mon Oct 21 12:22:33 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Oct 2013 21:22:33 +0200 Subject: [rust-dev] On Stack Safety In-Reply-To: (Patrick Walton's message of "Mon, 21 Oct 2013 08:48:45 -0700") References: Message-ID: <87bo2i4efa.fsf@mid.deneb.enyo.de> * Patrick Walton: > * I can pretty much guarantee you that that simple of a static > analysis to determine stack size is going to fail on any reasonable > program. It's needed to show total correctness, and often done with tool support in the embedded space. GCC has some support for it. Obviously, it only works with fairly restricted language subsets, but such is life if you're after verifiable total correctness. From bill_myers at outlook.com Mon Oct 21 13:07:52 2013 From: bill_myers at outlook.com (Bill Myers) Date: Mon, 21 Oct 2013 20:07:52 +0000 Subject: [rust-dev] On Stack Safety In-Reply-To: References: , , , , Message-ID: > It seems to me that trying to determine max stack size is incompatible with dynamic linking. So even if you disallow recursion, any function that calls a function outside of its own crate is not going to be able to trust its calculated max stack size. The maximum stack size needs to be computed dynamically, in a "C++ global constructor" placed by rustc in all crate compiled libraries/executables that would write the computed value in suitable global variables. The check only needs to be done by task creation routines, by function calls contained in a recursion cycle, by closures and by stubs put in ~Trait/@Trait vtables (where Trait is public and thus implementable by other crates). Note that the latter two cannot really be avoided by taking the max over all implementations dynamically because a new dynamic library could be loaded between the check and the indirect call. -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon Oct 21 15:05:56 2013 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 21 Oct 2013 15:05:56 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: Message-ID: <5265A544.1090802@mozilla.com> On 10/21/2013 07:30 AM, Corey Richardson wrote: > I've written a blog post about stack safety and a proposal for how I > think it should be implemented in Rust: > http://cmr.github.io/blog/2013/10/21/on-stack-safety/ > > Thoughts, comments? I'm going to implement this after my (ill-kept) > hiatus if there's consensus that this is a good idea. Thanks for writing this up! I agree with Patrick that static analysis isn't worth trying. As to the dynamic checks, I'd suggest just throwing out segmented stacks. Let's decide once and for all that they're a losing proposition; the tide seems to have turned against them. At that point the choice for checking stack overflow is between guard pages and the __morestack prologue, but why offer both options? Let's just pick one and keep it simple. The prospect of disabling stack safety on a crate level is interesting, but it's not clear to me what the use case is for combining unsafe crates with safe crates. The only reason I see for wanting to turn off the stack checks is for embedded cases that don't want to use tasks and don't want to link to morestack.a (assuming we use __morestack for the check). I'd like to know more about the reasoning here. The harder problem, not addressed here, is what to do when we run out of stack. For various reasons recovering in this situation is very hard, and right now the best we can do is abort. So my opinion of what to do with stacks is different: * Keep aborting when running out of stack via __morestack (we're already doing this) * Start using mmapping to map pages of stack on demand (this happens automatically on some linux configurations but needs to be done explicitly to guarantee lazy allocation). * Consider switching to guard pages for the stack check - this has some downsides in that the point of failure is arbitrary (not in the fn prologue) so much harder to recover from. Can we commit to making stack overflow a process abort? If we use guard pages for the check then there's not even any code gen difference between stack-safe Rust and stack-unsafe Rust; it's just a matter of runtime setup. From erick.tryzelaar at gmail.com Mon Oct 21 15:18:42 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 21 Oct 2013 15:18:42 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: In my opinion, there are two main reasons why one would prefer an immutable API over a mutable one: aliasing and sharing substructures. Given that unique pointers and references have mostly solved the first one, in my opinion we should prefer mutable APIs unless the API is going to take advantage of structure sharing. I don't think it makes a lot of sense to have immutable APIs like this: fn frob(&mut self) { ... } fn frobed(&self) -> Frob { let x = self.clone(); x.frob(); x } It's a lot more straightforward for the users to write `let y = x.clone(); y.frob();`, and it protects us from another combinatorial explosion of methods. All that being said, I feel there is an open question on whether or not to prefer statement oriented mutable APIs (methods like `fn frob(&mut self)`) and chain-oriented APIs (methods like `fn frob(self) -> Frob`). Does anyone have a good argument for one over the other? On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson wrote: > > Date: Fri, 18 Oct 2013 10:54:23 -0700 >> From: Jeff Petkau >> >> >> >> >> On my code (disclaimer: only toy projects to learn Rust so far), I've >> been >> pretty happy with a "mut_" prefix for mutable versions. >> >> newthing = oldthing.push(foo") >> anything.mut_push(foo") >> >> x = bagofun.sort() >> bagosadness.mut_sort() >> >> etc. >> >> Advantages: >> - consistent meaning with the 'mut' keyword. >> - works with pretty much any name. >> - makes mutable versions just a bit uglier than immutable code. >> >> Disadvantages: >> - If an API is inherently mutable, it gets pretty noisy. >> - A bit ugly, probably turns off newcomers. >> - If the compiler warns on ignoring return values, and mutating methods >> return (), then a convention might be unnecessary. >> >> --Jeff >> >> > What about establishing a convention that mutable methods start with an > uppercase letter while non-mutating methods start with a lowercase letter? > It would be lightweight in terms of character count/looks and at the same > time give mutable methods a slight visual emphasis, which makes sense I > think. > > I know this convention is already used by Traits, but when I looked > through some code with the above proposal in mind it would be easy to > distinguish between these two uses of the same convention due to the > differing contexts they're used in. > > -Eric > > > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Mon Oct 21 16:10:12 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Tue, 22 Oct 2013 10:10:12 +1100 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: References: Message-ID: <9D0CC3AD-0C5D-4B2E-9497-ED669D0673E2@yahoo.com.au> > chain-oriented APIs (methods like `fn frob(self) -> Frob`) What about: ~~~ fn frob(self) -> Frob { let mut x = self; // not sure if you need `cast::transmute_mut` here x.thing = foo(); x } ~~~ That would solve the 'copying' problem. I was actually considering doing this as a way of initialising an object in a fluent style: ~~~ let perlin = Perlin::from_seed_str("Kittens") .with_frequency(2.0) .with_octaves(3); ~~~ ~Brendan On 22/10/2013, at 9:18 AM, Erick Tryzelaar wrote: > In my opinion, there are two main reasons why one would prefer an immutable API over a mutable one: aliasing and sharing substructures. Given that unique pointers and references have mostly solved the first one, in my opinion we should prefer mutable APIs unless the API is going to take advantage of structure sharing. I don't think it makes a lot of sense to have immutable APIs like this: > > fn frob(&mut self) { ... } > fn frobed(&self) -> Frob { let x = self.clone(); x.frob(); x } > > It's a lot more straightforward for the users to write `let y = x.clone(); y.frob();`, and it protects us from another combinatorial explosion of methods. > > All that being said, I feel there is an open question on whether or not to prefer statement oriented mutable APIs (methods like `fn frob(&mut self)`) and chain-oriented APIs (methods like `fn frob(self) -> Frob`). Does anyone have a good argument for one over the other? > > > > On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson wrote: > > Date: Fri, 18 Oct 2013 10:54:23 -0700 > From: Jeff Petkau > > > > > On my code (disclaimer: only toy projects to learn Rust so far), I've been > pretty happy with a "mut_" prefix for mutable versions. > > newthing = oldthing.push(foo") > anything.mut_push(foo") > > x = bagofun.sort() > bagosadness.mut_sort() > > etc. > > Advantages: > - consistent meaning with the 'mut' keyword. > - works with pretty much any name. > - makes mutable versions just a bit uglier than immutable code. > > Disadvantages: > - If an API is inherently mutable, it gets pretty noisy. > - A bit ugly, probably turns off newcomers. > - If the compiler warns on ignoring return values, and mutating methods > return (), then a convention might be unnecessary. > > --Jeff > > > What about establishing a convention that mutable methods start with an uppercase letter while non-mutating methods start with a lowercase letter? It would be lightweight in terms of character count/looks and at the same time give mutable methods a slight visual emphasis, which makes sense I think. > > I know this convention is already used by Traits, but when I looked through some code with the above proposal in mind it would be easy to distinguish between these two uses of the same convention due to the differing contexts they're used in. > > -Eric > > > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danoctavian91 at gmail.com Mon Oct 21 16:33:35 2013 From: danoctavian91 at gmail.com (Dan Cristian Octavian) Date: Mon, 21 Oct 2013 16:33:35 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: Bumping this, because my deadline for choosing a master's project is 25th. Would appreciate it if somebody could give me a brief answer about my concerns with regards to the runtimeless rust thing, at least. If I am unclear please ask for clarifications. It's mainly about getting help with formulating a set of targets (bundle of issues) given my resources so i can submit a proposal. If I can't do that in the time left, I will have to choose something else. Many thanks, Dan On Thu, Oct 17, 2013 at 11:04 AM, Dan Cristian Octavian < danoctavian91 at gmail.com> wrote: > Hello, > > I've spend some time looking at proposed master's projects by my uni to > understand how this one compares and to understand the time resources that > I have available (roughly 3 months of solid work and roughly 3 months of > part-time during term-time work until project submission deadline, of > course i could continue working afterwards to get things done ): > > Correct me if I'm wrong on the following: > the main issues about runtimeless rust are: > * supporting std functionality (to various degrees depending on the > environment) > * the stacks issue > > One of my concerns is that suppose I choose to do this, it's part of an > active development effort and the aforementioned issues seem to be > connected to many other problems (the stack problem) and it's kind of hard > to just crop a big issue out and say "yup this is a standalone project, you > go do it". I am just worried I will have a hard time saying "I've done > this" and I will only be able to say "I've been a contributor to Rust for a > while working mainly on this" and that doesn't add up to be a master's > project. I would really like to work on this, though. Do you think it can > be formulated as a set of targets that are useful to the Rust project (they > are actually used) and at the same time constitute a valid master's > project? > > Would picking an issue that is milestoned for after 1.0 release be a good > cure for this problem since their are not as interconnected with currently > developed features? I've browsed through the interesting-project tagged > issues. Aside from runtimeless I was interested in the following: > > compile time stack size https://github.com/mozilla/rust/issues/4389 > proper REPL https://github.com/mozilla/rust/issues/9898 > parallel multi-crate compiler driver > https://github.com/mozilla/rust/issues/3431 > sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 > > But there's also the issue of having something sizeable enough. > Again any suggestions welcome. > > Many thanks, > > Dan > > > > On Tue, Oct 1, 2013 at 12:07 PM, Alex Crichton wrote: > >> > One of my first thoughts when I saw the Rust project was to make it >> > runtimeless. Shortly after that was achieved rather trivially with >> zero.rs. >> > I don't know if any major improvement can be done there. >> >> As others have said, I don't believe that Rust is currently at the >> point of being "runtimeless". In addition to what Brian mentioned >> about not being able to use core-language features easily (vectors, >> strings, convenient I/O), the story of stacks is also a little sad in >> runtimeless rust. Currently a "runtimeless" program is still forced to >> link to librustrt along with our own libmorestack to provide the >> __morestack function needed by LLVM's segmented stacks. It always >> seemed a little silly to me that "runtimeless" rust still links to the >> runtime... >> >> Various bits of discussion can be found on >> >> https://github.com/mozilla/rust/pull/8955 >> https://github.com/mozilla/rust/issues/8345 >> >> But in summary the story of how stacks are allocated is currently not >> sufficient for writing something like a kernel module or a kernel >> itself. I do believe that this is certainly within the realm of >> possibility, but it certainly needs to be done carefully. I'm not sure >> if it's too small of a master's project, but I personally consider >> this to be a fairly substantial undertaking to get right. The various >> modes discussed in those two issues would be useful to have. >> >> This also may not be limited to a runtimeless rust, because the >> current stack situation is a bit in flux with rust currently. Our >> segmented stacks are disabled in the new runtime (not implemented yet) >> and there's some unease about the fixed_stack_segment macro and how it >> can be more useful. >> >> For reference, here's some issues: >> >> Runtimeless rust: https://github.com/mozilla/rust/issues/3608 >> newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 >> revised stack attributes: https://github.com/mozilla/rust/issues/8822 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Mon Oct 21 16:55:44 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 21 Oct 2013 16:55:44 -0700 Subject: [rust-dev] mutable vs. functional APIs In-Reply-To: <9D0CC3AD-0C5D-4B2E-9497-ED669D0673E2@yahoo.com.au> References: <9D0CC3AD-0C5D-4B2E-9497-ED669D0673E2@yahoo.com.au> Message-ID: On Mon, Oct 21, 2013 at 4:10 PM, Brendan Zabarauskas wrote: > chain-oriented APIs (methods like `fn frob(self) -> Frob`) > > > What about: > > ~~~ > fn frob(self) -> Frob { > let mut x = self; // not sure if you need `cast::transmute_mut` here > x.thing = foo(); > x > } > ~~~ > You don't need the `transmute_mut` here, doing `let mut x = self;` works just fine. > That would solve the 'copying' problem. > > I was actually considering doing this as a way of initialising an object > in a fluent style: > > ~~~ > let perlin = Perlin::from_seed_str("Kittens") > .with_frequency(2.0) > .with_octaves(3); > ~~~ > I agree, it's great for initialization, I've used this approach too for https://github.com/erickt/rust-elasticsearch for building up JSON objects. I could see some logic to us using chaining by default. It has some nice symmetry with the iterator protocol: ``` fn frob(xs: ~[int]) -> ~[int] { xs .push(0) .push(1) .push(2) .move_iter().map(|x| x + 1).collect() } ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Mon Oct 21 17:14:02 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon, 21 Oct 2013 17:14:02 -0700 Subject: [rust-dev] master's project work on rust - ideas In-Reply-To: References: Message-ID: On Mon, Oct 21, 2013 at 4:33 PM, Dan Cristian Octavian wrote: > Bumping this, because my deadline for choosing a master's project is 25th. > > Would appreciate it if somebody could give me a brief answer about my > concerns with regards to the runtimeless rust thing, at least. If I am > unclear please ask for clarifications. > Hi Dan -- As a former grad student, the big piece of advice I have is to not make the success or lack thereof of your master's thesis topic depend on anything that's outside your control, which includes whether the Rust team decides to integrate your patch. It's nothing personal -- in open-source, code can fail to get integrated for a wide variety of reasons, not usually having to do with the submitter's lack of enthusiasm or skill -- just pragmatism. So I think you should choose a research question that you can formulate in a way that's independent of Rust. Then, make sure that whether or not your work succeeds or fails, you will have learned something. That way you can provide at least a partial answer to your research question even if your work ends up not being applicable to Rust. A good thesis topic is one that is guaranteed to contribute something to the literature whether it's in the form of a positive result or a negative result. I think you could potentially have a very strong thesis by formulating a question that's independent of any specific language, then explaining secondarily that as your case study, you will implement your approach as part of the Rust compiler. Then even if you don't have a finished solution at the end, you can write about your experiences. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From kmcallister at mozilla.com Mon Oct 21 17:37:32 2013 From: kmcallister at mozilla.com (Keegan McAllister) Date: Mon, 21 Oct 2013 17:37:32 -0700 (PDT) Subject: [rust-dev] On Stack Safety In-Reply-To: <5265A544.1090802@mozilla.com> References: <5265A544.1090802@mozilla.com> Message-ID: <1468570872.4433136.1382402252538.JavaMail.zimbra@mozilla.com> > * Consider switching to guard pages for the stack check What if your overflowing stack frame is bigger than a page and you access the far end of it first? I think we'd still need __morestack checks for functions that use a lot of stack. keegan From jhm456 at gmail.com Mon Oct 21 17:58:35 2013 From: jhm456 at gmail.com (Jerry Morrison) Date: Mon, 21 Oct 2013 17:58:35 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: On Sun, Oct 20, 2013 at 5:28 AM, G?bor Lehel wrote: > On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton wrote: > >> I think it's unfortunately too late to overhaul the language like this. >> This will require redesigns of all Rust code in existence. >> >> I do like unified function/method call syntax, but I think it can be done >> in a backwards compatible way. >> > > This is up to you and the rest of the Rust team, of course. But in my very > humble opinion, it feels shortsighted to impose backwards compatibility > constraints at this point. All Rust code in existence is still (hopefully!) > a negligibly small fraction of the code that is yet to be written. I know > there's a desire to get 1.0 out the door as soon as possible, and I > understand it (I want to be using Rust instead of C++, too!), but if Rust > is still in use years or decades from now, decisions made now about the > design of the language will echo far louder than whether it was released a > few months earlier or later. I think it would be unfortunate to start > suffering a C++-like fate sooner than absolutely necessary. > The Go team has been able to make incompatible language & library changes by providing a tool that updates existing programs. Since Go's pretty-printer fully defines the appearance of source code (indenting, line wrapping, etc.), the updater can't mess up such things (and there are no debates about them). > That was a general argument, and it only matters if something is > considered a good idea on the merits. In this case, it seems we disagree > about that: > > > On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton wrote: > >> I was thinking not. The dot operator should still have special name >> lookup rules: it searches through associated impls and all traits in scope. >> It cannot call anything that is not attached to an impl. >> >> This does make functions and methods somewhat less unified, but it makes >> methods feel more like OO methods from a scoping POV. I feel the draws of >> methods are not only that they switch the order of the receiver and action >> but also that they allow functions associated with a type to be called >> without explicitly importing their names. >> > > Aha. That's exactly the thing I don't like, and thought would be > beneficial to change. It's different from everything else for no great > reason (is being like OO a great reason?), and carries baggage with warts > and thorny issues in it. (Needing special language constructs to write > methods; normal `fn`s feel like second-class citizens; can't selectively or > rename-import methods; can't write method-syntax functions in a different > crate without introducing spurious abstraction boundaries; the whole `impl > T { fn(&self) }` versus `impl &T { fn(self) }` ugliness; traits and generic > types in paths raise awkward questions; ...) > > -- > Your ship was destroyed in a monadic eruption. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Oct 21 18:37:21 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 21 Oct 2013 21:37:21 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: <1468570872.4433136.1382402252538.JavaMail.zimbra@mozilla.com> References: <5265A544.1090802@mozilla.com> <1468570872.4433136.1382402252538.JavaMail.zimbra@mozilla.com> Message-ID: On Mon, Oct 21, 2013 at 8:37 PM, Keegan McAllister wrote: > > * Consider switching to guard pages for the stack check > > What if your overflowing stack frame is bigger than a page and you access > the far end of it first? I think we'd still need __morestack checks for > functions that use a lot of stack. > > keegan > LLVM could be taught to return the maximum stack frame size in order to allocate the right number of guard pages in addition to the regular stack size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Oct 21 18:38:21 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 21 Oct 2013 21:38:21 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: <1468570872.4433136.1382402252538.JavaMail.zimbra@mozilla.com> References: <5265A544.1090802@mozilla.com> <1468570872.4433136.1382402252538.JavaMail.zimbra@mozilla.com> Message-ID: Nope. Guard zones, not guard page (singular!). Except in the face of loading things from dynamic libs at runtime (which is unsafe right now anyway), you can always determine the maximum stack frame used by a given executable crate. On Mon, Oct 21, 2013 at 8:37 PM, Keegan McAllister wrote: >> * Consider switching to guard pages for the stack check > > What if your overflowing stack frame is bigger than a page and you access the far end of it first? I think we'd still need __morestack checks for functions that use a lot of stack. > > keegan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From vadimcn at gmail.com Mon Oct 21 18:57:45 2013 From: vadimcn at gmail.com (Vadim) Date: Mon, 21 Oct 2013 18:57:45 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: <5265A544.1090802@mozilla.com> References: <5265A544.1090802@mozilla.com> Message-ID: Hi Brian, Can you please elaborate on why segmented stacks fell out of favor? Maybe it's been discussed among the core Rust team, but external people like me are probably wondering why. It seems to me that segmented stacks would be essential for async I/O and actor-based architectures, no? Vadim On Mon, Oct 21, 2013 at 3:05 PM, Brian Anderson wrote: > On 10/21/2013 07:30 AM, Corey Richardson wrote: > >> I've written a blog post about stack safety and a proposal for how I >> think it should be implemented in Rust: >> http://cmr.github.io/blog/**2013/10/21/on-stack-safety/ >> >> Thoughts, comments? I'm going to implement this after my (ill-kept) >> hiatus if there's consensus that this is a good idea. >> > > Thanks for writing this up! > > I agree with Patrick that static analysis isn't worth trying. > > As to the dynamic checks, I'd suggest just throwing out segmented stacks. > Let's decide once and for all that they're a losing proposition; the tide > seems to have turned against them. At that point the choice for checking > stack overflow is between guard pages and the __morestack prologue, but why > offer both options? Let's just pick one and keep it simple. > > The prospect of disabling stack safety on a crate level is interesting, > but it's not clear to me what the use case is for combining unsafe crates > with safe crates. The only reason I see for wanting to turn off the stack > checks is for embedded cases that don't want to use tasks and don't want to > link to morestack.a (assuming we use __morestack for the check). I'd like > to know more about the reasoning here. > > The harder problem, not addressed here, is what to do when we run out of > stack. For various reasons recovering in this situation is very hard, and > right now the best we can do is abort. > > So my opinion of what to do with stacks is different: > > * Keep aborting when running out of stack via __morestack (we're already > doing this) > * Start using mmapping to map pages of stack on demand (this happens > automatically on some linux configurations but needs to be done explicitly > to guarantee lazy allocation). > * Consider switching to guard pages for the stack check - this has some > downsides in that the point of failure is arbitrary (not in the fn > prologue) so much harder to recover from. Can we commit to making stack > overflow a process abort? > > If we use guard pages for the check then there's not even any code gen > difference between stack-safe Rust and stack-unsafe Rust; it's just a > matter of runtime setup. > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Oct 21 18:59:56 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Tue, 22 Oct 2013 03:59:56 +0200 Subject: [rust-dev] Audio for "Rust: A Friendly Introduction" now available In-Reply-To: <52602BB6.2050003@mozilla.com> References: <52602BB6.2050003@mozilla.com> Message-ID: I will be giving the talk at CodeMash. Here's my RuPy slides: http://steveklabnik.github.io/nobody_knows_rust/#/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Oct 21 20:48:08 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 21 Oct 2013 23:48:08 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> Message-ID: On Mon, Oct 21, 2013 at 9:57 PM, Vadim wrote: > Hi Brian, > Can you please elaborate on why segmented stacks fell out of favor? > Maybe it's been discussed among the core Rust team, but external people > like me are probably wondering why. > It seems to me that segmented stacks would be essential for async I/O and > actor-based architectures, no? > > Vadim > Segmented stacks result in extra code being added to every function, loss of memory locality, high overhead for calls into C and unpredictable performance hits due to segment thrashing. They do seem important for making the paradigm of one task per connection viable for servers, but it's hard to balance that with other needs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Oct 21 21:31:23 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 21 Oct 2013 21:31:23 -0700 Subject: [rust-dev] Unified function/method call syntax and further simplification In-Reply-To: References: <39ef398a-7502-40e4-9d05-178608c409f5@email.android.com> Message-ID: <5265FF9B.9050901@mozilla.com> On 10/21/13 5:58 PM, Jerry Morrison wrote: > The Go team has been able to make incompatible language & library > changes by providing a tool that updates existing programs. Since Go's > pretty-printer fully defines the appearance of source code (indenting, > line wrapping, etc.), the updater can't mess up such things (and there > are no debates about them). They stopped doing that after Go 1.0, and most of the changes that we've made are not the kinds of things that could be updated with a gofix-like tool anyhow. Go made most of its radical changes while it was still a secret project at Google. Patrick From vadimcn at gmail.com Mon Oct 21 21:37:27 2013 From: vadimcn at gmail.com (Vadim) Date: Mon, 21 Oct 2013 21:37:27 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> Message-ID: Ok, so maybe they should be disabled by default. But to eliminate them outright would be shortsighted, IMHO. Can we leave them as an option for people who do care about this sort of stuff? On Mon, Oct 21, 2013 at 8:48 PM, Daniel Micay wrote: > On Mon, Oct 21, 2013 at 9:57 PM, Vadim wrote: > >> Hi Brian, >> Can you please elaborate on why segmented stacks fell out of favor? >> Maybe it's been discussed among the core Rust team, but external people >> like me are probably wondering why. >> It seems to me that segmented stacks would be essential for async I/O and >> actor-based architectures, no? >> >> Vadim >> > > Segmented stacks result in extra code being added to every function, loss > of memory locality, high overhead for calls into C and unpredictable > performance hits due to segment thrashing. > > They do seem important for making the paradigm of one task per connection > viable for servers, but it's hard to balance that with other needs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Oct 21 21:52:51 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 21 Oct 2013 21:52:51 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> Message-ID: <526604A3.20900@mozilla.com> On 10/21/13 8:48 PM, Daniel Micay wrote: > Segmented stacks result in extra code being added to every function, > loss of memory locality, high overhead for calls into C and > unpredictable performance hits due to segment thrashing. > > They do seem important for making the paradigm of one task per > connection viable for servers, but it's hard to balance that with other > needs. I'm not sure they're that important even for that use case. Is 4 kB (page size) per connection that bad? You won't compete with nginx's memory usage (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB stacks), but you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on 64 bit). Besides, if we really wanted to go head-to-head with nginx we could introduce "microthreads" with very small stack limits (256 bytes or whatever) that just fail if you run off the end. Such a routine would be utterly miserable to program correctly but would be necessary if you want to compete with nginx in the task model anyhow :) Realistically, though, if you are writing an nginx killer you will want to use async I/O and avoid the task model, as even the overhead of context switching via userspace register save-and-restore is going to put you at a disadvantage. Given what I've seen of the nginx code you aren't going to beat it without counting every cycle. Patrick From danielmicay at gmail.com Mon Oct 21 21:52:35 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 22 Oct 2013 00:52:35 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> Message-ID: On Tue, Oct 22, 2013 at 12:37 AM, Vadim wrote: > Ok, so maybe they should be disabled by default. But to eliminate them > outright would be shortsighted, IMHO. Can we leave them as an option for > people who do care about this sort of stuff? > Segmented stacks aren't actually implemented in the new runtime, so they would have to be implemented rather than just not eliminated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Tue Oct 22 00:19:41 2013 From: vadimcn at gmail.com (Vadim) Date: Tue, 22 Oct 2013 00:19:41 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> Message-ID: Sorry, I haven't followed newrt closely. What are the missing pieces currently? And there's other infrastructure in Rust for supporting segmented stacks. Like the "fixed stack" attribute (and all functions already marked up with it). Like implementations of __morestack for different architectures. If all that were removed from the source, bringing segmented stacks back would become much more difficult. On Mon, Oct 21, 2013 at 9:52 PM, Daniel Micay wrote: > On Tue, Oct 22, 2013 at 12:37 AM, Vadim wrote: > >> Ok, so maybe they should be disabled by default. But to eliminate them >> outright would be shortsighted, IMHO. Can we leave them as an option for >> people who do care about this sort of stuff? >> > > Segmented stacks aren't actually implemented in the new runtime, so they > would have to be implemented rather than just not eliminated. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Tue Oct 22 00:56:29 2013 From: vadimcn at gmail.com (Vadim) Date: Tue, 22 Oct 2013 00:56:29 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: <526604A3.20900@mozilla.com> References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: What I have in mind is not nginx, but rather something like a pub-sub service, with millions of idle connections, which don't do much most of the time. And no, I don't want an async I/O API :-) Not if I can help it. I am still hoping that Rust can avoid having separate sync and async I/O APIs. Not sure what context switching you are referring to... Surely nginx also needs to save and restore registers when it goes into kernel mode for select syscall (or whatever it uses)? Regarding "microthreads": wouldn't those need to check stack limit in every function in order to detect overflow, just as segmented stack prologues do? So what's the difference? Vadim On Mon, Oct 21, 2013 at 9:52 PM, Patrick Walton wrote: > On 10/21/13 8:48 PM, Daniel Micay wrote: > >> Segmented stacks result in extra code being added to every function, >> loss of memory locality, high overhead for calls into C and >> unpredictable performance hits due to segment thrashing. >> >> They do seem important for making the paradigm of one task per >> connection viable for servers, but it's hard to balance that with other >> needs. >> > > I'm not sure they're that important even for that use case. Is 4 kB (page > size) per connection that bad? You won't compete with nginx's memory usage > (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB > stacks), but you do compete with Go (4 kB initial stack segment) and Erlang > (2.4 kB on 64 bit). > > Besides, if we really wanted to go head-to-head with nginx we could > introduce "microthreads" with very small stack limits (256 bytes or > whatever) that just fail if you run off the end. Such a routine would be > utterly miserable to program correctly but would be necessary if you want > to compete with nginx in the task model anyhow :) > > Realistically, though, if you are writing an nginx killer you will want to > use async I/O and avoid the task model, as even the overhead of context > switching via userspace register save-and-restore is going to put you at a > disadvantage. Given what I've seen of the nginx code you aren't going to > beat it without counting every cycle. > > Patrick > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Tue Oct 22 04:37:04 2013 From: igor at mir2.org (Igor Bukanov) Date: Tue, 22 Oct 2013 13:37:04 +0200 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: On 22 October 2013 09:56, Vadim wrote: > What I have in mind is not nginx, but rather something like a pub-sub > service, with millions of idle connections, which don't do much most of the > time. And no, I don't want an async I/O API :-) Not if I can help it. I > am still hoping that Rust can avoid having separate sync and async I/O APIs. What if one wants to write nginx in Rust? Linear type systems must be very useful with asynchronous API as they ensure that the connection object cannot fall in the wrong hands - I was bitten by that in JS few times. From banderson at mozilla.com Tue Oct 22 16:40:50 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 22 Oct 2013 16:40:50 -0700 Subject: [rust-dev] Mozilla hiring a research engineer to work on Rust Message-ID: <52670D02.4070205@mozilla.com> Dear Rusties, Mozilla is going to hire another engineer to work on Rust! As we head toward Rust 1.0 we are looking for a motivated individual with serious chops to help us grind through the remaining blocking bugs. Enthusiasm for Servo will also be looked upon with great favor. See all the gory details here: https://careers.mozilla.org/en-US/position/oMiEXfwp I look forward to reading all those lovely applications. Regards, Brian From thadguidry at gmail.com Tue Oct 22 17:13:21 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 22 Oct 2013 19:13:21 -0500 Subject: [rust-dev] Mozilla hiring a research engineer to work on Rust In-Reply-To: <52670D02.4070205@mozilla.com> References: <52670D02.4070205@mozilla.com> Message-ID: And it looks like your still hiring for that LLVM Compiler engineer as well ! https://careers.mozilla.org/en-US/position/o3VZWfwD On Tue, Oct 22, 2013 at 6:40 PM, Brian Anderson wrote: > Dear Rusties, > > Mozilla is going to hire another engineer to work on Rust! As we head > toward Rust 1.0 we are looking for a motivated individual with serious > chops to help us grind through the remaining blocking bugs. Enthusiasm for > Servo will also be looked upon with great favor. See all the gory details > here: https://careers.mozilla.org/**en-US/position/oMiEXfwp > > I look forward to reading all those lovely applications. > > Regards, > Brian > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Oct 22 19:41:53 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 22 Oct 2013 19:41:53 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: <52673771.8010207@mozilla.com> On 10/22/2013 12:56 AM, Vadim wrote: > What I have in mind is not nginx, but rather something like a pub-sub > service, with millions of idle connections, which don't do much most > of the time. And no, I don't want an async I/O API :-) Not if I can > help it. I am still hoping that Rust can avoid having separate sync > and async I/O APIs. Millions of concurrent tasks was always a longshot anyway. Even when we had segmented stacks and put some effort into tuning the most tasks we ever had in a 32-bit process was 500,000; 1 million was my goal. At that time our minimum stack allocation was still around 3k. With the new strategy we're talking more like 4k of stack allocation. So some use cases will be served slightly worse, but we weren't doing that much better before anyway. > > Not sure what context switching you are referring to... Surely nginx > also needs to save and restore registers when it goes into kernel mode > for select syscall (or whatever it uses)? The context switching cost of converting async I/O into synchronous I/O. In the current task model every sync I/O operation incurs 2 context switches: context switch from the task to the scheduler, make an async I/O call, wait for completion, context switch back to the task. That's the minimum cost of not blocking other tasks when doing synchronous I/O. > > Regarding "microthreads": wouldn't those need to check stack limit in > every function in order to detect overflow, just as segmented stack > prologues do? So what's the difference? > > Vadim > > > > On Mon, Oct 21, 2013 at 9:52 PM, Patrick Walton > wrote: > > On 10/21/13 8:48 PM, Daniel Micay wrote: > > Segmented stacks result in extra code being added to every > function, > loss of memory locality, high overhead for calls into C and > unpredictable performance hits due to segment thrashing. > > They do seem important for making the paradigm of one task per > connection viable for servers, but it's hard to balance that > with other > needs. > > > I'm not sure they're that important even for that use case. Is 4 > kB (page size) per connection that bad? You won't compete with > nginx's memory usage (2.5 MB for 10,000 connections, compared to > 40 MB for the same with 4 kB stacks), but you do compete with Go > (4 kB initial stack segment) and Erlang (2.4 kB on 64 bit). > > Besides, if we really wanted to go head-to-head with nginx we > could introduce "microthreads" with very small stack limits (256 > bytes or whatever) that just fail if you run off the end. Such a > routine would be utterly miserable to program correctly but would > be necessary if you want to compete with nginx in the task model > anyhow :) > > Realistically, though, if you are writing an nginx killer you will > want to use async I/O and avoid the task model, as even the > overhead of context switching via userspace register > save-and-restore is going to put you at a disadvantage. Given what > I've seen of the nginx code you aren't going to beat it without > counting every cycle. > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From remifontan at yahoo.fr Wed Oct 23 01:22:49 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Wed, 23 Oct 2013 21:22:49 +1300 Subject: [rust-dev] writing file Message-ID: Hi, I'm learning how to open a file and write simple text data in it. I managed something to work but was wondering whether I had to cast my filestream as a writer: use std::path::Path; use std::rt::io::Writer; use std::rt::io::file::open; use std::rt::io::{Create, ReadWrite}; let p = &Path("test.txt"); let mut stream = match open(p, Create, ReadWrite) { Some(s) => s, None => fail!("whoops! I'm sure this raised, anyways..") }; writeln!(&mut stream as &mut Writer, "test {}, {}, {aa}", 1, 3.0, aa=2); Is that the simplest way to open a file and write in it? I find the "&mut stream as &mut Writer" a bit surprising. cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From danoctavian91 at gmail.com Wed Oct 23 07:59:02 2013 From: danoctavian91 at gmail.com (Dan Cristian Octavian) Date: Wed, 23 Oct 2013 15:59:02 +0100 Subject: [rust-dev] Rust on Xen In-Reply-To: <513121D2.1030603@mozilla.com> References: <513121D2.1030603@mozilla.com> Message-ID: has there been any discussion about this recently? is there any issue associated with it? How smooth is tackling the problem of making unikernels out of rust code at the moment, given the state of the runtime? Thanks, Dan On Fri, Mar 1, 2013 at 9:46 PM, Brian Anderson wrote: > On 03/01/2013 08:37 AM, Tim Ford wrote: > >> The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is very >> interesting to me. The idea is that your OCaml application is compiled >> directly into a bootable Xen microkernel image. Rather than running inside >> an OS, your OCaml links to a "libOS", a library that provides all the OS >> services in terms of Xen hypercalls. >> >> What are your thoughts regarding whether the same could be accomplished >> with Rust? You'd have to reimplement the Rust runtime and many OS >> services, though perhaps the work done for OpenMirage could be of some help >> there. >> >> It seems like Rust would be a great language for this. >> > > I am interested in this. What they are doing does sound a lot like Rust > and I would like us to get to the point where we can write kernel code in > Rust. As Graydon mentioned though, our runtime code isn't structured to > allow this yet, but we are inching closer. We probably shouldn't try to do > it until after the scheduler rewrite because `core` depends on a bunch of > runtime code that doesn't have a future and isn't worth porting to > kernelspace. Afterword though, I expect the relationship between `core` and > the scheduler to be [reversed], so that all the runtime machinery will be > optional. At that point it should take just a very small platform > abstraction layer to implement `core`, and we can think about the > multithreading separately. > > [reversed]: https://github.com/mozilla/**rust/issues/5157 > > I talked briefly with Anil (from openmirage) about this subject last year, > but it would be nice to touch base again sometime. I've copied him on this > thread. > > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed Oct 23 08:06:45 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 23 Oct 2013 17:06:45 +0200 Subject: [rust-dev] Rust on Xen In-Reply-To: References: <513121D2.1030603@mozilla.com> Message-ID: <5267E605.6010801@steveklabnik.com> There is now a dedicated OS IRC channel and wiki page: https://github.com/mozilla/rust/wiki/Operating-system-development -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From alex at crichton.co Wed Oct 23 08:47:56 2013 From: alex at crichton.co (Alex Crichton) Date: Wed, 23 Oct 2013 08:47:56 -0700 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: Right now the file I/O isn't quite what I think we want it to be in the end, but otherwise that is roughly the code which you'll want to write. It could be slightly shortened like this: use std::rt::io::Writer; use std::rt::io::file::FileInfo; use std::rt::io; let mut stream = Path::new("test.txt").open_writer(io::Create); writeln!(&mut stream as &mut Writer, "test {}, {}, {aa}", 1, 3.0, aa=2); Or at least you could write it as such if you didn't care about errors. Right now there's "impl Reader for Option" so there's no need to inspect the return value of open_writer. There are a few planned changes to this code which I would like to put into place, however: 1. std::rt::io::Writer belongs in the prelude 2. There should be a std::rt::io::File which wraps many common operations like opening a file, creating a file, etc, which doesn't require importing a trait from std::rt::io::file along with importing std::rt::io. 3. We should have object coercion so "&mut stream as &mut Writer" isn't necessary, but rather "&mut stream" is sufficient. With these changes, the code would look like: use std::rt::io::File; let mut stream = File::create("test.txt"); writeln!(&mut stream, "test {}, {}, {aa}", 1, 3.0, aa=2); Which I think looks a lot better than before! I would love to not have to write `&mut stream` or have something like `stream.write!(foo, bar, baz)`, but I haven't thought much about changing the write! macro. On Wed, Oct 23, 2013 at 1:22 AM, R?mi Fontan wrote: > Hi, > > I'm learning how to open a file and write simple text data in it. I managed > something to work but was wondering whether I had to cast my filestream as a > writer: > > > use std::path::Path; > use std::rt::io::Writer; > use std::rt::io::file::open; > use std::rt::io::{Create, ReadWrite}; > > let p = &Path("test.txt"); > let mut stream = match open(p, Create, ReadWrite) { > Some(s) => s, > None => fail!("whoops! I'm sure this raised, anyways..") > }; > > writeln!(&mut stream as &mut Writer, "test {}, {}, {aa}", 1, 3.0, aa=2); > > > Is that the simplest way to open a file and write in it? I find the "&mut > stream as &mut Writer" a bit surprising. > > cheers, > > R?mi > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From lists at dhardy.name Wed Oct 23 09:43:47 2013 From: lists at dhardy.name (Diggory Hardy) Date: Wed, 23 Oct 2013 18:43:47 +0200 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: <1427859.nfT6dGcr6k@tph-l10036> > use std::rt::io::File; > > let mut stream = File::create("test.txt"); > writeln!(&mut stream, "test {}, {}, {aa}", 1, 3.0, aa=2); > > > Which I think looks a lot better than before! I would love to not have > to write `&mut stream` or have something like `stream.write!(foo, bar, > baz)`, but I haven't thought much about changing the write! macro. Are macros possible in traits? stream.writeln!( "test {}, {}, {aa}", 1, 3.0, aa=2 ); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From hatahet at gmail.com Wed Oct 23 16:48:50 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 23 Oct 2013 16:48:50 -0700 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: On Wed, Oct 23, 2013 at 8:47 AM, Alex Crichton wrote: > With these changes, the code would look like: > > use std::rt::io::File; > > let mut stream = File::create("test.txt"); > writeln!(&mut stream, "test {}, {}, {aa}", 1, 3.0, aa=2); > > How would errors be handled in this case? Raising conditions? Thanks -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Wed Oct 23 17:01:13 2013 From: alex at crichton.co (Alex Crichton) Date: Wed, 23 Oct 2013 17:01:13 -0700 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: > Are macros possible in traits? Right now the grammar does not allow for this, and it may be difficult to do so (I don't think that we're going to change that in the near future) > Object coercion would be great, is that a planned feature? I believe so. I thought there was a bug open already, but I didn't find one, so I opened https://github.com/mozilla/rust/issues/10039 > How would errors be handled in this case? Raising conditions? We're entertaining the idea of removing conditions, so the `writeln!` macro and related `write!` functions will probably all return a `Result<(), ~Error>` or whatever the generic error type becomes. From pwalton at mozilla.com Wed Oct 23 17:02:54 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 23 Oct 2013 17:02:54 -0700 Subject: [rust-dev] writing file In-Reply-To: <1427859.nfT6dGcr6k@tph-l10036> References: <1427859.nfT6dGcr6k@tph-l10036> Message-ID: <526863AE.8010800@mozilla.com> On 10/23/13 9:43 AM, Diggory Hardy wrote: >> use std::rt::io::File; >> >> let mut stream = File::create("test.txt"); >> writeln!(&mut stream, "test {}, {}, {aa}", 1, 3.0, aa=2); >> >> >> Which I think looks a lot better than before! I would love to not have >> to write `&mut stream` or have something like `stream.write!(foo, bar, >> baz)`, but I haven't thought much about changing the write! macro. > > Are macros possible in traits? > > stream.writeln!( "test {}, {}, {aa}", 1, 3.0, aa=2 ); That can't really be done due to a phasing problem: macros run before typechecking, but trait resolution is not done until typechecking (and monomorphization happens at codegen, which actually can occur *after* compilation due to libraries). Patrick From banderson at mozilla.com Wed Oct 23 18:32:10 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 23 Oct 2013 18:32:10 -0700 Subject: [rust-dev] Rust on Xen In-Reply-To: References: <513121D2.1030603@mozilla.com> Message-ID: <5268789A.40606@mozilla.com> On 10/23/2013 07:59 AM, Dan Cristian Octavian wrote: > has there been any discussion about this recently? is there any issue > associated with it? How smooth is tackling the problem of making > unikernels out of rust code at the moment, given the state of the runtime? Not any further discussion along these lines, no. We saw Anil at OSCON and continued to agree that Rust would be great for this, but have not taken any steps. As Steve said though, a number of people are pursuing OS development in Rust. From thadguidry at gmail.com Wed Oct 23 20:47:56 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Wed, 23 Oct 2013 22:47:56 -0500 Subject: [rust-dev] Rust on Xen In-Reply-To: <5268789A.40606@mozilla.com> References: <513121D2.1030603@mozilla.com> <5268789A.40606@mozilla.com> Message-ID: THIS Anvil ? --> http://anvil.readthedocs.org/en/latest/topics/summary.html On Wed, Oct 23, 2013 at 8:32 PM, Brian Anderson wrote: > On 10/23/2013 07:59 AM, Dan Cristian Octavian wrote: > >> has there been any discussion about this recently? is there any issue >> associated with it? How smooth is tackling the problem of making >> unikernels out of rust code at the moment, given the state of the runtime? >> > > Not any further discussion along these lines, no. We saw Anil at OSCON and > continued to agree that Rust would be great for this, but have not taken > any steps. As Steve said though, a number of people are pursuing OS > development in Rust. > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -- -Thad Thad on Freebase.com Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Thu Oct 24 03:07:36 2013 From: igor at mir2.org (Igor Bukanov) Date: Thu, 24 Oct 2013 12:07:36 +0200 Subject: [rust-dev] map example from the tutorial and copy Message-ID: Here is the map example from the tutorial, http://static.rust-lang.org/doc/master/tutorial.html#generics , fn map(vector: &[T], function: &fn(v: &T) -> U) -> ~[U] { let mut accumulator = ~[]; for element in vector.iter() { accumulator.push(function(element)); } return accumulator; } It compiles even if the Clone trait is not specified for U and the push is defined as: fn push(&mut self, t: T); which I suppose implies a copy operation for T. So why the Clone trait is not necessary here for U? From asb at asbradbury.org Thu Oct 24 04:25:29 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Thu, 24 Oct 2013 12:25:29 +0100 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: On 24 October 2013 01:01, Alex Crichton wrote: > We're entertaining the idea of removing conditions, so the `writeln!` > macro and related `write!` functions will probably all return a > `Result<(), ~Error>` or whatever the generic error type becomes. Just from the IO module, or the language? Alex From ben.striegel at gmail.com Thu Oct 24 07:18:45 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Thu, 24 Oct 2013 10:18:45 -0400 Subject: [rust-dev] On Stack Safety In-Reply-To: <526604A3.20900@mozilla.com> References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: > you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on 64 bit). Actually, goroutines have a default stack size of 8kb since 1.2. Also, applicable to this discussion, in 1.3 Go will be moving away from segmented stacks to contiguous growable stacks: https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub On Tue, Oct 22, 2013 at 12:52 AM, Patrick Walton wrote: > On 10/21/13 8:48 PM, Daniel Micay wrote: > >> Segmented stacks result in extra code being added to every function, >> loss of memory locality, high overhead for calls into C and >> unpredictable performance hits due to segment thrashing. >> >> They do seem important for making the paradigm of one task per >> connection viable for servers, but it's hard to balance that with other >> needs. >> > > I'm not sure they're that important even for that use case. Is 4 kB (page > size) per connection that bad? You won't compete with nginx's memory usage > (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB > stacks), but you do compete with Go (4 kB initial stack segment) and Erlang > (2.4 kB on 64 bit). > > Besides, if we really wanted to go head-to-head with nginx we could > introduce "microthreads" with very small stack limits (256 bytes or > whatever) that just fail if you run off the end. Such a routine would be > utterly miserable to program correctly but would be necessary if you want > to compete with nginx in the task model anyhow :) > > Realistically, though, if you are writing an nginx killer you will want to > use async I/O and avoid the task model, as even the overhead of context > switching via userspace register save-and-restore is going to put you at a > disadvantage. Given what I've seen of the nginx code you aren't going to > beat it without counting every cycle. > > Patrick > > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Oct 24 07:23:29 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 24 Oct 2013 10:23:29 -0400 Subject: [rust-dev] map example from the tutorial and copy In-Reply-To: References: Message-ID: It's not necessary for U because there are no clones here, only moves. On Thu, Oct 24, 2013 at 6:07 AM, Igor Bukanov wrote: > Here is the map example from the tutorial, > http://static.rust-lang.org/doc/master/tutorial.html#generics , > > fn map(vector: &[T], function: &fn(v: &T) -> U) -> ~[U] { > let mut accumulator = ~[]; > for element in vector.iter() { > accumulator.push(function(element)); > } > return accumulator; > } > > > It compiles even if the Clone trait is not specified for U and the > push is defined as: > > fn push(&mut self, t: T); > > which I suppose implies a copy operation for T. So why the Clone trait > is not necessary here for U? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From steve at steveklabnik.com Thu Oct 24 07:39:12 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Thu, 24 Oct 2013 16:39:12 +0200 Subject: [rust-dev] writing file In-Reply-To: References: Message-ID: Conditions don't require language support, IIRC, they're just a library. So even if they were totally removed, you could still use them. From qwertie256 at gmail.com Thu Oct 24 08:19:09 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Thu, 24 Oct 2013 09:19:09 -0600 Subject: [rust-dev] Mozilla hiring a research engineer to work on Rust Message-ID: > Mozilla is going to hire another engineer to work on Rust! As we head > toward Rust 1.0 we are looking for a motivated individual with serious > chops to help us grind through the remaining blocking bugs. Enthusiasm > for Servo will also be looked upon with great favor. See all the gory > details here: https://careers.mozilla.org/en-US/position/oMiEXfwp > > I was a bit shocked to receive this rejection after just 2 hours and 15 minutes: >Thank you for taking the time to apply at Mozilla. We are always looking >for help creating great software and appreciate your offer to work with us! >Unfortunately, we're not always able to find a match within our organization >for everyone's skills and experience. After reviewing your application we >did not find a fit at this time, and as a result will not be able to move forward >further. If you don't want to give a reason, that's you're perogative, I guess, but this message doesn't even acknowledge that I applied for a *specific* position. I don't believe in 2 hours and 15 minutes someone actually checked if I was eligible for each of the available openings, not that I'm interested in most of the other positions anyhow. Also, I would at least like to know that the Rust team itself rejected me and not some generic HR person. >Also, if you are looking for ways to help build a better internet, there is no >easier way than running Firefox Aurora as your daily browser and filing >bugs and/or sending us your feedback. Getting hired by Mozilla could have changed my life. So this is a bit of a tacky way to finish the rejection, don't you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Thu Oct 24 08:57:29 2013 From: me at kevincantu.org (Kevin Cantu) Date: Thu, 24 Oct 2013 08:57:29 -0700 Subject: [rust-dev] Mozilla hiring a research engineer to work on Rust In-Reply-To: References: Message-ID: Hiring is hard. Their lawyers aren't going to let a Mozilla employee comment publicly. Send me (off the mailing list) what you sent them and I can give you my two cents of advice, privately, if you want! Kevin On Oct 24, 2013 8:19 AM, "David Piepgrass" wrote: > > >> Mozilla is going to hire another engineer to work on Rust! As we head >> toward Rust 1.0 we are looking for a motivated individual with serious >> chops to help us grind through the remaining blocking bugs. Enthusiasm >> for Servo will also be looked upon with great favor. See all the gory >> details here: https://careers.mozilla.org/en-US/position/oMiEXfwp >> >> I was a bit shocked to receive this rejection after just 2 hours and 15 > minutes: > > >Thank you for taking the time to apply at Mozilla. We are always looking > >for help creating great software and appreciate your offer to work with > us! > >Unfortunately, we're not always able to find a match within our > organization > >for everyone's skills and experience. After reviewing your application we > >did not find a fit at this time, and as a result will not be able to move > forward > >further. > > If you don't want to give a reason, that's you're perogative, I guess, but > this message doesn't even acknowledge that I applied for a *specific* > position. I don't believe in 2 hours and 15 minutes someone actually > checked if I was eligible for each of the available openings, not that I'm > interested in most of the other positions anyhow. > > Also, I would at least like to know that the Rust team itself rejected me > and not some generic HR person. > > >Also, if you are looking for ways to help build a better internet, there > is no > >easier way than running Firefox Aurora as your daily browser and filing > >bugs and/or sending us your feedback. > > Getting hired by Mozilla could have changed my life. So this is a bit of a > tacky way to finish the rejection, don't you think? > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Thu Oct 24 09:12:16 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 24 Oct 2013 18:12:16 +0200 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: On Thu, Oct 24, 2013 at 4:18 PM, Benjamin Striegel wrote: > > you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB > on 64 bit). > > Actually, goroutines have a default stack size of 8kb since 1.2. > > Also, applicable to this discussion, in 1.3 Go will be moving away from > segmented stacks to contiguous growable stacks: > https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub > > This is an interesting move, however the pointer-to-the-stack looks really hard to solve. In Rust, for example, I can store a reference to a stack element in a vec for example, and it is undistinguished (in the type system) from a pointer to an element not on the stack. Also, I was surprised at: "When that call returns, the new stack chunk is freed.", looks like they were not keeping the "next" chunk around. Indeed this could generate a lot of allocation traffic. -- Matthieu > > On Tue, Oct 22, 2013 at 12:52 AM, Patrick Walton wrote: > >> On 10/21/13 8:48 PM, Daniel Micay wrote: >> >>> Segmented stacks result in extra code being added to every function, >>> loss of memory locality, high overhead for calls into C and >>> unpredictable performance hits due to segment thrashing. >>> >>> They do seem important for making the paradigm of one task per >>> connection viable for servers, but it's hard to balance that with other >>> needs. >>> >> >> I'm not sure they're that important even for that use case. Is 4 kB (page >> size) per connection that bad? You won't compete with nginx's memory usage >> (2.5 MB for 10,000 connections, compared to 40 MB for the same with 4 kB >> stacks), but you do compete with Go (4 kB initial stack segment) and Erlang >> (2.4 kB on 64 bit). >> >> Besides, if we really wanted to go head-to-head with nginx we could >> introduce "microthreads" with very small stack limits (256 bytes or >> whatever) that just fail if you run off the end. Such a routine would be >> utterly miserable to program correctly but would be necessary if you want >> to compete with nginx in the task model anyhow :) >> >> Realistically, though, if you are writing an nginx killer you will want >> to use async I/O and avoid the task model, as even the overhead of context >> switching via userspace register save-and-restore is going to put you at a >> disadvantage. Given what I've seen of the nginx code you aren't going to >> beat it without counting every cycle. >> >> Patrick >> >> >> ______________________________**_________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/**listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Thu Oct 24 09:19:03 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 24 Oct 2013 09:19:03 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: <52694877.8060805@mozilla.com> On 10/24/13 9:12 AM, Matthieu Monrocq wrote: > > > > On Thu, Oct 24, 2013 at 4:18 PM, Benjamin Striegel > > wrote: > > > you do compete with Go (4 kB initial stack segment) and Erlang > (2.4 kB on 64 bit). > > Actually, goroutines have a default stack size of 8kb since 1.2. > > Also, applicable to this discussion, in 1.3 Go will be moving away > from segmented stacks to contiguous growable stacks: > https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub > > > This is an interesting move, however the pointer-to-the-stack looks > really hard to solve. In Rust, for example, I can store a reference to a > stack element in a vec for example, and it is undistinguished (in the > type system) from a pointer to an element not on the stack. Right. We can't do this without a fully precisely garbage-collected language, which Rust isn't. Patrick From banderson at mozilla.com Thu Oct 24 11:22:44 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 24 Oct 2013 11:22:44 -0700 Subject: [rust-dev] Rust on Xen In-Reply-To: References: <513121D2.1030603@mozilla.com> <5268789A.40606@mozilla.com> Message-ID: <52696574.5080604@mozilla.com> On 10/23/2013 08:47 PM, Thad Guidry wrote: > THIS Anvil ? --> > http://anvil.readthedocs.org/en/latest/topics/summary.html I was referring to Anil Madhavapeddy, one of the authors of OpenMirage, a system for creating unikernels that run on Xen. From dteller at mozilla.com Thu Oct 24 11:39:42 2013 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Thu, 24 Oct 2013 20:39:42 +0200 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> Message-ID: <5269696E.4080606@mozilla.com> I am curious. Isn't the stack a very simple region? Couldn't region inference be used to solve pointer-to-stack problems? Or do I completely misunderstand the definition of pointer-to-the-stack? On 10/24/13 6:12 PM, Matthieu Monrocq wrote: > This is an interesting move, however the pointer-to-the-stack looks > really hard to solve. In Rust, for example, I can store a reference to a > stack element in a vec for example, and it is undistinguished (in the > type system) from a pointer to an element not on the stack. > > Also, I was surprised at: "When that call returns, the new stack chunk > is freed.", looks like they were not keeping the "next" chunk around. > Indeed this could generate a lot of allocation traffic. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From igor at mir2.org Thu Oct 24 12:27:04 2013 From: igor at mir2.org (Igor Bukanov) Date: Thu, 24 Oct 2013 21:27:04 +0200 Subject: [rust-dev] map example from the tutorial and copy In-Reply-To: References: Message-ID: On 24 October 2013 16:23, Corey Richardson wrote: > It's not necessary for U because there are no clones here, only moves. Thanks, I missed the difference between move and copy here. I wonder is it possible to avoid any move at all? In C++ a push-like method can allocates storage and then it is used to store the result of the function call, like in *accumulator.raw_push() = function(element). But I guess Rust type system does not have a notion of raw storage that can only be used to write things to. From igor at mir2.org Thu Oct 24 12:33:39 2013 From: igor at mir2.org (Igor Bukanov) Date: Thu, 24 Oct 2013 21:33:39 +0200 Subject: [rust-dev] map example from the tutorial and copy In-Reply-To: References: Message-ID: Does it imply that in Rust any type can be moved even the one that have custom destructor? Thus it is not possible to have, for example, a stack-allocated struct that reference itself via a pointer? On 24 October 2013 16:23, Corey Richardson wrote: > It's not necessary for U because there are no clones here, only moves. > > On Thu, Oct 24, 2013 at 6:07 AM, Igor Bukanov wrote: >> Here is the map example from the tutorial, >> http://static.rust-lang.org/doc/master/tutorial.html#generics , >> >> fn map(vector: &[T], function: &fn(v: &T) -> U) -> ~[U] { >> let mut accumulator = ~[]; >> for element in vector.iter() { >> accumulator.push(function(element)); >> } >> return accumulator; >> } >> >> >> It compiles even if the Clone trait is not specified for U and the >> push is defined as: >> >> fn push(&mut self, t: T); >> >> which I suppose implies a copy operation for T. So why the Clone trait >> is not necessary here for U? >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Thu Oct 24 12:36:32 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 24 Oct 2013 15:36:32 -0400 Subject: [rust-dev] map example from the tutorial and copy In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 3:33 PM, Igor Bukanov wrote: > Does it imply that in Rust any type can be moved even the one that > have custom destructor? Thus it is not possible to have, for example, > a stack-allocated struct that reference itself via a pointer? > Every value can be moved, and it's always equivalent to a shallow `memcpy`. It's not possible to have a safe unboxed type depending on the location it's placed in memory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Thu Oct 24 13:07:15 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 24 Oct 2013 13:07:15 -0700 Subject: [rust-dev] map example from the tutorial and copy In-Reply-To: References: Message-ID: <52697DF3.2010808@mozilla.com> On 10/24/13 12:27 PM, Igor Bukanov wrote: > On 24 October 2013 16:23, Corey Richardson wrote: >> It's not necessary for U because there are no clones here, only moves. > > Thanks, I missed the difference between move and copy here. I wonder > is it possible to avoid any move at all? In C++ a push-like method can > allocates storage and then it is used to store the result of the > function call, like in *accumulator.raw_push() = function(element). > But I guess Rust type system does not have a notion of raw storage > that can only be used to write things to. This would be fixed by a placement new operator, which we'll need for custom smart pointers anyway. For example: new(accumulator.push_alloc) Element::create(); Patrick From erick.tryzelaar at gmail.com Thu Oct 24 16:24:37 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 24 Oct 2013 16:24:37 -0700 Subject: [rust-dev] 11/20 Rust Bay Area Meetup: SprocketNES Message-ID: Hey everyone! I'm happy to announce our next Rust Bay Area meetup! On November 20th at 7pm, Patrick Walton will be giving a presentation about his Nintendo emulator SprocketNES. This meetup will be held at the Mozilla San Francisco office at 2 Harrison St. Dinner and drinks will be provided by Mozilla (thanks Mozilla!). If you are interested in attending, please sign up on our meetup page here: http://www.meetup.com/Rust-Bay-Area/events/143439552/ We'll be filming the presentation if you can't make it. Finally, we have time available after Patrick for some short lightning talks. Please let me know if you are interested in giving one, and I'll make sure you get on the schedule. Thanks! I hope you can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilmars.cirulis at gmail.com Thu Oct 24 17:25:51 2013 From: ilmars.cirulis at gmail.com (=?UTF-8?B?SWxtxIFycyBDxKtydWxpcw==?=) Date: Fri, 25 Oct 2013 03:25:51 +0300 Subject: [rust-dev] Ideas for academic/research work related to Rust and formal verification Message-ID: Greetings! (I hope this isn't spam.) I am bachelor's degree student (the first of four years) in Computer Sciences. I am searching for any ideas that can be used as a research topic and is both related to Rust and formal verification/specification or similar. I'm learning Coq already, so it's my choice for any formal stuff. Some of my random ideas (most of them possible maybe in some future, but not now with rapidly development of Rust language): * Formal specification of Rust (maybe similar to LambdaJS) - to use it later in formal verification of Rust programs * Program extraction from proof. This idea got its inspiration from similarity of OCaml and Rust, and the fact that Coq allows extraction to OCaml. I understand that my ideas most probably are the unrealistic ones, because I have little to nothing experience and don't know what's is practical or even what's topical in formal method academic research. Maybe you have some ideas or suggestions? I plan to use that for activities besides lectures and later for my bachelor work. But then it's nice if it's something that academics/professors sees as something meaningful. Anyway, thanks! --- Ilm?rs C?rulis -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Thu Oct 24 17:31:29 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 24 Oct 2013 17:31:29 -0700 Subject: [rust-dev] Ideas for academic/research work related to Rust and formal verification In-Reply-To: References: Message-ID: Hi, Ilm?rs -- One of the things we're hoping to do is a type safety proof for a subset of Rust. Because machine-checked proofs are so labor-intensive (and it's almost impossible to appreciate just how labor-intensive until you try a proof for an even slightly realistic language), the usual approach is to start with a proof for a pared-down subset of your subject language. It would be a very good idea to start with a core language that isolated only *one* feature, and removed everything else that isn't relevant to formalizing that feature. For example, with Rust, one place to start is a language with integers and owned pointers (no borrowed or managed pointers) as the only types. To prove type soundness, you define an operational semantics for the sub-language you're working with, as well as a type system (static semantics) for it, and then prove that the two relate to each other (the usual reference on the basic approach is Benjamin Pierce's _Types and Programming Languages_, and Pierce's online book _Software Foundations_ shows how the proofs work in Coq). Again, if you did this for Rust, you'd want to start with the simplest possible subset of the language. https://github.com/mozilla/rust/issues/9883 is the issue tracking this task. Keep in mind that in that issue, we're thinking of a manual proof, not a machine-checked proof. We don't consider a machine-checked proof crucial for the success of the project, but it would certainly be an interesting project for somebody to undertake. The key to success is to limit the scope of the project severely, at least to start with. Niko Matsakis, on the core Rust team, has done some work already along these lines (formalization and manual proof, rather than machine-checked proof). I'm not sure how much of it is available. Cheers, Tim On Thu, Oct 24, 2013 at 5:25 PM, Ilm?rs C?rulis wrote: > Greetings! > > (I hope this isn't spam.) > > I am bachelor's degree student (the first of four years) in Computer > Sciences. I am searching for any ideas that can be used as a research topic > and is both related to Rust and formal verification/specification or > similar. > I'm learning Coq already, so it's my choice for any formal stuff. > > Some of my random ideas (most of them possible maybe in some future, but not > now with rapidly development of Rust language): > * Formal specification of Rust (maybe similar to LambdaJS) - to use it later > in formal verification of Rust programs > * Program extraction from proof. This idea got its inspiration from > similarity of OCaml and Rust, and the fact that Coq allows extraction to > OCaml. > > I understand that my ideas most probably are the unrealistic ones, because I > have little to nothing experience and don't know what's is practical or even > what's topical in formal method academic research. Maybe you have some ideas > or suggestions? > I plan to use that for activities besides lectures and later for my bachelor > work. But then it's nice if it's something that academics/professors sees as > something meaningful. > > Anyway, thanks! > > > --- > Ilm?rs C?rulis > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From bklooste at gmail.com Thu Oct 24 18:13:53 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Fri, 25 Oct 2013 09:13:53 +0800 Subject: [rust-dev] On Stack Safety In-Reply-To: <5269696E.4080606@mozilla.com> References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> <5269696E.4080606@mozilla.com> Message-ID: Yes its a simple region but region analysis is normally compile time while this is runtime..knowing the pointer points to the stack doesnt help . If you copy in a new stack you need to know every pointer to that stack if you move it to a new location .. Copying GCs do this all the time but they scan the heap for the mark and know the references and can use either a global pause or a write barrier . If you had a precise GC ( which can precisely define all the references) you could on need to grow stack , stop the world , scan the whole heap for references to the stack move the stack and update the references. This is expensive so you would want a warning to the programmer to increase the stack size. ( Note conservative collectors can confirm pointers to heap objects its just expensive , there may be a way of confirming a stack object maybe with a typecheck or wrapping such an object with some more data which allows precise determination). Why cant rust do precise marking , is it pointers to internal objects rather than offsets ? All good modern GCs are precise/copying so not having it is a big issue . Ben Kloosterman On Fri, Oct 25, 2013 at 2:39 AM, David Rajchenbach-Teller < dteller at mozilla.com> wrote: > I am curious. Isn't the stack a very simple region? Couldn't region > inference be used to solve pointer-to-stack problems? > > Or do I completely misunderstand the definition of pointer-to-the-stack? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Thu Oct 24 18:16:16 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 24 Oct 2013 18:16:16 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> <5269696E.4080606@mozilla.com> Message-ID: <5269C660.7070709@mozilla.com> On 10/24/13 6:13 PM, Ben Kloosterman wrote: > Yes its a simple region but region analysis is normally compile time > while this is runtime..knowing the pointer points to the stack doesnt help . > > If you copy in a new stack you need to know every pointer to that stack > if you move it to a new location .. Copying GCs do this all the time but > they scan the heap for the mark and know the references and can use > either a global pause or a write barrier . > > If you had a precise GC ( which can precisely define all the > references) you could on need to grow stack , stop the world , scan > the whole heap for references to the stack move the stack and update > the references. This is expensive so you would want a warning to the > programmer to increase the stack size. ( Note conservative collectors > can confirm pointers to heap objects its just expensive , there may be a > way of confirming a stack object maybe with a typecheck or wrapping such > an object with some more data which allows precise determination). > > Why cant rust do precise marking , is it pointers to internal objects > rather than offsets ? All good modern GCs are precise/copying so not > having it is a big issue . References (borrowed pointers) are not part of the stack map, so we can't rewrite them. Actually, there is no stack map support at all in LLVM (at least, not stack map support that supports a precise moving GC with roots in registers). Fixing this would be a lot of work, probably over a year. Patrick From banderson at mozilla.com Thu Oct 24 18:20:55 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 24 Oct 2013 18:20:55 -0700 Subject: [rust-dev] On Stack Safety In-Reply-To: <5269C660.7070709@mozilla.com> References: <5265A544.1090802@mozilla.com> <526604A3.20900@mozilla.com> <5269696E.4080606@mozilla.com> <5269C660.7070709@mozilla.com> Message-ID: <5269C777.8010103@mozilla.com> On 10/24/2013 06:16 PM, Patrick Walton wrote: > On 10/24/13 6:13 PM, Ben Kloosterman wrote: >> Yes its a simple region but region analysis is normally compile time >> while this is runtime..knowing the pointer points to the stack doesnt >> help . >> >> If you copy in a new stack you need to know every pointer to that stack >> if you move it to a new location .. Copying GCs do this all the time but >> they scan the heap for the mark and know the references and can use >> either a global pause or a write barrier . >> >> If you had a precise GC ( which can precisely define all the >> references) you could on need to grow stack , stop the world , scan >> the whole heap for references to the stack move the stack and update >> the references. This is expensive so you would want a warning to the >> programmer to increase the stack size. ( Note conservative collectors >> can confirm pointers to heap objects its just expensive , there may be a >> way of confirming a stack object maybe with a typecheck or wrapping such >> an object with some more data which allows precise determination). >> >> Why cant rust do precise marking , is it pointers to internal objects >> rather than offsets ? All good modern GCs are precise/copying so not >> having it is a big issue . > > References (borrowed pointers) are not part of the stack map, so we > can't rewrite them. > > Actually, there is no stack map support at all in LLVM (at least, not > stack map support that supports a precise moving GC with roots in > registers). Fixing this would be a lot of work, probably over a year. There is a new proposal to add stack maps to LLVM for use by the JS JIT: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066573.html. I haven't looked at the details, but this proposal is by Apple so it's probably going to happen. Could end up being beneficial to us someday. From redbrain at gcc.gnu.org Fri Oct 25 13:30:06 2013 From: redbrain at gcc.gnu.org (Philip Herron) Date: Fri, 25 Oct 2013 21:30:06 +0100 Subject: [rust-dev] Rust testsuite Message-ID: Hey all, I stumbled across rust at pycon ie 2013 and i've been hooked on learning more about it since. And so i thought i would give a go at writing a compiler for it so i've got: https://github.com/redbrain/gccrs Its a rust front-end to GCC and it compiles hello-world so far after about a week and a bit of development. I think its a fun exercise i think rust would target well on gcc. But anyways i was wondering the testsuite i was hoping i could maybe copy it into my sources for my testsuite but not sure if there is some sort of license thing or something that might be bad or something. I mean tbh i dont really understand open source licenses even though gccrs is a toy its under the gplv3 does that mean i could copy your testsuite or not. Anyways i am really excited about rust i hope to find some way i can contribute back thanks. --Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Fri Oct 25 13:35:11 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri, 25 Oct 2013 13:35:11 -0700 Subject: [rust-dev] Rust testsuite In-Reply-To: References: Message-ID: Great! I'm not a licensing expert either, but the Rust testsuite (like the rest of the compiler) is licensed under the following terms: // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 or the MIT license // , at your // option. This file may not be copied, modified, or distributed // except according to those terms. I think if you read through that, as well as the COPYRIGHT file, it should tell you whether it's ok to bundle the test suite in a GPL program. In the worst case, you could just make a new git repository with *just* the Rust testsuite (licensed under our license) and make it a git submodule of your compiler. Cheers, Tim On Fri, Oct 25, 2013 at 1:30 PM, Philip Herron wrote: > Hey all, > > I stumbled across rust at pycon ie 2013 and i've been hooked on learning > more about it since. And so i thought i would give a go at writing a > compiler for it so i've got: > > https://github.com/redbrain/gccrs > > Its a rust front-end to GCC and it compiles hello-world so far after about a > week and a bit of development. I think its a fun exercise i think rust would > target well on gcc. But anyways i was wondering the testsuite i was hoping i > could maybe copy it into my sources for my testsuite but not sure if there > is some sort of license thing or something that might be bad or something. > > I mean tbh i dont really understand open source licenses even though gccrs > is a toy its under the gplv3 does that mean i could copy your testsuite or > not. > > Anyways i am really excited about rust i hope to find some way i can > contribute back thanks. > > --Phil > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 From banderson at mozilla.com Fri Oct 25 14:15:01 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 25 Oct 2013 14:15:01 -0700 Subject: [rust-dev] Rust testsuite In-Reply-To: References: Message-ID: <526ADF55.40701@mozilla.com> On 10/25/2013 01:30 PM, Philip Herron wrote: > Hey all, > > I stumbled across rust at pycon ie 2013 and i've been hooked on > learning more about it since. And so i thought i would give a go at > writing a compiler for it so i've got: > > https://github.com/redbrain/gccrs > > Its a rust front-end to GCC and it compiles hello-world so far after > about a week and a bit of development. I think its a fun exercise i > think rust would target well on gcc. But anyways i was wondering the > testsuite i was hoping i could maybe copy it into my sources for my > testsuite but not sure if there is some sort of license thing or > something that might be bad or something. > Neat project! The license terms of all source files in the Rust tree, including the test suite, allow them to be individually copied, distributed and combined with code of nearly any other license, including all versions of the GPL, as long as the comment block containing the license at the top of each file is preserved. From redbrain at gcc.gnu.org Fri Oct 25 14:20:17 2013 From: redbrain at gcc.gnu.org (Philip Herron) Date: Fri, 25 Oct 2013 22:20:17 +0100 Subject: [rust-dev] Rust testsuite In-Reply-To: <526ADF55.40701@mozilla.com> References: <526ADF55.40701@mozilla.com> Message-ID: Thanks loads for the quick reply. Trying to see where i can try and contribute to rust but i am still learning the language. I hope i can get involved soon. Thanks --Phil On 25 October 2013 22:15, Brian Anderson wrote: > On 10/25/2013 01:30 PM, Philip Herron wrote: > >> Hey all, >> >> I stumbled across rust at pycon ie 2013 and i've been hooked on learning >> more about it since. And so i thought i would give a go at writing a >> compiler for it so i've got: >> >> https://github.com/redbrain/**gccrs >> >> Its a rust front-end to GCC and it compiles hello-world so far after >> about a week and a bit of development. I think its a fun exercise i think >> rust would target well on gcc. But anyways i was wondering the testsuite i >> was hoping i could maybe copy it into my sources for my testsuite but not >> sure if there is some sort of license thing or something that might be bad >> or something. >> >> > Neat project! The license terms of all source files in the Rust tree, > including the test suite, allow them to be individually copied, distributed > and combined with code of nearly any other license, including all versions > of the GPL, as long as the comment block containing the license at the top > of each file is preserved. > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vu3rdd at gmail.com Sat Oct 26 04:30:09 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sat, 26 Oct 2013 17:00:09 +0530 Subject: [rust-dev] How to use the std::path? Message-ID: Hi, This is my first post to the list. Had been playing with Rust for the past one week and it is very nice so far. I hope this is the list for "users" of Rust as well (as opposed to developers of Rust). I apologise if it is the wrong place to ask newbie questions.. I am trying to follow the documentation on std::path and am trying to create a path, just like it is described in the documentation: use std::path; fn main() { let mut path = Path::new("/tmp/path"); } When I compile, I get this error: $ rustc path.rs path.rs:4:19: 4:28 error: unresolved name `Path::new`. path.rs:4 let mut path = Path::new("/tmp/path"); ^~~~~~~~~ error: aborting due to previous error I tried to use std::Path as well but that gives me the same error message. FYI, this is rust 0.8 compiled from source. Any help to move forward will be greatly appreciated. Thanks. -- Ramakrishnan From vu3rdd at gmail.com Sat Oct 26 05:59:57 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sat, 26 Oct 2013 18:29:57 +0530 Subject: [rust-dev] How to use the std::path? In-Reply-To: References: Message-ID: On Sat, Oct 26, 2013 at 5:00 PM, Ramakrishnan Muthukrishnan wrote: > Hi, > > This is my first post to the list. Had been playing with Rust for the > past one week and it is very nice so far. I hope this is the list for > "users" of Rust as well (as opposed to developers of Rust). I > apologise if it is the wrong place to ask newbie questions.. > > I am trying to follow the documentation on std::path and am trying to > create a path, just like it is described in the documentation: > > > > use std::path; > > fn main() { > let mut path = Path::new("/tmp/path"); > } Okay, I could move on by doing: let mut path = Path("/tmp/path"); I also should have been looking at the manual for 0.8 version instead of master, as I am running 0.8. Thanks Ramakrishnan From bjzaba at yahoo.com.au Sat Oct 26 07:58:09 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Sun, 27 Oct 2013 01:58:09 +1100 Subject: [rust-dev] How to use the std::path? In-Reply-To: References: Message-ID: <3E11D6E0-2CAE-4593-AA4B-BBBFBA8D2E3F@yahoo.com.au> Using master is highly recommended. Treat the 0.* releases as snapshots as opposed to stable releases. ~Brendan On 26/10/2013, at 11:59 PM, Ramakrishnan Muthukrishnan wrote: > On Sat, Oct 26, 2013 at 5:00 PM, Ramakrishnan Muthukrishnan > wrote: >> Hi, >> >> This is my first post to the list. Had been playing with Rust for the >> past one week and it is very nice so far. I hope this is the list for >> "users" of Rust as well (as opposed to developers of Rust). I >> apologise if it is the wrong place to ask newbie questions.. >> >> I am trying to follow the documentation on std::path and am trying to >> create a path, just like it is described in the documentation: >> >> >> >> use std::path; >> >> fn main() { >> let mut path = Path::new("/tmp/path"); >> } > > Okay, I could move on by doing: > > let mut path = Path("/tmp/path"); > > I also should have been looking at the manual for 0.8 version instead > of master, as I am running 0.8. > > Thanks > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From clonejo at clnj.de Sat Oct 26 05:16:52 2013 From: clonejo at clnj.de (clonejo) Date: Sat, 26 Oct 2013 14:16:52 +0200 Subject: [rust-dev] How to use the std::path? In-Reply-To: References: Message-ID: <156664ba-d3ac-4c9c-8fda-0d9c6ab50b05@email.android.com> It seems you never told the compiler that the Path struct is to be found in the path module. So either import the Path struct ("use std::path::Path;") or call "path::Path::new(?)". Regards, clonejo Ramakrishnan Muthukrishnan schrieb: >Hi, > >This is my first post to the list. Had been playing with Rust for the >past one week and it is very nice so far. I hope this is the list for >"users" of Rust as well (as opposed to developers of Rust). I >apologise if it is the wrong place to ask newbie questions.. > >I am trying to follow the documentation on std::path and am trying to >create a path, just like it is described in the documentation: > > > >use std::path; > >fn main() { > let mut path = Path::new("/tmp/path"); >} > >When I compile, I get this error: > >$ rustc path.rs >path.rs:4:19: 4:28 error: unresolved name `Path::new`. >path.rs:4 let mut path = Path::new("/tmp/path"); > ^~~~~~~~~ >error: aborting due to previous error > >I tried to use std::Path as well but that gives me the same error >message. > >FYI, this is rust 0.8 compiled from source. Any help to move forward >will be greatly appreciated. Thanks. > >-- > Ramakrishnan >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sat Oct 26 11:00:36 2013 From: corey at octayn.net (Corey Richardson) Date: Sat, 26 Oct 2013 14:00:36 -0400 Subject: [rust-dev] How to use the std::path? In-Reply-To: <156664ba-d3ac-4c9c-8fda-0d9c6ab50b05@email.android.com> References: <156664ba-d3ac-4c9c-8fda-0d9c6ab50b05@email.android.com> Message-ID: Nope. Path is in the prelude. The problem is he is using 0.8, which didn't have `Path::new`. On Sat, Oct 26, 2013 at 8:16 AM, clonejo wrote: > It seems you never told the compiler that the Path struct is to be found in > the path module. > > So either import the Path struct ("use std::path::Path;") or call > "path::Path::new(?)". > > Regards, clonejo > > > > Ramakrishnan Muthukrishnan schrieb: >> >> Hi, >> >> This is my first post to the list. Had been playing with Rust for the >> past one week and it is very nice so far. I hope this is the list for >> "users" of Rust as well (as opposed to developers of Rust). I >> apologise if it is the wrong place to ask newbie questions.. >> >> I am trying to follow the documentation on std::path and am trying to >> create a path, just like it is described in the documentation: >> >> >> >> use std::path; >> >> fn main() { >> let mut path = Path::new("/tmp/path"); >> } >> >> When I compile, I get this error: >> >> $ rustc path.rs >> path.rs:4:19: 4:28 error: unresolved name `Path::new`. >> path.rs:4 let mut path = Path::new("/tmp/path"); >> ^~~~~ >> ~~~~ >> error: aborting due to previous error >> >> I tried to use std::Path as well but that gives me the same error message. >> >> FYI, this is rust 0.8 compiled from source. Any help to move forward >> will be greatly appreciated. Thanks. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From oren at ben-kiki.org Sat Oct 26 12:16:31 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 26 Oct 2013 22:16:31 +0300 Subject: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation In-Reply-To: <20131025160524.GE2395@Mr-Bennet> References: <20131025160524.GE2395@Mr-Bennet> Message-ID: This is a good summary of the situation. There's one more twist to it though; I not only want both ownership and aliasing, I also want send-ability. That is, it should be possible to send the whole arena to another task. I think this rules out option 1 (though I don't know enough about lifetimes to be sure). It leaves option 2 on the table, though. The main problem with option 2 is that if one borrows a mutable pointer to `root.poolOfSomeObjects[someIndex]` then the whole `root` is now considered to be borrowed-as-mutable, disallowing borrowing a mutable pointer to `root.poolOfOtherObjects[otherIndex]`. I'm tempted to say that the type system "should" be smart enough to allow this, but I'm not 100% certain it is actually safe to do so without some run-time support. For now I am going with (3) which is using an UnsafePtr struct and scary comments :-( On Fri, Oct 25, 2013 at 7:05 PM, Niko Matsakis wrote: > On Mon, Sep 30, 2013 at 08:10:45PM +0300, Oren Ben-Kiki wrote: > > That's good! But there remains the fact that there's no way to say "my > > lifetime is the same as the struct that contains me". If 'self > specialness > > goes away, perhaps it can be re-introduced to mean that (or a different > > name can be given to it). > > So, I have had this thread on a "must read" list of e-mails for a while, > but didn't get around to it until just now. Sorry about that. > > It is true that there is no way to have a lifetime that means "as long > as the current struct" -- at least not in a type definition. The > reason for this is that this is not a well-defined thing; structs can > be moved, for example. The only place you can get a lifetime like that > is in a method: > > fn foo<'a>(&'a mut self, ...) > > Here, 'a is the lifetime you are looking for (the current lifetime of > the struct itself). > > We do have a way to express the notion of memory that moves with a > struct and is freed when the struct is freed: ownership. That's what a > `~` pointer is for. But of course the `~` pointer is designed for > recursive ownership and transfers and thus prevents aliasing, which > may not be what you need. > > Sometimes you want ownership and aliasability: basically you want to > be able to create a subcomponent tied to a struct that will never > itself be "moved out" of the struct into some other container. You can > imagine doing this by having an arena that moves with the struct, and > pointers that live as long as that arena. I had originally hoped to > support this (that was indeed the origin of the 'self name) but it's > quite complex to do so; that lifetime is a kind of "existential" > lifetime and we don't really have a good way to capture it. > > In the meantime, you have two options: > > 1. Parameterize the struct with a lifetime, and have it contain the > arena that way. This technique works when there is ultimately some > master stack frame that the struct will not outlive; this master > frame owns the arena, and the struct just borrows it. You can see > an example in this (yet to be landed) code. [1] > > 2. Have the struct own a vector or other data structure, and replace > pointers with indices. This works best when the struct will be > moved around. You can see an example in this Graph data > structure. [2] > > While I know that neither technique feels perfect, they are quite > workable, and I have used both with much rejoicing. > > > > Niko > > [1] https://gist.github.com/nikomatsakis/7157110 > [2] > https://github.com/mozilla/rust/blob/master/src/librustc/middle/graph.rs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redbrain at gcc.gnu.org Sat Oct 26 15:03:57 2013 From: redbrain at gcc.gnu.org (Philip Herron) Date: Sat, 26 Oct 2013 23:03:57 +0100 Subject: [rust-dev] rust issue 9382 Message-ID: Hey I started looking around and working on https://github.com/mozilla/rust/issues/9382 And the crash is: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Users/redbrain/workspace/rust/src/llvm/lib/IR/Instructions.cpp, line 281. Program received signal SIGABRT, Aborted. [Switching to process 83206 thread 0x1203] 0x00007fff8780a212 in __pthread_kill () This is an ice in the llvm side of things from the backtrace. Just wondering the llvm code base that is pulled in on ./configure is that the official llvm or a rust maintained version. If so is it someting to look at fixing the error on the llvm side or the compiler side to gen different code maybe. --Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sat Oct 26 15:07:10 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sat, 26 Oct 2013 18:07:10 -0400 Subject: [rust-dev] rust issue 9382 In-Reply-To: References: Message-ID: On Sat, Oct 26, 2013 at 6:03 PM, Philip Herron wrote: > Hey > > I started looking around and working on > https://github.com/mozilla/rust/issues/9382 > > And the crash is: > > Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == > Args[i]->getType()) && "Calling a function with a bad signature!"), > function init, file > /Users/redbrain/workspace/rust/src/llvm/lib/IR/Instructions.cpp, line 281. > > Program received signal SIGABRT, Aborted. > [Switching to process 83206 thread 0x1203] > 0x00007fff8780a212 in __pthread_kill () > > This is an ice in the llvm side of things from the backtrace. Just > wondering the llvm code base that is pulled in on ./configure is that the > official llvm or a rust maintained version. If so is it someting to look at > fixing the error on the llvm side or the compiler side to gen different > code maybe. > > --Phil > LLVM makes heavy use of assertions to enforce the invariants the caller of the API is supposed to guarantee. In all likelihood this is a bug in the Rust frontend, where it is generating an invalid call instruction. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Sat Oct 26 21:35:26 2013 From: kevin at sb.org (Kevin Ballard) Date: Sat, 26 Oct 2013 21:35:26 -0700 Subject: [rust-dev] How to use the std::path? In-Reply-To: References: Message-ID: <9955D2BC-673B-49CC-91CA-509888AB86AC@sb.org> The path module was rewritten in between 0.8 and master. The documentation you are looking at only applies to master. I would strongly encourage you to upgrade. Anyway, as long as you're using 0.8, the correct documentation is http://static.rust-lang.org/doc/0.8/std/path/index.html. -Kevin On Oct 26, 2013, at 4:30 AM, Ramakrishnan Muthukrishnan wrote: > Hi, > > This is my first post to the list. Had been playing with Rust for the > past one week and it is very nice so far. I hope this is the list for > "users" of Rust as well (as opposed to developers of Rust). I > apologise if it is the wrong place to ask newbie questions.. > > I am trying to follow the documentation on std::path and am trying to > create a path, just like it is described in the documentation: > > > > use std::path; > > fn main() { > let mut path = Path::new("/tmp/path"); > } > > When I compile, I get this error: > > $ rustc path.rs > path.rs:4:19: 4:28 error: unresolved name `Path::new`. > path.rs:4 let mut path = Path::new("/tmp/path"); > ^~~~~~~~~ > error: aborting due to previous error > > I tried to use std::Path as well but that gives me the same error message. > > FYI, this is rust 0.8 compiled from source. Any help to move forward > will be greatly appreciated. Thanks. > > -- > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From vu3rdd at gmail.com Sat Oct 26 23:16:27 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sun, 27 Oct 2013 11:46:27 +0530 Subject: [rust-dev] How to use the std::path? In-Reply-To: <9955D2BC-673B-49CC-91CA-509888AB86AC@sb.org> References: <9955D2BC-673B-49CC-91CA-509888AB86AC@sb.org> Message-ID: On Sun, Oct 27, 2013 at 10:05 AM, Kevin Ballard wrote: > The path module was rewritten in between 0.8 and master. The documentation you are looking at only applies to master. I would strongly encourage you to upgrade. > > Anyway, as long as you're using 0.8, the correct documentation is http://static.rust-lang.org/doc/0.8/std/path/index.html. Thanks Kevin. I am moving to master right now and hope to track master and its docs while writing new code. Ramakrishnan From vu3rdd at gmail.com Sun Oct 27 05:15:59 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sun, 27 Oct 2013 17:45:59 +0530 Subject: [rust-dev] return type of closure Message-ID: I am having a hard time trying to figure out what is going on here. fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { match n { 0 => &|x| { x }, _ => &|x| { f(x) }, _ => &|x| { let nf = ntimes(f, n - 1); nf(f(x)) }, } } fn double(a: int) -> int { a * 2 } fn main() { let quadruple = ntimes(double, 2); println(format!("quad = {:d}", quadruple(2))); } When I compile it, I get this error message: $ rustc --version rustc 0.9-pre (950add4 2013-10-26 02:16:08 -0700) host: x86_64-apple-darwin $ rustc fn1.rs fn1.rs:2:4: 10:5 error: mismatched types: expected `&fn(int) -> int` but found `&&fn(int) -> int` (expected fn but found &-ptr) fn1.rs:2 match n { fn1.rs:3 0 => &|x| { x }, fn1.rs:4 _ => &|x| { f(x) }, fn1.rs:5 _ => &|x| fn1.rs:6 { fn1.rs:7 let nf = ntimes(f, n - 1); ... error: aborting due to previous error task '' failed at 'explicit failure', /Users/rkrishnan/src/rust/src/libsyntax/diagnostic.rs:101 task '' failed at 'explicit failure', /Users/rkrishnan/src/rust/src/librustc/rustc.rs:396 Can someone help me understand what is going on here? I tried omitting the return type of ntimes and let compiler try to infer the type. The only change is in the first line of the code omitting the return type of ntimes. But I then get an error about quadruple function. It says that quadruple is a void. Thanks. -- Ramakrishnan From oren at ben-kiki.org Sun Oct 27 05:42:06 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sun, 27 Oct 2013 14:42:06 +0200 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: Off the top of my head, I'd take out the "&" in front of the "|x|" everywhere, it seems like you are borrowing a pointer out of something that is already a borrowed pointer to a function (expected &, found &&, you have one & too many, right? :-). On Sun, Oct 27, 2013 at 2:15 PM, Ramakrishnan Muthukrishnan < vu3rdd at gmail.com> wrote: > I am having a hard time trying to figure out what is going on here. > > fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { > match n { > 0 => &|x| { x }, > _ => &|x| { f(x) }, > _ => &|x| > { > let nf = ntimes(f, n - 1); > nf(f(x)) > }, > } > } > > fn double(a: int) -> int { > a * 2 > } > > fn main() { > let quadruple = ntimes(double, 2); > println(format!("quad = {:d}", quadruple(2))); > } > > When I compile it, I get this error message: > > $ rustc --version > rustc 0.9-pre (950add4 2013-10-26 02:16:08 -0700) > host: x86_64-apple-darwin > > $ rustc fn1.rs > fn1.rs:2:4: 10:5 error: mismatched types: expected > `&fn(int) -> int` but found `&&fn(int) -> int` > (expected fn but found &-ptr) > fn1.rs:2 match n { > fn1.rs:3 0 => &|x| { x }, > fn1.rs:4 _ => &|x| { f(x) }, > fn1.rs:5 _ => &|x| > fn1.rs:6 { > fn1.rs:7 let nf = ntimes(f, n - 1); > ... > error: aborting due to previous error > task '' failed at 'explicit failure', > /Users/rkrishnan/src/rust/src/libsyntax/diagnostic.rs:101 > task '' failed at 'explicit failure', > /Users/rkrishnan/src/rust/src/librustc/rustc.rs:396 > > Can someone help me understand what is going on here? I tried omitting > the return type of ntimes and let compiler try to infer the type. The > only change is in the first line of the code omitting the return type > of ntimes. But I then get an error about quadruple function. It says > that quadruple is a void. > > Thanks. > -- > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vu3rdd at gmail.com Sun Oct 27 09:04:20 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sun, 27 Oct 2013 21:34:20 +0530 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: On Sun, Oct 27, 2013 at 6:12 PM, Oren Ben-Kiki wrote: > Off the top of my head, I'd take out the "&" in front of the "|x|" > everywhere, it seems like you are borrowing a pointer out of something that > is already a borrowed pointer to a function (expected &, found &&, you have > one & too many, right? :-). Yes, I had tried that too but get "cannot infer an appropriate lifetime due to conflicting requirements" errors. Is there some way to fix that? Ramakrishnan From oren at ben-kiki.org Sun Oct 27 09:05:55 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sun, 27 Oct 2013 18:05:55 +0200 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: You got me there... On Sun, Oct 27, 2013 at 6:04 PM, Ramakrishnan Muthukrishnan < vu3rdd at gmail.com> wrote: > On Sun, Oct 27, 2013 at 6:12 PM, Oren Ben-Kiki wrote: > > Off the top of my head, I'd take out the "&" in front of the "|x|" > > everywhere, it seems like you are borrowing a pointer out of something > that > > is already a borrowed pointer to a function (expected &, found &&, you > have > > one & too many, right? :-). > > Yes, I had tried that too but get "cannot infer an appropriate > lifetime due to conflicting requirements" errors. Is there some way to > fix that? > > Ramakrishnan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Sun Oct 27 09:41:34 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 27 Oct 2013 09:41:34 -0700 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: <526D423E.4070108@mozilla.com> On 10/27/13 5:15 AM, Ramakrishnan Muthukrishnan wrote: > I am having a hard time trying to figure out what is going on here. > > fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { > match n { > 0 => &|x| { x }, > _ => &|x| { f(x) }, > _ => &|x| > { > let nf = ntimes(f, n - 1); > nf(f(x)) > }, > } > } The compiler is actually (admittedly obliquely) telling you about a memory safety problem. Consider this line: > _ => &|x| { f(x) }, Here you're referring to the outer variable (argument in this case) `f`. But by the time the closure is invoked, `f` won't exist, because the activation record for the `ntimes` function won't exist anymore. It's the same problem that occurs when you return a pointer to an argument in C. In Rust the lifetime system prevents such errors, and that's what you're seeing. Other languages get around this by moving `f` to a garbage collected box implicitly, but that's contrary to the design of Rust, which has no GC unless you explicitly opt in. From the code snippet I'm not sure exactly what you're trying to do, so I don't know the most idiomatic way to solve this. Patrick From vu3rdd at gmail.com Sun Oct 27 10:00:19 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Sun, 27 Oct 2013 22:30:19 +0530 Subject: [rust-dev] return type of closure In-Reply-To: <526D423E.4070108@mozilla.com> References: <526D423E.4070108@mozilla.com> Message-ID: On Sun, Oct 27, 2013 at 10:11 PM, Patrick Walton wrote: > On 10/27/13 5:15 AM, Ramakrishnan Muthukrishnan wrote: >> >> I am having a hard time trying to figure out what is going on here. >> >> fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { >> match n { >> 0 => &|x| { x }, >> _ => &|x| { f(x) }, >> _ => &|x| >> { >> let nf = ntimes(f, n - 1); >> nf(f(x)) >> }, >> } >> } > > > The compiler is actually (admittedly obliquely) telling you about a memory > safety problem. Consider this line: > > >> _ => &|x| { f(x) }, The '_' is a bug there, which creeped in while I was fiddling with it. Sorry about that. This is the function I am looking at: fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { match n { 0 => &|x| { x }, _ => &|x| { let nf = ntimes(f, n - 1); nf(f(x)) }, } } > Here you're referring to the outer variable (argument in this case) `f`. But > by the time the closure is invoked, `f` won't exist, because the activation > record for the `ntimes` function won't exist anymore. It's the same problem > that occurs when you return a pointer to an argument in C. In Rust the > lifetime system prevents such errors, and that's what you're seeing. Very very nice! Thank you. I now understand what is going on. > Other languages get around this by moving `f` to a garbage collected box > implicitly, but that's contrary to the design of Rust, which has no GC > unless you explicitly opt in. > > From the code snippet I'm not sure exactly what you're trying to do, so I > don't know the most idiomatic way to solve this. `ntimes' is trying to return a closure which when invoked with an integer argument x will will apply the function f, n times on it. Does that explain it better? Thanks again. I had been reading your web pages to understand a lot of design decisions behind Rust. Thanks. :) -- Ramakrishnan From steven099 at gmail.com Sun Oct 27 11:32:19 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Sun, 27 Oct 2013 14:32:19 -0400 Subject: [rust-dev] return type of closure In-Reply-To: References: <526D423E.4070108@mozilla.com> Message-ID: This is the closest I've been able to get. Note that it doesn't accept stack closures. This is because ~fn doesn't seem to want to accept non-static lifetime bounds, and potentially other issues with aliasing stack closures. The closure story in Rust is supposed to be changing at some point, though, so I don't know what this will eventually look like. """ use std::util::id; fn ntimes(f: extern "Rust" fn(int) -> int, n: int) -> ~fn:(int) -> int { match n { 0 => do id::<~fn:(int) -> int> |x| { x }, _ => do id::<~fn:(int) -> int> |x| { let nf = ntimes(f, n - 1); nf(f(x)) }, } } fn double(a: int) -> int { a * 2 } fn main() { let quadruple = ntimes(double, 2); println(format!("quad = {:d}", quadruple(2))); } """ On Sun, Oct 27, 2013 at 1:00 PM, Ramakrishnan Muthukrishnan < vu3rdd at gmail.com> wrote: > On Sun, Oct 27, 2013 at 10:11 PM, Patrick Walton > wrote: > > On 10/27/13 5:15 AM, Ramakrishnan Muthukrishnan wrote: > >> > >> I am having a hard time trying to figure out what is going on here. > >> > >> fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { > >> match n { > >> 0 => &|x| { x }, > >> _ => &|x| { f(x) }, > >> _ => &|x| > >> { > >> let nf = ntimes(f, n - 1); > >> nf(f(x)) > >> }, > >> } > >> } > > > > > > The compiler is actually (admittedly obliquely) telling you about a > memory > > safety problem. Consider this line: > > > > > >> _ => &|x| { f(x) }, > > The '_' is a bug there, which creeped in while I was fiddling with it. > Sorry about that. This is the function I am looking at: > > fn ntimes(f: &fn(int) -> int, n: int) -> &fn(int) -> int { > match n { > 0 => &|x| { x }, > _ => &|x| > { > let nf = ntimes(f, n - 1); > nf(f(x)) > }, > } > } > > > Here you're referring to the outer variable (argument in this case) `f`. > But > > by the time the closure is invoked, `f` won't exist, because the > activation > > record for the `ntimes` function won't exist anymore. It's the same > problem > > that occurs when you return a pointer to an argument in C. In Rust the > > lifetime system prevents such errors, and that's what you're seeing. > > Very very nice! Thank you. I now understand what is going on. > > > Other languages get around this by moving `f` to a garbage collected box > > implicitly, but that's contrary to the design of Rust, which has no GC > > unless you explicitly opt in. > > > > From the code snippet I'm not sure exactly what you're trying to do, so I > > don't know the most idiomatic way to solve this. > > `ntimes' is trying to return a closure which when invoked with an > integer argument x will will apply the function f, n times on it. Does > that explain it better? > > Thanks again. I had been reading your web pages to understand a lot of > design decisions behind Rust. Thanks. :) > > -- > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jruderman at gmail.com Sun Oct 27 23:11:23 2013 From: jruderman at gmail.com (Jesse Ruderman) Date: Sun, 27 Oct 2013 23:11:23 -0700 Subject: [rust-dev] return type of closure In-Reply-To: <526D423E.4070108@mozilla.com> References: <526D423E.4070108@mozilla.com> Message-ID: On Sun, Oct 27, 2013 at 9:41 AM, Patrick Walton wrote: > But > by the time the closure is invoked, `f` won't exist, because the activation > record for the `ntimes` function won't exist anymore. I tried tying the lifetime of `f` to the lifetime of the returned function by making them both &'a..., but that didn't help. From jruderman at gmail.com Sun Oct 27 23:18:00 2013 From: jruderman at gmail.com (Jesse Ruderman) Date: Sun, 27 Oct 2013 23:18:00 -0700 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: If you don't mind changing ntimes to not return a closure: fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { match times { 0u => x, _ => ntimes(|x| f(x), times - 1u, f(x)) } } fn main() { println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); } From vu3rdd at gmail.com Mon Oct 28 01:46:45 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Mon, 28 Oct 2013 14:16:45 +0530 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman wrote: > If you don't mind changing ntimes to not return a closure: > > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { > match times { > 0u => x, > _ => ntimes(|x| f(x), times - 1u, f(x)) > } > } > > fn main() { > println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); > } Thanks. That is very nice. No, I am not particular about returning a closure. I was just trying out some toy programs to learn Rust. It would have been nice to return a closure from `ntimes' though. :( -- Ramakrishnan From remifontan at yahoo.fr Mon Oct 28 02:26:17 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Mon, 28 Oct 2013 22:26:17 +1300 Subject: [rust-dev] num::cast Message-ID: Hi, just checking performance wise, is num::cast() doing a dynamic type cast or a static cast. I'm writing some template code that works on Real and I need sometime to divide T:Real by 2 or compate with 0 or 1. I've been using num::zero() and num::one() so far but how about dividing by 2? should I write something like this: let two = num::one::()+ num::one::(); let res:T = aVariable / two; or would be just as efficient? let res:T = aVariable / num::cast::(2.0); or is there an even better alternative? with rust 0.8. cheers, R?mi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Mon Oct 28 03:12:41 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Mon, 28 Oct 2013 21:12:41 +1100 Subject: [rust-dev] num::cast In-Reply-To: References: Message-ID: Yes, it's a static cast, so llvm should optimise that out. Do note however that the API has changed in 0.9-pre, and num::cast now returns an Option. So your code would be: ~~~ let res: T = aVariable / num::cast(2).unwrap(); ~~~ LLVM should resolve the conditional at statically - I haven't checked though. ~Brendan On 28/10/2013, at 8:26 PM, R?mi Fontan wrote: > Hi, > > just checking performance wise, is num::cast() doing a dynamic type cast or a static cast. > > I'm writing some template code that works on Real and I need sometime to divide T:Real by 2 or compate with 0 or 1. > > I've been using num::zero() and num::one() so far but how about dividing by 2? > > should I write something like this: > > let two = num::one::()+ num::one::(); > let res:T = aVariable / two; > > or would be just as efficient? > let res:T = aVariable / num::cast::(2.0); > > or is there an even better alternative? > > with rust 0.8. > > cheers, > > R?mi > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vu3rdd at gmail.com Mon Oct 28 09:40:00 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Mon, 28 Oct 2013 22:10:00 +0530 Subject: [rust-dev] recursive types Message-ID: Hello rust hackers, In section 8.1.7 of the Rust manual ("Recursive types"), there is an example of a List definition which is recursive. Here I define a very simple arithmetic expression which consists of numbers and add expressions. When I compile it I get errors.. enum Expr { Num(int), Add(@Expr, @Expr), } fn eval(e: Expr) -> int { match e { Num(x) => x, Add(x, y) => eval(x) + eval(y), } } fn main() { println(format!("eval 2 = {:d}", eval(Num(2)))); println(format!("eval 2 + 3 = {:d}", eval(Add(Num(2), Num(3))))); } $ rustc arith.rs arith.rs:4:8: 4:13 error: The managed box syntax may be replaced by a library type, and a garbage collector is not yet implemented. Consider using the `std::rc` module as it performs much better as a reference counting implementation. arith.rs:4 Add(@Expr, @Expr), ^~~~~ arith.rs:4:8: 4:13 note: add #[feature(managed_boxes)] to the crate attributes to enable arith.rs:4 Add(@Expr, @Expr), ^~~~~ arith.rs:4:15: 4:20 error: The managed box syntax may be replaced by a library type, and a garbage collector is not yet implemented. Consider using the `std::rc` module as it performs much better as a reference counting implementation. arith.rs:4 Add(@Expr, @Expr), ^~~~~ arith.rs:4:15: 4:20 note: add #[feature(managed_boxes)] to the crate attributes to enable arith.rs:4 Add(@Expr, @Expr), ^~~~~ error: aborting due to 2 previous errors I am running rust from master. What exactly is the compiler suggesting me to do? How can `std::rc' module help in this situation? TIA -- Ramakrishnan From oren at ben-kiki.org Mon Oct 28 10:52:58 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 28 Oct 2013 19:52:58 +0200 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: I assume the compiler suggests you replace @Expr with Rc (Rc is defined in std::rc). This means you wouldn't be able to create cycles (that is, expressions must form a tree, or at most a DAG), and that there would be the overhead of reference counting when you create new expressions, clone the pointers to them etc.; on the other hand, there wouldn't be any GC involved. On Mon, Oct 28, 2013 at 6:40 PM, Ramakrishnan Muthukrishnan < vu3rdd at gmail.com> wrote: > Hello rust hackers, > > In section 8.1.7 of the Rust manual ("Recursive types"), there is an > example of a List definition which is recursive. Here I define a very > simple arithmetic expression which consists of numbers and add > expressions. When I compile it I get errors.. > > enum Expr > { > Num(int), > Add(@Expr, @Expr), > } > > fn eval(e: Expr) -> int { > match e { > Num(x) => x, > Add(x, y) => eval(x) + eval(y), > } > } > > fn main() { > println(format!("eval 2 = {:d}", eval(Num(2)))); > println(format!("eval 2 + 3 = {:d}", eval(Add(Num(2), Num(3))))); > } > > $ rustc arith.rs > arith.rs:4:8: 4:13 error: The managed box syntax may be replaced by a > library type, and a garbage collector is not yet implemented. Consider > using the `std::rc` module as it performs much better as a reference > counting implementation. > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:8: 4:13 note: add #[feature(managed_boxes)] to the crate > attributes to enable > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:15: 4:20 error: The managed box syntax may be replaced by a > library type, and a garbage collector is not yet implemented. Consider > using the `std::rc` module as it performs much better as a reference > counting implementation. > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:15: 4:20 note: add #[feature(managed_boxes)] to the crate > attributes to enable > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > error: aborting due to 2 previous errors > > I am running rust from master. What exactly is the compiler suggesting > me to do? How can `std::rc' module help in this situation? > > TIA > -- > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Oct 28 11:25:15 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 28 Oct 2013 11:25:15 -0700 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: Yes, Oren is right here. You probably want to be using ~s rather than @s. From oren at ben-kiki.org Mon Oct 28 11:27:41 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 28 Oct 2013 20:27:41 +0200 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: If you use ~Expr instead of @Expr, then the expressions would have to form a tree (A = B + C). If you use Rc, you could build a DAG (A = B + B). With @Expr (if that worked), in principle you could allow for cycles (A = B + A), which is probably not what you want. On Mon, Oct 28, 2013 at 8:25 PM, Steve Klabnik wrote: > Yes, Oren is right here. You probably want to be using ~s rather than @s. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Oct 28 11:29:57 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 28 Oct 2013 14:29:57 -0400 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: On Mon, Oct 28, 2013 at 2:27 PM, Oren Ben-Kiki wrote: > If you use ~Expr instead of @Expr, then the expressions would have to form > a tree (A = B + C). If you use Rc, you could build a DAG (A = B + B). > With @Expr (if that worked), in principle you could allow for cycles (A = B > + A), which is probably not what you want. > You won't actually be able to create cycles with @T unless T is non-Freeze because it's immutable and Rust doesn't use laziness. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Mon Oct 28 12:05:05 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 28 Oct 2013 21:05:05 +0200 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: Right, it would have to be @mut Expr to allow for cycles... and you'd have to really work hard to construct the cycle. At any rate, this isn't what you'd want - very probably just using ~Expr would be enough. On Mon, Oct 28, 2013 at 8:29 PM, Daniel Micay wrote: > On Mon, Oct 28, 2013 at 2:27 PM, Oren Ben-Kiki wrote: > >> If you use ~Expr instead of @Expr, then the expressions would have to >> form a tree (A = B + C). If you use Rc, you could build a DAG (A = B >> + B). With @Expr (if that worked), in principle you could allow for cycles >> (A = B + A), which is probably not what you want. >> > > You won't actually be able to create cycles with @T unless T is non-Freeze > because it's immutable and Rust doesn't use laziness. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Mon Oct 28 12:59:45 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Mon, 28 Oct 2013 15:59:45 -0400 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote: > On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman > > wrote: > > If you don't mind changing ntimes to not return a closure: > > > > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { > > match times { > > 0u => x, > > _ => ntimes(|x| f(x), times - 1u, f(x)) > > } > > } > > > > fn main() { > > println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); > > } > > Thanks. That is very nice. > > No, I am not particular about returning a closure. I was just trying > out some toy programs to learn Rust. > > It would have been nice to return a closure from `ntimes' though. :( You can *create* a closure from ntimes, doing `|x| ntimes(|k| k*2, 2, x)`. The idea is that closures borrow data from the stack, so passing them up the stack is difficult. If you want to use the stack as your datastructure, you have to ensure everything travels down the stack, which you can do by requiring the caller to pass in their own closure accepting your closure as an argument (a syntax extension abstracting over this pattern would be nice so the code doesn't become ungainly). Otherwise, you have to build up your own datastructure to pass up the stack, and then derive a closure from that somehow. Ultimately, if closures become a special case of trait objects, this should be really straightforward to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Mon Oct 28 13:03:17 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Mon, 28 Oct 2013 16:03:17 -0400 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote: > On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman > > wrote: > > If you don't mind changing ntimes to not return a closure: > > > > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { > > match times { > > 0u => x, > > _ => ntimes(|x| f(x), times - 1u, f(x)) > > } > > } > > > > fn main() { > > println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); > > } > > Thanks. That is very nice. > > No, I am not particular about returning a closure. I was just trying > out some toy programs to learn Rust. > > It would have been nice to return a closure from `ntimes' though. :( You can *create* a closure from ntimes, doing `|x| ntimes(|k| k*2, 2, x)`. The idea is that closures borrow data from the stack, so passing them up the stack is difficult. If you want to use the stack as your datastructure, you have to ensure everything travels down the stack, which you can do by requiring the caller to pass in their own closure accepting your closure as an argument (a syntax extension abstracting over this pattern would be nice so the code doesn't become ungainly). Otherwise, you have to build up your own datastructure to pass up the stack, and then derive a closure from that somehow. Ultimately, if closures become a special case of trait objects, this should be really straightforward to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven099 at gmail.com Mon Oct 28 13:06:38 2013 From: steven099 at gmail.com (Steven Blenkinsop) Date: Mon, 28 Oct 2013 16:06:38 -0400 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote: > On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman > > wrote: > > If you don't mind changing ntimes to not return a closure: > > > > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { > > match times { > > 0u => x, > > _ => ntimes(|x| f(x), times - 1u, f(x)) > > } > > } > > > > fn main() { > > println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); > > } > > Thanks. That is very nice. > > No, I am not particular about returning a closure. I was just trying > out some toy programs to learn Rust. > > It would have been nice to return a closure from `ntimes' though. :( You can *create* a closure from ntimes, doing `|x| ntimes(|k| k*2, 2, x)`. The idea is that closures borrow data from the stack, so passing them up the stack is difficult. If you want to use the stack as your datastructure, you have to ensure everything travels down the stack, which you can do by requiring the caller to pass in their own closure accepting your closure as an argument (a syntax extension abstracting over this pattern would be nice so the code doesn't become ungainly). Otherwise, you have to build up your own datastructure to pass up the stack, and then derive a closure from that somehow. Ultimately, if closures become a special case of trait objects, this should be really straightforward to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eperso.mail at gmail.com Mon Oct 28 13:45:01 2013 From: eperso.mail at gmail.com (Guillaume HERVIER) Date: Mon, 28 Oct 2013 21:45:01 +0100 Subject: [rust-dev] Default arguments and keyword arguments In-Reply-To: <5264368E.3030301@gmail.com> References: <5264368E.3030301@gmail.com> Message-ID: <526ECCCD.30703@gmail.com> Hi, Just a mail to inform about updates on "Default arguments and keyword arguments" feature request. Since the creation of the pad, a lot of text has been written on the pad, here is a small summary: - Pros / Cons about the feature (actually, there is more pros than cons) - Indications about feature requirements and other languages implementation - A wild FAQ appears, where you can ask question, or answer the existing - For devs who want to try implementing this feature, there is a section about "dev tips" where you can find some useful informations about specific code locations for arguments parsing / function calling / etc... - A small section appears too, about the changes which could be done on actual libraries/tools Reminder - Pad URL: https://pad.riseup.net/p/hvbg6dQQnEe7 Cordially, Guillaume (aka KokaKiwi) On 10/20/2013 10:01 PM, Guillaume HERVIER wrote: > Hi, > > I was reading an issue on Rust repo about functions default arguments > and keyword arguments, and I saw that it didn't advanced yet. > So, after asking in #rust IRC chan, I decided to create a pad about this > issue to let people talk and arguing about this feature request. > > The goal of this pad is to have a spec to propose, and so, re-opening > the issue. > > The issue URL is: https://github.com/mozilla/rust/issues/6973 > And the pad URL: https://pad.riseup.net/p/hvbg6dQQnEe7 > > Cordially, > Guillaume (aka KokaKiwi) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From corey at octayn.net Mon Oct 28 14:48:43 2013 From: corey at octayn.net (Corey Richardson) Date: Mon, 28 Oct 2013 17:48:43 -0400 Subject: [rust-dev] This Week in Rust Message-ID: Welcome to another issue of *This Week in Rust!* This week marks the addition of some more feature gates, removal of `std::io`, and some feature proposals. # What's cooking on master? 47 PRs were merged this week, and we passed issue number 10000. ## Breaking Changes - Most of the crypto in the stdlib [has been removed](https://github.com/mozilla/rust/pull/9744). - `std::io` [has been removed](https://github.com/mozilla/rust/pull/9901), with corresponding improvements in `std::rt::io`. - The `frame_address` intrinsic [has been removed](https://github.com/mozilla/rust/pull/10040). - `@`-ptrs are [now feature-gated](https://github.com/mozilla/rust/pull/9923), reflecting the fact that they will exist in a very different form once they are finished. - All of the logging that used `fmt` (`debug!` and so forth) [have been transitioned to `format!`](https://github.com/mozilla/rust/pull/10006). - `asm!` [is also featured gated](https://github.com/mozilla/rust/pull/10009). - `sys::log_str` [has moved](https://github.com/mozilla/rust/pull/9937). ## Other changes - The long-awaited addition of `mut` in patterns [has finally happened](https://github.com/mozilla/rust/pull/10026). `let (mut x, y) = (1, 2);` works. - The scheduler now uses [lock free data structures](https://github.com/mozilla/rust/pull/10080), which are supposed to perform much better. - The homing code [now does less work](https://github.com/mozilla/rust/pull/10070), which does one third as many `write`'s. - `stdout` [is now buffered](https://github.com/mozilla/rust/pull/10060). - A [non-libuv event loop](https://github.com/mozilla/rust/pull/10054) has been added. - `std::rand` has seen [more](https://github.com/mozilla/rust/pull/9810) [work](https://github.com/mozilla/rust/pull/10015). - `rustpkg` [now supports arbitrary dependencies](https://github.com/mozilla/rust/pull/9654), such as C libraries. - `mut` is [now allowed on self](https://github.com/mozilla/rust/pull/9989). - Nested comments [are now allowed](https://github.com/mozilla/rust/pull/9936). - `rustpkg` will now [find crates in the current directory], so you can say `rustpkg build` in a source dir and it will build in a workspace. - Some new float intrinsics [have been exposed](https://github.com/mozilla/rust/pull/9986). - `println!` [allocates less](https://github.com/mozilla/rust/pull/9979). ## New contributors - Igor Bukanov - Mark Rowe - Michael Letterle - reedlepee # Announcements etc - There will be a [meetup](http://www.meetup.com/Rust-Bay-Area/events/143439552/) in the San Fransisco Mozilla office. Patrick Walton will be talking about sprocketnes. If you're in the area, you should definitely go! - [rust-ci](http://hiho.io/rust-ci/) has been created, which lets you have travis automatically rebuild and test your repo daily, to reduce language/library breakage. - [rust-mustache](https://github.com/erickt/rust-mustache) and [rust-zmq](https://github.com/erickt/rust-zmq) have been updated for master. - [Short talk about Rust at Scala.IO in Paris (October 25th)](http://www.reddit.com/r/rust/comments/1pdrv6/short_talk_about_rust_at_scalaio_in_paris_october/). - [A Bit of Functional Programming in Rust, or A Misguided First Look at Rust for ML Programmers](http://www.reddit.com/r/rust/comments/1pe2lc/a_bit_of_functional_programming_in_rust_or_a/). - [A draft proposal for single inheritance](http://www.reddit.com/r/rust/comments/1p52tj/a_draft_proposal_for_single_inheritance_in_rust/). - [Iterators yielding mutable references](http://www.reddit.com/r/rust/comments/1p4vnk/iterators_yielding_mutable_references/). - [Servo transitions from libcss to a new CSS library written in Rust](http://www.reddit.com/r/rust/comments/1p4qeh/servo_transitions_from_libcss_to_a_new_css/). - [On stack safety](http://www.reddit.com/r/rust/comments/1owhwi/on_stack_safety/). From cadencemarseille at gmail.com Mon Oct 28 20:00:33 2013 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Mon, 28 Oct 2013 23:00:33 -0400 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: Hi Corey, I just wanted to thank you for the "This Week in Rust" notes. I love reading them and I am sure that I am not the only one who appreciates the effort that you put into each one. Cadence On Mon, Oct 28, 2013 at 5:48 PM, Corey Richardson wrote: > Welcome to another issue of *This Week in Rust!* This week marks the > addition > of some more feature gates, removal of `std::io`, and some feature > proposals. > > # What's cooking on master? > > 47 PRs were merged this week, and we passed issue number 10000. > > ## Breaking Changes > > - Most of the crypto in the stdlib [has been > removed](https://github.com/mozilla/rust/pull/9744). > - `std::io` [has been removed](https://github.com/mozilla/rust/pull/9901), > with corresponding improvements in `std::rt::io`. > - The `frame_address` intrinsic [has been > removed](https://github.com/mozilla/rust/pull/10040). > - `@`-ptrs are [now feature-gated]( > https://github.com/mozilla/rust/pull/9923), > reflecting the fact that they will exist in a very different form once > they > are finished. > - All of the logging that used `fmt` (`debug!` and so forth) [have been > transitioned to `format!`](https://github.com/mozilla/rust/pull/10006). > - `asm!` [is also featured gated]( > https://github.com/mozilla/rust/pull/10009). > - `sys::log_str` [has moved](https://github.com/mozilla/rust/pull/9937). > > ## Other changes > > - The long-awaited addition of `mut` in patterns [has finally > happened](https://github.com/mozilla/rust/pull/10026). `let (mut x, y) > = (1, > 2);` works. > - The scheduler now uses [lock free data > structures](https://github.com/mozilla/rust/pull/10080), which are > supposed > to perform much better. > - The homing code [now does less > work](https://github.com/mozilla/rust/pull/10070), which does one third > as > many `write`'s. > - `stdout` [is now buffered](https://github.com/mozilla/rust/pull/10060). > - A [non-libuv event loop](https://github.com/mozilla/rust/pull/10054) has > been added. > - `std::rand` has seen [more](https://github.com/mozilla/rust/pull/9810) > [work](https://github.com/mozilla/rust/pull/10015). > - `rustpkg` [now supports arbitrary > dependencies](https://github.com/mozilla/rust/pull/9654), such as C > libraries. > - `mut` is [now allowed on self](https://github.com/mozilla/rust/pull/9989 > ). > - Nested comments [are now > allowed](https://github.com/mozilla/rust/pull/9936). > - `rustpkg` will now [find crates in the current directory], so you can say > `rustpkg build` in a source dir and it will build in a workspace. > - Some new float intrinsics [have been > exposed](https://github.com/mozilla/rust/pull/9986). > - `println!` [allocates less](https://github.com/mozilla/rust/pull/9979). > > ## New contributors > > - Igor Bukanov > - Mark Rowe > - Michael Letterle > - reedlepee > > # Announcements etc > > - There will be a > [meetup](http://www.meetup.com/Rust-Bay-Area/events/143439552/) in the > San > Fransisco Mozilla office. Patrick Walton will be talking about > sprocketnes. > If you're in the area, you should definitely go! > - [rust-ci](http://hiho.io/rust-ci/) has been created, which lets you have > travis automatically rebuild and test your repo daily, to reduce > language/library breakage. > - [rust-mustache](https://github.com/erickt/rust-mustache) and > [rust-zmq](https://github.com/erickt/rust-zmq) have been updated for > master. > - [Short talk about Rust at Scala.IO in Paris (October > 25th)]( > http://www.reddit.com/r/rust/comments/1pdrv6/short_talk_about_rust_at_scalaio_in_paris_october/ > ). > - [A Bit of Functional Programming in Rust, or A Misguided First Look at > Rust > for ML > Programmers]( > http://www.reddit.com/r/rust/comments/1pe2lc/a_bit_of_functional_programming_in_rust_or_a/ > ). > - [A draft proposal for single > inheritance]( > http://www.reddit.com/r/rust/comments/1p52tj/a_draft_proposal_for_single_inheritance_in_rust/ > ). > - [Iterators yielding mutable > references]( > http://www.reddit.com/r/rust/comments/1p4vnk/iterators_yielding_mutable_references/ > ). > - [Servo transitions from libcss to a new CSS library written in > Rust]( > http://www.reddit.com/r/rust/comments/1p4qeh/servo_transitions_from_libcss_to_a_new_css/ > ). > - [On stack > safety](http://www.reddit.com/r/rust/comments/1owhwi/on_stack_safety/). > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack at metajack.im Mon Oct 28 20:03:31 2013 From: jack at metajack.im (Jack Moffitt) Date: Mon, 28 Oct 2013 21:03:31 -0600 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: > I just wanted to thank you for the "This Week in Rust" notes. I love > reading them and I am sure that I am not the only one who appreciates the > effort that you put into each one. +1! These are great. They are the easiest way for us on the Servo team to estimate how much work we'll need to do to upgrade. jack. From simon80 at gmail.com Mon Oct 28 22:02:41 2013 From: simon80 at gmail.com (Simon Ruggier) Date: Tue, 29 Oct 2013 01:02:41 -0400 Subject: [rust-dev] Faster communication between tasks Message-ID: Greetings fellow Rustians! First of all, thanks for working on such a great language. I really like the clean syntax, increased safety, separation of data from function definitions, and freedom from having to declare duplicate method prototypes in header files. I've been working on an alternate way to communicate between tasks in Rust, following the same approach as the LMAX Disruptor.[1] I'm hoping to eventually offer a superset of the functionality in the pipes API, and replace them as the default communication mechanism between tasks. Just as with concurrency in general, my main motivation in implementing this is to improve performance. For more information about the disruptor approach, there's a lot of information linked from their home page, in a variety of formats. This is my first major contribution of new functionality to an open-source project, so I didn't want to discuss it in advance until I had a working system to demonstrate. I currently have a very basic proof of concept that achieves almost two orders of magnitude better performance than the pipes API. On my hardware[2], I currently see throughput of about 27 million items per second when synchronizing with a double-checked wait condition protocol between sender and receivers, 80+ million items with no blocking (i.e. busy waiting), and anywhere from 240,000 to 600,000 when using pipes. The LMAX Disruptor library gets up to 110 million items per second on the same hardware (using busy waiting and yielding), so there's definitely still room for significant improvement. I've put the code up on GitHub (I'm using rustc from master).[3] Currently, single and multi-stage pipelines of receivers are supported, while many features are missing, like multiple concurrent senders, multiple concurrent receivers, or mutation of the items as they pass through the pipeline. However, given what I have so far, now is probably the right time to start soliciting feedback and advice. I'm looking for review, suggestions/constructive criticism, and guidance about contributing this to the Rust codebase. Thanks, Simon [1] http://lmax-exchange.github.io/disruptor/ [2] A 2.66GHz Intel P8800 CPU running in a Thinkpad T500 on Linux x86_64 [3] https://github.com/sruggier/rust-disruptor -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Mon Oct 28 22:23:22 2013 From: corey at octayn.net (Corey Richardson) Date: Tue, 29 Oct 2013 01:23:22 -0400 Subject: [rust-dev] More on stack safety Message-ID: I've written up more thoughts on stack safety at http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one objects to it (meeting tomorrow!) or has any better ideas, I'll start implementing it. From bklooste at gmail.com Mon Oct 28 22:37:23 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Tue, 29 Oct 2013 13:37:23 +0800 Subject: [rust-dev] Faster communication between tasks In-Reply-To: References: Message-ID: Hi Simon , You may want to test the througput of tasks first to set a base line. Disruptor is faster but normally runs in a tight loop ( or a yield loop) so pretty much tying up a core ( even when yielding it will run again very soon , its the fact that its always running which makes it very fast as there is no contention /communication ). You cant run 100 tasks like that with real work not just micro benches . While i like there Disruptor approach it doesnt fit well with rust tasks which are more an actor model . ( Well Disruptor is like tasks its just they are much bigger). Anyway Disruptor really rests on the old ringbuffer , take the ring buffer , think about scheduling / sequencing and test so it doesnt set the CPU to 100%.. ( Note there catch up extentions on the ring buffer may or may not be relevant) . Im sure the performance of tasks can be approved have a look at IPC in barrel fish OS . It uses a ring buffer like Disruptor and plays around with cache prefetch to give either low latency or high latency with better throughput ( its simple) .. It can be improved further with non temporal SIMD moves but this is more tricky to do as its the compiler / marsheling the types. Ben On Tue, Oct 29, 2013 at 1:02 PM, Simon Ruggier wrote: > Greetings fellow Rustians! > > First of all, thanks for working on such a great language. I really like > the clean syntax, increased safety, separation of data from function > definitions, and freedom from having to declare duplicate method prototypes > in header files. > > I've been working on an alternate way to communicate between tasks in > Rust, following the same approach as the LMAX Disruptor.[1] I'm hoping to > eventually offer a superset of the functionality in the pipes API, and > replace them as the default communication mechanism between tasks. Just as > with concurrency in general, my main motivation in implementing this is to > improve performance. For more information about the disruptor approach, > there's a lot of information linked from their home page, in a variety of > formats. > > This is my first major contribution of new functionality to an open-source > project, so I didn't want to discuss it in advance until I had a working > system to demonstrate. I currently have a very basic proof of concept that > achieves almost two orders of magnitude better performance than the pipes > API. On my hardware[2], I currently see throughput of about 27 million > items per second when synchronizing with a double-checked wait condition > protocol between sender and receivers, 80+ million items with no blocking > (i.e. busy waiting), and anywhere from 240,000 to 600,000 when using pipes. > The LMAX Disruptor library gets up to 110 million items per second on the > same hardware (using busy waiting and yielding), so there's definitely > still room for significant improvement. > > I've put the code up on GitHub (I'm using rustc from master).[3] > Currently, single and multi-stage pipelines of receivers are supported, > while many features are missing, like multiple concurrent senders, multiple > concurrent receivers, or mutation of the items as they pass through the > pipeline. However, given what I have so far, now is probably the right time > to start soliciting feedback and advice. I'm looking for review, > suggestions/constructive criticism, and guidance about contributing this to > the Rust codebase. > > Thanks, > Simon > > [1] http://lmax-exchange.github.io/disruptor/ > [2] A 2.66GHz Intel P8800 CPU running in a Thinkpad T500 on Linux x86_64 > [3] https://github.com/sruggier/rust-disruptor > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Oct 29 01:51:01 2013 From: gaetan at xeberon.net (Gaetan) Date: Tue, 29 Oct 2013 09:51:01 +0100 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: +1 I just subscribed yesterday and I really appreciates this overview :) ----- Gaetan 2013/10/29 Jack Moffitt > > I just wanted to thank you for the "This Week in Rust" notes. I love > > reading them and I am sure that I am not the only one who appreciates the > > effort that you put into each one. > > +1! > > These are great. They are the easiest way for us on the Servo team to > estimate how much work we'll need to do to upgrade. > > jack. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vu3rdd at gmail.com Tue Oct 29 02:40:53 2013 From: vu3rdd at gmail.com (Ramakrishnan Muthukrishnan) Date: Tue, 29 Oct 2013 15:10:53 +0530 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: Thanks to everyone who replied. Daniel Micay gave me more ideas on the irc channel about the move semantics. Here is the final program which compiled and worked fine (with borrow/clone) is given below for reference. Additionally I later found Patrick Walton's blog post explaining reference counting and why it is going to be in standard library etc. Very nice stuff, I am learning a lot. :) Thanks. Ramakrishnan use std::rc::Rc; #[deriving(Clone)] enum Expr { Num(int), Add(Rc, Rc), } fn eval(e: Expr) -> int { match e { Num(x) => x, Add(x, y) => { let xx = x.borrow(); let yy = y.borrow(); eval(xx.clone()) + eval(yy.clone()) }, } } fn main() { println(format!("eval 2 = {:d}", eval(Num(2)))); println(format!("eval 2 + 3 = {:d}", eval(Add(Rc::new(Num(2)), Rc::new(Num(3)))))); } On Tue, Oct 29, 2013 at 12:35 AM, Oren Ben-Kiki wrote: > Right, it would have to be @mut Expr to allow for cycles... and you'd have > to really work hard to construct the cycle. At any rate, this isn't what > you'd want - very probably just using ~Expr would be enough. > > > On Mon, Oct 28, 2013 at 8:29 PM, Daniel Micay wrote: >> >> On Mon, Oct 28, 2013 at 2:27 PM, Oren Ben-Kiki wrote: >>> >>> If you use ~Expr instead of @Expr, then the expressions would have to >>> form a tree (A = B + C). If you use Rc, you could build a DAG (A = B + >>> B). With @Expr (if that worked), in principle you could allow for cycles (A >>> = B + A), which is probably not what you want. >> >> >> You won't actually be able to create cycles with @T unless T is non-Freeze >> because it's immutable and Rust doesn't use laziness. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Ramakrishnan From bjzaba at yahoo.com.au Tue Oct 29 02:54:54 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Tue, 29 Oct 2013 20:54:54 +1100 Subject: [rust-dev] num::cast In-Reply-To: References: Message-ID: <73316B8E-4E61-4B37-A212-65B76164B716@yahoo.com.au> You can use the `--emit-llvm` flag with rustc to check out the IR. To increase the optimisation amount, you can use `--opt-level LEVEL`, or just `-O` for an optimisation level of 2. ~Brendan On 29/10/2013, at 6:00 AM, R?mi Fontan wrote: > Thanks. > > I hope that llvm its capable optimizing the code,I wouldn't want an option struct to be created each time I call this function. > > What would be the way to verify that llvm did the job correctly? > > Cheers > > Remi > > On Oct 28, 2013 11:12 PM, "Brendan Zabarauskas" wrote: > Yes, it's a static cast, so llvm should optimise that out. > > Do note however that the API has changed in 0.9-pre, and num::cast now returns an Option. So your code would be: > > ~~~ > let res: T = aVariable / num::cast(2).unwrap(); > ~~~ > > LLVM should resolve the conditional at statically - I haven't checked though. > > ~Brendan > > On 28/10/2013, at 8:26 PM, R?mi Fontan wrote: > >> Hi, >> >> just checking performance wise, is num::cast() doing a dynamic type cast or a static cast. >> >> I'm writing some template code that works on Real and I need sometime to divide T:Real by 2 or compate with 0 or 1. >> >> I've been using num::zero() and num::one() so far but how about dividing by 2? >> >> should I write something like this: >> >> let two = num::one::()+ num::one::(); >> let res:T = aVariable / two; >> >> or would be just as efficient? >> let res:T = aVariable / num::cast::(2.0); >> >> or is there an even better alternative? >> >> with rust 0.8. >> >> cheers, >> >> R?mi >> >> -- >> R?mi Fontan : remifontan at yahoo.fr >> mobile: +64 21 855 351 >> 93 Otaki Street, Miramar 6022 >> Wellington, New Zealand >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Tue Oct 29 03:11:25 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Tue, 29 Oct 2013 12:11:25 +0200 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: Indeed. It is invaluable in helping me decide when to pull a new master and be prepared for what I need to fix in my code. Many thanks for doing this! On Tue, Oct 29, 2013 at 10:51 AM, Gaetan wrote: > +1 I just subscribed yesterday and I really appreciates this overview :) > > ----- > Gaetan > > > > 2013/10/29 Jack Moffitt > >> > I just wanted to thank you for the "This Week in Rust" notes. I love >> > reading them and I am sure that I am not the only one who appreciates >> the >> > effort that you put into each one. >> >> +1! >> >> These are great. They are the easiest way for us on the Servo team to >> estimate how much work we'll need to do to upgrade. >> >> jack. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Tue Oct 29 03:33:44 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 06:33:44 -0400 Subject: [rust-dev] return type of closure In-Reply-To: References: Message-ID: <20131029103344.GB23801@Mr-Bennet> Incidentally, my preferred way to "return a closure" is to use an impl like so: struct ntimes(times: uint, value: T) -> T; impl ntimes { fn call(&mut self) -> Option { if self.times == 0 { None } else { self.times -= 1; Some(self.value.clone()); } } } Now you can "call" it like: let foo = ntimes(3, v); foo.call(); // Some(v) foo.call(); // Some(v) foo.call(); // Some(v) foo.call(); // None Niko On Mon, Oct 28, 2013 at 04:06:38PM -0400, Steven Blenkinsop wrote: > On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote: > > > On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman > > > wrote: > > > If you don't mind changing ntimes to not return a closure: > > > > > > fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { > > > match times { > > > 0u => x, > > > _ => ntimes(|x| f(x), times - 1u, f(x)) > > > } > > > } > > > > > > fn main() { > > > println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); > > > } > > > > Thanks. That is very nice. > > > > No, I am not particular about returning a closure. I was just trying > > out some toy programs to learn Rust. > > > > It would have been nice to return a closure from `ntimes' though. :( > > > You can *create* a closure from ntimes, doing `|x| ntimes(|k| k*2, 2, x)`. > The idea is that closures borrow data from the stack, so passing them up > the stack is difficult. If you want to use the stack as your datastructure, > you have to ensure everything travels down the stack, which you can do by > requiring the caller to pass in their own closure accepting your closure as > an argument (a syntax extension abstracting over this pattern would be nice > so the code doesn't become ungainly). Otherwise, you have to build up your > own datastructure to pass up the stack, and then derive a closure from that > somehow. Ultimately, if closures become a special case of trait objects, > this should be really straightforward to do. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From niko at alum.mit.edu Tue Oct 29 03:37:05 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 06:37:05 -0400 Subject: [rust-dev] recursive types In-Reply-To: References: Message-ID: <20131029103705.GC23801@Mr-Bennet> You may just want to enable the garbage-collection feature gate by adding `#[feature(managed_boxes)];` to the top of the file. We have currently made `@T` types "opt-in" because we expect the syntax to change (as the message notes) and we expect the collector to change from a ref-counting to a tracing collector, which has rather different semantics (e.g., non-deterministic collection points). In other words, we expect programs that use `@T` to require changes in the future as Rust evolves, and we want to alert you to that fact. Niko On Mon, Oct 28, 2013 at 10:10:00PM +0530, Ramakrishnan Muthukrishnan wrote: > Hello rust hackers, > > In section 8.1.7 of the Rust manual ("Recursive types"), there is an > example of a List definition which is recursive. Here I define a very > simple arithmetic expression which consists of numbers and add > expressions. When I compile it I get errors.. > > enum Expr > { > Num(int), > Add(@Expr, @Expr), > } > > fn eval(e: Expr) -> int { > match e { > Num(x) => x, > Add(x, y) => eval(x) + eval(y), > } > } > > fn main() { > println(format!("eval 2 = {:d}", eval(Num(2)))); > println(format!("eval 2 + 3 = {:d}", eval(Add(Num(2), Num(3))))); > } > > $ rustc arith.rs > arith.rs:4:8: 4:13 error: The managed box syntax may be replaced by a > library type, and a garbage collector is not yet implemented. Consider > using the `std::rc` module as it performs much better as a reference > counting implementation. > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:8: 4:13 note: add #[feature(managed_boxes)] to the crate > attributes to enable > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:15: 4:20 error: The managed box syntax may be replaced by a > library type, and a garbage collector is not yet implemented. Consider > using the `std::rc` module as it performs much better as a reference > counting implementation. > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > arith.rs:4:15: 4:20 note: add #[feature(managed_boxes)] to the crate > attributes to enable > arith.rs:4 Add(@Expr, @Expr), > ^~~~~ > error: aborting due to 2 previous errors > > I am running rust from master. What exactly is the compiler suggesting > me to do? How can `std::rc' module help in this situation? > > TIA > -- > Ramakrishnan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From niko at alum.mit.edu Tue Oct 29 04:08:48 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 07:08:48 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: References: Message-ID: <20131029110848.GD23801@Mr-Bennet> If I understand correctly, what you are proposing is to offer fixed size stacks and to use a guard page to check for stack overflow (vs a stack preamble)? My two thoughts are: 1. I do think segmented stacks offer several tangible benefits: - Recursion limited only by available memory / address space - Avoid chewing up address space on 32 bit builds However, I can accept that on balance they are not worth the price, given that point #2 is probably not that important for 64-bit systems. It is sad to lose limitless recursion but typically one can rewrite routines that recurse arbitrarily deep to use a stack on the heap, though sometimes the code is very unnatural, and using a stack on the heap will not play as well with lifetimes, since the compiler doesn't know that you are obeying a stack discipline. 2. I think that our official semantics for stack overflow should be task failure, not abort. There are some technical challenges to be overcome with regard to the best way to signal/detect stack overflow, and I'm fine with this being a "todo" item (possibly for a long time). But abort is wrong. One non-technical difficulty to failing on overflow is how to handle user-defined destructors when there is no stack to run them on -- but I think this is adequately addressed by keeping a red zone (so that simple dtors work) and implementing Graydon's plan for handling recursive failure otherwise. We also have to modify drop glue to not be recursive (see point #1 about the convenience of limitless recursion -- though of course drop glue must be ready for OOM as well). Niko On Tue, Oct 29, 2013 at 01:23:22AM -0400, Corey Richardson wrote: > I've written up more thoughts on stack safety at > http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one > objects to it (meeting tomorrow!) or has any better ideas, I'll start > implementing it. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From bjzaba at yahoo.com.au Tue Oct 29 04:14:13 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Tue, 29 Oct 2013 22:14:13 +1100 Subject: [rust-dev] return type of closure In-Reply-To: <20131029103344.GB23801@Mr-Bennet> References: <20131029103344.GB23801@Mr-Bennet> Message-ID: <6A4CC44F-63A8-4F01-8F1D-6112A8B8C9DE@yahoo.com.au> > struct ntimes(times: uint, value: T) -> T; Does this syntax work at the moment? ~Brendan On 29/10/2013, at 9:33 PM, Niko Matsakis wrote: > Incidentally, my preferred way to "return a closure" is to use > an impl like so: > > struct ntimes(times: uint, value: T) -> T; > impl ntimes { > fn call(&mut self) -> Option { > if self.times == 0 { > None > } else { > self.times -= 1; > Some(self.value.clone()); > } > } > } > > Now you can "call" it like: > > let foo = ntimes(3, v); > foo.call(); // Some(v) > foo.call(); // Some(v) > foo.call(); // Some(v) > foo.call(); // None > > > Niko > > On Mon, Oct 28, 2013 at 04:06:38PM -0400, Steven Blenkinsop wrote: >> On Monday, October 28, 2013, Ramakrishnan Muthukrishnan wrote: >> >>> On Mon, Oct 28, 2013 at 11:48 AM, Jesse Ruderman > >>> wrote: >>>> If you don't mind changing ntimes to not return a closure: >>>> >>>> fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T { >>>> match times { >>>> 0u => x, >>>> _ => ntimes(|x| f(x), times - 1u, f(x)) >>>> } >>>> } >>>> >>>> fn main() { >>>> println(format!("{:d}", ntimes(|k| k*2, 2u, 3))); >>>> } >>> >>> Thanks. That is very nice. >>> >>> No, I am not particular about returning a closure. I was just trying >>> out some toy programs to learn Rust. >>> >>> It would have been nice to return a closure from `ntimes' though. :( >> >> >> You can *create* a closure from ntimes, doing `|x| ntimes(|k| k*2, 2, x)`. >> The idea is that closures borrow data from the stack, so passing them up >> the stack is difficult. If you want to use the stack as your datastructure, >> you have to ensure everything travels down the stack, which you can do by >> requiring the caller to pass in their own closure accepting your closure as >> an argument (a syntax extension abstracting over this pattern would be nice >> so the code doesn't become ungainly). Otherwise, you have to build up your >> own datastructure to pass up the stack, and then derive a closure from that >> somehow. Ultimately, if closures become a special case of trait objects, >> this should be really straightforward to do. > >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Tue Oct 29 07:49:20 2013 From: corey at octayn.net (Corey Richardson) Date: Tue, 29 Oct 2013 10:49:20 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029110848.GD23801@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> Message-ID: On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis wrote: > If I understand correctly, what you are proposing is to offer fixed > size stacks and to use a guard page to check for stack overflow (vs a > stack preamble)? > > My two thoughts are: > > 1. I do think segmented stacks offer several tangible benefits: > > - Recursion limited only by available memory / address space > - Avoid chewing up address space on 32 bit builds > > However, I can accept that on balance they are not worth the price, > given that point #2 is probably not that important for 64-bit systems. > > It is sad to lose limitless recursion but typically one can rewrite > routines that recurse arbitrarily deep to use a stack on the heap, > though sometimes the code is very unnatural, and using a stack on the > heap will not play as well with lifetimes, since the compiler doesn't > know that you are obeying a stack discipline. > I agree. This is why I think fixed-size stacks feel like a step backwards. There's still room to have optional segmented stacks, but it's going to require a lot of extra complexity to do right. > 2. I think that our official semantics for stack overflow should be > task failure, not abort. There are some technical challenges to be > overcome with regard to the best way to signal/detect stack overflow, > and I'm fine with this being a "todo" item (possibly for a long time). > But abort is wrong. > I don't know how to go about doing this, but am open to it. From igor at mir2.org Tue Oct 29 08:21:35 2013 From: igor at mir2.org (Igor Bukanov) Date: Tue, 29 Oct 2013 16:21:35 +0100 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029110848.GD23801@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> Message-ID: On 29 October 2013 12:08, Niko Matsakis wrote: > 1. I do think segmented stacks offer several tangible benefits: > > - Recursion limited only by available memory / address space This is a weak argument. If one needs that much memory, then using an explicit stack is a must as it allows for significantly more compact memory presentation. > > 2. I think that our official semantics for stack overflow should be > task failure, not abort. Just for consideration, SpiderMonkey uses a lot of explicit stack depth checks , see http://mxr.mozilla.org/mozilla-central/ident?i=JS_CHECK_RECURSION&tree=mozilla-central&filter= It would be nice if Rust would allow to avoid them. And if aborting is the only good option for performance reasons then having an API to do those checks manually is a must to have. From niko at alum.mit.edu Tue Oct 29 08:43:25 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 11:43:25 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: References: <20131029110848.GD23801@Mr-Bennet> Message-ID: <20131029154325.GA26949@Mr-Bennet> On Tue, Oct 29, 2013 at 04:21:35PM +0100, Igor Bukanov wrote: > This is a weak argument. If one needs that much memory, then using an > explicit stack is a must as it allows for significantly more compact > memory presentation. I considered this when I wrote the e-mail. I partially agree but not fully. Let me expound some. In general, both segmented stacks and an explicit stack on the heap have the property that if you add more RAM, you can get more work done. I agree that using a stack on the heap offers a better constant factor (that is, a better work-to-RAM ratio), but that may not be the relevant point for all use cases. This debate is not new: we've been considering whether or not to keep segmented stacks for a while. Originally I thought as you do, that one should just not write recursion whose depth is proportional to the input, for fear of overflow. In past compilers I've worked on we tried to obey this rule, since people always managed to surprise us with the complexity of inputs they would provide. But I've been watching the code I write now and I've found that many times a recursion-based solution is much cleaner. Moreover, since we integrate recursion specially with the type system in the form of lifetimes, it can also express things that are more awkward with a heap vector. All that said, probably the most important thing is that we have graceful failure on stack overflow (even an abort is perhaps adequate, though obviously a proper failure is better). This permits users to start with recursion-based code and either convert to heap-based code or allocate bigger stack frames when they start to hit limits. Obviously no one is proposing segfaulting on stack overflow, so I guess I will be satisfied. :) Niko From niko at alum.mit.edu Tue Oct 29 08:55:11 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 11:55:11 -0400 Subject: [rust-dev] return type of closure In-Reply-To: <6A4CC44F-63A8-4F01-8F1D-6112A8B8C9DE@yahoo.com.au> References: <20131029103344.GB23801@Mr-Bennet> <6A4CC44F-63A8-4F01-8F1D-6112A8B8C9DE@yahoo.com.au> Message-ID: <20131029155511.GB2341@Mr-Bennet> On Tue, Oct 29, 2013 at 10:14:13PM +1100, Brendan Zabarauskas wrote: > > struct ntimes(times: uint, value: T) -> T; > > > Does this syntax work at the moment? My mistake, I meant to leave off the `-> T`. It would just be: struct ntimes(times: uint, value: T) -> T; impl ntimes { fn call(&mut self) -> Option { if self.times == 0 { None } else { self.times -= 1; Some(self.value.clone()); } } } Niko From igor at mir2.org Tue Oct 29 08:59:31 2013 From: igor at mir2.org (Igor Bukanov) Date: Tue, 29 Oct 2013 16:59:31 +0100 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029110848.GD23801@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> Message-ID: On 29 October 2013 12:08, Niko Matsakis wrote: > One non-technical difficulty to failing on overflow is how to handle > user-defined destructors when there is no stack to run them on >From C++ experience the need to handle recursion comes from code like parsers or tree-like structure navigation. In such cases the only relevant destructors are those that release heap-allocated memory. This suggests to have a module or function level annotation that states that the code does not run custom destructors. Then the runtime can provide a function like run_with_stack_check_enabled() that runs such destructor-less code while allowing to recover from the stack overflow. Then the only problem would be to properly release all ~temporaries. From igor at mir2.org Tue Oct 29 09:38:41 2013 From: igor at mir2.org (Igor Bukanov) Date: Tue, 29 Oct 2013 17:38:41 +0100 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029154325.GA26949@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> <20131029154325.GA26949@Mr-Bennet> Message-ID: On 29 October 2013 16:43, Niko Matsakis wrote: > But I've been watching the code I write now and I've found that many > times a recursion-based solution is much cleaner. Moreover, since we > integrate recursion specially with the type system in the form of > lifetimes, it can also express things that are more awkward with a > heap vector. My "weak argument" was referring to the recursion that uses tons of memory, not to the idea of using recursion at all. Clearly there are some very practical cases like parsers where total recursion avoidance is not an option if one wants to stay with maintainable code and yet it is desirable to support deeply nested structures. The question is how common those cases to justify a performance impact by default for the rest of code. From the experience I suppose this is rare so it should be fine to require special annotations and/or special setup when calling into such code as long as the stack overflow in general is not worse than an explicit abort. From banderson at mozilla.com Tue Oct 29 12:30:00 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 29 Oct 2013 12:30:00 -0700 Subject: [rust-dev] Faster communication between tasks In-Reply-To: References: Message-ID: <52700CB8.8010706@mozilla.com> On 10/28/2013 10:02 PM, Simon Ruggier wrote: > Greetings fellow Rustians! > > First of all, thanks for working on such a great language. I really > like the clean syntax, increased safety, separation of data from > function definitions, and freedom from having to declare duplicate > method prototypes in header files. > > I've been working on an alternate way to communicate between tasks in > Rust, following the same approach as the LMAX Disruptor.[1] I'm hoping > to eventually offer a superset of the functionality in the pipes API, > and replace them as the default communication mechanism between tasks. > Just as with concurrency in general, my main motivation in > implementing this is to improve performance. For more information > about the disruptor approach, there's a lot of information linked from > their home page, in a variety of formats. This is really exciting work. Thanks for pursuing it. I've been interested in exploring something like Disruptor in Rust. The current channel types in Rust are indeed slow, and fixing them is the topic of https://github.com/mozilla/rust/issues/8568. > > This is my first major contribution of new functionality to an > open-source project, so I didn't want to discuss it in advance until I > had a working system to demonstrate. I currently have a very basic > proof of concept that achieves almost two orders of magnitude better > performance than the pipes API. On my hardware[2], I currently see > throughput of about 27 million items per second when synchronizing > with a double-checked wait condition protocol between sender and > receivers, 80+ million items with no blocking (i.e. busy waiting), and > anywhere from 240,000 to 600,000 when using pipes. The LMAX Disruptor > library gets up to 110 million items per second on the same hardware > (using busy waiting and yielding), so there's definitely still room > for significant improvement. Those are awesome results! > > I've put the code up on GitHub (I'm using rustc from master).[3] > Currently, single and multi-stage pipelines of receivers are > supported, while many features are missing, like multiple concurrent > senders, multiple concurrent receivers, or mutation of the items as > they pass through the pipeline. However, given what I have so far, now > is probably the right time to start soliciting feedback and advice. > I'm looking for review, suggestions/constructive criticism, and > guidance about contributing this to the Rust codebase. I'm not deeply familiar with Disruptor, but I believe that it uses bounded queues. My general feeling thus far is that, as the general 'go-to' channel type, people should not be using bounded queues that block the sender when full because of the potential for unexpected deadlocks. I could be convinced otherwise though if it's just not possible to have reasonably fast unbounded channels. Note that I don't think it's critical for the general-purpose channel to be as fast as possible - it's more important to be convenient. Please keep working on this. I'm excited to see your results. > > Thanks, > Simon > > [1] http://lmax-exchange.github.io/disruptor/ > [2] A 2.66GHz Intel P8800 CPU running in a Thinkpad T500 on Linux x86_64 > [3] https://github.com/sruggier/rust-disruptor > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Oct 29 13:24:49 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 29 Oct 2013 16:24:49 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029110848.GD23801@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> Message-ID: On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis wrote: > If I understand correctly, what you are proposing is to offer fixed > size stacks and to use a guard page to check for stack overflow (vs a > stack preamble)? > > My two thoughts are: > > 1. I do think segmented stacks offer several tangible benefits: > > - Recursion limited only by available memory / address space > - Avoid chewing up address space on 32 bit builds > > However, I can accept that on balance they are not worth the price, > given that point #2 is probably not that important for 64-bit systems. > > It is sad to lose limitless recursion but typically one can rewrite > routines that recurse arbitrarily deep to use a stack on the heap, > though sometimes the code is very unnatural, and using a stack on the > heap will not play as well with lifetimes, since the compiler doesn't > know that you are obeying a stack discipline. > > 2. I think that our official semantics for stack overflow should be > task failure, not abort. There are some technical challenges to be > overcome with regard to the best way to signal/detect stack overflow, > and I'm fine with this being a "todo" item (possibly for a long time). > But abort is wrong. > > One non-technical difficulty to failing on overflow is how to handle > user-defined destructors when there is no stack to run them on -- but > I think this is adequately addressed by keeping a red zone (so that > simple dtors work) and implementing Graydon's plan for handling > recursive failure otherwise. We also have to modify drop glue to not > be recursive (see point #1 about the convenience of limitless > recursion -- though of course drop glue must be ready for OOM as > well). > If we want to unwind on task failure, we'll need to disable the `prune-eh` pass that bubbles up `nounwind` since every function will be able to unwind. I think it will cause a very significant increase in code size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Tue Oct 29 14:50:11 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Tue, 29 Oct 2013 14:50:11 -0700 Subject: [rust-dev] More on stack safety In-Reply-To: References: <20131029110848.GD23801@Mr-Bennet> Message-ID: Stack overflow gets a mention in this article: http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences:) -- Ziad On Tue, Oct 29, 2013 at 1:24 PM, Daniel Micay wrote: > On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis wrote: > >> If I understand correctly, what you are proposing is to offer fixed >> size stacks and to use a guard page to check for stack overflow (vs a >> stack preamble)? >> >> My two thoughts are: >> >> 1. I do think segmented stacks offer several tangible benefits: >> >> - Recursion limited only by available memory / address space >> - Avoid chewing up address space on 32 bit builds >> >> However, I can accept that on balance they are not worth the price, >> given that point #2 is probably not that important for 64-bit systems. >> >> It is sad to lose limitless recursion but typically one can rewrite >> routines that recurse arbitrarily deep to use a stack on the heap, >> though sometimes the code is very unnatural, and using a stack on the >> heap will not play as well with lifetimes, since the compiler doesn't >> know that you are obeying a stack discipline. >> >> 2. I think that our official semantics for stack overflow should be >> task failure, not abort. There are some technical challenges to be >> overcome with regard to the best way to signal/detect stack overflow, >> and I'm fine with this being a "todo" item (possibly for a long time). >> But abort is wrong. >> >> One non-technical difficulty to failing on overflow is how to handle >> user-defined destructors when there is no stack to run them on -- but >> I think this is adequately addressed by keeping a red zone (so that >> simple dtors work) and implementing Graydon's plan for handling >> recursive failure otherwise. We also have to modify drop glue to not >> be recursive (see point #1 about the convenience of limitless >> recursion -- though of course drop glue must be ready for OOM as >> well). >> > > If we want to unwind on task failure, we'll need to disable the `prune-eh` > pass that bubbles up `nounwind` since every function will be able to > unwind. I think it will cause a very significant increase in code size. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Oct 29 15:01:52 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 29 Oct 2013 18:01:52 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: References: <20131029110848.GD23801@Mr-Bennet> Message-ID: I don't think anything but (correct) strict static analysis would have helped in that case. Embedded systems often avoid dynamic memory allocation completely, because dynamic out-of-memory conditions would be unacceptable. That's likely why there was so much data on the stack in the first place. A growable segmented stack is the opposite of robustness, in a case like that. Unwinding on out-of-stack is more robust than aborting, but losing the entire context of a task is often going to be totally unacceptable. If every function call can unwind, it also makes it much harder to write memory-safe low-level code. In a web browser, it's going to be okay for most tasks to unwind. It's not going to be a very viable solution for truly robust embedded systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at mir2.org Tue Oct 29 15:51:10 2013 From: igor at mir2.org (Igor Bukanov) Date: Tue, 29 Oct 2013 23:51:10 +0100 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. Message-ID: SpiderMonkey uses recursive algorithms in quite a few places. As the level of recursion is at mercy of JS code, checking for stack exhaustion is a must. For that the code explicitly compare an address of a local variable with a limit set as a part of thread initialization. If the limit is breached, the code either reports failure to the caller (parser, interpreter, JITed code) or tries to recover using a different algorithm (marking phase of GC). This explicit strategy allowed to archive stack safety with relatively infrequent stack checks compared with the total number of function calls in the code. Granted, without statick analysis this is fragile as missing stack check on a code path that is under control of JS could be potentially exploitable (this is C++ code after all), but it has being working. So I think aborting on stack overflow in Rust should be OK as it removes security implications from a stack overflow bugs. However, it is a must then to provide facilities to check for a low stack. It would also be very useful to have an option to call code with a newly allocated stack of the given size without creating any extra thread etc. This would allow for a pattern like: fn part_of_recursive_parser ... { if stack_low() { call_with_new_stack(10*1024*1024, part_of_recursive_parser) } } Then missing stack_low() becomes just a bug without security implications. From niko at alum.mit.edu Tue Oct 29 17:23:22 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 20:23:22 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: References: <20131029110848.GD23801@Mr-Bennet> Message-ID: <20131030002322.GA31511@Mr-Bennet> On Tue, Oct 29, 2013 at 04:24:49PM -0400, Daniel Micay wrote: > If we want to unwind on task failure, we'll need to disable the `prune-eh` > pass that bubbles up `nounwind` since every function will be able to > unwind. I think it will cause a very significant increase in code size. That's too bad, but safety and sensible error recovery comes first. As pcwalton said, if you have an image decoder that has a bug which leads to infinite recursion, it's just not acceptable for that to crash your *entire process*. That said, I imagine we could recover some code size improvements by having an LLVM pass that (1) identified when function X calls function Y unconditionally; (2) combined the overflow check for X and Y; and then (3) removes exception handling around calls to Y. Obviously this would be more complex. Niko From niko at alum.mit.edu Tue Oct 29 19:17:55 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 29 Oct 2013 22:17:55 -0400 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: References: Message-ID: <20131030021742.GA2264@Mr-Bennet> I certainly like the idea of exposing a "low stack" check to the user so that they can do better recovery. I also like the idea of `call_with_new_stack`. I am not sure if this means that the default recovery should be *abort* vs *task failure* (which is already fairly drastic). But I guess it is a legitimate question: to what extent should we permit safe rust code to bring a system to its knees? We can't truly execute untrusted code, since it could invoke native things or include unsafe blocks, but it'd be nice if we could give some guarantees as to the limits of what safe code can do. Put differently, it'd be nice if tasks could serve as an effective sandbox for *safe code*. It seems to me that the main way that safe code can cause problems for a larger system are (1) allocating too much heap; (2) looping infinitely; and (3) over-recursing. But no doubt there are more. Maybe it doesn't make sense to address only one problem and not the others; on the other hand, we should not let the perfect be the enemy of the good, and perhaps we can find ways to address the others as well (e.g., hard limits on total memory a task can ever allocate; leveraging different O/S threads for pre-emption and killing, etc). Niko On Tue, Oct 29, 2013 at 11:51:10PM +0100, Igor Bukanov wrote: > SpiderMonkey uses recursive algorithms in quite a few places. As the > level of recursion is at mercy of JS code, checking for stack > exhaustion is a must. For that the code explicitly compare an address > of a local variable with a limit set as a part of thread > initialization. If the limit is breached, the code either reports > failure to the caller (parser, interpreter, JITed code) or tries to > recover using a different algorithm (marking phase of GC). > > This explicit strategy allowed to archive stack safety with relatively > infrequent stack checks compared with the total number of function > calls in the code. Granted, without statick analysis this is fragile > as missing stack check on a code path that is under control of JS > could be potentially exploitable (this is C++ code after all), but it > has being working. > > So I think aborting on stack overflow in Rust should be OK as it > removes security implications from a stack overflow bugs. However, it > is a must then to provide facilities to check for a low stack. It > would also be very useful to have an option to call code with a newly > allocated stack of the given size without creating any extra thread > etc. This would allow for a pattern like: > > fn part_of_recursive_parser ... { > if stack_low() { > call_with_new_stack(10*1024*1024, part_of_recursive_parser) > } > } > > Then missing stack_low() becomes just a bug without security implications. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From simon80 at gmail.com Tue Oct 29 21:55:02 2013 From: simon80 at gmail.com (Simon Ruggier) Date: Wed, 30 Oct 2013 00:55:02 -0400 Subject: [rust-dev] Faster communication between tasks In-Reply-To: <52700CB8.8010706@mozilla.com> References: <52700CB8.8010706@mozilla.com> Message-ID: On Tue, Oct 29, 2013 at 3:30 PM, Brian Anderson wrote: > On 10/28/2013 10:02 PM, Simon Ruggier wrote: > > Greetings fellow Rustians! > > First of all, thanks for working on such a great language. I really like > the clean syntax, increased safety, separation of data from function > definitions, and freedom from having to declare duplicate method prototypes > in header files. > > I've been working on an alternate way to communicate between tasks in > Rust, following the same approach as the LMAX Disruptor.[1] I'm hoping to > eventually offer a superset of the functionality in the pipes API, and > replace them as the default communication mechanism between tasks. Just as > with concurrency in general, my main motivation in implementing this is to > improve performance. For more information about the disruptor approach, > there's a lot of information linked from their home page, in a variety of > formats. > > > This is really exciting work. Thanks for pursuing it. I've been interested > in exploring something like Disruptor in Rust. The current channel types in > Rust are indeed slow, and fixing them is the topic of > https://github.com/mozilla/rust/issues/8568. > I'll start paying attention to that. The Morrison & Afek 2013 paper looks like something I should read. > > > This is my first major contribution of new functionality to an open-source > project, so I didn't want to discuss it in advance until I had a working > system to demonstrate. I currently have a very basic proof of concept that > achieves almost two orders of magnitude better performance than the pipes > API. On my hardware[2], I currently see throughput of about 27 million > items per second when synchronizing with a double-checked wait condition > protocol between sender and receivers, 80+ million items with no blocking > (i.e. busy waiting), and anywhere from 240,000 to 600,000 when using pipes. > The LMAX Disruptor library gets up to 110 million items per second on the > same hardware (using busy waiting and yielding), so there's definitely > still room for significant improvement. > > > Those are awesome results! > Thanks! When I first brought it up, it was getting about 14 million with the busy waiting. Minimizing the number of atomic operations (even with relaxed memory ordering) makes a big difference in performance. The 2/3 drop in performance with the blocking wait strategy comes from merely doing a read-modify-write operation on every send (it currently uses atomic swap, I haven't experimented with others yet). To be fair, the only result I can take credit for is the blocking algorithm. The other ideas are straight from the original disruptor. > I've put the code up on GitHub (I'm using rustc from master).[3] > Currently, single and multi-stage pipelines of receivers are supported, > while many features are missing, like multiple concurrent senders, multiple > concurrent receivers, or mutation of the items as they pass through the > pipeline. However, given what I have so far, now is probably the right time > to start soliciting feedback and advice. I'm looking for review, > suggestions/constructive criticism, and guidance about contributing this to > the Rust codebase. > > > I'm not deeply familiar with Disruptor, but I believe that it uses bounded > queues. My general feeling thus far is that, as the general 'go-to' channel > type, people should not be using bounded queues that block the sender when > full because of the potential for unexpected deadlocks. I could be > convinced otherwise though if it's just not possible to have reasonably > fast unbounded channels. Note that I don't think it's critical for the > general-purpose channel to be as fast as possible - it's more important to > be convenient. > Yes, it does. I'm divided on this, because unbounded queues can also lead to memory exhaustion and added latency, but I suspect that for many use cases, you're right. For performance critical code, I think there's probably no argument: if a queue is too large, it starts causing latency problems (like with bufferbloat). A queue that accepts an unlimited number of items is like an API that doesn't let the caller know about errors. The caller needs to know that there's a large queue, and adjust its behaviour. Because of this, I doubt any performance-critical application would find it truly optimal to use unbounded queues. My opinion on this is strongly influenced by this post: http://mechanical-sympathy.blogspot.co.uk/2012/05/apply-back-pressure-when-overloaded.html For general usage, though, I need to do more research. Any application where latency is relevant really should be designed to deal with back-pressure from queues, but there may be some batch job style use cases where, as you say, it isn't worth the extra effort. On the other hand, it's relevant to think about how deadlocks occur, and decide whether or not it's reasonable for developers to expect to be able to do those things. I'll look into this and see what I come up with. If there were some general way to mitigate the deadlock issue within the runtime, it would also solve this problem. As a last resort, I suspect that I could probably figure out a way to have the sender resize the buffer when it fills, copy the elements over, and then switch the consumers over to the larger buffer. I don't know if I could do it without affecting the fast path on the receiver side. Please keep working on this. I'm excited to see your results. > I appreciate the encouragement :) > > Thanks, > Simon > > [1] http://lmax-exchange.github.io/disruptor/ > [2] A 2.66GHz Intel P8800 CPU running in a Thinkpad T500 on Linux x86_64 > [3] https://github.com/sruggier/rust-disruptor > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bklooste at gmail.com Tue Oct 29 22:24:35 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Wed, 30 Oct 2013 13:24:35 +0800 Subject: [rust-dev] Faster communication between tasks In-Reply-To: References: <52700CB8.8010706@mozilla.com> Message-ID: Note pre fetch and non temporal instructions really help with this.. I'm not deeply familiar with Disruptor, but I believe that it uses bounded >> queues. My general feeling thus far is that, as the general 'go-to' channel >> type, people should not be using bounded queues that block the sender when >> full because of the potential for unexpected deadlocks. I could be >> convinced otherwise though if it's just not possible to have reasonably >> fast unbounded channels. Note that I don't think it's critical for the >> general-purpose channel to be as fast as possible - it's more important to >> be convenient. >> > Rust tasks however are more than a GP channel .. they are your parralelism and saying they should be convenient is the same in the parralel world of saying your method callls should be convenient rather than fast - they need to be both with little compromise. It will be a major bottle neck to using independent task based components. Note you dont need to stop the sender if the queue is full , what can do is write the messages to a buffer in the senders memory when the queue is full and continue running , you can then make a decision of how big that should be based on memory pressure ( you can persist part of the queue even ( maybe force paging) , causing a disk acces which the thread will wait for) etc.. Lockless , non blocking async IPC is possible ( so its possible with rust tasks) though its an area of little research . The key is the sender must either slow , have sufficient memory to handle all requests up till the point it stops running waiting for something else or persist some of that. Expanding queues are possible and help reduce memory but need carefull scheduling. ( obvious way is stop both , create a new queue and copy the data accross) . The worst case is probably a logger / printf service we have all experienced apps slowing to write to disk / console ,in this case they would not but it comes at the cost of memory . Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bklooste at gmail.com Tue Oct 29 22:37:00 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Wed, 30 Oct 2013 13:37:00 +0800 Subject: [rust-dev] Fwd: Faster communication between tasks In-Reply-To: References: Message-ID: Simon 1 thing you may want to test is 10-20 senders to 1 reciever. Multiple senders have completely diffirent behaviour and can create a lot of contention around locks / interlocked calls . Also checks what happens to CPU when the receiver blocks for 100ms disk accesses every 100ms. Disruptor as used by Lmax normally uses very few senders / receivers and the main/busy threads do no IO. Ben On Wed, Oct 30, 2013 at 1:03 PM, Simon Ruggier wrote: > See my first message, I tested the throughput of the pipes API, it is far > slower. Synchronization between sender and receiver depends on which wait > strategy is used. There is a strategy that blocks indefinitely if no new > items are sent. To see how it works, look at this comment: > > https://github.com/sruggier/rust-disruptor/blob/7cbc2fababa087d0bc116a8a739cbb759354388b/disruptor.rs#L762 > > Multiple senders are also on my roadmap. > > Some things just aren't testable, because the memory ordering guarantees > depend on the hardware you're running on. For it to be truly correct and > portable, the source code has to be simple enough for a reviewer to able to > verify correctness at compile time. The comment I link to above is a good > example, I could never test that code thoroughly enough to be satisfied, a > proof of correctness is the only way. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bklooste at gmail.com Tue Oct 29 23:43:37 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Wed, 30 Oct 2013 14:43:37 +0800 Subject: [rust-dev] More on stack safety In-Reply-To: <20131029110848.GD23801@Mr-Bennet> References: <20131029110848.GD23801@Mr-Bennet> Message-ID: On Tue, Oct 29, 2013 at 7:08 PM, Niko Matsakis wrote: > If I understand correctly, what you are proposing is to offer fixed > size stacks and to use a guard page to check for stack overflow (vs a > stack preamble)? > > My two thoughts are: > > 1. I do think segmented stacks offer several tangible benefits: > > - Recursion limited only by available memory / address space > - Avoid chewing up address space on 32 bit builds > > However, I can accept that on balance they are not worth the price, > given that point #2 is probably not that important for 64-bit systems. > > It is sad to lose limitless recursion but typically one can rewrite > routines that recurse arbitrarily deep to use a stack on the heap, > though sometimes the code is very unnatural, and using a stack on the > heap will not play as well with lifetimes, since the compiler doesn't > know that you are obeying a stack discipline. Fixed stacks can be expanded once you have precise collection ( help will come from LLVM eventually...). What i think hasnt been discussed ( though it has previously) is how much of a penalty segmented stacks represent and what it could be .. In terms of memory allocations a faster expansion or greater reuse from a segment pool ( Why does the scheduler segment pool start empty. I would have thought you would have 2Meg worth pre allocated - one runs in the context of a microbench the other allocated before hand ( like C stacks) ) . a 4^N expansion of each stack would result in more contigous stacks. And if stack is unused for a long time hand some segments back. In terms of the stack size check , as has been mentioned you can do more with some analysis , each method gives an indication of worst cases stack growth , these can then be added together to reduces checks by 80% and hence significantly reduce the performance impact . Though obviously for production release soon you will get there faster with fixed stacks earlier. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Oct 30 07:55:33 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 30 Oct 2013 07:55:33 -0700 Subject: [rust-dev] More on stack safety In-Reply-To: References: <20131029110848.GD23801@Mr-Bennet> Message-ID: <52711DE5.3090504@mozilla.com> On 10/29/13 11:43 PM, Ben Kloosterman wrote: > What i think hasnt been discussed ( though it has previously) is how > much of a penalty segmented stacks represent and what it could be .. No, we tried all sorts of optimizations. Look in the history at the scheduler code. That path was heavily optimized in the common case. > In terms of memory allocations a faster expansion or greater reuse from > a segment pool ( Why does the scheduler segment pool start empty. I > would have thought you would have 2Meg worth pre allocated - one runs > in the context of a microbench the other allocated before hand ( like C > stacks) ) . a 4^N expansion of each stack would result in more > contigous stacks. And if stack is unused for a long time hand some > segments back. We tried it. The performance cost was still very high compared to C. I know Jonathan Shapiro also thinks that we didn't try hard enough, but when you're competing against C function calls (2 ns?) there is extremely little wiggle room. Even 10 instructions means you're at least 2x slower. > In terms of the stack size check , as has been mentioned you can do > more with some analysis , each method gives an indication of worst > cases stack growth , these can then be added together to reduces checks > by 80% and hence significantly reduce the performance impact . Citation for the 80% number? Patrick From sh4.seo at samsung.com Wed Oct 30 10:02:24 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Wed, 30 Oct 2013 17:02:24 +0000 (GMT) Subject: [rust-dev] Mysterious comment Message-ID: <2216107.369691383152543957.JavaMail.weblogic@epv6ml05> src/librustc/middle/trans/callee.rs line 614 says: In particular, for lang items, it is invoked with a dest of None, and Did we lose the comment or was it always an incomplete comment? And what (in particular) is about lang items? From matthieu.monrocq at gmail.com Wed Oct 30 10:39:11 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Wed, 30 Oct 2013 18:39:11 +0100 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: <20131030021742.GA2264@Mr-Bennet> References: <20131030021742.GA2264@Mr-Bennet> Message-ID: I really like the idea of a task being a sandbox (if pure/no-unsafe Rust). It seems (relatively) easy for a task to keep count of the number of bytes it allocated (or the number of blocks), both heap-allocated and stack-allocated blocks could be meshed together there (after all, both consume memory), and this single count would address both (1) and (3) at once. Regarding the intrinsic to "extend" the stack, it seems nice, and in fact generalizable. It looks to me like a coroutine in the same memory space, compared to a task being a coroutine in a different memory space. Maybe some unification is possible here ? -- Matthieu On Wed, Oct 30, 2013 at 3:17 AM, Niko Matsakis wrote: > I certainly like the idea of exposing a "low stack" check to the user > so that they can do better recovery. I also like the idea of > `call_with_new_stack`. I am not sure if this means that the default > recovery should be *abort* vs *task failure* (which is already fairly > drastic). > > But I guess it is a legitimate question: to what extent should we > permit safe rust code to bring a system to its knees? We can't truly > execute untrusted code, since it could invoke native things or include > unsafe blocks, but it'd be nice if we could give some guarantees as to > the limits of what safe code can do. Put differently, it'd be nice > if tasks could serve as an effective sandbox for *safe code*. > > It seems to me that the main way that safe code can cause problems for > a larger system are (1) allocating too much heap; (2) looping > infinitely; and (3) over-recursing. But no doubt there are more. > Maybe it doesn't make sense to address only one problem and not the > others; on the other hand, we should not let the perfect be the enemy > of the good, and perhaps we can find ways to address the others as > well (e.g., hard limits on total memory a task can ever allocate; > leveraging different O/S threads for pre-emption and killing, etc). > > > Niko > > On Tue, Oct 29, 2013 at 11:51:10PM +0100, Igor Bukanov wrote: > > SpiderMonkey uses recursive algorithms in quite a few places. As the > > level of recursion is at mercy of JS code, checking for stack > > exhaustion is a must. For that the code explicitly compare an address > > of a local variable with a limit set as a part of thread > > initialization. If the limit is breached, the code either reports > > failure to the caller (parser, interpreter, JITed code) or tries to > > recover using a different algorithm (marking phase of GC). > > > > This explicit strategy allowed to archive stack safety with relatively > > infrequent stack checks compared with the total number of function > > calls in the code. Granted, without statick analysis this is fragile > > as missing stack check on a code path that is under control of JS > > could be potentially exploitable (this is C++ code after all), but it > > has being working. > > > > So I think aborting on stack overflow in Rust should be OK as it > > removes security implications from a stack overflow bugs. However, it > > is a must then to provide facilities to check for a low stack. It > > would also be very useful to have an option to call code with a newly > > allocated stack of the given size without creating any extra thread > > etc. This would allow for a pattern like: > > > > fn part_of_recursive_parser ... { > > if stack_low() { > > call_with_new_stack(10*1024*1024, part_of_recursive_parser) > > } > > } > > > > Then missing stack_low() becomes just a bug without security > implications. > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Wed Oct 30 10:44:15 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Wed, 30 Oct 2013 18:44:15 +0100 Subject: [rust-dev] Fwd: Faster communication between tasks In-Reply-To: References: Message-ID: If I may suggest, rather than blocking the sender in case the channel is full, I suggest simply returning an error (or raising a condition) immediately. This is both extremely simple (for the channel implementer) and heavily customizable (for the user). It seems certainly much easier than provide an extremely wide array of different channels as part of the core Rust distribution... and actually makes it possible to build libraries for common cases (such as local queuing). -- Matthieu. On Wed, Oct 30, 2013 at 6:37 AM, Ben Kloosterman wrote: > Simon 1 thing you may want to test is 10-20 senders to 1 reciever. > Multiple senders have completely diffirent behaviour and can create a lot > of contention around locks / interlocked calls . Also checks what happens > to CPU when the receiver blocks for 100ms disk accesses every 100ms. > > Disruptor as used by Lmax normally uses very few senders / receivers and > the main/busy threads do no IO. > > Ben > > > On Wed, Oct 30, 2013 at 1:03 PM, Simon Ruggier wrote: > >> See my first message, I tested the throughput of the pipes API, it is far >> slower. Synchronization between sender and receiver depends on which wait >> strategy is used. There is a strategy that blocks indefinitely if no new >> items are sent. To see how it works, look at this comment: >> >> https://github.com/sruggier/rust-disruptor/blob/7cbc2fababa087d0bc116a8a739cbb759354388b/disruptor.rs#L762 >> >> Multiple senders are also on my roadmap. >> >> Some things just aren't testable, because the memory ordering guarantees >> depend on the hardware you're running on. For it to be truly correct and >> portable, the source code has to be simple enough for a reviewer to able to >> verify correctness at compile time. The comment I link to above is a good >> example, I could never test that code thoroughly enough to be satisfied, a >> proof of correctness is the only way. >> >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Wed Oct 30 12:25:36 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 30 Oct 2013 15:25:36 -0400 Subject: [rust-dev] Mysterious comment In-Reply-To: <2216107.369691383152543957.JavaMail.weblogic@epv6ml05> References: <2216107.369691383152543957.JavaMail.weblogic@epv6ml05> Message-ID: <20131030192536.GE31075@Mr-Bennet> On Wed, Oct 30, 2013 at 05:02:24PM +0000, Sanghyeon Seo wrote: > src/librustc/middle/trans/callee.rs line 614 says: > > In particular, for lang items, it is invoked with a dest of > None, and > > Did we lose the comment or was it always an incomplete comment? > And what (in particular) is about lang items? Ah, that's my fault. I wrote a complete version of that comment at some point, but I guess it's on some now abandoned branch. I'll have to go find it. My basic recollection is that the lang items makes use of the return value, whereas other fns expect a destination pointer to be passed in, but you'll have to read the code to see. Niko From robert at ocallahan.org Wed Oct 30 16:12:18 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 31 Oct 2013 12:12:18 +1300 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: <20131030021742.GA2264@Mr-Bennet> References: <20131030021742.GA2264@Mr-Bennet> Message-ID: On Wed, Oct 30, 2013 at 3:17 PM, Niko Matsakis wrote: > But I guess it is a legitimate question: to what extent should we > permit safe rust code to bring a system to its knees? We can't truly > execute untrusted code, since it could invoke native things or include > unsafe blocks, but it'd be nice if we could give some guarantees as to > the limits of what safe code can do. Put differently, it'd be nice > if tasks could serve as an effective sandbox for *safe code*. > This is very important if Servo is to improve browser reliability as well as security. That means resource exhaustion should cause task failure with unwinding. It seems to me that the main way that safe code can cause problems for > a larger system are (1) allocating too much heap; (2) looping > infinitely; and (3) over-recursing. But no doubt there are more. > Maybe it doesn't make sense to address only one problem and not the > others; on the other hand, we should not let the perfect be the enemy > of the good, and perhaps we can find ways to address the others as > well (e.g., hard limits on total memory a task can ever allocate; > leveraging different O/S threads for pre-emption and killing, etc). > Since tasks don't share heaps, bounding their memory usage seems tractable; it becomes an accounting problem. Instead of using explicit counters I suggest following the lead of Gecko's MemShrink project and building infrastructure to compute the memory usage of a task by walking its heap. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Wed Oct 30 16:14:56 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 31 Oct 2013 12:14:56 +1300 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: References: <20131030021742.GA2264@Mr-Bennet> Message-ID: On Thu, Oct 31, 2013 at 12:12 PM, Robert O'Callahan wrote: > Since tasks don't share heaps, bounding their memory usage seems > tractable; it becomes an accounting problem. Instead of using explicit > counters I suggest following the lead of Gecko's MemShrink project and > building infrastructure to compute the memory usage of a task by walking > its heap. > The idea then would be that if the program as a whole gets into a low-memory situation, you compute the heap size of each task and kill some of them. It's a bit like OOM killing in operating systems, but in Rust you have a lot more information available (and we can ask developers to provide even more if it's helpful), so we should be able to make more sensible decisions. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Oct 30 16:16:59 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 30 Oct 2013 16:16:59 -0700 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: References: <20131030021742.GA2264@Mr-Bennet> Message-ID: <5271936B.3030903@mozilla.com> On 10/30/13 4:12 PM, Robert O'Callahan wrote: > Since tasks don't share heaps, bounding their memory usage seems > tractable; it becomes an accounting problem. Instead of using explicit > counters I suggest following the lead of Gecko's MemShrink project and > building infrastructure to compute the memory usage of a task by walking > its heap. They do though, through ARCs and RWarcs. I don't expect they're a large portion of memory usage though. We don't have precise stack maps, though, which would be needed to have the runtime explicitly start from all stack roots and sum up all exchange heap memory in a holistic way. In the absence of that I can't think of any solution off the top of my head other than manually coded memory reporters like Gecko. But there might be something clever we can do. Patrick From pcwalton at mozilla.com Wed Oct 30 16:21:04 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 30 Oct 2013 16:21:04 -0700 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: <5271936B.3030903@mozilla.com> References: <20131030021742.GA2264@Mr-Bennet> <5271936B.3030903@mozilla.com> Message-ID: <52719460.4050406@mozilla.com> On 10/30/13 4:16 PM, Patrick Walton wrote: > We don't have precise stack maps, though I should add that this is an LLVM problem, not a language problem. Although it's a big LLVM problem that is a lot of work to fix. Maybe some of Apple's changes will help here. (GCC has the same problem, by the way.) Patrick From robert at ocallahan.org Wed Oct 30 16:25:53 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 31 Oct 2013 12:25:53 +1300 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: <52719460.4050406@mozilla.com> References: <20131030021742.GA2264@Mr-Bennet> <5271936B.3030903@mozilla.com> <52719460.4050406@mozilla.com> Message-ID: On Thu, Oct 31, 2013 at 12:21 PM, Patrick Walton wrote: > On 10/30/13 4:16 PM, Patrick Walton wrote: > >> We don't have precise stack maps, though >> > > I should add that this is an LLVM problem, not a language problem. > Although it's a big LLVM problem that is a lot of work to fix. Maybe some > of Apple's changes will help here. > > (GCC has the same problem, by the way.) Sure. It's probably safe to make robust OOM handling a long-term goal that can wait for advances like that. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Wed Oct 30 16:31:37 2013 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 31 Oct 2013 12:31:37 +1300 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: <5271936B.3030903@mozilla.com> References: <20131030021742.GA2264@Mr-Bennet> <5271936B.3030903@mozilla.com> Message-ID: On Thu, Oct 31, 2013 at 12:16 PM, Patrick Walton wrote: > On 10/30/13 4:12 PM, Robert O'Callahan wrote: > >> Since tasks don't share heaps, bounding their memory usage seems >> tractable; it becomes an accounting problem. Instead of using explicit >> counters I suggest following the lead of Gecko's MemShrink project and >> building infrastructure to compute the memory usage of a task by walking >> its heap. >> > > They do though, through ARCs and RWarcs. I don't expect they're a large > portion of memory usage though. > For ARCs it may be good enough to just charge each task with the cost of the object. RWarcs are worse. However, tasks that share a RWarc can't generally fail independently, I assume. So one possibility is to group tasks into units of failure, require that RWarcs can only be shared within such units, and account for memory usage at failure-unit granularity. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Oct 30 16:33:08 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 30 Oct 2013 16:33:08 -0700 Subject: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK. In-Reply-To: References: <20131030021742.GA2264@Mr-Bennet> <5271936B.3030903@mozilla.com> Message-ID: <52719734.4060101@mozilla.com> On 10/30/13 4:31 PM, Robert O'Callahan wrote: > RWarcs are worse. However, tasks that share a RWarc can't generally fail > independently, I assume. So one possibility is to group tasks into units > of failure, require that RWarcs can only be shared within such units, > and account for memory usage at failure-unit granularity. Yeah, something like that could work. Incidentally RWarcs are quite rare. Off the top of my head I don't think we use a single one in Servo. (Though we'll probably need a couple, e.g. the interning table, which will likely actually be a concurrent hashmap of some sort instead of a RWarc.) Patrick From sebastian.sylvan at gmail.com Wed Oct 30 17:22:46 2013 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed, 30 Oct 2013 17:22:46 -0700 Subject: [rust-dev] More on stack safety In-Reply-To: References: Message-ID: On Mon, Oct 28, 2013 at 10:23 PM, Corey Richardson wrote: > I've written up more thoughts on stack safety at > http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one > objects to it (meeting tomorrow!) or has any better ideas, I'll start > implementing it. > Consider this: *if* you're only executing tasks that you know will never block (either due to IO, a concurrency primitive, or due to pre-emption) then you would only need a single stack per OS thread. These can be therefore be "big" (e.g. 1GB, lazily allocated, with logic to shrink it occasionally?). This holds true if only 90% of tasks are non-blocking. For blocking tasks you can't use large stacks without risking that the task will block while holding on to all that address space (and even physical memory). So, if 90% of tasks run without blocking, you could run the remaining 10% of tasks with segmented stacks. Do all the usual heroic analysis to minimize cost of segmented stacks, but know that it only affects tasks that block, which would be a minority in this scheme. One way to make sure that most tasks don't block is to make co-operative scheduling the default. IME you tend to have a lot of blocking at the bottom of a thread (for coordination), and then a whole bunch of work happening in functions that never touch any IO or OS primitives (and really don't need to be pre-empted either). If you can make sure the scheduler never pre-empts these tasks they can switch to a big stack as soon as they enter a function that doesn't block (known statically). This way the vast majority of code executes without ever checking for stack sizes manually, and you still don't gobble up massive amounts of address space. The big issue here then is really that rust tasks can be pre-empted, and therefore you can't guarantee that *any* function is free from blocking (which means you can't assign it a large stack, since it may go to sleep while holding it). IMO co-operative tasks (by default) is worth considering as a solution here. Then tag functions that don't block (transitively), and let those functions run on large stacks (unless you statically know that the current segmented stack space is enough.. you can save the switching cost in those cases). Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon80 at gmail.com Wed Oct 30 18:54:27 2013 From: simon80 at gmail.com (Simon Ruggier) Date: Wed, 30 Oct 2013 21:54:27 -0400 Subject: [rust-dev] Fwd: Faster communication between tasks In-Reply-To: References: Message-ID: It's not a problem to offer non-blocking functions on both the send and receive sides, in addition to the blocking ones. It's up to callers to choose what's right for their application, but at the same time, they shouldn't have to reinvent the wheel. The reason it's not in there yet is that riskier items were and are my first priority. On Wed, Oct 30, 2013 at 1:44 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > If I may suggest, rather than blocking the sender in case the channel is > full, I suggest simply returning an error (or raising a condition) > immediately. > > This is both extremely simple (for the channel implementer) and heavily > customizable (for the user). > > It seems certainly much easier than provide an extremely wide array of > different channels as part of the core Rust distribution... and actually > makes it possible to build libraries for common cases (such as local > queuing). > > -- Matthieu. > > > On Wed, Oct 30, 2013 at 6:37 AM, Ben Kloosterman wrote: > >> Simon 1 thing you may want to test is 10-20 senders to 1 reciever. >> Multiple senders have completely diffirent behaviour and can create a lot >> of contention around locks / interlocked calls . Also checks what happens >> to CPU when the receiver blocks for 100ms disk accesses every 100ms. >> >> Disruptor as used by Lmax normally uses very few senders / receivers and >> the main/busy threads do no IO. >> >> Ben >> >> >> On Wed, Oct 30, 2013 at 1:03 PM, Simon Ruggier wrote: >> >>> See my first message, I tested the throughput of the pipes API, it is >>> far slower. Synchronization between sender and receiver depends on which >>> wait strategy is used. There is a strategy that blocks indefinitely if no >>> new items are sent. To see how it works, look at this comment: >>> >>> https://github.com/sruggier/rust-disruptor/blob/7cbc2fababa087d0bc116a8a739cbb759354388b/disruptor.rs#L762 >>> >>> Multiple senders are also on my roadmap. >>> >>> Some things just aren't testable, because the memory ordering guarantees >>> depend on the hardware you're running on. For it to be truly correct and >>> portable, the source code has to be simple enough for a reviewer to able to >>> verify correctness at compile time. The comment I link to above is a good >>> example, I could never test that code thoroughly enough to be satisfied, a >>> proof of correctness is the only way. >>> >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kami911 at gmail.com Thu Oct 31 02:04:24 2013 From: kami911 at gmail.com (KAMI911 KAMI911) Date: Thu, 31 Oct 2013 10:04:24 +0100 Subject: [rust-dev] Rust and Servo presentations, demos Message-ID: Hi Folks, (sorry for cross posting), I am a Hungarian contributor to Mozilla. Next weekend I will have a presentation about Mozilla Labs projects and I would like to introduce Rust and Servo. Can you point some presentations, demos that available for everyone? Thank you in advance! ?dv?zlettel / Best Regards: K?lm?n (KAMI) Szalai -------------- next part -------------- An HTML attachment was scrubbed... URL: From bklooste at gmail.com Thu Oct 31 07:07:51 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Thu, 31 Oct 2013 22:07:51 +0800 Subject: [rust-dev] More on stack safety In-Reply-To: References: Message-ID: > > The big issue here then is really that rust tasks can be pre-empted, and > therefore you can't guarantee that *any* function is free from blocking > (which means you can't assign it a large stack, since it may go to sleep > while holding it). IMO co-operative tasks (by default) is worth considering > as a solution here. > re Co operative tasks , I have bad memories of 3.X apps which could lock the whole OS/GUI when in a tight loop ? Certainly not a solution for single core systems , even on dual system it can be an issue. On quad+ there is some merit but history has shown every addin /lib will use as many resources as they can ( eg flash add animations ) and not yield willingly. It can be done but you need to check tasks with a schedule service task and if they dont behave pre-empt / reduce priority. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Thu Oct 31 07:20:42 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 31 Oct 2013 10:20:42 -0400 Subject: [rust-dev] More on stack safety In-Reply-To: References: Message-ID: <20131031142042.GA17686@Mr-Bennet> Currently, Rust does not pre-empty. I still hope we can leverage the O/S for pre-emption rather than having to implement it ourselves. Niko On Thu, Oct 31, 2013 at 10:07:51PM +0800, Ben Kloosterman wrote: > > > > The big issue here then is really that rust tasks can be pre-empted, and > > therefore you can't guarantee that *any* function is free from blocking > > (which means you can't assign it a large stack, since it may go to sleep > > while holding it). IMO co-operative tasks (by default) is worth considering > > as a solution here. > > > > re Co operative tasks , I have bad memories of 3.X apps which could lock > the whole OS/GUI when in a tight loop ? Certainly not a solution for > single core systems , even on dual system it can be an issue. On quad+ > there is some merit but history has shown every addin /lib will use as > many resources as they can ( eg flash add animations ) and not yield > willingly. It can be done but you need to check tasks with a schedule > service task and if they dont behave pre-empt / reduce priority. > > Ben > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From bklooste at gmail.com Thu Oct 31 07:44:36 2013 From: bklooste at gmail.com (Ben Kloosterman) Date: Thu, 31 Oct 2013 22:44:36 +0800 Subject: [rust-dev] More on stack safety In-Reply-To: <52711DE5.3090504@mozilla.com> References: <20131029110848.GD23801@Mr-Bennet> <52711DE5.3090504@mozilla.com> Message-ID: > > > > > In terms of the stack size check , as has been mentioned you can do >> more with some analysis , each method gives an indication of worst >> cases stack growth , these can then be added together to reduces checks >> by 80% and hence significantly reduce the performance impact . >> > > Citation for the 80% number? > > Actually it was a guess based on the algoirithm in my head but i did just find a paper which showed up to 89% of checks can be removed. http://courses.cs.vt.edu/cs5204/fall05-gback/papers/capriccio-sosp-2003.pdf Segmented stacks for Apache with highly concurrent workload. " At 0.1% of call sites, checkpoints caused a new stack chunk to be linked, at a cost of 27 instructions. At 0.4?0.5% of call sites, a large stack chunk was linked unconditionally in order to handle an external function, costing 20 instructions. At 10% of call sites, a checkpoint determined that a new chunk was not required, which cost 6 instructions. The remaining 89% of call sites were una?ected. Assuming all instructions are roughly equal in cost, the result is a 71?73% slowdown when considering function calls alone. Since call instructions make up only 5% of the program?s instructions, the overall slowdown is approximately 3% to 4%" This is also interesting for a compiler that implements it. http://www.cs.technion.ac.il/~erez/Papers/sctack-scan-vee09.pdf Note im in the big stack and tune it down camp was just trying to work out why segments were so bad. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.sylvan at gmail.com Thu Oct 31 11:41:36 2013 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu, 31 Oct 2013 11:41:36 -0700 Subject: [rust-dev] More on stack safety In-Reply-To: References: Message-ID: On Thu, Oct 31, 2013 at 7:07 AM, Ben Kloosterman wrote: >> >> The big issue here then is really that rust tasks can be pre-empted, and >> therefore you can't guarantee that *any* function is free from blocking >> (which means you can't assign it a large stack, since it may go to sleep >> while holding it). IMO co-operative tasks (by default) is worth considering >> as a solution here. >> > > re Co operative tasks , I have bad memories of 3.X apps which could lock > the whole OS/GUI when in a tight loop ? Certainly not a solution for > single core systems , even on dual system it can be an issue. On quad+ > there is some merit but history has shown every addin /lib will use as > many resources as they can ( eg flash add animations ) and not yield > willingly. It can be done but you need to check tasks with a schedule > service task and if they dont behave pre-empt / reduce priority. > > > > I do think there definitely needs to be a solution for actually pre-emptible threads (whether backed by OS or done in the language runtime). E.g. you might put third party code in there if it's something that will run for a long time. I'm just not sure that most tasks within your own code needs to be pre-empted to ensure they don't misbehave - you're in charge of them, make sure they don't soak up cycles for an unbounded period of time to avoid having starving the other tasks (the language RT would probably spawn up more OS threads if that happens, I'd imagine, which gets you back into the same area of eating up virtual address space by having more OS threads than HW threads, each of which has a dedicated "large stack" to run non-blocking tasks on)! -- Sebastian Sylvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack at metajack.im Thu Oct 31 13:43:42 2013 From: jack at metajack.im (Jack Moffitt) Date: Thu, 31 Oct 2013 14:43:42 -0600 Subject: [rust-dev] [dev-servo] Rust and Servo presentations, demos In-Reply-To: References: Message-ID: Szia! There is a list of collected presentations related to Servo here: https://github.com/mozilla/servo/wiki/Videos-and-presentations and one for Rust: https://github.com/mozilla/rust/wiki/Docs#presentations The best way to demo servo are the following files which you can find in `src/test/html`: acid1.html summit2.html (showing parallel iframes) summit-fail.html (showing isolated failure) Hope this helps and gives you some ideas! jack. On Thu, Oct 31, 2013 at 3:04 AM, KAMI911 KAMI911 wrote: > Hi Folks, (sorry for cross posting), > > I am a Hungarian contributor to Mozilla. Next weekend I will have a > presentation about Mozilla Labs projects and I would like to introduce Rust > and Servo. Can you point some presentations, demos that available for > everyone? > > Thank you in advance! > > ?dv?zlettel / Best Regards: > > K?lm?n (KAMI) Szalai > _______________________________________________ > dev-servo mailing list > dev-servo at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo From ben.striegel at gmail.com Thu Oct 31 17:13:16 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Thu, 31 Oct 2013 20:13:16 -0400 Subject: [rust-dev] Rust and Servo presentations, demos In-Reply-To: References: Message-ID: Before you give the presentation, would you mind showing it to us here? I for one would be happy to review your code and make sure it's up to date. On Thu, Oct 31, 2013 at 5:04 AM, KAMI911 KAMI911 wrote: > Hi Folks, (sorry for cross posting), > > I am a Hungarian contributor to Mozilla. Next weekend I will have a > presentation about Mozilla Labs projects and I would like to introduce Rust > and Servo. Can you point some presentations, demos that available for > everyone? > > Thank you in advance! > > ?dv?zlettel / Best Regards: > > K?lm?n (KAMI) Szalai > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: