[01:22] *** sena_kun joined [01:23] *** Altai-man_ left [03:08] *** linkable6 left [03:08] *** evalable6 left [03:10] *** evalable6 joined [03:11] *** linkable6 joined [03:21] *** Altai-man_ joined [03:23] *** sena_kun left [05:22] *** sena_kun joined [05:23] *** Altai-man_ left [06:30] sena_kun: looks promising :) https://github.com/Raku/Blin/pull/23 [06:32] greppable6: \.\..*\.reverse [06:32] AlexDaniel, 24 lines, 15 modules: https://gist.github.com/66034742de35b4d63077fa7faba1f25a [06:34] Xliff: well, you can add arguments to the one you did before [06:34] Xliff: for example, JSON::Fast is likely to pass tests everywhere so it'll be `OK` [06:36] Xliff: I think module Sum is AlwaysFail [06:38] Xliff: basically pick anything from here: https://gist.github.com/AlexDaniel/acf237b7b3598087834c10e5abb8a785 [06:38] just keep in mind that some of them have dependencies :) [07:06] <[Tux]> Rakudo version 2020.02.1-291-g30e7a67c5 - MoarVM version 2020.02.1-73-gc7e75be60 [07:06] <[Tux]> csv-test-xs-20 0.376 - 0.388 [07:06] <[Tux]> csv-ip5xs 0.694 - 0.694 [07:06] <[Tux]> test-t --race 0.948 - 0.986 [07:06] <[Tux]> test-t 1.949 - 1.961 [07:06] <[Tux]> csv-ip5xs-20 5.839 - 5.879 [07:06] <[Tux]> test 7.565 - 7.620 [07:06] <[Tux]> test-t-20 --race 9.519 - 9.575 [07:06] <[Tux]> csv-parser 23.546 - 24.095 [07:06] <[Tux]> test-t-20 31.316 - 31.357 [07:08] *** maggotbrain left [07:21] *** Altai-man_ joined [07:23] *** sena_kun left [08:27] is geth down? don't think i saw 30e7a67c55546e934ae46ed600e04c1c503cece5 go by [08:27] (2020-04-04) https://github.com/rakudo/rakudo/commit/30e7a67c55 Add s/PERL6/RAKU test environment variables [08:34] MasterDuke: I'll kick him [08:35] woohoo, got my branch building rakudo and passing nqp's `make m-test` and rakudo's `make m-test m- spectest`. compile times seem unchanged, but heaptrack reports ~4gb less allocated [08:35] considering to just kick him on a daily basis at this point, tbh [08:35] *** Geth_ joined [08:35] *** Geth left [08:35] it doesn't report anything in particular in the logs as to why it's having troubles [08:46] Files=1306, Tests=111228, 213 wallclock secs (28.90 usr 8.27 sys + 3009.80 cusr 267.12 csys = 3314.09 CPU) [08:46] oom killer? [08:47] the process runs just fine [08:47] if the OOMkiller were to come around, kubernetes would restart the process somewhere [08:47] and there would be no problem [09:05] *** Voldenet joined [09:05] *** Voldenet left [09:05] *** Voldenet joined [09:14] m: use NativeCall; class A repr {}; my $a = A.new; +$a.say [09:14] rakudo-moar 30e7a67c5: OUTPUT: «5===SORRY!5=== Error while compiling ␤Unable to parse class definition␤at :1␤------> 3use NativeCall; class A7⏏5 repr {}; my $a = A.new; +$a.s␤ expecting any of:␤ generic role␤» [09:14] m: use NativeCall; class A is repr {}; my $a = A.new; +$a.say [09:14] rakudo-moar 30e7a67c5: OUTPUT: «WARNINGS for :␤A.new␤Useless use of "+" in expression "+$a.say" in sink context (line 1)␤» [09:14] m: use NativeCall; class A is repr {}; my $a = A.new; (+$a).say [09:14] rakudo-moar 30e7a67c5: OUTPUT: «Cannot resolve caller Numeric(A:D: ); none of these signatures match:␤ (Mu:U \v: *%_)␤ in block at line 1␤␤» [09:15] ^^ What would it take to get that to work? [09:22] *** sena_kun joined [09:24] *** Altai-man_ left [09:35] *** hungrydonkey left [09:35] *** hungryd80 joined [09:43] ¦ rakudo: 3983b4f8f2 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6 [09:43] ¦ rakudo: Make (1..-Inf).reverse) work as intended [09:43] ¦ rakudo: [09:43] ¦ rakudo: Fixes R#3595 [09:43] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3983b4f8f2 [09:43] R#3595 [open]: https://github.com/rakudo/rakudo/issues/3595 [ranges][regression] (1 .. -Inf).reverse is wrong [09:45] AlexDaniel: Do you really want both .output-old and .output-new? [09:47] AlexDaniel: https://gist.github.com/Xliff/a9bb1b058123200cd0921ed46f609f29 [09:47] Xliff: markdown in tickets is different from markdown that is in gists [09:47] so test your stuff in comments :D [09:48] I know, I know, but that's how it is :D [09:49] Um. No. [09:49] It's how YOU want it. Not necessarily how it is. [09:50] Xliff: I mean that github parses markdown differently [09:50] depending on whether it's in tickets, gists or wikis [09:50] It looks fine. See PR [09:50] I'm more concerned about comment length with both .output-new AND .output-old [09:52] Xliff: yeah… we can have nested collapsible things but it gets kinda ridiculous [09:53] Xliff: btw here's the source of my comment (in case you can't see it): https://gist.github.com/AlexDaniel/ae883209542ac973e22e9f0a25ba7f78 [09:53] Xliff: ``` instead of
 so that there's no need to escape stuff, also the whole thing is indented so that it's part of the todo item

