@amtoine gave me valuable feedback about the [PR of `std bench`
improvement](https://github.com/nushell/nu_scripts/pull/859) CANDIDATE
into `stdlib-candidates`.
I understood and respected his reasoning about his position. Yet, I
still believe that users of `std bench` will benefit from my proposal.
I incorporated some of @amtoine advice in this PR.
I removed the `bench --units` option as I now believe it is better to
encourage users to use core functionality for formatting duration (which
I had not thought of initially) and to avoid multiplying `--options`.
```
bench -n 10 {sleep 0.1sec} | format duration ms mean min max stddev
# or
bench -n 10 {sleep 0.1sec} | format duration ms ...($in | columns)
```
Also, I removed the option of `--sign-digits` and just hard-coded the
precision of conversion to the fourth significant digit (which will give
a maximum relative error of 0.05%, which I still think is unnecessarily
precise).
To explain my motivation, I added some context from our previous
conversation:
>> Maybe you would agree with me that this representation is very wordy
and unnecessary, even for a professional?
>> `1sec 333ms 333µs 333ns`
> maybe, but then i would argue the issue comes from the formatting
nushell does on durations, not from std bench, it's just that Nushell
will show every part of the duration 😕
And I add here that if Nushell adds the setting for resetting
insignificant digits from displaying, those conversions could be removed
for the better. Yet, we don't have such a setting yet, but we already
use bench and use it quite often. So, I propose this usability
improvement.
In my defense, I would add that the existing `--pretty` option will only
benefit from the proposed changes (while it can't benefit from `| format
duration ms`).
```diff
> bench {sleep (10sec / 3)} --rounds 2 --pretty
- 3sec 335ms 974µs 264ns +/- 1ms 108µs 748ns
+ 3sec 335ms +/- 1ms 108µs
```
Finally, I kept the `--list-timings` option because I strongly believe
that users much more often will not need expanded 50 lines of timing
results on their screen (which they can get rid of by adding `| reject
time` in the second execution of the `bench` command - but I would like
to avoid this second execution).
I won't be hurt if my proposed changes aren't accepted and applied to
mainstream. Yet, I feel like my initial PR is still valuable and will
benefit from my current PR's additions.
In the last `pr` there was an error, that I just discovered and fixed.
Also I added test for this case in future, and some test for negative
numbers
```
0 | signfificant digits 2
33 │
34 │ let insignif_position = $n - 1 - ($num | math abs | math log 10 | math floor)
· ──┬─ ────┬───
· │ ╰── 'math log' undefined for values outside the open interval (0, Inf).
· ╰── value originates from here
35 │
╰────
```
I'm sorry for hassle here 😞
This PR is part of porting all old scripts #221 and includes the
`stdlib_candidate` scripts
## 7 changed files
- `flatter.nu`
- `get-column.nu`
- `get-row.nu`
- `get-latest-release-linux.nu`
- `logging.nu`
- `nu_style.nu`
- `print.nu`
[Generated diff](https://www.diffnow.com/report/xmq4f) for command
because move broke it.
- No `file` prefix similar to other [filesystem
commands](https://www.nushell.sh/commands/categories/filesystem.html)
- Input paths instead of directory param for filters or globbing
- Record closure param with original path (`$in` is still stem)
- `--verbose` table output
- `--no-exectute` for dry run with `--verbose`
- Shorthand flags
- Parallel renaming for large directories
- More tests
@amtoine Request feedback 🙏🏼 Happy to revise ot revert anything!
```console
❯ bulk-rename -h
Rename bulk input files in parallel using a closure.
The reason behind this command is quite simple:
- Sometimes one receives a bunch of files with integer ids: 1, 2, 3, ...
- These ids come rarely with padding... i.e. 1 instead of 001 when there are 3-digit ids
- This means that file with id 9 will be sorted way after file with id 1000
This command allows to do such a task!
Examples:
Rename `.mise.toml` files to `.mise.local.toml` recursively
> glob **/.mise.toml | bulk-rename { str append .local }
Rename files in `/foo` with a name that has an id to have 3 digits with 0-padding
> ls /foo | bulk-rename { |path|
if $path.input.type == file {
$path.stem | parse "some_format_{id}"
| get 0
| update id { fill --alignment r --character 0 --width 3 }
| $"some_format_($in.id)"
}
# else skip dirs
}
Usage:
> main {flags} <update_stem>
Flags:
-v, --verbose - Show which files were renamed, if any
-n, --no-execute - Do not make any changes; add --verbose to see what would be made
whitespace bug: nushell/nushell#12264
-h, --help - Display the help message for this command
Parameters:
update_stem <closure()>: The code to rename the file stem: receives the old stem as input and a record param with both `stem` and `input` keys
Input/output types:
╭───┬───────────┬─────────────────────────────────╮
│ # │ input │ output │
├───┼───────────┼─────────────────────────────────┤
│ 0 │ list<any> │ nothing │
│ 1 │ list<any> │ table<old: string, new: string> │
╰───┴───────────┴─────────────────────────────────╯
```
- Move to directory for other `str` contributions
- Add simple `help` docs
- Simplify type check since only 2 cases are possible
@savente93 Are these okay?
Easier to review individual commits because of renames. Happy to provide
DiffNow links if helpful. Involved:
1. Moving scripts to a subdirectory
2. Copying `nupm.nuon` from another directory
3. Making modules work
4. Extracting tests
5. Fixing tests (related to nushell/nushell#12193)
To test first set up nupm then:
```console
nu_scripts on std-nupm-integration
❯ $env.NUPM_REGISTRIES.nupm_test = 'https://raw.githubusercontent.com/texastoland/nupm/registry-std-rfc/registry.nuon'
nu_scripts on std-nupm-integration
❯ nupm install std-rfc
╭──────────┬───────────────────────────────────────────╮
│ name │ std-rfc │
│ version │ 0.1.0 │
│ url │ https://github.com/texastoland/nu_scripts │
│ revision │ 65aa7cc │
│ path │ stdlib-candidate │
│ type │ git │
╰──────────┴───────────────────────────────────────────╯
Cloning into 'nu_scripts-4a047f13a05fe35393f3a8d73377b02c-65aa7cc'...
remote: Enumerating objects: 8015, done.
remote: Counting objects: 100% (822/822), done.
remote: Compressing objects: 100% (333/333), done.
remote: Total 8015 (delta 538), reused 641 (delta 445), pack-reused 7193
Receiving objects: 100% (8015/8015), 49.72 MiB | 23.12 MiB/s, done.
Resolving deltas: 100% (4605/4605), done.
Note: switching to '65aa7cc'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 65aa7cc Fix nupm test --dir stdlib-candidate
2024-03-12T20:42:49.462|INF|installing package std-rfc
nu_scripts on std-nupm-integration took 4s
❯ use std-rfc set-env
nu_scripts on std-nupm-integration
❯ set-env -h
Gracefully set an environment variable or merge a nested option.
...etc.
nu_scripts on std-nupm-integration
❯ nupm test --dir stdlib-candidate
Testing package /Users/texas/Developer/nu_scripts/stdlib-candidate
tests record filter-name predicate ... SUCCESS
tests record filter-value predicate ... SUCCESS
tests record list_merge ... SUCCESS
tests str append ... SUCCESS
tests fs file bulk-rename ... SUCCESS
tests str prepend ... SUCCESS
tests record filter-name text ... SUCCESS
Ran 7 tests. 7 succeeded, 0 failed.
```
Rewrite of nushell/nushell#12156 for jdx/mise#1763.
### Why?
Nushell philosophically omits a `set` list mutation. But `$env` is
inherently mutable leading to issues described in nushell/nushell#12148.
`set-env` provides such an operation exclusively for `$env`.
### What changed?
1. Explicit flag instead of implicit list concatenation
2. Expands updates to any `$env` field not only `$env.config`
### How is it used?
```yaml
❯ set-env -h
Gracefully set an environment variable or merge a nested option.
Examples:
Set $env.NUPM_HOME
> set-env NUPM_HOME $'($nu.home-path)/.local/share/nupm'
Add to $env.NU_LIB_DIRS
> set-env --append NU_LIB_DIRS $'($env.NUPM_HOME)/modules'
Set a nested config option
> set-env config.filesize.metric true
Add a config hook
> set-env -a config.hooks.pre_prompt 'ellie | print'
Usage:
> main {flags} <field> <value>
Flags:
-a, --append - Append to the previous value or wrap in a new list
-h, --help - Display the help message for this command
Parameters:
field <cell-path>: The environment variable name or nested option cell path
value <any>: The value to set or append
Input/output types:
╭───┬─────────┬─────────╮
│ # │ input │ output │
├───┼─────────┼─────────┤
│ 0 │ nothing │ nothing │
╰───┴─────────┴─────────╯
```
### How does it work?
```nushell
export def --env main [
field: cell-path
value: any
--append (-a)
]: nothing -> nothing {
# just an alias
def 'get or' [default field] {
get --ignore-errors $field | default $default
}
let value = if $append {
# append to the previous value or empty list
$env | get or [] $field | append $value
} else {
$value
}
# work around nushell/nushell#12168
let field = $field | to text | split row .
let value = match $field {
[_] => $value
# if cell path is nested
[$root, ..$field] => {
let field = $field | into cell-path
# reassigning $env would be an error
# merging reserved names like PWD would be an error
# so merge from 1 level deep instead
$env | get or {} $root | upsert $field $value
}
}
# avoid issues noted above
load-env { ($field | first): $value }
}
```
### Where are the tests?
Pending next PR for nupm integration.
i received an archive with files with integer ids in their names (1, 2,
...) but because these ids had no padding, the files were completely out
of order when sorting... e.g. 9 comes after 10 because 1 comes before 9
as a character 🤔
i wrote a command to rename a bulk of files in a directory with a
closure 😋
i was not really sure where to put it, so i created
`stdlib-candidate/fs.nu` 👍
Add a module to manipulate records.
It can be a potential candidate to nu's standard library ?
Take a look at the name of the functions to see if they respect naming
convention (or if you have better ideas of course 😉 )
As discussed in https://github.com/nushell/nushell/issues/10486 I've
added an stdlib-candidate folder where we can add scripts that might
want to be in std-lib at some point. Currently it only contains `str
append` and `str prepend` which work about how you'd expect. Thanks to
@amtoine for writing the initial function. I added a default branch that
just returns the input unaltered so it can be used more easily in the
middle of a pipe.