github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke samcv: src/strings/decode_stream.c:145:27: warning: implicit declaration of function ‘MVM_string_utf16be_decodestream’; did you mean ‘MVM_string_utf16_decodestream’? [-Wimplicit-function-declaration] 01:44
same for '*le_*' at line 148 01:45
travis-ci MoarVM build failed. Samantha McVey 'Fix fprintf compiler warning in main.c 03:53
travis-ci.org/MoarVM/MoarVM/builds/429866466 github.com/MoarVM/MoarVM/compare/a...5b3cdaa2bc
brrt \o 05:37
nwc10 o/ 05:43
brrt ohai nwc10 07:00
dogbert2 it's very silent around here 11:02
lizmat drops a pin 11:03
brrt not everyday can be a party :-)
brrt has just looked at the source code for libuv, and is less-than-excited of replicating that for the sync IO ops 11:17
so I guess the tc loop structure is here to stay :-)
dogbert2 are you working on your fork branch? 11:30
brrt no, it's ready for review / merge, as far as I'm concerned 11:47
I'm not intersted in cloning the libuv behaviour
dogbert2 brrt: didn't jnthn find a jit bug a few weeks ago? 12:37
which he worked around 12:38
brrt he might have, but I am not aware of it 12:46
dogbert2 brrt: perhaps my memory decieves me, let me backlog for a bit 12:52
brrt dogbert2: well, if you find anything, be sure to let me know 13:38
dogbert2 brrt: I haven't found anything, perhaps my mind is playing a prank on me :( 13:52
perhaps jnthn remembers
jnthn On postrelease-opts, there are some SEGVs now and then in spectest that go away with MVM_JIT_DISABLE=1 13:55
jnthn wonders if gist.github.com/dogbert17/2d499ec5...9c7db6107b is still relevant/happening 14:06
brrt jnthn: say no more, i'll investigate :-) 14:09
or mabe say more
jnthn Well, MVM_SPESH_BLOCKING=1 makes them go away, so argh.
Or it was a lucky run.
brrt oh...
hmmmm
jnthn Since I was getting them only sometimes
diakopter or it was unlucky both times 14:10
jnthn I've also got one that shows up reliably under blocking but only with JIT disabled...wow.
diakopter heisencatdebugs 14:11
dogbert2 jnthn: I can retry the postrelease-opts branch when I get home 14:32
jnthn: also I found something odd in master, i.e. github.com/MoarVM/MoarVM/issues/960
jnthn ooh, interesting 14:35
brrt wonders if ASAN makes them more reliable 14:40
jnthn Well, latest spectest run was fine, and the last faily one (with JIT) was some days ago... 14:55
jnthn doing another run now
oh, no, yesterday
But still, rebuilt everything sience
*since
timotimo btw we don't have hllbool and hllboolfor in facts.c
jnthn And a second clean run 14:57
(this is with postrelease-opts)
dogbert2: I think the DU chain fail is due to a mistake in the hllboolfor opt 15:03
dogbert2 jnthn: aha, that makes sense, i.e. I was certain that it had been eradicated from postrelease-opts 15:04
jnthn Well, it's there too now, because I rebased onto master :) 15:06
dogbert2 as for postrelease-opts, you enabled a new check there for SC-index. I guess that bug hasn't been fixed yet?
it was possible to trigger that check with e.g. gist.github.com/dogbert17/24e6033e...c8cfdfb444 15:07
jnthn Did you manage to get that bug to happen on master too? 15:10
dogbert2 haven't tried 15:11
I guess I'll have to move that commit to master first 15:13
jnthn Hmm, no commit reports here? 15:16
Anyway, github.com/MoarVM/MoarVM/commit/7a...96e7634d89 15:17
dogbert2 jnthn++ 15:19
jnthn I can repro gist.github.com/dogbert17/24e6033e...c8cfdfb444 one in every few runs
brrt yay, i guess :-) 15:20
this is JIT sensitive?
jnthn Nope, shows up with MVM_JIT_DISABLE=1 15:21
brrt oh, hm..
jnthn However, I can't get it to happen with MVM_SPESH_DISABLE=1
Not in many, many runs 15:24
Nor with MVM_SPESH_INLINE_DISABLE=1
dogbert2 perhaps a smaller nursery might help 15:25
jnthn Well, or it's inlining related ;)
dogbert2 any theories?
jnthn Need some more data yet 15:26
timotimo i have a discovery bit for hllbool 15:28
but hllboolfor would also be interesting, surely
jnthn tssk...can't get it to fail any more 15:29
brrt jnthn: maybe jit-bisect.pl --spesh helps 15:30
dogbert2 jnthn: I just remembered that I had (almost) golfed the problem: gist.github.com/dogbert17/23b5e847...c582760963 15:38
dogbert2 if it is indeed the same one 15:38
dogbert2 changes location & 15:39
jnthn I think it's the MVM_CF_REF_FROM_GEN2 addition 15:44
diakopter I do not understand what in the world they are talking about on #perl6 .. some rakudo fork they want to be an alternative alias in the debian packages? 15:52
jnthn Darn it, thought I'd got a fix, but no... 16:00
[Coke] not a fork. 16:02
being able to call an installed rakudo with either `rakudo` or `perl6` instead of just `perl6`
ilmari I think the point is to be able to choose which perl6 implementation gets to be /usr/bin/perl6 16:15
timotimo github.com/MoarVM/MoarVM/commit/24...2865db06f5 - let spesh discover the type of hllbool[for] 16:18
jnthn Think I have a fix for the GC crash 16:36
dogbert17 jnthn++, was it a tricky problem? 16:41
Geth MoarVM/postrelease-opts: 9e90cdd6ce | (Jonathan Worthington)++ | 2 files
Don't set ref'd from gen2 flag during GC

