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
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
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
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
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 *
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
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
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
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
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
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
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
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:
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
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
> 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
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
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:
18 matches
Mail list logo