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 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/…
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 ( no output )
Zoffix Weird that it crashes in a role but not class
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
"This representation (Null) does not support associative access (for type VMNull)" 01:01
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:07
Zoffix Weird... This fixes the quote braid cache bug: gist.github.com/zoffixznet/99f6c63...12882d78c8 but this doesn't: gist.github.com/zoffixznet/2dde6f3...150bff9088 I thought the two version would be equivalent 02:20
Oh, it's all crap. It never caches and nothing's fixed -_- 02:25
'cause return value ain't null
heh... it either caches too eagerly or doesn't cache at all 03:02
buggable: zen can has middle ground?
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.”
Zoffix Neat. 03:03
ZOFFLOP: t/spec/S11-modules/nested.t 04:08
ZOFVM: Files=1283, Tests=152770, 146 wallclock secs (19.90 usr 3.31 sys + 3122.17 cusr 152.68 csys = 3298.06 CPU)
Geth rakudo: ad16c6fb86 | (Zoffix Znet)++ | src/Perl6/Grammar.nqp
Fix quote lang cache regression

Fixes RT#132262: rt.perl.org/Ticket/Display.html?id=132262
After the Big Slang Refactor, the quote lang cache started to fail to notice when the cached lang was mutated (e.g. by defining a new prefix op). This caused failure to parse new ops, such as behaviour in the ticket, since the new quoted block still used the old pre-op-mixin lang.
Fix by adding the name of the lang object to key the cache on.		 04:15
synopsebot RT#132262 [open]: rt.perl.org/Ticket/Display.html?id=132262 [REGRESSION] Quote braid misses Main braid's language change due to new ops 04:16
roast: 730b5c8239 | (Zoffix Znet)++ | S13-overloading/operators.t
Test quote lang cache does not break our ops

