by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 19 17:59
    Dylan-DPC synchronize #58
  • Apr 19 17:59

    Dylan-DPC on master

    Fix README link (#162) (compare)

  • Apr 19 17:59
    Dylan-DPC closed #162
  • Apr 19 16:56
    feidtmb opened #162
  • Mar 25 12:56
    XAMPPRocky closed #146
  • Feb 06 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
  • Dec 07 2019 00:50
    yoshuawuyts removed as member
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:
Pascal Hertleif
@killercup
good question about next steps. i don't know. the "grand vision" was to have clap generate man pages, and make prototypes that allowed that but i haven't planned beyond that
Daniel Sockwell
@codesections
Thanks! What does it mean to be part of the maintainers group? I thought that would be the group that has write access to the repo, but it doesn't look like I do (unless I'm missing something)
Pascal Hertleif
@killercup
@codesections you should have write access? let me double check
@codesections ah you need to explicitly accept the invitation it seems
Daniel Sockwell
@codesections
Aha, that resolved it, thanks. (Odd UX for GitHub to send an email about that but not have a notification in the web UI)
What's the etiquette within CLIque for merging ones own PRs? I know some groups dislike that/want more code review but others like it to keep the pace of development up/avoid blockers
Pascal Hertleif
@killercup
@codesections don't think we have a specific etiquette established here, so let me come up with something: it's fine if the PRs implement what the core maintainers decided to do
Daniel Sockwell
@codesections
Makes sense :+1:
Pascal Hertleif
@killercup
which leads us to: who are the core maintainer of that repo? i'd propose you, @yoshuawuyts, and @Dylan-DPC who volunteered earlier :)
yes this is super informal and boils down to: best just have a quick chat about it and then get coding :)
Daniel Sockwell
@codesections
:) Sounds about right to me! I think though, that at least in the short term, there's no a whole lot that roff-rs needs to support the core work in man. So, unless anyone has particular features they'd like to see in roff-rs, I expect the majority of my time will be spent on man
It feels like man is very close to being usable for most CLI apps (even if better integration with clap would be great in a post-clap-3.0.0 world)
Pascal Hertleif
@killercup
sounds great!
(that reminds me to add the clique maintainers as owners of the crate on crates.io too. done)
Yoshua Wuyts
@yoshuawuyts
killercup: hi, yes — totally on board with having codesections on the project!
Input has been super helpful; I love that it's active again; never saw it through to the end, so happy it's getting there ^_^
Pascal Hertleif
@killercup
@yoshuawuyts great!
killercup @killercup is revising the CLIque 2019 roadmap to include "stick it to the man"
Ricky
@deg4uss3r
Any other rust cli nerds at LCA?
Pascal Hertleif
@killercup
i don't even know what that is :sweat_smile:
Daniel Sockwell
@codesections
^^^
Ricky
@deg4uss3r
Linux Conference Australia