[09:56]   + ``` does not work

[09:56]  Xliff: you need a newline before ``` I think

[09:56]  like an empty line

[09:56]  And this whole indenting stuff might be taking this too far.

[09:57]  but it does need to be part of the todo item

[09:57]  ¦ rakudo: c588323e51 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6

[09:57]  ¦ rakudo: Make (foo .. foo).reverse correctly

[09:57]  ¦ rakudo: 

[09:57]  ¦ rakudo: Fixes R#3597

[09:57]  ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/c588323e51

[09:57]  R#3597 [open]: https://github.com/rakudo/rakudo/issues/3597 [ranges] (Inf ^.. Inf).reverse is wrong

[09:57]  otherwise you can't drag'n'drop todo items

[10:00]  ``` Does not work. Destroyes formatting.

[10:01]  Also, can't drag and drop TODO items at all.

[10:01]  Old Output will indent, New Output will NOT

[10:02]  Xliff: but it works here? https://github.com/Raku/Blin/pull/23#issuecomment-609363030

[10:02]  I can drag'n'drop but maybe just for my own comment

[10:06]  lizmat: I wonder, wouldn't it be simpler for everything if .reverse on a Range just returned a reversed Range object?

[10:06]  lizmat: that's fully not backward compatible but I'm not sure if it matters

[10:07]  well, I guess you could consider a dedicated Range.reverse to be a premature optimization

[10:08]  as you could probably easily replace (a .. b).reverse by b ... a

[10:08]  what optimization

[10:08]  it's a completely different behavior

[10:08]  but the latter is like 10 times slower 

[10:08]  m: say (1..10).reverse

[10:08]  rakudo-moar 3983b4f8f: OUTPUT: «(10 9 8 7 6 5 4 3 2 1)␤»

[10:08]  Got it!

[10:08]  m: say 10...1

[10:08]  rakudo-moar 3983b4f8f: OUTPUT: «(10 9 8 7 6 5 4 3 2 1)␤»

[10:09]  AlexDaniel: not very different in most cases

[10:09]  ah, I see what you're saying

[10:09]  so, I'm fixing those tickets now

[10:09]  yeah for now that makes sense for sure

[10:09]  once ... is optimized, I will look and see how much we can rip out

[10:11]  lizmat: I'm just trying to make sense of the behavior and right now “I don't know” is the only short explanation I have :)

[10:12]  so .reverse is like, uhm, having a range with sides reversed but it's allowed to count down ?

[10:13]  on a Range that is

[10:13]  m: say (1..10).reverse   # indeeed

[10:13]  rakudo-moar c588323e5: OUTPUT: «(10 9 8 7 6 5 4 3 2 1)␤»

[10:13]  on everything else it's just iterating backwards

[10:14]  m: my @a = 1..10; say @a.reverse   # functional equivalent

[10:14]  rakudo-moar c588323e5: OUTPUT: «(10 9 8 7 6 5 4 3 2 1)␤»

[10:14]  m: say (1..10.5).reverse

[10:14]  rakudo-moar c588323e5: OUTPUT: «(10.5 9.5 8.5 7.5 6.5 5.5 4.5 3.5 2.5 1.5)␤»

[10:14]  m: my @a = 1..10.5; say @a.reverse

[10:14]  rakudo-moar c588323e5: OUTPUT: «(10 9 8 7 6 5 4 3 2 1)␤»

[10:14]  not exactly…

[10:15]  hmmm... that would be a bug :-)

[10:15]  care to make a ticket?

[10:15]  lizmat: it's by design, this is why we have this conversation

[10:15]  :)

[10:16]  hmmmm

[10:16]  premature optimization    :-(

[10:17]  lizmat: now you *can* fix this particular case with maths, I think

[10:17]  but then what about Num ranges? :)

[10:17]  m: dd $_ for 10e0..15e0

[10:17]  rakudo-moar c588323e5: OUTPUT: «10e0␤11e0␤12e0␤13e0␤14e0␤15e0␤»

[10:19]  lizmat: but if we say that .reverse is supposed to produce exactly the same values just in reverse, then maybe there's a way to get there eventually

[10:21]  m: say (Inf ^.. Inf).reverse[^10]

[10:21]  rakudo-moar c588323e5: OUTPUT: «(Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil)␤»

[10:21]  e: say (Inf ^.. Inf).reverse[^10]

[10:21]  AlexDaniel, rakudo-moar c588323e5: OUTPUT: «(Nil Nil Nil Nil Nil Nil Nil Nil Nil Nil)␤»

[10:24]  lizmat: I'm a bit confused as to why it still prints what it prints, but either way the fix for R#3597 is possibly not right

[10:24]  R#3597 [open]: https://github.com/rakudo/rakudo/issues/3597 [ranges][tests needed] (Inf ^.. Inf).reverse is wrong

[10:24]  ah

[10:25]  now that I squinted a bit harder it's probably right

[10:27]  m: dd ("1"..9).reverse.head(10)   # another case  :-(

[10:27]  rakudo-moar c588323e5: OUTPUT: «This type cannot unbox to a native string: P6opaque, Int␤  in block  at  line 1␤␤»

[10:30]  lizmat: oh I have not even considered mixed types

[10:30]  yeah... I think some cleanup is needed  :-(

[10:32]  Xliff: it looks pretty good!

[10:33]  Xliff: don't put the sha in `` because in rakudo/rakudo repo github will automatically create links for shas

[10:33]  Xliff: and you don't even need to substr it I think

[10:33]  it's a bit ugly in plaintext but as a ticket it'll be fine

[10:34]  *shrug*

[10:34]  Is it enough to do for now?

[10:35]  Getting tired and need to accomplish something on my own stuffs before I pass out. :/

[10:35]  Oh, you want me to finish before merge. See? tired.

[10:35]  well, I dunno. There's also output that is not in ``` ```, meaning all html stuff needs to be escaped

[10:36]  escaping ``` is probably significantly easier :)

[10:36]  Again, ``` does not work.

[10:36]  Dunno why, but inside of 
, using ``` destroys the formatting.
 was the only alternative.

[10:37]  Xliff: I just edited your comment with ```

[10:37]  Checking

[10:38]  Hmmm... newline before ```?

[10:38]  Did you already mention that?

[10:38]  See? tired. :P

[10:39]  m: dd (NaN..NaN).head(10)

[10:39]  rakudo-moar c588323e5: OUTPUT: «(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq␤»

[10:39]  this feels...  weird...  I sorta expected this to produce a single NaN value ?

[10:40]  m: dd (NaN...NaN).head(10)

[10:40]  rakudo-moar c588323e5: OUTPUT: «(NaN,).Seq␤»

[10:40]  lizmat: I don't even know what to expect now, really. Cognitive overload because of all edge cases

[10:41]  yeah...  anyways, lunch has arrived&

[10:42]  AlexDaniel: Committed. 

[10:43] *** hungryd80 left
[10:43] *** hungrydonkey joined
[10:45]  m: use NativeCall; class A is repr { has uint32 $!a }; my $a = $a.new; say cast(Pointer[A], $a);

[10:45]  rakudo-moar c588323e5: OUTPUT: «5===SORRY!5=== Error while compiling ␤Cannot use variable $a in declaration to initialize itself␤at :1␤------> 3r { has uint32 $!a }; my $a = $7⏏5a.new; say cast(Pointer[A], $a);␤    expecting any of:␤        ter…»

[10:45]  m: use NativeCall; class A is repr { has uint32 $!a }; my $a = A.new; say cast(Pointer[A], $a);

[10:45]  rakudo-moar c588323e5: OUTPUT: «5===SORRY!5=== Error while compiling ␤Undeclared routine:␤    cast used at line 1. Did you mean 'cas', 'last'?␤␤»

[10:45]  m: use NativeCall; class A is repr { has uint32 $!a }; my $a = A.new; say nativecast(Pointer[A], $a);

[10:45]  rakudo-moar c588323e5: OUTPUT: «NativeCall::Types::Pointer[A]<0x3b40910>␤»

[10:46]  m: use NativeCall; class A is repr { has uint32 $!a }; my $a = A.new; my $b; nativecast(Pointer[A], $a); my $c = nativecast(Pointer, $a); $b.deref.say

[10:46]  rakudo-moar c588323e5: OUTPUT: «No such method 'deref' for invocant of type 'Any'␤  in block  at  line 1␤␤»

[10:47]  m: use NativeCall; class A is repr { has uint32 $!a }; my $a = A.new; my $b = nativecast(Pointer[A], $a); my $c = nativecast(Pointer, $a); $b.deref.say

[10:47]  rakudo-moar c588323e5: OUTPUT: «A.new␤»

[11:20] *** Kaiepi left
[11:21] *** Altai-man_ joined
[11:24] *** sena_kun left
[11:25] *** Kaiepi joined
[11:30] *** hungryd2 joined
[11:31] *** hungrydonkey left
[11:36] *** hungryd2 left
[11:37] *** hungrydonkey joined
[11:40] *** hungryd68 joined
[11:42] *** hungrydonkey left
[12:11] *** Kaiepi left
[12:13] *** Kaiepi joined
[12:21] *** brrt joined
[12:24] *** hungrydonkey joined
[12:24] *** hungryd68 left
[12:32] *** hungryd77 joined
[12:32] *** hungrydonkey left
[12:36] *** hungrydonkey joined
[12:36] *** hungryd77 left
[12:50]  AlexDaniel: I'm stopping with trying to fix the Range anomalies

[12:50]  lizmat: it simply never ends, right?

[12:50]  I think we need a discussion on how these edge cases should work

[12:51]  or apply some simple rules as:  if startpoint and endpoint are the same, then only 1 value will be generated for ..

[12:51]  and no values will be generated for ^.. ..^ and ^..^

[12:51]  m: dd (NaN..NaN).head(10)

[12:51]  rakudo-moar c588323e5: OUTPUT: «(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq␤»

[12:52]  m: dd (NaN^..NaN).head(10)

[12:52]  rakudo-moar c588323e5: OUTPUT: «(NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN).Seq␤»

[12:52]  m: dd (NaN..^NaN).head(10)

[12:52]  rakudo-moar c588323e5: OUTPUT: «().Seq␤»

[12:52]  m: dd (NaN^..^NaN).head(10)

[12:52]  rakudo-moar c588323e5: OUTPUT: «().Seq␤»

[12:52]  there's currently a test depending on the current NaN .. NaN behaviour

[12:54]  yay

[12:54]  lizmat: IMO we just need to define some predictable and easy to understand behavior for ..

[12:55]  currently it does magic

[12:58]  lizmat: I actually had a draft of a ticket proposing changes to the string behavior with .., and it all made sense until I realized that people often want to have single-letter ascii string ranges

[12:58]  maybe we should re-read "Range and RangeIter semantics" in the specs

[12:58]  and I couldn't make myself propose to use (‘a’.ord..‘z’.ord)».chr insead :D

[12:59]  basically, if a type support .succ that should be used to create the range

[13:00]  m: dd NaN.succ   # the reason NaN..foo produces (NaN,NaN....)

[13:00]  rakudo-moar c588323e5: OUTPUT: «NaN␤»

[13:03]  lizmat: yeah, both .. and ... relying on .succ was my conclusion also, if I'm not mistaken

[13:04]  ok, I thought I could fix this quickly, but am not now with ... refactoring in my head

[13:04]  ¦ rakudo: lizmat self-unassigned (Inf .. Inf) is wrong https://github.com/rakudo/rakudo/issues/3596

[13:05]  ¦ rakudo: lizmat self-unassigned Reversed ranges with NaN are wrong (maybe?) https://github.com/rakudo/rakudo/issues/3599

[13:05]  ¦ rakudo: lizmat self-unassigned (Inf ... Inf) is wrong https://github.com/rakudo/rakudo/issues/3600

[13:05]  ¦ rakudo: lizmat self-unassigned Run time SORRY when dividing an Inf range by 0 https://github.com/rakudo/rakudo/issues/3598

[13:06]  m: use nqp; my $code = start { my $c := nqp::getcomp('Raku') || nqp::getcomp('perl6'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; await $code;

[13:06]  rakudo-moar c588323e5: OUTPUT: «An operation first awaited:␤  in block  at  line 1␤␤Died with the exception:␤    existskey requires a concrete object (got a NQPMu type object instead)␤      in block  at  line 1␤␤»

[13:07]  bisectable6, use nqp; my $code = start { my $c := nqp::getcomp('Raku') || nqp::getcomp('perl6'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; await $code;

[13:07]  Altai-man_, Bisecting by output (old=2015.12 new=c588323) because on both starting points the exit code is 1

[13:07]  Altai-man_, bisect log: https://gist.github.com/f5a3a4774d6fb77af90e523ee64a8f49

[13:07]  Altai-man_, (2016-05-12) https://github.com/rakudo/rakudo/commit/33ef5a95459b95bf7256391a053550d4efe221de

[13:22] *** sena_kun joined
[13:24] *** Altai-man_ left
[13:35]  lizmat: so my thought process was like this: 1) remove magical string special-casing and just let .succ do the work, this is fairly obvious and it also has a bonus of making ‘ab’.IO .. ‘ba’.IO and ‘ab’..‘ba’ function the same way. If we decide that magical pattern generation is very useful we can have a separate sub for that 2) however, IO-like .succ still counts the wrong way for negative numbers, so let's just admit that .su

[13:35]  can't be well defined, ban it and let users choose the behavior they want explicitly 3) OK, cool, but now people can't do simple stuff like ‘a’..‘z’ which is extremely common

[13:36]  maybe instead of banning Str.succ we can make it more magical to count the right way, but uhh…

[13:37]  m: ('ab'.IO .. 'ad'.IO).gist.say

[13:37]  rakudo-moar c588323e5: OUTPUT: «IO::Path.new("ab", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))..IO::Path.new("ad", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))␤»

[13:37]  m: say (‘ab’..‘ba’)[^10]

[13:37]  m: ('ab'.IO..'ad'.IO).gist.say

[13:37]  rakudo-moar c588323e5: OUTPUT: «(ab aa bb ba Nil Nil Nil Nil Nil Nil)␤»

[13:37]  rakudo-moar c588323e5: OUTPUT: «IO::Path.new("ab", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))..IO::Path.new("ad", :SPEC(IO::Spec::Unix), :CWD("/home/camelia"))␤»

[13:37]  m: say (‘ab’..‘ba’)[^10]

[13:37]  rakudo-moar c588323e5: OUTPUT: «(ab aa bb ba Nil Nil Nil Nil Nil Nil)␤»

[13:37]  m: say (‘ab’.IO..‘ba’.IO)[^10]

[13:37]  rakudo-moar c588323e5: OUTPUT: «("ab".IO "ac".IO "ad".IO "ae".IO "af".IO "ag".IO "ah".IO "ai".IO "aj".IO "ak".IO)␤»

[13:38] *** brrt left
[13:38]  m: ('ab'.IO..'ad'.IO)[^4]

[13:38]  rakudo-moar c588323e5: ( no output )

[13:38]  m: ('ab'.IO..'ad'.IO)[^4].say

[13:38]  rakudo-moar c588323e5: OUTPUT: «("ab".IO "ac".IO "ad".IO Nil)␤»

[13:38]  m: ('ab'.IO...'ad'.IO).say

[13:38]  rakudo-moar c588323e5: OUTPUT: «("ab".IO "ac".IO "ad".IO)␤»

[13:39]  another example from my wall of text:

[13:39]  m: say (‘-5’...*)[^10]

[13:39]  rakudo-moar c588323e5: OUTPUT: «(-5 -6 -7 -8 -9 -10 -11 -12 -13 -14)␤»

[13:39]  m: say (-5...*)[^10]

[13:39]  rakudo-moar c588323e5: OUTPUT: «(-5 -4 -3 -2 -1 0 1 2 3 4)␤»

[13:39]  same with .. btw

[13:40]  (why is it counting down? It's not counting down, it's doing .succ on Str!)

[13:40]  .oO( which in this case .succs )

[13:41]  well, that's why you should use dd rather than say

[13:43]  lizmat: as if output printing can fix bad design? :)

