00:02 zakharyas joined 00:04 yoleaux2 joined
timotimo i'm getting super tired super fast 00:06
maybe i'll sign out soon 00:09
samcv kk
timotimo i'm definitely relieved that these frames are actually jitted 00:10
have you had a chance to find the spesh output in the log for these inner for loop frames?
samcv no
i can't really tell what's going on in the spesh log
timotimo the graph spesh tool helps you make sense of the superstructure of the BBs 00:11
samcv Of 52159936 specialized or JIT-compiled frames, there were 3216089 deoptimizations (that's 6.17% of all optimized frames).
is that a lot of depopts or normal
so i guess on my computer it takes 16 seconds to sort all the cp. though idk if it was slowed down by doing my str @sorted = %points.keys.sort.... 00:13
the native str type or possibly the array did it too, idk
what would be the fastest way to assign it to something.
i mean obv a scalar but. i know arrays can cause reification right 00:14
timotimo that's all right
arrays will itemize each element at least
i.e. put things into scalar containers 00:15
samcv lol still taking 70.7900297 seconds to run that section of code
timotimo not native arrays of course
samcv was about 79 for me before
timotimo what did you change?
samcv i just did the sorting outside of it
timotimo ah
samcv so didn't gain 16 seconds
but gained like 9
timotimo well, you probably sort more than once all in all 00:16
it has like 70 entries?
samcv no it has hundreds of thousands
i sorted twice at least in that file
i think i may sort in another file
timotimo the tab with the profile in it crshed :)
samcv just say you want to wait 00:17
and it will eventually work
it's just slow
or did it fully crash?
timotimo no, it full on crashed
had to reload
i do know about the telling it to wait, i've used the profiler for a while :P
it does that for almost all workloads ;( 00:18
there's a qt/c++ program that can interpret the json output from the profiler, but it's feature-incomplete
and what's even worse is that the json parser it uses refuses to load files above a random size
which we routinely surpass
but it'd probably make more sense to base a gui on the SQL output instead 00:19
what i meant with "like 70 entries" is the sort
MERGESORT-REIFIED-LIST-AS
i see a sort with 14 entries, one with 205 entries, one with 106 and another with 8 00:20
so more than i thought, but not as many as you said, so you were looking at something else?
timotimo relocates closer to bed 00:21
any questions before i dip into dreamland? 00:37
samcv let me read 00:38
oh some of the sorts are sorting things of not very many elements 00:39
though some of the modules do some sort which i can remedy
no that's it i think, you can sleep 00:40
timotimo have you calculated how many msec per entry the for loops take? 00:41
samcv which ones, the point index ones
with the stuff i took out of the other sub?
i have not
timotimo that'd interest me 00:43
samcv how do i find that
timotimo just a rough estimate would be enough
samcv let me see 00:44
timotimo just opening the profile again myself 00:45
so, the inner loop, right?
m: say "spent 20136
camelia rakudo-moar b51a55: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Unable to parse expression in double quotes; couldn't find final '"' ā¤at <tmp>:1ā¤------> say "spent 20136ā<EOL>ā¤ expecting any of:ā¤ argument listā¤ double quotesā¤ ā€¦Ā»
timotimo durrr 00:46
m: say "spent { 20136 / 29792280 }ms per iteration"
camelia rakudo-moar b51a55: OUTPUTĀ«spent 0.00067588ms per iterationā¤Ā»
samcv i haven't pushed the latest changes in removing the sort
computing now
Finished computing all rows, took 67.3072336 for 354670 elems. Now creating the final unduplicated version. 00:48
so 0.0001889s per iteration 00:49
timotimo so, i notice method Bool is taking up a surprising amount of time
samcv 0.188908 ms
would this call bool nqp::if(nqp::atkey(points-point, $prop), '1', '0') 00:50
that would hold a boolean value
points-point{$prop} = True/False
also what is calling the Bool 00:51
timotimo oh, there's definitely a bool object in there?
samcv yes it's either True or false 00:52
should i change it to nqp::atkey(points-point, $prop) ?? '1' !! '0'
timotimo maybe try =:= True 00:53
the profile crashed again :\
samcv but what if it's set to 1 on accident 00:54
lol.
then it wouldn't give the right value
timotimo do you call &so or prefix:<?> or prefix:<!> or something somewhere hot?
samcv no
i don't think
timotimo hmm
anyway, the spesh for the innermost loop looks okay
there's some lexical lookups that might be expensive perhaps? 00:55
and of course the always-beloved setlex a lexical and then immediately getlex it again 00:56
samcv timotimo, check it out again
and get my latest changes
s/check out/pull
timotimo right 00:57
now it bites us in the butt that we don't generate a map for perf and friends to understand 00:58
so they can't introspect our jitted code at all :(
otherwise we could figure out what pieces of the jitted code are hot and what pieces are not so hot 00:59
is atkey2 small? it gets called every time, and calling stuff can be costly 01:01
perhaps you can inline it manually and see if that helps?
samcv it just calls atkey( atkey( ))
is in now inlining it?
let me try putting it back to how i had it before 01:03
timotimo if it's so small, it's probably costly to call it each time 01:04
let me run it again to see if it gets inlined 01:05
i'm not sure why it would do that now as compared to before, though? did you change something inside the inner loop?
samcv ok it may make it 2s faster
no
timotimo how do you figure?
samcv it went from 67s to 65s 01:06
timotimo oh
samcv when i put back the code i previously removed
timotimo well, that's underwhelming
samcv yeah
timotimo oh, those are the comments all over the place?
samcv yea
782
timotimo, just pushed it with the code as it was week ago or so 01:07
timotimo i'm not sure i understand how that can be equivalent to the code below it?
samcv see changes in the last commit
timotimo you could try what happens if you turn the for loop into a while loop and manually shifting the array (need to clone) or an iterator over it (don't need to clone) 01:09
because then we might have the chance that the inner loop gets inlined into the outer loop
getting rid of a few million frame invocations
samcv both for loops into while loops? 01:10
timotimo and then see if you can get it to stash the object reference to these lexicals you defined at the beginning of the sub into the inner loop
try only the inner one first
samcv ok
timotimo i'll go sleep for reals now :) 01:11
good luck!
samcv night
timotimo, should i use an actual iterator object?
timotimo night
samcv or just like a c for loop or something
except in perl 6 obv
timotimo i was thinking nqp::iterator over the $!reified of the array 01:12
see the core setting for how to cheat the $!reified out of an Array/List object
samcv in $!reified
err
src/core/Rakudo/Iterator.pm
timotimo but doing a c-style for loop and atpos might also be worth a try
a loop loop 01:13
samcv yeah
nqp::getattr(list,List,'$!reified')
like that?
timotimo actually ... you can use a normal rakudo iterator and .pull-one
that's how
samcv @array.iterator?
doesn't that automatically happen with a for loop? 01:14
timotimo i ... think so
i never had to do this
yes, but the for loop ends up calling the sub you give it a bunch of times
samcv what is the 'that's how' refering to. your message the line previous?
or what i asked
timotimo the getattr code
samcv ok
timotimo that's what i meant
samcv kk
timotimo anyway, with a while loop we may have the inner block embedded directly into the outer block and only a thin piece of code before and after to make the looping happen
rather than having to have sink-all call the sub every time 01:15
samcv so do i need to get an iterator each time?
for each cp?
nqp::getattr(list,List,'$!reified') i mean
timotimo 'fraid so
how many times does the inner loop run per codepoint?
samcv like 01:16
20
timotimo oh
for some reason i had thought it'd be more often
samcv well more than 20
depends how many props you are building
may be 35tm not 100% sure
timotimo in that case you'd probably have to turn the outer loop into such a while loop, too
and yeah, there'd have to be a new iterator every time
samcv and so how do i get the next thing out of the iterator? 01:17
do i use nqp or perl 6
timotimo for the iterator class you linked to in Iterator.pm, you'd use .pull-one until it returns IterationEnd
samcv my $iter = nqp::getattr(@list,List,'$!reified'); so that i need the pull one
ok
timotimo you could look at the implementation of .sink-all and friends
with $!reified, you'll get a low-level nqp list 01:18
samcv oh ok
so i need to use nqp. i can do that
timotimo with @list.iterator you'd get the thing with .pull-one and such
samcv ok
timotimo you have a choice between nqp and perl6 stuff here
samcv nqp sounds fine
timotimo OK
i'll leave now, otherwise i'd end up staying up all night 01:19
samcv night
timotimo o/
samcv uh how do i tell if iterator has more
with nqp::elems? or? 01:20
if this went properly it took 46 instead of 60 seconds making the inner loop a while loop 01:36
cloning the iterator for each cp
nice it did work fine 01:37
30% speedup. not too shabby
01:42 lizmat joined 01:45 MasterDuke joined
samcv nice now at 38 instead of 46 01:49
MasterDuke nice. you figured out how to use nqp::iterator i assume? 01:50
samcv nope 01:51
but sorta i suppose
i had to change it from my str @blah; to just @blah though
not sure how to iterate a native array
maybe have to clone the object and then shift it
not sure if that will be faster
but i can try
MasterDuke nqp: my $l =: nqp::list("ab", "cd"); my $i := nqp::iterator($l); while $i { say(nqp::shift($i)) } 01:52
camelia nqp-moarvm: OUTPUTĀ«Assignment ("=") not supported in NQP, use ":=" instead at line 2, near ": nqp::lis"ā¤ at gen/moar/stage2/NQPHLL.nqp:765 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:panic)ā¤ from <unknown>:1 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/nqp.moaā€¦Ā»
MasterDuke nqp: my $l := nqp::list("ab", "cd"); my $i := nqp::iterator($l); while $i { say(nqp::shift($i)) }
camelia nqp-moarvm: OUTPUTĀ«abā¤cdā¤Ā»
samcv let me try a native array and cloning the whole array instead of cloning the iterator 01:53
m: my str @array = 'test', '123'; use nqp; say nqp::iterator(@array)
camelia rakudo-moar b51a55: OUTPUTĀ«Cannot find method 'gist': no method cache and no .^find_methodā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv m: my str @array = 'test', '123'; use nqp; my $item := nqp::iterator(@array); say nqp::elems($item)
camelia rakudo-moar b51a55: OUTPUTĀ«This representation (VMIter) does not support elems (for type BOOTIter)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv vmiter isn't in nqp docs 01:54
m: my str @array = 'test', '123'; use nqp; my $item := nqp::clone(@array); say nqp::elems($item) 01:56
camelia rakudo-moar b51a55: OUTPUTĀ«2ā¤Ā»
MasterDuke m: my @array = "test", "123"; use nqp; my $item := nqp::iterator(nqp::getattr(@array,List,q|$!reified|)); nqp::while($item, say(nqp::shift($item))) 01:58
camelia rakudo-moar b51a55: OUTPUTĀ«testā¤123ā¤Ā»
samcv so i'll see which is faster
cause i pulled out the nqp iterator and cloned that every time
i will compare to cloning the native array and shifting that instead of shifting the iterator
(not calling getattr each time, only calling it once and cloning the object that returned) 01:59
MasterDuke you're comparing against atpos? 02:00
samcv no 02:01
comparing against using nqp iterator
shifting the iterator each time
m: my str @array = 'test', '123'; use nqp; my $item := nqp::clone(@array); say nqp::shaft($item) 02:03
camelia rakudo-moar b51a55: OUTPUTĀ«===SORRY!===ā¤No registered operation handler for 'shaft'ā¤Ā»
samcv m: my str @array = 'test', '123'; use nqp; my $item := nqp::clone(@array); say nqp::shift($item)
camelia rakudo-moar b51a55: OUTPUTĀ«MVMArray: shift expected string registerā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv argh
m: my str @array = 'test', '123'; use nqp; my $item := nqp::clone(@array); say nqp::shift(@array)
camelia rakudo-moar b51a55: OUTPUTĀ«MVMArray: shift expected string registerā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv m: my str @array = 'test', '123'; use nqp; my $item := nqp::clone(@array); say nqp::shift_s(@array) 02:04
camelia rakudo-moar b51a55: OUTPUTĀ«testā¤Ā»
samcv \o/
MasterDuke do you want to shift @array or $item? 02:07
samcv well item, since i'm cloning it 02:08
but it works fine for $item
ok not sure if it's faster using a native array or not
well it maybe it's 41s now, maybe it was 45 before, not sure
ok 38.44655769 before. so doesn't seem to make it faster 02:11
slower and or it's just being different between runs 02:12
MasterDuke oh well 02:13
samcv but i clone the nqp iterator so that probbaly pretty fast
38 instead of 73 is good 02:14
MasterDuke almost half
samcv yep :)
02:49 ilbot3 joined 03:04 zostay_ joined 03:06 avarab joined 03:08 geekosaur joined 03:19 MasterDuke joined 03:50 agentzh joined
samcv not sure why but my program goes from 42 to like 60 seconds if i change from a perl 6 while loop to a nqp while loop 06:25
all the code inside the while loop is nqp
maybe it's not getting JIT'd hmm
or maybe something else 06:26
wow i'm down to 166 seconds 06:30
for a build without the names 06:31
06:40 brrt joined 07:13 stmuk_ joined
Geth MoarVM/even-moar-jit: 4e857e9690 | (Bart Wiegmans)++ | 2 files
Refactor spill_register

