github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 reportable6 left 00:05 reportable6 joined 01:10 Kaeipi joined, Kaiepi left 01:17 lucasb left 01:59 frost-lab joined, frost-lab left 02:00 frost-lab joined 03:51 Voldenet left 03:56 Voldenet joined, Voldenet left, Voldenet joined 04:28 frost joined, frost left 04:44 frost-lab left 04:45 frost-lab joined, frost-lab left 05:50 frost-lab joined 05:51 frost-lab left, frost-lab joined 06:02 reportable6 left 06:04 reportable6 joined 06:35 squashable6 left 06:38 squashable6 joined 07:50 Altai-man_ joined 07:51 sena_kun left 08:30 camelia left, Geth left, leont left, rba left 08:31 camelia joined, Geth joined, leont joined, rba joined 08:35 demostanis[m] left 08:48 dogbert11 left 08:54 dogbert17 joined
dogbert17 does this really work? 08:55
Nicholas good *, dogbert17
dogbert17 hello Nicholas. What happened to nwc10? 08:56
Nicholas I think it's still abailable to register :-)
available
but I grabbed the one I like better
08:57 demostanis[m] joined
nine A real name on IRC...that's unusual 08:57
dogbert17 do I have to register my nick or did it transfer over automatically somehow?
nine: did you see that Masterduke found another SEGV yesterday? 09:00
nine yes 09:01
dogbert17: you have to register
dogbert17 nine: thx 09:02
registration done 09:05
the SEGV in t/spec/S17-lowlevel/cas.t can happen on different tests an the debugger tends to stop at a couple of different locations 09:06
e.g. 0x00007ffff7939a5e in MVM_gc_object_id (tc=0x7fffe011e3d0, obj=0x0) at src/gc/objectid.c:10 09:07
10 if (obj->header.flags2 & MVM_CF_SECOND_GEN) {
nine But it's always due to NULL values where there shouldn't be any 09:08
dogbert17 yes 09:09
FWIW, spesh is innocent, same error with MVM_SPESH_DISABLE=1
nine does it also occur i a debug build? 09:10
dogbert17 you mean one with --debug and --no-optimize? 09:11
I always run with --debug so yes
nine That's good. --no-optimize would be even better 09:12
Sadly I cannot reproduce that one
dogbert17 I'm trying with --no-optimize now ... 09:13
do you have a small nursery?
nine 8192
oh... not ok 24 - CAS on linked list with Scalar attribute head works (4)
# Failed test 'CAS on linked list with Scalar attribute head works (4)'
# at t/spec/S17-lowlevel/cas.t line 121
# expected: '2002000'
# got: '961093'
dogbert17 so test failure instead of SEGV then
nine at least with spesh disabled 09:14
dogbert17 seems to me that running with --no-optimize makes the bugs more elusive 09:15
nine more elusive or completely unreproducible? 09:16
dogbert17 I'd say more elusive although the word is still out on t/spec/S17-lowlevel/cas.t 09:17
nine Finally: #0 0x00007fd8423b512a in MVM_gc_object_id (tc=0x402fe10, obj=0x0) at src/gc/objectid.c:10 09:18
dogbert17 horay
was rr running by any chance
nine no :( 09:19
not even the debugger, so all I got is a core dump
dogbert17 perhaps that's enough 09:22
09:36 moon-child left, moon-child joined
nine It may have to be. It's quite possible that it just cannot fail in rr because rr is single threaded. It simulates multiple threads but can switch between them only on syscalls or retired conditional branches (whatever those are exactly) 09:38
09:40 gugod left 09:41 gugod joined
dogbert17 so it sort of has the same problem as valgrind 09:47
10:19 LizBot left
MasterDuke is decodertakechars expected to convert \r\n to \n? 10:20
10:21 LizBot joined
nine Another NULL: 0x00007ffff78fde18 in MVM_interp_run (tc=tc@entry=0x403c0c0, initial_invoke=0x0, initial_invoke@entry=0x7ffff7915c90 <thread_initial_invoke>, invoke_data=0x0, invoke_data@entry=0x7ffff7915c90 <thread_initial_invoke>, outer_runloop=0x6, outer_runloop@entry=0x0) at src/core/interp.c:1981 10:26
1981 GET_REG(cur_op, 0).o = MVM_6model_get_how(tc,
Found in t/spec/S17-lowlevel/cas.t (with MVM_SPESH_DISABLE=1)
MasterDuke caught it in rr?
nine No, haven't managed to get any failure in rr 10:27
It actually seems to be closely related to the NULL in nqp::objectid 10:29
MasterDuke i was wondering about that
nine Mu's WHICH code does this: nqp::concat( nqp::concat(nqp::unbox_s(self.^name), '|'), nqp::objectid(self))
The NULL I just found is self in self.^name, and objectid is again called on self
MasterDuke i don't remember what the fix was, think that was all you 10:31
nine The curious part is: tracing back that NULL gives me:
00008 set loc_0_obj, loc_12_obj
00011 set loc_5_obj, loc_0_obj
00012 decont loc_6_obj, loc_5_obj 10:32
00013 gethow loc_6_obj, loc_6_obj
Work registers 0, 5 and 6 contain NULL in their object slot. But register 12 actually contains a Node object
Actually having those two related crashes tells us something more: that loc_0_obj does indeed become NULL after first containing a value. In my crash it happens just early enough to trip up gethow, while in dogbert's case it happend between gethow and objectid 10:37
dogbert17: seems like I now got MasterDuke only on freenode and you only here and we're all looking at the same problem :/ 10:38
dogbert17: colabti.org/irclogger/irclogger_lo...-05-22#l40
MasterDuke this does seem like the sort of thing that's much much harder to debug when it can't be caught in rr 10:39
nine yeah :/ Just like yesterday's hunt 10:40
10:43 Kaeipi left 10:44 Kaeipi joined
nine So what do those cases have in common? They are both about highly threaded code, both have NULLs appearing and both are seeminlgy connected to garbage collection 10:44
In my case the 00009 param_sn loc_3_obj seems to be a place where GC can happen, i.e. right after setting loc_o_obj 10:45
Oh, and it's possible that the bugs only appear in optimized builds 10:46
dogbert17: have you managed to reproduce in a --no-optimize build yet?
dogbert17 nine: no :( 10:48
not giving up though 10:49
nine By adding a MVM_gc_enter_from_allocator(tc) to MVM_args_slurpy_name I seem to be able to trigger segfaults in a non-optimized build! 10:50
Try adding a MVM_gc_enter_from_allocator(tc) to MVM_args_slurpy_named
MasterDuke change anything about how catchable it is in rr? 10:51
10:53 Kaeipi left, Merfont joined
nine I fear not 10:54
Oh and I removed the obj && in OP(decont) to catch it earlier
Wait...what?! 10:56
10:56 frost joined
nine (gdb) p tc->cur_frame->work[0] 10:56
dogbert17 nine: around any special line?
nine Cannot access memory at address 0xffffffff00000032
(gdb) p tc->cur_frame
$7 = (MVMFrame *) 0xffffffff0000001a
MasterDuke that looks...not normal/correct 10:57
nine early on. I put it before the for loop
So...tc->cur_frame gets messed up?
dogbert17 ok, will do
10:58 Merfont left, Merfont joined
lizmat 1a = 26 is number of alphabetic characters ? 10:59
nine And yet another segfault in decont, this time in at SETTING::src/core.c/Any.pm6:459 (/home/nine/rakudo/blib/CORE.c.setting.moarvm:infix:<===>) 11:00
I think I just found a GC issue in MVM_args_slurpy_name, though it's probably unrelated 11:11
rr finally cought something! Though it's MoarVM panic: Invalid GC status observed while blocking thread; aborting 11:18
Not exactly what I expected
11:19 dogbert17 joined
dogbert17 nine: so now you found another bug? 11:20
nine After adding MVM_gc_mark_thread_(un)blocked(tc) around MVM_conditionvariable_wait in OP(condwait) I can't reproduce it anymore
I don't think that's a fix though. AFAIK marking the thread blocked just avoids deadlocks
11:27 cog left
nine Actually that "Invalid GC status observed while blocking thread" is thrown by my MVM_gc_mark_thread_blocked 11:32
Ah because MVM_conditionvariable_wait already marks the thread as blocked 11:36
Don't know why I didn't check that first
11:37 cog joined 11:57 ggoebel left
nine I just realized that my debug-on script still contained --optimize=2 11:59
12:02 reportable6 left 12:03 reportable6 joined
dogbert17 so, are we any closer to understanding what's going on? 12:08
nine I fear gcc optimizations are a crucial part of this
I can get it to explode easily with --optimize=2, but have yet to see it crash even once with --optimize=1 12:09
dogbert17 that doesn't bode well 12:14
lizmat does that affect the static optimizer? 12:15
nine no, gcc
lizmat ah, ok
nine Let's see if I can find a specific optimization that triggers it...
dogbert17 oddly enough, when compiling with -O1 the compiler suddenly complains a bit about the code 12:16
rc/strings/iter.h:181:28: warning: ‘n_gi.next_strand’ may be used uninitialized in this function [-Wmaybe-uninitialized] 12:17
181 | gi->next_strand++;
| ~~~~~~~~~~~~~~~^~
nine yeah 12:18
dogbert17 how is that possible
nine Well optimization changes the code. This may hide such issues 12:20
dogbert17 I guess -O1 slows the code down quite a bit 12:22
nine That's why I hope to find no specific optimization that triggers the issue 12:23
If it's just a timing issue we're still in territory that I kinda understand :D
OTOH if an optimization causues issues, we're still at nine's debugging rule #1 "the bug is always in your own code". In this case it would mean that we're relying on undefined behavior somewhere. 12:24
It just failed with --optimize='1 -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively -fexpensive-optimizations -ffinite-loops -fgcse -fgcse-lm -fhoist-adjacent-loads -finline-functions -finline-small-functions -findirect-inlining 12:25
-fipa-bit-cp -fipa-cp -fipa-icf -fipa-ra -fipa-sra -fipa-vrp -fisolate-erroneous-paths-dereference -flra-remat -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks-algorithm=stc -freorder-blocks-and-partition -freorder-functions -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec'
dogbert17 the number of different optimizations is staggering 12:26
12:26 ggoebel joined
nine Well the 2x speed up of running an optimized build must come from somewhere :) 12:27
#2 0x00007ffff78cb7c1 in MVM_interp_run (tc=0x2, tc@entry=0x7fffe406c370, initial_invoke=0x7ffff36ae810, initial_invoke@entry=0x7ffff7919310 <thread_initial_invoke>, invoke_data=0x7ffff36ae810, invoke_data@entry=0x7ffff7919310 <thread_initial_invoke>, outer_runloop=0x7ffff75034a5 <__GI_raise+325>, outer_runloop@entry=0x0) at src/core/interp.c:213
That tc=0x2 somehow doesn't look right 12:28
One frame up it's still 0x7fffe406c370
dogbert17 rr ?
nine By now I've given up on rr
dogbert17 might github.com/MoarVM/MoarVM/issues/1431 contain any clues? (extreme longshot) 12:30
nine Nothing immediate stands out, but those are certainly not good 12:33
Down to --optimize='1 -fschedule-insns -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively -fexpensive-optimizations -ffinite-loops -fgcse -fgcse-lm -fhoist-adjacent-loads 12:38
dogbert17 fdelete-null-pointer-checks sounds a bit scary 12:39
nine The check for NULL values I added to OP(set) is what triggers most often now 12:41
Just --optimize='1 -fschedule-insns -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps' now 12:42
dogbert17 so the -f<opt> stuff is -O2 optimizations then I guess 12:44
nine yes 12:45
12:57 squashable6 left 12:58 squashable6 joined 13:05 squashable6 left, squashable6 joined
nine And the winner is: --optimize='1 -fschedule-insns' 13:12
"If supported for the target machine, attempt to reorder instructions to eliminate execution stalls due to required data being unavailable. This helps machines that have slow floating point or memory load instructions by allowing other instructions to be issued until the result of the load or floating-point instruction is required.
13:19 AlexDaniel joined
dogbert17 nine++ 13:24
how much does it affect perf?
13:24 sourceable6 left, bisectable6 left, statisfiable6 left, notable6 left, linkable6 left, benchable6 left, nativecallable6 left, quotable6 left, committable6 left, bloatable6 left, reportable6 left, coverable6 left, greppable6 left, evalable6 left, squashable6 left, unicodable6 left, releasable6 left, shareable6 left, tellable6 left
jnthn Wonder if some well-placed memory barrier insertions might prevent whatever reordering is to blame 13:25
nine I've tried sprinkling volatile everywhere but it didn't have any effect so far 13:26
13:28 AlexDaniel is now known as whateverable
jnthn Maybe try using MVM_load for loads that maybe don't want reordering 13:29
nine That'd be easy. If only I knew which loads that might be :D So far it simply looks like a register is losing its value during a GC run 13:30
13:30 whateverable is now known as AlexDaniel
nine And yesteray's (still unsolved) issue was a node in the ConcBlockingQueue losing its value 13:31
jnthn Oh, I thought this was about ConcBlockingQueue, sorry. 13:33
13:33 sourceable6 joined
jnthn (Where ordering totally could be an issue) 13:34
13:34 notable6 joined, quotable6 joined, reportable6 joined, bloatable6 joined
nine Btw. ConcBlockingQueue's shift already contains two MVM_barrier() 13:35
13:35 coverable6 joined, nativecallable6 joined, releasable6 joined, linkable6 joined, committable6 joined
jnthn Yeah, I just noticed that while glancing for anything obviously missing 13:39
To the degree that there's anything obvious about that code :)
Seems silly younger me didn't leave a link to the paper describing the algorithm so now I'll have to dig it up again... 13:40
Altai-man_ the Blin is clear 13:41
anything blocking the release?
nine Thinking about how NULLs in work registers or queues can be related to GC and instruction ordering issues I wondered if the GC writes NULL when trying to write the object's new address. Usually the new address comes from an allocator, but there's one place where we read it from memory set by someone else: github.com/MoarVM/MoarVM/blob/mast...ect.c#L226 13:45
I changed that to *item_ptr = MVM_load(&item->sc_forward_u.forwarder); and so far haven't seen a failure
until right after I wrote this of course... 13:46
jnthn What about a barrier after github.com/MoarVM/MoarVM/blob/mast...ect.c#L337 ? 13:48
nine Trying that right now 13:49
And for good measure a barrier before the line where we read
jnthn Yeah, either that or the load. 13:51
(I believe the load pretty much barrier then read) 13:52
nine Yes, MVM_load is AO_load_full and the full is about the used barrier 13:54
10 minutes without failure! I'm starting to believe that this might be it 14:00
Also running the ConcBlockingQueue golf in a loop. So far so quiet
Altai-man_: if this turns out to be right it may be worth slipping it into the release 14:01
jnthn I wonder if an MVM_store would be a bit more efficient than the write and then the barrier, at least on some platforms 14:02
(I don't know if it'd ever be worse, but it may be better if there's a half-barrier)
Uh, I don't think it would ever be worse, I meant. 14:03
I do wonder how much this costs
I suspect on x64 "not much" because it's quite strongly consistent anyway
nine switching to a fully optimized build now and removed all volatile decorators that I added 14:04
10 minutes later and it's still going strong. That and the fact that both the diagnosis and the fix make perfect sense, makes me declare victory :) 14:17
jnthn :D 14:18
nine++
lizmat I would be against slipping it into the release
nine lizmat: why?
jnthn lizmat: Why?
lizmat we'd at least want another Blin run for that, no? 14:19
.oO( in unison! )
well, maybe I'm over cautious
jnthn Famous last words, but: it feels really quite low risk to me, if it's no more than adding memory barriers
nine Just 2 MVM_barrier() 14:20
jnthn In terms of not introducing semantic regressions anyway
Performance is another question
lizmat ok if Altai-man_ is ok with it
ah, performance... what if this makes everything 2x as slow ?
nine Any performance impact would be limited to GC runs
lizmat logs.liz.nl/raku-dev/2021-05-21.html#16:19 # last test-t 14:21
jnthn An impact like 2x as slow feels hugely unlikely :)
I'd not be surprised if the only way to see the difference is with cachegrind 14:22
nine MVM_barrier compiles to a single MFENCE assembly instruction
lizmat ok, you've convinced *me* :-) 14:23
jnthn (e.g. it's noise in any timing benchmarks)
I do think using MVM_load and MVM_store would be better than the full barriers, but I suspect the assembly might come out the same on x64 14:24
nine Since MVM_load maps to AO_load_full and MVM_store maps to AO_store_full, we'd get full barriers in any case 14:25
nwc10 I can't look at this "today" but if you provide the two versions I can have a look on ARM, where (a) it might make a different and (b) I stand a fighting chance of understaning the assembler output
although this 32 bit addressing is still very new-fangled.
nine 1892:# define AO_load_full(addr) (AO_nop_full(), AO_load_acquire(addr)) 14:26
jnthn Ah, OK
And I guess MVM_nop_full is what MVM_barrer maps to? 14:27
nine yes
jnthn Then yeah, no difference
nine I like the MVM_barrier() version more because we don't have to cast from size_t to MVMCollectable*
jnthn Yeah, makes sense if the assembly omes out the same 14:28
*comes
nwc10: (what to compare) I guess it'll just be with the commit nine will do and without 14:29
I'm kinda amazed that we've gotten away with this for so long.
nine Anyway it seems like to fix the visible symptoms at least we'd get away with an MVM_barrier when writing. Which makes sense as this will certainly block the code reordering that would make it set the CF_FORWARDER_VALID flag before actually writing the forwarder address
nwc10 I meant ""using MVM_load and MVM_store would be better than the full barriers, but I suspect the assembly might come out the same on x64" 14:30
jnthn Yeah, I sorta think we might get away wiht it just there
nwc10: Well, since then we've realized that those two *are* doing full barriers (at the moment)
nine The funny bit is that in our recent job posting I wrote about me as the CTO who understands software development including "how to fix that damned threading bug in the garbage collector". Now I'll have a specific commit to link to doing just that :D 14:31
jnthn :D 14:32
lizmat nine++ 14:33
Altai-man_ nine++
nine Question remains: do we add a barrier before the reading instruction just to be safe? 14:34
Altai-man_ about including it to the release: if I had a better machine I'd do a Blin run now, it'd take like a hour more maybe, just in time to write a changelong, but currently I'll assume it to be safe.
jnthn nine: I guess there's still a risk of the compiler moving the read of the pointer ahead of the read of the flag if we don't 14:35
nine Yeah, let's keep it in there
Altai-man_ also, am I correct this commit deals with `non-AsyncTask fetched from eventloop active work list`? 14:38
or at least some case of it
as I saw it in my Cro::LDAP and it was annoying, so I'd welcome the fix very much
14:40 frost-lab left, frost left
jnthn afk for a bit 14:41
Geth MoarVM: 8532c6bb3b | (Stefan Seifert)++ | src/gc/collect.c
Fix object pointers getting turned into NULL by multi-threaded GC

Highly threaded code could segfault randomly because NULL values appeared in registers or e.g. a ConcBlockingQueue. The reason was that the C compiler re-ordered code when optimizing causing the MVM_CF_FORWARDER_VALID flag to get set before we actually wrote the forwarder address. This could result in a different thread reading a NULL from forwarder and using that as an item's ... (7 more lines)		 14:49
14:58 AlexDaniel left
Altai-man_ by the way, during review I am deleting merged one-commit branches with fixes by nine, I hope that's ok, insult me otherwise 15:00
nine oh, sure 15:02
jnthn: I think we got away for it so long because it only affects multi-threaded programs with cross-thread data access 15:49
dogbert17 nine++, do you think these changes might have fixed the insidious return-in-tap bug as well? 15:51
Altai-man_ hmmmmm 15:55
is the CI failure related to the commit? :)
15:58 nativecallable6 left, sourceable6 left, committable6 left, coverable6 left, linkable6 left, releasable6 left, reportable6 left, bloatable6 left, notable6 left, quotable6 left, sourceable6 joined, coverable6 joined 15:59 reportable6 joined, quotable6 joined, linkable6 joined 16:00 bloatable6 joined, notable6 joined, releasable6 joined
Altai-man_ saves the log and re-runs the test 16:01
16:01 committable6 joined
Altai-man_ it seems we have `test plan not found` segfault every now and then 16:01
16:01 nativecallable6 joined
nine dogbert17: I don't have much hope, but wouldn't rule it out either 16:19
16:26 childlikempress joined 16:30 moon-child left, camelia left 16:31 camelia joined
Altai-man_ did a bump 16:33
hmm 16:34
dogbert17 nine: it turns out that the error, i.e. return-in-tap, is still present
Altai-man_ after a re-run it's a failure again 16:35
t/02-rakudo/11-deprecated.t (Wstat: 256 Tests: 0 Failed: 0)
Non-zero exit status: 1
Parse errors: No plan found in TAP output
but with another test this time
Can github.com/MoarVM/MoarVM/commit/a7...6cdcb43fb1 be the reason?
16:36 dogbert11 joined 16:41 committable6 left, releasable6 left, bloatable6 left, reportable6 left, coverable6 left, LizBot left, dogbert17 left 16:46 committable6 joined, releasable6 joined, bloatable6 joined, coverable6 joined 16:47 sourceable6_ joined 16:48 quotable6_ joined, linkable6_ joined, dogbert17 joined, ggoebel_ joined 16:52 notable6_ joined 16:54 nativecallable6_ joined 16:55 ggoebel left, sourceable6 left, linkable6 left, quotable6 left, dogbert11 left, notable6 left, nativecallable6 left 16:58 bloatable6 left, releasable6 left, bloatable6 joined
Altai-man_ no, it is clearly older 17:00
I still don't like it a lot, but we can make it a blocker for the next release (hopefully) 17:01
17:08 bloatable6 left, committable6 left, coverable6 left
nine dogbert17: IIRC return-in-tap is most probable a spesh bug 17:10
17:12 releasable6 joined, bloatable6 joined, coverable6 joined, committable6 joined
Geth MoarVM/release-2021.05: ee8c70c7df | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2021.05 release
 17:13
MoarVM/release-2021.05: d2dc3bb01e | Altai-man++ | VERSION
Bump VERSION for release
MoarVM: Altai-man++ created pull request #1499:
Release 2021.05		 17:14
MoarVM: ee8c70c7df | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2021.05 release
 17:15
MoarVM: d2dc3bb01e | Altai-man++ | VERSION
Bump VERSION for release
MoarVM: d57f575c27 | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #1499 from MoarVM/release-2021.05

Release 2021.05
nine Altai-man_: any other output by 11-deprecated.t? Did it create a core dump? 17:18
Altai-man_ nine, not really, I think. I see how different seemingly not related tests are failing on Windows with "TAP plan not found", it's also apparently a race we had for some time now. 17:19
and as it is something we had already, the release is done
17:22 Altai-man_ left 17:23 sena_kun joined
nine sena_kun++ 17:23
17:28 releasable6 left
dogbert17 sena_kun++ 17:40
17:48 [Coke]_ joined 17:49 moon-child joined, coverable6 left, bloatable6 left, committable6 left 17:51 [Coke] left, nine left, childlikempress left 17:53 bloatable6 joined, committable6 joined, coverable6 joined 17:57 childlikempress joined, dogbert17 is now known as 073AAAPQ4, dogbert17 joined 18:01 nativecallable6_ left, notable6_ left, sourceable6_ left, 073AAAPQ4 left, linkable6_ left 18:05 camelia left, quotable6_ left, moon-child left, reportable6 joined 18:10 dogbert2 joined 18:19 dogbert17 left 18:22 camelia joined 18:24 [Coke] joined, releasable6 joined 18:33 [Coke]_ left 18:55 sourceable6 joined 18:57 linkable6 joined 18:59 camelia left 19:01 notable6 joined 19:05 nativecallable6 joined 19:10 camelia joined 19:12 quotable6 joined 19:14 moritz left
MasterDuke jnthn: did you see my question about decodertakechars earlier? 19:19
oh, nm i think, i see the translate_newlines option... 19:32
20:09 zakharyas joined 20:14 MasterDuke joined
MasterDuke jnthn: in case you don't get github notifications, i would appreciate a glance at github.com/Raku/nqp/pull/724 to see if it's somewhat reasonable (and if so, should i implement the translate_newline checking in the other methods?) 20:23
20:30 ilogger2_ joined 21:20 zakharyas left 21:41 quotable6 left, nativecallable6 left, notable6 left 21:42 nativecallable6 joined 21:43 quotable6 joined 21:51 gugod left
sena_kun t/04-nativecall/13-cpp-mangling.t (Wstat: 256 Tests: 0 Failed: 0) 22:06
Non-zero exit status: 1
Parse errors: No plan found in TAP output
that's from MVM_gcc_njit_libffi
t/02-rakudo/06-is.t (Wstat: 256 Tests: 0 Failed: 0)
Non-zero exit status: 1
Parse errors: No plan found in TAP output
that's from Win_MVM_reloc 22:07
this looks very bad to me, so that's certainly a blocker for the next time. :S
if the solution will be found soon, maybe a point release is necessary, though it depends
MasterDuke hopefully this week i can get the nqp+rakudo ci pipelines a little more synced up with the recent changes to the moarvm ci pipeline, one benefit is getting a little more info in such cases 22:09
sena_kun hmm, MoarVM repo has no `severe` tag nor `critical`. :S 22:13
anyway, the ticket is created. I know this kind of info is a pathetic joke when it comes to such kinds of horrible scary issues, but I have not much on my hands, sorry. :( 22:14
22:17 childlikempress is now known as moon-child 23:46 quotable6 left, nativecallable6 left, notable6 left, coverable6 left, bloatable6 left, reportable6 left, sourceable6 left, committable6 left, linkable6 left, releasable6 left, sourceable6 joined, reportable6 joined, nativecallable6 joined, quotable6 joined, releasable6 joined 23:48 committable6 joined, bloatable6 joined, coverable6 joined, notable6 joined, linkable6 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!