[13:44]  that said I have no clue what would be a better one

[13:45]  m: dd "-5".succ, (-5).succ, -5.succ   # shit happens

[13:45]  rakudo-moar c588323e5: OUTPUT: «"-6"␤-4␤-6␤»

[13:45]  ¦ nqp: MasterDuke17++ created pull request #612: Write large chunks of bytecode to a file on the fly instead of doing it all in memory first

[13:45]  ¦ nqp: review: https://github.com/Raku/nqp/pull/612

[13:48]  lizmat: well yeah, and the shittier shit is that .. and ... also do something completely different for strings :)

[13:48] *** Altai-man_ joined
[13:48]  sourceable6: ‘foo’.succ

[13:48]  AlexDaniel, https://github.com/rakudo/rakudo/blob/c588323/src/core.c/Str.pm6#L770

[13:51] *** sena_kun left
[13:52]  Xliff: btw $bisected is unused

[13:53]  afk&

[14:25]  AlexDaniel: :P

[14:36]  So, I've decided to ditch Inline::Perl5::Object and use generated wrapper classes only (using my custom meta class). Not only does this unify a lot, which unveiled a hand full of bugs as it's now exercised by all tests and gives you proper type names for all P5 objects you encounter.

[14:37]  It also got rid of the severe memory leak in our application which now has pretty stable memory usage (~1G after 20K requests instead of >6G).

[14:37]  And it's a _lot_ faster. Those 20K requests took less than 1/6 of the CPU time on the backend application.

[14:37]  wow, nice all around

[14:39]  oh wow

[14:39]  very impressive

[14:40]  Nothing like production code to show you where you went wrong ;)

[14:55]  nine, impressive! If you are around, anything in https://github.com/rakudo/rakudo/issues/3579 rings a bell?

[14:58]  Altai-man_: no

[15:24] *** ufobat__ joined
[15:28] *** ufobat_ left
[15:49] *** sena_kun joined
[15:51] *** Altai-man_ left
[15:51]  m: use nqp; await start nqp::getcomp('Raku').parse('say 42;');

[15:51]  rakudo-moar c588323e5: OUTPUT: «An operation first awaited:␤  in block  at  line 1␤␤Died with the exception:␤    existskey requires a concrete object (got a NQPMu type object instead)␤␤»

[15:52]  59 characters now.

[16:11]  ¦ rakudo: patrickbkr++ created pull request #3602: Fix issue 3581

[16:11]  ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3602

[16:17]  narrowed it further...

[16:18]  https://github.com/rakudo/rakudo/blob/b787095358bcbac4c6326b99e9673e54ef5afd58/src/Perl6/Grammar.nqp#L529 <- it seems `%*COMPILING<%?OPTIONS>` isn't initialized...

