Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 04 2020 02:03
    matu3ba commented #8
  • Apr 19 2020 17:59
    Dylan-DPC synchronize #58
  • Apr 19 2020 17:59

    Dylan-DPC on master

    Fix README link (#162) (compare)

  • Apr 19 2020 17:59
    Dylan-DPC closed #162
  • Apr 19 2020 16:56
    feidtmb opened #162
  • Mar 25 2020 12:56
    XAMPPRocky closed #146
  • Feb 06 2020 18:33
    trevordmiller commented #161
  • Dec 12 2019 20:36
    stappersg commented #144
  • Dec 11 2019 12:53
    JohnTitor closed #144
  • Dec 11 2019 12:53
    JohnTitor commented #144
  • Dec 10 2019 13:17
    killercup transferred #154
  • Dec 08 2019 13:06
    spacekookie synchronize #58
  • Dec 08 2019 13:06

    spacekookie on master

    Clarify source position Make i… (compare)

  • Dec 08 2019 13:06
    spacekookie closed #159
  • Dec 07 2019 00:50
    Dylan-DPC added as member
  • Dec 07 2019 00:50
    spacekookie added as member
  • Dec 07 2019 00:50
    yoshuawuyts added as member
  • Dec 07 2019 00:50
    killercup added as member
  • Dec 07 2019 00:50
    Dylan-DPC removed as member
  • Dec 07 2019 00:50
    spacekookie removed as member
Ed Page
@epage
For cargo-tarball, I'm created stager for describing what you want to package. I'd like to reuse stager in other packaging tools.
I've not yet looked into how to do the equivalent of PPAs for each platform.
Russell Cohen
@rcoh
Looks like https://github.com/jaemk/self_update is similar to equinox in end-user experience
I might add that to angle-grinder and see how it goes
Russell Cohen
@rcoh
Anyone know how to make an option that behaves like --version (hits a totally separate code path then main() in quicli / structopt)?
I approximated it with putting the happy path and the update path in an arg group --
error: The following required arguments were not provided:
    <query|--self-update>

USAGE:
    agrind [FLAGS] [OPTIONS] <query|--self-update>
but it would be nice if it just behaved like version behaves
alfa
@dkotrada
Hello. Trying last section of Chapter 1.4 Nicer error reporting. (Providing Context). What should I add to cargo.toml file in order to get last code snippet working?
use failure::ResultExt;
use exitfailure::ExitFailure;

fn main() -> Result<(), ExitFailure> {
    let path = "test.txt";
    let content = std::fs::read_to_string(path)
        .with_context(|_| format!("could not read file `{}`", path))?;
    println!("file content: {}", content);
    Ok(())
}
Pascal Hertleif
@killercup
@dkotrada hey! the example uses the most recent failure (0.1) and exitfailure (0.5)
at least i think they are the most recent :) the code is tested with this config btw: https://github.com/rust-lang-nursery/cli-wg/blob/25f1851e3885fff97d3e4bd375ae79157074ceb0/Cargo.toml#L66-L67
alfa
@dkotrada
Thank you it works now.
Pascal Hertleif
@killercup
great! feel free to ping me if you have more questions :)
alfa
@dkotrada
@killercup may I critique the Book 'Command Line Applicatons in Rust' ?
Pascal Hertleif
@killercup
@dkotrada of course! you can also call it CLAiR :)
Pascal Hertleif
@killercup
the current version is at the "i think i wrote enough to cover the basics" stage, and I want to get back to adding more content as well as copy-editing soon, so any kind of feedback is super appreciated :) (here, as github issues, emails, in english or german… postcards in swedish might take me a while to respond to, but i promise i'll try)
alfa
@dkotrada
@killercup
  • Chapter 1.5 contains code like this do_hard_work() (Showing a progress bar). When this book is more by example than this is a problem. Because I (newbee) can't try this code. Tried alredy to implement some downloader of files but got problems with open_ssl being included by many crates.
  • Chapter 1.6 Testing Suddenly the difficulty increases for me. So I tend to close this chapter and never look in to it.
Would be good to comment directly on the book content. And discuss it there on github.
Pascal Hertleif
@killercup
thanks -- that's great feedback!
there is a never-to-be-merged PR here rust-lang-nursery/cli-wg#58 to allow comments on the diff
not sure how to give a good progress bar code example for downloading without also having to go into a lot of details around http/async… you can find some examples here, tho: https://github.com/mitsuhiko/indicatif/tree/master/examples
@dkotrada can you say where the testing chapter got difficult for you?
alfa
@dkotrada
fn find_matches<W: std::io::Write>(content: &str, pattern: &str, writer: &mut W)
@killercup Geht auch in deutsch?
Pascal Hertleif
@killercup
@dkotrada ja, aber vielleicht nicht in diesem channel. willst du mich direkt anschreiben?
Pascal Hertleif
@killercup
wrote rust-lang-nursery/cli-wg#115 in response to alfa's feedback -- anyone want to review?
Rohan Jain
@crodjer

Trying to follow the cli-wg tutorial, this is my implementation: https://github.com/crodjer/grrs/blob/master/src/main.rs#L23
I am using BufReader to avoid copying lines:

    let lines = BufReader::new(f)
        .lines()
        .filter(Result::is_ok)
        .map(Result::unwrap);

I then feed this iterator to my library function to find_matches:

pub fn find_matches<I>(lines: I, pattern: &str) -> Vec<String>
where
    I: Iterator<Item = String>,
{
    lines.filter(|line| line.contains(&pattern)).collect()
}

But, I want to avoid return a vector and want to return an iterator which main can then lazily render. After removing collect, I am unable to figure out the type signatures.

How can I modify find_matches so that I only deal with lazy iterators?
Rohan Jain
@crodjer

Okay, so this works:

pub fn find_matches<'a, I: 'a>(lines: I, pattern: &'a str) -> impl Iterator<Item = String> + 'a
where
    I: Iterator<Item = String>,
{
    lines.filter(move |line| line.contains(pattern))
}

Based on: https://stackoverflow.com/a/27649089. Don't know why though.

Screwtapello
@Screwtapello
@crodjer You mean, you don't know why that's different from what you had originally, or you don't know why that particular incantation is needed?
Rohan Jain
@crodjer
@Screwtapello I could not find any mention of return signature of the like impl ... from the rust book.
Also, shouldn't rust have Sized issues with this? Given the type signature just has the trait.
Screwtapello
@Screwtapello
"impl Trait in return position" is a pretty new feature, so I'm not wholly surprised it's not mentioned in the book yet.
If it were "this function returns any type that implements Iterator", then yeah, there would be Sized issues because there's lots of different types that may implement Iterator and they have different sizes.
This particular syntax means "this function returns one particular type that implements Iterator, but I won't write its name". The compiler can validate that the function only ever returns one particular type, and the compiler knows what type that is, so the compiler knows what the size is and all is well.
Rohan Jain
@crodjer
Got it. Thanks @Screwtapello!
Screwtapello
@Screwtapello
So you can't, for example, have a function that returns impl Iterator where sometimes it returns an iterator with a filter applied and sometimes it returns one without, because that would be two different types.
Dylan DPC
@Dylan-DPC
Size shouldn't be an issue since the compiler will know the concrete type at compile time.
Rohan Jain
@crodjer
Got it
Pascal Hertleif
@killercup

@crodjer that's a very good solution! tbh, i had never fully implemented the tool with all features and lazy streaming… :sweat_smile: thanks for doing that!

you can read more on the impl Trait feature in RFC #1522 and an expansion of it in RFC #1951

you also can write find_matches like this if you want the param and return type to be more symmetrical:

pub fn find_matches<'a>(
    lines: impl Iterator<Item = String> + 'a,
    pattern: &'a str,
) -> impl Iterator<Item = String> + 'a {
    lines.filter(move |line| line.contains(pattern))
}
oh, and instead of doing .filter(Result::is_ok).map(Result::unwrap) you can also .filter_map(Result::ok) by the way
Rohan Jain
@crodjer
Thanks for the suggestions @killercup .
Pascal Hertleif
@killercup
any time! :)
Rohan Jain
@crodjer
@killercup Thanks for the tutorial. It was very helpful in getting my hands wet with Rust and cli.
Published the crate at: https://crates.io/crates/grrs-lazy
Pascal Hertleif
@killercup
awesome! so glad you liked it :)
good idea to publish it! maybe other people following the tutorial will find your crate and get some inspiration or see how you did the lazy iteration :)
Dylan DPC
@Dylan-DPC
i was thinking of pushing a demo repo maybe this should be enough then
Rohan Jain
@crodjer
Sure
Rohan Jain
@crodjer
Trying to modify channels based signal handle from the book to handle dual Ctrl-C signals. I have a way with mutexes and threads, but I feel there may be a better way to do this instead:
    let status = Arc::new(Mutex::new(0));
    loop {
        if *status.lock().unwrap() >= 2 {
            break;
        }

        select! {
            recv(ticks) -> _ => {
                println!("working!");
            }
            recv(ctrl_c_events) -> _ => {
                let status = status.clone();
                *status.lock().unwrap() += 1;

                thread::spawn(move || {
                    println!("Shutting down...");
                    thread::sleep(Duration::from_secs(2));
                    println!("Goodbye!");
                    *status.lock().unwrap() += 1;
                });
            }
        }
    }
Russell Cohen
@rcoh
@epage I'm seeing a weird behavior with cross on travis when combined with assert-cli. All my regular tests run, but then the first two of my assert-cli tests take ~5-10 minutes (as if maybe it's fully compiling from scratch again?)