RT#132262: rt.perl.org/Ticket/Display.html?id=132262 Rakudo fix: github.com/rakudo/rakudo/commit/ad16c6fb86
Zoffix heh my ./close-rt got broken by nom rename :) 04:19
A 2-second fix, but I'm going to have to speak to your manager about it!! :) 04:20
Geth nqp: e5849c41ec | (Zoffix Znet)++ | tools/build/MOAR_REVISION
Bump MoarVM
 04:23
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...4-g89565bf
rakudo: 9dba8e5bc3 | (Zoffix Znet)++ | tools/build/NQP_REVISION
Bump NQP
AlexDaniel greppable6: moar-nom 06:43
greppable6 AlexDaniel, gist.github.com/7b0b64bea6e04d2004...907565f149
AlexDaniel oooooops 06:44
ok, all these have a PR to replace nom with master 06:50
(except when it's in a comment, so who cares)
Geth star: hankache++ created pull request #105:
Update perl6intro.pdf		 07:52
star: ffe583683e | (Naoum Hankache)++ | docs/perl6intro.pdf
Update perl6intro.pdf
 07:59
star: b14f160438 | (Steve Mynott)++ (committed using GitHub Web editor) | docs/perl6intro.pdf
Merge pull request #105 from hankache/master

Update perl6intro.pdf
lizmat Files=1229, Tests=75775, 321 wallclock secs (14.81 usr 5.23 sys + 2198.02 cusr 213.28 csys = 2431.34 CPU) 09:20
and there I thought :ignoremark was a thing 09:35
stackoverflow.com/questions/469871...-in-perl-6 09:36
moritz it is, though maybe not what OP wants 09:43
lizmat docs.perl6.org appears to be oblivious to ignoremark 09:48
Geth nqp: 8f18b6a281 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Bump Moar for the latest goodies
 09:49
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...4-g590dd2e
moritz lizmat: indeed
lizmat: I'll open an issue for that
github.com/perl6/doc/issues/1133 AlexDaniel++ was faster 09:50
AlexDaniel squashable6: next 09:52
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 6 days and ≈0 hours (2017-11-04 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
dogbert17 lizmat: do you still have trouble with the CAS tests? 10:00
lizmat $ time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 16'; do :; done 10:01
Segmentation fault: 11
real0m4.120s
dogbert17: so that would be a yes, I'm afraid
dogbert17 tries the example ... 10:03
dogbert17 runs a spectest at the same time 10:04
lizmat it fixed it for jnthn on linux, but apparently MacOS is different :-( 10:05
dogbert17 could be, is also on Linux
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
gist.github.com/lizmat/d22cfb0c67f...3b7187c15e 10:07
dogbert17 now the first example crashed
lizmat I also have the vague idea that the crashes seem to coincide with filesystem activity
Geth rakudo: 6a6cea3856 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump NQP for the latest MoarVM goodies
 10:08
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.
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:11
lizmat aaahhhh, that gives me an idea: 10:12
github.com/rakudo/rakudo/blob/mast...er.pm#L549
it's pushing to the general queue, but that may not exist yet at that time ? 10:13
dogbert17 but then I should see this text 'Stealing queue from affinity worker' or ? 10:15
lizmat ah, yes
but still, we need to make sure we have a general queue at that time 10:16
:w
oops
dogbert17 tries running the cas example under asan 10:20
stmuk_ github.com/stmuk/rakudo-packages 10:22
Geth rakudo: a7972a0ce4 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Make sure we have a general queue when stealing

  - although unlikely, it is possible to have no general queue at that point		 10:30
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? :)
Zoffix HEAD: 62.83user 0.40system 1:02.80elapsed 100%CPU (0avgtext+0avgdata 220256maxresident)k
Results for running this program: gist.github.com/zoffixznet/e83afe9...5dca0dff73
AlexDaniel so it's much slower now? Let's see when this happened? 10:39
Zoffix The slang refactor happened.
And you won't see much, consdering since about 2017.03 that program was broken until last night 10:40
AlexDaniel :(
Zoffix or I think it was... 10:41
(expected it to crash instantly but it didn't) 10:42
Ah right, it's not actually using the ops for it to crash; but still it's not caching the quote lang properly 10:43
star: $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }"; 10:44
camelia 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
Zoffix c: 2017.03 $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }";
committable6 Zoffix, gist.github.com/fa24260474685f9e68...c0aa5a1aeb
Zoffix c: 2017.01 $ = ""; sub postfix:<!> { [*] ^$^f+1}; say "{ 5! }";
committable6 Zoffix, ¦2017.01: «120»
Zoffix builds 2017.01 to see the measurements there
stmuk_ samcv: which versions of rakudo and star are available in your flatpak builds? It's unclear to me looking at the filenames at github.com/samcv/rakudo-appimage-m...e/gh-pages 10:51
Zoffix 48.66user 0.08system 0:48.77elapsed 99%CPU (0avgtext+0avgdata 176344maxresident)k 10:53
for 2017.01 10:54
2017.09: 63.84user 0.31system 1:03.86elapsed 100%CPU (0avgtext+0avgdata 218200maxresident)k 10:55
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. 10:56
stmuk_ Does anyone know of anything which should be added to github.com/stmuk/rakudo-packages? 11:04
Zoffix AlexDaniel: github.com/perl6/marketing/tree/ma...on/2017.11 11:09
AlexDaniel Zoffix: awesome. Tweet? 11:11
Zoffix twitter.com/zoffix/status/924232852551716864 11:15
AlexDaniel Zoffix: thx ♥
squashable6: next 11:18
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 5 days and ≈22 hours (2017-11-04 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
AlexDaniel 7 days? :o
Zoffix whatevs... it's 7 days in my timezone 11:19
lizmat hmmm... it looks like adding an nqp::getpid to the mainline of ThreadPoolScheduler, fixes GH #1202 for me # dogbert17 11:22
dogbert17 that's interesting, how long have you been running? 11:23
lizmat about 5 minutes now
dogbert17 didn't it use to crash more or less immediatly for you? 11:25
jnthn's fix from yesterday has made a large difference on my system 11:27
hmm, no numbers from |Tux| today ? 11:31
lizmat I guess [Tux] is relaxing
dogbert17: still running 11:32
closing in on 15 minutes
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,
and / or a race condition in getting it
that is prevented by doing it from the start 11:34
when there are no threads running yet
MoarVM panic: Heap corruption detected: pointer 0x10ff31780 to past fromspace # real 16m48.435s *sigh* 11:35
dogbert17 :(
lizmat running another one
Geth rakudo: a1866b7b33 | (Elizabeth Mattijsen)++ | 2 files
Always set up $*PID

  - needed it earlier for debugging message
  - seems to have a stabilizing effect wrt GH #1202, at least on MacOS
  - registering the cheap dynamic was probably relatively expensive anyway		 11:38
synopsebot RAKUDO#1202 [open]: github.com/rakudo/rakudo/issues/1202 [severe] Async qqx sometimes hangs or dies ( await (^5).map({start { say qqx{… …} } }) )
dogbert17 also got it to segv. Trying with gdb now ...
dogbert17 while running a stresstest with six jobs plus some downloads 11:39
hah
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb47ffb40 (LWP 4282)]
0xb7c36892 in MVM_serialization_finish_deserialize_method_cache (tc=tc@entry=0xa0e6d88, st=st@entry=0x8c5dfb8) at src/6model/serialization.c:2901 11:40
probably another missing MVM_ROOT since it seems to be dealing with a mutex again
github.com/MoarVM/MoarVM/blob/mast...on.c#L2901 11:42
Geth rakudo: 260e4a3a27 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Only call debug status sub if debug status set

  - this is the only place so far where debug status is called
  - it's inside the hot loop, so makes sense to not always take the call overhead
  - makes the supervisor idle overhead drop from 37 to 33 msec / second		 12:06
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
lizmat yeah, but still, all little things help 12:09
timotimo mhm
jnthn tbh, the cost of getrusage is probably dominated by what getrusage does :)
lizmat and the orange was distracting in the --profile output :-)
timotimo :)
jnthn: a chance you could also review the "cstructarray" pull request in the coming week? 12:10
jnthn timotimo: Yes; please prod me on Tuesday if I didn't already get to it by then 12:11
timotimo OK! 12:12
[Tux] Tux was walking on the "Hulshorsterzand". Timing is running now 13:17
buggable New CPAN upload: RPi-ButtonWatcher-0.0.1.tar.gz by PATRICKZ cpan.metacpan.org/authors/id/P/PA/...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?
timotimo oh, i did not 13:27
does it also work with array of string?
MasterDuke nope 13:28
i think i made that a tiny bit faster with my INTERPOLATE refactor, but nowhere near the same amount 13:29
timotimo mhm :S 13:30
[Tux] Rakudo version 2017.10-4-g4fca94743 - MoarVM version 2017.10-1-g213fc774
csv-ip5xs1.159 - 1.284
csv-ip5xs-2014.476 - 15.130
csv-parser12.150 - 12.342
csv-test-xs-200.472 - 0.500
test11.464 - 11.884
test-t3.129 - 3.188
test-t-2056.537 - 57.055
test-t-20 --race20.393 - 20.875
 13:35
timotimo the ones with 20 are like 20x as many lines?
lizmat yes 13:37
although we seem to have lost a second on t-20 --race since the last time :-(((
but won 2 seconds on the t-20 without race
hmmm... not sure what to make of that
m: ^100 .race>>.say # weird 13:43
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing << or >>
at <tmp>:1
------> 3^100 .race>>.7⏏5say # weird
lizmat m: (^100).race>>.say # works ok
camelia 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…
lizmat jnthn: could it be that the additional MVM_ROOTs have a rather large negative effect on racing performance ? 13:45
Geth nqp: 225fdfce33 | (Stefan Seifert)++ | 2 files
Map the new getarg_i op for reading from the args buffer
 13:50
rakudo: 3bd756f549 | (Stefan Seifert)++ | 2 files
Support rw integer arguments of JIT compiled native subs

After the call to the native function, we need to read back the changed values from the args buffer. We can't use the param_* ops there because we don't set up a call frame for the native call. Thus the param_* ops would read the HLL sub's arguments instead of the native function's. We use the new getarg_i op instead to get the changed value and assign it to the lexicalref for the rw parameter.		 13:54
dogbert17 lizmat: the MVMROOT fix has been merged, hopefully it fixes the segv's (famous last words) 14:00
Geth nqp: 9fc2e1f1f3 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Bump Moar to get additional mutex MVMROOTs
 14:27
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...9-g5a31123
lizmat dogbert17: alas, still crashing, but feels that it is crashing less often 14:38
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
22 seconds 14:39
and then a bunch below 3 seconds :-(
dogbert17 hmm, so the search continues 14:41
lizmat yeah...
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:42
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
dogbert17 cool
lizmat argh
lizmat is stupid
I haven't bumped rakudo locally yet
dogbert17 :)
so there's still a chance 14:45
lizmat yup
running spectest and code now 14:47
so far so good 14:48
Geth rakudo: 0a029db60c | (Stefan Seifert)++ | lib/NativeCall.pm6
Treat undefined strings correctly in JIT compiled native subs
 14:50
lizmat dogbert17: still looking good 14:51
time while perl6 --ll-exception -e 'await (^16).map({start { qqx{echo -n foo $_} } })'; do :; done # heap corruption after 5 minutes 14:55
the cas one still going strong
dogbert17: looks like jnthn found another one 14:56
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) 14:57
lizmat dogbert17: cas one still running, the GH #1202 one as well 15:07
so that's 20 minutes for the cas one
dogbert17 lizmat, that's promising 15:08
Geth rakudo: d05e61df95 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump NQP to get latest Moar gc fixes.
 15:09
lizmat GH 1202 one crashed after almost 20 mins, cas one still going strong 15:15
dogbert17: I'd say this was a definite improvement!
buggable New CPAN upload: RPi-Device-ST7036-0.0.3.tar.gz by PATRICKZ cpan.metacpan.org/authors/id/P/PA/...0.3.tar.gz 15:16
lizmat buggable: that link is not really useful this way :-( 15:17
dogbert17 perhaps the one jnthn found will seal the deal 15:19
lizmat hopes so 15:23
jnthn Zoffix nine timotimo: would you have anything against making $*PID writable ? 15:38
this is re: github.com/rakudo/rakudo/commit/a1...t-25253686 15:39
jnthn Uh...writable? 15:43
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
*your
oh, it's a fork question
lizmat yup
jnthn fork *will* end in tears anyway
lizmat well, yes, so I wanted to not facilitate it too much by creating a Proxy that would do a nqp::getpid
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
also, maybe we should add a fork() that throws an X::ThatIsNotAGoodIdea eror
error
jnthn I don't think so 15:46
Because anyone nativecalling it would just hide that anyway
And the docs already discuss the situation
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.
lizmat b2gills: you will have to do a PROCESS::<$PID> = nqp::getpid in the child process 15:48
actually bind it: PROCESS::<$PID> := nqp::getpid
time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 4'; do :; done 15:54
has now run over an hour without crashing
I consider that problem fixed now (although I don't think we actually had a ticket for that) 15:55
it was inspired by a test anyways
jnthn Yeah, if it's a flappy test file then we can consider it covveref
covfefe!
covered :)
AlexDaniel squashable6: next 16:08
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 5 days and ≈17 hours (2017-11-04 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
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:29
i can't stop watching it 16:30
Geth nqp: e5c0926544 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Get some more MoarVM goodies by bumping§
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...6-gad2d6fb
lizmat dogbert17 jnthn: that last MVMROOT did not fix the 1202 crash :-( 16:50
Geth rakudo: 8203073db0 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Get the latest MoarVM again
 16:51
dogbert17 darn 17:09
Geth nqp: 0d4885d745 | MasterDuke17++ (committed using GitHub Web editor) | src/HLL/World.nqp
Remove some @*comp_line_directives accesses (#376)

These may be lost in the noise, but accessing dynamic variables is slow.		 17:10
lizmat .ask jnthn at github.com/rakudo/rakudo/blob/mast...er.pm#L230 , why don't we get an IterationBuffer instead of a List? 17:18
yoleaux lizmat: I'll pass your message to jnthn.
dogbert17 lizmat: it still hangs for me, under load, as well 17:19
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]: rt.perl.org/Ticket/Display.html?id=132316 [SEGV] Crash while running program (MongoDB module)
lizmat guaranteed to be save to push to from different threads simultaneously
and intended to be shifted from from a single thread 17:32
most likely *after* all of the pushing threads are done
Zoffix It can be shifted from multiple threads, can't it? And it'd block if there's nothing to shift. 17:35
I'd use a Channel for that case personally, though as I mentioned on the ticket, I don't know much about concurrency stuff.
lizmat yeah, but then you're left with blocked threads at the end
and the race between nqp::elems() and nqp::shift will leave one blocked indefinitely I would think 17:36
for that particular use case, I feel a Channel is overkill
Zoffix Yeah, jnthn++ pointed that one out when I did the affinity worker stuff and told me to use nqp::queuepoll op instead
lizmat also, I was thinking about was to expose nqp::cpucores and nqp::getrusage in Perl 6 17:43
and I would like to see the number of cpucores overridable by environment variable
not sure that should be at the Rakudo or at the MoarVM level
I would expect the latter 17:45
Zoffix AlexDaniel: RE 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:51
AlexDaniel Zoffix: sure, of course 17:52
my point was simply that it's not just jnthn++ :) 17:53
Zoffix :)
jnthn In fact, the more things are not just jnthn, the better :-) 18:02
yoleaux 17:18Z <lizmat> jnthn: at github.com/rakudo/rakudo/blob/mast...er.pm#L230 , why don't we get an IterationBuffer instead of a List?
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:03
I don't think it makes any sense to make cpucores overridable 18:04
Zoffix lol
jnthn But it may make sense to provide a way to set the thread pool's "preferred size"
That is, the number of threads it'll make before it gets reluctant to add more
lizmat jnthn: ok, any ideas about exposing nqp::cpucores and nqp::getrusage ? 18:06
the latter specifically wrt to the Benchmark module
jnthn: you also don't see a need to be able to reduce number of worker threads, right ? 18:08
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
As a .cpu-cores method returning an Int
getrusage needs a bit more careful thought as it's not really portable
Only some of the information is reliably available
Which doesn't mean we can't provide it, but need to think a little about what API we want 18:11
Though perhaps some methods on something would do it
I don't think returning an array that you have to remember the magic number to index is a very Perl-ish API :)
lizmat indeed 18:13
Zoffix FWIW, currently working on making all the method call variations respect nodality. 18:14
m: my @a := <a b c>, <d e>; dd @a».*Any::elems # e.g. this one
camelia ($((1,), (1,), (1,)), $((1,), (1,)))
Zoffix Just mentioning in case it weren't meant to work; so I don't get a revert after the work went in :) 18:15
^ expected for the above is ((3), (2)) 18:16
^ expected for the above is ((3,), (2,))
jnthn Perhaps for rusage we want one method returning an object with a bunch of int attributes 18:23
Or containing the array and with methods the index it
So that you can do one rusage call and access all the info
So if you need multiple pieces of it then it's cheap 18:24
(Sorry for the async replies to stuff, this is competing with cooking :))
lizmat jnthn: something like Usage.cpu, Usage.cpu-user, Usage.cpu-sys 18:26
?
jnthn Well, an object instance rather than on the type object 18:27
But yeah
lizmat yeah, of course :-)
jnthn lizmat: re github.com/rakudo/rakudo/blob/mast...er.pm#L230 it's 'cus the thing we've given is a VMArray, and it comes from the VM's event loop
lizmat ah, and the VM doesn't know IterationBuffer :-( 18:28
jnthn Right
Though if we told it what type to stick things in...it could create that instead
So long as the thing as the VMArray REPR it's all god
*good
lizmat so where would we tell that? in Moar or in Rakudo ?
timotimo it needs to have an argument that you provide the type in 18:29
if it doesn't have that yet, it'll go into moarvm's oplist + interp + the function in question
jnthn We'd need Rakudo to tell Moar the type, much like we pass it the async task handle type 18:30
Note that for the proc async spawn op those go in a hash, so no config change needed 18:31
*no ops change
Then we'd need to tweak MoarVM a bit
lizmat wouldn't that introduce additional overhead ? 18:32
jnthn Not really
Less than having to wrap the thing into a List :)
And unwrap it later
lizmat ok, because it would save not having to create a List for each job, and one less getattr
indeed
having read all this, the principle is clear... but I'm not seeing yet *where* this would need to happen :-( 18:33
jnthn Well, there's a few places that'd need the tweak. One would be around github.com/rakudo/rakudo/blob/nom/...nc.pm#L332 - you'd poke IterationBuffer into another key of that hash 18:35
Like args_type or so 18:36
Geth rakudo: a9b8854a25 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm
Make Queue.elems and .loads about 1.8x faster

