00:03 Kaiepi left 00:24 leont left 00:54 Altai-man_ joined 00:56 sena_kun left 01:11 chansen_ left 01:19 chansen_ joined 02:55 sena_kun joined 02:56 Altai-man_ left 03:36 softmoth joined 04:39 evalable6 left, unicodable6 left, sourceable6 left, committable6 left, bisectable6 left, greppable6 left, statisfiable6 left, benchable6 left, releasable6 left, quotable6 left, linkable6 left, bloatable6 left, notable6 left, nativecallable6_ left, tellable6 left, shareable6_ left, coverable6 left, reportable6 left, squashable6 left, sourceable6 joined 04:40 bisectable6 joined, shareable6 joined 04:41 benchable6 joined, reportable6 joined, squashable6 joined, committable6 joined, unicodable6 joined, coverable6 joined, statisfiable6 joined, nativecallable6 joined 04:42 notable6 joined, evalable6 joined, bloatable6 joined, tellable6 joined, greppable6 joined, linkable6 joined, releasable6 joined, quotable6 joined 04:54 Altai-man_ joined 04:56 sena_kun left 06:04 Kaiepi joined 06:34 softmoth left
[Tux] Rakudo version 2020.05.1-277-g87e91defd - MoarVM version 2020.05-61-g63051257b
csv-ip5xs1.042 - 1.075
csv-ip5xs-2012.977 - 13.201
csv-parser28.223 - 28.682
csv-test-xs-200.395 - 0.400
test9.892 - 10.096
test-t3.227 - 3.599
test-t --race1.089 - 1.575
test-t-2060.258 - 62.143
test-t-20 --race14.647 - 14.719
06:51
is there a reason for this extreme raise or what? I don't se aan extreme load on my workstation 06:52
06:55 sena_kun joined 06:56 Altai-man_ left 07:30 patrickb joined
patrickb o/ 07:30
I'm working on a small module that generates native exec runner programs. Idea: Have a precompiled program that retrieves some arguments attached to its executable (similar to what selfcontained zip archives do) and does exec (an emulation on Windows) with those arguments and the given arguments. 07:32
Now I'd like some feed back on how to best encode the arguments that I attach to the execuable.
I think it's easiest to attach stuff by adding a magic marker prefix which I can then search in my own executable. 07:34
As far as I currently see the only data I need to attach is an array with the arguments. What would be a sensible way to encode those? I'd like to have it as platform / compiler independent as possible. Also I'd like to generate the data to attach to my program via a raku program. 07:35
Is the struct data layout stable enough to try to generate a blob directly? 07:36
Will endianess bite me?
Hm... this might have been better asked on #raku, but now it's too late... 07:38
lizmat Files=1306, Tests=111378, 216 wallclock secs (28.84 usr 8.27 sys + 3032.90 cusr 282.70 csys = 3352.71 CPU) 07:52
patrickb I have to leave, but will backlog. 08:02
o/
08:07 patrickb left
Geth rakudo: atroxaper++ created pull request #3752:
#3751 Fix vcs conflict marker detection
08:09
linkable6 RAKUDO#3751 [open]: github.com/rakudo/rakudo/issues/3751 Find a version control conflict marker only after unspace
Geth roast: atroxaper++ created pull request #647:
Add test for a vcs conflict marker detection
08:10
08:14 atroxaper joined 08:54 Altai-man_ joined 08:56 sena_kun left
Geth rakudo: 65e412f7a8 | (Mikhail Khorkov)++ | src/Perl6/Grammar.nqp
#3751 Fix vcs conflict marker detection

Previously vcs conflict marker detection work only after unspace. Now the marker can be detected as after unspace as without it.
08:57
rakudo: f4747daf70 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Grammar.nqp
Merge pull request #3752 from atroxaper/3751

  #3751 Fix vcs conflict marker detection
linkable6 RAKUDO#3751 [open]: github.com/rakudo/rakudo/issues/3751 Find a version control conflict marker only after unspace
roast: 98a60f88d2 | (Mikhail Khorkov)++ | S32-exceptions/misc.t
Add test for a vcs conflict marker detection
08:58
roast: 786afd5e2f | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-exceptions/misc.t
Merge pull request #647 from atroxaper/3751

