github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:49 lkoranda22 joined 00:50 p6bannerbot sets mode: +v lkoranda22, lkoranda22 left 01:47 Kaiepi left 01:52 Kaiepi joined 01:53 p6bannerbot sets mode: +v Kaiepi 02:55 DarthGandalf24 joined, p6bannerbot sets mode: +v DarthGandalf24 03:00 DarthGandalf24 left 03:14 linuxmodder7 joined, linuxmodder7 left 03:19 raSter^9 joined, p6bannerbot sets mode: +v raSter^9 03:21 raSter^9 left
Geth MoarVM: MasterDuke17++ created pull request #935:
Silence an incorrect GCC string overflow warning		 03:29
03:43 Syfer joined 03:44 p6bannerbot sets mode: +v Syfer, Syfer left 03:45 Kaiepi left 04:43 promote joined 04:44 p6bannerbot sets mode: +v promote 04:48 promote left 05:42 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 06:25 shareable6 joined, p6bannerbot sets mode: +v shareable6 06:41 robertle joined 06:42 p6bannerbot sets mode: +v robertle 06:56 Kaiepi left 06:57 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 07:24 macky6 joined 07:25 p6bannerbot sets mode: +v macky6 07:26 macky6 left 07:50 Ricardus1 joined 07:51 Ricardus1 left 07:58 avar left 08:02 zakharyas joined, p6bannerbot sets mode: +v zakharyas 08:04 dogbert11 left 08:10 AlexDaniel left
Geth MoarVM/pea: ca89cd992f | (Carl Masak)++ | docs/bytecode.markdown
Remove incorrect byte sum

This number used to be correct, but 8a348d7480d47f1214d3201a7bd4c840bfb3f054 turned everything into 32-bit integers, and failed to update this sum from 10 to 12.
Probably unlikely that the sum will update again, but removing it because presenting the total number of bytes doesn't add much in terms of documentation. (Cf. it being the wrong number for the past five years.)		 08:39
masak :) 08:40
ur. wrong branch. dang.
Geth MoarVM: 082dddfdd2 | (Carl Masak)++ | docs/bytecode.markdown
Remove incorrect byte sum

This number used to be correct, but 8a348d7480d47f1214d3201a7bd4c840bfb3f054 turned everything into 32-bit integers, and failed to update this sum from 10 to 12.
Probably unlikely that the sum will update again, but removing it because presenting the total number of bytes doesn't add much in terms of documentation. (Cf. it being the wrong number for the past five years.)		 08:41
masak git++
08:57 ski_ joined 08:58 p6bannerbot sets mode: +v ski_ 08:59 ski_ left 09:02 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Carl Masak 'Remove incorrect byte sum 09:02
travis-ci.org/MoarVM/MoarVM/builds/413478119 github.com/MoarVM/MoarVM/compare/3...2dddfdd228
09:02 travis-ci left 09:03 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 09:04 p6bannerbot sets mode: +v avar
masak I doubt that my docu update was what broke the build. 09:05
"===SORRY!=== Found a MoarVM binary but was not able to get its version number." 09:06
I saw that one in a build break a while back. no idea what causes it. 09:07
09:11 lizmat joined 09:12 p6bannerbot sets mode: +v lizmat, lizmat_ joined 09:13 p6bannerbot sets mode: +v lizmat_ 09:14 lizmat__ joined 09:15 p6bannerbot sets mode: +v lizmat__ 09:16 lizmat left, lizmat_ left 09:17 lizmat joined, p6bannerbot sets mode: +v lizmat 09:18 lizmat__ left 09:32 Typhon24 joined 09:33 p6bannerbot sets mode: +v Typhon24, Typhon24 left 09:37 Kaiepi left 10:01 BranchPredictor2 joined, BranchPredictor2 left
nwc10 $ ./perl6-m -Ilib t/04-nativecall/06-struct.t 10:13
===SORRY!===
No such spesh plugin 'decontrv' for current language
jnthn wat
nwc10 indeed :-/ 10:14
jnthn How can that even happen...
nwc10 also ASAN still excited
at least last night
hadn't got to the end yet to retest
jnthn: MVM_SPESH_NODELAY=1 10:15
jnthn oh...
Darn, can't reproduce the error 10:17
nwc10 I also have +#define FSA_SIZE_DEBUG 1 10:18
+#define MVM_SPESH_CHECK_DU 1
+#define MVM_ARRAY_CONC_DEBUG 1
and MVM_SPESH_BLOCKING=1
Geth MoarVM: 50b063e045 | (Jonathan Worthington)++ | 2 files
Mark sp_speshresolve as :useshll

