remi-dupre / aoc Goto Github PK

It seems like an issue with your version on clap.

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.3.0/src/lib.rs:23:18
   |
23 |                 .about("Read input from stdin instead of downloading it"),
   |                  ^^^^^ method not found in `Arg<'_>`


error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.3.0/src/lib.rs:32:18
   |
32 |                 .about("Read input from file instead of downloading it"),
   |                  ^^^^^ method not found in `Arg<'_>`


error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.3.0/src/lib.rs:40:18
   |
40 |                 .about("Days to execute. By default all implemented days will run"),
   |                  ^^^^^ method not found in `Arg<'_>`


error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.3.0/src/lib.rs:46:18
   |
46 |                 .about("Run criterion benchmarks"),
   |                  ^^^^^ method not found in `Arg<'_>`

It would be nice to allow for a leading 0 in mod names (e.g. day01 instead of day1) so that days 10-19 aren't sorted after day1 and days 20-25 aren't sorted after day2.

In other words currently I'm forced to have:

mod day01;
mod day10;
mod day11;
// ...
mod day19;
mod day2;
mod day20;
// ...
mod day25;
mod day3;

whereas I'd like to be able to do:

mod day01;
mod day02
mod day03;
// ...
mod day10;
mod day11;
mod day12;

etc.

Benchmarks take a long time to run, so it's useful to select a single day to run. However, currently I get the following error:

error: Found argument '--day' which wasn't expected, or isn't valid in this context

I made a fork that basically has this functionality, but I'm unsure why the error occurs (presumably it originates from clap?).

I think it's unexpected behavior to store the .token file in the project directory. I personally didn't notice that it was there and accidentally committed and pushed it. I know accidentally leaking the session cookie for adventofcode.com isn't a huge security concern, but it would still be better to store the token in an external config directory, using e.g. https://docs.rs/dirs/3.0.1/dirs/fn.config_dir.html

At the very least, it would be nice to have some warning in the README to add .token to the .gitignore file.

For linux dirs could be replaced by just reading the $HOME env var and we could use curl instead of compiling a whole http client for just a daily download.

For some reason on windows 10 in the vscode terminal .dimmed() doesn't work, it's most likely an issue with colored but a potential workaround could be to use .bright_black() instead since it's very close to what .dimmed() outputs.

in vscode

First one is using .bright_black, second one is using .dimmed

Here it is in the windows terminal, again first one is using bright_black, second one is using dimmed

I can make a PR if you want

From a reddit suggestion.

The syntax already invites to do it, so I suppose it could be nice. However I'm not sure we can just extend the rules to allow for

day1: generator1 => part1_1,
      generator2 => part1_2;

because it would be ambiguous. I didn't test it so maybe I think it is more complicated that it really is.

First of all thanks for the awesome project.

While doing day 22 today I bumped into a problem. If there are too many solutions in total the macro expansion hits a recursion limit. Here's a MWE exemplifying the issue.

aoc_main::main! {
    year 2020;
    // 60 parts
    day1 => p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p;
    day2 => p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p;
}

mod day1 {
    pub fn p(_: &str) -> &str {
        ""
    }
}

Resulting in the error:

error: recursion limit reached while expanding `$crate::format_args!`
 --> src/main.rs:1:1
  |
1 | / aoc_main::main! {
2 | |     year 2020;
3 | |     // 60 parts
4 | |     day1 => p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p;
5 | |     day2 => p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p,p;
6 | | }
  | |_^
  |
  = help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`aoc_bug`)
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

The proposed fix by using #![recursion_limit="256"] works, but maybe there's a way to fix this in the crate.

Cheers.

I want to use the benchmarks, but I don't understand how the criterion toggle is supposed to work.
After moving example.rs to a main.rs "cargo run" works just fine.
However, if I add

[dependencies]
aoc-main = { version = "*", features = ["bench"] }

to Cargo.toml I get the above error.

AoC's creator made a request on the AoC subreddit to include that information so that they'll be able to better handle "abusive traffic".

A crate with the same name already exists https://crates.io/crates/aoc, so I don't know if you published it under a different name or not. If you don't want to publish (yet), it might be a good idea to have that stated in the readme.

Great crate. I was just wondering if it is possible to bench generators as well? I saw some macro for it but could not find it in the cli options.

From a reddit suggestion.

I am not sure how this would be implemented, maybe it would require a proper syntax to indicate that the output needs to be unwrapped, maybe we would reach the limit of using a macro_rule.

At least criterion is an heavy dependency which should have a feature flag to be disabled, it makes this crate unreasonably long to compile for someone who is not interested in this.

Maybe some clap features could also be disabled for a very slight improvement.

I'm not sure what should be enabled by default or not though ^^'

cargo run now throws this error about headers each time. The header you added looks valid though, so I'm not sure what is wrong.

thread 'main' panicked at 'invalid header value: Error(Http(http::Error(InvalidHeaderValue)))', /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/attohttpc-0.24.0/src/request/builder.rs:246:40
stack backtrace:
   0: rust_begin_unwind
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/result.rs:1785:5
   3: core::result::Result<T,E>::expect
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/result.rs:1064:23
   4: attohttpc::request::builder::RequestBuilder<B>::header
             at /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/attohttpc-0.24.0/src/request/builder.rs:246:9
   5: aoc_main::input::get_input::{{closure}}
             at /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.5.0/src/input.rs:36:20
   6: aoc_main::input::get_from_path_or_else
             at /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.5.0/src/input.rs:79:19
   7: aoc_main::input::get_input
             at /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.5.0/src/input.rs:31:22
   8: advent2022::main
             at /Users/jlartz/.asdf/installs/rust/1.65.0/registry/src/github.com-1ecc6299db9ec823/aoc-main-0.5.0/src/lib.rs:117:21
   9: core::ops::function::FnOnce::call_once
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:248:5

The only way to run the benchmarks currently is to run it with --bench , because Criterion happens to ignore it when parsing its own CLI arguments.

Using the short form -b or any other argument conflicts with Criterion's own argument handling that macros use.

I'm not sure what a good solution here would be, but maybe it's better to manually instantiate a Criterion instance with sane defaults? The very basic way to do that would be

diff --git a/src/lib.rs b/src/lib.rs
index c4a4138..630822f 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -171,7 +171,9 @@ macro_rules! main {
             use $crate::criterion::*;

             pub fn run_benchs() {
-                main();
+                let mut crit = Criterion::default();
+                $($day(&mut crit))+;
+                crit.final_summary();
             }

             $(
@@ -196,9 +198,6 @@ macro_rules! main {
                     group.finish();
                 }
             )+
-
-            criterion_group!(benches, $($day),+);
-            criterion_main!(benches);
         }
     };
 }

A better setup would probably involve at least enabling colored and HTML output. I'd be interested in looking into it more if you're interested in this approach and want a patch.