Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-28

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 travis-ci joined #moarvm
00:00 travis-ci MoarVM build failed. Elizabeth Mattijsen 'Remove dependency on autodie'
00:00 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/293879305 https://github.com/MoarVM/MoarVM/compare/213fc77426ba...00c3211c5c00
00:00 travis-ci left #moarvm
00:02 timotimo lizmat: getrusage is trivial to jit, as it's just a c function call
00:19 timotimo not exactly sure how to properly measure all this
00:26 Geth ¦ MoarVM: 89565bf51e | (Timo Paulssen)++ | src/jit/graph.c
00:26 Geth ¦ MoarVM: jit for getrusage
00:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/89565bf51e
00:28 timotimo lizmat: it does jit the full getrusage-total sub now
00:28 timotimo let me know how much this is worth :)
00:28 Zoffix \o/
00:35 timotimo it's a very small sub anyway
00:36 timotimo not sure if that means it's worth more or less :)
00:50 timotimo sadly the first argument for that method is still being ketp alive by deopt requirements
00:51 timotimo and the setting of $*DISPATCHER still happens - well, if the dispatcher it takes is non-null
00:55 timotimo i wonder if we should ever do logging and such for takedispatcher
00:55 timotimo logging and guarding
00:57 MasterDuke what is takedispatcher?
00:58 timotimo it takes the tc's currently active dispatcher and nulls it iirc
00:59 MasterDuke what's the point of that?
00:59 timotimo well, there's also a setdispatcher op
01:00 timotimo (and a setdispatcherfor op, too)
01:00 MasterDuke ah
01:00 timotimo i won't pretend i know how the dispatcher dance works :)
01:04 evalable6 joined #moarvm
01:12 committable6 joined #moarvm
01:56 ilbot3 joined #moarvm
01:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:13 travis-ci joined #moarvm
02:13 travis-ci MoarVM build passed. Timo Paulssen 'jit for getrusage'
02:13 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/293947445 https://github.com/MoarVM/MoarVM/compare/9ad1f5fc8664...89565bf51e43
02:13 travis-ci left #moarvm
04:14 evalable6 joined #moarvm
05:26 evalable6 joined #moarvm
07:42 Geth ¦ MoarVM: 0468d95a12 | (Samantha McVey)++ | src/6model/reprs/MVMIter.c
07:42 Geth ¦ MoarVM: Handle unsigned types to switch in MVM_iter()
07:42 Geth ¦ MoarVM:
07:42 Geth ¦ MoarVM: Fixes "Unknown lexical type encountered while building context iterator"
07:42 Geth ¦ MoarVM: error when MVM_iter() tries to handle unsigned integers.
07:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0468d95a12
07:42 Geth ¦ MoarVM: eb8acff6f3 | niner++ (committed using GitHub Web editor) | src/6model/reprs/MVMIter.c
07:42 Geth ¦ MoarVM: Merge pull request #733 from samcv/MVMIter
07:42 Geth ¦ MoarVM:
07:43 Geth ¦ MoarVM: Handle unsigned types to switch in MVM_iter()
07:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eb8acff6f3
08:37 evalable6 joined #moarvm
08:57 evalable6 joined #moarvm
09:28 Geth ¦ MoarVM: 8b53b1ebbd | (Nick Logan)++ | 3rdparty/libuv
09:28 Geth ¦ MoarVM: Bump libuv to ver. 1.15.0
09:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8b53b1ebbd
09:28 Geth ¦ MoarVM: 60e56edb93 | (Nick Logan)++ | src/io/fileops.c
09:28 Geth ¦ MoarVM: Use uv_fs_copyfile
09:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/60e56edb93
09:28 Geth ¦ MoarVM: cb785db9e0 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | 2 files
09:28 Geth ¦ MoarVM: Merge pull request #719 from ugexe/uv_fs_copyfile
09:28 Geth ¦ MoarVM:
09:28 Geth ¦ MoarVM: Use uv_fs_copyfile API
09:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cb785db9e0
09:29 Geth ¦ MoarVM: 66ba242887 | (Daniel Green)++ | src/6model/sc.c
09:29 Geth ¦ MoarVM: Convert realloc plus memset 0 to recalloc
09:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/66ba242887
09:29 Geth ¦ MoarVM: 7b7a8d14f8 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/6model/sc.c
09:29 Geth ¦ MoarVM: Merge pull request #712 from MasterDuke17/convert_realloc_plus_memset_0_to_recalloc
09:29 Geth ¦ MoarVM:
09:29 Geth ¦ MoarVM: Convert realloc plus memset 0 to recalloc
09:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7b7a8d14f8
09:29 travis-ci joined #moarvm
09:29 travis-ci MoarVM build canceled. Jimmy Zhuo 'Merge pull request #719 from ugexe/uv_fs_copyfile
09:29 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/294059317 https://github.com/MoarVM/MoarVM/compare/eb8acff6f33c...cb785db9e006
09:29 travis-ci left #moarvm
09:30 Geth ¦ MoarVM: 900178b52c | MasterDuke17++ | src/core/fixedsizealloc.c
09:30 Geth ¦ MoarVM: Support FSA_SIZE_DEBUG in MVM_fixed_size_realloc
09:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/900178b52c
09:30 Geth ¦ MoarVM: abea56319f | MasterDuke17++ | src/core/fixedsizealloc.c
09:30 Geth ¦ MoarVM: Also do FSA_SIZE_DEBUG for *realloc_at_safepoint
09:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/abea56319f
09:30 Geth ¦ MoarVM: 590dd2e303 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/core/fixedsizealloc.c
09:30 Geth ¦ MoarVM: Merge pull request #711 from MasterDuke17/support_FSA_SIZE_DEBUG_in_MVM_fixed_size_realloc
09:30 Geth ¦ MoarVM:
09:30 Geth ¦ MoarVM: Support FSA_SIZE_DEBUG in MVM_fixed_size_realloc*
09:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/590dd2e303
09:46 travis-ci joined #moarvm
09:46 travis-ci MoarVM build passed. Jimmy Zhuo 'Merge pull request #711 from MasterDuke17/support_FSA_SIZE_DEBUG_in_MVM_fixed_size_realloc
09:46 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/294059576 https://github.com/MoarVM/MoarVM/compare/7b7a8d14f893...590dd2e30382
09:46 travis-ci left #moarvm
09:52 AlexDaniel squashable6: next
09:52 squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 6 days and ≈0 hours (2017-11-04 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day
09:57 greppable6 joined #moarvm
10:33 patrickz joined #moarvm
11:21 lizmat hmmm... it looks like adding an nqp::getpid to the mainline of ThreadPoolScheduler, fixes GH #1202 for me
11:43 dogbert17 jnthn: the SEGV in lizmat's example seems to happen here, https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L2901
11:49 dogbert17 (gdb) p sc->body
11:49 dogbert17 $2 = (MVMSerializationContextBody *) 0x0
11:50 lizmat that's not a lot of body
11:52 dogbert17 very similar to yesterdays problem, https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L2746
11:54 jnthn Should probably audit all of the acquires
11:54 dogbert17 perhaps an MVMROOT around https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L2875 might do the trick ?
11:55 jnthn dogbert17: Yes
11:56 dogbert17 hmm, I might try to do a PR, perhaps adding one on 2813 as well
11:58 dogbert17 unless jnthn is already fixing them ofc :)
12:01 jnthn No, reviewing some cro stuff at the moment, and lunch is about to be ready :)
12:01 dogbert17 ok, I'll give it a shot then
12:02 samcv did i get pinged here?
12:03 samcv hm maybe i didn't and just saw wrong
12:03 dogbert17 hi samcv, shouldn't you be sleeping at this time?
12:03 samcv yes
12:05 samcv maybe it looked like i was mentioned in #perl6
12:10 dogbert17 does your computer have a high beep?
12:29 Geth ¦ MoarVM: dogbert17++ created pull request #739: Add two more missing MVMROOTs around managed mutex acquire
12:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/739
13:17 MasterDuke joined #moarvm
13:30 xi- joined #moarvm
13:43 Geth ¦ MoarVM: 82273161ce | (Stefan Seifert)++ | 6 files
13:43 Geth ¦ MoarVM: JIT compile native calls with up to 3 UTF-8 string arguments
13:43 Geth ¦ MoarVM:
13:43 Geth ¦ MoarVM: Strings are unboxed and the resulting pointers stored in the scratch space
13:43 Geth ¦ MoarVM: on the stack so both the actual C call and the MVM_free call afterwards can
13:43 Geth ¦ MoarVM: access them. The scratch space is 0x40=64 bytes large and we already need
13:43 Geth ¦ MoarVM: 8 bytes for the native function's return value, leaving us with space for
13:43 Geth ¦ MoarVM: 7 string pointers.
13:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/82273161ce
13:43 Geth ¦ MoarVM: 57f6315d77 | (Stefan Seifert)++ | src/core/nativecall.c
13:43 Geth ¦ MoarVM: Don't try to JIT compile native calls with rw arguments
13:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/57f6315d77
13:43 Geth ¦ MoarVM: 0edfd0c7ba | (Stefan Seifert)++ | 10 files
13:43 Geth ¦ MoarVM: JIT compile native calls with integer rw arguments
13:43 Geth ¦ MoarVM:
13:43 Geth ¦ MoarVM: Passing a pointer to an integer instead of the integer itself to the native
13:43 Geth ¦ MoarVM: function is easy. Getting the changed value back to the HLL code is the hard
13:43 Geth ¦ MoarVM: part. Since the native function writes to the register that's passed in the
13:43 Geth ¦ MoarVM: args buffer, the HLL code needs to read the value back from the args buffer.
13:43 Geth ¦ MoarVM: That's what the new getarg_* ops are for.
13:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0edfd0c7ba
13:48 nine These give me a 9.214/8.608 = 7 % speedup for csv-ip5xs-20
13:54 MasterDuke nice
13:54 Geth ¦ MoarVM: f66d7aa240 | (Jan-Olof Hendig)++ | src/6model/serialization.c
13:54 Geth ¦ MoarVM: Add two more missing MVMROOTs around managed mutex acquire
13:54 Geth ¦ MoarVM:
13:54 Geth ¦ MoarVM: The mutex acquire may GC block and thus trigger GC, moving objects.
13:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f66d7aa240
13:54 Geth ¦ MoarVM: 5a31123afe | niner++ (committed using GitHub Web editor) | src/6model/serialization.c
13:54 Geth ¦ MoarVM: Merge pull request #739 from dogbert17/add-missing-mvmroots
13:54 Geth ¦ MoarVM:
13:54 Geth ¦ MoarVM: Add two more missing MVMROOTs around managed mutex acquire
13:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5a31123afe
13:59 dogbert17 nine++
14:50 Geth ¦ MoarVM: 3a4321783d | (Stefan Seifert)++ | 3 files
14:50 Geth ¦ MoarVM: Treat NULL strings correctly in JIT compiled native subs
14:50 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3a4321783d
14:55 jnthn Left a commnet on dogbert17++'s PR; it's correct, but we need one more MVMROOT in one of those places
15:30 dogbert17 MVMROOT(tc, st, {   // jnthn, like this ?
15:30 dogbert17 MVMROOT(tc, sc, {
15:30 dogbert17 MVM_reentrantmutex_lock(tc, (MVMReentrantMutex *)sc->body->mutex);
15:30 dogbert17 });
15:30 dogbert17 });
15:30 jnthn yes
15:31 dogbert17 should I make a new PR considering the previous one has already been merged?
15:37 * dogbert17 spectesting
15:44 Geth ¦ MoarVM: dogbert17++ created pull request #740: Add another MVMROOT around managed mutex acquire. jnthn++
15:44 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/740
15:52 Geth ¦ MoarVM/master: 4 commits pushed by (Stefan Seifert)++
15:52 Geth ¦ MoarVM/master: 76f43ec08d | Mark nativeinvoke_* noinline to enable JIT compilation
15:52 Geth ¦ MoarVM/master: 932788fe00 | JIT compile param_rp_s
15:52 Geth ¦ MoarVM/master: f8c921734b | JIT compile trunc_i16
15:52 Geth ¦ MoarVM/master: 73c43fb830 | JIT compile getarg_* ops
15:52 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/3a4321783d...73c43fb830
15:52 nine jnthn: did I remember the reason correctly? https://github.com/MoarVM/MoarVM/commit/76f43ec08dcb9350f6a920435dd02f596b21ef22
15:53 evalable6 joined #moarvm
15:53 zakharyas joined #moarvm
15:56 jnthn nine: Yes, that's a sensible thing to do for the time being :)
15:57 zakharyas joined #moarvm
15:57 nine So the obvious next step is to fix spesh. Which sounds like the effort will consist of 80 % learning about spesh followed by the other 80 % of actually working on a fix
16:00 nine I'm actually a bit surprised that the :noinline version is faster. I'd have guessed that call overhead is much larger than the benefits of JIT compilation
16:00 jnthn Good news is that it'll be a LOT less nasty than it used to be
16:01 jnthn We used to not even include inlined things into the spesh graph in any "proper" way at all
16:01 jnthn I fixed all of that over the summer (TPF++)
16:01 zakharyas joined #moarvm
16:02 jnthn So getting inlinee facts in place, and propagating facts from the inliner to the inlinee, should work out nicely
16:02 jnthn Or at least, without all the pain it would have done if attempting it some months ago
16:02 jnthn If you want a warm-up task, another interesting job would be to try moving the inlined code to the point of the invocation it replaced
16:03 jnthn I think timotimo++ tried it and ran into some issues though
16:03 jnthn I don't recall any details
16:03 nine jnthn: may I infer from that that the code is currently appended and the call replaced by a jump?
16:03 jnthn But figuring that out would probably be a good education in inlining, and also have a useful result along the way
16:03 jnthn Yeah, we append the inlines at the end
16:04 jnthn Which was easy
16:04 jnthn I *think* deopt doesn't depend on that in any way, though
16:06 timotimo i don't remember why exactly things broke either
16:06 Geth ¦ MoarVM: 9ee680f052 | (Jan-Olof Hendig)++ | src/6model/serialization.c
16:06 Geth ¦ MoarVM: Add another MVMROOT around managed mutex acquire. jnthn++
16:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ee680f052
16:06 Geth ¦ MoarVM: ad2d6fb0dd | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/serialization.c
16:06 Geth ¦ MoarVM: Merge pull request #740 from dogbert17/add-another-missing-mvmroot
16:06 Geth ¦ MoarVM:
16:06 Geth ¦ MoarVM: Add another MVMROOT around managed mutex acquire. jnthn++
16:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ad2d6fb0dd
16:06 timotimo i don't think i pushed my branch that tried to put inlines in the place it's called
16:07 Geth ¦ MoarVM/inline_in_place: 94aa824a67 | (Timo Paulssen)++ | 2 files
16:07 Geth ¦ MoarVM/inline_in_place: WIP on putting inlined blocks between their caller and its succ
16:07 Geth ¦ MoarVM/inline_in_place:
16:07 Geth ¦ MoarVM/inline_in_place: currently prevents more than one inline from happening per graph,
16:07 Geth ¦ MoarVM/inline_in_place: and also seems to create wrong code in some way.
16:07 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/94aa824a67
16:07 timotimo there it is
16:07 jnthn Well, with most things spesh, it's mostly a case of being stubborn enough to figure out why the odd bustage :)
16:08 timotimo it's true
16:08 lizmat jnthn nine ok to bump Moar ?
16:08 timotimo this branch was before the graph properly got re-ssa'd after an inline
16:08 nine lizmat: sure
16:08 lizmat ok, will do in a mo
16:09 zakharyas joined #moarvm
16:09 Geth ¦ MoarVM: ugexe++ created pull request #741: Add MVMROOT around more reentrantmutex acquires
16:09 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/741
16:10 ugexe nine: MVMCompUnit object does not need to be MVMROOTd right?
16:11 ugexe oh maybe it does
16:11 nine ugexe: I don't know of any exceptions. It's all just objects to the GC
16:12 Geth ¦ MoarVM/inline_in_place: 37fbba5578 | (Timo Paulssen)++ (committed by Stefan Seifert) | 2 files
16:12 Geth ¦ MoarVM/inline_in_place: WIP on putting inlined blocks between their caller and its succ
16:12 Geth ¦ MoarVM/inline_in_place:
16:12 Geth ¦ MoarVM/inline_in_place: currently prevents more than one inline from happening per graph,
16:12 Geth ¦ MoarVM/inline_in_place: and also seems to create wrong code in some way.
16:12 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/37fbba5578
16:12 * lizmat holds off bumping Moar for a bit
16:12 nine timotimo: rebased on master ^^^
16:12 ugexe i read a comment saying that it didn't "move"
16:12 ugexe and 20ish lines under that it MVMROOTs a MVMCompUnit :)
16:30 zakharyas joined #moarvm
16:50 nine timotimo: why is it preventing more than one inline per graph?
16:51 timotimo i think it's because it doesn't know where one starts and the next ends
16:51 timotimo i.e. on the first step you're guaranteed that the first bb with "is_inlined" is what you're working on
16:51 nine timotimo: looks like it breaks on nested inlines
16:51 timotimo could very well be
16:52 MasterDuke while a bunch of jitting commits are going in, anyone have a comment on https://github.com/MoarVM/MoarVM/pull/729?
16:52 nine Seems odd that annotate_inline_start_end is happending after the merging. Wouldn't this be trivial to do before actually inlining?
16:53 lizmat MasterDuke: that's above my pay scale, hope that jnthn timotimo nine can vet that
16:54 Zoffix FWIW, there's also https://github.com/MoarVM/MoarVM/pull/734 awaiting a merge
16:54 nine Looks sane to me, but have to leave for dinner now
16:54 lizmat MasterDuke: what was wrong with #730 ?
16:55 domidumont joined #moarvm
16:55 MasterDuke lizmat: OBE, nine just did the same thing a couple commits ago
16:55 lizmat ah, ok  :-)
17:01 Geth ¦ MoarVM: ugexe++ created pull request #742: Add more missing MVMROOTs
17:01 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/742
17:02 domidumont joined #moarvm
17:03 timotimo MasterDuke: you put "used to cause n bails" in the PR, but it'd be more interesting to see how many of the frames that used to bail still bail because of some other op
17:04 MasterDuke timotimo: you know, i'd meant to calculate that and then got distracted
17:04 timotimo i can imagine :)
17:05 timotimo i tend to grep bail, sort | uniq -c | sort -rn
17:05 timotimo and then diff the results
17:05 MasterDuke almost exactly what i do
17:05 timotimo OK
17:06 MasterDuke i think i have a couple minutes now, let me give it a go...
17:10 xi- joined #moarvm
17:12 MasterDuke i do `sort | uniq -c | sort -rn` so many times, i really should have an alias or function or something for it
17:16 timotimo yeah, me too
17:41 Geth ¦ MoarVM: 5e8be59d32 | MasterDuke17++ | 4 files
17:41 Geth ¦ MoarVM: JIT the getexcategory op
17:41 Geth ¦ MoarVM:
17:41 Geth ¦ MoarVM: Create an MVM_get_exception_category function and call that in interp.c
17:41 Geth ¦ MoarVM: and graph.c.
17:41 Geth ¦ MoarVM:
17:41 Geth ¦ MoarVM: Used to cause 15 BAILs when building the Rakudo core setting.
17:41 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5e8be59d32
17:41 Geth ¦ MoarVM: e9067c7bdb | niner++ (committed using GitHub Web editor) | 4 files
17:41 Geth ¦ MoarVM: Merge pull request #729 from MasterDuke17/jit_getexcategory
17:41 Geth ¦ MoarVM:
17:41 Geth ¦ MoarVM: JIT the getexcategory op
17:41 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e9067c7bdb
17:44 ugexe 742 didn't stop 1202 either
19:08 ugexe should we be using fctnl + F_FULLFSYNC on OSX in place of fsync? sqlite and libuv do this fwiw. http://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know-about-fsync/
19:37 ggoebel joined #moarvm
19:44 colomon joined #moarvm
20:19 MasterDuke timotimo: ok, finally got a minute. jitting getexcategory removed the 15 bails it caused, but total only went down by 12
20:21 timotimo that's quite good
20:21 timotimo i'll go rest a little
21:56 samcv good *
22:10 jnthn o/ samcv
22:10 samcv hey jnthn so what do i need to learn about Buf
22:10 samcv and how it's handled as an object on the MVM side
22:11 samcv since i only know the code that's in rakudo
22:11 samcv how do we store bufs in mvm and what things do we need added for working with Buf's
22:11 jnthn It's just a VMArray underneath
22:12 jnthn The "magic" that makes that happen is the "is repr('VMArray')" in Rakudo
22:12 samcv so it's a uint based vmarray?
22:12 jnthn Yup
22:12 jnthn That said
22:12 jnthn I've been pondering making Blob uses MultiDimArray
22:12 jnthn Not for multiple dimensions, but for the fixed size
22:13 samcv hm
22:13 samcv Blob is fixed and Buf is unfixed?
22:13 jnthn Because if our I/O layers spit *those* out then we can shove 'em into Decoder and it won't have to do a defensive copy
22:13 jnthn Blob is immutable, Buf is mutable (in both content and size)
22:13 jnthn So Buf needs to be a growing thing underneath
22:13 jnthn Blob needn't
22:14 jnthn And would likely be better for us if it didn't
22:14 jnthn At the moment Decoder always does a defensive copy of the contents of the Blobs it is given
22:14 jnthn Since it can't know they won't mutate
22:14 samcv yeah
22:15 jnthn Which is a bit wasteful
22:15 jnthn Would probably help us catch up a bit with Perl 5 in the non-Unicode line-reading benchmarks :)
22:16 jnthn (We already win the Unicode one)
22:16 jnthn Well, utf-8 specifically
22:16 samcv decodng as ascii or what?
22:16 samcv as binary?
22:17 timotimo no, decoding real utf8
22:17 timotimo oh, i might misunderstand
22:17 jnthn samcv: The for $fh.lines { } thing
22:17 samcv ok so where in our code is this?
22:18 samcv so i can start reading
22:18 jnthn Which "it"? :)
22:19 timotimo he's called pennywise, jnthn
22:19 jnthn For the Blob/Buf stuff in Rakudo, src/core/Buf.pm
22:20 jnthn For VMArray/MultiDimArray, src/6model/reprs/VMArray.c and src/6model/reprs/MultiDimArray.c
22:20 jnthn For Decoder stuff, src/6model/reprs/Decoder.c (API to the outside world) and src/strings/decode_stream.c (impl)
22:20 samcv thanks :)
22:21 jnthn And the decoder impls are under src/strings/
22:54 bisectable6 joined #moarvm
23:21 samcv jnthn, is this accurate? https://github.com/rakudo/rakudo/issues/1209#issuecomment-340226255
23:21 samcv replied to this
23:26 jnthn samcv: Just about to sleep, will check tomorrow
23:26 samcv ok
23:26 samcv night
23:27 jnthn (Needs more thinking than I have brane left for)
23:27 jnthn 'night o/
23:29 timotimo https://github.com/jnthn/p6-app-moarvm-heapanalyzer/blob/master/lib/App/MoarVM/HeapAnalyzer/Model.pm6#L348-L409 - this is a thing i made and use

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary