Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-10-28

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:57 Zoffix nqp: sub meow() { 42 }; role Foo { has %!quote_lang_cache; method x($x) { my $z := nqp::existskey(%!quote_lang_cache, 'x') ?? %!quote_lang_cache{$x} !! (%!quote_lang_cache{$x} := meow()) } }; class Bar does Foo {}; Bar.new.x: 42
00:57 camelia nqp-moarvm: OUTPUT: «Cannot invoke this object (REPR: Null; VMNull)␤   at <tmp>:1  (<ephemeral file>:x)␤ from <tmp>:1  (<ephemeral file>:<mainline>)␤ from gen/moar/stage2/NQPHLL.nqp:1542  (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:eval)␤ from gen/moar/stage2/…»
00:58 Zoffix nqp: sub meow() { 42 }; class Foo { has %!quote_lang_cache; method x($x) { my $z := nqp::existskey(%!quote_lang_cache, 'x') ?? %!quote_lang_cache{$x} !! (%!quote_lang_cache{$x} := meow()) } }; Foo.new.x: 42
00:58 camelia nqp-moarvm: ( no output )
00:58 Zoffix Weird that it crashes in a role but not class
00:58 Zoffix Also weird: it crashes with a different error in rakudo's sauce when similar setup is in role; says stuff about %!quote_lang_cache being null
01:01 Zoffix "This representation (Null) does not support associative access (for type VMNull)"
01:04 evalable6 joined #perl6-dev
01:07 MasterDuke annoying, i can't --profile-compile 2017.10. i'm trying on my gce vm with 26gb ram, but i think it's still running out of memory
01:12 committable6 joined #perl6-dev
01:57 ilbot3 joined #perl6-dev
01:57 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:20 Zoffix Weird... This fixes the quote braid cache bug: https://gist.github.com/zoffixznet/99f6c630bdfb95903575dc12882d78c8 but this doesn't: https://gist.github.com/zoffixznet/2dde6f364b4f0814a7fc2c150bff9088  I thought the two version would be equivalent
02:25 Zoffix Oh, it's all crap. It never caches and nothing's fixed -_-
02:25 Zoffix 'cause return value ain't null
03:02 Zoffix heh... it either caches too eagerly or doesn't cache at all
03:02 Zoffix buggable: zen can has middle ground?
03:02 buggable Zoffix, “The only thing that is ultimately real about your journey is the step that you are taking at this moment. That's all there ever is.”
03:03 Zoffix Neat.
04:08 Zoffix ZOFFLOP: t/spec/S11-modules/nested.t
04:08 Zoffix ZOFVM: Files=1283, Tests=152770, 146 wallclock secs (19.90 usr  3.31 sys + 3122.17 cusr 152.68 csys = 3298.06 CPU)
04:14 evalable6 joined #perl6-dev
04:15 Geth ¦ rakudo: ad16c6fb86 | (Zoffix Znet)++ | src/Perl6/Grammar.nqp
04:15 Geth ¦ rakudo: Fix quote lang cache regression
04:15 Geth ¦ rakudo:
04:15 Geth ¦ rakudo: Fixes RT#132262: https://rt.perl.org/Ticket/Display.html?id=132262
04:15 Geth ¦ rakudo:
04:15 Geth ¦ rakudo: After the Big Slang Refactor, the quote lang cache started to fail
04:15 Geth ¦ rakudo: to notice when the cached lang was mutated (e.g. by defining
04:15 Geth ¦ rakudo: a new prefix op). This caused failure to parse new ops, such
04:15 Geth ¦ rakudo: as behaviour in the ticket, since the new quoted block still used the
04:16 synopsebot RT#132262 [open]: https://rt.perl.org/Ticket/Display.html?id=132262 [REGRESSION] Quote braid misses Main braid's language change due to new ops
04:16 Geth ¦ rakudo: old pre-op-mixin lang.
04:16 Geth ¦ rakudo:
04:16 Geth ¦ rakudo: Fix by adding the name of the lang object to key the cache on.
04:16 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/ad16c6fb86
04:16 Geth ¦ roast: 730b5c8239 | (Zoffix Znet)++ | S13-overloading/operators.t
04:16 Geth ¦ roast: Test quote lang cache does not break our ops
04:16 Geth ¦ roast:
04:16 Geth ¦ roast: RT#132262: https://rt.perl.org/Ticket/Display.html?id=132262
04:16 Geth ¦ roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/ad16c6fb86
04:16 Geth ¦ roast: review: https://github.com/perl6/roast/commit/730b5c8239
04:19 Zoffix heh my ./close-rt got broken by nom rename :)
04:20 Zoffix A 2-second fix, but I'm going to have to speak to your manager about it!! :)
04:23 Geth ¦ nqp: e5849c41ec | (Zoffix Znet)++ | tools/build/MOAR_REVISION
04:23 Geth ¦ nqp: Bump MoarVM
04:23 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/e5849c41ec
04:23 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.10-3-g9ad1f5f...2017.10-4-g89565bf
04:23 Geth ¦ rakudo: 9dba8e5bc3 | (Zoffix Znet)++ | tools/build/NQP_REVISION
04:23 Geth ¦ rakudo: Bump NQP
04:23 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/9dba8e5bc3
05:26 evalable6 joined #perl6-dev
06:43 AlexDaniel greppable6: moar-nom
06:43 greppable6 AlexDaniel, https://gist.github.com/7b0b64bea6e04d20045220907565f149
06:44 AlexDaniel oooooops
06:50 AlexDaniel ok, all these have a PR to replace nom with master
06:50 AlexDaniel (except when it's in a comment, so who cares)
07:52 Geth ¦ star: hankache++ created pull request #105: Update perl6intro.pdf
07:52 Geth ¦ star: review: https://github.com/rakudo/star/pull/105
07:59 Geth ¦ star: ffe583683e | (Naoum Hankache)++ | docs/perl6intro.pdf
07:59 Geth ¦ star: Update perl6intro.pdf
07:59 Geth ¦ star: review: https://github.com/rakudo/star/commit/ffe583683e
07:59 Geth ¦ star: b14f160438 | (Steve Mynott)++ (committed using GitHub Web editor) | docs/perl6intro.pdf
07:59 Geth ¦ star: Merge pull request #105 from hankache/master
07:59 Geth ¦ star:
07:59 Geth ¦ star: Update perl6intro.pdf
07:59 Geth ¦ star: review: https://github.com/rakudo/star/commit/b14f160438
08:37 evalable6 joined #perl6-dev
08:57 evalable6 joined #perl6-dev
09:20 lizmat Files=1229, Tests=75775, 321 wallclock secs (14.81 usr  5.23 sys + 2198.02 cusr 213.28 csys = 2431.34 CPU)
09:35 lizmat and there I thought :ignoremark was a thing
09:36 lizmat https://stackoverflow.com/questions/46987156/can-i-modify-a-literal-regex-in-perl-6
09:43 moritz it is, though maybe not what OP wants
09:48 lizmat docs.perl6.org appears to be oblivious to ignoremark
09:49 Geth ¦ nqp: 8f18b6a281 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
09:49 Geth ¦ nqp: Bump Moar for the latest goodies
09:49 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/8f18b6a281
09:49 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.10-4-g89565bf...2017.10-14-g590dd2e
09:49 moritz lizmat: indeed
09:49 moritz lizmat: I'll open an issue for that
09:50 moritz https://github.com/perl6/doc/issues/1133 AlexDaniel++ was faster
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 #perl6-dev
10:00 dogbert17 lizmat: do you still have trouble with the CAS tests?
10:01 lizmat $ time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 16'; do :; done
10:01 lizmat Segmentation fault: 11
10:01 lizmat real0m4.120s
10:01 lizmat dogbert17: so that would be a yes, I'm afraid
10:03 * dogbert17 tries the example ...
10:04 * dogbert17 runs a spectest at the same time
10:05 lizmat it fixed it for jnthn on linux, but apparently MacOS is different :-(
10:05 dogbert17 could be, is also on Linux
10:06 dogbert17 but the other example, 1202 something, still hangs for me while under load
10:06 lizmat I've only got it to hang once, and created a dump of it, which I gisted
10:07 lizmat https://gist.github.com/lizmat/d22cfb0c67f9866df3f5fe3b7187c15e
10:07 dogbert17 now the first example crashed
10:07 lizmat I also have the vague idea that the crashes seem to coincide with filesystem activity
10:08 Geth ¦ rakudo: 6a6cea3856 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
10:08 Geth ¦ rakudo: Bump NQP for the latest MoarVM goodies
10:08 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/6a6cea3856
10:10 lizmat .tell timotimo jitting getrusage saved 70 msecs off a 500000 iteration, so in practice 7 msecs on a program running 500 seconds
10:10 yoleaux lizmat: I'll pass your message to timotimo.
10:11 dogbert17 all I can add at them moment wrt to 1202, is that if I run the code with RAKUDO_SCHEDULER_DEBUG=1 it always hang after writing out '[SCHEDULER] Created initial affinity worker thread' but before writing '[SCHEDULER] Added a general worker thread'
10:12 lizmat aaahhhh, that gives me an idea:
10:12 lizmat https://github.com/rakudo/rakudo/blob/master/src/core/ThreadPoolScheduler.pm#L549
10:13 lizmat it's pushing to the general queue, but that may not exist yet at that time ?
10:15 dogbert17 but then I should see this text 'Stealing queue from affinity worker' or ?
10:15 lizmat ah, yes
10:16 lizmat but still, we need to make sure we have a general queue at that time
10:16 lizmat :w
10:16 lizmat oops
10:20 * dogbert17 tries running the cas example under asan
10:22 stmuk_ https://github.com/stmuk/rakudo-packages
10:30 Geth ¦ rakudo: a7972a0ce4 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
10:30 Geth ¦ rakudo: Make sure we have a general queue when stealing
10:30 Geth ¦ rakudo:
10:30 Geth ¦ rakudo: - although unlikely, it is possible to have no general queue at that point
10:30 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a7972a0ce4
10:33 patrickz joined #perl6-dev
10:38 Zoffix 2017.03:  46.66user 0.19system 0:46.85elapsed 100%CPU (0avgtext+0avgdata 181832maxresident)k
10:38 yoleaux 09:57Z <AlexDaniel> Zoffix: squashathon poster plz? :)
10:38 Zoffix HEAD:     62.83user 0.40system 1:02.80elapsed 100%CPU (0avgtext+0avgdata 220256maxresident)k
10:38 Zoffix Results for running this program: https://gist.github.com/zoffixznet/e83afe96a469092cc41ce05dca0dff73
10:39 AlexDaniel so it's much slower now? Let's see when this happened?
10:39 Zoffix The slang refactor happened.
10:40 Zoffix And you won't see much, consdering since about 2017.03 that program was broken until last night
10:40 AlexDaniel :(
10:41 Zoffix or I think it was...
10:42 Zoffix (expected it to crash instantly but it didn't)
10:43 Zoffix Ah right, it's not actually using the ops for it to crash; but still it's not caching the quote lang properly
10:44 Zoffix star: $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }";
10:44 camelia star-m 2017.07: OUTPUT: «5===SORRY!5=== Error while compiling <tmp>␤Negation metaoperator not followed by valid infix␤at <tmp>:1␤------> 3sub postfix:<!> { [*] ^$^f+1}; say "{ 5!7⏏5 }";␤    expecting any of:␤        infix␤        infix stopper␤»
10:44 Zoffix c: 2017.03 $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }";
10:44 committable6 Zoffix, https://gist.github.com/fa24260474685f9e68a879c0aa5a1aeb
10:44 Zoffix c: 2017.01 $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }";
10:44 committable6 Zoffix, ¦2017.01: «120»
10:44 * Zoffix builds 2017.01 to see the measurements there
10:51 stmuk_ samcv: which versions of rakudo and star are available in your flatpak builds? It's unclear to me looking at the filenames at https://github.com/samcv/rakudo-appimage-module-test-automation/tree/gh-pages
10:53 Zoffix 48.66user 0.08system 0:48.77elapsed 99%CPU (0avgtext+0avgdata 176344maxresident)k
10:54 Zoffix for 2017.01
10:55 Zoffix 2017.09: 63.84user 0.31system 1:03.86elapsed 100%CPU (0avgtext+0avgdata 218200maxresident)k
10:56 Zoffix OK. I'm content now. I thought it was last night's fix that made it use so much more RAM, but I guess it's somethign else.
11:04 stmuk_ Does anyone know of anything which should be added to https://github.com/stmuk/rakudo-packages?
11:09 Zoffix AlexDaniel: https://github.com/perl6/marketing/tree/master/TablePosters/SQUASHathon/2017.11
11:11 AlexDaniel Zoffix: awesome. Tweet?
11:15 Zoffix https://twitter.com/zoffix/status/924232852551716864
11:15 AlexDaniel Zoffix: thx ♥
11:18 AlexDaniel squashable6: next
11:18 squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 5 days and ≈22 hours (2017-11-04 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day
11:18 AlexDaniel 7 days? :o
11:19 Zoffix whatevs... it's 7 days in my timezone
11:22 lizmat hmmm... it looks like adding an nqp::getpid to the mainline of ThreadPoolScheduler, fixes GH #1202 for me  # dogbert17
11:23 dogbert17 that's interesting, how long have you been running?
11:23 lizmat about 5 minutes now
11:25 dogbert17 didn't it use to crash more or less immediatly for you?
11:27 dogbert17 jnthn's fix from yesterday has made a large difference on my system
11:31 dogbert17 hmm, no numbers from |Tux| today ?
11:31 lizmat I guess [Tux] is relaxing
11:32 lizmat dogbert17: still running
11:32 lizmat closing in on 15 minutes
11:33 dogbert17 any ideas as to why your fix works?
11:33 lizmat the only thing I can think of is some code that depends on the pid being stored somewhere, but not being there,
11:33 lizmat and / or a race condition in getting it
11:34 lizmat that is prevented by doing it from the start
11:34 lizmat when there are no threads running yet
11:35 lizmat MoarVM panic: Heap corruption detected: pointer 0x10ff31780 to past fromspace    # real 16m48.435s   *sigh*
11:35 dogbert17 :(
11:35 lizmat running another one
11:38 Geth ¦ rakudo: a1866b7b33 | (Elizabeth Mattijsen)++ | 2 files
11:38 Geth ¦ rakudo: Always set up $*PID
11:38 Geth ¦ rakudo:
11:38 Geth ¦ rakudo: - needed it earlier for debugging message
11:38 Geth ¦ rakudo: - seems to have a stabilizing effect wrt GH #1202, at least on MacOS
11:38 Geth ¦ rakudo: - registering the cheap dynamic was probably relatively expensive anyway
11:38 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a1866b7b33
11:38 synopsebot RAKUDO#1202 [open]: https://github.com/rakudo/rakudo/issues/1202 [severe] Async qqx sometimes hangs or dies ( await (^5).map({start { say qqx{… …} } }) )
11:38 dogbert17 also got it to segv. Trying with gdb now ...
11:39 * dogbert17 while running a stresstest with six jobs plus some downloads
11:39 dogbert17 hah
11:39 dogbert17 Program received signal SIGSEGV, Segmentation fault.
11:39 dogbert17 [Switching to Thread 0xb47ffb40 (LWP 4282)]
11:40 dogbert17 0xb7c36892 in MVM_serialization_finish_deserialize_method_cache (tc=tc@entry=0xa0e6d88, st=st@entry=0x8c5dfb8) at src/6model/serialization.c:2901
11:40 dogbert17 probably another missing MVM_ROOT since it seems to be dealing with a mutex again
11:42 dogbert17 https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L2901
12:06 Geth ¦ rakudo: 260e4a3a27 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
12:06 Geth ¦ rakudo: Only call debug status sub if debug status set
12:06 Geth ¦ rakudo:
12:06 Geth ¦ rakudo: - this is the only place so far where debug status is called
12:06 Geth ¦ rakudo: - it's inside the hot loop, so makes sense to not always take the call overhead
12:06 Geth ¦ rakudo: - makes the supervisor idle overhead drop from 37 to 33 msec / second
12:06 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/260e4a3a27
12:08 timotimo lizmat: wow, that's barely anything at all saved :(
12:08 yoleaux 10:10Z <lizmat> timotimo: jitting getrusage saved 70 msecs off a 500000 iteration, so in practice 7 msecs on a program running 500 seconds
12:09 lizmat yeah, but still, all little things help
12:09 timotimo mhm
12:09 jnthn tbh, the cost of getrusage is probably dominated by what getrusage does :)
12:09 lizmat and the orange was distracting in the --profile output  :-)
12:09 timotimo :)
12:10 timotimo jnthn: a chance you could also review the "cstructarray" pull request in the coming week?
12:11 jnthn timotimo: Yes; please prod me on Tuesday if I didn't already get to it by then
12:12 timotimo OK!
13:17 MasterDuke joined #perl6-dev
13:17 [Tux] Tux was walking on the "Hulshorsterzand". Timing is running now
13:26 buggable New CPAN upload: RPi-ButtonWatcher-0.0.1.tar.gz by PATRICKZ https://cpan.metacpan.org/authors/id/P/PA/PATRICKZ/Perl6/RPi-ButtonWatcher-0.0.1.tar.gz
13:26 MasterDuke timotimo: did you get around to adding the mention of how typing the string to interpolate to a regex is faster to that SO post?
13:27 timotimo oh, i did not
13:27 timotimo does it also work with array of string?
13:28 MasterDuke nope
13:29 MasterDuke i think i made that a tiny bit faster with my INTERPOLATE refactor, but nowhere near the same amount
13:30 timotimo mhm :S
13:30 xi- joined #perl6-dev
13:35 [Tux] Rakudo version 2017.10-4-g4fca94743 - MoarVM version 2017.10-1-g213fc774
13:35 [Tux] csv-test-xs-20      0.472 -  0.500
13:35 [Tux] csv-ip5xs           1.159 -  1.284
13:35 [Tux] test-t              3.129 -  3.188
13:35 [Tux] test               11.464 - 11.884
13:35 [Tux] csv-parser         12.150 - 12.342
13:35 [Tux] csv-ip5xs-20       14.476 - 15.130
13:36 [Tux] test-t-20 --race   20.393 - 20.875
13:36 [Tux] test-t-20          56.537 - 57.055
13:36 timotimo the ones with 20 are like 20x as many lines?
13:37 lizmat yes
13:37 lizmat although we seem to have lost a second on t-20 --race since the last time  :-(((
13:37 lizmat but won 2 seconds on the t-20 without race
13:37 lizmat hmmm... not sure what to make of that
13:43 lizmat m: ^100 .race>>.say   # weird
13:43 camelia rakudo-moar 4fca94743: OUTPUT: «5===SORRY!5=== Error while compiling <tmp>␤Missing << or >>␤at <tmp>:1␤------> 3^100 .race>>.7⏏5say   # weird␤»
13:43 lizmat m: (^100).race>>.say   # works ok
13:43 camelia rakudo-moar 4fca94743: OUTPUT: «0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤11␤12␤13␤14␤15␤16␤17␤18␤19␤20␤21␤22␤23␤24␤25␤26␤27␤28␤29␤30␤31␤32␤33␤34␤35␤36␤37␤38␤39␤40␤41␤42␤43␤44␤45␤46␤47␤48␤49␤50␤51␤5…»
13:45 lizmat jnthn: could it be that the additional MVM_ROOTs have a rather large negative effect on racing performance ?
13:50 Geth ¦ nqp: 225fdfce33 | (Stefan Seifert)++ | 2 files
13:50 Geth ¦ nqp: Map the new getarg_i op for reading from the args buffer
13:50 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/225fdfce33
13:54 Geth ¦ rakudo: 3bd756f549 | (Stefan Seifert)++ | 2 files
13:55 Geth ¦ rakudo: Support rw integer arguments of JIT compiled native subs
13:55 Geth ¦ rakudo:
13:55 Geth ¦ rakudo: After the call to the native function, we need to read back the changed
13:55 Geth ¦ rakudo: values from the args buffer. We can't use the param_* ops there because
13:55 Geth ¦ rakudo: we don't set up a call frame for the native call. Thus the param_* ops
13:55 Geth ¦ rakudo: would read the HLL sub's arguments instead of the native function's.
13:55 Geth ¦ rakudo: We use the new getarg_i op instead to get the changed value and assign
13:55 Geth ¦ rakudo: it to the lexicalref for the rw parameter.
13:55 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3bd756f549
14:00 dogbert17 lizmat: the MVMROOT fix has been merged, hopefully it fixes the segv's (famous last words)
14:27 Geth ¦ nqp: 9fc2e1f1f3 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
14:27 Geth ¦ nqp: Bump Moar to get additional mutex MVMROOTs
14:27 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/9fc2e1f1f3
14:27 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.10-17-g0edfd0c7b...2017.10-19-g5a31123
14:38 lizmat dogbert17: alas, still crashing, but feels that it is crashing less often
14:38 lizmat time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 4'; do :; done   # 27 seconds just now
14:39 lizmat 22 seconds
14:39 lizmat and then a bunch below 3 seconds  :-(
14:41 dogbert17 hmm, so the search continues
14:41 lizmat yeah...
14:42 lizmat I've once found a bug in a program that had been used in production for 6 years all over the world with 1000s of users
14:43 dogbert17 I'll start running it again and see if it comes crashing down
14:43 lizmat it was basically an off-by-one if a certain buffer was *almost* full
14:43 dogbert17 cool
14:43 lizmat argh
14:43 * lizmat is stupid
14:43 lizmat I haven't bumped rakudo locally yet
14:43 dogbert17 :)
14:45 dogbert17 so there's still a chance
14:45 lizmat yup
14:47 lizmat running spectest and code now
14:48 lizmat so far so good
14:50 Geth ¦ rakudo: 0a029db60c | (Stefan Seifert)++ | lib/NativeCall.pm6
14:50 Geth ¦ rakudo: Treat undefined strings correctly in JIT compiled native subs
14:50 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/0a029db60c
14:51 lizmat dogbert17: still looking good
14:55 lizmat time while perl6 --ll-exception -e 'await (^16).map({start { qqx{echo -n foo $_} } })'; do :; done  # heap corruption after 5 minutes
14:55 lizmat the cas one still going strong
14:56 lizmat dogbert17: looks like jnthn found another one
14:57 nine Wow, with my local patches to Inline::Perl5 csv-ip5xs.pl is only 25x slower than csv-test-xs.pl (the Perl 5 version)
15:07 lizmat dogbert17: cas one still running, the GH #1202 one as well
15:07 lizmat so that's 20 minutes for the cas one
15:08 dogbert17 lizmat, that's promising
15:09 Geth ¦ rakudo: d05e61df95 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
15:09 Geth ¦ rakudo: Bump NQP to get latest Moar gc fixes.
15:09 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/d05e61df95
15:15 lizmat GH 1202 one crashed after almost 20 mins, cas one still going strong
15:15 lizmat dogbert17: I'd say this was a definite improvement!
15:16 buggable New CPAN upload: RPi-Device-ST7036-0.0.3.tar.gz by PATRICKZ https://cpan.metacpan.org/authors/id/P/PA/PATRICKZ/Perl6/RPi-Device-ST7036-0.0.3.tar.gz
15:17 lizmat buggable: that link is not really useful this way  :-(
15:19 dogbert17 perhaps the one jnthn found will seal the deal
15:23 * lizmat hopes so
15:32 BenGoldberg joined #perl6-dev
15:38 lizmat jnthn Zoffix nine timotimo: would you have anything against making $*PID writable ?
15:39 lizmat this is re: https://github.com/rakudo/rakudo/commit/a1866b7b3339099c06ffb7ee28e721d16558f0a1#commitcomment-25253686
15:43 jnthn Uh...writable?
15:44 nine lizmat: appears to me that it should just always return what nqp::getpid gives
15:44 jnthn You can't change our PID, so that sounds odd
15:44 jnthn *your
15:44 jnthn oh, it's a fork question
15:44 lizmat yup
15:44 jnthn fork *will* end in tears anyway
15:44 lizmat well, yes, so I wanted to not facilitate it too much by creating a Proxy that would do a nqp::getpid
15:45 jnthn Yeah, it's a bit odd to go to the effort of providing it when fork is something we can't really support
15:45 lizmat indeed
15:45 lizmat also, maybe we should add a fork() that throws an X::ThatIsNotAGoodIdea eror
15:45 lizmat error
15:46 jnthn I don't think so
15:46 jnthn Because anyone nativecalling it would just hide that anyway
15:46 jnthn And the docs already discuss the situation
15:47 lizmat ok, will leave it as is then
15:47 b2gills I was just unsure if there was any other way that the PID could change out from under running code.
15:48 lizmat b2gills: you will have to do a PROCESS::<$PID> = nqp::getpid in the child process
15:48 lizmat actually bind it: PROCESS::<$PID> := nqp::getpid
15:53 evalable6 joined #perl6-dev
15:54 lizmat time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 4'; do :; done
15:54 lizmat has now run over an hour without crashing
15:55 lizmat I consider that problem fixed now (although I don't think we actually had a ticket for that)
15:55 lizmat it was inspired by a test anyways
15:55 jnthn Yeah, if it's a flappy test file then we can consider it covveref
15:55 jnthn covfefe!
15:55 jnthn covered :)
16:08 AlexDaniel squashable6: next
16:08 squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 5 days and ≈17 hours (2017-11-04 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day
16:29 ugexe having the rakudo repo open in sublime text and running the spectest makes for an interesting show of the file listing sidebar going batshit
16:30 ugexe i can't stop watching it
16:30 Geth ¦ nqp: e5c0926544 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
16:30 Geth ¦ nqp: Get some more MoarVM goodies by bumping§
16:30 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/e5c0926544
16:30 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.10-19-g5a31123...2017.10-26-gad2d6fb
16:50 lizmat dogbert17 jnthn: that last MVMROOT did not fix the 1202 crash  :-(
16:51 Geth ¦ rakudo: 8203073db0 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
16:51 Geth ¦ rakudo: Get the latest MoarVM again
16:51 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/8203073db0
17:09 dogbert17 darn
17:10 xi- joined #perl6-dev
17:10 Geth ¦ nqp: 0d4885d745 | MasterDuke17++ (committed using GitHub Web editor) | src/HLL/World.nqp
17:10 Geth ¦ nqp: Remove some @*comp_line_directives accesses (#376)
17:10 Geth ¦ nqp:
17:10 Geth ¦ nqp: These may be lost in the noise, but accessing dynamic variables is slow.
17:10 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/0d4885d745
17:14 BenGoldberg joined #perl6-dev
17:18 lizmat .ask jnthn at https://github.com/rakudo/rakudo/blob/master/src/core/ThreadPoolScheduler.pm#L230 , why don't we get an IterationBuffer instead of a List?
17:18 yoleaux lizmat: I'll pass your message to jnthn.
17:19 dogbert17 lizmat: it still hangs for me, under load, as well
17:31 lizmat re last remark of Zoffix on RT #132316, I'm wondering whether we shouldn't expose the ConcBlockingQueue repr as a Queue class
17:31 synopsebot RT#132316 [open]: https://rt.perl.org/Ticket/Display.html?id=132316 [SEGV] Crash while running program (MongoDB module)
17:31 lizmat guaranteed to be save to push to from different threads simultaneously
17:32 lizmat and intended to be shifted from from a single thread
17:32 lizmat most likely *after* all of the pushing threads are done
17:35 Zoffix It can be shifted from multiple threads, can't it? And it'd block if there's nothing to shift.
17:35 Zoffix I'd use a Channel for that case personally, though as I mentioned on the ticket, I don't know much about concurrency stuff.
17:35 lizmat yeah, but then you're left with blocked threads at the end
17:36 lizmat and the race between nqp::elems() and nqp::shift will leave one blocked indefinitely I would think
17:36 lizmat for that particular use case, I feel a Channel is overkill
17:36 Zoffix Yeah, jnthn++ pointed that one out when I did the affinity worker stuff and told me to use nqp::queuepoll op instead
17:43 lizmat also, I was thinking about was to expose nqp::cpucores and nqp::getrusage in Perl 6
17:43 lizmat and I would like to see the number of cpucores overridable by environment variable
17:43 lizmat not sure that should be at the Rakudo or at the MoarVM level
17:45 lizmat I would expect the latter
17:51 Zoffix AlexDaniel: RE https://irclog.perlgeek.de/perl6/2017-10-28#i_15367106 FWIW lizmat++ usually leads the number of contributions to rakudo/rakudo; the ticket count only went down 'cause tests for fixed tickets were written.
17:52 AlexDaniel Zoffix: sure, of course
17:53 AlexDaniel my point was simply that it's not just jnthn++ :)
17:53 Zoffix :)
18:02 jnthn In fact, the more things are not just jnthn, the better :-)
18:02 yoleaux 17:18Z <lizmat> jnthn: at https://github.com/rakudo/rakudo/blob/master/src/core/ThreadPoolScheduler.pm#L230 , why don't we get an IterationBuffer instead of a List?
18:03 jnthn Not least because they've temporarily replaced some of my local tram services with a bus, which is not so promising on the bus number front :P :P
18:04 jnthn I don't think it makes any sense to make cpucores overridable
18:04 Zoffix lol
18:04 jnthn But it may make sense to provide a way to set the thread pool's "preferred size"
18:04 jnthn That is, the number of threads it'll make before it gets reluctant to add more
18:06 lizmat jnthn: ok, any ideas about exposing nqp::cpucores and nqp::getrusage ?
18:06 lizmat the latter specifically wrt to the Benchmark module
18:08 lizmat jnthn: you also don't see a need to be able to reduce number of worker threads, right ?
18:10 jnthn Exposing cpucores - that one I think is a pretty easy call, yes, let's, maybe $*KERNEL is the best place to hang it
18:10 jnthn As a .cpu-cores method returning an Int
18:10 jnthn getrusage needs a bit more careful thought as it's not really portable
18:10 jnthn Only some of the information is reliably available
18:11 jnthn Which doesn't mean we can't provide it, but need to think a little about what API we want
18:11 jnthn Though perhaps some methods on something would do it
18:11 jnthn I don't think returning an array that you have to remember the magic number to index is a very Perl-ish API :)
18:13 lizmat indeed
18:14 Zoffix FWIW, currently working on making all the method call variations respect nodality.
18:14 Zoffix m: my @a := <a b c>, <d e>; dd @a».*Any::elems # e.g. this one
18:14 camelia rakudo-moar 4fca94743: OUTPUT: «($((1,), (1,), (1,)), $((1,), (1,)))␤»
18:15 Zoffix Just mentioning in case it weren't meant to work; so I don't get a revert after the work went in :)
18:16 Zoffix ^ expected for the above is ((3), (2))
18:16 Zoffix ^ expected for the above is ((3,), (2,))
18:23 jnthn Perhaps for rusage we want one method returning an object with a bunch of int attributes
18:23 jnthn Or containing the array and with methods the index it
18:23 jnthn So that you can do one rusage call and access all the info
18:24 jnthn So if you need multiple pieces of it then it's cheap
18:24 jnthn (Sorry for the async replies to stuff, this is competing with cooking :))
18:26 lizmat jnthn: something like Usage.cpu, Usage.cpu-user, Usage.cpu-sys
18:26 lizmat ?
18:27 jnthn Well, an object instance rather than on the type object
18:27 jnthn But yeah
18:27 lizmat yeah, of course  :-)
18:27 jnthn lizmat: re https://github.com/rakudo/rakudo/blob/master/src/core/ThreadPoolScheduler.pm#L230 it's 'cus the thing we've given is a VMArray, and it comes from the VM's event loop
18:28 lizmat ah, and the VM doesn't know IterationBuffer  :-(
18:28 jnthn Right
18:28 jnthn Though if we told it what type to stick things in...it could create that instead
18:28 jnthn So long as the thing as the VMArray REPR it's all god
18:28 jnthn *good
18:28 lizmat so where would we tell that?  in Moar or in Rakudo ?
18:29 timotimo it needs to have an argument that you provide the type in
18:29 timotimo if it doesn't have that yet, it'll go into moarvm's oplist + interp + the function in question
18:30 jnthn We'd need Rakudo to tell Moar the type, much like we pass it the async task handle type
18:31 jnthn Note that for the proc async spawn op those go in a hash, so no config change needed
18:31 jnthn *no ops change
18:31 jnthn Then we'd need to tweak MoarVM a bit
18:32 lizmat wouldn't that introduce additional overhead ?
18:32 jnthn Not really
18:32 jnthn Less than having to wrap the thing into a List :)
18:32 jnthn And unwrap it later
18:32 lizmat ok, because it would save not having to create a List for each job, and one less getattr
18:32 lizmat indeed
18:33 lizmat having read all this, the principle is clear...  but I'm not seeing yet *where* this would need to happen  :-(
18:35 jnthn Well, there's a few places that'd need the tweak. One would be around https://github.com/rakudo/rakudo/blob/nom/src/core/Proc/Async.pm#L332 - you'd poke IterationBuffer into another key of that hash
18:36 jnthn Like args_type or so
18:38 Geth ¦ rakudo: a9b8854a25 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
18:38 Geth ¦ rakudo: Make Queue.elems and .loads about 1.8x faster
18:38 Geth ¦ rakudo:
18:38 Geth ¦ rakudo: Apparently when assigning to native from a sub returning a native
18:38 Geth ¦ rakudo: adding "is raw" makes it about 1.8x as fast.  Probably because it sees
18:38 Geth ¦ rakudo: it doesn't need to box/unbox.
18:38 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a9b8854a25
18:42 jnthn And from there follow it down into the MoarVM guts (from interp.c, probably into somewhere in src/io/procops.c)
18:45 lizmat and there you lost me  :-)
18:47 lizmat we don't have nqp::cpucores and nqp::getrusage on JVM yet, right ?
18:47 jnthn Pretty sure we do
18:47 jnthn Though getrusage is un hack totallement
18:47 jnthn It only gives back one value :)
18:47 lizmat ah, cool :-)
18:48 jnthn Conveniently, the one that the scheduler cares about to do its decision making
18:48 lizmat ah? but as a nqp::list_i, I hope ?
18:48 jnthn It is
18:48 jnthn I just mean only one value is non-zero
18:48 jnthn cpucores should be accurate/correct
18:48 jnthn I put them in so that the new scheduler would build/work on JVM
18:48 lizmat ack
18:49 jnthn Seems like my karahi chicken should be about cooked. bbl :)
18:49 lizmat have a nice dinner!
18:58 Geth ¦ rakudo: 61af87bcd9 | (Elizabeth Mattijsen)++ | src/core/Kernel.pm
18:58 Geth ¦ rakudo: Introducing Kernel.cpu-cores
18:58 Geth ¦ rakudo:
18:58 Geth ¦ rakudo: - callable as class and instance method
18:58 Geth ¦ rakudo: - no documentation yet
18:58 Geth ¦ rakudo: - no tests yet
18:58 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/61af87bcd9
19:30 Zoffix nqp: use QAST; say(QAST::Want.new(QAST::WVal.new(:value('Str')), 'Ss', QAST::SVal.new(:value<x>)))
19:30 camelia nqp-moarvm: OUTPUT: «cannot stringify this␤   at gen/moar/stage2/NQPCORE.setting:950  (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPCORE.setting.moarvm:join)␤ from gen/moar/stage2/NQPCORE.setting:939  (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPCORE.setting.moarvm:say)␤ …»
19:31 Zoffix Is there some way to stringify it and test its string value without poking through it, trying to find QAST::SVal and using its .value?
19:37 ggoebel joined #perl6-dev
19:48 Geth ¦ rakudo: cbd4f212a4 | (Elizabeth Mattijsen)++ | 3 files
19:48 Geth ¦ rakudo: Introducing Usage (name to be bikeshedded)
19:48 Geth ¦ rakudo:
19:48 Geth ¦ rakudo: - exposing nqp::getrusage information
19:48 Geth ¦ rakudo: - methods: cpu, cpu-user, cpu-sys providing microsecond accuracy
19:48 Geth ¦ rakudo: - method: interval, returning CPU microseconds since last call
19:48 Geth ¦ rakudo: - can all be called as class and as instance method
19:48 Geth ¦ rakudo: - also provides infix:<->(Usage,Usage) for convenience
19:48 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/cbd4f212a4
19:49 lizmat $ 6 'my Usage $tracking; for ^10 { print $tracking.interval ~ " " }'
19:49 lizmat 0 1109 279 34 17 20 15 15 23 22
19:51 lizmat perhaps Usage is not such a good name, perhaps Rusage  ?  or Performance?  Timing?
19:52 lizmat hmmm... with Timing, maybe could add wallclock as well
19:54 lizmat suggestions ?
19:57 Zoffix Telemetry? ¯\_(ʘʘ)_/¯
19:58 lizmat actually, I like that  :-)
19:59 masak what does one gain from calling it on an instance?
19:59 lizmat well, if you want to have the cpu-user and cpu-sys seperately from the same moment, you need the instance
19:59 lizmat also, if you want to know the difference between to times
20:02 masak not sure whether I understand fully the cases in which this thing depends on the exact moment you call it, and the cases where it does not :)
20:03 masak I wonder if there is a factoring lurking about wherein each instance could be immutable, like we do with Date and DateTime
20:03 lizmat each instance *is* immutable
20:04 timotimo hm, what does .interval give you exactly?
20:04 lizmat microseconds CPU usage since the previous call
20:04 masak except $tracking.immutable seems to return different things each time :)
20:05 masak I think we migh mean different things by "immutable" here
20:05 masak might*
20:05 lizmat $tracking is just a container that gets a new Usage object each time
20:09 masak oh, so each such object would always return a constant .interval?
20:12 lizmat .interval returns the difference in CPU microseconds, *and* sets the container to the new Usage (immutable) object
20:14 timotimo so the Usage object is immutable, but the method replaces one "self" with another?
20:14 lizmat yeah... that was the idea...  similar to my $a; $a<a> = 42 autovivifying as a hash
20:16 masak again, I don't have all the background, but it sounds A Bit Too Magical :/
20:17 timotimo maybe it'd be better to have it be .= interval ?
20:23 lizmat timotimo: then how would it return the CPU ?
20:33 lizmat masak: would it make you feel better if .interval would return a new object, and update its invocant ?
20:39 masak lizmat: I think it could be surprising that reading .interval would also clear it
20:39 lizmat would clear what ?
20:39 masak .interval
20:41 lizmat now *i* am confused
20:42 masak I guess I was hunting around for a design where you instantiated a Usage object, and it would always give you back the same .interval, and it would never be magically replaced
20:46 lizmat what do you mean with "the same .interval" ?
20:47 masak an unchanging value
20:47 lizmat but what is the point then ?
20:47 lizmat perhaps "elapsed" is a better word
20:47 masak guess I'm missing something based on that question ;)
20:48 lizmat I'm trying to devise an API that could e.g. be easily used in a Benchmark module
20:48 masak I do get that, yes
20:49 masak but all our other time-based types are immutable, and that's very useful/dependable
20:49 masak I'm wondering if that can't be made to work here too
20:50 lizmat feels to me you're asking to make "now" immutable
20:53 masak not quite
20:53 masak `now` returns immutable things
20:54 masak it doesn't feel like the current design has something similar to the immutability of Instant
20:55 masak I'm not sure why I would ever want to store Usage instances, if querying them makes them replace themselves
20:55 lizmat no, querying them would *not* change them
20:56 lizmat cpu, cpu-user, cpu-sys, wallclock
20:56 lizmat would all remain constant for the lifetime of the object
20:56 masak ok
20:56 lizmat .interval is a special utlity method
20:57 masak aha -- with the semantics of "now do a new snapshot"?
20:57 lizmat yep
20:58 masak I'm still uneasy with the "replace `self`" bit of it, at least if I grok it correctly
20:59 masak it's exactly that kind of magic that makes CPAN's DateTime hard to handle, and exactly why we eventually went for full immutability in Perl 6's
20:59 lizmat my Usage $foo; $foo.interval  # is that ok to vivify ?
21:00 lizmat vivify $foo
21:01 masak let me make a full proposal, just to compare it against the current design
21:03 masak no vivification needed. .interval would be a constructor, returning fresh immutable Usage objects. that method would work on instances too, just like .new, but you'd be expected to call it on the Usage class.
21:06 * lizmat is listening
21:06 masak that's it
21:06 masak the way no objects are ever replaced or vivified acts as a guarantee of predictability
21:07 masak specifically, I know that if I'm holding a Usage instance, it won't ever have other values because it was replaced
21:07 lizmat so what's the difference with .new ?
21:08 masak maybe nothing?
21:08 lizmat well, that's not very useful then
21:09 lizmat I've called it Elapsed now:
21:09 lizmat $ 6 'my Usage $tracking; say "$_ $tracking.Elapsed()" for ^3'
21:09 lizmat 0 cpu / wallclock
21:09 lizmat 1 1391 / 688
21:09 lizmat 2 88 / 87
21:09 lizmat how would you do that in your scenario ?
21:09 lizmat and what to you think of the name Telemetry ?
21:10 masak sounds fine
21:10 masak I'm very, very confused by the output from that one-liner
21:11 masak so perhaps best to take everything I'm saying with a grain of salt :P
21:11 lizmat it shows how many CPU and wallclock was used in each iteration (in microseconds)
21:11 masak I understand the $_ bit, but... not the $tracking.Elapsed() bit
21:11 lizmat except for the first iteration, where it conveniently replaces 0/0 by a legenda
21:12 masak augh
21:12 masak ok, I...
21:12 masak I don't know how to provide useful feedback on that ;) sorry
21:13 lizmat $ 6 'my Usage $tracking; say "$_ $tracking.Elapsed.wallclock()" for ^3'
21:13 lizmat 0 0
21:13 lizmat 1 675
21:13 lizmat 2 43
21:13 lizmat if I only want to see wallclock times
21:13 masak though it seems to me returning data as a formatted string might not serve everyone perfectly always
21:14 masak easily formattable data is usually preferable
21:14 lizmat that's just the .Str / .gist of the object
21:14 masak ok
21:19 masak I think two useful operations are mixed up in the current .Elapsed() design: (a) returning some telemetry output, and (b) replacing an old instance by a new instance
21:19 lizmat actually, the latter is no longer the case: it modifies the Usage object in place
21:20 masak ok; same difference
21:20 lizmat well, there you go:
21:20 masak I agree it looks convenient to mix those up for the use case you're showcasing, but it might be less ergonomic for other, less easily imaginable uses
21:21 lizmat I want to make it easier so you don't need to my $old = $current; my $new = Usage.new; my $diff = $new - $old; $current = $new
21:22 masak *nod*
21:23 lizmat from a performance point of view, I wonder what would be better: new objects all the time, or updating an existing
21:23 lizmat I think updating an existing would actually be better
21:23 lizmat but perhaps not  :-)
21:25 masak I'm looking at https://developer.mozilla.org/en-US/docs/Web/API/Performance/now trying to see if there's something we can learn/steal from that API
21:29 lizmat that's just in Instant in another scale
21:30 lizmat or am I missing something
21:33 masak my point is that that API manages to be a Telemetry API which looks very much like our Instant
21:34 lizmat those 4 lines would be for me:
21:36 lizmat my $t = Usage.new; doSomething(); say "Call to doSomething took $t.Elapsed() microseconds"
21:37 lizmat doSomethingElse; say "Call to doSomethingElse took $t.Elapsed() microseconds"
21:37 lizmat no need for extra variables
21:37 masak in the end, we seem to be arguing from our subjective feelings about statefulness in time-like objects
21:37 masak you seem to embrace it; I'm very uneasy with it
21:38 lizmat well, it could well be that other types of Telemetry information are added in the future
21:38 lizmat such as number of disk writes, number of thread changes, number of this, number of that
21:39 masak it reminds me a bit of how a lot of regex matching state is handled in special global variables in Perl 5
21:39 lizmat but it wouldn't be a special variable at all?
21:40 lizmat I mean, a Telemetry object by itself is pretty useless
21:41 lizmat you need at least 2 of them to become useful
21:41 lizmat maybe .Elapsed should be called .GetNextStateInInvocantAndReturnDifferenceSinceLast
21:43 masak :)
21:44 masak please consider my repeated complaining food for thought rather than a demand for change
21:45 lizmat ok, it's just that we don't see you around much here anymore  :)
21:45 masak I realize that
21:45 lizmat now I know how to get your  attention  :-)
21:45 masak will try to make a more positive entrance next time ;)
21:46 masak I think you've basically arrived in terms of ease -- I'm just concerned about, hm, composability, I guess
21:53 lizmat basic interface: my $t = Telemetry.new; say $t.Period
21:53 lizmat 205 / 201
21:53 lizmat actually, that one is slightly magic
22:16 lizmat interesting idea: everything is tainted, unless you mark it as safe: https://tht.help/tutorials/language-tour#lock-strings
22:21 Zoffix neat. Should be pretty easy to make a module, with like this stuff: https://tht.help/manual/class/lock-string/fill . Then things can just require users to give LockStrings.
22:23 jnthn lizmat: I think the rusage thing should return an (immutable) object on each call
22:24 lizmat each call to .new ?
22:24 jnthn Well, my presumption is you'd call something and it'd return an instance, but I guess I can have each time you .new the object it does a call to nqp::getrusage in BUILD
22:25 jnthn That works too
22:25 lizmat yes, that's what it does
22:25 jnthn That said
22:25 lizmat lemme just commit
22:25 Zoffix m: class LockStr does Stringy { has Str:D $.value is required; has @!fills; method fill (*@!fills) {}; method render { $!value.subst: :g, '{}', {shift @!fills} } }; sub prefix:<L> (Str:D $value) { LockStr.new: :$value }; my $l = L'{} says {}'; $l.fill: 'cat', 'meow'; $l.render.say
22:25 jnthn It (this isn't a big concern really) means you can't so easily fake it for tests :)
22:25 camelia rakudo-moar 4fca94743: OUTPUT: «cat says meow␤»
22:25 Geth ¦ rakudo: 273168d7b2 | (Elizabeth Mattijsen)++ | 4 files
22:25 Geth ¦ rakudo: Usage -> Telemetry + more changes
22:25 Geth ¦ rakudo:
22:25 Geth ¦ rakudo: - now also includes wallclock information
22:25 Geth ¦ rakudo: - Telemetry class is just a class with "standard" methods
22:25 Geth ¦ rakudo:   - cpu, cpu-user, cpu-sys, wallclock
22:25 Geth ¦ rakudo:   - can not be created with parameters, .new snapshots current state
22:25 Geth ¦ rakudo: - Telemetry::Period is just a class with the same standard methods
22:25 Geth ¦ rakudo: <…commit message has 7 more lines…>
22:25 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/273168d7b2
22:27 lizmat jnthn: they're just two classes: Telemetry and Telemetry::Period
22:27 lizmat each normal by themselves
22:27 lizmat the only special thing is the .Period method on Telemetry
22:27 lizmat $ 6 'my Telemetry $t; say $t.Period for ^3'
22:27 lizmat cpu / wallclock
22:27 lizmat 1038 / 705
22:27 lizmat 177 / 176
22:28 lizmat if you want to do it the hard way, you can
22:28 jnthn Why does the - operator assume you only care about one of the units?
22:28 lizmat well, I guess I can also make that return a Telemetry::Period object
22:29 lizmat you're right
22:29 jnthn I'd rather that you subtract two Telemetry objects to get a Telemetry::Period
22:29 jnthn .Period updating the object in-place feels a bit...odd
22:30 jnthn Just getting two Telemetry objects and subtracting one from the other to get the period feels a lot cleaner to me
22:31 jnthn oooh, bonus sleep tonight \o/
22:31 masak \o/
22:40 lizmat $ 6 'my $t = Telemetry.new; say (Telemetry.new - $t).perl'
22:40 lizmat Telemetry::Period.new(:cpu-user(333), :cpu-sys(24), :wallclock(177))
22:40 lizmat more like that ?
22:40 Geth ¦ rakudo: 3e175c833b | (Elizabeth Mattijsen)++ | src/core/Telemetry.pm
22:40 Geth ¦ rakudo: Make sure Telemetry - Telemetry returns a T::Period
22:40 Geth ¦ rakudo:
22:40 Geth ¦ rakudo: - also fix Telemetry::Period.perl invocant check
22:40 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3e175c833b
22:41 jnthn lizmat: Yeah :)
22:42 lizmat and with that /me goes to bed
22:42 lizmat good night, have an extra long one!
22:43 jnthn 'night, lizmat++ :)
22:54 bisectable6 joined #perl6-dev

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary