00:01 hungrydonkey joined 00:10 pmurias left 00:56 Kaiepi left 01:01 Kaiepi joined 01:34 sena_kun joined 01:36 Altai-man_ left 02:09 Kaeipi joined, Kaiepi left 02:12 Kaeipi left 02:14 Kaeipi joined, ufobat_ joined 02:18 ufobat__ left
vrurg Turns out, multi-dispatch doesn't pay respect to inheritance... 02:24
releasable6 Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
03:33 Altai-man_ joined 03:36 sena_kun left
Geth rakudo: vrurg++ created pull request #3500:
Make multi method dispatcher handle MRO		 03:56
04:36 hungrydonkey left 04:37 hungrydonkey joined 05:20 vrurg left 05:21 vrurg joined 05:34 sena_kun joined 05:36 Altai-man_ left 06:39 domidumont joined 06:42 domidumont left 06:52 domidumont joined 07:33 Altai-man_ joined 07:36 sena_kun left 07:50 Kaeipi left 07:53 Kaiepi joined, domidumont left 08:02 cognomin_ joined 08:05 cognominal left 08:16 domidumont joined
Geth Blin: jsoref++ created pull request #21:
Spelling		 08:31
Blin: d88b3fd1aa | (Josh Soref)++ | bin/blin.p6
spelling: algorithmically
 08:47
Blin: dbc48e43d2 | (Josh Soref)++ | docker/README.md
spelling: takes
Blin: b495ad0342 | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #21 from jsoref/spelling

Spelling
Altai-man_ >no issues with Blin check 08:53
tellable6 2020-02-21T08:41:57Z #raku <jmerelo> Altai-man great job!
Altai-man_ releasable6, status 08:54
releasable6 Altai-man_, Next release in ≈1 day and ≈10 hours. There are no known blockers. 163 out of 247 commits logged
Altai-man_, Details: gist.github.com/86e4b460f6ffb15543...01803cb8f9
Geth rakudo: 388846cf5a | Altai-man++ | tools/create-release-announcement.raku
Fix executable name and off-by-one
 09:09
09:34 sena_kun joined 09:36 Altai-man_ left
sena_kun bisectable6, my $a = (^2).Seq; my $b = $a; say $a eqv $b; 09:47
bisectable6 sena_kun, Bisecting by exit code (old=2015.12 new=388846c). Old exit code: 1
sena_kun, bisect log: gist.github.com/f7179ec92670a1951d...3741b2713e
sena_kun, (2020-01-27) github.com/rakudo/rakudo/commit/76...b05ce4c9fb
10:11 cognominal joined 10:15 cognomin_ left
lizmat sena_kun: ^^ is that a problem ? 10:29
sena_kun lizmat, nope, just checked if that's a "fix" or "change"
|Tux| Rakudo version 2020.01-248-g388846cf5 - MoarVM version 2020.01.1-43-ga71eee4c2
csv-ip5xs0.699 - 0.708
csv-ip5xs-205.753 - 5.853
csv-parser22.782 - 22.799
csv-test-xs-200.368 - 0.370
test7.261 - 7.546
test-t1.743 - 1.841
test-t --race0.778 - 0.822
test-t-2029.170 - 29.216
test-t-20 --race8.530 - 8.821
 10:30
sena_kun I'll scream here loudly if see any issues. ;)
lizmat sena_kun++
Geth rakudo/release-2020.02: 11997c8e26 | Altai-man++ | 2 files
Update changelog + announcement