Apparently when assigning to native from a sub returning a native adding "is raw" makes it about 1.8x as fast. Probably because it sees it doesn't need to box/unbox.		 18:38
jnthn And from there follow it down into the MoarVM guts (from interp.c, probably into somewhere in src/io/procops.c) 18:42
lizmat and there you lost me :-) 18:45
we don't have nqp::cpucores and nqp::getrusage on JVM yet, right ? 18:47
jnthn Pretty sure we do
Though getrusage is un hack totallement
It only gives back one value :)
lizmat ah, cool :-)
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 ?
jnthn It is
I just mean only one value is non-zero
cpucores should be accurate/correct
I put them in so that the new scheduler would build/work on JVM
lizmat ack
jnthn Seems like my karahi chicken should be about cooked. bbl :) 18:49
lizmat have a nice dinner!
Geth rakudo: 61af87bcd9 | (Elizabeth Mattijsen)++ | src/core/Kernel.pm
Introducing Kernel.cpu-cores

  - callable as class and instance method
  - no documentation yet
  - no tests yet		 18:58
Zoffix nqp: use QAST; say(QAST::Want.new(QAST::WVal.new(:value('Str')), 'Ss', QAST::SVal.new(:value<x>))) 19:30
camelia 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)
…
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:31
Geth rakudo: cbd4f212a4 | (Elizabeth Mattijsen)++ | 3 files
Introducing Usage (name to be bikeshedded)

  - exposing nqp::getrusage information
  - methods: cpu, cpu-user, cpu-sys providing microsecond accuracy
  - method: interval, returning CPU microseconds since last call
  - can all be called as class and as instance method
  - also provides infix:<->(Usage,Usage) for convenience		 19:48
