00:54 Altai-man_ joined 00:57 sena_kun left 01:11 leont left 02:00 Xliff left 02:47 chansen_ left 02:50 chansen_ joined 02:55 sena_kun joined 02:57 Altai-man_ left 04:54 Altai-man_ joined 04:57 sena_kun left 06:55 sena_kun joined 06:57 Altai-man_ left 08:51 camelCaser left 08:53 camelCaser joined 08:55 Altai-man_ joined 08:57 sena_kun left 09:10 MasterDuke left
lizmat Files=1306, Tests=111384, 216 wallclock secs (28.69 usr 8.55 sys + 3029.13 cusr 286.43 csys = 3352.80 CPU) 09:20
nine lizmat's law of spec test length: number of tests x rakudo speed ~~ 220s 09:23
lizmat interesting :-) 09:24
Altai-man_ lizmat, hi! 09:26
09:27 leont joined
lizmat Altai-man_ o/ 09:27
.oO( uh oh, what did I break? )
Altai-man_ lizmat, I know Saturday is not the best day, but can I request more playing with IO::Path.dir?
It seems github.com/rakudo/rakudo/commit/48...b8a969e89f breaks File::Copy module.
lizmat will look at it now 09:28
Altai-man_ I am not sure if revert is wise, because that apparently fixed something else. :S
Thank you!
lizmat Altai-man_: the commit fixed a number of cases AlexDaniel pointed out, that weren't tested before
but which now have tests, so reverting does not appear to be an option 09:29
Altai-man_ lizmat, gist.github.com/Altai-man/9f3ebc60...9aecb584df <- is the log.
Altai-man_ tries it out locally 09:32
lizmat the tests are using dirs in the form: ./t/foo, which now get cleaned up to t/foo 09:36
Altai-man_ Can we help it or? 09:38
lizmat looking at it now 09:39
looks like the test gets the original IO paths, not the destination IO Paths 09:40
ok, I think I see what the problem is 09:49
the test calls "strip-dir", which uses the uncleaned version of the dir 09:50
09:51 MasterDuke joined
lizmat so it *looks* like we *should* revert, as the internal cleaning of IO does *not* change the outside 09:51
Geth roast: 7661e76fc7 | (Elizabeth Mattijsen)++ | S32-io/dir.t
Revert "Add some tests for dirty dir specififications"

This reverts commit cfe16b93c634bcbbfa071211cd162bf4bda86dc2.
The associated Rakudo commit also got reverted.		 09:59
rakudo: e231558c46 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Revert "Make sure we dir with a clean slate"