Deliberately not logged:
8099d64 4ffd8df 4437723 6c5615e 2b04eea 1cc43c8 2e69d7a 4829711 4e12365 5629cdf 58e8fb1 b582c7e 1299e32 5d65764 0d53009 547c7b9 bae5fc7 c9a6b02 749ab90 14abd58 fb13c31 e27811a 68ff8cf 589ba38 f8b9d02 37b1be7 5cffce1 9a83b61 e2a66ff 94b30b6 ca912be a152997 5a4a3be f2b3091 cdc907b ab9c1ff 774a839 8390016 f95bf76 5685648 fbeb3e3 585cc6b 17f7c5a 0bebe4e b74e5d7 348fa84 4035239		 11:01
rakudo: Altai-man++ created pull request #3501:
Release 2020.02		 11:03
11:19 hankache joined 11:27 hungryd59 joined 11:29 hungrydonkey left 11:33 Altai-man_ joined 11:36 sena_kun left 11:42 hungrydonkey joined 11:44 hungryd59 left 11:45 hungrydonkey left, hungrydonkey joined
Geth rakudo: 539e96c262 | (Elizabeth Mattijsen)++ | 2 files
Make error on Buf stringification more awesome

  - tell the type it was attempted on
  - mention the use of .decode instead
  - also add prefix:<~> to the actual cases tested
Inspired by Ralph Mellor's comment on:
   stackoverflow.com/questions/603343...t-the-spac		 11:47
rakudo: dumarchie++ created pull request #3502:
Make listing and coercion of sequences more efficient
rakudo: 992f1b83f8 | (Jonathan Worthington)++ | 2 files
Fix mixing in Raku-level code to the grammar

The grammar is written in NQP, and so wants its match objects to have an nqp::list for quantified captures. An internals change resulted in us always creating a Raku Array instead; this is fine for everything except when we want to mix into the Raku grammar itself. In that case, we could end up with quantified things only collecting the last captured value, ... (5 more lines)		 11:57
jnthn releasable6: status
releasable6 jnthn, Next release in ≈1 day and ≈7 hours. There are no known blockers. 163 out of 249 commits logged
jnthn, Details: gist.github.com/dc2b49ca4ec275868e...16afe552a9
jnthn \o/
Altai-man_ jnthn, given moarvm will be released today or early tomorrow, I'll wrap one tomorrow, things look (hopefully) smoothly here. 11:58
jnthn :) 12:04
Altai-man_++
Then next week I can break st^W^Wmerge my latest MoarVM work :)
Altai-man_ jnthn, please do by all means! 12:05
jnthn, it would be great to also merge everything available related to unix sockets grant
lizmat And I will join with some of my breaking opts :-)
but first some afk&
Altai-man_ lizmat, good luck!
I am not sure about including github.com/rakudo/rakudo/commit/99...971ca0877e into the release, but tending not to do so: this failure is not a last release regression, has flapping nature and we release montly anyway. Any objections? 12:20
jnthn Altai-man_: It was a regression in the release before the last one, I guess... 12:37
Altai-man_: imo it's low-risk
(to include it)
Altai-man_ jnthn, yes, it doesn't contradict with what I wrote.
jnthn Up to you really. It means that the module will only have been broken for one release, rather than for two if we don't include it. 12:39
12:46 lucasb joined, Kaiepi left 12:47 domidumont left 12:49 Kaiepi joined
nine t/spec/S32-container/buf.t ........................................ Dubious, test returned 1 (wstat 256, 0x100) 12:51
Failed 1/21 subtests
lizmat: ^^^ 12:52
13:23 hankache left 13:34 sena_kun joined 13:36 Altai-man_ left
MasterDuke jnthn: any thoughts on github.com/MasterDuke17/rakudo/com...b27aeaff5a ? 14:36
14:47 pmurias joined
jnthn m: say 1 ~~ 1.5 | 1.0 14:52
evalable6 True
jnthn Does it get this right?
(It may be over-committing on type, if I'm reading it right) 14:55
I really want just desugar it into a chain of calls to .ACCEPTS and then let the right thing happen 14:56
MasterDuke m: sub a($a where 1.0|1.5) { $a }; my $a; my $b := 1; say a($b)
evalable6 1
MasterDuke i get '1' also
but should i change it to a bunch of .ACCEPTS? 14:57
jnthn Oh, you don't optimize for Rat, but... 14:58
m: say 1 ~~ 1.5e0 | 1e0
evalable6 True
jnthn What about a case like that?
m: say '1' ~~ 1.5e0 | 1e0
evalable6 True
jnthn Or that?
MasterDuke m: sub a($a where 1e0|1.5e0) { $a }; my $a; my $b = 1; say a($b); my $c = '1'; say a($c) 15:00
evalable6 1
1
MasterDuke heh. i get 'Internal error: inconsistent bind result'
jnthn Yeah, I feared that one might not go well 15:01
MasterDuke guess we should also add tests for those cases, because my branch does pass a spectest 15:02
jnthn +1 15:03
My gut feeling is that calling .ACCEPTS is going to be the best way, because doing otherwise will mean the code size is liable to explode 15:04
MasterDuke i'll give that a try
15:33 Altai-man_ joined 15:34 cognomin_ joined 15:36 sena_kun left 15:37 pmurias left, cognominal left
lizmat nine: grrr.... adding a period I didn't think would make that much of a difference 16:18
Geth rakudo: 3f637af9e1 | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6
Remove period to fix test

Really didn't think it would make a difference :-(		 16:23
16:54 domidumont joined
nine t/spec/S16-io/watch.t ............................................. Dubious, test returned 1 (wstat 256, 0x100) 16:58
Failed test: 1 16:59
lizmat nine: that's potentially a flapper: some OS's sometimes take a little longer to deliver file system events 17:00
or does it repeatedly fail for you ? 17:01
nine Yeah, I've noted that here multiple times already. But no one feels responsible for fixing it. 17:02
lizmat well, it depends on the OS... I've fixed it for MacOS 17:04
nine The test is obviously still broken. In a quite obvious way even. 17:07
[Coke] is there a ticket to track it? 17:08
nine Now: github.com/perl6/roast/issues/621 17:10
Maybe I should mark it a release blocker. After all it did cause my test run of the new release script for MoarVM to abort. 17:11
Apparently there is no blocker label in roast. So maybe I should assume that the test is correct after all and create a rakudo release blocker issue? 17:12
Altai-man_ nine, if the test itself is broken, how release blocker?
nine, is it reliable? if yes, can we bisect it? if it's a flapper since forever, how blocker? 17:13
nine The test being broken is just my interpretation after all. It's not like I have mathematical proof of it. 17:14
lizmat nine: then. from my experience trying to test this, we should make it a stress test, maybe
nine It's pretty easy to make it fail by running on a heavily loaded system
lizmat the thing is that on such systems, in my experience, some events just don't get delivered 17:15
so increasing the timeout, would result in a hanging test, rather than a failing test
nine What timeout? 17:16
lizmat Promise.in(5);
nine The test file goes straight from triggering the last even to checking the 5 second time out without giving the system any time at all to deliver the event.
Geth roast: b3274b105b | (Jonathan Worthington)++ | S16-io/watch.t
Try to make file watching test more reliable

Don't rely on time, just keep the thing making events and thing that expects them in lock step with each other.		 17:19
lizmat nine: works for me... :-) 17:20
nine Still the same :/ 17:21
jnthn Still fails?
After my fix, or the timeout bump?
nine jnthn: still same error mode even with your fix 17:22
lizmat nine: I was mistaken that test file with S17-supply/watch-path.t 17:23
nine jnthn: I think the test actually still has exactly the same issue. Your fix suffers from an off-by-one in a way 17:24
jnthn ah, shit, I see...
No, I don't think it does
It's a race
nine Do we need $done-writing at all?
jnthn no, that's precisely what I'm removing at the moment
nine We could just end if $count arrives at 10
17:25 domidumont left
Geth roast: 440672c984 | (Jonathan Worthington)++ | S16-io/watch.t
Remove another source of race in file watch test
 17:25
nine Btw sorry for being so grumpy about this. I'm overly stressed by $daytime-job and just finished my workout which left me unusually exhausted and not feeling good at all :/ 17:26
jnthn I was pissed off you were being grumpy so decided to fix it while you were grumping :P
So I guess it worked out :P
Well, if it's fixed now anyway... 17:27
17:27 domidumont joined
Geth roast: 72ab057be3 | (Jonathan Worthington)++ | S16-io/watch.t
Factor out a magic number to a constant
 17:28
