Closed coke closed 3 weeks ago
The test passes, but the uninitialized
warning appears with any invocation of the command line. Running any command in the checked out dir gives the uninitialized warnings and zero output.
I've just uploaded 0.97 to fez. Could you try again with that version?
Running 0.98 here, and still getting many uninitialized warnings running rak.
I think these are because of
$ raku -e 'dd $*USER'
Any
Looks like no matches are being returned when they are possible. I can see the help now, but 'rak criteria path' that should return hits (does with grep -r) just gives uninitialized warnings.
Could you screen dump / post the exact warnings?
C:\>rak
Use of uninitialized value of type Any in numeric context
in code at C:\raku\share\perl6\site\sources\93FA4B124BD2B78D35904277206B994A789307B7 (path-utils) line 4
Use of uninitialized value of type Any in numeric context
in code at C:\raku\share\perl6\site\sources\93FA4B124BD2B78D35904277206B994A789307B7 (path-utils) line 5
Must at least specify a pattern.
Update
if I run this in a command prompt, I get the warnings, AND I get results when I use, e.g. 'rak test'
However, if I use git bash (another shell available on windows), I am now getting an error with less detail and then it's hanging:
$ rak depend META6.json
Use of uninitialized value of type Any in numeric context
<hangs here>
Not sure why it's behaving differently between the two shells, or why the failure mode in git bash seems to have changed.
If we can avoid the warnings in the path-utils, then at least we'd get a pretty functional version when running in a command prompt.
The path-utils warnings should be gone now
zef upgrade App::Rak
is failing with:
$ zef upgrade App::Rak
===> Searching for: App::Rak
===> Updating fez mirror: https://360.zef.pm/
The following distributions will be upgraded: App::Rak:ver<0.1.1>:auth<zef:lizmat>
===> Updating: App::Rak:ver<0.1.1>:auth<zef:lizmat>
[https://360.zef.pm/A/PP/APP_RAK/a61921c2adb3295cff6f75f38b18216dbf7d8605.tar.gz] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
===> Searching for missing dependencies: highlighter:ver<0.0.15>:auth<zef:lizmat>, rak:ver<0.0.31>:auth<zef:lizmat>
===> Searching for missing dependencies: Git::Files:ver<0.0.3>:auth<zef:lizmat>, path-utils:ver<0.0.10>:auth<zef:lizmat>
[Git::Files] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
!!!> Failed upgrading *all* modules
===> Updated fez mirror: https://360.zef.pm/
Cannot create a Zef::Distribution from non-existent path: C:\Users\wcoleda\AppData\Local\Temp/.zef\0d40a06c5dc2634f9d3a2b176f48cbcbf556b06c.tar.gz\rak-0.0.31/META6.json
Similar failure with uninstall/install
$ zef install App::Rak
===> Searching for: App::Rak
Cannot create a Zef::Distribution from non-existent path: C:\Users\wcoleda\AppData\Local\Temp/.zef\0d40a06c5dc2634f9d3a2b176f48cbcbf556b06c.tar.gz\rak-0.0.31/META6.json
===> Searching for missing dependencies: highlighter:ver<0.0.15>:auth<zef:lizmat>, rak:ver<0.0.31>:auth<zef:lizmat>
===> Searching for missing dependencies: Git::Files:ver<0.0.3>:auth<zef:lizmat>, path-utils:ver<0.0.10>:auth<zef:lizmat>
[App::Rak] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
[Git::Files] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
What happens if you do a zef upgrade rak
?
Basically the same:
$ zef upgrade rak
===> Searching for: rak
Cannot create a Zef::Distribution from non-existent path: C:\Users\wcoleda\AppData\Local\Temp/.zef\0d40a06c5dc2634f9d3a2b176f48cbcbf556b06c.tar.gz\rak-0.0.31/META6.json
The following distributions will be upgraded: rak:ver<0.0.31>:auth<zef:lizmat>
===> Updating: rak:ver<0.0.31>:auth<zef:lizmat>
!!!> Failed upgrading *all* modules
OOC, and a sequence of:
$ zef uninstall rak
$ zef install rak
?
$ zef uninstall rak
===> Uninstalled from inst#C:\raku\share\perl6\site
rak:ver<0.0.26>:auth<zef:lizmat>
rak:ver<0.0.22>:auth<zef:lizmat>
$ zef install rak
===> Searching for: rak
===> Updating fez mirror: https://360.zef.pm/
===> Searching for missing dependencies: Git::Files:ver<0.0.3>:auth<zef:lizmat>, path-utils:ver<0.0.10>:auth<zef:lizmat>
[rak] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
[Git::Files] Extracting with plugin Zef::Service::Shell::tar+{<anon|1>} aborted.
===> Testing: path-utils:ver<0.0.10>:auth<zef:lizmat>
===> Testing [OK] for path-utils:ver<0.0.10>:auth<zef:lizmat>
===> Testing: Git::Files:ver<0.0.3>:auth<zef:lizmat>
===> Testing [OK] for Git::Files:ver<0.0.3>:auth<zef:lizmat>
===> Testing: rak:ver<0.0.32>:auth<zef:lizmat>
===> Testing [OK] for rak:ver<0.0.32>:auth<zef:lizmat>
===> Installing: path-utils:ver<0.0.10>:auth<zef:lizmat>
===> Installing: Git::Files:ver<0.0.3>:auth<zef:lizmat>
===> Installing: rak:ver<0.0.32>:auth<zef:lizmat>
===> Updated fez mirror: https://360.zef.pm/
Tried the App::Rak install again, similar failure (but this time the Git::Files dep was already installed as noted here).
Don't know why git::Files complained here but then ALSO installed.
Install worked. @ugexe suggested it might have been a path length issue on windows, but managed to get an install without hitting it.
Latest issue: rak project subdir
emits Unexpected leftovers: {:paths($["subdir"])}
and then hangs (whether or not subdir exists).
$ rak --version
rak - provided by App::Rak 0.1.3, running Raku 6.d with Rakudo 2022.04.42.
Updated rakudo to HEAD, no change - but the error above is visible in 'git bash' only. when running in a CMD prompt or powershell, it does work - no error, but the output isn't great:
C:\dev\rak-test>rak test test.md
test.md
1:This is a [1mtest[22m
this is after setting 'chcp 65001` which is required on windows to process unicode - I assume these are *nix specific color codes, not unicode quotes?
Testing a generic Terminal::ANSIColor script, I find that the sequences work in git bash, but generate the other output on powershell/CMD. Related: https://github.com/tadzik/Terminal-ANSIColor/issues/17
I suspect the easiest fix here is to avoid bold in the case of CMD/powershell (skipping for all of windows for now probably easiest); running with --no-highlight
generates the expected output.
git bash appears to be trying to read from stdin. This works:
cat README.md | rak rak --highlight
AAAAhhhhh... ok.
Could you check what the value of $*IN.t
is in raku -e 'say $*IN.t'
Good catch - that returns True in powershell & CMD, but False in 'git bash'
We already figured this out in https://github.com/rakudo/rakudo/issues/4378
ok, now on to recognizing when running in PowerShell & CMD...
or find a way to get Powershell to return True for $*IN.t
when there's someone typing :-)
Closing this in light of the Rakudo issue
on c5aeee1 on main, seeing the following test failures on windows: