Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-31

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

All times shown according to UTC.

Time Nick Message
00:20 samcv \o/ it works
00:21 Zoffix \o/
00:21 geekosaur joined #moarvm
00:21 samcv it's not like perfectly clean. toward the end i find the bad elements which is basically the PropertyValueAliases line
00:21 samcv gc ; C                                ; Other                            # Cc | Cf | Cn | Co | Cs
00:22 samcv but it has the right number assigned to it. and i then split it into the parts and add those to the array. then at the end i reverse the array so that i make sure the right elements are first
00:22 samcv a little hackish but it works
00:22 samcv so i'll take it!
00:23 samcv now that that works, i think spectest should be mostly good. since i had all the other ones i think working, and property values now being totally distinct per property
00:32 samcv not totally finished got to get Letter working but L works and C works
00:57 samcv and Letter is correct in one of the data structures just need to get it into the other one..
01:31 geekosaur joined #moarvm
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:53 * samcv mad scientist cackle
01:54 samcv now to remove all the extra code which didn't work and leave only the code that actually works
02:56 MasterDuke joined #moarvm
04:28 Ven`` joined #moarvm
05:21 Geth ¦ MoarVM: samcv++ created pull request #670: Update Unicode database for Unicode 10
05:21 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/670
05:51 Geth ¦ MoarVM: bea907b4b0 | (Samantha McVey)++ | 4 files
05:51 Geth ¦ MoarVM: Update Unicode database for Unicode 10
05:51 Geth ¦ MoarVM:
05:51 Geth ¦ MoarVM: Also make changes to the Unicode database so property values
05:51 Geth ¦ MoarVM: are unique for each property.
05:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bea907b4b0
05:51 Geth ¦ MoarVM: 79654248b0 | (Samantha McVey)++ (committed using GitHub Web editor) | 4 files
05:51 Geth ¦ MoarVM: Merge pull request #670 from samcv/property-value-2
05:51 Geth ¦ MoarVM:
05:51 Geth ¦ MoarVM: Update Unicode database for Unicode 10
05:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/79654248b0
06:16 brrt joined #moarvm
06:21 brrt good * #moarvm
06:21 yoleaux 30 Aug 2017 20:32Z <nine> brrt: why does the JIT clear RV in the epilogue? It could be used for returning a value to the caller otherwise
06:23 brrt .tell nine the even-moar-jit and jit-legacy-cleanup branch don't clear it, the idea was to signal the caller if it should unwind the stack
06:24 yoleaux brrt: I'll pass your message to nine.
06:24 brrt .tell nine we now explicitly unwind the stack in the implmeentation of the return ops, so that's no longer necesary
06:24 yoleaux brrt: I'll pass your message to nine.
06:27 samcv good *
06:28 brrt ohai samcv
06:28 brrt hows your fight with uc2dc.pl ending
06:39 samcv i won
06:39 samcv a fight is the best description
06:40 brrt good
06:40 samcv Added Korean codepoint names too
06:40 brrt are you ready to tell glorious tales about it as well?
06:40 samcv and property values are now distinct
06:40 samcv haha
07:24 lizmat joined #moarvm
07:40 brrt joined #moarvm
07:54 leont joined #moarvm
07:57 nine So many movs...
07:57 yoleaux 06:23Z <brrt> nine: the even-moar-jit and jit-legacy-cleanup branch don't clear it, the idea was to signal the caller if it should unwind the stack
07:57 yoleaux 06:24Z <brrt> nine: we now explicitly unwind the stack in the implmeentation of the return ops, so that's no longer necesary
08:00 brrt aye, i know
08:00 brrt yesterday i learned
08:01 brrt when *not* to rebase
08:01 nine brrt: did you get rid of dynasm in even-moar-jit or can it be used to actually dynamically create code?
08:02 brrt i fixed dynasm to be able to select the full range of registers
08:02 brrt this was one wondrous adventure
08:02 brrt at the end, i thought, maybe it would've been simpler to have some other assembly abstraction
08:03 brrt on the other hand, that would never have allowed me to 'fit in' the legacy JIT as easy as it is now
08:03 zakharyas joined #moarvm
08:03 nine So it can be used without going through the dasc compiler?
08:04 brrt i recently had a bug with that, too, where dynasm would think that a label could fit into 1 byte, and then the range increased due to a REX byte that had to be added, and the label would overflow and become negative
08:04 brrt no, it still goes through dynasm
08:04 brrt dynasm is and remains the assembly backend for both JITs
08:05 brrt but dynasm is a really, really thin layer of abstraction
08:05 brrt so i'm not too worried about that
08:06 nine So how do you create code with it where the register to use is not static?
08:06 brrt you select it by number
08:06 brrt using: Rq(1), Rq(2), Rq(11) etc
08:06 brrt that was what i fixed :-)
08:07 nine ah, and there you can say Rq(num_gpr)
08:10 lizmat samcv++  # Unicode 10 support
08:10 lizmat BTW, is there a way to introspect which version of Unicode is supported?
08:10 samcv thanks lizmat :)
08:10 samcv no
08:10 lizmat :-(
08:10 samcv lizmat, also property values are now unique
08:11 lizmat cool!
08:11 samcv yeah
08:11 lizmat but being able to introspect version would be something nice to have  :-)
08:11 lizmat in the future  :-)
08:11 samcv uhm is there an already existing thing that returns data
08:11 samcv i should latch it onto?
08:11 lizmat samcv: what is that thing?
08:12 samcv like nqp::getmoarinfo
08:12 brrt aye!
08:12 samcv ^ i made that up
08:12 brrt i think there is something yes
08:12 lizmat is that thing documented ?
08:13 * lizmat was told all of the interesting  nqp:: ops are actually undocumented  :-)
08:13 brrt hmm
08:13 brrt hehe
08:13 brrt .oO( the documentation, thats just interp.c, right? )
08:13 samcv hehe
08:13 nine pretty much yes :)
08:13 samcv that's what i look at when i don't know what an op does
08:13 samcv and find the moarvm function that it coorasponds to
08:14 samcv i've been documenting all my ops!
08:14 samcv practically
08:19 dogbert2 joined #moarvm
08:22 samcv ok now i documented the variations of index(ic)?(im)? and eqat(ic)?(im)?
08:23 nine samcv++
08:23 samcv and i updated unicmp to the latest yesterday or day before to how i changed the bitmask
08:54 samcv i added a script that will print out all the undocumented nqp ops
08:54 lizmat :-)
08:55 samcv or at least all the ones not found with .contains in the ops.markdown
08:55 samcv only shows ones added to QASTOpretionsMAST
08:55 samcv and you can supply a command line switch to show nqp and moar names for the ops side by side or just the moar names
08:56 samcv lizmat, is there a way to do a cube root or some other non square root?
08:57 lizmat m: dd 27**1/3   # samcv
08:57 camelia rakudo-moar 64dd94: OUTPUT: «9.0?»
08:57 lizmat hmmm
08:57 samcv i couldn't find anything on docs.perl6.org
08:58 lizmat m: dd 27**(1/3)   # samcv
08:58 camelia rakudo-moar 64dd94: OUTPUT: «3e0?»
08:58 samcv wellllllll
08:58 lizmat :-)
08:58 samcv technically that works
08:58 lizmat yup
08:58 samcv would be nice if we could keyword root
08:58 samcv and say to do that
08:58 lizmat perhaps.  or it could be module spaced :-)
08:58 lizmat afk for a bit&
08:59 leont joined #moarvm
09:16 Ven`` joined #moarvm
09:35 nine OMG IT LIVES!
09:35 nine What have I done?
09:37 nine Deconting, unboxing, running and boxing, everything's there. And it no longer makes assumptions about allocated locals in the current frame, except that the arguments must be in the first locals in order. Which is quite sane and doesn't depend on further processing.
09:40 timotimo how do you signal what registers have the values you want?
09:40 nine I added a new argument and a new return value mode to the JIT which essentially implement GET_REG
09:44 timotimo i don't get it :)
09:46 nine You can now tell the JIT that the C function you want to call should take an argument from WORK[cur_op + whatever] which is the equivalent of all those GET_REG(curop, whatever) in interp.c
09:48 nine Same for return values. So when in interp.c you'd write GET_REG(cur_op, 0) = ...; you tell the JIT: box_rv_node->u.call.rv_mode = MVM_JIT_RV_DYNIDX; box_rv_node->u.call.rv_idx = 0;
10:01 nine Does that help?
10:13 Geth ¦ MoarVM/jit_nativecall: 59c737ab76 | (Stefan Seifert)++ | 3 files
10:13 Geth ¦ MoarVM/jit_nativecall: Dynamically determine register for return value and type
10:13 Geth ¦ MoarVM/jit_nativecall:
10:13 Geth ¦ MoarVM/jit_nativecall: This replaces assumptions about which locals the high level code uses for
10:13 Geth ¦ MoarVM/jit_nativecall: storing the return type and for expecting the return value by accessing the
10:13 Geth ¦ MoarVM/jit_nativecall: register numbers stored in the byte code for nativecallinvokejit instructions.
10:13 Geth ¦ MoarVM/jit_nativecall: You can now tell the JIT that the C function you want to call should take an
10:13 Geth ¦ MoarVM/jit_nativecall: argument from WORK[cur_op + whatever] which is the equivalent of all those
10:14 Geth ¦ MoarVM/jit_nativecall: GET_REG(cur_op, whatever) in interp.c.
10:14 Geth ¦ MoarVM/jit_nativecall: Same for return values. When in interp.c you'd write GET_REG(cur_op, 0) = ...;
10:14 Geth ¦ MoarVM/jit_nativecall: you tell the JIT: node->u.call.rv_mode = MVM_JIT_RV_DYNIDX;
10:14 Geth ¦ MoarVM/jit_nativecall: box_rv_node->u.call.rv_idx = 0;
10:14 Geth ¦ MoarVM/jit_nativecall: review: https://github.com/MoarVM/MoarVM/commit/59c737ab76
10:18 Geth ¦ MoarVM: duke-m++ created pull request #671: MVM_IS_32BIT_INT(i) with explicit casts
10:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/671
10:26 brrt wait, what
10:27 brrt you use get_cur_op to do what? :-o
10:32 nine To find the place where I should put the return value of the invokenativecalljit op
10:32 nine And to find the place where I get the return type from for boxing (that's the first operand of the invokenativecalljit op)
10:33 nine Previously I used hard coded indices into the WORK array which....was fragile at best
10:49 brrt why, couldn't you read the index where you'd compile it?
10:50 nine Because at that point I don't know it yet
10:53 brrt hmm. okay, that's fair, i guess
10:54 timotimo the jit is a lot to take in over just a couple of days
11:04 nine Well compared to spesh it's relatively straight forward :) Though I had to learn quite a bit about gdb to be able to debug this stuff
11:15 brrt :-)
12:02 ilmari[m] nwc10: lunch!
12:03 ilmari[m] (my IRC screen host seems to have fallen off the net, so I can't do it on #london.pm)
12:14 AlexDani` joined #moarvm
12:17 zura joined #moarvm
12:53 huggable joined #moarvm
12:56 Zoffix ??? New blog post: "On Troll Hugging, Hole Digging, and Improving Open Source Communities": https://rakudo.party/post/On-Troll-Hugging-Hole-Digging-and-Improving-Open-Source-Communities
13:03 nwc10 aha, there you are
13:03 nwc10 this window wasn't visible
13:03 nwc10 was going to ask "Is it raining?"
13:06 ilmari[m] brief showers
13:07 ilmari[m] from $ork slack: * tomh considers a variant of Godwin's Law where all IM channels eventually end up discussing @ilmari's lunch
13:07 Zoffix :D
13:08 ilmari[m] (I mentioned that I was going for lunch while waiting for jenkins+puppet)
13:30 lizmat joined #moarvm
13:58 zakharyas joined #moarvm
14:19 brrt so, what i learned yesterday
14:19 brrt there are cases where rebases are like, not the right thing to do
14:20 brrt this being: a): when there is significate divergence between the original base and the new base
14:22 brrt b): when the commit history of the rebased branch has been merged in the past to adjust to the new base
14:22 nine It usually also depends on how small or large your commits are.
14:23 brrt c): when the commit history of the rebased branch isn't by itself 'clean' or 'delimited' but adds-and-deletes things repeatedly
14:23 brrt (more speciifcally, if there isn't a clean 'progression' in the branch history)
14:24 brrt mostly c and b bite
14:24 timotimo C bites most :P
14:25 brrt basically, for a rebase to work, the history-to-rebase has to be small and self-contained
14:25 brrt if that doesn't hold, you're not actually gaining anything by the rebase
14:25 brrt and linearly progressing!
14:27 nine I don't really believe in the "small" part as I've done major rebases in the past. But yes, moving back and forth makes things really hard.
14:27 brrt yeah, maybe i should stress 'contained' more than 'small'
14:28 brrt the 'split it in two branches' bit, that's probably still a decent enough idea, since the changes to the legacy JIT are much more self-contained and linear-progressive than the history of even-moar-jit
14:28 nine It helps to clean (rebase) frequently when developing a branch
14:28 brrt aye! that would've helped a lot
14:28 brrt next time i start a two-year branch, i'll renember to do just that :-P
14:28 nine There! Easy ;)
14:28 timotimo i tend to work like that nowadays
14:29 timotimo not that i have many long-running branches any more
14:29 brrt .oO( we can also replay a rebase of even-moar-jit on every commit on master between july 2015 and today)
14:29 timotimo well, you could call them long-running, but i'd call them "short running, then long-resting"
14:30 brrt actually, i *could* do that
14:30 brrt iteratively rebase in 'lockstep'
14:31 brrt i.e. add commits until 2015-07-01 from master, then 2015-07-01 from even-moar-jit, then 2015-07-02 from master, then rebase earlier branch on top of that, including commits from 2017-05-03… etc
14:31 brrt eh, 07-02
14:31 brrt i mean, it's just… a graph, and we can modify it any way we like
14:32 nine At that point I wonder if it's worth it
14:32 brrt i know it ain't.
14:32 brrt but
14:32 brrt it is possible
14:32 brrt :-)
14:32 brrt and it would've given us the same result as if i had regularly-rebased it in the past
14:33 timotimo hah
14:55 brrt joined #moarvm
15:20 ilmari joined #moarvm
15:22 sivoais joined #moarvm
15:26 brrt joined #moarvm
15:27 Geth ¦ MoarVM/even-moar-jit: 2100f25f33 | (Bart Wiegmans)++ | build/Makefile.in
15:27 Geth ¦ MoarVM/even-moar-jit: Add old-style suffix rule for dynasm compilation
15:27 Geth ¦ MoarVM/even-moar-jit:
15:27 Geth ¦ MoarVM/even-moar-jit: This will work when we rename the dynasm file to whatever else,
15:27 Geth ¦ MoarVM/even-moar-jit: which is a nice little cleanup
15:27 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2100f25f33
15:27 Geth ¦ MoarVM/even-moar-jit: 892f1fff91 | (Bart Wiegmans)++ | 8 files
15:27 Geth ¦ MoarVM/even-moar-jit: Add old-style inference rules for expr and tile lists
15:27 Geth ¦ MoarVM/even-moar-jit:
15:27 Geth ¦ MoarVM/even-moar-jit: Especially for expr lists this is interesting because we want to support
15:27 Geth ¦ MoarVM/even-moar-jit: per-REPR templates, and that has just become a bit easier to build.
15:27 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/892f1fff91
15:28 brrt see, much more productive than rebasing
15:35 brrt oh boy, i'm looking at my todo list again :-o
15:35 brrt it's scary
16:05 Ven`` joined #moarvm
16:35 vendethiel- joined #moarvm
17:14 timotimo did you already put the optimizer in? :)
17:33 nine Oh, my unboxing doesn't actually unbox yet. Because the compiler adds a box_i for me. How...unhelpful :/
17:33 nine How can I avoid that?
17:40 dogbert2 joined #moarvm
17:42 nine Ah, I guess a :returns on the QAST::Var. Now where do I get the appropriate native type from?
17:44 timotimo you need one of the "primspec" ops
17:44 timotimo nine: but :returns in the right address
17:48 nine Does the :returns on a :decl<param> Var do what I mean?
17:50 timotimo i think so, but i'd have to study other code
17:51 timotimo you probably need to repeat the :returns everywhere you use the var
17:51 timotimo so it knows you want it in that type, rather than boxed
17:53 nine Oh, but nqp::objprimspec doesn't give me a type, but only a number corresponding to a type
17:53 nine For :returns I need NQP's int type object I think
17:57 nine In other words...a bootint!
17:59 lizmat_ joined #moarvm
18:01 timotimo oh, it does?
18:01 timotimo i'd look how tthe optimizer handles this :)
18:01 nine Which Perl6 apparently HLLizes immediately...
18:02 timotimo oh, huh. yeah, all other parts using that aren't in the perl6 hll
18:03 nine No, it doesn't. nqp::getattr($block.list[*-1], QAST::Node, '$!returns').^name still gives me a BOOTInt, yet the hllization is still there
18:14 nine I'm half a mind to just rip the box_i op out of the MAST tree there...
18:18 timotimo oh my
18:18 timotimo that sounds bad :)
18:20 nine Well I'm running out of ideas
18:24 timotimo shouldn't anything that gives you the right objprimspec back be right for native stuff?
18:24 timotimo i.e. a perl6-level native int type object?
18:28 nine This is about the value. The code should unbox the value into a local, so the JITed code can access it directly: https://github.com/rakudo/rakudo/blob/jit_nativecall/lib/NativeCall.pm6#L375
18:30 nine But the MAST compiler adds the box_i call: https://gist.github.com/niner/45702763ec437ac579ced93cf28b45a8
18:35 timotimo isconcrete only works on object values, doesn't it?
18:35 timotimo perhaps that's why it boxes?
18:37 robertle joined #moarvm
18:47 nine But it seems to box the results of the unbox?
18:49 timotimo :o
18:49 timotimo sorry, doing about 5 things at the same time
18:54 timotimo not used to reading this format at all
19:01 timotimo i don't actually see the code you really have there, but i'd expect the trouble comes mostly from the if + isconcrete
19:02 timotimo so maybe have an extra branch for primspec being > 0 but not rw
19:04 nine That's simple to test: https://gist.github.com/niner/f6f590739a94bfd73337c9b899d6704c
19:04 nine Now it's just the decont + bind at it still hllzies
19:08 Ven joined #moarvm
19:51 zakharyas joined #moarvm
20:11 leont joined #moarvm
20:18 * jnthn is safely home from SPW + vacation :)
20:18 yoleaux 29 Aug 2017 12:17Z <raschipi> jnthn: Does Cro support Http/2 over non-tls connections?
20:18 yoleaux 30 Aug 2017 20:12Z <brrt> jnthn: i notice a bunch of jgb_sc_wb calls to things where the operand might be an integer rather than an object
20:18 yoleaux 04:08Z <AlexDaniel> jnthn: FWIW https://rt.perl.org/Ticket/Display.html?id=131961#txn-1486128
20:19 nine jnthn: hope you enjoyed the trip :)
20:20 lizmat jnthn o/
20:20 jnthn .tell raschipi Yes, but you must then configure it as HTTP/2 only (pass :http<2> to Cro::HTTP::Server). Having an endpoint doing HTTP/1.1 or HTTP/2.0 is the thing that requires TLS (because it uses ALPN to do the decision making).
20:20 yoleaux jnthn: I'll pass your message to raschipi.
20:23 jnthn nine: Yeah; we were especially glad that we decided to break the journey in St Anton, but then once we were there were sad we'd only got 2 nights. Guess we'll be heading back at some point... :-)
20:23 jnthn Hopefully when they're done working on the Linz - Rybnik railway line so there's no need to endure a bus, that then manages to break down... :P
20:24 nine jnthn: well trains can just stop at half of the way, too as I've learned on my way to Switzerland ;)
20:25 jnthn hah, yeah, we got a delay in Switzerland on the Montreux - St Anton leg also that made us arrive 2 hours later than planned...
20:25 jnthn Apparently running a railway is hard work.
20:26 jnthn Anyways, I'll probably be relaxing the next days from the travel, and then will try to get back into things again. :)
20:26 nine Sounds like a good plan :)
20:27 nine Next couple of days will be rainy, so I should be able to get some more coding done
20:27 moritz and yes, railway is hard. It's a distributed system with many stakeholders with conflicting interests
20:46 japhb jnthn: I have questions, but I BELIEVE IN REST, so ... when do you think you are going to be in the head space for non-critical questions again?  I'll hold off until then.
20:46 jnthn japhb: Sunday/Monday-ish :)
20:48 japhb Excellent, thank you.  Enjoy your rest!  :-)
20:59 samcv good *
21:00 japhb Good *, samcv
21:00 japhb .oO( * where Afternoon )
21:18 samcv i'm thinking i should not allocate 16Kb onto the stack
21:18 samcv but i wanted to know what you guys think
21:19 samcv i mean it should be fine on linux, but i don't know about other OS's like bsd's
21:21 japhb Zoffix++  # Hugging post
21:23 Zoffix \o/
21:25 japhb I seriously ? when you \o/ a ++
21:28 Zoffix :)
21:33 AlexDaniel u: ?
21:33 unicodable6 AlexDaniel, U+2764 HEAVY BLACK HEART [So] (?)
21:33 AlexDaniel oh, heavy
21:43 japhb For a native English speaker, that character name has a lot of emotional content that has nothing to do with its semantic meaning.  :-/
21:46 stmuk_ joined #moarvm
21:49 samcv maybe it weights a lot?
21:49 samcv :P
21:50 samcv idk do they mean heavy as in thick? maybe bold?
21:50 samcv u: black heart
21:50 unicodable6 samcv, U+2665 BLACK HEART SUIT [So] (?)
21:50 unicodable6 samcv, U+2764 HEAVY BLACK HEART [So] (?)
21:50 unicodable6 samcv, 4 characters in total (???????): https://gist.github.com/fafd241a1759f5d3963091176721a998
21:51 samcv they look the same for my font at least
21:52 japhb I think HEAVY is meant to be bold, yeah.  Though clearly fonts don't necessarily show that.
22:18 leont joined #moarvm
22:25 Ven`` joined #moarvm

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