buggable 🎺🎺🎺 It's time for the monthly Accidental /win Lottery 😍😍😍 We have 1 ballots submitted by 1 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 99! Congratulations to samcv! You win a can of WD40!
timotimo congrats, samcv 00:01
btw, can we allow surrogate pairs in our utf8 encoder so i can support json properly in json::fast? ;_;
samcv woah
\o/
at least i have won something on my vacation
00:12 Ven`` joined 00:32 Ven`` joined
timotimo actually, scratch that, i should encode it as two \uXXXX escapes instead 00:38
not sure what i was thinking there
wowza, my test suite already contains a test where the combiner that is on a outside-16bit-character is itself an outside-16bit-character 00:44
(it's a flag thingie i believe?) 00:49
m: say "\c[REGIONAL INDICATOR SYMBOL LETTER H]" ~~ /<[\x[1000]..\x[10FFFF]]>/ 00:57
camelia ｢🇭｣
timotimo m: say "\c[REGIONAL INDICATOR SYMBOL LETTER H, REGIONAL INDICATOR SYMBOL LETTER R]" ~~ /<[\x[1000]..\x[10FFFF]]>/
camelia Nil
timotimo i beg your pardon?
m: say "\c[REGIONAL INDICATOR SYMBOL LETTER H, REGIONAL INDICATOR SYMBOL LETTER R]" ~~ /<[\x[0]..\x[10FFFFF]]>/ 01:00
camelia Nil
timotimo surely there's a bug here
m: say "\c[REGIONAL INDICATOR SYMBOL LETTER H, REGIONAL INDICATOR SYMBOL LETTER R]" ~~ /:m <[\x[1000]..\x[10FFFFF]]>/ 01:09
camelia ｢🇭🇷｣
01:09 Ven`` joined 02:29 Zoffix joined 02:59 ilbot3 joined 03:46 Ven`` joined 04:11 Kaiepi joined 06:59 piojo_ joined 07:33 piojo_ joined 08:08 piojo_ joined 08:51 geospeck joined 09:40 committable6 joined 09:59 domidumont joined 10:24 domidumont joined 11:03 Zoffix left 11:04 piojo_ joined 11:09 domidumont joined
nine New year, new chance to get inline_in_place up and running. 11:35
What I've found out so far: NQP's build fails with "compunitcodes requires an MVMCompUnit". That's apparently caused by exists_stage getting inlined into compile in HLL::Compiler. 11:36
exists_stage seems to be one of the few methods that use an explicit "return" instruction even in normal control flow (incidentally, "compile" is another one). 11:37
This raises suspicion about throwpayloadlex or more concrete search_for_handler_from. If that finds the wrong handler, the mysteriously wrong return value of "compile" could be explained. 11:39
Actually I shouldn't be surprised about that. After all I still append the inlinee's handlers to the handlers table. So they are gonna be searched last. Which in turn means that the caller's handlers will be found instead. 12:16
12:33 piojo_ joined 13:09 statisfiable6 joined 13:11 nativecallable6 joined
jnthn nine: Did you rebase your work on HEAD, 'cus towards the end of the year I reworked a bunch of exception handler + inlining stuff? 13:30
nine jnthn: yes, that's where this new issue comes from. I already strongly suspected a handler issue but forgot most of that during my month long not entirely voluntary programming hiatus. 13:33
But at least I'm now sure about which code exactly gets broken. That reduces the search space considerably. 13:34
I'm currently investigating whether it's possible to retain the current "copy and extend the handlers table" scheme. 13:35
That would e.g. be possible by searching the handlers table in reverse, retaining the latest found matching handler and on encountering an MVM_EX_INLINE_BOUNDARY returning that match. 13:38
jnthn It should be possible, with the introduction of the MVM_EX_INLINE_BOUNDARY thing 13:40
I guess you removed the "duplicate the caller's handlers" thing? 13:41
nine Actually not yet 13:42
I assume those are currently just redundant and won't hurt. So it seems safer to fix the "finding wrong handler" issue first and getting to a stable base before changing that code. 13:45
jnthn Perhaps so, yes. 13:49
Just wondering if they could interfere in some way, but can't immediately think of one.
Glad to see you back working on this, anyways. nine++ :)
14:07 geospeck joined
nine Just reversing the search order really messes up all the skip logic 15:36
15:42 releasable6 joined
jnthn Reversing the search order makes no sense to me; the point of the search is to find the innermost handler. 15:45
nine Well the idea was that as inlined handlers are appended to the table, a reverse search would find them first. It's of course more complicated than that because we want to find the _first_ innermost handler. So we need to continue to search until we hit the MVM_EX_INLINE_BOUNDARY. 15:47
Err....does the MVM_EX_INLINE_BOUNDARY mark the start or the end of an inlinee?? 15:48
jnthn Oh...I see the issue, because there was no overlap before appending them was fine. I guess maybe we need to prepend them now. 15:53
It marks the end of it
Effectively, the boundary
The commit introducing it had some explanatory comments, if you didn't already see them 15:54
nine Actually the explanations are in the comments above the code :) 15:56
And I have no idea why I completely ignored this: "Upon reaching an (or, in the case of skip_first_inline, a second) inline boundary indicator, there are two cases that apply. We take the inline that we are leaving" 15:58
It doesn't get much more explicit than that and should leave no doubt as to what a boundary marks
Prepending the handlers is where I get to deal with outdated handler index annotations all over the place, isn't it? 16:09
jnthn Oh, right, yes. 16:17
I guess that is why I appended them ;) But it shouldn't be too hard to go through and bump 16:18
In fact, it's just a change of tweakery: now we have to bump the inlinee's indexes, we'd instead now bump the inliner's indexes 16:19
So there should already be code doing this than can be repurposed
Take care of updating the dead handlers table also, if there are any
Gotta go for a bit, bbl
16:21 domidumont joined 16:23 Ven`` joined 16:25 geospeck joined 16:48 geospeck joined 16:57 squashable6 joined, reportable6 joined, zakharyas joined 16:59 Ven`` joined 17:22 bloatable6 joined, coverable6 joined, benchable6 joined 17:39 bisectable6 joined 17:54 geospeck joined 18:11 Kaiepi joined 18:14 MasterDuke joined 18:34 quotable6 joined, releasable6 joined, squashable6 joined, benchable6 joined, bloatable6 joined
AlexDaniel squashable6: next 18:37
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 3 days and ≈15 hours (2018-01-06 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
18:48 zakharyas joined 19:04 zakharyas joined 19:07 unicodable6 joined 19:18 Kaiepi joined 19:24 Kaiepi joined 19:39 greppable6 joined
Geth MoarVM: MasterDuke17++ created pull request #773:
Use FSA for string storage		 19:40
20:46 geospeck joined 20:58 evalable6 joined 21:30 Kaiepi joined 22:01 leont joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/01/01/...-6-alerts/ 22:02
23:45 quotable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!