samcv \o/ it works 00:20
Zoffix \o/ 00:21
00:21 geekosaur joined
samcv it's not like perfectly clean. toward the end i find the bad elements which is basically the PropertyValueAliases line 00:21
gc ; C ; Other # Cc | Cf | Cn | Co | Cs
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
a little hackish but it works
so i'll take it!
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:23
not totally finished got to get Letter working but L works and C works 00:32
and Letter is correct in one of the data structures just need to get it into the other one.. 00:57
01:31 geekosaur joined 01:52 ilbot3 joined
samcv mad scientist cackle 01:53
now to remove all the extra code which didn't work and leave only the code that actually works 01:54
02:56 MasterDuke joined 04:28 Ven`` joined
Geth MoarVM: samcv++ created pull request #670:
Update Unicode database for Unicode 10		 05:21
MoarVM: bea907b4b0 | (Samantha McVey)++ | 4 files
Update Unicode database for Unicode 10

Also make changes to the Unicode database so property values are unique for each property.		 05:51
MoarVM: 79654248b0 | (Samantha McVey)++ (committed using GitHub Web editor) | 4 files
Merge pull request #670 from samcv/property-value-2

Update Unicode database for Unicode 10
06:16 brrt joined
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
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:23
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
yoleaux brrt: I'll pass your message to nine.
samcv good * 06:27
brrt ohai samcv 06:28
hows your fight with uc2dc.pl ending
samcv i won 06:39
a fight is the best description
brrt good 06:40
samcv Added Korean codepoint names too
brrt are you ready to tell glorious tales about it as well?
samcv and property values are now distinct
haha
07:24 lizmat joined 07:40 brrt joined 07:54 leont joined
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
06:24Z <brrt> nine: we now explicitly unwind the stack in the implmeentation of the return ops, so that's no longer necesary
brrt aye, i know 08:00
yesterday i learned
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?
brrt i fixed dynasm to be able to select the full range of registers 08:02
this was one wondrous adventure
at the end, i thought, maybe it would've been simpler to have some other assembly abstraction
on the other hand, that would never have allowed me to 'fit in' the legacy JIT as easy as it is now 08:03
08:03 zakharyas joined
nine So it can be used without going through the dasc compiler? 08:03
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
no, it still goes through dynasm
dynasm is and remains the assembly backend for both JITs
but dynasm is a really, really thin layer of abstraction 08:05
so i'm not too worried about that
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
using: Rq(1), Rq(2), Rq(11) etc
that was what i fixed :-)
nine ah, and there you can say Rq(num_gpr) 08:07
lizmat samcv++ # Unicode 10 support 08:10
BTW, is there a way to introspect which version of Unicode is supported?
samcv thanks lizmat :)
no
lizmat :-(
samcv lizmat, also property values are now unique
lizmat cool! 08:11
samcv yeah
lizmat but being able to introspect version would be something nice to have :-)
in the future :-)
samcv uhm is there an already existing thing that returns data
i should latch it onto?
lizmat samcv: what is that thing?
samcv like nqp::getmoarinfo 08:12
brrt aye!
samcv ^ i made that up
brrt i think there is something yes
lizmat is that thing documented ?
lizmat was told all of the interesting nqp:: ops are actually undocumented :-) 08:13
brrt hmm
hehe
.oO( the documentation, thats just interp.c, right? )
samcv hehe
nine pretty much yes :)
samcv that's what i look at when i don't know what an op does
and find the moarvm function that it coorasponds to
i've been documenting all my ops! 08:14
practically
08:19 dogbert2 joined
samcv ok now i documented the variations of index(ic)?(im)? and eqat(ic)?(im)? 08:22
nine samcv++ 08:23
samcv and i updated unicmp to the latest yesterday or day before to how i changed the bitmask
i added a script that will print out all the undocumented nqp ops 08:54
lizmat :-)
samcv or at least all the ones not found with .contains in the ops.markdown 08:55
only shows ones added to QASTOpretionsMAST
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
lizmat, is there a way to do a cube root or some other non square root? 08:56
lizmat m: dd 27**1/3 # samcv 08:57
camelia 9.0?
lizmat hmmm
samcv i couldn't find anything on docs.perl6.org
lizmat m: dd 27**(1/3) # samcv 08:58
camelia 3e0?
samcv wellllllll
lizmat :-)
samcv technically that works
lizmat yup
samcv would be nice if we could keyword root
and say to do that
lizmat perhaps. or it could be module spaced :-)
afk for a bit&
08:59 leont joined 09:16 Ven`` joined
nine OMG IT LIVES! 09:35
What have I done?
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:37
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
timotimo i don't get it :) 09:44
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:46
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; 09:48
Does that help? 10:01
Geth MoarVM/jit_nativecall: 59c737ab76 | (Stefan Seifert)++ | 3 files
Dynamically determine register for return value and type

This replaces assumptions about which locals the high level code uses for storing the return type and for expecting the return value by accessing the register numbers stored in the byte code for nativecallinvokejit instructions. 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(cur_op, whatever) in interp.c. Same for return values. When in interp.c you'd write GET_REG(cur_op, 0) = ...; you tell the JIT: node->u.call.rv_mode = MVM_JIT_RV_DYNIDX; box_rv_node->u.call.rv_idx = 0;		 10:13
MoarVM: duke-m++ created pull request #671:
MVM_IS_32BIT_INT(i) with explicit casts		 10:18
brrt wait, what 10:26
you use get_cur_op to do what? :-o 10:27
nine To find the place where I should put the return value of the invokenativecalljit op 10:32
And to find the place where I get the return type from for boxing (that's the first operand of the invokenativecalljit op)
Previously I used hard coded indices into the WORK array which....was fragile at best 10:33
brrt why, couldn't you read the index where you'd compile it? 10:49
nine Because at that point I don't know it yet 10:50
brrt hmm. okay, that's fair, i guess 10:53
timotimo the jit is a lot to take in over just a couple of days 10:54
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:04
brrt :-) 11:15
ilmari[m] nwc10: lunch! 12:02
(my IRC screen host seems to have fallen off the net, so I can't do it on #london.pm) 12:03
12:14 AlexDani` joined 12:17 zura joined 12:53 huggable joined
Zoffix ??? New blog post: "On Troll Hugging, Hole Digging, and Improving Open Source Communities": rakudo.party/post/On-Troll-Hugging...ommunities 12:56
nwc10 aha, there you are 13:03
this window wasn't visible
was going to ask "Is it raining?"
ilmari[m] brief showers 13:06
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
ilmari[m] (I mentioned that I was going for lunch while waiting for jenkins+puppet) 13:08
13:30 lizmat joined 13:58 zakharyas joined
brrt so, what i learned yesterday 14:19
there are cases where rebases are like, not the right thing to do
this being: a): when there is significate divergence between the original base and the new base 14:20
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.
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
(more speciifcally, if there isn't a clean 'progression' in the branch history)
mostly c and b bite 14:24
timotimo C bites most :P
brrt basically, for a rebase to work, the history-to-rebase has to be small and self-contained 14:25
if that doesn't hold, you're not actually gaining anything by the rebase
and linearly progressing!
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'
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
brrt aye! that would've helped a lot
next time i start a two-year branch, i'll renember to do just that :-P
nine There! Easy ;)
timotimo i tend to work like that nowadays
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)
timotimo well, you could call them long-running, but i'd call them "short running, then long-resting"
brrt actually, i *could* do that 14:30
iteratively rebase in 'lockstep'
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
eh, 07-02
i mean, it's just… a graph, and we can modify it any way we like
nine At that point I wonder if it's worth it 14:32
brrt i know it ain't.
but
it is possible
:-)
and it would've given us the same result as if i had regularly-rebased it in the past
timotimo hah 14:33
14:55 brrt joined 15:20 ilmari joined 15:22 sivoais joined 15:26 brrt joined
Geth MoarVM/even-moar-jit: 2100f25f33 | (Bart Wiegmans)++ | build/Makefile.in
Add old-style suffix rule for dynasm compilation

This will work when we rename the dynasm file to whatever else, which is a nice little cleanup		 15:27
MoarVM/even-moar-jit: 892f1fff91 | (Bart Wiegmans)++ | 8 files
Add old-style inference rules for expr and tile lists

Especially for expr lists this is interesting because we want to support per-REPR templates, and that has just become a bit easier to build.
brrt see, much more productive than rebasing 15:28
oh boy, i'm looking at my todo list again :-o 15:35
it's scary
16:05 Ven`` joined 16:35 vendethiel- joined
timotimo did you already put the optimizer in? :) 17:14
nine Oh, my unboxing doesn't actually unbox yet. Because the compiler adds a box_i for me. How...unhelpful :/ 17:33
How can I avoid that?
17:40 dogbert2 joined
nine Ah, I guess a :returns on the QAST::Var. Now where do I get the appropriate native type from? 17:42
timotimo you need one of the "primspec" ops 17:44
nine: but :returns in the right address
nine Does the :returns on a :decl<param> Var do what I mean? 17:48
timotimo i think so, but i'd have to study other code 17:50
you probably need to repeat the :returns everywhere you use the var 17:51
so it knows you want it in that type, rather than boxed
nine Oh, but nqp::objprimspec doesn't give me a type, but only a number corresponding to a type 17:53
For :returns I need NQP's int type object I think
In other words...a bootint! 17:57
17:59 lizmat_ joined
timotimo oh, it does? 18:01
i'd look how tthe optimizer handles this :)
nine Which Perl6 apparently HLLizes immediately...
timotimo oh, huh. yeah, all other parts using that aren't in the perl6 hll 18:02
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:03
I'm half a mind to just rip the box_i op out of the MAST tree there... 18:14
timotimo oh my 18:18
that sounds bad :)
nine Well I'm running out of ideas 18:20
timotimo shouldn't anything that gives you the right objprimspec back be right for native stuff? 18:24
i.e. a perl6-level native int type object?
nine This is about the value. The code should unbox the value into a local, so the JITed code can access it directly: github.com/rakudo/rakudo/blob/jit_...l.pm6#L375 18:28
But the MAST compiler adds the box_i call: gist.github.com/niner/45702763ec43...3cf28b45a8 18:30
timotimo isconcrete only works on object values, doesn't it? 18:35
perhaps that's why it boxes?
18:37 robertle joined
nine But it seems to box the results of the unbox? 18:47
timotimo :o 18:49
sorry, doing about 5 things at the same time
not used to reading this format at all 18:54
i don't actually see the code you really have there, but i'd expect the trouble comes mostly from the if + isconcrete 19:01
so maybe have an extra branch for primspec being > 0 but not rw 19:02
nine That's simple to test: gist.github.com/niner/f6f590739a94...b899d6704c 19:04
Now it's just the decont + bind at it still hllzies
19:08 Ven joined 19:51 zakharyas joined 20:11 leont joined
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?
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
04:08Z <AlexDaniel> jnthn: FWIW rt.perl.org/Ticket/Display.html?id...xn-1486128
nine jnthn: hope you enjoyed the trip :) 20:19
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).
yoleaux jnthn: I'll pass your message to raschipi.
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
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
nine jnthn: well trains can just stop at half of the way, too as I've learned on my way to Switzerland ;) 20:24
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
Apparently running a railway is hard work.
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 :)
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
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 :)
japhb Excellent, thank you. Enjoy your rest! :-) 20:48
samcv good * 20:59
japhb Good *, samcv 21:00
.oO( * where Afternoon )
samcv i'm thinking i should not allocate 16Kb onto the stack 21:18
but i wanted to know what you guys think
i mean it should be fine on linux, but i don't know about other OS's like bsd's 21:19
japhb Zoffix++ # Hugging post 21:21
Zoffix \o/ 21:23
japhb I seriously ? when you \o/ a ++ 21:25
Zoffix :) 21:28
AlexDaniel u: ? 21:33
unicodable6 AlexDaniel, U+2764 HEAVY BLACK HEART [So] (?)
AlexDaniel oh, heavy
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:43
21:46 stmuk_ joined
samcv maybe it weights a lot? 21:49
:P
idk do they mean heavy as in thick? maybe bold? 21:50
u: black heart
unicodable6 samcv, U+2665 BLACK HEART SUIT [So] (?)
samcv, U+2764 HEAVY BLACK HEART [So] (?)
samcv, 4 characters in total (???????): gist.github.com/fafd241a1759f5d396...176721a998
samcv they look the same for my font at least 21:51
japhb I think HEAVY is meant to be bold, yeah. Though clearly fonts don't necessarily show that. 21:52
22:18 leont joined 22:25 Ven`` 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!