00:31 colomon_ joined
samcv jnthn, you still awake? 01:33
anyway. so i just made a script to automate downloading all the unicode files and extracting them properly 01:34
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 03:21 pyrimidine joined
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, ChanServ joined, JimmyZ joined, Util joined, jnthn joined, moritz joined, masak joined, harrow joined, BinGOs joined, zostay joined, konobi_ joined, mtj_ joined, nwc10 joined, yoleaux2 joined, sivoais joined, SmokeMachine joined, japhb joined, btyler joined, samcv joined, psch joined, [Coke] joined, leedo_ joined, stmuk joined, hoelzro joined, avar joined, timotimo joined, geekosaur joined, ggoebel joined, notviki joined, nebuchadnezzar joined, diakopter joined, nine joined, camelia joined, mst joined, synopsebot6 joined, dogbert2 joined, Dunearhp joined, leego joined, tbrowder joined, lizmat joined, dalek joined
samcv ok i think that's it 03:35
diakopter heh 03:36
samcv oops wrong channel
diakopter so it was special cased in ucd2c.pl? or I ignored that bidi file or what
samcv oh regarding the brackets? 03:37
diakopter yeah
samcv nope it was just in roast and nqp wrong
wollmers may have added both that and the ornate parens
oh he just removed spaces. i'm looking at git blame now. so i know who to blame :P 03:39
timotimo ah, there might be a flag that ignores whitespace changes 03:40
samcv uhm it's been in there for a while
like forever
timotimo huh. 03:41
samcv Auzon <Auzon@c213334d-75ef-0310-aa23-eaa082d1ae64> 03:42
ok we can blame this person from 2008
timotimo that must have been before my time. maybe during the pugs time?
samcv yeah
git-svn-id: svn.pugscode.org/pugs@20873 c213334d-75ef-0310-aa23-eaa082d1ae64 03:43
heh
i'm sure they were added in without giving it __too__ much thought 03:44
but that is ok. has been corrected :P
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:58
or at least only putting the script names in the property name keys, instead of EVERYTHING 03:59
which causes conflicts between like LF=space and space=True
and the Greek block (i think block) an Greek script property
diakopter samcv: I'm currently enthralled by okay, I found the right thing I need to port from Agda to Lean: typetheorypodcast.com/2016/12/episo...n-cedille/ and the prospect of attempting the Herculean (or is it Sisyphean?) task of porting Cedille from Agda to Lean 04:07
samcv interesting 04:09
what's agda
timotimo a prog lang for dependent typing and proofs and such 04:10
diakopter of course, it would help if Cedille were open-source [yet] šŸ™„ 04:24
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
like 'SpacingMark' is true if Grapheme_Cluster_Break == true
and other such things
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:40
timotimo the slowest thing a computer can do nowadays is memory access 04:43
(or so i've been told)
geekosaur if you s/computer/CPU/ that's not far from the truth 04:47
timotimo oh, right
because computers can also do network requests to the ISS :)
or bounce signals off of the mirror on the moon
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.)
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:49
diakopter timotimo: it's a philosophical question, you're right :) 04:51
timotimo hah
a question of terminology, clearly
04:52 pyrimidine joined
samcv ok so we should compute it from values we already have? 04:52
timotimo if it's not too much work, yeah i guess so 04:53
samcv kk
timotimo hm, except if we use the value a whole bunch of times in a row
samcv but... how does that change it
timotimo then it'd stay in l1 cache and it might actually be faster to have the right value already available??
samcv hm
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
samcv i'm going to try and make as many things as possible rely on grapheme_cluster_break property
instead of multiple. so that should be good
instead of many different ones
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
diakopter well the thing is, if it's computed it would be a separate moar op 04:56
timotimo oh?
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
bunch of branches
geekosaur the idea of getting I/O out of memory to simplify memory management wasn't necessarily bad, just not fully thought out
diakopter to the property lookup thing
timotimo diakopter: i expect that MVM_unicode_get_property_int would gain a bit more code 04:59
what it currently does is read out the props_bitfield and & it with some bit
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:00
i wonder how many bits are unused at the end of the last bitfield row 05:01
and how many bits are unused in each of the rows at the end
there's probably nothing much to save there? :(
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
until we find a good benchmark, that is.
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?
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:07
timotimo because the code is already a switch/case and all properties are already "computed" 05:08
just that the computation is a bit-and and a shift on a piece of storage that's specifically for that property
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
timotimo and we'd just look at a different property's storage and interpret it differently
samcv i think it should be combined into only one function 05:09
timotimo it could be because of the JIT, mind you
samcv so we don't have to lookup 2x for the full path
i think we may be able to ignore CCC if we use GCB
will have to test that though
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
samcv just search for should_break
err let me look up the exact name
MVM_unicode_normalizer_process_codepoint_full normalize.c 05:11
timotimo no, i meant the getcodepointfromgrapheme and getcodepointfromgrapheme_full
samcv err doesn't exist. sorry i meant codepoint from grahpeme (whatever its name) calls first MVM_unicode_normalizer_process_codepoint 05:12
which then checks many things, then if it fails passes to MVM_unicode_normalizer_process_codepoint_full
timotimo ah. we have two of those because the short one is explicitly marked to be inlined
samcv can we inline both?
well _one
timotimo the _full one is a bit big for that
samcv they're like the same size?
well. they are a little diff 05:13
timotimo checks again
it's like 2x as big 05:14
samcv yeah
timotimo nah, 3x
(i removed comments for the measurement)
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:15
github.com/MoarVM/MoarVM/compare/m...c8d29e348e 05:17
so only one change
timotimo right, doesn't seem to change the lengths 05:18
samcv what's the best way to benchmark this?
should i just try to process loads of random text?
timotimo i suppose so? 05:24
you can use valgrind's callgrind tool to get more precise measurements than timing stuff 05:25
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:26
samcv yeah i have, should check where for them, just advent or where else? 05:27
timotimo 6guts.wordpress.com is his blog
samcv kk
i'm going to use this repeated 10,000 times in a file github.com/minimaxir/big-list-of-n...r/blns.txt 05:29
just for the variety
and gonna just use a ramdisk for the benchmarks 05:31
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:33
yeah inlining seems to be faster, and it's not that long (the non full one) 05:36
timotimo inlining the _full function, too? 05:38
samcv no
timotimo oh, the non full one
i'm confused. i thought that one is already inline? 05:39
samcv just how it was before
no it is
timotimo i'll try to get some sleep again, i seem to be hiccup-free right now 05:53
just as i said that it starts again 05:54
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:27
ok seems most of the slowness is caused by the normalizer 06:38
processing huge string it uses 30% of cycles
well inclusive. exclusive it's 7.1
strtol is doing 30% of the cpu cycles of MVM_unicode_normalizer_process_codepoint_full :( 07:00
07:00 domidumont joined
samcv * decomposition on it; 07:00
:(
/* Parse hex character code, and then recurse to do any further decomposition on it;
07:03 FROGGS joined 07:05 domidumont joined
timotimo aha! 07:15
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:16
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
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?
samcv because insanity
samcv shouts at the heavens
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 :(
it will probably break everything
(in the script)
timotimo ;(
did we already get it ported to perl6, btw?
samcv no 07:21
i wish
i don't know how it allocates bitfields and things at all
and perl 6 would take so long to process all the text files
idk could make it a module with Inline:: 07:23
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:24
samcv shakes her head 07:28
$points_by_hex->{$code_str} = $points_by_code->{$code} = $point;
time for spaghetti
diakopter, WHY!
timotimo what's wrong with that, exactly? 07:29
samcv not not that specifically 07:30
just even storing them as hex
timotimo mhm
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
and not store them as numbers but i'll look into it
i expect it to break everything
08:16 zakharyas joined
samcv timotimo, how do you feel about this github.com/samcv/MoarVM/compare/mo...nicode_9.0 08:33
my Even_Moar_Unicode_9.0 bracnch that passes 100% of the unicode 9.0 ones 08:34
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:35
timotimo my brain isn't ready to do any sort of review 08:41
samcv kk
timotimo i'm suffering from sleep deprivation, and those hiccups that are also preventing me from sleeping are draining my concentration
samcv i'm sorry you're still having them
timotimo me, too :(
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:42
08:53 pyrimidi_ joined
dalek arVM: 5c03c27 | samcv++ | tools/UCD-download.p6:
Add a script to download the latest version of all of the Unicode data

Downloads UCD.zip, collation data (allkeys.txt) and emoji-data.txt.		 09:00
arVM: 99d019d | lizmat++ | tools/UCD-download.p6:
Merge pull request #479 from samcv/UCD-download

Add a script to download the latest version of all of the Unicode data
arVM/even-moar-jit: 9a67811 | brrt++ | src/jit/linear_scan.c:
Replace ValueRef array buffer with linked list

This reduces the need for the second loop in determine_live_ranges. As a result of the union proces, the reference lists are merged and flushed in the 'remaining' live range.
A check in the linear_scan algorithm removes the need for a compaction / worklist reaping step (although this would also be a valid approach).		 09:14
09:21 brrt joined
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. :-)
brrt googles philosophy is somewhat infamous, and has a known-high false negative rate 09:23
whether that is a problem is another matter entirely
i should probably add a live_range_merge function 09:28
nwc10 by "false negative" you mean "rejects candidates who would actually have been suitable" ? 09:30
timotimo i think so
brrt stronger yet: 'candidates who in a later version of themselves would become highly desirable to google' 09:34
stories of that type are spread over the internet 09:35
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. :-)
jnthn samcv: 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
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:13
samcv yep good to go 10:15
:)
brrt morning jnthn 10:17
dalek arVM: 9eb6b6e | samcv++ | / (4 files):
Implement in unicmp_s and checking secondary and tetriary weights

   An issue is also fixed where ucd2c.pl would not add up the total
   weighting for characters which decompose into multiple characters.
fe110d6 | jnthn++ | src/strings/utf8_c8.c: Catch some missed invalid sequences in utf8-c8.
jnthn samcv++
nwc10 poor dalek needs a rate limiter
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
jnthn Because that's just the way ucd2c.pl was originally implemented 10:18
timotimo right
samcv :^)
jnthn And I had more than enough to do with getting a working implementation of NFG to be worrying about such things.
timotimo samcv found a workload where a whole lot of time is spend in strotl :) 10:19
samcv yep
timotimo well, a noticable amount at least
jnthn Yes, well, my implementation aim was "make the code look as much like the spec as possible so I can quickly fix divergences" :)
Not "make it run fast"
samcv 14%
jnthn I'm sure we can optimize this in many places. :-)
samcv like not doing string to hex :P 10:20
jnthn Indeed. ;-)
samcv yeah. jnthn my Even_Moar_Unicode9.0 has some optimizations as well. but so far it seems to not have too much impact
jnthn When I put that in I was like "urgh, do I have to...eh, ok" :)
samcv saving the state when iterating
for the workload i'm testing with about 1/2 ascii 1/2 not
timotimo 1/2 ascii, 1/2 art :D
samcv heh 10:21
jnthn ASCII should go pretty fast since I think we don't even look at any props
samcv well unless it has to backtrack when it sees an extend
but yeah i think that's probably true 10:22
jnthn Well, I meant two ASCII chars next to each other :)
dogbert2 jnthn: are you fixing bugs today as well? 10:48
jnthn Well, this morning at least :) 10:49
Going to see if I can figure out github.com/jnthn/oo-monitors/issues/9 10:50
nwc10 cool. it's always morning on #moarvm 10:52
dogbert2 a tricky bug it seems
10:54 pyrimidine joined
jnthn dogbert2: Indeed. 10:58
11:23 arnsholt joined
arnsholt jnthn: Doesn't that patch for the utf8-c8 bug reject sequences like 0b11100000_10xxxxxx_10xxxxxx? 11:26
Or am I misreading it?
jnthn Well, utf8-c8 doesn't reject anything 11:27
It just turns things it thinks won't round-trip into synthetics to represent the original bytes
Something starting 0b11100000 will surely be rejected though
Since there's a shorter encoding, no? 11:28
The fix I put in *is* an over-estimate of what it needs to make synthetics for though
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
Yeah 11:29
jnthn We'd need to keep a bit more state otherwise
arnsholt But you're right; it'll overgenerate synthetics, but round-trip correctly nonetheless
jnthn Indeed. We can surely fix the over-generation too at some point. 11:30
But the failure to round-trip was my main worry
arnsholt Yeah, that's definitely worse
jnthn If you're interested enough, feel free to patch it :)
arnsholt Yeah, I'll see if I can't carve out some time to fiddle with it
jnthn Well, and time-endowed enough :)
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*
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.
It already keeps track of the bytes
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
jnthn So we just need to make sure we call process_bad_bytes instead of the thing that says the codepoint is OK
arnsholt Ah, cool 11:33
12:03 brrt joined
brrt i'll pose my design question again 12:17
a new design question in fact
12:17 ilmari joined
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:18
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
12:19 notviki joined, leego joined
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
what to do, what to do
12:22 tbrowder joined 12:25 SmokeMachine joined
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:37
o.O 12:38
lunch &
arnsholt Sounds like a good time for it, yeah. Happy noms =) 12:46
12:57 pyrimidine joined
jnthn Righty, let's see if the 3 types of cheese I had at lunch will be any help with the bug hunting... :) 13:09
13:11 brrt joined
brrt that is weird indeed jnthn 13:11
dalek arVM: a93a48f | jnthn++ | src/core/frame.c:
Missing rooting in rare exit handler case.

Doesn't fix an observed bug, but was certainly wrong.		 13:12
13:13 brrt joined
dogbert2 .oO (jnthn getting to the root of the problem) 13:23
jnthn Slowly... 13:43
Still not at all cler what's going on 13:44
Oh, latest debug output provides a strong indication 13:47
dogbert2 do I see a blog post in the future
13:48 harrow joined
jnthn Yes, I think I've got a good idea what happens 13:50
dogbert2 cool, do you think it has affected more than OO::Monitors? 13:51
jnthn Yes.
It's finalization related
Actually nothing much to do with OO::Monitors besides that it uses callsame 13:52
dogbert2 maybe you'll be able to close a few RT's then 13:54
jnthn Hm, I thought we had one that I could fix together with this, but I can't find it 14:02
m: class P { method m($a) { say 'here' } }; class C is P { method m($a) { callsame } }; C.m(6)
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)
camelia rakudo-moar fb4f16: OUTPUTĀ«hereā¤Ā»
jnthn m: class P { method m($a) { say 'here' } }; class C is P { method m($a where { $a > 5 }) { callsame } }; C.m(6)
camelia rakudo-moar fb4f16: OUTPUTĀ«hereā¤Ā»
jnthn Hm, apparently we already did fix that one :)
dogbert2 :) 14:05
does rt.perl.org/Public/Bug/Display.html?id=125135 apply? 14:08
14:10 lizmat joined
jnthn It's possible a good fix will nail that one too 14:11
I also dug up rt.perl.org/Ticket/Display.html?id=123989
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
Then nothing else can sneakily take it except the intended recipient
dogbert2 is that easy to implement? 14:14
jnthn Think so. Working on it at the moment 14:15
dogbert2 cool, and we have three scripts to test it with 14:16
that cheese really made a difference :)
jnthn Question is, was it the niva, cheddar, or camembert? :) 14:18
dogbert2 that you might need to research further :) 14:19
nine that could also fix the callsame endless loopbI reported 2 years ago 14:24
jnthn :) 14:26
jnthn will be happy if he can get 3 RTs out of this. :)
Well, 2 RTs and an issue reported against OO::Monitors
nine win 2 14:36
brrt what is the problem with tthe JITing? 15:01
jnthn Darn, where's dalek... 15:03
Anyway, I just pushed a commit that changes takedispatcher a bit
So will need to update how it JITs
Thing is, in my initial factoring, it became quite a bit more complicated
But now I figured a way to move the complexity to the newly added setdispatcherfor op 15:04
So it should be easier to fix it up
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
(unrelated to the issue I'm working on)
(and very probably on a code-path Rakudo doesn't use) 15:08
nine: rt.perl.org/Ticket/Display.html?id=123989 now prints: 15:14
>0
<10
generic
brrt i'll have to take a look then 15:15
the safe thing to do is of course just to disable them
i've been thinking about a way to disable specific ops from being JITted 15:16
jnthn rt.perl.org/Ticket/Display.html?id=125135 also passes wiht the fix 15:17
I need to unapply it and make sure those two are really fixed by it, rather than in the meantime, though 15:18
And turn them into tests
And somehow need to work out a decent golf of the japhb++ submission that triggered all of those, if I can.
That can go in as a spectest
dogbert2 impressive work
15:19 lizmat_ joined
jnthn OK, need a break for a bit 15:22
But spectest came out clean
nwc10 coffee? 15:24
or a stronger break?
jnthn Tea, and a kitten tongue :)
15:31 lizmat joined 15:33 dalek joined
jnthn back 15:52
Hm, so seems that 125135 was already fixed 15:54
Before my change
Though I suspect this fix is more robust and will stop it being reintroduced 15:55
123989 is fixed by the change
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:56
jnthn Odd 15:57
dogbert2 tests 2 and 4 fail
jnthn Hm, wonder why not for me
Do they pass for you on MoarVM HEAD? 15:58
dogbert2 that I have to test, sec
jnthn k 16:01
I've turned rt.perl.org/Ticket/Display.html?id=123989 into a test that I've verified passes/fails ahead of the test
*the change
And "before" :)
And now I've got a hanging test for the JIT 16:03
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:04
jnthn Maybe you need --prefix=... to Configure? 16:05
So that it will install to the correct place
Oh wait
dogbert2 I did
jnthn Duh.
I have local NQP and Rakudo changes :(
That you'd also need
D'oh. Sorry.
dogbert2 oh 16:06
jnthn Forgot those :)
dogbert2 :)
jnthn hmm...the takedispatcher JIT already wasn't quite identical to the interpreter one 16:07
nqp: sub foo() { nqp::say(nqp::takedispatcher().HOW.name(1)) }; foo()
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ā€¦Ā»
jnthn nqp: sub foo() { my $a; nqp::say(nqp::takedispatcher('$a').HOW.name(1)) }; foo()
camelia nqp-moarvm: OUTPUTĀ«VMNullā¤Ā»
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ā€¦Ā»
jnthn Hm, thought we might get a SEGV
dogbert2 I'm messing things up it seems. It is possible to transform 125135 to a Camelia oneliner? 16:17
jnthn Not really because meta-ojbects really have to live in a separate compilation unit 16:18
That's the only way to use EXPORTHOW
dalek arVM: a4fbf52 | jnthn++ | src/jit/emit_x64.dasc:
Update JIT of takedispatcher.

Brings it in sync with the recent changes to the op in interp.c.		 16:19
jnthn The first assembly of the year :)
dogbert2 m: gist.github.com/dogbert17/9563e21b...35b4dff4d7
camelia rakudo-moar fb4f16: OUTPUTĀ«1..4ā¤ok 1 - ā¤ok 2 - ā¤ok 3 - ā¤ok 4 - ā¤Ā»
dogbert2 hmm
jnthn I don't think that'll actually use the TestHOW 16:21
Well, it can't 'cus class is already compiled before it's introduced
dogbert2 how do I get the local Rakudo changes you mentioned? 16:23
jnthn I just pushed the NQP ones 16:24
I'll push the Rakudo ones to a branch
Rakudo branch is named setdispatcherfor 16:25
dogbert2 thx, I'll try again
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: rt.perl.org/rt3//Public/Bug/Displa...?id=123989
jnthn So don't worry about that one :)
nwc10 clearly that was good cheese 16:28
dogbert2 :( my attempt to build head was a failure 16:47
jnthn :S 16:48
My attempt to try my JVM updates is...slow :)
dogbert2 perhaps we can trick nwc10 to try the code example in RT 125135 16:49
dogbert2 installs rakudo from scratch 16:55
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:00
jnthn dogbert2: Any chance you're able to turn it into a spectest? 17:16
(You can put the module in t/spec/packages
)
dogbert2 jnthn: that I should be able to do 17:18
jnthn Nice, thanks. :) 17:19
I pushed my fixes
About to push spectest and resolve the other ticket
dogbert2 where should I put the test itself, any suggestions
any appropriate file in roast? 17:20
jnthn Hm
Somewhere under S12-meta
dogbert2 ok
jnthn In fact the TestHOW.pm6 could go under thre too
But that's where other meta-programming tests have gone
17:21 lizmat joined 18:38 domidumont joined 18:40 domidumont joined 19:35 hoelzro_ joined, synopsebot6 joined, notviki joined 19:36 timotimo joined, leego joined, geekosaur joined 20:12 domidumont joined
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:01
23:34 lizmat joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!