00:50 ggoebel9 joined 01:05 ggoebel joined 01:32 vendethiel joined
[Coke] finally opened a ticket to get Moarvm macport file updated, sorry for delay. 03:33
05:47 FROGGS joined
FROGGS o/ 05:59
dalek arVM: 728fa7a | FROGGS++ | build/setup.pm:
use cross-platform devnull in build script
 06:03
06:22 vendethiel joined 06:51 zakharyas joined 06:57 Ven joined 07:03 brrt joined 07:04 vendethiel joined
brrt \o 07:05
FROGGS hi brrt 07:13
brrt hi FROGGS
jnthn morning o/ 07:58
FROGGS morning jnthn 08:00
brrt morning jnthn 08:01
FROGGS cries when looking at his work code... he'd like to run code in parallel in a POE worker, but that seems to be problematic in P5 08:02
JimmyZ it is easy by Inline::perl5 :P 08:03
masak FROGGS: worth a shot. I hear good things about POE.
nwc10 if your code objects to any sort of event loop or co-operation, maybe try metacpan.org/pod/Parallel::ForkManager ? 08:04
FROGGS masak: I use POE 08:05
though forking in a worker is the issue... I tried to apply this to my code but failed: poe.perl.org/?POE_Cookbook/Child_Pr...ses_Nested 08:06
my main event loop is a POE::Wheel::SocketFactory that handles http/https connections 08:07
08:07 vendethiel joined
brrt what's POE 08:10
FROGGS brrt: "POE is a Perl framework for reactive systems, cooperative multitasking, and network applications." 08:11
brrt ah
looks quite useful 08:12
ok, to give a minor update on my progress so far since last week 08:13
you can do code generation in two ways; linearly, using register management and pre-generation register allocation to get good results, *if* you're compiling for a RISC machine 08:15
that way is relatively simple, and would be a minor extension on what we currently have (at the cost of quite significant complexity), 08:16
or you can use a tree-form, and then you can compile whole expressions at a time 08:17
notably, moarvm bytecode can be seen as a linear IR
the latter format can generate much better code because it encodes relations between instructions in a way that the linear form does not 08:18
unless, of course, you treat the linear form like a tree
it was and still is my intention to use the tree form, *however* all then depends on what we still call an expression and what we do not
jnthn notes that what is a single instruction at VM level can be tree-ish at machine level...
brrt yes, exactly, that too 08:19
jnthn But that won't get us all the goodness since we want to avoid lots of the register writes
brrt to give a very simple example, suppose we try to generate an expresion from a basic block (or rather a set of expression, bear with me) 08:20
suppose the last of the operations is an addition
now in x86 i can do two things
three, actually
a): add register to register; b): add memory to register; c): add register to memory 08:21
jnthn FROGGS++ # warning is gone in Configure
FROGGS jnthn: and it wasn't even my fault :o) 08:22
(at least kinda not)
brrt now whichever is actually cheaper depends on whether the second operand is in a register (the previous code) and on whether we will want to store the write operand into memory (i.e. we know that it'll spill)
hence, the spill is also part of the expression 08:23
(whereas hopefully no spill is necessary for temporary variables)
hmm, i also have another plan 08:32
a actionable plan, i might add
maybe you recall i said something about using a string representation to map opcodes to c-calls 08:33
(that is to say, a string, pointer pair representation, with the string representing the code and the pointer the c function 08:34
)
jnthn Ah, think I vaguely remember
brrt well, one of the bigger advantages of that is that this can be used by the per-piece JIT as well as by the expression JIT 08:35
my plan (for integration at least) is:
for each basic block, first try to construct an expression 08:36
if you can't construct an expression, construct a graph of per-opcode nodes (as before)
well, if we'd have a table of conversions from opcode to function call, they can be added automatically to the expression 08:38
dalek arVM: f443ffd | FROGGS++ | src/io/procops.c:
let libuv autoquote cmd line args on windows
 08:43
09:45 Ven joined 10:00 Ven joined 10:25 vendethiel joined
brrt it's quite warm here 11:06
jnthn Only a little over 20 here :) 11:08
And yays, I now have my nice dev machine, keyboard, etc. set up :)
nwc10 and coffee?
JimmyZ cherry keyboard?
jnthn It's a split keyboard...I've had it for years... 11:09
And they don't make the same model any more.
nwc10 jnthn: you're aware of obra's new crazy keyboard? www.kickstarter.com/projects/keybo...for-seriou
brrt wow 11:11
even the way they've described it
a heirloom keyboard
JimmyZ there is a camelia on the keyboard ... 11:12
which is perl6-friendly ,hahah 11:13
brrt as if in 50 year's people will be using an USB plug for their keyboard
jnthn nwc10: Yeah, saw that one. :) 11:23
brrt errand & 11:53
12:07 vendethiel joined 12:17 ggoebel joined
flussence on the one hand, that looks like the sort of keyboard I've dreamed of having... on the other, that was before I became a prolific AltGr [ab]user :D 12:25
dalek arVM: a6330f7 | jnthn++ | src/math/bigintops.c:
Add missing concreteness check on bigint ops.
 12:35