Since plugins are resolved for the current HLL, so inlining this op will cause a mis-lookup.		 10:19
jnthn See if that helps
dogbert2 MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 -Ilib t/04-nativecall/06-struct.t 10:22
jnthn Yeah, that's what I ran
dogbert2 failed for me, but I'm just compiling your fix ... 10:23
preliminary findings are promising :) 10:24
nwc10 jnthn: OK, about to test. ASAN excitement was paste.scsys.co.uk/581373
dogbert2 nwc10: I reported that for you as github.com/MoarVM/MoarVM/issues/931 10:25
nwc10 now paste.scsys.co.uk/581374
beleive these are identical apart from addresses
and sadly diakopter's believed fix didn't fix *that*
dogbert2: thanks, yes, saw that in passing but then forgot that you'd done that 10:26
dogbert2 jnthn: my 32 bit Linux system gives your 'Mark sp_speshresolve as :useshll' fix a thumbsup :-) 10:28
jnthn yay :)
nwc10 "there will be a delay" - I'm told that lunch is ready
NQP build in progress
dogbert2 github.com/MoarVM/MoarVM/issues/931 is a bit odd though 10:29
the actual line causing ASAN/valgrind barfage seems to be github.com/MoarVM/MoarVM/blob/mast...ker.c#L336 10:31
dunno of that gives rise to any theories?
10:39 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Mark sp_speshresolve as :useshll 10:39
travis-ci.org/MoarVM/MoarVM/builds/413512903 github.com/MoarVM/MoarVM/compare/0...b063e04511
10:39 travis-ci left 10:48 Kaiepi joined 10:49 p6bannerbot sets mode: +v Kaiepi 10:52 zakharyas left
jnthn Will look at the bugs later... Been sketching out a spesh plugin for return type check / coercion handling 11:00
In the least valuable case this will halve the size of the type check bytecode we emit 11:01
Spesh was already quite good at stripping it all out anyway
11:02 statisfiable6 joined
jnthn But it's still quite bloaty in the unoptimized form 11:02
Plus a ton of error strings in the constant table etc.
11:02 p6bannerbot sets mode: +v statisfiable6
jnthn lunch; bbiab 11:06
11:08 Facilitating joined 11:09 p6bannerbot sets mode: +v Facilitating 11:13 Facilitating left 11:21 lizmat left 11:35 lizmat joined, p6bannerbot sets mode: +v lizmat 11:37 brrt joined 11:38 p6bannerbot sets mode: +v brrt 12:01 lizmat left 12:03 lizmat joined 12:04 p6bannerbot sets mode: +v lizmat
dogbert2 jnthn: cool, do you think the new plugin will have an effect on |Tux| code? 12:09
jnthn Not sure 12:12
Though I'm hoping it'll let me improve the inlining situation around array access which quite possibly would help 12:20
dogbert2 yes, it was something with going above the inlining limit or some such 12:21
jnthn Rakudo now builds using the plugin
Fails 3 tests from make test
dogbert2 doesn't seem so bad
jnthn Yeah, with all the definite/coercion/Nil/Failure special cases in there, it's rather complex 12:23
12:24 brrt left 12:27 zakharyas joined
dogbert2 You should arm yourself with a cup of 'post lunch coffee' 12:28
12:28 p6bannerbot sets mode: +v zakharyas
jnthn Ah, hmm 12:31
Yeah, it's I think because the callercode op gives wrong results if the caller is inlined 12:33
Thankfully, I recently built a mechanism for fixing these things :)
Yup, that helps a lot :) 12:49
Anyone got a recent build handy and can tell me the size of their CORE.setting.moarvm? 12:51
Geth MoarVM: 09717adec8 | (Jonathan Worthington)++ | 6 files
Make the callercode op inline-aware