Because it is also necessary to be able to spill a specific register (rather than just any), I need to reuse the logic for spilling a live range, which has been extracted. The logic to find a spillable position and to select the 'optimal' live range for spilling has also been split out because they can develop independently.		 07:23
brrt next up; indirect-mode two-ref fixing 07:25
07:48 brrt joined
brrt good *, by the way :-) 07:58
samcv good ( 08:01
err *
brrt :-) 08:02
jnthn morning o/ 09:57
brrt moarning jnthn 10:00
timotimo o/ 10:01
dogbert11 o/ 10:02
timotimo i'm really glad the iterator and while-loop suggestion gave good results
dogbert11 jnthn: so what's on the agenda today? 10:03
jnthn Well, at the moment just looking over recent RT tickets to see if any particularly merit my attention :) 10:04
samcv morning 10:05
jnthn o/
samcv me too timotimo
for some reason the perl 6 while loop is fairly faster than nqp while loop
timotimo that's weird indeed
samcv and that's changing nothing at all except turning while nqp::elems($iter) into nqp::while(nqp::elems($iter 10:06
yeah
timotimo i could compare the spesh logs 10:08
a more proper spesh diff tool would really be nice to have *cough*
i pulled and the outer loop is still a for loop 10:10
brrt perl6s 'blocks are function calls' dogma is really costly in loops 10:11
timotimo just backlogging right now, samcv, you said todd could /{3 - 2}/, and that "it evaluates to True" 10:12
samcv uh. i didn't say that
timotimo but raw code blocks in regex have no effect on the matching by themselves; you'd need <?{ }> or <!{ }> for that
oh? let me re-read 10:13
samcv i was giving an example of how it evalutes things
ah ok
well i was pointing out bracketns in perl 6 cause the code in it to be executed
dogbert11 jnthn, timotimo: apart from MVM_string_repeat the function collapse_strands is used here as well github.com/MoarVM/MoarVM/blob/mast...ops.c#L397 10:14
do you see any dangers therein?
jnthn Will take a look soon :) 10:15
timotimo no danger there, AFAICT
dogbert11 timotimo: sounds promising 10:16
timotimo i'm surprised nobody suggested .contains($Thingie) rather than ~~ /$Thingie/ 10:17
jnthn I think it's codepaths with allocate_strands that want a close look
timotimo the difference in speed should be about a gazillion times
all 6 occurrences of allocate_strands look safe upon first glance 10:20
samcv gazillion 10:21
timotimo in scientific terms, yes
jnthn Been through all the allocate_strands also 10:24
timotimo i don't really know how to do it, but at some point a regex like that should definitely be compiled to just compile to .contains
dogbert11 and hopefully samcv hasn't stumbled on any more nasty bugs .. 10:26
samcv heh
not yet
Geth MoarVM: 7b2e3d943c | (Jonathan Worthington)++ | src/strings/ops.c
Factor out repeated code.
jnthn Currently trying to figure out rt.perl.org/Ticket/Display.html?id=130692 fwiw 10:27
Ah. Argh. 10:31
Wondered how soon we'd run into this fun...
timotimo uh oh
jnthn The basic problem is that various things in Supply internals use locks 10:54
Which isn't automatically a problem.
But when we do an await somewhere in such a call stack, the lock "moves" 10:55
To another thread on resume
timotimo oh, and our locks are re-entrant
jnthn Right
timotimo and so when a different thread resumes and unlocks, it thinks that one doesn't own the lock
and explosion happens
jnthn Yup
timotimo but we also can't just unlock when we continuation outwards 10:56
jnthn MoarVM catches that, so no overly bad explosion at VM level
Right
timotimo so ... we need something "more" than reentrant
where the owner isn't just GetCurrentThread, but ... GetOwnerObject
jnthn Well, the immediate fix is to install an awaiter in Lock.protect
That forces a real blocking
timotimo OK, so when you're holding a lock, you can't actually switch ot another thread 10:57
right
jnthn Thing is, that'll hurt anyone who does reasonable things like an await in a supply block 10:58
timotimo aye, that's not so great
jnthn We kinda need a Lock::Awaitable
dogbert11 sounds difficult
timotimo can the awaiter that belongs to the lock semi-undo the lock (like, set a regular variable to 1, unlock the lock) and then await via the outer awaiter?
jnthn timotimo: Not sure that's a too good idea 10:59
A Lock::Awaitable basically would work like:
timotimo yeah, i see some problems with it already
jnthn await $alock.lock();
Which will either complete immediately if you get it 11:00
Or suspend you until you can have it
(In a pool-efficient way) 11:01
timotimo right
samcv that sounds great 11:02
jnthn We might also want to replace the mechanism in supply/react blocks with this
As I'm not entirely happy with the contention handling there at the moment 11:03
If we have two producers
timotimo we need punny names for our inspection tools. i suggest "Inspeshtor Gadjit" 11:04
jnthn And the supply block has tapped them both
When the first will emit a value
Then it notes the fact it's "working" in the supply block by putting itself onto a queue and then running itself 11:05
Well, running the code in the appropriate whenever
timotimo that's the current implementation, right?
jnthn Yes
If the second supply then emits a value while the first is being processed, then it sees it can't process it now
timotimo ISTR how it does the queueing its own work stuff
jnthn So it just sticks it into the queue and goes on its own way
timotimo so the queue can grow pretty big, yeah? 11:06
jnthn When the first emitter is done, it sees new work arrived and decides to help out with it
timotimo that's something that you'd call "backpressure", or a lack thereof?
jnthn So yeah, there's two things here
First, there's no backpressure on the second emitter. Depending on the nature of it we might not get any anyway of course.
timotimo oh, so when you emit, you might end up with your emitting thread doing work for hours before it can on its own resume
jnthn But also, yes, you might end up doing a lot more work than you expected 11:07
I mean, it's implicit that emit is a blocking operation for the sender
But it might be surprising that you end up doing somebody elses work too :)
timotimo right
on your thread, no less
jnthn Yup
timotimo but we don't really offer thread local storage
jnthn Before we used real locks
timotimo except maybe when you nativecall
jnthn But that ran into a deadlock in some cases 11:08
5f1249e843b in Rakudo did that change fwiw 11:10
Also pondering rt.perl.org/Ticket/Display.html?id=130716 in this 11:12
timotimo ah, that one 11:13
jnthn Thing is, the way to do cleanup is a CLOSE block 11:22
Except we never get change to run it, because the supply block's main body is always holding the "lock", as it were 11:23
timotimo: Did your last/redo in whenever stuff get merged? 11:38
Geth MoarVM: 5538029892 | (Daniel Green)++ | src/strings/ops.c
Del unused var, don't call MVM_string_graphs twice
 11:40