jnthn Plus that gets rid of the 10 everywhere
nine Yeah, looks better now. I do get an occasional timeout though.
jnthn Hmm
nine But I'm running spectest with TEST_JOBS=40 to generate load
jnthn Can it really take more than 5 seconds for 10 write/fs event cycles? 17:29
The first fix I did was 'cus I figured it was batching them and getting the count wrong.
nine Bumped the timeout to 50s and still got one 17:30
lizmat as I said: OS's are not guaranteed to deliver all events at all times
at least in my experience
17:32 domidumont left
lizmat so maybe we should test for a percentage of events arriving? 17:32
17:33 domidumont joined
jnthn I wonder if there's a race between the file watcher setup request being sent and the first write 17:34
17:34 sena_kun joined
jnthn Since I don't think the `whenever` giving back control means the setup was completed, and the first write might beat it... 17:35
Geth roast: c1f86a12b7 | (Jonathan Worthington)++ | S16-io/watch.t
Allow time for file watcher setup
 17:36
17:36 Altai-man_ left
jnthn Don't like having a time in there...grmbl :) 17:36
But if it helps, then it explains what is going on
I've run it during a loop for an entire spectest run without failure. 17:45
17:47 hungryd5 joined 17:50 hungrydonkey left
jnthn OK, home time o/ 17:50
vrurg jnthn: double promise approach for watch.t would do better: first the start block signals that it's ready (promise1), then it would await for the command to start (promise2). 18:00
18:03 hungryd5 left
Geth rakudo: 1d946e15fe | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
IO::Path!new-from-absolute-path is a private method

  - so it doesn't need any named parameters, it can use positionals
  - it doesn't need any defaults or coercing		 18:04