If the caller frame had performed inlining, then we would get the wrong callercode result.		 12:53
lizmat jnthn: 14075648
as of HEAD just now
jnthn Mine with the change is 14047512 12:54
lizmat nice reduction
jnthn m: say 14075648 - 14047512
camelia 28136
jnthn make test happy, 2 spectest regressions I need to look at 12:55
lizmat m: say 14047512 / 14075648
camelia 0.99800109
jnthn ah, darn, it doesn't have entirely good performance consequences though :( 12:56
Wonder why
lizmat jnthn: fwiw, moarvm size last october was 12849568 12:57
jnthn Yeah, the opts can't always keep up with the CORE.setting additions :) 12:59
nwc10 CORE.setting.moarvm: 14075232 13:05
masak CORE.setting.moarvm: 14082176 (this is on Rakudo 7c08ba7) 13:07
13:13 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Make the callercode op inline-aware 13:13
travis-ci.org/MoarVM/MoarVM/builds/413567653 github.com/MoarVM/MoarVM/compare/5...717adec889
13:13 travis-ci left 13:16 brrt joined 13:17 p6bannerbot sets mode: +v brrt
jnthn boggles at where the slowdown coulda come from 13:17
dogbert2 speaking of slowdowns, is it correct to say, that atm, some code runs slower than it did before you started on the performance grant 13:21
because some opts haven't yet beeen implemented?
13:23 egos6 joined
jnthn It's possible, and even where there's opts done, there's trade-offs 13:23
13:24 p6bannerbot sets mode: +v egos6 13:25 egos6 left
dogbert2 there was one commit, where the text explicitly said that this would make things slower. I can't find it atm but I believe that it had something to do with moving some code from MoarVM to nqp 13:26
jnthn Ah, yeah
brrt \o
dogbert2 hi brrt
brrt .tell Kaiepi I would actually kind of rather have not a reimplementation of the lego JIT 13:27
yoleaux brrt: I'll pass your message to Kaiepi.
brrt ohai dogberg2
dogbert2
dogbert2 so now some code is almost two times slower than 2018.06
:)
diakopter images a floating DogBerg
*imagines
jnthn 171,437,489 /home/jnthn/dev/MoarVM/src/spesh/deopt.c:uninline [/home/jnthn/dev/MoarVM/install/lib
That...might have something to do with it... 13:28
dogbert2 aha
diakopter hopes for a 99.9999% slowness reduction
jnthn yeah, absolute flood of 13:29
Deopt one requested by JIT in frame 'pull-one' (cuid '10348') (330 -> 398)
Recreated frame 'consume-line-chars' (cuid '3829')
In the deopt log :)
dogbert2 does anyone know if part of Perl 6 has been inspired by Julia or could it be the other way around 13:34
diakopter I thought Julia was much older 13:37
dogbert2 I reacted to blurbs like 'Julia uses multiple dispatch as a paradigm, making it easy to express many object-oriented and functional programming patterns.' 13:38
and 'Julia is dynamically-typed, feels like a scripting language'
the spruced up their homepage a bit - julialang.org/ 13:39
ilmari First appeared: 2012 according to wikipedia
diakopter oh 13:40
masak dogbert2: Julia appeared in 2012, at which point Perl 6 had had multi dispatch *implemented* for a few years
so if anything, Julia was inspired by Perl 6
dogbert2 masak: cool
it seems to be the up and coming lang if your'e doing at lot of maths 13:41
masak yes, I wish Julia well -- it seems a cool, well-designed language 13:43
jnthn For some reason, we're inserting a guard that looks for a type object, which is bonkers 'cus most of the time it's a concrete instance, but also, we don't even care if it's a type object 13:45
diakopter jnthn: kiwf?
jnthn language class time, bbl 13:46
masak what a cliffhanger! 13:47
[Coke] am i the only one who tries to read "useshll" as sean connery? 14:20
Kaiepi that's alright brrt 14:23
yoleaux 13:27Z <brrt> Kaiepi: I would actually kind of rather have not a reimplementation of the lego JIT
lizmat [Coke]: I think so :-) 14:24
diakopter [Coke]: I do 14:27
[Coke]: the offishers and I will shubmerge beneath you and shcuttle the ship 14:28
lizmat ah, like that...
you just mean a heavy Scottish accent
ok, I can follow *that*
brrt i'd rather have an implementation built on the expression JIT, since that will involve far fewer assembly, and can reuse many more moving parts 14:30
timotimo jnthn: what do you think is the impact of making speshresolve :usehll? 14:35
we can totally have a speshresolvefrom op that has an hll name parameter 14:38
Kaiepi fair 14:47
14:55 nebuchadnezzar left
brrt Kaiepi: the downside is, that isn't totally possible yet because we haven't translated everything to expression JIT again 15:05
*already
Kaiepi ah 15:06
brrt so
:-)
jnthn timotimo: I'd expect it's close to zero 15:16
timotimo: We have some guts code written in NQP that is called from Perl 6 code
But we have little the other way that's hot that I can think of, and NQP doesn't use spesh plugins
timotimo OK 15:19
jnthn So...what's wrong with this thing... 15:20
15:21 AlexDaniel joined 15:22 AlexDaniel left, AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
jnthn ho, the stats are bogus 15:29
408:
timotimo what spesh logs make?
jnthn 2 x type Str (TypeObj)
204 x static frame 'identity' (151) (caller is outer: 0, multi 0)
2 x type tuple:
Type 0: Str (TypeObj)
Where are the types for the other 202 calls? :)
15:44 Slumlord_16 joined 15:45 p6bannerbot sets mode: +v Slumlord_16
jnthn still didn't figure out where on earth they're getting lost to... 15:45
15:45 Slumlord_16 left
timotimo getting confused by indices? 15:46
like, the 408?
or the correlation id getting messed up somehow?
jnthn No, the offset is OK
I guess maybe perhaps kinda but...that's still odd
Why are all the static frame entries OK? 15:47
timotimo no idea :(
jnthn And why do we get two - but only the type object cases - resolved?
uh, logged 15:48
I wonder if somehow the call to the spesh plugin confuses it
15:50 robertle left 15:51 Zoffix joined, p6bannerbot sets mode: +v Zoffix
timotimo oh, jnthn, are you -1 or +1 on adding a "first time invoked" attribute to profiler call graph nodes? 15:52
jnthn What would it mean? :) 15:53
15:53 channels joined
jnthn Or rather, how would it differ from seeing if the call count isn't zero? 15:54
15:54 p6bannerbot sets mode: +v channels
timotimo well, just whenever a new node appears in the call graph we record what time-since-start it was 15:54
15:54 channels left
timotimo it'd help correlate different phases of programs against the GCs for example 15:54
jnthn ah, I see 15:55
Yeah, no problem
Zoffix Can utf8_c8 produce more bytes than in the original stream? If change `bytes` to `(bytes + 1)` in this malloc: github.com/MoarVM/MoarVM/blob/mast..._c8.c#L471 it fixes the SEGV in R#2158 trying to figure out if the result is undersized or if the position gets messed up somewhere.
synopsebot R#2158 [open]: github.com/rakudo/rakudo/issues/2158 [SEGV][regression][tests committed][āš  blocker āš ] :enc<utf8-c8> on Proc drops content / SEGVs
timotimo i'm also considering putting a "rss or maxrss at time of collection" thing in, but that would require careful accounting so as not to count the whole profiler data as well 15:56
jnthn More bytes, yes, but I can't think of a case where it'd result in more than one grapheme per byte
And we're allocating graphemes there 15:57
Zoffix ah, ok
jnthn Ohh.
Unless maybe there's a partial byte in the buffer
e.g. of bytes from the previous buffer that didn't before a char yet 15:58
So in that case + 1 fixing it would make sense
Zoffix FWIW, this is the bytes I'm reading from `cat tehfile`: github.com/perl6/roast/blob/b6fc8e....t#L21-L28 15:59
And when I was golfing those bytes, the SEGV would occur at 4-byte intervals (if I shorten the buf by 1 byte, no segv, 2, 3 bytes, no segv, 4 bytes, SEGV again 16:00
jnthn Yeah, that fits 16:01
So the + 1 is probably right
Zoffix jnthn: as a fix to the bug?
jnthn Yes 16:02
Zoffix Ah, cool
\o/
jnthn (As in, there's a reason for it to be a sensible fix, rather than it just hiding something else)
Zoffix I don't follow actually: "Unless maybe there's a partial byte in the buffer" <-- partial byte? or partial grapheme? 16:06
And if partial grapheme, wouldn't it still be at most 1 grapheme per bytes we got? 16:08
jnthn oh, hah, right. Hmm. 16:11
16:12 robertle joined, hammer06511 joined, hammer06511 left, p6bannerbot sets mode: +v robertle
diakopter I thought you merged a fix to 2158 yesterday 16:14
PR 934
Zoffix diakopter: the fix fixed shortchange on read bytes, but now there's a SEGV 16:15
diakopter oh
16:20 xelak6 joined, p6bannerbot sets mode: +v xelak6 16:23 suim4 joined, p6bannerbot sets mode: +v suim4 16:24 suim4 left
xelak6 Zoffix: I have also done some debugging, and it seems that last grapheme of the previous input buffer is always inserted in the current result buffer. That means, the result buffer needs space for an additional grapheme when processing the last input buffer. 16:26
Zoffix xelak6: I'm giving up on this Issue :) Hope you can fix it. 16:28
Zoffix &
16:28 Zoffix left
xelak6 Zoffix: Increasing the result buffer by 1 should fix the problem anyway ... 16:31
16:32 tadzik joined 16:33 p6bannerbot sets mode: +v tadzik 16:36 nebuchad` joined, lizmat left 16:37 p6bannerbot sets mode: +v nebuchad`, dogbert17 joined 16:38 p6bannerbot sets mode: +v dogbert17 16:39 nebuchad` is now known as nebuchadnezzar 16:43 xelak6 left 16:46 brrt left
jnthn Argh, I've worked out what's going on 16:54
diakopter Argh 16:55
jnthn The `identity` function gets hot before various things using it
But we log return values and type tuples of parameters as part of the callee's spesh log entries 16:56
But once specialized it doesn't record them
So we end up with a few early unrepresentative values logged
Then identity gets specialized
Then we don't record any more return values
And thus end up with bogus stats, insert a guard that's rarely going to be met based on them, and deopt a load 16:57
dogbert17 is it an easy fix? 16:58
jnthn Not immediately sure
dogbert17 but spesh will be able to do a better job if the stats are correct then 16:59
Geth MoarVM: xelak6++ created pull request #936:
Increase the result buffer size.		 17:02
jnthn Yeah... Well, it's not a new problem, just made obvious when it killed performance of a benchmark I often run :) 17:05
Geth MoarVM: 4ec15fc568 | (Alexius Korzinek)++ | src/strings/utf8_c8.c
Increase the result buffer size.

The last grapheme of the previous input buffer is inserted in the current result buffer. Therefore, the result buffer needs space for an additional grapheme when processing the last input buffer.		 17:09
MoarVM: f700c13420 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/utf8_c8.c
Merge pull request #936 from xelak6/master

Increase the result buffer size.
MoarVM: 91d2878f17 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/utf8_c8.c
Document why we're bumping buffer by 1
 17:11
jnthn I guess we can log the returned type when the caller is being logged and stash it under the return bytecode offset or some such 17:15
But that can be a task for another day :)
Also I guess for things so simple as `identity` we don't want to go specializing them at all 17:17
There's nothing to even specialize
Time for some break/dinner :) bbl 17:20
17:54 zakharyas left 18:17 AlexDaniel left 19:27 linuxmodder14 joined 19:28 p6bannerbot sets mode: +v linuxmodder14, linuxmodder14 left 19:59 Guest88756 joined 20:00 p6bannerbot sets mode: +v Guest88756 20:02 kek918 joined 20:03 p6bannerbot sets mode: +v kek918, kek918 left 20:05 Guest88756 left 20:09 brrt joined, p6bannerbot sets mode: +v brrt
brrt \o 20:17
jnthn o/ brrt 20:22
20:24 depleted joined, p6bannerbot sets mode: +v depleted 20:27 lizmat joined, p6bannerbot sets mode: +v lizmat 20:29 depleted left 20:53 brrt left
masak brrtings 21:02
21:07 hexa-12 joined 21:08 p6bannerbot sets mode: +v hexa-12 21:11 hexa-12 left 21:41 Guest95232 joined, p6bannerbot sets mode: +v Guest95232, Guest95232 left 21:44 monoxane28 joined, monoxane28 left
jnthn Phew, only one more day of ridiculously hot before things get more sensible 22:16
22:19 Exagone31322 joined 22:20 Exagone31322 left
timotimo hooray! 22:24
jnthn: how do you feel about making a distinction in the UI between inclusive and exclusive allocations?
as in, in the current frontend you can only get the exclusive allocations for the exact methods that have 'em 22:25
but in the call graph explorer, there could be more information for that
jnthn inclusive meaning allocations of this + all its callers? 22:30
timotimo callees* 22:31
but yes
jnthn d'oh, yes :D
Big +1 to that :)
timotimo glad to see i'm not the only one who thinks that's worth a lot :)
jnthn Think I've a fix for caller type stats recording 22:32
It looks like it's doing the right thing, anyway :)
Was much easier to come up with here with fresh air blowing in the window than in the hot office earlier on today :) 22:33
timotimo \o/
jnthn haha
4 files changed, 17 insertions(+), 29 deletions(-) 22:34
It's actually *simpler* to do it this way
timotimo nice. is it what you alluded to before you went out for dinner?
jnthn Yeah
22:48 }ls{15 joined 22:49 p6bannerbot sets mode: +v }ls{15, }ls{15 left
Geth MoarVM: 51197804f8 | (Jonathan Worthington)++ | 4 files
Log return value types under the caller's log ID

This means that we still log them if returning from specialized to unspecialized code. Since it's an unspecialized caller that needs the information, this makes a lot more sense. There are situations where a callee called from many places is specialized before various of its callers are. In the worst case (which has been observed happening in ... (8 more lines)		 22:50
timotimo "resoliving" <3 22:51
22:52 robertle left
jnthn Darn it, I read that like 3 times :P 22:52
MasterDuke anyone mind if i merge github.com/MoarVM/MoarVM/pull/935 ? 22:54
jnthn #include "gcc_diag.h" 22:55
What's that gonna do on non-GCC?
timotimo it succeeds in the clang jobs on travis at least 22:56
jnthn What about MSVC?
MasterDuke yeah, src/6model/reprs.c also includes it
timotimo well, appveyor builds it fine 22:57
nqp also does its "make install", but not its "make test" for some reason? was that deactivated?
23:02 lizmat left
jnthn yawns 23:02
Will test out that commit on my real example tomorrow at the office :)
timotimo: Does appveyor use MSVC?
timotimo i believe so, yes 23:04
visual studio 2015
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64
compile: cl /nologo /MT /Ox /GL /DNDEBUG /DWIN32 /DAO_ASSUME_WINDOWS98
23:04 reportable6 left, yoleaux left
timotimo assume windows 98 m) 23:05
beautiful
23:05 reportable6 joined, p6bannerbot sets mode: +v reportable6, nativecallable6 left, benchable6 left 23:06 statisfiable6 left, bisectable6 left
MasterDuke 98se may be the first OS i ever purchased 23:06
23:06 shareable6 left 23:07 shareable6 joined
MasterDuke either that or a red hat 23:07
23:07 p6bannerbot sets mode: +v shareable6 23:09 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Log return value types under the caller's log ID 23:09
travis-ci.org/MoarVM/MoarVM/builds/413822384 github.com/MoarVM/MoarVM/compare/9...197804f823 23:10
23:10 travis-ci left 23:25 bluszcz26 joined, bluszcz26 left 23:49 Guest41007 joined
jnthn season-lab.github.io/papers/osr-dis...pldi18.pdf 23:49
23:49 p6bannerbot sets mode: +v Guest41007 23:50 Guest41007 left
timotimo jnthn: i'd like to expose the managed size of types in the profile, any objections? 23:52
jnthn No :)
timotimo gnite jnthn :) 23:58
jnthn timotimo: btw, I didn't read that paper yet by it may be applicable to profiling application/unapplication 23:59
(Read properly, at least :)
'night

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!