github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:21 lucasb left 07:33 AlexDaniel joined 09:24 robertle joined 12:50 Kaiepi left 12:52 Kaiepi joined 13:04 Kaiepi left 13:07 Kaiepi joined 13:16 Kaiepi left 13:17 Kaiepi joined 13:37 lucasb joined, Kaiepi left, Kaiepi joined
dogbert17 drops needle 14:16
timotimo bursts
dogbert17 timotimo: hi, can you merge github.com/MoarVM/MoarVM/pull/1047 or is that a job for jnthn? 14:17
timotimo can probably just do it 14:18
Geth MoarVM: 62b58164a8 | (Nick Logan)++ (committed by timo) | 2 files
Update libuv to 1.26
dogbert17 yay, now we're uptodate 14:19
jnthn Yeah, it's a good time to do that :) 14:20
dogbert17 I'll run a stresstest with that on my 32 bit vm. I think it'll work though 14:21
wasn't there a recent release of libtommath as well, hmm 14:24
timotimo yep 14:29
dogbert17 should we update to that at as well?
timotimo yeah, i'd say so 14:34
dogbert17 is this the commit we want? github.com/libtom/libtommath/commi...c6473a9c55 14:40
14:42 Kaiepi left
timotimo could very well be 14:42
do we have to do anything in our repo to reflect the license change?
dogbert17 hides, someone else will have to answer that :) 14:43
14:45 Kaiepi joined 14:48 Kaiepi left 15:25 Kaiepi joined
jnthn Hm, how does the license change? 15:28
15:32 AlexDaniel` left
timotimo turns from wtfpl to unlicense 15:41
both are attempts at public-domaining the work
15:46 AlexDaniel` joined 16:52 domidumont joined 17:37 ggoebel joined 18:17 AlexDaniel left 18:18 AlexDaniel joined
dogbert17 jnthn: if you're on the hunt for moar-pea problems you can find them here: gist.github.com/dogbert17/e6b0d003...9513d780cd 18:43
19:31 ggoebel left 20:16 lucasb left
ugexe $ nqp -e 'my int $x := 10000; my $t := nqp::newthread({1}, 0, 0); nqp::threadrun($t);' 21:10
yoleaux 20:08Z <uzl> ugexe: Can you show with a simple example how it can be done? BTW, I'm referring to this: colabti.org/irclogger/irclogger_lo...03-16#l157
ugexe const_iX NYI
i'm trying to add a 3 parameter to nqp::newthread, but I'm getting that const_iX NYI error and i'm not sure why or how to figure out where its coming from
timotimo ugexe: that's usually memory corruption 21:11
ugexe gist.github.com/ugexe/09d8220ca204...2fc27a9261 is there anything special i need to do when adding a member to a struct? 21:16
timotimo oh 21:17
if you want to change an op, you'll have to run generate_ops.p6
nine_ and start at src/core/oplist
ugexe its a little odd that app_lifetime is a MVMint32 in the struct and MVMint64 in function parameters, but changing that didn't fix it
timotimo but since it's an op that's also used in nqp - at least possibly? - it'll involve a bootstrap/circularity cycle 21:18
ah, yes, start at the oplist
what you're currently getting is that the code gen generates newthread with two operands, but the interpreter reads three operands
ugexe ah ok. i didnt think to do those things for editing, only adding new ones
timotimo so it'll read the next opcode as an operand, and the first operant of the next opcode as the opcode
there's no way to put that change between newthread and runthread? 21:19
ugexe no, it was suggested to add stack-size to Therad.new, so part of it must be in nqp::newthread. but uv_create_thread_ex is in runthread 21:20
timotimo doesn't have to be in nqp::newthread just because it's in Thread.new 21:21
Thread.new could call nqp::setthreadstacksize or whatever
btw adding new ops can be done in the middle, too, if you find a deprecated op that's got a fitting signature it won't even make a huge diff 21:22
ugexe ah i see. if you have a suggestion on how to better accomidate lmk
timotimo is that for total stack size, like a limit, or for initial stack size? 21:23
ugexe although setting the stacksize would only make sense at certain times
initial stack size
If UV_THREAD_HAS_STACK_SIZE is set, stack_size specifies a stack size for the new thread. 0 indicates that the default value should be used, i.e. behaves as if the flag was not set. Other values will be rounded up to the nearest page boundary.
jvm is fairly simple as well 21:24
- ((VMThreadInstance)thread).thread = new Thread(new CodeRunnable(tc.gc, thread, code));
+ ((VMThreadInstance)thread).thread = new Thread(new CodeRunnable(tc.gc, thread, code, stackSize));
plus changing the func parameters and JAST mapping thing 21:25
but the java impl above follows the api i was using (passing in to thread.new), although i dont know if that suggests its the reasonable choice 21:26
21:32 domidumont left
ugexe alright updating oplist and rerunning generate_ops.p6 was all that was needed 21:33
timotimo well, let's hope nqp::newthread doesn't show up in nqp's code :) 21:35
i do believe it shows up in the tests, but that doesn't cause trouble, since that isn't needed to build nqp itself
ugexe yea i had to fix the tests but that was it
timotimo OK, nice
ugexe should stack-size be a public attribute of Thread? 21:42
because i'm not sure we can get the stack size from a thread (i.e. determining the default) 21:43
so it would always be 0 unless the user set it
Geth MoarVM: ugexe++ created pull request #1069:
Give MVM_thread_new a stack size parameter		 21:47
MoarVM/jit-expr-float: 16 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/7...829b209970		 22:22
22:39 brrt joined
brrt ohai 22:48
timotimo yo
brrt I'm trying to finally write a blog about the optimization problem I've been banging on about here 22:51
timotimo yeah 22:53
brrt I think we can do some form of state-machine building for the optimizer 23:20
ugexe someone want to look at merging github.com/MoarVM/MoarVM/pull/1049 so I don't have to keep updating op conflicts? 23:21
brrt ehm. hmm 23:27
i've nothing against it per se...
but I'm going to defer the decision nevertheless
timotimo i'm not against it 23:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!