18:07 domidumont left 18:08 patrickb joined 18:11 rba[m] left, unclechu left 18:12 CIAvash left, AlexDaniel` left 18:29 rba[m] joined 18:30 rba[m] left 18:50 cognominal joined
lizmat .ask vrurg could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ? 18:52
tellable6 lizmat, I'll pass your message to vrurg
18:54 cognomin_ left 18:59 Xliff joined
vrurg lizmat: it was patrickb addition and I rather avoid this part of the build. 19:00
lizmat .ask patrickb could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ?
tellable6 lizmat, I'll pass your message to patrickb
lizmat vrurg++
vrurg lizmat: But if he's too busy, I'll do it. 19:01
Xliff m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { }
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/cvjQfyHrsM
Method 'BUILD' must be resolved by class C because it exists in multiple roles (B, A)
at /tmp/cvjQfyHrsM:1
tellable6 2020-02-05T07:21:31Z #raku <holyghost> Xliff thanks for updating the raku/perl6 compiler :-)
lizmat I'm working on some IO::Path streamlining
and it breaks during that process... but can't really see why :-(
Xliff m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { submethod BUILD (:$c) { say "C" } }; C.new}
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/8IrYlVRWET
Unexpected closing bracket
at /tmp/8IrYlVRWET:1
------> 03bmethod BUILD (:$c) { say "C" } }; C.new08⏏04}
Xliff m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { submethod BUILD (:$c) { say "C" } }; C.new
evalable6 C
19:02 CIAvash joined
vrurg lizmat: Actually, --ll-exception could be added to the command line without extracting into a script. 19:03
lizmat: Do you just need the full backtrace or there is something else? 19:04
lizmat true, but that wouldn't give me an easy way to find out what exactly is going on
a full backtrace will do for now :-)
which I have now, thanks! :-)
vrurg lizmat: np :) 19:11
19:25 unclechu joined, rba[m] joined, AlexDaniel` joined
lizmat I wonder if someone can explain to me why this doesn't select the :basename! candidate: gist.github.com/lizmat/1c4480ee309...c8e3177b60 19:27
19:33 Altai-man_ joined
patrickb lizmat, vrurg: Not sure what the RUN_CLEAN_TARGET_FILES / --ll-exception thing is about. 19:36
tellable6 2020-02-21T07:15:27Z #raku <jmerelo> patrickb, no, no way that I know of. And yes, the organization has been deleted for me too; it returned a 403.
2020-02-21T19:00:43Z #raku-dev <lizmat> patrickb could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ?
19:36 sena_kun left
lizmat in the Makefile there is a piece of code run with -e 19:36
I would like to see it being run from a script so that I can easily add debugging code if necessary 19:37
rather than to fiddle with the Makefile
re gist.github.com/lizmat/1c4480ee309...c8e3177b60 I figured it out 19:43
19:43 domidumont joined
lizmat m: dd $*SPEC, $*SPEC.defined 19:43
evalable6 Unix element = IO::Spec::Unix
Bool::False
lizmat constraining to IO::Spec:D is suicide :)
patrickb jmerelo: I wrote to GSoC support and asked about our rejection, they answered really fast. Our application wasn't bad in any way. It's just that they have a maximum of 200 orgs they accept, and want to get 30 new ones in every time, so some have to pause from time to time. This year we were paused. 19:45
tellable6 patrickb, I'll pass your message to jmerelo
19:47 domidumont left
lizmat so, if we would have applied as The Raku Foundation, we would have had a good chance of being accepted :-( 19:48
[Coke] Given that would be the same org with a d.b.a., we might have, but only on a technicality. 19:51
It wouldn't hurt to have a third name for the foundation, for sure. 19:52
(from the standpoint of someone who wouldn't be dealing with any of the legalities.)
lizmat I've been told it would be relatively easy and painless 19:58
as TPF is also a d.b.a of Yet Another Society 19:59
vrurg m: class Foo { multi method foo(Str:D $a) { say "Foo" } }; class Bar is Foo { multi method foo(Any:D $v) { say "Bar" } }; Bar.new.foo("ok") 20:07
evalable6 (exit code 1) Ambiguous call to 'foo(Bar: Str)'; these signatures all match:
:(Foo: Str:D $a, *%_)
:(Bar: Any:D $v, *%_)
in block <unit> at /tmp/thVw2Ey6s5 line 1
vrurg ^ Am I right that this is not how it should behave?
m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.new.foo("ok") 20:08
evalable6 Foo
jnthn vrurg: That is correct behavior. 20:19
vrurg jnthn: The second one too?
jnthn vrurg: The invocant is just another parameter so far as the multi-dispatch is concerned 20:20
Didn't look at the second one yet, just the one you asked about :)
vrurg I know the invokant is considered, but it feels to me that Str:D should have preference in this case.
jnthn It's correct in the second csae tht it picks Foo, but it's not clear to me why it'd not then nextsame into bar 20:21
Um, to be clear, the one that says Foo 20:22
Since I think both should be valid candidates
vrurg jnthn: I know what you mean, that's the point. 20:23
jnthn It's a bit of a funny nextsame in so far as you go down the class hierarchy, but that should be totally irrelevant given we're walking a multi candidate list 20:24
(multi method dispatch is actually two dispatches, one to find the controlling proto, and then a standard multi dispatch once it's found)
vrurg jnthn: I wanna try rewriting MethodDispatch to have it handle multis too. Gonna see if it would impact the issue. 20:26
jnthn m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.^lookup("foo").cando(Bar.new, "str")
evalable6 (exit code 1) Too many positionals passed; expected 2 arguments but got 3
in block <unit> at /tmp/1pgbEZhLvz line 1
jnthn d'oh
m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.^lookup("foo").cando(\(Bar.new, "str"))
evalable6
jnthn m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; say Bar.^lookup("foo").cando(\(Bar.new, "str")) 20:27
evalable6 (foo foo)
jnthn That thinks they are both candidates
And I thought nextsame would use the same plumbing
So I'm a bit surprised it doesn't reach the `say "Bar"` 20:28
vrurg Looks like candidates are taken before foo from Bar is added to the cloned proto.
jnthn Huh?
vrurg So, runtime sees both, but only one is compiled into.
jnthn But the dispatcher is formed at runtime?
vrurg It was a only guess for now. 20:29
jnthn I suspect whatever it is will be fairly localized to the deferral handling 20:30
vrurg I'll try to see what I can done about it.
*can do
jnthn One thing I worry about is that we don't end up revisiting the same multi method multiple times 'cus it exists in many protos
Which a naive fix for this issue would end up doing 20:31
So maybe MethodDispatcher trying to rule over the whole process is a rightish way to go 20:32
*MethodDispatch
vrurg jnthn: I took care of this in #3500, but as I thought about that implementation afterwards, it's prone to the revisiting if child classes would override with non-multi.
Aha, that was exactly my enlightenment before I went to bed. :) Gonna try it this way today. 20:33
patrickb Is it possible to have a catch-the-rest argument in sub MAIN? like 'sub MAIN(Str $folder, Str @files)'?
jnthn *@files 20:34
And you can't type slurpies
Geth ¦ problem-solving: lizmat assigned to jnthn Issue $*CWD is an IO::Path, IO::Path.CWD is a Str github.com/Raku/problem-solving/issues/164
vrurg And it would still have to remember what packages protos were defined in to get around corresponding parents.
jnthn Yes, and I'm not sure we retain that information 20:35
The other thing it could potentially do is keep a seen list
Though that's not really efficient 20:36
vrurg jnthn: We do retain it. That's how I solved it with MultiDispatcher. It walks MRO but throws away the first entry and records the proto's package. Did work in a way.
jnthn: Nevermind, don't get yourself distracted on this. I have a plan, will see how it works. 20:37
vrurg needs it or the whole architecture of my event dispatching in Vikna is broken. :(
jnthn vrurg: Hm, how is it retained out of curiosity? :) 20:38
Is that something you added, or is there a bit of information retained that I forgot about?
vrurg In terms of Dispatcher.nqp vivify_for: $sub.dispatcher.package. For Bar it gives Foo. 20:40
jnthn Aha!
vrurg m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Any $v) { say "Bar" } }; say Bar.^method_table<foo>.is_dispatcher; say Bar.^method_table<foo>.package.^name 20:42
evalable6 True
Dummy
vrurg But this ^ is confusing me though.
lizmat Dummy is the class in which protos are generated ? 20:43
Dummy.HOW.set_autogen_proto(&Dummy::AUTOGEN);
vrurg m: class Foo { proto method foo(|) {*}; multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Any $v) { say "Bar" } }; say Bar.^method_table<foo>.is_dispatcher; say Bar.^method_table<foo>.package.^name; 20:44
evalable6 True
Foo
vrurg lizmat: thanks!
But it means a lot of problems then... I have what to think about... 20:45
What if I "rebind" the proto to the package it's being instantiated for? I.e. enforce it's package attribute to the correct value? 20:51
nine jnthn: with your latest commit I haven't been able anymore to reproduce a failure in watch.t :) 21:01
Geth rakudo: patrickbkr++ created pull request #3504:
Move RUN_CLEAN_TARGET_FILES to separate script		 21:25
patrickb vrurg, lizmat: github.com/rakudo/rakudo/pull/3504
jnthn nine: Hurrah :) 21:26
vrurg: That'd probably work given it's cloned 21:27
MasterDuke jnthn: should/could github.com/rakudo/rakudo/blob/mast...9676-L9706 just be made smarter? 21:28
jnthn MasterDuke: I'd prefer optimizations stay in the optimizer, I think 21:34
21:34 sena_kun joined 21:36 Altai-man_ left
MasterDuke k 21:36
releasable6 Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
Geth rakudo: 21aa02ba0d | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Revert "Make Match.STR faster if there are no captures"

This reverts commit 495ddcc1ffcb9d652e555608cb60b2cc166a916e.
This was only an optimization in an area that could use a lot of thinking and reorganization. Since it apparently causes issues:
   colabti.org/irclogger/irclogger_lo...02-21#l112
revert it.		 23:31
lizmat .tell sena_kun suggest you cherry pick github.com/rakudo/rakudo/commit/21aa02ba0d into the release
tellable6 lizmat, I'll pass your message to sena_kun
lizmat sleep&
23:33 Altai-man_ joined 23:36 sena_kun left
vrurg greppable6: Dummy 23:42
greppable6 vrurg, 26 lines, 10 modules: gist.github.com/0c1657a081b6cb7d51...de7e69b7ac
23:46 lucasb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!