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
alfa
@dkotrada
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?)
Pascal Hertleif
@killercup
@rcoh yeah, assert-cli calls cargo internally in a specific way that sometimes makes it recompile everything :( this especially happens when you specify --target… so using cross will trigger this
Daniel Sockwell
@codesections
Hi all! I'm working on a simple CLI app and have gotten to writing the man(1) page for the app, so I'm looking for the current best way to do so. I found https://github.com/rust-clique/man ; is that the best option? I'm asking because it looks like that repo isn't that active—no commits in a couple of months, and the README example doesn't work (e.g., it uses the .description method instead of the .help method in the code.
I also found https://rust-lang-nursery.github.io/cli-wg/in-depth/docs.html, which discusses rendering man pages from Clap, but that doesn't seem to be implemented (yet?)
I'd be happy to help out with the man crate—it seems really cool and helpful (I'm a big fan of man pages for CLI apps!). But I don't want to spend time opening issues/PRs if the community or WG has moved on to a different solution
Pascal Hertleif
@killercup
@codesections hi! the current support for man pages in clap is quite experimental, and requires the alpha version of clap 3. the man crate(s) are also quite simple right now --if you want to help out there it would be greatly appreciated!
i'm at work right now, but we can talk later if you want, just ping me!
Daniel Sockwell
@codesections
@killercup thanks for the reply. I'd be happy to help with the man crate! Just to be clear, though, it's not going to be depreciated when clap 3 has support for generating man pages, right? No sense on working on something that is about to be replaced/eliminated, after all
Pascal Hertleif
@killercup
@codesections AFAIK clap will use https://github.com/rust-clique/man
the internals of that might change drastically depending on what we want to do
(the roff crate for example is super simplistic right now)
Daniel Sockwell
@codesections
@killercup Ok, cool. I've opened two issues and submitted one (minor) PR for man (which, if merged, would close one of the issues). I'll probably wait a bit before getting started on the PR for the second issue to see if you/anyone else have other ideas for a good way to proceed.
Pascal Hertleif
@killercup

@codesections hey, thanks for all the contributions to the man crate! the roff crate is pretty much just a POC so far, but @aoikonomopoulos_gitlab made an alternative impl some time ago: https://gitlab.com/aoikonomopoulos/rroff

if you're interested in working on a good roff crate and bring the design together, i'd love to add you as a contributor (and maybe move it to the clique github orga) :)

Daniel Sockwell
@codesections

Yeah, I'd definitely be interested in that/helping out with more CLIque stuff in general.

What do you think the next steps are for creating a good roff crate?

Dylan DPC
@Dylan-DPC
can help with that s well :)
Pascal Hertleif
@killercup
@codesections moved to https://github.com/rust-clique/roff-rs and added you to maintainers group
Dylan DPC
@Dylan-DPC
:+1: