00:44 squashable6 left 00:46 squashable6 joined 00:47 squashable6 left 00:50 squashable6 joined 00:54 Altai-man_ joined 00:56 sena_kun left 02:55 sena_kun joined 02:56 Altai-man_ left 04:53 committable6 left, nativecallable6 left, quotable6 left, coverable6 left, unicodable6 left, squashable6 left, bloatable6 left, sourceable6 left, linkable6 left, tellable6 left, notable6_ left, greppable6 left, statisfiable6 left, reportable6 left, evalable6 left, shareable6 left, releasable6 left, bisectable6 left, evalable6 joined, bloatable6 joined, linkable6 joined, shareable6 joined 04:54 reportable6 joined, committable6 joined, tellable6 joined, Altai-man_ joined, statisfiable6 joined 04:55 nativecallable6 joined, squashable6 joined, bisectable6 joined, greppable6 joined, releasable6 joined 04:56 unicodable6 joined, quotable6 joined, notable6 joined, coverable6 joined, sourceable6 joined, sena_kun left
Kaeipi greppable6, .sub_signature 06:36
greppable6 Kaeipi, 3 lines, 3 modules: gist.github.com/fe7d21ff9b6bc2557f...21eab0b6d6
06:55 sena_kun joined 06:57 Altai-man_ left
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
08:39 leont_ joined, leont joined 08:54 Altai-man_ joined 08:56 sena_kun left
Geth rakudo: Kaiepi++ created pull request #3760:
Type Parameter's methods		 09:30
rakudo: Altai-man assigned to patrickbkr Issue rakudo/repl.t fails consistently on Windows github.com/rakudo/rakudo/issues/3761
6b22c1eb4d | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6

The logic finding out what to prefix each directory entry with, was flawed if the "/" was the path (well, actually the directory separator). This fixes IO::Glob (*phew*)
09:40 JJMerelo joined
JJMerelo Anyway, I'm going to try and see why it didn't fail before and it does now. Which is the whole point, I guess. 09:41
I mean, IO::Glob.
Altai-man_ JJMerelo, this is a nice idea, at least golfing the issue may be helpful for bisecting. 09:45
JJMerelo My hunch is that it's what's returned by the call, which was underspecced 09:51
But let's get down to it.
lizmat well, I think I've found it 09:54
or at least something that is icky 09:55
github.com/zostay/raku-IO-Glob/blo...lute.t#L20
that line does a grep on: none("$root-dir.","$rootdir..") 09:56
now, effectively that tests on "/." and "/.." 09:57
hmmmm
it's not the test of the dir, just a grep... ok, sorry for the noise
JJMerelo lizmat but it's also the dir 09:59
lizmat yeah, I have a hunch now 10:00
JJMerelo m: now it returns the values with "/" in front, before it didn't
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3now7⏏5 it returns the values with "/" in front
expecting any of:
infix
infix stopper
statement end
statemen…
JJMerelo m: dir("/").sort
camelia ( no output )
Altai-man_ m: say dir("/").sort 10:01
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)
Altai-man_ committable6, say dir("/").sort
committable6 Altai-man_, Seems like you forgot to specify a revision (will use “v6.c” instead of “say”)
Altai-man_ committable6, v6.c dir("/").sort 10:02
committable6 Altai-man_, gist.github.com/e781c1cf46019cf2fd...29815b7e4d
Altai-man_, ¦v6.c (43 commits): «»
Altai-man_ Yay
10:02 literal_ is now known as literal
Altai-man_ bisectable6, dir("/").sort.say 10:03
bisectable6 Altai-man_, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel Altai-man_: I don't understand this output, actually
aa ok now I understand it
bisectable6 Altai-man_, Output on all releases: gist.github.com/51dcb495e3db2b2636...1ec7f9e542
Altai-man_, Bisecting by output (old=2020.05.1 new=cd61724) because on both starting points the exit code is 0
Altai-man_, bisect log: gist.github.com/cb5ddcf7737eb30db0...18bf03f9ed
Altai-man_, (2020-05-21) github.com/rakudo/rakudo/commit/b6...0d84535de8
Altai-man_, Output on all releases and bisected commits: gist.github.com/4678be437e324766b6...c6e79e40fe
JJMerelo So that's the thing. 10:05
lizmat but that's actually never entered... 10:06
Altai-man_ BTW, that commit is different from the one found by Blin 10:11
Altai-man_ as I said, different problems with the module, at least two different ones.
Altai-man_ JJMerelo, it is the same commit. " Altai-man_, (2020-05-21) github.com/rakudo/rakudo/commit/b6...d84535de8" and "IO::Glob – Fail, Bisected: b63976a". 10:12
JJMerelo Ah, right, sorry. 10:13
lizmat hmmm... IO::Glob doesn't appear to call dir ?
JJMerelo lizmat only in the tests
Altai-man_ lizmat, we have a golf, so doesn't matter where is it. 10:14
lizmat ok, what is the golf?
Altai-man_ dir("/").sort.say
evalable6 ("bin".IO "boot".IO "dev".IO "etc".IO "home".IO…
Altai-man_, Full output: gist.github.com/e0871d5769e8e1274f...6878fe30e0
Altai-man_ lizmat, Output on all releases and bisected commits: gist.github.com/4678be437e324766b6...c6e79e40fe <- 10:15
JJMerelo I think that the problem is the added slash at the beginning of every path, basically
IO::Glob parses that, and does not find . and .. to skip, but /. and /.. 10:16
Altai-man_ Yes, we had it and now don't, so need to get it back.
lizmat ok, *that* I can work with :-)
JJMerelo Not clear if there was a spec for that. Because it's weird it didn't pop up in any test...
lizmat++ 10:17
Altai-man_ No spec, but in unix envs "foo" and "/foo" are very different paths anyway. No harm to have a test somewhere for it, though. 10:18
JJMerelo OTOH, since there was no spec, I'm not sure the former way was the good one. It makes much more sense the way it is now, not including the input path
m: say dir("/tmp").sort 10:19
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>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp>".IO "<tmp…
Altai-man_ Well, it is consistent this way.
I mean...
lizmat yeah, it should add the /
JJMerelo Altai-man_ it's time-wise consistent 10:20
Altai-man_ You type `dir("usr")` in / and get `usr/src`. But if you type `dir("/usr")` you get `/usr/src`. So you get the prefix you search for with or without /. And if user sets a prefix of `/`, it should be there to be consistent.
Otherwise we treat the prefix the same and then boom, for `/` there is an exception. We have enough special cases, really. 10:21
lizmat yeah, I agree that's what the optimization broke
JJMerelo Anyway, there's a test that can be added: the output to dir should include the input at the beginning.
lizmat JJMerelo: pretty sure there are, but not for "/" 10:22
JJMerelo lizmat you mean specs? 10:23
lizmat yeah
JJMerelo bisectable6: dir("/tmp").sort.say
bisectable6 JJMerelo, Will bisect the whole range automagically because no endpoints were provided, hang tight
JJMerelo, More than 4 changes to bisect, please try a narrower range like old=2020.05.1 new=HEAD 10:24
JJMerelo, Output on all releases: gist.github.com/d02a0fc7cb688c02b8...7479c7bbf6
lizmat bisectable6: say "/usr".IO.cloned-with-path("local")
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
JJMerelo OK, that was dumb.
bisectable6 lizmat, Output on all releases: gist.github.com/e2ef3d73f26413ab05...85778a17a7
lizmat, Bisecting by exit code (old=2020.05.1 new=cd61724). Old exit code: 1
lizmat, bisect log: gist.github.com/926101df8715d71f84...340145f23f 10:25
lizmat, (2020-05-21) github.com/rakudo/rakudo/commit/b6...0d84535de8
lizmat, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/44023e77d8f89adb66...1463cc9ba4
lizmat, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
lizmat, Output on all releases and bisected commits: gist.github.com/bc9d8870f3bffd737e...2c74d0e283
lizmat que?
JJMerelo bisectable6: dir("/usr/lib/").sort.say 10:26
bisectable6 JJMerelo, Will bisect the whole range automagically because no endpoints were provided, hang tight
JJMerelo, Nothing to bisect!
JJMerelo, Output on all releases: gist.github.com/215f74539741fcaf39...fb2fb2b736
JJMerelo bisectable6: dir("/usr/lib").sort.say 10:27
bisectable6 JJMerelo, Will bisect the whole range automagically because no endpoints were provided, hang tight
JJMerelo It only happens on /?
lizmat yeah, it only happens on / afaik
bisectable6 JJMerelo, Nothing to bisect!
JJMerelo, Output on all releases: gist.github.com/15a430f750067c3e5d...c36d90ada2
AlexDaniel lizmat: behavior change more than once since 2015.12, it bisected it twice
JJMerelo Which is why it only fails on IO::Glob, with works with / explicitly 10:28
AlexDaniel lizmat: the last link shows exactly what happened: gist.github.com/bc9d8870f3bffd737e...2c74d0e283
changed* 10:29
.oO( is my d key not working properly… )
lizmat ok, I think I've found my thinko 10:32
spectesting now 10:40
JJMerelo lizmat++ 10:49
Altai-man_ lizmat++, thank you very much!
JJMerelo downloading and testing IO::Glob
10:55 sena_kun joined 10:57 Altai-man_ left
JJMerelo Tested and working perfectly fine now. lizmat++ 11:01
Geth rakudo: 7691742ae5 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Simplify prefix logic

The "/" case is also handled by the .ends-with("/") case, so we don't need to check for it separately.		 11:03
JJMerelo lizmat: maybe add a test too? 11:11
lizmat working on that 11:12
11:12 JJMerelo left
lizmat feels to me S16-filehandles/dir.t can be removed from roast 11:13
Geth roast: 3eb1abdda6 | (Elizabeth Mattijsen)++ | S32-io/dir.t
Add test to prevent repeat of IO::Glob breakage
 11:17
AlexDaniel bisect: .say for dir("./.").sort 11:20
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel, Output on all releases: gist.github.com/0d034395e2c561bf92...dad9acba7b
AlexDaniel, Bisecting by output (old=2016.05 new=2016.06) because on both starting points the exit code is 0
AlexDaniel no no not that one…
bisectable6 AlexDaniel, bisect log: gist.github.com/a808f06fd96bb92df1...8c98892d06
AlexDaniel, (2016-05-22) github.com/rakudo/rakudo/commit/37...744c1872c2
AlexDaniel, ⚠ New output detected, please review the results manually 11:21
AlexDaniel, Output on all releases and bisected commits: gist.github.com/2113f62910428ee703...4e7dd13aa2
AlexDaniel bisect: dir("/tmp/.").sort.say
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel, More than 4 changes to bisect, please try a narrower range like old=2020.05.1 new=HEAD 11:22
AlexDaniel, Output on all releases: gist.github.com/f45e409dd2630e473f...54eeca86e0
Geth roast: b2ee3e06a6 | (Elizabeth Mattijsen)++ | S16-filehandles/dir.t
Remove obsolete test file

This hasn't been meaningfully touched in *12* years. It tests for basically a port of Perl's opendir and friends, which do not exist in Raku (although the P5opendir module *does* try to mimic that). In any case, this test-file is not being run anyway, and such is only a distraction.
AlexDaniel lizmat: anyway that's another change in behavior
c: 2020.05.1,HEAD dir("/tmp/.").sort.say 11:23
committable6 AlexDaniel, gist.github.com/014825d912ef1853f2...8cc4a0116b
lizmat looks
AlexDaniel lizmat: and more: ↓ 11:24
c: 2020.05.1,HEAD say dir("///").sort
committable6 AlexDaniel, gist.github.com/b51e134dcc93ef27ad...ba3a15514c
11:37 JJMerelo joined
lizmat AlexDaniel: will you write some tests for that ? 11:38
AlexDaniel lizmat: no, if possible
Geth rakudo: 484f07443e | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make sure we dir with a clean slate
lizmat AlexDaniel: why not ?
AlexDaniel cuz I wanna do other stuff right now? Sorry 11:39
lizmat I also want to do other stuff right now
AlexDaniel 🤷
lizmat * 11:40
sena_kun There is always a log with nice cases pointed out, so no need to hurry with this.
Geth roast: cfe16b93c6 | (Elizabeth Mattijsen)++ | S32-io/dir.t
Add some tests for dirty dir specififications

Easily expandable should anyone feel the need		 11:45
12:17 JJMerelo left
Geth rakudo/master: 5 commits pushed by (Elizabeth Mattijsen)++ 12:41
lizmat 059072277e is the important one there 12:47
linkable6 (2020-06-18) github.com/rakudo/rakudo/commit/059072277e Move all of INTERPOLATE and friends into a separate file
12:54 Altai-man_ joined 12:57 sena_kun left
jnthn lizmat: Hm, that introduces more files that have unmatched curlies in them? 12:58
lizmat nope
this one uses the same method as with Any-iterable
augment class Match { }
jnthn OK, good 12:59
13:12 vrurg left, vrurg joined 13:31 lucasb joined
[Tux] Rakudo version 2020.05.1-300-g059072277 - MoarVM version 2020.05-97-gb5bb4f8d1
csv-ip5xs0.802 - 0.836
csv-ip5xs-208.382 - 8.748
csv-parser26.596 - 26.756
csv-test-xs-200.392 - 0.402
test7.589 - 7.717
test-t1.899 - 1.959
test-t --race0.841 - 0.892
test-t-2031.733 - 31.755
test-t-20 --race9.092 - 9.162
 13:44
14:33 klapperl_ left
Geth roast: 1b6986193d | (Elizabeth Mattijsen)++ | 5 files
Remove some superfluous grammar.new's

Unless your grammar actually contains non-system attributes that need instantiating, you do *not* need to instantiate a grammar in order to be able go parse strings with it.
Saves one unnecessary call to Match::BUILD.		 14:40
lizmat Sadly, it has proven difficult to have Grammar.new just return self on calls without parameters, as subclasses may indeed have attributes with defaults that may initializing 14:43
jnthn Is calling that actually common? 14:46
I always just do SomeGrammar.parse and that's what I've widely seen
lizmat well, a number of cases in roast anyway :-)
jnthn Yeah, I'm surprised :)
lizmat checking the ecosystem for such things with greppable6 is going to be eh.... difficult 14:47
greppable6: \.new
greppable6 help
14:50 greppable6 left 14:52 greppable6 joined 14:54 klapperl joined
greppable6 lizmat, 32335 lines, 1014 modules: gist.github.com/1822ec1464667f3a4c...fa552e1ac6 14:54
14:55 sena_kun joined 14:56 Altai-man_ left
lizmat looks like the very first hit in that long list is one of them 14:57
but indeed, not many of them, apparently 15:01
nine jnthn: you asked about performance measurements of in-process precompilation. There's actually one: installing the CORE dist takes 11.14506058 seconds on master vs. 8.6965494 seconds on my branch 15:15
lizmat nine: fwiw, that's almost within the range that I see when compiling core setting 15:16
nine lizmat: I'm not following? 15:18
lizmat with in-process precompilation, I'm seeing values in that range for installing the core modules in the 20+ times a day I build the setting 15:19
so you're positive result may be affected by noise, is what I'm saying 15:20
nine I took 2 measurements each and it's about +-0.1s. I also can't remember seeing a time < 10s for core modules 15:21
lizmat good, then I must have a faster machine :-) 15:22
9.701862 10.188191 12.7423004 9.48681609 10.576796 11.2876687 9.990865 9.9734318 9.1254897 9.4703215 15:24
my last 10 install time
s
afk for a few hours& 15:25
nine Taking lots more measurements grew the error range to +-.3s which makes the speedup still highly significant. 15:26
Darn that means it's all the more worth it to pursue this further...
AlexDaniel greppable6: Grammar\.new 15:45
greppable6 AlexDaniel, 30 lines, 12 modules: gist.github.com/192b79b6ea169b80ad...e210ed2512
dogbert17 nine: is it this line you an lizmat are referring to: "Installed 13 core modules in 9.076875 seconds!" 15:50
nine dogbert17: yes
dogbert17 cool
16:17 MasterDuke joined 16:31 leont_ left 16:54 Altai-man_ joined 16:57 sena_kun left 18:21 vrurg left 18:22 vrurg joined 18:26 vrurg left 18:31 vrurg joined 18:36 vrurg left 18:55 sena_kun joined 18:57 Altai-man_ left 19:14 vrurg joined 19:46 vrurg left
lizmat sena_kun did you already start a Blin run ? 20:29
sena_kun lizmat, I did not plan one today. 20:36
lizmat ok, good :)
sena_kun Can do, but better to do it tomorrow.
lizmat yeah... I might be breaking something soon :-)
sena_kun We still have a blocker, plus chances to have regressions in a day are relatively low given we have 2-3 of them for a couple of weeks. 20:37
lizmat, oops... Will you put it back until Friday night or?
lizmat which blocker?
sena_kun releasable6, status
releasable6 sena_kun, Next release in ≈1 day and ≈22 hours. 1 blocker. 143 out of 300 commits logged (⚠ 4 warnings)
sena_kun, Details: gist.github.com/b79838cf641aaf9169...6a7875dcbb
sena_kun Windows failures.
github.com/rakudo/rakudo/issues/3761
lizmat ah, I'm no use there 20:38
sena_kun Should have opened an issue two weeks ago, but. :(
Geth roast: 925e48209d | (Elizabeth Mattijsen)++ | S32-str/split.t
Remove unnecessary "list" and "hash" parameters

  - these aren't necessary for testing
  - these could be considered implementation detail		 20:39
20:46 vrurg joined 20:47 patrickb joined 20:48 patrickb left 20:50 vrurg left
[Coke] I just did a windows build 1-2 weeks ago and ... didn't run make test. hurm. 20:51
[Coke] tests that slightly older build... 20:52
timotimo goddamnit i can't be arsed to figure out why my ghost admin panel isn't working for me to write a new post for my grunt >_< 20:53
20:54 Altai-man_ joined 20:57 sena_kun left
lizmat so about 3 years ago, TimToady merged the Cursor and Match classes into a single class 20:57
I just realized that that has one big disadvantage 20:58
if you do a Match.raku , you get raku code
but that Raku code misses quite a lot of information about the Cursor / Match internals 20:59
Altai-man_ Sorry to de-rail. About the blocker: I did some research just now and apparently it is not _so_ horrible, seems like it passes a wrong value in some cases to a sub and that's all. But I don't know a thing about how to fix it nicely, so ideas are welcome. 21:00
lizmat the only reason Match.raku.EVAL works, is because *each* Match object carries around a list / hash in its internals
even if it is a "leaf" Match object (as in without any sub-matches) 21:01
which is a lot of wastage, since all submatches already exist in a Match object on the $!cstack 21:02
[Coke] often misses tcl tests standard of give every test a number.
21:03 vrurg joined
lizmat sleep& 21:58
Altai-man_ lizmat, have a nice rest. o/ 21:59
lizmat will do, hopefully :-)
gfldex i stepped on an odd bug involing hyper run and a role mixin 22:21
gist.github.com/6ec6c03d65dd9e298b...a0deabeace
that's as far as I could golf it
it should not say Any 22:22
jnthn roles are not closures 22:23
timotimo yeah, would need a role parameter for that
gfldex with :degree(1) the problem goes away 22:24
It's a ENODOC then. 22:25
timotimo hm, where'd that piece of info go?
gfldex docs.raku.org/language/typesystem#Parameterized 22:28
jnthn docs.raku.org/syntax/role doesn't really spell it out; it mentions they are immutable from the closing } but that's not really on the money. Probably belongs inthe mixin section.
gfldex Well, somewhere around that. 22:29
It's pretty hard to decide where to put docs for something that should not be there.
jnthn gfldex: I suspect if you're reading the bit on parameterized roles, you already knwo the answer to the problem...
gfldex Using a parameterized role makes the problem go away. 22:30
I think I will use a blod post to help with the thinking. 22:31
is there any chance to get a warning on such a closury role? 22:47
22:55 sena_kun joined
gfldex raku: my $R = role :: [$t] {}; dd $R; dd $R[42]; 22:56
evalable6 (exit code 1) <anon|1> $R = <anon|1>
Could not …
gfldex, Full output: gist.github.com/e7dda1f248f888f451...d382a4625d
gfldex I can store a parameterised Role in a scalar but I can not use it.
Is that intentional? 22:57
22:57 Altai-man_ left 23:00 leont left
jnthn Yes; one can never have enough bracket chars. 23:06
And [...] gets used for both type parameters and array indexing, so there have to be rules to decide which is which
And $sigil'd-variable[$foo] will always be an array index 23:07
You'll have to use the .^parameterize escape hatch if you want to store it in a $sigil'd-var

Powered by Cro and the Raku® Programming Language.

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

Thank you!