This reverts commit 484f07443ea146a49f9fd34d1a5e5fb8a969e89f.
Causes ecosystem breakage. Apparently, we should *not* use a cleanedup representation, as that breaks expectancy of what will be returned for the directory entries.
Altai-man_ lizmat++ # thank you! 10:00
lizmat Altai-man_: hmmm... the revert broke another spectest 10:08
S32-io/dir.t 10:09
Altai-man_ New tests or old ones?
I am now preparing a moarvm release, so no hurry, technically we have time to fix it until evening. Not end of the world if delay, of course. 10:10
lizmat hmmm... can't reproduce 10:11
ah.... I guess that was a pre-revert test 10:12
*phew*
so all green again
Altai-man_ Ooh, thank goodness.
This is probably over-cautious (can you even be so?), but I'm running Blin again with this. 7 hours is not so long and at the same time it adds some time between moarvm and rakudo releases for me to get a life. 10:16
releasable6, status 10:18
releasable6 Altai-man_, Next release in ≈8 hours. There are no known blockers. 143 out of 304 commits logged (⚠ 4 warnings)
AlexDaniel` so we're not back to the previous behavior?
releasable6 Altai-man_, Details: gist.github.com/ca4cb4ba4317ac1290...a9f24b0658
Altai-man_ AlexDaniel`, you mean the one that broke another module?
There is "Old (working)", "New (broken)", "New (fixed)" (<- after the last revert we are here), "New 2 (Broken)" (we were here just an hour ago. 10:20
AlexDaniel` c: 2020.05.1,HEAD dir("/tmp/.").sort.say
committable6 AlexDaniel`, gist.github.com/183421291af54f365a...682a1edef0
AlexDaniel` c: 2020.05.1,HEAD say dir("///").sort 10:21
committable6 AlexDaniel`, gist.github.com/e035f388a05f3a37c2...5197ae0600
Altai-man_ stops blin 10:22
AlexDaniel` technically both are valid paths, but it was working differently before… 10:24
lizmat 484f07443ea146a49f9fd34d1a5e5fb8a969e89f changed semantics to accommodate the "dirty" paths that AlexDaniel` had found 10:25
I've reverted that
10:25 JJMerelo joined
lizmat we need to discuss options here *after* the release 10:25
the behaviour of accepting dirty paths for dir seems to be what module authors expect 10:26
if they want clean dirs, they should call .cleanup themselves
aka "./foo".IO.cleanup.dir 10:27
AlexDaniel` why did it change?
lizmat why did what change ? 10:28
AlexDaniel` the behavior
compared to the last release
lizmat the timeline is like this, to my recollection: 10:29
1. /me makes dir a lot faster
2. blin finds it breaks IO::Glob 10:30
3. turns out the speedup was caused by dirs of / not being handled correctly
4. /me fixes that
5. AlexDaniel points out that other paths such as "///" and "foo/../bar" do not produce clean results 10:31
6. /me adds a .cleanup internally to make that clean
7 /me adds tests for that
8. 7blin finds that it breaks IO::Copy
9. /me reverts additional .cleanup call internally 10:32
10. /me reverts tests for dirty paths
so we're back at 4.
AlexDaniel` and we're back to (5) with me pointing out that the behavior changed compared to the last release 10:33
lizmat but did it ?
Altai-man_ It did.
m: dir("/tmp/.").sort.say
camelia ("/tmp/./.ICE-unix".IO "/tmp/./.Test-unix".IO "/tmp/./.X11-unix".IO "/tmp/./.XIM-unix".IO "/tmp/./.font-unix".IO "/tmp/./.precomp".IO "/tmp/./bla".IO "/tmp/./evalbot-file-002P854eer".IO "/tmp/./evalbot-file-00_X3XPHzv".IO "/tmp/./evalbot-file-02vOJPVa…
Altai-man_ c: 2020.05 dir("/tmp/.").sort.say 10:34
committable6 Altai-man_, ¦2020.05: «("/tmp/57fpHgZ5_D".IO "/tmp/83zCyW1Zw0".IO "/tmp/8_uy6app89".IO "/tmp/GI9oILAM1p".IO "/tmp/UHRTkfi3NR".IO "/tmp/XTiCHc7M76".IO "/tmp/ZjXseonYNg".IO "/tmp/aAbWI5qr2Z".IO "/tmp/ctGzXCm43f".IO "/tmp/qBpjxL3Ojm".IO "/tmp/whateverable".IO)␤»
AlexDaniel` c: 2020.05.1,HEAD my $path = ‘/usr/’; $path ~= ‘/local’; say dir($path).sort 10:35
committable6 AlexDaniel`, gist.github.com/79afc940280bc49c6c...34fe19dae2
AlexDaniel` if you want a realistic example that is relatively common in real life, here it is ↑
it's as simple as appending ‘/foo’ when something already had a slash at the end. I know there's .add in Raku, but people work with strs sometimes 10:36
lizmat c: 2020.05 dir("/tmp/..").sort.say 10:40
committable6 lizmat, gist.github.com/14e854ae2121d4ccc2...083ab4676a
lizmat ok, I can see how /. is incorrect 10:49
however, I don't think that /usr//local is a problem that dir() should fix
or /usr/./local for that matter
I think that's a case of garbage in / out 10:50
if you don't want garbage, cleanup your IO::Path with .cleanup
Altai-man_ lizmat, can we get back to 2020.05 way of things? 10:51
10:52 JJMerelo left
lizmat
.oO( that should teach me *again* to do anything IO related )
 10:54
10:56 sena_kun joined 10:57 Altai-man_ left 10:58 JJMerelo joined
lizmat so should: "./foo".IO.dir produce "./foo/bar" or "foo/bar" ? 11:00
sena_kun AlexDaniel` ^^
sena_kun 2020.05 produced "./foo/bar". 11:01
MasterDuke anything that touches filesytems, filenames, etc. is fraught with complications/complexity. i think there was good reason zoffix did that big chunk of work as a grant
lizmat that is not the answer
and gave the grant back in the end, no ? MasterDuke 11:02
and that's also spent about 3 months of my life on a newio branch
MasterDuke hm. wasn't that the Rat grant?
lizmat that got flushed
ah, could be 11:03
sena_kun lizmat, we want to be compatible with existing code and avoid visible changes for the user, so I would say `./foo/bar` is the answer.
But yes, this is a complex matter.
MasterDuke blogs.perl.org/users/zoffix_znet/20...grant.html 11:04
AlexDaniel` lizmat: I think it is the answer. Both are valid paths but someone can have an `is $path, ‘…’` test in their code and you'd be breaking it
lizmat well, that is what broke File::Copy's testing
AlexDaniel` not sure I understand? File::Copy's tests were working fine on 2020.05 ? 11:06
lizmat yes 11:08
adding the .cleanup broke them 11:09
sena_kun bisectable6, 2020.5,HEAD dir("/tmp/.").sort.say 11:14
bisectable6 sena_kun, Will bisect the whole range automagically because no endpoints were provided, hang tight
sena_kun erm 11:15
bisectable6, help
bisectable6 sena_kun, ¦6c (43 commits): «04===SORRY!04=== Error while compiling /tmp/hJINN2DhEI␤Undeclared name:␤ HEAD used at line 1␤␤ «exit code = 1»»
sena_kun, Nothing to bisect!
sena_kun, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: github.com/Raku/whateverable/wiki/Bisectable
AlexDaniel` ok that looks like a bug
ah no
sena_kun bisectable6, old=2020.5 new=HEAD dir("/tmp/.").sort.say
bisectable6 sena_kun, Cannot find revision “2020.5” (did you mean “2020.05”?) 11:16
AlexDaniel` not a bug
sena_kun bisectable6, old=2020.05 new=HEAD dir("/tmp/.").sort.say
AlexDaniel` sena_kun: 2020.5 is not a valid release
bisectable6 sena_kun, Bisecting by output (old=2020.05 new=e231558) because on both starting points the exit code is 0
sena_kun, bisect log: gist.github.com/dc635a3573d5d446fc...788ea8bea6
sena_kun, (2020-05-03) github.com/rakudo/rakudo/commit/2b...a48530fc19
AlexDaniel` the output is random 11:17
my messages are a bit delayed 😇 11:18
sena_kun Yeah.
bisectable6, old=2020.05 new=HEAD dir("/boot/..").sort.say 11:19
bisectable6 sena_kun, On both starting points (old=2020.05 new=e231558) the exit code is 0 and the output is identical as well
sena_kun, gist.github.com/e6043673343e329665...b296563a31
sena_kun bisectable6, old=2020.05 new=HEAD dir("/boot/.").sort.say 11:20
bisectable6 sena_kun, Bisecting by output (old=2020.05 new=e231558) because on both starting points the exit code is 0
sena_kun, bisect log: gist.github.com/a0f158cf6db8a26fc8...1388b8494d
sena_kun, (2020-05-21) github.com/rakudo/rakudo/commit/b6...0d84535de8
sena_kun So it does point to b63976a8f19e650fe3533562a5fa040d84535de8 after all. 11:21
linkable6 (2020-05-21) github.com/rakudo/rakudo/commit/b63976a8f1 Make IO::Path.dir between 1.5x and 2.2x as fast
lizmat yeah, *that* is clear
so to fix that, I added a .cleanup internally to clean up the path for which to create a dir
and *that* broke IO::Copy
I have a fix for trailing /. 11:22
sena_kun I think the trailing `/.` is the main issue we can spot, no?
lizmat no, because apparently "foo/../bar/ should also produce "bar/baz" and not "foo/../bar/baz" ? 11:23
sena_kun I don't think so.
For me on 2020.05 running `'Work/../Work'.IO.dir` returns paths like `"Work/../Work/foo".IO`. 11:24
Geth rakudo: 9b9d9f64ed | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Correct trailing '/." in dir
11:24 ShimmerFairy left 11:25 ShimmerFairy joined
lizmat that should take care of the "foo/.".IO.dir issue, keep "foo/../bar/" returning "foo/../bar/baz" 11:25
sena_kun Awesome. I am running blin ASAP. 11:26
lizmat but this will *not* fix "///" 11:27
or "foo//bar" 11:28
sena_kun m: '///'.IO.dir.sort.say; 11:29
camelia ("///bin".IO "///boot".IO "///dev".IO "///etc".IO "///home".IO "///lib".IO "///lib64".IO "///mnt".IO "///opt".IO "///proc".IO "///root".IO "///run".IO "///sbin".IO "///selinux".IO "///srv".IO "///sys".IO "///tmp".IO "///usr".IO "///var".IO)
sena_kun I see.
lizmat or we should decide we *do* want .cleanup, just not for the "./" in ./"foo" case 11:30
sena_kun So people relied on partial cleaning we did before. Now we can either have full cleaning, which breaks, or bent backwards horribly to fix some cases.
lizmat, I would say let's release with 0 ecosystem breakage for now and specify the situation in changelog special notes. Then we can do a full cleanup in next release and make it breaking, patch modules etc. 11:32
lizmat that's a thought: or we could just not allow IO::Path's to be created that are dirty
but the checks for that would come at a significant performance price 11:33
which is why I think we shouldn't be cleaning up paths involuntarily at all
and adding .cleanup internally to dir() was a mistake
afk for half an hour or so 11:37
12:05 Xliff joined 12:08 JJMerelo left 12:45 lichtkind joined
ShimmerFairy In general, I would say you should only do as much automatic cleaning as is necessary to make doing IO stuff not a nightmare. As long Raku can traverse directories and open files, you shouldn't clean things up by default if you don't have to. 12:49
lizmat ShimmerFairy: so should "foo/." produce "foo/bar" or "foo/./bar" in that case ? 12:50
ShimmerFairy foo/./bar unless it costs nothing to simplify that, or your IO implementation for whatever reason chokes on that path string. I personally am fine with doing a $path.cleanup.Str whenever I want a "display path", but I can understand other people not being happy with that. 12:52
(maybe string-ifying a path can call cleanup() internally so that people always see a nice path outside of an IO object) 12:53
Xliff sena-kun AlexDaniel: Can you point me to a project that uses %?RESOURCES 12:54
12:55 Altai-man_ joined 12:57 sena_kun left
lizmat ShimmerFairy: it appears either spectest / ecosystem expects "foo/bar" 12:58
ShimmerFairy: if cleaning up a path would be cheap, I would agree
but it isn't :-( 12:59
ShimmerFairy Yeah, it's worth noting that I'm talking about a perfect world where you don't care about backward compatibility, or where you can safely chuck changes behind a 'use v6.e' 13:00
In general, I think ideally IO shouldn't simplify paths unless either a) the user calls .cleanup() or whatever it's actually called, or b) the user wants to stringify the object in some way (e.g. $path.Str or $path.gist causing a cleanup to happen and then be cached) 13:01
lizmat afk for a few hours& 14:41
14:56 sena_kun joined 14:57 Altai-man_ left
nine foo/../bar is NOT equal to foo/bar 15:03
err... foo/./bar
ShimmerFairy isn't it though? 15:04
nine needs to exit train 15:05
15:44 JJMerelo joined
JJMerelo releasable6: status 15:44
releasable6 JJMerelo, Next release in ≈3 hours. There are no known blockers. 143 out of 305 commits logged (⚠ 4 warnings)
JJMerelo, Details: gist.github.com/376e86b3da286f0524...ef5db022fe
sena_kun Ouch, 3 hours. 15:47
JJMerelo I'm trying to run a raku program from a test. If I do raku t/00-basic.t it works, but if I do zef test . it does not find raku 16:21
The PATH of the shell is inherited from, well, the shell to whatever, but somewhere in zef it gets lost... 16:22
m: say $*RAKU 16:25
camelia Raku (6.d)
JJMerelo m: say $*RAKU.raku
camelia Raku.new(compiler => Compiler.new(id => "F809199F1E0AF9667C594B6434325AD139D37F83", release => "", codename => "", name => "rakudo", auth => "The Perl Foundation", version => v2020.05.1.305.g.9.b.9.d.9.f.64.e, signature => Blob, desc => Str), name => …
JJMerelo m: say $*EXECUTABLE
camelia "/home/camelia/rakudo-m-inst-1/bin/perl6-m".IO
JJMerelo well, that works but now it does not find the installed libraries... 16:26
nine Ok, looks like I was wrong about /. 16:28
16:32 ShimmerFairy left 16:33 ShimmerFairy joined 16:55 Altai-man_ joined 16:57 sena_kun left
nine Oh, it's use lib that's breaking NativeCall tests with in-process precompilation 17:36
lizmat nine: what's the difference between "foo/bar" and "foo/./bar" ? 17:45
nine lizmat: none, I was in error 17:46
lizmat ah, ok *phew* :-)
nine I thought I remembered some obscurity, but research proved me wrong
18:06 patrickb joined 18:36 Xliff left
lizmat m: "ab" ~~ /(a) $<b>=b/; say $/.keys # should this always be (0 b) or can it also be (b 0) ? 18:42
camelia (0 b)
lizmat it appears we have a spectest for the behaviour of always returning (0 b) 18:43
Altai-man_ releasable6, status 18:45
releasable6 Altai-man_, Next release is just a few moments away. There are no known blockers. 305 out of 305 commits logged (⚠ 4 warnings)
Altai-man_, Details: gist.github.com/c7e5f37c58a3add183...deb9c04354
18:55 sena_kun joined
sena_kun releasable6, status 18:55
releasable6 sena_kun, Next release is just a few moments away. There are no known blockers. 305 out of 305 commits logged (⚠ 4 warnings)
sena_kun, Details: gist.github.com/662a82b8e44f205fb1...48b667a066
sena_kun Anyone who can help a lot by spending some time proofreading (and fixing grammar) the changelog? 18:56
lizmat I never remember the URL of the draft change log 18:57
18:57 Altai-man_ left
sena_kun github.com/rakudo/rakudo/wiki/ChangeLog-Draft 18:58
MasterDuke sena_kun++ 19:01
lizmat sena_kun: c0b5fb28 is from Nov ? 19:04
and it's the *output" that's simpler ? 19:05
sena_kun: re 077300c5 I would add "when splitting using a regex" 19:07
linkable6 (2020-06-15) github.com/rakudo/rakudo/commit/077300c56c Make sure push-all doesn't push when exhausted
sena_kun lizmat, it is, but it was merged only for this release. 19:13
I mean, we don't immediately merge all PRs, so sometimes commits from Nov are in Jun. :)
lizmat, anything else? 19:14
lizmat perhaps mention ".raku" for c0b5fb28 , mentioning .perl there now is confusing 19:15
linkable6 (2019-11-05) github.com/rakudo/rakudo/commit/c0b5fb282c Make Instant.perl a bit less noisy
sena_kun lizmat, fixed 19:16
lizmat sena_kun: why isn't b63976a8f1 mentioned?
linkable6 (2020-05-21) github.com/rakudo/rakudo/commit/b63976a8f1 Make IO::Path.dir between 1.5x and 2.2x as fast
lizmat because that was the previous release ? 19:17
sena_kun lizmat, erm, it is.
Make IO::Path.dir between 1.5x and 2.2x as fast [b63976a8][6b22c1eb][7691742a][9b9d9f64]
lizmat he... so we didn't notice any issues with that in the previous release 19:18
odd
ah
ok, misunderstood
sena_kun lizmat, no, it wasn't in the previous release
lizmat hmmm... maybe mention 700b7432 together with b63976a8f1 19:19
linkable6 (2020-05-24) github.com/rakudo/rakudo/commit/700b74329d Make dir() about 15% faster
(2020-05-21) github.com/rakudo/rakudo/commit/b63976a8f1 Make IO::Path.dir between 1.5x and 2.2x as fast
lizmat as the 1.5x to 2.2x *also* applies to "dir"
it's just that the sub version has become 15% faster *on top* of that
sena_kun I was not bothered enough to calculate^A^K Hmm. 19:20
lizmat hehe... 19:21
then just put the "dir" one *after* the IO::Path.dir one
sena_kun done
lizmat that's it from me 19:22
sena_kun lizmat, thanks!
1473 out of 1478 modules processed (left: Spreadsheet::XLSX Cro::HTTP::Session::Red Async::Workers Vikna LibXSLT) 19:23
Geth roast: 410354de4b | (Elizabeth Mattijsen)++ | S05-match/capturing-contexts.t
Fix test depending on not having a Match.keys

It might in the future, so change the name of the method we're adding to the Match class		 20:12
gfldex raku: class C { has $.a = s; } 20:52
evalable6 (exit code 1) 04===SORRY!04===
Nu…
gfldex, Full output: gist.github.com/32369c026dc9a35a37...88df402de0
gfldex does rakudo think I wanted to write `= s///`?
raku: class C { has $.a = soso; } 20:54
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/kXZXJlzhpv
Undeclared routine:
soso used at line 1
gfldex this is kinda bizzar :->
raku: class C { has $.a = s(); }
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/BCRKLwjoJZ
Undeclared routine:
s used at line 1
20:55 Altai-man_ joined
gfldex .oO( taking the wrong turn in a Grammar … ) 20:55
should I file an LTA for this one? 20:56
20:58 sena_kun left
Geth roast/6.d-errata: 8 commits pushed by (Elizabeth Mattijsen)++, (Donald Hunter)++ 21:33
22:26 JJMerelo left
Geth roast/6.c-errata: 4 commits pushed by Altai-man++, (Donald Hunter)++, (Elizabeth Mattijsen)++ 22:27
rakudo/release-2020.06: 14ba3cf5f7 | Altai-man++ | 3 files
Update changelog + announcement

Deliberately not logged:
46648b9 fe14bcb 0d238d8 40fdfee 002acb1 25f8395 c8570e8 45df9bc e1cefec 7bace1b 8134470 f11d750 dac68b2 2b6a582 3d2522e 43c1f50 5965cc3 4a3f29d d7ce52b 0ca0f58 649ef23 9a583dc 8eb7214 e95eb3a ... (10 more lines)		 22:48
22:56 sena_kun joined 22:57 Altai-man_ left 23:52 leont left, patrickz joined 23:54 lichtkind left 23:56 patrickb left
Geth nqp: 0cf2166d6a | Altai-man++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2020.06
 23:57
nqp: 059418f2f3 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.06
rakudo/release-2020.06: 3434ad69f2 | Altai-man++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2020.06
rakudo/release-2020.06: eda1a4b477 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.06
rakudo: Altai-man++ created pull request #3763:
Release 2020.06		 23:58
rakudo/master: 4 commits pushed by Altai-man++

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!