lizmat $ 6 'my Usage $tracking; for ^10 { print $tracking.interval ~ " " }' 19:49
0 1109 279 34 17 20 15 15 23 22
perhaps Usage is not such a good name, perhaps Rusage ? or Performance? Timing? 19:51
hmmm... with Timing, maybe could add wallclock as well 19:52
suggestions ? 19:54
Zoffix Telemetry? ¯\_(ʘʘ)_/¯ 19:57
lizmat actually, I like that :-) 19:58
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
also, if you want to know the difference between to times
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:02
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
timotimo hm, what does .interval give you exactly? 20:04
lizmat microseconds CPU usage since the previous call
masak except $tracking.immutable seems to return different things each time :)
I think we migh mean different things by "immutable" here 20:05
might*
lizmat $tracking is just a container that gets a new Usage object each time
masak oh, so each such object would always return a constant .interval? 20:09
lizmat .interval returns the difference in CPU microseconds, *and* sets the container to the new Usage (immutable) object 20:12
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
masak again, I don't have all the background, but it sounds A Bit Too Magical :/ 20:16
timotimo maybe it'd be better to have it be .= interval ? 20:17
lizmat timotimo: then how would it return the CPU ? 20:23
masak: would it make you feel better if .interval would return a new object, and update its invocant ? 20:33
masak lizmat: I think it could be surprising that reading .interval would also clear it 20:39
lizmat would clear what ?
masak .interval
lizmat now *i* am confused 20:41
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:42
lizmat what do you mean with "the same .interval" ? 20:46
masak an unchanging value 20:47
lizmat but what is the point then ?
perhaps "elapsed" is a better word
masak guess I'm missing something based on that question ;)
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
but all our other time-based types are immutable, and that's very useful/dependable 20:49
I'm wondering if that can't be made to work here too
lizmat feels to me you're asking to make "now" immutable 20:50
masak not quite 20:53
`now` returns immutable things
it doesn't feel like the current design has something similar to the immutability of Instant 20:54
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
cpu, cpu-user, cpu-sys, wallclock 20:56
would all remain constant for the lifetime of the object
masak ok
lizmat .interval is a special utlity method
masak aha -- with the semantics of "now do a new snapshot"? 20:57
lizmat yep
masak I'm still uneasy with the "replace `self`" bit of it, at least if I grok it correctly 20:58
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 ?
vivify $foo 21:00
masak let me make a full proposal, just to compare it against the current design 21:01
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:03
lizmat is listening 21:06
masak that's it
the way no objects are ever replaced or vivified acts as a guarantee of predictability
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 ?
masak maybe nothing? 21:08
lizmat well, that's not very useful then
I've called it Elapsed now: 21:09
$ 6 'my Usage $tracking; say "$_ $tracking.Elapsed()" for ^3'
0 cpu / wallclock
1 1391 / 688
2 88 / 87
how would you do that in your scenario ?
and what to you think of the name Telemetry ?
masak sounds fine 21:10
I'm very, very confused by the output from that one-liner
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)
masak I understand the $_ bit, but... not the $tracking.Elapsed() bit
lizmat except for the first iteration, where it conveniently replaces 0/0 by a legenda
masak augh 21:12
ok, I...
I don't know how to provide useful feedback on that ;) sorry
lizmat $ 6 'my Usage $tracking; say "$_ $tracking.Elapsed.wallclock()" for ^3' 21:13
0 0
1 675
2 43
if I only want to see wallclock times
masak though it seems to me returning data as a formatted string might not serve everyone perfectly always
easily formattable data is usually preferable 21:14
lizmat that's just the .Str / .gist of the object
masak ok
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
masak ok; same difference 21:20
lizmat well, there you go:
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
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:21
masak *nod* 21:22
lizmat from a performance point of view, I wonder what would be better: new objects all the time, or updating an existing 21:23
I think updating an existing would actually be better
but perhaps not :-)
masak I'm looking at developer.mozilla.org/en-US/docs/W...rmance/now trying to see if there's something we can learn/steal from that API 21:25
lizmat that's just in Instant in another scale 21:29
or am I missing something 21:30
masak my point is that that API manages to be a Telemetry API which looks very much like our Instant 21:33
lizmat those 4 lines would be for me: 21:34
my $t = Usage.new; doSomething(); say "Call to doSomething took $t.Elapsed() microseconds" 21:36
doSomethingElse; say "Call to doSomethingElse took $t.Elapsed() microseconds" 21:37
no need for extra variables
masak in the end, we seem to be arguing from our subjective feelings about statefulness in time-like objects
you seem to embrace it; I'm very uneasy with it
lizmat well, it could well be that other types of Telemetry information are added in the future 21:38
such as number of disk writes, number of thread changes, number of this, number of that
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?
I mean, a Telemetry object by itself is pretty useless 21:40
you need at least 2 of them to become useful 21:41
maybe .Elapsed should be called .GetNextStateInInvocantAndReturnDifferenceSinceLast
masak :) 21:43
please consider my repeated complaining food for thought rather than a demand for change 21:44
lizmat ok, it's just that we don't see you around much here anymore :) 21:45
masak I realize that
lizmat now I know how to get your attention :-)
masak will try to make a more positive entrance next time ;)
I think you've basically arrived in terms of ease -- I'm just concerned about, hm, composability, I guess 21:46
lizmat basic interface: my $t = Telemetry.new; say $t.Period 21:53
205 / 201
actually, that one is slightly magic
interesting idea: everything is tainted, unless you mark it as safe: tht.help/tutorials/language-tour#lock-strings 22:16
Zoffix neat. Should be pretty easy to make a module, with like this stuff: tht.help/manual/class/lock-string/fill . Then things can just require users to give LockStrings. 22:21
jnthn lizmat: I think the rusage thing should return an (immutable) object on each call 22:23
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
That works too 22:25
lizmat yes, that's what it does
jnthn That said
lizmat lemme just commit
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
jnthn It (this isn't a big concern really) means you can't so easily fake it for tests :)
camelia cat says meow
Geth rakudo: 273168d7b2 | (Elizabeth Mattijsen)++ | 4 files
Usage -> Telemetry + more changes

  - now also includes wallclock information
  - Telemetry class is just a class with "standard" methods
   - cpu, cpu-user, cpu-sys, wallclock
   - can not be created with parameters, .new snapshots current state
  - Telemetry::Period is just a class with the same standard methods
