main doesn't work on windows.

[coke]

on c5aeee1 on main, seeing the following test failures on windows:

$ zef test .
===> Testing: App::Rak:ver<0.0.96>:auth<zef:lizmat>
[App::Rak] Use of uninitialized value of type Any in numeric context
[App::Rak]   in code  at C:\raku\share\perl6\site\sources\917BB35F93E417835CF3E5D3AFB4D749AA5CF677 (path-utils) line 4
[App::Rak] Use of uninitialized value of type Any in numeric context
[App::Rak]   in code  at C:\raku\share\perl6\site\sources\917BB35F93E417835CF3E5D3AFB4D749AA5CF677 (path-utils) line 5
===> Testing [OK] for App::Rak:ver<0.0.96>:auth<zef:lizmat>

$ raku --version
Welcome to Rakudo™ v2022.04-42-ge9de06b85e.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2022.04.

$ zef --version
v0.14.2

[coke]

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.

[coke]

See https://github.com/rakudo/rakudo/issues/5066

[lizmat]

I've just uploaded 0.97 to fez. Could you try again with that version?

[coke]

Running 0.98 here, and still getting many uninitialized warnings running rak.

I think these are because of

$ raku -e 'dd $*USER'
Any

https://github.com/rakudo/rakudo/issues/5066

[coke]

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.

[lizmat]

Could you screen dump / post the exact warnings?

[coke]

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.

[coke]

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.

[lizmat]

The path-utils warnings should be gone now

[coke]

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.

[lizmat]

What happens if you do a zef upgrade rak ?

[coke]

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

[lizmat]

OOC, and a sequence of:

$ zef uninstall rak
$ zef install rak

?

[coke]

$ 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.

[coke]

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.

[coke]

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?

[coke]

https://github.com/lizmat/App-Rak/blob/main/lib/App/Rak.rakumod#L12-L14.

[coke]

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.

[coke]

git bash appears to be trying to read from stdin. This works:

cat README.md | rak rak --highlight

[lizmat]

AAAAhhhhh... ok.

Could you check what the value of $*IN.t is in raku -e 'say $*IN.t'

[coke]

Good catch - that returns True in powershell & CMD, but False in 'git bash'

[coke]

We already figured this out in https://github.com/rakudo/rakudo/issues/4378

[lizmat]

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 :-)

[lizmat]

Closing this in light of the Rakudo issue