TimToady %-15f, heh, won't ask who installed that one... 00:37
01:03 Mouq joined 01:32 d4l3k_ joined
diakopter TimToady: 01:34
01:43 lue joined
TimToady
.oO(Nobody strikes again!)
 01:47
02:12 jnap joined 02:51 Mouq joined 03:28 ozmq joined
ozmq everybody++ for release 03:30
04:10 ozmq joined 04:39 Mouq joined 06:27 Mouq joined 08:13 FROGGS joined 08:15 Mouq joined 08:26 odc joined 09:05 cognominal joined 09:16 Mouq joined 13:09 Mouq joined 13:43 bibifuc_ joined 13:52 ggoebel1112 joined 14:02 camelia joined 14:57 Mouq joined 14:58 ggoebel1112 joined 15:07 jnap joined 16:45 Mouq joined
timotimo in MVMString.h there's a reference to "lower_index" and "higher_index" that's supposed to be in the MVMStrand struct 16:56
those do not currently exist there
what'll it be?
FROGGS could be about unicode codepoints <=0xFFFF and >0xFFFF too, no? 16:58
not looked at the code though
17:07 FROGGS[mobile] joined
diakopter no 17:07
the .h comments are out of date, not speculative
or they were renamed 17:08
timotimo right. 17:12
can you update them? 17:13
diakopter the 'no' was to Froggs
timotimo ah 17:23
FROGGS[mobile] tss 17:24
[Coke] moar at to 28673 today. 17:36
s/to//
17:39 ggoebel1112 joined
timotimo (gdb) print *result 17:57
"r(NQPCORE)(.setting.moarvm)"
that's the result of a concatenation :)
a rope! :D
okay, so a pretty printer for string, that's done 18:03
now i suppose i can display some extra info for MVMObject*
[Coke] timotimo++ 18:04
18:07 FROGGS joined
timotimo i forgot again: how exactly do i get to the name of something? 18:09
i know how to get the name of the repr, so that much is known 18:12
jnthn timotimo: With difficulty at present, if you're in C land. 18:19
timotimo: 'cus you'd have to call .name on the meta-object, but that'll drop you back into the runloop.
timotimo: For these kinda things I've pondered having a way to set a debug name on an STable, which we hold as a simple C string (in utf-8)... 18:20
timotimo hm, right 18:24
is there a sane way to have an inferior runloop like what i've heard exists somewhere in parrot land? 18:25
don't we need something like that for callbacks from c land anyway?
jnthn There's no sane way to have inferior runloops. 18:26
TimToady that depends on whether the subcode expects it to run immediately, or can just schedule it to run 18:27
if you can just schedule it, then it's not an inferior runloop
timotimo hehe.
jnthn Moar doesn't have them at all. We may allow a *very* limited form for callbacks from C land that must execute synchronously, but it will be deliberately written as unreusable code to make sure people don't use it for anything else.
TimToady "Here be dinosaurs!" 18:28
jnthn Parrot made inferior runloops easy and the consequences were...painful.
r: sub foo($x = take 42) { }; say gather foo() 18:29
camelia rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«42␤»
..rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤ in sub foo at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
jnthn r: sub foo($x = take 42) { say "and we got here" }; say gather foo()
camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤ in sub foo at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«and we got here␤42␤»
jnthn I'm a little surprised that one works out on Parrot :)
FROGGS jnthn: it works!!
jnthn r: sub foo($x = take 42, $y = take 43) { say "and we got here" }; say gather foo() 18:30
camelia rakudo-parrot 8ae2de, rakudo-jvm 8ae2de, rakudo-moar 8ae2de: OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfile␤Variable '$y' is not declared␤at /tmp/tmpfile:1␤------> sub foo($x = take 42, $y⏏ = take 43) { say "and we got here" }; s…»
jnthn r: sub foo($x = (take 42), $y = take 43) { say "and we got here" }; say gather foo()
camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤ in sub foo at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«and we got here␤42 43␤»
jnthn Yeah, I'm a bit surprised Parrot manages that one :)
I thougth there'd be a continuation barrier there.
Oh, but it's done with coroutines, which aren't implemented atop of continuations 18:31
So we perhaps get away with a bit more. :)
r: sub foo($x = (take 42), $y = take 43) { say "and we got here" }; my @a := gather foo(); say @a[0]; say 'here'; say @a[1]; # curious about this one 18:32
camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤ in sub foo at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-moar 8ae2de: OUTPUT«42␤here␤43␤»
..rakudo-parrot 8ae2de: OUTPUT«42␤here␤43␤Nominal type check failed for parameter '$y'; expected Any but got Mu instead␤»
jnthn Oh my. :)
TimToady it's not clear to me that gather/take should be implemented with a control exception in any case 18:38
especially if that implies a stack search every take 18:40
well, I suppose the destination can be cached locally 18:45
jnthn Yeah, I think control exception is probably the right way, and then find a caching approach. 18:46
We need a caching approach for dynamic variables too, I think. 18:47
TimToady that could be a big speedup in spots
jnthn getdynlex used to be a whopping 5% of the entire CORE.setting compilation time on Moar
TimToady depending on depth of nesting of dynamic scopes 18:48
jnthn It's down to a still-too-high 2.something% now, after I implemented caching of hash coes for strings...
*codes
TimToady well, find some more 20%ers first :)
FROGGS multithreaded NFA evaluation! 19:13
jnthn If you think NFA evaluation is a bottleneck, you didn't read the profile yet :P 19:20
FROGGS hehe 19:22
20:01 jnap joined 20:49 jnap joined
diakopter read what profile 20:59
(did I miss an url?) 21:08
FROGGS there was none
jnthn diakopter: Just meant a profile of CORE.setting compilation 21:10
diakopter do you have a screenshot or xls or something? :)
jnthn 'fraid not...
Just been looking at it in VS
diakopter finally gets to working on the hll profiler again 21:11
diakopter reads kcachegrind.sourceforge.net/html/Ca...ormat.html 21:12
hm, incomplete 21:18
[Coke] jvm still borked. parrot now in the lead, followed by moar. 21:19
s/still/re-/
diakopter jnthn: should all the profiling options be configure-time, or just 1 configure-time and most others invoke time? 21:21
FROGGS [Coke]: I just unborked jvm 21:22
25 minutes ago, to be exact
[Coke] FROGGS++ 21:23
jnthn diakopter: What kind of options do you have in mind?
diakopter: Is the Configure time one you had in mind "build with profiling support"? 21:24
diakopter the default would be to count/time callsites|staticcode tuples and its tree (or graph!), but then optionally also count/time each opcode 21:25
could also count reprops, ish 21:26
yes, one configure-time to enable the profiling checks overall
jnthn The first is probably good enough to get some decent data.
Could per-op be a big slowdown?
(if not in use) 21:27
diakopter yeah, would need to be configure time
jnthn yeah, that was my guess 21:28
well, maybe a if (profiling_ops) at the top of the runloop could be fast enough to have it runtime configurable if you already did a profiling build.
diakopter well, rebuild is plenty fast :P 21:29
esp if you don't change any .h 21:30
jnthn aye
Aside from the link time opts...
diakopter well, or .c :)
my idea was to use averaging to summarize >1000 invocations, while still retaining the 2% of outliers on both ends, to avoid huge data explosion of the timings 21:32
21:33 Mouq joined
diakopter that assumes single-hump distribution though, so there should also be an option to allow the data to asplode :D 21:34
jnthn: does that seem sane? 21:36
jnthn diakopter: Seems like you're better at statistics than me :) 21:37
diakopter: It *sounds* sane but I'm pretty bad at knowing what's reasonable when it comes to these things :)
diakopter maybe a smart bucketing system would be better 21:38
it's just I HATE that visual studio uses like 500MB of disk per second to profile. 21:40
an instrumented build I mean
I mean, seriously. 21:41
FROGGS SSD ftw
diakopter yeah but it also adds 10-20x slowdown overhead to do so. so a 4-second program run takes 30GB 21:42
(an otherwise 4-second program, I mean)
that's with an SSD. 21:43
FROGGS yeah, I know what you mean 21:47
and then you actually have a problem to read in these 30gig, especially on windows
diakopter a sampling build/profile is much more efficient, but far less precise and informative
jnthn I've found them quite informative. 21:48
Agree they can't get the precision to the same level, though otoh they are less invasive...
diakopter could also trivially have it annotate a --dump output with the timings also, optionally, so once you're looking at the kcachegrind visualization, you can refer back to the dumped assembly view to see what each callsite called and its timings 21:50
for that matter... could intersperse the original source code into the assembly view :) or vice versa. 21:53
"hmm, this 1 line of Perl 6 code created 46 static code frames and 9973 moarvm opcode instructions..." 21:54
"that's a lot of inline/implied closures!" 21:55
FROGGS O.o 21:56
jnthn Ooh, a 301s spectest. That's a new record... 22:38
22:38 FROGGS joined
[Coke] S05-mass ? 22:40
jnthn [Coke]: ? 22:41
Does dir.t work for anybody at all? 22:43
I think I've heard folks say it does, so I guess the explosion I'm seeing is just on Windows.
22:45 FROGGS joined
jnthn nqp-m: my $h := nqp::opendir('.'); say(nqp::nextfiledir($h)) 22:46
camelia nqp-moarvm: OUTPUT«.lesshst␤»
jnthn nqp-j: my $h := nqp::opendir('.'); say(nqp::nextfiledir($h))
camelia nqp-jvm: OUTPUT«./.lesshst␤»
dalek arVM: 8286436 | jnthn++ | src/io/dirops.c:
At least somewhat unbust dir on Windows.
 23:00
diakopter 500 error on github.com/perl6/nqp/commits/master 23:14
500 error on all the things 23:15
timotimo secmoar now forks a new moarvm, runs code in it and then fails waiting on it because the forked moarvm thinks its stdin wasn't initialised 23:30
diakopter TimToady had a trick to fix that 23:33
timotimo i think the handles are being overwritten, but i actually hacked a check in there :\ 23:42
i made a very dumb mistake to cause this 23:58
jnthn just made one of those too :) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!