Parallel GC relies on us only updating the object flags from the thread that owns the object (or the nominated thread to GC that thread's objects). The updates caused by the write barrier touching the object that was referenced caused races that could lead to incorrect GC behavior, which typically showed up as an invalid SC (which was really because the forwarder lives in the same slot that the SC used to on a
  moved object).		 16:45
travis-ci MoarVM build failed. Timo Paulssen 'let spesh discover the type of hllbool[for]' 16:48
travis-ci.org/MoarVM/MoarVM/builds/430129934 github.com/MoarVM/MoarVM/compare/0...860d4c0949
jnthn dogbert17: Yeah, somewhat 16:48
Makes sense in hindsight :)
timotimo damn, yeah
dogbert17 are there any other problems left on this branch after this fix?
jnthn No idea :) 16:49
If there are, I don't see them in spectest :)
dogbert17 cool
jnthn I should try it out on $big-customer-application
We'll merge postrelease-opts immediately after the next MoarVM release :) 16:52
dogbert17 yay
jnthn Yeah, the customer app ran alright, I guess I should give it a few runs. 17:02
Since it's does plenty of parallel work so stresses things quite well
dogbert17 is running a spectest with sundry debug flags set 17:06
jnthn away for a bit 17:07
dogbert17 MoarVM oops: Malformed DU chain: writer set of 18(11) in BB 117 is incorrect 17:11
Spesh of 'old_rx_mods' (cuid: 592, file: gen/moar/Perl6-Grammar.nqp:4028)
jnthn: time permitting, try running t/spec/S05-mass/named-chars.t with the DU chain checker enabled 17:13
brrt jnthn++ 17:35
timotimo man, we really need a fuller API for printing out pieces of spesh graph 17:50
nine Handler information now seem to get written properly :) 20:13
timotimo nice work 20:14
mst I see bannerbot is correctly not vocing things spamming 20:18
mst let's see if a +o Sigyn has some fun 20:19
travis-ci MoarVM build passed. Timo Paulssen 'let spesh discover the type of hllbool[for]' 21:21
travis-ci.org/MoarVM/MoarVM/builds/430129934 github.com/MoarVM/MoarVM/compare/0...860d4c0949
Geth MoarVM: 3e94a68f6f | (Samantha McVey)++ | src/strings/utf16.c
Pass through BOM with utf16le and utf16be

I have decided for now to act similar to Perl 5 and for writing and reading to utf16le and utf16be it will not act any differently if there is a BOM encountered.
So it will pass through the BOM and zero width non-breaking space for ... (6 more lines)		 22:28

Powered by Cro and the Raku® Programming Language.

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

Thank you!