Add test for a vcs conflict marker detection
09:22 leont joined 09:53 MasterDuke left
Geth nqp: 9d156a4ffa | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP for latest goodies, like a new libuv
10:42
10:55 sena_kun joined 10:56 Altai-man_ left
Geth rakudo: 5b507c8adf | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get latest MoarVM and NQP goodies
10:59
dogbert11 o/ 11:06
Have anyone looked into the massive slowdown that [Tux] mentioned above? 11:08
test-t 3.227 - 3.599
lizmat hmmm.. hadn't noticed it yet... 11:10
lemme do some local test-t's
hmmm.. that *does* look way off 11:12
dogbert11 I have an idea what it might be 11:13
lizmat, to confirm, can you try again without github.com/MoarVM/MoarVM/commit/63...20adb26414 11:14
sena_kun hopes it is not a new "take a severe perf drop or segfaults into a release" issue 11:15
lizmat dogbert11: down from 2.237 to 1.272 on my machine, so I'd say: yes, that's the reason :-( 11:32
jnthn ^^ 11:33
perhaps, since this was a temporary fix indeed, we should just revert it ? 11:35
11:52 jjatria left
lizmat bisectable6: sub foo() { fail }(); CATCH { default { say .backtrace.elems } } 11:53
bisectable6 lizmat, Bisecting by output (old=2015.12 new=5b507c8) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/f9f0303736f85aef6b...4afc2d969d 11:54
lizmat, (2019-07-12) github.com/rakudo/rakudo/commit/96...11ee58c65a
lizmat bisectable6: old=2020.05.1 sub foo() { fail }(); CATCH { default { say .backtrace.elems } } 11:55
bisectable6 lizmat, On both starting points (old=2020.05.1 new=5b507c8) the exit code is 0 and the output is identical as well
lizmat, Output on both points: Ā«4ā¤Ā»
11:57 jjatria joined
lizmat bisectable6: old=2020.05.1 sub foo() { fail }(); CATCH { default { say .backtrace.list[2].code.name } }' 11:58
foo
bisectable6 lizmat, On both starting points (old=2020.05.1 new=5b507c8) the exit code is 1 and the output is identical as well
lizmat, Output on both points: Ā«04===SORRY!04=== Error while compiling /tmp/N2fvrP0IOYā¤Strange text after block (missing semicolon or comma?)ā¤at /tmp/N2fvrP0IOY:1ā¤------> 03t { say .backtrace.list[2].code.name } }08ā04'ā¤Ā»
lizmat bisectable6: old=2020.05.1 sub foo() { fail }(); CATCH { default { say .backtrace.list[2].code.name } }
bisectable6 lizmat, On both starting points (old=2020.05.1 new=5b507c8) the exit code is 0 and the output is identical as well
lizmat, Output on both points: Ā«fooā¤Ā»
lizmat bisectable6: old=2020.02 sub foo() { fail }(); CATCH { default { say .backtrace.list[2].code.name } }
bisectable6 lizmat, On both starting points (old=2020.02 new=5b507c8) the exit code is 0 and the output is identical as well
lizmat, Output on both points: Ā«fooā¤Ā»
lizmat wonders why t/spec/S32-exceptions/misc.t is failing for her 11:59
hmmm... HEAD appears to have test errors with JSON::Fast 12:13
will look at it when back 12:14
afk for a few hours&
jnthn lizmat, dogbert11: Please try it as `if (IS_CONCRETE(is->invocation_handler)) {` to see if that help 12:17
*helps
12:42 atroxaper left 12:54 Altai-man_ joined 12:56 sena_kun left
dogbert11 jnthn: that does ineed help :) 13:08
*indeed
jnthn dogbert11: OK, good, if it spectests clean and you've time to commit it (or PR it), please do :)
(I'm on new-disp in the middle of a tricky debug...) 13:09
dogbert11 jnthn: will test and submit PR 13:11
jnthn Thanks! 13:14
[Tux]++ # helping us spot perf regressions
13:45 lichtkind joined 14:05 atroxaper joined
ShimmerFairy I found another segfault, this time all you have to do is nqp::mvmstartprofile(nqp::hash("kind", "instrumented")); nqp::mvmendprofile() (poking at the coredump in gdb at the moment) 14:35
jnthn At a wild guess, it probably expects something to be recorded and trips up when nothing ever was. 14:42
And of course that's a useless thing to do, so nobody ever ran into this before :) 14:43
ShimmerFairy That's the minimum case. I initially had a simple nqp::hash(...) statement between the two, assuming it would log something.
jnthn No, that ain't how it works; you need to make a call to actually profile.
It can't instrument the frame it's sitting in. We're crazy enough to do OSR, but not so crazy as to do it just for the fun of it :) 14:44
ShimmerFairy It's a good thing I'm trying to improve the documentation, never said anything about what the profiler can and can't log. 14:46
jnthn The nqp:: op docs? 14:48
ShimmerFairy Yeah, but just the docs/ directory in general. I want to write a compiler for an old language in NQP, and if I need to read the source code to understand it, might as well improve the docs. 14:49
(and btw, making a call did, of course, work)
jnthn Long short, but: did anyone here ever do any analysis of the use of flattening args and the stability of the resulting arg set at a particular callsite? 14:53
*shot
14:54 sena_kun joined
jnthn I'm guessing the ratio of megamorphic sites must be somewhat higher, but I don't have that much intuition how much higher... 14:55
14:57 Altai-man_ left 14:59 softmoth joined
Geth rakudo/new-disp: 8a0b228a80 | (Jonathan Worthington)++ | 3 files
Mostly switch qualified method calls to dispatch

Which needs filling in an amount of the general dispatch-y logic too. Some tests fail because multiple dispatch caching needs to be done in terms of the new dispatcher, which is a rather larger task.
15:04
[Tux] jnthn, np. Glad to be of help. 15:11
Just call when you need another run. Note that I am not glued to my screen. I need some sleep once in a while :)
Geth rakudo/new-disp: 370d1c84b0 | (Jonathan Worthington)++ | 3 files
Replace .? spesh plugin with dispatcher