jnthn And that was le SEGV 12:37
12:43 vendethiel joined 13:27 vendethiel joined 13:56 vendethiel joined 13:59 JimmyZ_ joined 14:21 Ven joined 14:22 vendethiel joined 14:35 FROGGS[mobile] joined
timotimo i wonder if it's easy to figure out during a GC run whether or not a given jit code segment has an instruction pointer or a return address point at it from any of the threads 15:54
if it's simple-ish, maybe i'll go ahead and write a "merge small jit code segments into big jit code segments" thing; though i'm not sure if there are any absolute jumps in these code segments at all that need fixing up
jnthn looks confusedly at timotimo's suggestion 15:55
timotimo i've talked about this a while back 15:56
due to having to make the jit code segments either writable or executable, we have to (potentially) waste a whole page on even the smallest pieces of bytecode we spit out 15:57
hm, though i remember now: the problem was that we had to also be able to free jit code segments 15:58
i suppose i'm just starting to feel a bit useless, what with not writing moarvm/rakudo code in a bit 16:04
so i may be jumping at straws :)
jnthn Yeah...there's probably more useful things to work at... :)
timotimo i think today i'll run a spectest and try out a few libraries to see if merge_facts_at_phi is good to be merged
jnthn ponders whether to have dinner or do more pre-comp bughunt 16:05
Ah, let's do 30 mins more, maybe I'll find it... :) 16:06
timotimo got something simple-ish you'd like me to point my eyeballs & fingers at? 16:07
jnthn Well, I dunno how simple it'll be, but there's a spesh bug exposed in rt.perl.org/Ticket/Display.html?id=125408 16:08
JimmyZ_ timotimo: engineering a compiler is a nice book, maybe we can steal some ideas from there. 16:14
timotimo ah, yeah 16:15
i looked at the spesh log and it didn't seem suspicious :\
i'll take another look
16:15 Ven joined
JimmyZ_ I saw many spesh idea from that book . 16:15
timotimo i'll try to reproduce it, that ought to help
JimmyZ_ hopes jnthn++ will push his old ea branch, he wants to learn something from there too. 😊 16:17
dalek arVM: 017d184 | jnthn++ | src/6model/6model.h:
Expose HOW accessors in API.
 16:22
[Coke] .seen curisovidpoe 16:23
timotimo curtis* 16:48
alternatively: curious 16:49
17:19 FROGGS joined
FROGGS nebuchadnezzar: hi, is it possible that the reproducable build fixes are not in yet? 17:24
nebuchadnezzar: I'm just wondering because these two sites show different stats: tracker.debian.org/pkg/moarvm and packages.qa.debian.org/m/moarvm.html 17:25
18:09 ggoebel2 joined
nebuchadnezzar FROGGS: yes, the fixes are not yet commited, + Arturo ask an experimental branch on latest git to check mips build 19:16
FROGGS ahh, okay 19:17
19:30 dalek joined 19:32 TEttinger joined
timotimo turns out i didn't actually attempt to reproduce that problem 19:37
instead, i read a webcomic, cooked and ate
jnthn Food is important too :) 19:43
masak as are webcomics 19:58
21:17 FROGGS_ joined 23:38 vendethiel joined
timotimo to be fair, if i want to find some hard to crack spesh failures :\ 23:45
doesn't need to be the CArray thing
but it definitely helps that it's happened to a user rather than "just in theory if we make moar more aggressive"
agressive*

Powered by Cro and the Raku® Programming Language.

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

Thank you!