[16:25] *** TheAthlete joined
[17:46] *** hungrydonkey left
[17:48] *** Altai-man_ joined
[17:50] *** sena_kun left
[18:17]  Altai-man_: I'm not sure you can just call "parse" and expect it to have all the required compilation state in place...should probably be calling .compile and giving a target

[18:18]  m: use nqp; dd await start nqp::getcomp("Raku").compile("say 42;", target => "parse", :compunit_ok);

[18:18]  rakudo-moar c588323e5: OUTPUT: «Perl6::Grammar.new() #`[139978152996144]␤»

[18:18]  That looks like it's doing the right kind of thing

[18:19] * Altai-man_ takes notes

[18:19]  I suspect it works on the main thread 'cus it just steals the state in dynamic scope of the entrypoint

[18:19]  Which is not exactly robust

[18:19]  jnthn, thanks.

[18:19]  Maybe Perl6::Parser wants patching to use this instead, if it's calling .parse

[18:25]  ¦ rakudo: 2e60552099 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6

[18:25]  ¦ rakudo: Add Exception.message stub

[18:25]  ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/2e60552099

[19:01] *** patrickb joined
[19:06]  bisectable6: class C is Exception { }; C.new.throw

[19:06]  lizmat, Bisecting by output (old=2015.12 new=2e60552) because on both starting points the exit code is 1

[19:07]  lizmat, bisect log: https://gist.github.com/f6078fb7ff7c40b0e22f25a3449e46bf

[19:07]  lizmat, (2017-07-08) https://github.com/rakudo/rakudo/commit/1a4d94930c581e915a2351049e8ee12246c4c26c

[19:07]  bisectable6: old=2020.02.1 class C is Exception { }; C.new.throw

[19:07]  lizmat, On both starting points (old=2020.02.1 new=2e60552) the exit code is 1 and the output is identical as well

[19:07]  lizmat, Output on both points: «Died with C␤  in block  at /tmp/0KmXCd7r2_ line 1␤␤»

[19:13] *** TheAthlete left
[19:25]  ¦ problem-solving: FCO assigned to jnthn Issue No easy way of getting the N highest/lowest items on a list https://github.com/Raku/problem-solving/issues/172

[19:33] *** vrurg left
[19:33] *** vrurg_ joined
[19:36] *** vrurg_ left
[19:39] *** vrurg joined
[19:49] *** sena_kun joined
[19:49]  ¦ rakudo: patrickbkr++ created pull request #3604: Fix building non-moar backends on Windows

[19:49]  ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3604

[19:50] *** Altai-man_ left
[19:52] *** vrurg_ joined
[19:53] *** vrurg left
[20:03] *** patrickb left
[20:16] *** patrickb joined
[20:18] <[Coke]> #172 there seems like something very specific to add to the language.

[20:28] *** vrurg_ left
[20:29] *** vrurg joined
[21:41] *** patrickb left
[21:48] *** Altai-man_ joined
[21:50] *** sena_kun left
[21:53]  ¦ roast: 755e5f208b | (Elizabeth Mattijsen)++ | S03-sequence/exhaustive.t

[21:53]  ¦ roast: Some more ... tests ported

[21:53]  ¦ roast: review: https://github.com/Raku/roast/commit/755e5f208b

[23:49] *** sena_kun joined
[23:50] *** Altai-man_ left