... (7 more lines)
lizmat jnthn: they're just two classes: Telemetry and Telemetry::Period 22:27
each normal by themselves
the only special thing is the .Period method on Telemetry
$ 6 'my Telemetry $t; say $t.Period for ^3'
cpu / wallclock
1038 / 705
177 / 176
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?
lizmat well, I guess I can also make that return a Telemetry::Period object
you're right 22:29
jnthn I'd rather that you subtract two Telemetry objects to get a Telemetry::Period
.Period updating the object in-place feels a bit...odd
Just getting two Telemetry objects and subtracting one from the other to get the period feels a lot cleaner to me 22:30
oooh, bonus sleep tonight \o/ 22:31
masak \o/
lizmat $ 6 'my $t = Telemetry.new; say (Telemetry.new - $t).perl' 22:40
Telemetry::Period.new(:cpu-user(333), :cpu-sys(24), :wallclock(177))
more like that ?
Geth rakudo: 3e175c833b | (Elizabeth Mattijsen)++ | src/core/Telemetry.pm
Make sure Telemetry - Telemetry returns a T::Period

  - also fix Telemetry::Period.perl invocant check
jnthn lizmat: Yeah :) 22:41
lizmat and with that /me goes to bed 22:42
good night, have an extra long one!
jnthn 'night, lizmat++ :) 22:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!