Re: [rust-dev] No stdout in test builds?

2014-05-26 Thread Urban Hafner
Thank you Alex! On Tue, May 27, 2014 at 7:23 AM, Alex Crichton wrote: > The test runner captures stdout by default and prints it at the end of > the test run, but only if the test failed. This is intended to turn > down the noise of successful tests, especially the failing ones. > > If you pass

Re: [rust-dev] No stdout in test builds?

2014-05-26 Thread Alex Crichton
The test runner captures stdout by default and prints it at the end of the test run, but only if the test failed. This is intended to turn down the noise of successful tests, especially the failing ones. If you pass the --nocapture option to the test binary, it will disable this behavior and print

[rust-dev] No stdout in test builds?

2014-05-26 Thread Urban Hafner
Hey everyone, still me, the Rust newbie ;) Coming from Ruby I use TDD quite heavily. For my toy rust project I've setup my Makefile in such a way that it first compiles and runs a test build before compiling the real executable. When trying to debug a failing test I tried putting println! stateme

Re: [rust-dev] Glob crate?

2014-05-26 Thread Steven Fackler
A glob crate like this one? https://github.com/mozilla/rust/blob/master/src/libglob/lib.rs Steven Fackler On Mon, May 26, 2014 at 6:57 PM, Daniel Fagnan wrote: > Writing it here to gauge an interest of the community for a glob crate. If > it seems people are liking the idea, I'll write an RFC

[rust-dev] Glob crate?

2014-05-26 Thread Daniel Fagnan
Writing it here to gauge an interest of the community for a glob crate. If it seems people are liking the idea, I'll write an RFC for it and send a PR. I'm guessing the majority of the folks here already know what it is, as it's pretty universal and used heavily in unix-based environments. (One *

Re: [rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Kevin Ballard
Sure, that seems like a pretty easy job to tackle. You should audit the whole getopts API to see where it uses String inappropriately. Any &[String] parameters should probably be &[S] where , and any bare String parameters (if any) should probably be &str. -Kevin On May 26, 2014, at 6:29 PM, G

Re: [rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Kevin Ballard
How is that any better than just using strings? ["a", "b", "c"] is no more typing than ['a', 'b', 'c'], but it doesn't require defining new traits. -Kevin On May 26, 2014, at 4:54 PM, Sean McArthur wrote: > Considering many options would be single characters, it'd seem nice to also > be able

Re: [rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Sean McArthur
Considering many options would be single characters, it'd seem nice to also be able to pass a slice of chars. It doesn't look like char implements Str. getopts could define a new trait, Text or something, for all 3... On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard wrote: > I think getopts has a

Re: [rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Kevin Ballard
I think getopts has an old API. All the methods that take &[String] should probably be rewritten to be generic with and take &[S] instead, which will allow taking either a slice of Strings or a slice of &str's. -Kevin On May 26, 2014, at 12:16 PM, Benjamin Striegel wrote: > I'm not familiar

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Kevin Ballard
captures() should not take . That's unnecessary, it should just take &str as it does now. The use of taking is for taking things like &[S], where you want to take both &str and String (such as in the other post about getops()). For the time being, the answer is to use .as_slice() explicitly. T

Re: [rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Benjamin Striegel
I'm not familiar with the getopts module, but on the surface that behavior sounds wrong to me. As for the verbosity of the repeated `to_owned` calls, this sounds like the perfect application for macros: #![feature(macro_rules)] macro_rules! owned( ($($e:expr),*) => ([$($e.to_owne

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Benjamin Striegel
I don't think any of these will be necessary. We already have a trait called `Str` (which is a bad name, btw) in the std::str module. This trait has exactly one method: `as_slice`. This trait is already implemented on both `&str` and `StrBuf` (the former in std::str, the latter in std::strbuf). Al

[rust-dev] Array of heap allocated strings for opts_present?

2014-05-26 Thread Gulshan Singh
Why does getopts::Matches::opts_present() take an array of heap allocated strings? Unless I'm missing something, it doesn't seem like it needs to: https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302 Currently, my code to use it looks like this:

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Igor Bukanov
Perhaps Rust should provide something like BorrowAsStr trait allowing to convert automatically to &str. &* is just too ugly... On 26 May 2014 08:58, Vladimir Matveev wrote: >> My suspicion is that the automatic conversion will come back at some >> point, but I'm not sure. > > I think it will be p

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Urban Hafner
Alright. Thank you. There's still a lot to learn for me coming from a dynamic language like Ruby. On Mon, May 26, 2014 at 9:41 AM, Vladimir Matveev wrote: > > And hopefully in the future the regular expression library will be > updated to work on StrBuf instead of &str > This is very unlikely. S

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Vladimir Matveev
> And hopefully in the future the regular expression library will be updated to > work on StrBuf instead of &str This is very unlikely. See, you can go from `StrBuf` to `&str` without allocation - `as_slice()` returns a "view" into the `StrBuf`. This is very cheap operation. But you cannot go from

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Andrew Gallant
It should not receive such an update. There's no reason for the library to require a string allocated on the heap. On May 26, 2014 3:31 AM, "Urban Hafner" wrote: > Thanks guys, I now use "as_slice()" when necessary. And hopefully in the > future the regular expression library will be updated to w

Re: [rust-dev] StrBuf and regular expressions

2014-05-26 Thread Urban Hafner
Thanks guys, I now use "as_slice()" when necessary. And hopefully in the future the regular expression library will be updated to work on StrBuf instead of &str as this seems to be the main use case (read in file, run regexp on it). Urban On Mon, May 26, 2014 at 8:58 AM, Vladimir Matveev wrote: