Jakub Žádník

The issue was already reported upstream https://github.com/technologicalMayhem/human-date-parser/issues/1. There are no replies and the crate seems unmaintained, so we can't hope for an upstream fix. We'd need to either remove the...

From a cursory look, the general idea seems fine. Just two comments: 1. Can you get rid of the `expect()s`? You may use the `report_error()` function, for example, to print...

Yeah, fallback cloning could work. We can definitely bring up the property-based testing, but it seems like a different topic than this PR. But yeah, more rigorous tests are always...

We talked with the core team about the proptest, and it would be better if you could extract useful unit tests for this PR and leave proptest for a further...

Adding the proptests into a separate file and putting it behind a feature (or env var, to me it seems feature would be cleaner) could be a good first step...

OK, sounds good. Could you split the proptest itself into a separate PR? We can investigate there what happens with the `tests/` directory, it seems like a better fit than...

`register` is a parser keyword and needs a constant argument. That's the current language design limitation and no easy way around it. You should be able to use `const` instead...

> Do we have an issue regarding > > > IIRC string interpolation is not supported in const evaluation yet, so you might need to use something else for now....

I think polars panicking is a bug in polars and should be resolved there. However, we still need some mechanism for dealing with panicking crates, not sure what the best...

Where is your `command.nu`? It needs to be in some discoverable location, such as in one of NU_LIB_DIRS directories, or right next to `config.nu`. Did it work in 0.83 and...