Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-01-03

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

All times shown according to UTC.

Time Nick Message
00:31 colomon_ joined #moarvm
01:33 samcv jnthn, you still awake?
01:34 samcv anyway. so i just made a script to automate downloading all the unicode files and extracting them properly
01:34 samcv had to have it check the Emoji readme's to find out if it's a draft or not though, since they don't have a 'latest' directory, but shouldn't be a problem
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:21 pyrimidine joined #moarvm
03:28 japhb .tell jnthn Oh man, that's even weirder than I expected.  Thank you for the bug hunting.  :-)
03:28 yoleaux2 japhb: I'll pass your message to jnthn.
03:35 pyrimidine joined #moarvm
03:35 ChanServ joined #moarvm
03:35 JimmyZ joined #moarvm
03:35 Util joined #moarvm
03:35 jnthn joined #moarvm
03:35 moritz joined #moarvm
03:35 masak joined #moarvm
03:35 harrow joined #moarvm
03:35 BinGOs joined #moarvm
03:35 zostay joined #moarvm
03:35 konobi_ joined #moarvm
03:35 mtj_ joined #moarvm
03:35 nwc10 joined #moarvm
03:35 yoleaux2 joined #moarvm
03:35 sivoais joined #moarvm
03:35 SmokeMachine joined #moarvm
03:35 japhb joined #moarvm
03:35 btyler joined #moarvm
03:35 samcv joined #moarvm
03:35 psch joined #moarvm
03:35 [Coke] joined #moarvm
03:35 leedo_ joined #moarvm
03:35 stmuk joined #moarvm
03:35 hoelzro joined #moarvm
03:35 avar joined #moarvm
03:35 timotimo joined #moarvm
03:35 geekosaur joined #moarvm
03:35 ggoebel joined #moarvm
03:35 notviki joined #moarvm
03:35 nebuchadnezzar joined #moarvm
03:35 diakopter joined #moarvm
03:35 nine joined #moarvm
03:35 camelia joined #moarvm
03:35 mst joined #moarvm
03:35 synopsebot6 joined #moarvm
03:35 dogbert2 joined #moarvm
03:35 Dunearhp joined #moarvm
03:35 leego joined #moarvm
03:35 tbrowder joined #moarvm
03:35 lizmat joined #moarvm
03:35 dalek joined #moarvm
03:35 samcv ok i think that's it
03:36 diakopter heh
03:36 samcv oops wrong channel
03:36 diakopter so it was special cased in ucd2c.pl? or I ignored that bidi file or what
03:37 samcv oh regarding the brackets?
03:37 diakopter yeah
03:37 samcv nope it was just in roast and nqp wrong
03:37 samcv wollmers may have added both that and the ornate parens
03:39 samcv oh he just removed spaces. i'm looking at git blame now. so i know who to blame :P
03:40 timotimo ah, there might be a flag that ignores whitespace changes
03:40 samcv uhm it's been in there for a while
03:40 samcv like forever
03:41 timotimo huh.
03:42 samcv Auzon <Auzon@c213334d-75ef-0310-aa23-eaa082d1ae64>
03:42 samcv ok we can blame this person from 2008
03:42 timotimo that must have been before my time. maybe during the pugs time?
03:42 samcv yeah
03:43 samcv git-svn-id: http://svn.pugscode.org/pugs@20873 c213334d-75ef-0310-aa23-eaa082d1ae64
03:43 samcv heh
03:44 samcv i'm sure they were added in without giving it __too__ much thought
03:44 samcv but that is ok. has been corrected :P
03:58 samcv diakopter, do you want to help me to implement key values and property names from both being combined with each other and causing property number conflicts :P
03:59 samcv or at least only putting the script names in the property name keys, instead of EVERYTHING
03:59 samcv which causes conflicts between like LF=space and space=True
03:59 samcv and the Greek block (i think block) an Greek script property
04:07 diakopter samcv: I'm currently enthralled by okay, I found the right thing I need to port from Agda to Lean: http://typetheorypodcast.com/2016/12/episode-6-aaron-stump-on-cedille/ and the prospect of attempting the Herculean (or is it Sisyphean?) task of porting Cedille from Agda to Lean
04:09 samcv interesting
04:09 samcv what's agda
04:10 timotimo a prog lang for dependent typing and proofs and such
04:24 diakopter of course, it would help if Cedille were open-source [yet] 🙄
04:39 samcv diakopter, do yo uthink it would be beneficial to try and derive some of the properties ourself instead of storing it in addition?
04:39 samcv like 'SpacingMark' is true if Grapheme_Cluster_Break == true
04:39 samcv and other such things
04:40 samcv do lookups get cached in anyway? i mean is there any way this helps us, or is it faster to just access the bitfield and reduce the number of operations it has to do
04:43 timotimo the slowest thing a computer can do nowadays is memory access
04:43 timotimo (or so i've been told)
04:47 geekosaur if you s/computer/CPU/ that's not far from the truth
04:47 timotimo oh, right
04:47 timotimo because computers can also do network requests to the ISS :)
04:47 timotimo or bounce signals off of the mirror on the moon
04:48 timotimo what do you think the CPU can do that's slower than main memory access, geekosaur?
04:48 geekosaur (it's an oversimplification, but not much of one. I/O is going to be slow regardless, but is also multistep; accesses to main memory are otherwise the slowest thing a CPU has to deal with.)
04:49 timotimo I/O, fair enough, but we said CPU rather than computer, and most interesting I/O will be handled by north/south bridge? or is that wrong?
04:51 diakopter timotimo: it's a philosophical question, you're right :)
04:51 timotimo hah
04:51 timotimo a question of terminology, clearly
04:52 pyrimidine joined #moarvm
04:52 samcv ok so we should compute it from values we already have?
04:53 timotimo if it's not too much work, yeah i guess so
04:53 samcv kk
04:53 timotimo hm, except if we use the value a whole bunch of times in a row
04:53 samcv but... how does that change it
04:53 timotimo then it'd stay in l1 cache and it might actually be faster to have the right value already available??
04:53 samcv hm
04:54 timotimo i'm quite bad at estimating these things
04:54 geekosaur timotimo, depends. if the bridge did all of it, OSes wuld be a lot smaller
04:54 samcv i'm going to try and make as many things as possible rely on grapheme_cluster_break property
04:54 samcv instead of multiple. so that should be good
04:54 samcv instead of many different ones
04:55 geekosaur but from the POV of a CPU, I/O is generally a bunch of operations on various memory addresses (or possibly Intel I/O ports) which are not actually memory. so CPU sees an even slower than usual memory access
04:55 timotimo right, memory-mapped I/O has basically won
04:56 diakopter well the thing is, if it's computed it would be a separate moar op
04:56 timotimo oh?
04:57 geekosaur because I/O ports are basically worse memory with worse addressability :)
04:57 diakopter well, at least it would add a bunch of checks
04:57 diakopter bunch of branches
04:57 geekosaur the idea of getting I/O out of memory to simplify memory management wasn't necessarily bad, just not fully thought out
04:57 diakopter to the property lookup thing
04:59 timotimo diakopter: i expect that MVM_unicode_get_property_int would gain a bit more code
04:59 timotimo what it currently does is read out the props_bitfield and & it with some bit
05:00 timotimo if the computation for getting it from a different prop is just a little bit more expensive than what we have already, and we can somehow save up a little bit of memory in total, we'll probably end up ahead
05:01 timotimo i wonder how many bits are unused at the end of the last bitfield row
05:01 timotimo and how many bits are unused in each of the rows at the end
05:01 timotimo there's probably nothing much to save there? :(
05:04 diakopter heh
05:04 timotimo and anyway, we have more than enough bottlenecks left everywhere else so we can keep this code a bit simpler for the time being
05:04 timotimo until we find a good benchmark, that is.
05:06 diakopter well, probably you would flag certain properties to divert them to another case/switch if you wanted to make them computed. it'd be a slower path if the compiler didn't inline it.  it's impossible to predict if it would be faster on any given machine for any sort of usage pattern
05:06 timotimo um, are you sure about that?
05:07 diakopter yeah, because who knows how local that code itself would be, whether it's already cached. I mean, are we talking about making the first lookup/computation fast, or a ton of them
05:08 timotimo because the code is already a switch/case and all properties are already "computed"
05:08 timotimo just that the computation is a bit-and and a shift on a piece of storage that's specifically for that property
05:08 samcv i don't think that is the slowest codepath, the should_break thing. not everything seems to be fully optimized since there's get codepoint from grapheme and getcodepointfromgrapheme_full
05:08 timotimo and we'd just look at a different property's storage and interpret it differently
05:09 samcv i think it should be combined into only one function
05:09 timotimo it could be because of the JIT, mind you
05:09 samcv so we don't have to lookup 2x for the full path
05:09 samcv i think we may be able to ignore CCC if we use GCB
05:09 samcv will have to test that though
05:10 timotimo i'm failing to find that with ack, can you tell me what exact name those two functions have?
05:10 diakopter my point is simply that I wouldn't be surprised if it ends up not "faster", even if that could be realistically measured
05:10 samcv just search for should_break
05:10 samcv err let me look up the exact name
05:11 samcv MVM_unicode_normalizer_process_codepoint_full normalize.c
05:11 timotimo no, i meant the getcodepointfromgrapheme and getcodepointfromgrapheme_full
05:12 samcv err doesn't exist. sorry i meant codepoint from grahpeme (whatever its name) calls first MVM_unicode_normalizer_process_codepoint
05:12 samcv which then checks many things, then if it fails passes to MVM_unicode_normalizer_process_codepoint_full
05:12 timotimo ah. we have two of those because the short one is explicitly marked to be inlined
05:12 samcv can we inline both?
05:12 samcv well _one
05:12 timotimo the _full one is a bit big for that
05:12 samcv they're like the same size?
05:13 samcv well. they are a little diff
05:13 * timotimo checks again
05:14 timotimo it's like 2x as big
05:14 samcv yeah
05:14 timotimo nah, 3x
05:14 timotimo (i removed comments for the measurement)
05:15 samcv hold on let me compare it to my branch which passes all unicode 9.0 and saves state. see what i did to it
05:17 samcv https://github.com/MoarVM/MoarVM/compare/master...samcv:Even_Moar_Unicode_9.0#diff-56c5c06fe8e61c2b126dd3c8d29e348e
05:17 samcv so only one change
05:18 timotimo right, doesn't seem to change the lengths
05:18 samcv what's the best way to benchmark this?
05:18 samcv should i just try to process loads of random text?
05:24 timotimo i suppose so?
05:25 timotimo you can use valgrind's callgrind tool to get more precise measurements than timing stuff
05:26 timotimo have you read jnthn's blog posts? he often explains his process of finding stuff and there's been multiple posts about performance improvements,too
05:27 samcv yeah i have, should check where for them, just advent or where else?
05:27 timotimo 6guts.wordpress.com is his blog
05:27 samcv kk
05:29 samcv i'm going to use this repeated 10,000 times in a file https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt
05:29 samcv just for the variety
05:31 samcv and gonna just use a ramdisk for the benchmarks
05:33 samcv such as i'm not sure if going long path is faster if we returned 1 or more for the last iteration (usually an extend glyph)
05:36 samcv yeah inlining seems to be faster, and it's not that long (the non full one)
05:38 timotimo inlining the _full function, too?
05:38 samcv no
05:38 timotimo oh, the non full one
05:39 timotimo i'm confused. i thought that one is already inline?
05:39 samcv just how it was before
05:39 samcv no it is
05:53 timotimo i'll try to get some sleep again, i seem to be hiccup-free right now
05:54 timotimo just as i said that it starts again
06:27 samcv timotimo, do we prefer to pass MVMint32 around? what if it's only internal to moarvm? and would be easy to use a smaller number
06:38 samcv ok seems most of the slowness is caused by the normalizer
06:38 samcv processing huge string it uses 30% of cycles
06:38 samcv well inclusive. exclusive it's 7.1
07:00 samcv strtol is doing 30% of the cpu cycles of MVM_unicode_normalizer_process_codepoint_full :(
07:00 domidumont joined #moarvm
07:00 samcv * decomposition on it;
07:00 samcv :(
07:00 samcv /* Parse hex character code, and then recurse to do any further decomposition on it;
07:03 FROGGS joined #moarvm
07:05 domidumont joined #moarvm
07:15 timotimo aha!
07:16 samcv :\ i knew i put the values as hex codes in ucd2c.pl but i **assumed** that it converted to numbers after it was put in the data structures
07:18 timotimo with regards to passing around MVMint32 and such, it depends on what we do with it. passing arguments and returning values usually goes through registers anyway, so we'll pay the same cost for 8, 16, 32, or (if on 64bit) 64 bit numbers
07:18 samcv ah
07:19 samcv tru
07:19 timotimo got a clue why we might be using hex character codes as strings? perhaps values may be wildly out of range of 64bit for some weird reason?
07:19 samcv because insanity
07:19 * samcv shouts at the heavens
07:20 timotimo if it's just that reason, we might be able to fix it easy-ish
07:20 samcv nothing in ucd2c.pl is easy :(
07:20 samcv it will probably break everything
07:20 samcv (in the script)
07:20 timotimo ;(
07:20 timotimo did we already get it ported to perl6, btw?
07:21 samcv no
07:21 samcv i wish
07:21 samcv i don't know how it allocates bitfields and things at all
07:21 samcv and perl 6 would take so long to process all the text files
07:23 samcv idk could make it a module with Inline::
07:24 samcv at least send perl 6 all the 'object' things. and then maybe will be easier to manipulate it and introspect it. cause it's kinda lame on perl5
07:28 * samcv shakes her head
07:28 samcv $points_by_hex->{$code_str} = $points_by_code->{$code} = $point;
07:28 samcv time for spaghetti
07:28 samcv diakopter, WHY!
07:29 timotimo what's wrong with that, exactly?
07:30 samcv not not that specifically
07:30 samcv just even storing them as hex
07:30 timotimo mhm
08:08 samcv timotimo, at least the decomposition map uses hex digits. hm. if i change it to numbers it'd probably put literally those numbers in the table or something
08:08 samcv and not store them as numbers but i'll look into it
08:08 samcv i expect it to break everything
08:16 zakharyas joined #moarvm
08:33 samcv timotimo, how do you feel about this https://github.com/samcv/MoarVM/compare/more-UCA...samcv:Even_Moar_Unicode_9.0
08:34 samcv my Even_Moar_Unicode_9.0 bracnch that passes 100% of the unicode 9.0 ones
08:35 samcv jnthn didn't really like me using the return value the way i do, but. i don't see any other easy way to do it. i turned the function it turns into the old 'ready' variable a switch and made it inline (i think, it's in a .c file so will that be unable to inline if it's only used in that file?)
08:41 timotimo my brain isn't ready to do any sort of review
08:41 samcv kk
08:41 timotimo i'm suffering from sleep deprivation, and those hiccups that are also preventing me from sleeping are draining my concentration
08:41 samcv i'm sorry you're still having them
08:41 timotimo me, too :(
08:42 timotimo i had a few breaks in the mean time, but when i lie down and then switch from side to on-back or vice versa they come back
08:53 pyrimidi_ joined #moarvm
09:00 dalek MoarVM: 5c03c27 | samcv++ | tools/UCD-download.p6:
09:00 dalek MoarVM: Add a script to download the latest version of all of the Unicode data
09:00 dalek MoarVM:
09:00 dalek MoarVM: Downloads UCD.zip, collation data (allkeys.txt) and emoji-data.txt.
09:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5c03c278b4
09:00 dalek MoarVM: 99d019d | lizmat++ | tools/UCD-download.p6:
09:00 dalek MoarVM: Merge pull request #479 from samcv/UCD-download
09:00 dalek MoarVM:
09:00 dalek MoarVM: Add a script to download the latest version of all of the Unicode data
09:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/99d019dd53
09:14 dalek MoarVM/even-moar-jit: 9a67811 | brrt++ | src/jit/linear_scan.c:
09:14 dalek MoarVM/even-moar-jit: Replace ValueRef array buffer with linked list
09:14 dalek MoarVM/even-moar-jit:
09:14 dalek MoarVM/even-moar-jit: This reduces the need for the second loop in determine_live_ranges.
09:14 dalek MoarVM/even-moar-jit: As a result of the union proces, the reference lists are merged and
09:14 dalek MoarVM/even-moar-jit: flushed in the 'remaining' live range.
09:14 dalek MoarVM/even-moar-jit:
09:14 dalek MoarVM/even-moar-jit: A check in the linear_scan algorithm removes the need for a compaction /
09:14 dalek MoarVM/even-moar-jit: worklist reaping step (although this would also be a valid approach).
09:14 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9a67811b27
09:21 brrt joined #moarvm
09:22 brrt i'm not so happy about the factoring of the live range merge code into the value_sets_union
09:22 yoleaux2 2 Jan 2017 20:11Z <japhb> brrt: Google's philosophy is that baseline SWE (SoftWare Engineer) requirements are the same across all subdisciplines, and then some jobs require additional skills.  But baseline SWE is expected to have algorithms experience, solid coding in at least one language, architectural design skills, and so forth.  Which is why it takes most of a day to interview for it -- and then why we do phone pre-interviews first.  :-)
09:23 brrt googles philosophy is somewhat infamous, and has a known-high false negative rate
09:23 brrt whether that is a problem is another matter entirely
09:28 brrt i should probably add a live_range_merge function
09:30 nwc10 by "false negative" you mean "rejects candidates who would actually have been suitable" ?
09:30 timotimo i think so
09:34 brrt stronger yet: 'candidates who in a later version of themselves would become highly desirable to google'
09:35 brrt stories of that type are spread over the internet
09:59 jnthn morning, #moarvm
09:59 yoleaux2 03:28Z <japhb> jnthn: Oh man, that's even weirder than I expected.  Thank you for the bug hunting.  :-)
10:11 jnthn samcv: https://github.com/MoarVM/MoarVM/pull/477 looks good to me now; anything more you wanted to do pre-merge?
10:11 samcv don't think so. will make a quick visual look over
10:13 jnthn Yeah, I just gave it a look and all the stuff I spotted before seems better and I didn't see any new issues.
10:15 samcv yep good to go
10:15 samcv :)
10:17 brrt morning jnthn
10:17 dalek MoarVM: 9eb6b6e | samcv++ | / (4 files):
10:17 dalek MoarVM: Implement in unicmp_s and checking secondary and tetriary weights
10:17 dalek MoarVM:
10:17 dalek MoarVM:    An issue is also fixed where ucd2c.pl would not add up the total
10:17 dalek MoarVM:    weighting for characters which decompose into multiple characters.
10:17 jnthn samcv++
10:17 nwc10 poor dalek needs a rate limiter
10:17 timotimo jnthn: got some insight into why we have hex strings in there that we immediately turn into ints when we use the corresponding property?
10:18 dalek joined #moarvm
10:18 jnthn Because that's just the way ucd2c.pl was originally implemented
10:18 timotimo right
10:18 samcv :^)
10:18 jnthn And I had more than enough to do with getting a working implementation of NFG to be worrying about such things.
10:19 timotimo samcv found a workload where a whole lot of time is spend in strotl :)
10:19 samcv yep
10:19 timotimo well, a noticable amount at least
10:19 jnthn Yes, well, my implementation aim was "make the code look as much like the spec as possible so I can quickly fix divergences" :)
10:19 jnthn Not "make it run fast"
10:19 samcv 14%
10:19 jnthn I'm sure we can optimize this in many places. :-)
10:20 samcv like not doing string to hex :P
10:20 jnthn Indeed. ;-)
10:20 samcv yeah. jnthn my Even_Moar_Unicode9.0 has some optimizations as well. but so far it seems to not have too much impact
10:20 jnthn When I put that in I was like "urgh, do I have to...eh, ok" :)
10:20 samcv saving the state when iterating
10:20 samcv for the workload i'm testing with about 1/2 ascii 1/2 not
10:20 timotimo 1/2 ascii, 1/2 art :D
10:21 samcv heh
10:21 jnthn ASCII should go pretty fast since I think we don't even look at any props
10:21 samcv well unless it has to backtrack when it sees an extend
10:22 samcv but yeah i think that's probably true
10:22 jnthn Well, I meant two ASCII chars next to each other :)
10:45 dalek MoarVM: fe110d6 | jnthn++ | src/strings/utf8_c8.c:
10:45 dalek MoarVM: Catch some missed invalid sequences in utf8-c8.
10:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fe110d6028
10:48 dogbert2 jnthn: are you fixing bugs today as well?
10:49 jnthn Well, this morning at least :)
10:50 jnthn Going to see if I can figure out https://github.com/jnthn/oo-monitors/issues/9
10:52 nwc10 cool. it's always morning on #moarvm
10:52 dogbert2 a tricky bug it seems
10:54 pyrimidine joined #moarvm
10:58 jnthn dogbert2: Indeed.
11:23 arnsholt joined #moarvm
11:26 arnsholt jnthn: Doesn't that patch for the utf8-c8 bug reject sequences like 0b11100000_10xxxxxx_10xxxxxx?
11:26 arnsholt Or am I misreading it?
11:27 jnthn Well, utf8-c8 doesn't reject anything
11:27 jnthn It just turns things it thinks won't round-trip into synthetics to represent the original bytes
11:27 jnthn Something starting 0b11100000 will surely be rejected though
11:28 jnthn Since there's a shorter encoding, no?
11:28 jnthn The fix I put in *is* an over-estimate of what it needs to make synthetics for though
11:28 arnsholt No, a two-byte sequence only has room for eleven bytes, 110xxxxx_10xxxxxx, whereas the last two bytes of a three byte sequence has room for 12
11:29 arnsholt Yeah
11:29 jnthn We'd need to keep a bit more state otherwise
11:29 arnsholt But you're right; it'll overgenerate synthetics, but round-trip correctly nonetheless
11:30 jnthn Indeed. We can surely fix the over-generation too at some point.
11:30 jnthn But the failure to round-trip was my main worry
11:30 arnsholt Yeah, that's definitely worse
11:30 jnthn If you're interested enough, feel free to patch it :)
11:30 arnsholt Yeah, I'll see if I can't carve out some time to fiddle with it
11:30 jnthn Well, and time-endowed enough :)
11:31 arnsholt I think the only added state is another int of how long the sequence we read is, and checking that the codepoint isn't too narrow
11:31 jnthn *nod*
11:32 arnsholt And then the logic to explode the codepoint back into "UTF-8" to insert as bad bytes
11:32 jnthn I'd also kinda like to try and factor the remaining bit of commonality out of the streaming/non-streaming case at some point.
11:32 jnthn It already keeps track of the bytes
11:32 arnsholt I actually implemented some limited UTF-8 decoding for $work not too long ago. Maybe I'll give that a whack at the same time
11:32 jnthn So we just need to make sure we call process_bad_bytes instead of the thing that says the codepoint is OK
11:33 arnsholt Ah, cool
12:03 brrt joined #moarvm
12:17 brrt i'll pose my design question again
12:17 brrt a new design question in fact
12:17 ilmari joined #moarvm
12:18 brrt with the new live range building, i can get a worklist that has empty (refless) live ranges as a result of PHI node merging
12:19 brrt i.e. i encounter a node, create a live range; then i encounter a PHI, and merge two live ranges; one of them ends up 'empty'
12:19 notviki joined #moarvm
12:19 leego joined #moarvm
12:20 brrt i can handle that easily in the worklist-processing code, but, i can also write a simple compaction algorithm to remove these items
12:20 brrt what to do, what to do
12:22 tbrowder joined #moarvm
12:25 SmokeMachine joined #moarvm
12:37 jnthn Meanwhile, the super-obscure bug I'm hunting seems to be that, very occasionally, callsame doesn't actually call the thing it's meant to
12:38 jnthn o.O
12:38 jnthn lunch &
12:46 arnsholt Sounds like a good time for it, yeah. Happy noms =)
12:57 pyrimidine joined #moarvm
13:09 jnthn Righty, let's see if the 3 types of cheese I had at lunch will be any help with the bug hunting... :)
13:11 brrt joined #moarvm
13:11 brrt that is weird indeed jnthn
13:12 dalek MoarVM: a93a48f | jnthn++ | src/core/frame.c:
13:12 dalek MoarVM: Missing rooting in rare exit handler case.
13:12 dalek MoarVM:
13:12 dalek MoarVM: Doesn't fix an observed bug, but was certainly wrong.
13:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a93a48ff1b
13:13 brrt joined #moarvm
13:23 dogbert2 .oO (jnthn getting to the root of the problem)
13:43 jnthn Slowly...
13:44 jnthn Still not at all cler what's going on
13:47 jnthn Oh, latest debug output provides a strong indication
13:47 * dogbert2 do I see a blog post in the future
13:48 harrow joined #moarvm
13:50 jnthn Yes, I think I've got a good idea what happens
13:51 dogbert2 cool, do you think it has affected more than OO::Monitors?
13:51 jnthn Yes.
13:51 jnthn It's finalization related
13:52 jnthn Actually nothing much to do with OO::Monitors besides that it uses callsame
13:54 dogbert2 maybe you'll be able to close a few RT's then
14:02 jnthn Hm, I thought we had one that I could fix together with this, but I can't find it
14:02 jnthn m: class P { method m($a) { say 'here' } }; class C is P { method m($a) { callsame } }; C.m(6)
14:03 camelia rakudo-moar fb4f16: OUTPUT«here␤»
14:03 jnthn m: class P { method m($a) { say 'here' } }; class C is P { method m($a where $a > 5) { callsame } }; C.m(6)
14:03 camelia rakudo-moar fb4f16: OUTPUT«here␤»
14:03 jnthn m: class P { method m($a) { say 'here' } }; class C is P { method m($a where { $a > 5 }) { callsame } }; C.m(6)
14:03 camelia rakudo-moar fb4f16: OUTPUT«here␤»
14:03 jnthn Hm, apparently we already did fix that one :)
14:05 dogbert2 :)
14:08 dogbert2 does https://rt.perl.org/Public/Bug/Display.html?id=125135 apply?
14:10 lizmat joined #moarvm
14:11 jnthn It's possible a good fix will nail that one too
14:11 jnthn I also dug up https://rt.perl.org/Ticket/Display.html?id=123989
14:12 jnthn I think perhaps the best bet is that we introduce a setdispatcherfor op that constrains the dispatcher to only be takable by a certain code object
14:12 jnthn Then nothing else can sneakily take it except the intended recipient
14:14 dogbert2 is that easy to implement?
14:15 jnthn Think so. Working on it at the moment
14:16 dogbert2 cool, and we have three scripts to test it with
14:16 dogbert2 that cheese really made a difference :)
14:18 jnthn Question is, was it the niva, cheddar, or camembert? :)
14:19 dogbert2 that you might need to research further :)
14:24 nine that could also fix the callsame endless loopbI reported 2 years ago
14:26 jnthn :)
14:26 * jnthn will be happy if he can get 3 RTs out of this. :)
14:26 jnthn Well, 2 RTs and an issue reported against OO::Monitors
14:36 nine win 2
15:01 brrt what is the problem with tthe JITing?
15:03 jnthn Darn, where's dalek...
15:03 jnthn Anyway, I just pushed a commit that changes takedispatcher a bit
15:03 jnthn So will need to update how it JITs
15:03 jnthn Thing is, in my initial factoring, it became quite a bit more complicated
15:04 jnthn But now I figured a way to move the complexity to the newly added setdispatcherfor op
15:04 jnthn So it should be easier to fix it up
15:07 jnthn Spotted while I was fixing things up: if you run the NQP test suite with a small nursery and FSA debugging on, then 01-continuations.t explodes with a panic
15:07 jnthn (unrelated to the issue I'm working on)
15:08 jnthn (and very probably on a code-path Rakudo doesn't use)
15:14 jnthn nine: https://rt.perl.org/Ticket/Display.html?id=123989 now prints:
15:14 jnthn >0
15:14 jnthn <10
15:14 jnthn generic
15:15 brrt i'll have to take a look then
15:15 brrt the safe thing to do is of course just to disable them
15:16 brrt i've been thinking about a way to disable specific ops from being JITted
15:17 jnthn https://rt.perl.org/Ticket/Display.html?id=125135 also passes wiht the fix
15:18 jnthn I need to unapply it and make sure those two are really fixed by it, rather than in the meantime, though
15:18 jnthn And turn them into tests
15:18 jnthn And somehow need to work out a decent golf of the japhb++ submission that triggered all of those, if I can.
15:18 jnthn That can go in as a spectest
15:18 dogbert2 impressive work
15:19 lizmat_ joined #moarvm
15:22 jnthn OK, need a break for a bit
15:22 jnthn But spectest came out clean
15:24 nwc10 coffee?
15:24 nwc10 or a stronger break?
15:24 jnthn Tea, and a kitten tongue :)
15:31 lizmat joined #moarvm
15:33 dalek joined #moarvm
15:52 * jnthn back
15:54 jnthn Hm, so seems that 125135 was already fixed
15:54 jnthn Before my change
15:55 jnthn Though I suspect this fix is more robust and will stop it being reintroduced
15:55 jnthn 123989 is fixed by the change
15:56 dogbert2 hmm, I get two test fails with the 125135 example on 'This is Rakudo version 2016.12-191-gee38721ca built on MoarVM version 2016.12-55-gfe110d60'
15:57 jnthn Odd
15:57 dogbert2 tests 2 and 4 fail
15:57 jnthn Hm, wonder why not for me
15:58 jnthn Do they pass for you on MoarVM HEAD?
15:58 dogbert2 that I have to test, sec
16:01 jnthn k
16:01 jnthn I've turned https://rt.perl.org/Ticket/Display.html?id=123989 into a test that I've verified passes/fails ahead of the test
16:01 jnthn *the change
16:01 jnthn And "before" :)
16:03 jnthn And now I've got a hanging test for the JIT
16:04 dogbert2 maybe I don't know how to do this properly, I went to nqp/MoarVM and: git checkout master; git pull; Configure followed by make install. That is obviously not the way to get hold of HEAD ?
16:05 jnthn Maybe you need --prefix=... to Configure?
16:05 jnthn So that it will install to the correct place
16:05 jnthn Oh wait
16:05 dogbert2 I did
16:05 jnthn Duh.
16:05 jnthn I have local NQP and Rakudo changes :(
16:05 jnthn That you'd also need
16:05 jnthn D'oh. Sorry.
16:06 dogbert2 oh
16:06 jnthn Forgot those :)
16:06 dogbert2 :)
16:07 jnthn hmm...the takedispatcher JIT already wasn't quite identical to the interpreter one
16:07 jnthn nqp: sub foo() { nqp::say(nqp::takedispatcher().HOW.name(1)) }; foo()
16:07 camelia nqp-moarvm: OUTPUT«takedispatcher must have a single QAST::SVal child␤   at gen/moar/stage2/QAST.nqp:4261  (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:)␤ from gen/moar/stage2/QAST.nqp:1596  (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)␤ from…»
16:07 jnthn nqp: sub foo() { my $a; nqp::say(nqp::takedispatcher('$a').HOW.name(1)) }; foo()
16:07 camelia nqp-moarvm: OUTPUT«VMNull␤»
16:08 jnthn nqp: sub foo() { my $a; nqp::say(nqp::takedispatcher('$a').HOW.name(1)) }; while 1 { foo() }
16:08 camelia nqp-moarvm: OUTPUT«(signal XFSZ)VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull␤VMNull…»
16:08 jnthn Hm, thought we might get a SEGV
16:17 dogbert2 I'm messing things up it seems. It is possible to transform 125135 to a Camelia oneliner?
16:18 jnthn Not really because meta-ojbects really have to live in a separate compilation unit
16:18 jnthn That's the only way to use EXPORTHOW
16:19 dalek MoarVM: a4fbf52 | jnthn++ | src/jit/emit_x64.dasc:
16:20 dalek MoarVM: Update JIT of takedispatcher.
16:20 dalek MoarVM:
16:20 dalek MoarVM: Brings it in sync with the recent changes to the op in interp.c.
16:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a4fbf52e9f
16:20 jnthn The first assembly of the year :)
16:20 dogbert2 m: https://gist.github.com/dogbert17/9563e21b80f6bea38c8a5c35b4dff4d7
16:20 camelia rakudo-moar fb4f16: OUTPUT«1..4␤ok 1 - ␤ok 2 - ␤ok 3 - ␤ok 4 - ␤»
16:20 dogbert2 hmm
16:21 jnthn I don't think that'll actually use the TestHOW
16:21 jnthn Well, it can't 'cus class is already compiled before it's introduced
16:23 dogbert2 how do I get the local Rakudo changes you mentioned?
16:24 jnthn I just pushed the NQP ones
16:24 jnthn I'll push the Rakudo ones to a branch
16:25 jnthn Rakudo branch is named setdispatcherfor
16:25 dogbert2 thx, I'll try again
16:26 jnthn OK. And my spectest for RT #123989 is ready, I'll push it once I've got JVM fixed up for this change
16:26 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=123989
16:26 jnthn So don't worry about that one :)
16:28 nwc10 clearly that was good cheese
16:47 dogbert2 :( my attempt to build head was a failure
16:48 jnthn :S
16:48 jnthn My attempt to try my JVM updates is...slow :)
16:49 dogbert2 perhaps we can trick nwc10 to try the code example in RT 125135
16:55 * dogbert2 installs rakudo from scratch
17:00 * dogbert2 with my clean rakudo install, i.e. without jnthn's latest fixes, I get two test failures when running the RT #125135 example
17:16 jnthn dogbert2: Any chance you're able to turn it into a spectest?
17:16 jnthn (You can put the module in t/spec/packages
17:16 jnthn )
17:18 dogbert2 jnthn: that I should be able to do
17:19 jnthn Nice, thanks. :)
17:19 jnthn I pushed my fixes
17:19 jnthn About to push spectest and resolve the other ticket
17:19 dogbert2 where should I put the test itself, any suggestions
17:20 dogbert2 any appropriate file in roast?
17:20 jnthn Hm
17:20 jnthn Somewhere under S12-meta
17:20 dogbert2 ok
17:20 jnthn In fact the TestHOW.pm6 could go under thre too
17:20 jnthn But that's where other meta-programming tests have gone
17:21 lizmat joined #moarvm
18:38 domidumont joined #moarvm
18:40 domidumont joined #moarvm
19:35 hoelzro_ joined #moarvm
19:35 synopsebot6 joined #moarvm
19:35 notviki joined #moarvm
19:36 timotimo joined #moarvm
19:36 leego joined #moarvm
19:36 geekosaur joined #moarvm
20:12 domidumont joined #moarvm
23:01 japhb .tell jnthn Excellent bug destruction!  I'll rebuild and confirm on my side later, but very happy to hear a golfed version is now in roast.
23:34 lizmat joined #moarvm

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