Probably a win over the spesh plugin, in so far as even before spesh it can avoid invoking the args-discarding code block and just evaluate to a Nil constant instead.
15:36
15:40 dogbert11 left
Kaiepi IO::Socket::Async.connect seems to perform around 10-15% better on average with my changes to dns resolution for v6.e compared to v6.c's changes so far 15:40
that's with happy eyeballs' logic for dns queries and connections, but not address sorting yet
jnthn ooh, nice 15:41
15:56 maggotbrain left 16:04 atroxaper left
Geth rakudo/new-disp: 049536c1f8 | (Jonathan Worthington)++ | 3 files
Move private method dispatch to the dispatcher
16:12
16:54 Altai-man_ joined 16:56 sena_kun left
Geth rakudo/new-disp: ec6b477b89 | (Jonathan Worthington)++ | 2 files
Stub in the assign dispatcher

For now, it just always produces the slow path. Switch over to using the dispatcher rather than the spesh plugin, to see that this much works.
17:01
jnthn Home time, but by this point I've either done or got WIP on every one of the spesh plugins being moved over to the new dispatcher.
17:10 patrickb joined 17:14 patrickz joined 17:17 patrickb left
[Coke] nice. 17:27
17:40 patrickz left
lizmat JSON::Fast testing current fails with: 18:14
raku(68007,0x10dcb65c0) malloc: *** error for object 0x7faf54d466e0: pointer being freed was not allocated 18:15
raku(68007,0x10dcb65c0) malloc: *** set a breakpoint in malloc_error_break to debug
18:24 MasterDuke joined
MasterDuke lizmat: which test? sounds like it might be something from that leak cleanup PR of mine jnthn++ merged earlier today 18:26
lizmat MasterDuke: was that from before the bump? if so, then probably yes 18:27
it does this trying to parse a *very* troublesome piece of invalid JSON 18:28
MasterDuke hm. i see a double free in t/01-parse.t, but the backtrace doesn't point exactly to code i modified in the PR 18:31
lizmat t/01-parse.t in github.com:timo/json_fast.git
I feared 87e91defd5a600e1c3a9 could be the reason, but the error occurs without that one as well 18:32
linkable6 (2020-06-11) github.com/rakudo/rakudo/commit/87e91defd5 Make Match.caps about 35% faster
MasterDuke it's happening in src/6model/reprs/MVMString.c's gc_free. maybe an exception is being caught (because i did do some freeing of string stuff before exceptions), which keeps the object alive and then it is collected and freed again? 18:33
18:55 sena_kun joined 18:57 Altai-man_ left
timotimo can give valgrind or asan a try 19:01
MasterDuke timotimo: it's here github.com/MoarVM/MoarVM/blame/mas...f16.c#L258 19:10
timotimo that's where it gets freed the second time? 19:11
MasterDuke first time
timotimo or the first time?
ok let me look very sharply at the code
ah, yeah 19:12
MasterDuke second time is github.com/MoarVM/MoarVM/blob/mast...ring.c#L68
timotimo since the gc_free function doesn't null-check, you can't just null out the str->body.storage.blob_32
but the moment the string object was allocated via gc_alloc_init it has already escaped
and gc_free_unmarked will get to it 19:13
so all the MVM_free(ā€¦blob_32) in this function are suspect
MasterDuke hm. guess i need to go back and double check all those changes?
timotimo alternatively, move the allocation towards the return 19:14
yeah, with this new insight, this pattern should be easy-ish to spot
MasterDuke so if some thing has been repr-allocated, and then some storage malloced into it, we shouldn't free the attached storage? 19:15
timotimo that sounds about right 19:16
MasterDuke (in this case, yeah, the simple fix to the move the allocation to after the exceptions can be thrown and then the frees aren't needed at all)
timotimo doesn't have to be MVM_repr_alloc_init, that's just a shortcut for REPR(type)->alloc(size) + REPR(type)->init(*obj, blah) 19:17
MasterDuke yep
i can't swear i'll be able to audit all the changes from the PR this evening, but i should probably be able to by tomorrow 19:18
gfldex react whenever run("/usr/bin/find", "/mnt", :out).out.lines { say $++ } 19:31
evalable6 0
gfldex dies with:
Died because of the exception:
Malformed UTF-8 near bytes 47 6c 81
in block <unit> at -e line 1
Should Rakudo be able to handle malformed utf-8 that pops out of Proc::Async? 19:32
MasterDuke hm. or should the user be required to manually decode/encode before calling .lines? 19:36
lizmat perhaps it should default to utf8-c8 ?
MasterDuke timotimo: oh, can't simply move the allocation, it's written to in the loop immediately after. so i'll just remove the frees 19:40
timotimo hm? 19:41
the allocation of the buffer can be separate from the allocation of the object
MasterDuke oh, you meant move the object allocation after the loop? 19:42
timotimo yes
MasterDuke hm. is that better? then we still need the frees before the throw
19:42 AlexDani` joined
timotimo it is better, because then you can free the buffer without crashing moarvm 19:43
Geth roast: 041a5fce65 | (Elizabeth Mattijsen)++ | 2 files
Remove some RT references that are confusing
19:44
roast: 9dcc29e03a | (Elizabeth Mattijsen)++ | S05-mass/rx.t
Remove confusing quote
roast: 74ca4b2231 | (Elizabeth Mattijsen)++ | 357 files
Update majority of RT ticket references to new repo
timotimo if you just throw out the frees in front of the exception throws, the object with its buffer will stick around until the next GC run
19:44 AlexDaniel left
MasterDuke ok, i'll just move the object allocation then 19:44
timotimo [X] bully contributors into taking my position by snarkily point out problems with alternative solutions they bring up 19:45
i'm very good person
gfldex filed as #3753 19:46
MasterDuke heh. you're making good points though
timotimo i can make the same good points with less snark, though
MasterDuke hm, i didn't actually pick up on much snark 19:47
timotimo maybe just a random moment of too much self-reflection 19:51
MasterDuke to confirm, gist.github.com/MasterDuke17/4971e...b7a782d0b7 is what you were thinking/looks good? 19:52
timotimo + MVMString *result = (MVMString *)REPR(result_type)->allocate(tc, STABLE(result_type)); 19:55
+ result->body.storage.blob_32 = buffer;
i think that's a variable declaration after code
MasterDuke oops, that's a copy+paste and forgot to remove the decl 19:58
fixes the double free in json::fast 20:02
what about this one github.com/MoarVM/MoarVM/pull/1291...fa4972R115 20:11
timotimo can be fine, if you null out the condvar field after freeing it 20:19
MasterDuke so just make it MVM_free_null? 20:28
timotimo think so 20:29
20:48 MasterDuke left 20:54 Altai-man_ joined 20:56 sena_kun left 21:17 MasterDuke joined 22:55 sena_kun joined 22:57 Altai-man_ left 23:48 leont left