MoarVM: 542baec756 | (Jonathan Worthington)++ | src/strings/ops.c
Merge pull request #537 from MasterDuke17/minor_optimization_to_MVM_string_indexing_optimized

Minor optimization to MVM_string_indexing_optimized
jnthn Ah, no, it wasn't 11:43
samcv do we need to flush stdout to proc async? 11:47
jnthn samcv: What are you observing that's making you ask? 11:49
samcv gist.github.com/7bbb850655bcc3fa27...46a911b4a6
i'm getting Broken from this
dogbert11 timotimo, jnthn: is this gist 'informative' or is a case of 'something was clobbered at an earlier stage'? gist.github.com/dogbert17/d3d73521...968eb135a9 11:50
samcv broken for the call to .print
jnthn The :r isn't needed (and ignored) fwiw
samcv maybe it's the tap not working 11:52
jnthn "This process is not opened for write"...huh
Wait, does echo even accept stuff on stdin? 11:54
echo foo | echo at the shell does nothing
Except print an empty line
samcv oh
yeah it seems to work with cat
but not with my program hmm 11:55
jnthn Was gonna say, :w can't be entirley busted 'cus I'm using it in $dayjob code running dozens of times a day
samcv i'm using scanf also tried gets 11:56
and it doesn't respond back. but running from terminal is fine
can it not do relative paths? though i'd think it'd give an error- 11:57
not getting stdout even when i make it show a message on starting it 11:58
this should work right my $proc = Proc::Async.new('./build/bitfield', :w, :r);
jnthn The :r is redundant as mentioned earlier
samcv yeah but that changes nothing
jnthn Otherwise, don't see anthing wrong there
*anything
samcv wtf 11:59
jnthn lunch; bbi30 12:10
samcv i gotta go to bed. night all 12:12
moritz \o
jnthn back 12:37
dogbert11 jnthn: was the gist crap, i.e. should I valgrind/ASAN the code? 12:49
jnthn dogbert11: No, it makes sense 13:15
I know how to fix that one :)
dogbert11: What code is it from, ooc? 13:17
Something small enough we can add it as a spectest?
Currently looking at a fragility in Supplier::Preserving 13:19
dogbert11 jnthn: MoarVM #458 and RT #128833 13:24
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128833
dogbert11 I believe that the RT bug was two problems from the beginning but you fixed the first some time ago 13:26
it's still a bit difficult to reproduce (for me that is) however it became easier when I learned how to autmatically (re)run a program in gdb until it crashes 13:27
jnthn :) 13:34
Yay, I think I've fixed the Supplier::Preserving bug 13:50
Language lesson now
Will turn that into a spectest, then have a reliable fix for japhb++
bbi1h
dogbert11 .oO 14:35
14:44 Ven joined 15:33 japhb joined
jnthn m: gist.github.com/jnthn/a4b1dee67863...3e4cd5c5c8 15:39
camelia rakudo-moar b51a55: OUTPUTĀ«not ok 1 - Received expected messages (0)ā¤ā¤# Failed test 'Received expected messages (0)'ā¤# at <tmp> line 25ā¤# expected: '1 2 3 4 5'ā¤# got: '35'ā¤not ok 2 - Received expected messages (1)ā¤ā¤# Failed test 'Received expected messages (1)'ā€¦Ā»
timotimo you mixed tabs and spaces! ;) 15:43
jnthn wat? 15:53
*sigh* 15:54
Why can't everyone just use spaces :P
And why does /\t in vim not find them
Oh, :retab I guess should sort it out 15:55
timotimo :set tabexpand or :set notabexpand 16:21
16:35 japhb joined
jnthn timotimo: I think if you have :set paste, those don't deal with it? 16:39
timotimo if you have :set paste, it won't do anything at all, IIUC 16:40
so if you're pasting something with tabs, you'll get tab characters
even if you :set tabe 16:41
no, it's expandtab
:set et
jnthn Yeah, that's what I did
So original musta had tabs :)
timotimo likely 16:42
jnthn tests a fix for the issue dogbert11++ golfed/gisted earlier today 16:58
Well, best I can, anyway
Got it running in a loop in gdb
Geth MoarVM/even-moar-jit: f7aef159f7 | (Bart Wiegmans)++ | 2 files
Special case handling of ARGLIST

ARGLIST can create more references than can fit in the register set and register assignment to an ARGLIST reference will not work. So special-case those.		 16:59
timotimo one more step towards function calls! 17:00
jnthn \o/ 17:01
dogbert11: I pushed the fix for the thing you gisted earlier; feel free to give it a try out 17:16
m: for ^10 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 } 17:18
camelia ( no output )
jnthn m: for ^100 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia rakudo-moar cf500e: OUTPUTĀ«(signal )Ā»
jnthn aha 17:19
but...which signal...
m: for ^100 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia ( no output )
jnthn m: for ^100 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia ( no output )
jnthn m: for ^100 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia rakudo-moar cf500e: OUTPUTĀ«(signal )Ā»
dogbert17 jnthn: will test
jnthn OK, not just resoruce consumption
dogbert17: Could you try out the thing I just sent to the evalbot on a build without it?
without the fix, that is 17:20
commitable: 2017.01 for ^100 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
ah, not here
dogbert17 ok
SEGV 17:21
jnthn Seems that it'll be a decent test to cover it though
Nice :)
timotimo i can ask them to get the *able bots in here
dogbert17 so you got it, impressive
timotimo also, we could try to figure out why camelia doesn't understand what signal that is
dogbert17 SEGV seems to be in the same place as the original bug 17:22
================================================================= 17:23
==12090== ERROR: AddressSanitizer: heap-use-after-free on address 0x90f14fdc at pc 0xb6061c56 bp 0x9c2dd828 sp 0x9c2dd81c
READ of size 4 at 0x90f14fdc thread T16
#0 0xb6061c55 in bind_key /home/dogbert/repos/rakudo/nqp/MoarVM/src/6model/reprs/MVMHash.c:98
jnthn cool 17:26
dogbert17 jnthn: that means that you can close at least one RT and a MoarVM issue
jnthn You got the IDs of those two handy? 17:29
dogbert17 MoarVM #458 and RT #128833
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128833
dogbert17 it seem as if this wasn't a bug in MoarVM after all 17:30
timotimo the "bug" is that hashes aren't threadsafe
jnthn We shouldn't SEGV, but yeah, code assuming they are threadsafe is wrong 17:31
timotimo jnthn: got a better place to put the vmhealth implementation than moar.c?
jnthn Add a new file for it, perhaps? 17:32
timotimo ugh, so much work :)
dogbert17 :) 17:33
there are now only ~30 RT tickets marked SEGV. I don't think all of them are valid anymore 17:34
jnthn RT closed 17:35
dogbert17 cool
should I close the MoarVM one then? 17:36
jnthn Just did ;0
dogbert17 :) 17:37
timotimo turns "number of threads" into "number of threads in each state"
mst timotimo: and make sure you give texas extra 17:38
jnthn Uff, tired...guess I'll have to save the next issues I want to look into until tomorrow
timotimo of course
dogbert17 maybe it's time for dinner?
jnthn Something like that :) 17:39
dogbert17 should MoarVM be bumped or should we wait until after this months release?
timotimo it gets bumped for the release anyway 17:43
at least we've done it like that forever
if we didn't want something for "in" the release, we'd put it into a branch for the time being
17:44 camelia joined
jnthn Odd, rt.perl.org/Ticket/Display.html?id=130690 notes that it's sensitive to MVM_SPESH_DISABLE 17:45
Oh...was about to say it seems to go away under just MVM_JIT_DISABLE, but it showed up just after I was gonna write it :P 17:46
IOninja m: for ^400 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia ( no output )
IOninja m: for ^400 { my \g = EVAL 'grammar { token TOP { <a> | <b> }; token a { \d | \s }; token b { a | b } }'; await (start g.parse('b')) xx 8 }
camelia ( no output )
IOninja m: use NativeCall; sub raise(int32) is native { * }; raise 11 17:47
camelia rakudo-moar 62bd30: OUTPUTĀ«(signal SEGV)Ā»
IOninja There. Fixed forever.
jnthn IOninja++
timotimo i'm also going to want to give out the number of threads marked as "blocked for gc", right? for vmhealth, i mean
jnthn Could do, yeah 17:48
OK, will continue with this bug tomorrow... 17:49
Rest; bbiab
timotimo good rest!
18:17 Geth joined 18:20 ggoebel joined
timotimo i'm not sure if i should be polling the GC Status for threads that aren't in stage 3 (running iirc) 19:06
20:14 agentzh joined 20:21 agentzh joined
jnthn timotimo: At some point they cease to have a ->tc 20:27
timotimo it'll get nulled out properly, though? 20:28
jnthn Yes 20:33
dogbert17 should this snippet recurse infinitely? class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy
timotimo has seen this before :)
if it should recurse/hang then we should be able to close github.com/MoarVM/MoarVM/issues/412 since jnthn has fixed the callsame bug which caused it to crash 20:35
jnthn m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy
camelia rakudo-moar a62882: OUTPUTĀ«(timeout)Ā» 20:36
jnthn m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".WHAT 20:37
camelia rakudo-moar a62882: OUTPUTĀ«(Str)ā¤Ā»
jnthn m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy.WHAT
camelia rakudo-moar a62882: OUTPUTĀ«(SQLString)ā¤Ā»
jnthn m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy.Str
camelia rakudo-moar a62882: OUTPUTĀ«SQLString<59372912>ā¤Ā»
jnthn m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy.gist
hah
Well, I guess .gist calls .Stringy on something 20:38
camelia rakudo-moar a62882: OUTPUTĀ«(timeout)Ā»
jnthn Which is reasonable I guess
dogbert17 and the SEGV is gone 20:39
jnthn Wrapping Str.Stringy probably counts as playing with fire
If the SEGV is gone then it's certinaly not a moar bug any more :)
dogbert17 but I can't close it, perhaps nine should do that 20:40
jnthn I think I'd need more persuading that it's a Rakudo bug
I mean, for starters SQLString doesn't even do the Stringy role
dogbert17 I'm not going to try to do that :) 20:44
but there are several MoarVM issues open that I believe have been solved already 20:47
timotimo food time \o/ 20:53
dogbert17 kabooom: gist.github.com/dogbert17/c1f9fe86...6422570694 21:48
jnthn Innerestin' 21:51
dogbert17 it's the code from rt.perl.org/Public/Bug/Display.html?id=130494 run with a 64k nursery and GC_DEBUG=1 21:53
jnthn wonders where this bug will end up being 22:03
It's...odd
It almost looks like a double-release of an object
Or double-gc_free of it
Phew, nearly got my grant report done 22:10
dogbert17 I have the strand and gc-fixes in 'my' moarvm, do you think thay might be involved in which case I can remove them 22:21
22:34 MasterDuke joined
timotimo i wonder if there's any circumstances where we share decodestream across objects 22:34
or clone the insides of a decodestream?
i.e. the pointer there
MasterDuke timotimo: have you seen this? is it a legit problem? gist.github.com/MasterDuke17/5f071...0f388b51d4 22:37
timotimo probably no problem 22:45
it happens basically every single time we precomp 22:46
MasterDuke causes the test to fail 22:47
to be more precise, the test fails occasionally. when i run it in valgrind, i get that output occasionally, i assumed they were related
timotimo oh? 22:48
maybe i should look closely into it
what do i have to run to get that exact one, MasterDuke 23:13
oh
there it is
for those all the "program did not hang" tests all fail all the time 23:24
is that because of valgrind slowing things down? 23:25
i think you can only get that error if you have precompilation happening 23:27
and it's potentially not important what process you're running as long as there's some precomp 23:31
ah, interesting 23:32
(i said interesting because i looked at the right line in a different file) 23:34
i don't get it. i changed the offending allocation to calloc and it still says uninitialized memory? 23:38
maybe it's memcpying some uninitialized bytes into it or something
it seems to be inside the serialized blob 23:41

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!