Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-09

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

All times shown according to UTC.

Time Nick Message
00:01 timotimo thank you, that'll either ease my mind or crush me with guilt :P
00:01 hoelzro we shall see >:)
00:06 btyler hoelzro: has anyone already mentioned the build failure on OSX? bisected it to 67a0f6 (openpipe patch), the failure is waitpid being called in fileops.c with only one arg
00:06 hoelzro btyler: which openpipe patch?
00:06 hoelzro if it's mine, you can consider it abandoned =)
00:07 btyler hm, ok. maybe FROGGS++ would be a better poke then, sorry
00:09 hoelzro np =)
00:09 hoelzro I don't know if FROGGS' patch ever calls waitpid, though
00:10 hoelzro timotimo: backing out this branch is proving difficult =/
00:15 timotimo your stuff probably requires newer wommits to be in place? :(
00:16 hoelzro I'll try just moving back to that commit
00:16 hoelzro I'll try
00:16 hoelzro testing URI shouldn't be *too* bad
00:16 * hoelzro crosses his fingers
00:21 btyler in the hope that this is helpful to someone clogging: looks like waitpid was introduced in 67a0f6f to io/fileops.c at 291 and 6model/reprs/MVMOSHandle.c 61. it bombs during building on OSX because waitpid expects 3 params
00:26 hoelzro timotimo: well, it's hard to tell; I get a different error entirely when using an older moar
00:27 hoelzro btyler: I'll have a look
00:29 hoelzro well, I believe those waitpids are redundant, since libuv calls waitpid on its own
00:30 hoelzro I'll try playing around (tomorrow) to see if I can fix that
00:31 btyler woo
01:59 FROGGS_ joined #moarvm
02:28 JimmyZ FROGGS: I think https://github.com/MoarVM/MoarVM/commit/c2b3c94486e9db6dbf7185f1eb05c610657cb0bb is not needed
02:30 JimmyZ FROGGS: MVM_string_utf8_encode_C_string won't trigger GC
03:00 colomon joined #moarvm
03:00 FROGGS__ joined #moarvm
05:13 jvicondoa joined #moarvm
05:29 rurban_ joined #moarvm
05:35 cognominal joined #moarvm
06:21 cognominal joined #moarvm
06:36 japhb_ joined #moarvm
06:39 japhb joined #moarvm
07:22 FROGGS__ morning
07:27 JimmyZ FROGGS: morning, I had a message for you
07:27 FROGGS JimmyZ: morning
07:27 FROGGS do you still have a msg for me?
07:28 JimmyZ FROGGS: see irclog
07:28 FROGGS ahh, yeah :o)
07:29 FROGGS ahh, it was only the other way around
07:34 FROGGS feel free to revert or I will do it when I am actually awake
07:40 FROGGS /home/froggs/dev/MoarVM/src/6model/reprs/MVMOSHandle.c:65:                    waitpid(handle->body.u.process->pid);
07:40 FROGGS /home/froggs/dev/MoarVM/src/io/fileops.c:297:            waitpid(handle->body.u.process->pid);
07:41 FROGGS hoelzro: note that waitpid is called twice ---^
07:41 FROGGS would be cool if libuv would call it internally...
09:46 dalek MoarVM: 784dfdd | jimmy++ | src/io/procops.c:
09:46 dalek MoarVM: Revert "protect objects against movement"
09:46 dalek MoarVM:
09:46 dalek MoarVM: This reverts commit c2b3c94486e9db6dbf7185f1eb05c610657cb0bb.
09:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/784dfdd2cd
11:39 dalek MoarVM: 7ab3433 | jnthn++ | src/io/fileops.c:
11:39 dalek MoarVM: Enable writing of uint8 buffers.
11:39 dalek MoarVM:
11:39 dalek MoarVM: Unbreaks some regressed Rakudo spectests.
11:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7ab3433aa4
11:39 dalek MoarVM: e1ff37a | jnthn++ | src/math/bigintops.c:
11:39 dalek MoarVM: Code clarity/consistency improvement; japhb++.
11:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e1ff37a0d2
11:48 jnthn m: print ~(1..10).pick(5)
11:48 camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
11:48 jnthn m: print ~(1..10).pick(5)
11:48 camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
11:48 jnthn m: print ~(1..10).pick(5)
11:48 camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
11:48 jnthn I...think we need to be a little more random than that ;)
11:49 JimmyZ :)
11:52 moritz yes, misses some srand call, I guess :-)
12:06 dalek MoarVM: 353a47f | jnthn++ | src/core/threadcontext.c:
12:06 dalek MoarVM: Initialize random seed differently each time.
12:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/353a47f0b5
12:06 dalek MoarVM: 5792266 | jnthn++ | src/io/procops.c:
12:06 dalek MoarVM: Ensure srand op controls rand_I also.
12:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/579226619f
13:21 hoelzro FROGGS: it does
15:38 timotimo m: print ~(1..10).pick(5)
15:38 camelia rakudo-moar 46234b: OUTPUT«5 8 9 6 2»
15:38 timotimo m: print ~(1..10).pick(5)
15:38 camelia rakudo-moar 46234b: OUTPUT«5 8 9 6 2»
15:38 timotimo huh.
15:38 timotimo revision not bumped?
15:39 jnthn yeah, didn't bother bumping it, figured we'd have another reason to soon enough :)
15:40 timotimo that's probably fair
16:21 FROGGS jnthn: you've seen this already? https://gist.github.com/FROGGS/a78e5ce755315e879065
16:22 FROGGS I am currently trying to bisect that error in Perl5::Terms
16:23 jnthn FROGGS: No, not seen that...
16:24 jnthn Simplest case, it's a failure to check if the buffer has enough space..but I doubt it's that.
16:26 FROGGS seems to be in a sub P5unpack
16:31 jnthn FROGGS: Maybe try this: https://gist.github.com/jnthn/da10a4abd2199c91f8a0
16:33 FROGGS jnthn: no, still crashes
16:34 jnthn OK, I've no idea then.
16:34 FROGGS seems like I can gold it down
16:34 FROGGS golf*
16:42 timotimo morgenstund' hat golf im mund
16:43 FROGGS m: sub loop( $c ) { }; loop( -> $a { $a -= 4294967296 if $a > 2147483647 } )
16:43 camelia rakudo-moar 46234b: ( no output )
16:43 FROGGS jnthn: this fails when you precompile it^^
16:46 hoelzro hmm
16:46 hoelzro so, for the waitpid thing
16:47 hoelzro libuv calls waitpid and passes the info to the exit_cb
16:47 hoelzro so I think that *maybe* the right thing to do is to run the event loop until it's called?
16:50 jnthn FROGGS: Do the exact values of the constants matter?
16:51 FROGGS lets see
16:52 FROGGS jnthn: yes
16:52 FROGGS 1 if $a > 2147483647 fails
16:52 FROGGS 1 if $a > 2147483648 passes
16:52 FROGGS 1 if $a > 2147483646 passes
16:53 jnthn eeks
16:53 * jnthn wonders a little if varint is to blame
16:54 FROGGS yeah, that sounds at least plausible
16:54 * nwc10 was wondering *exactly* that, but with little real evidence
16:55 FROGGS MoarVM/src/6model/reprs/P6bigint.h:5:#define MVM_IS_32BIT_INT(i)     (i >= -2147483648LL && i <= 2147483647LL)
16:55 FROGGS should it be i < 2147483647LL ?
16:56 FROGGS yeah, that passes
16:57 jnthn 2147483647 is representable in 31 bits, I thought?
16:57 jnthn And is max val for 32-bit int?
16:58 FROGGS perl -E 'say length sprintf "%b", 2147483647'
16:58 FROGGS 31
16:58 jnthn If you tweak that you'll force it to use a big integer, and so it'll serialize the number as a string.
16:58 jnthn Thus avoiding the varint code I suspect may be to blame.
16:59 jnthn So I think changing that hides the real issue.
16:59 FROGGS k
17:02 nwc10 (gdb) call varintsize(2147483646)
17:02 nwc10 $13 = 5
17:02 nwc10 (gdb)
17:02 nwc10 (gdb) call varintsize(2147483647)
17:02 nwc10 $14 = 1317624576693539328
17:02 nwc10 I think we have a winner.
17:03 nwc10 I never was completely comfortable with that floating point based code, but confess that I did nothing to look harder at it
17:04 nwc10 also, I'm a bit surprised by this:
17:04 nwc10 (gdb) call varintsize(64)
17:04 nwc10 $17 = 2
17:04 nwc10 (gdb) call varintsize(63)
17:04 nwc10 $18 = 1
17:04 nwc10 I thought that the change from 1 to 2 bytes should be from 127 to 128
17:06 nwc10 also, sorry, my head is still too full of cold to do anything useful to help figure this out further
17:08 FROGGS yeah, I get identical results
17:08 nwc10 OK, I have a thought. I'd be tempted to get lazy and replace the pre-calcuation code with just using a fixed temporary buffer and memcpy
17:09 nwc10 and then special case the 1 byte and 2 byte forms.
17:16 nwc10 ie - special case them to write directly and not use a temporary buffer
17:19 FROGGS ahh
17:26 nwc10 aha yes, signed integers. That's why it's 63
17:29 FROGGS dinner &
17:35 timotimo >_<
17:35 timotimo did i implement varintsize wrong?
17:35 timotimo there was already a wrongness in it before, wasn't it?
17:35 timotimo wasn't there?
17:48 jnthn Well, the first cut didn't work on Windows
17:49 jnthn But yeah, it certainly looks like something's wrong with it.
17:56 nwc10 timotimo: it looks to be "unhappy" with values of 2147483647 and over
18:01 hoelzro ok, I don't think my libuv fu is good enough to fix this
18:01 hoelzro I tried something like this: while(! handle->u.process.data) { uv_run(tc->loop, UV_DEFAULT); }
18:02 hoelzro but apparently libuv stops caring about the signal handling pipe after the first run?
18:02 hoelzro so I don't know how to reset its notion of whether it should be checking that handle
18:37 hoelzro working on this makes me wonder how the heck signal handling actually works in libuv
18:38 FROGGS I dunno
18:38 FROGGS but while(! handle->u.process.data) feels icky
18:38 FROGGS because handle->u.process.data is a pointer to an int, no?
18:38 hoelzro it's really icky
18:38 hoelzro oh, I changed that
18:38 hoelzro there was this code in openpipe:
18:39 hoelzro MVMint64 result = 0; process->data = &result;
18:39 FROGGS right
18:39 hoelzro so it's pointing to the stack data =/
18:39 hoelzro so that *could* blow things up
18:39 hoelzro but
18:39 hoelzro because you called waitpid by hand
18:39 hoelzro libuv's exit_cb is never called
18:39 hoelzro so that pointer is never written to
18:40 FROGGS hmmm
18:40 hoelzro so I had the exit handler allocate the data pointer
18:40 hoelzro but yes, the busy waiting is gross
18:41 FROGGS but at least I understand the issue now :o)
18:41 hoelzro that helps =)
18:42 hoelzro I think we may have to resort to busy waiting at the moment
18:42 hoelzro at least, in order to get libuv to play ball
18:43 hoelzro the problem *seems* to be
18:43 hoelzro that libuv exits its run loop early if it has nothing to do
18:43 hoelzro we close one end of the pipe to signal the child process that things are done
18:43 hoelzro and then I do that busy waiting thing
18:44 hoelzro so libuv thinks it no longer has work to do
18:44 FROGGS do we already have uv_unref'd that process at that time?
18:45 hoelzro I believe so
18:45 hoelzro I tried moving that around
18:45 hoelzro oh, wait, no
18:45 hoelzro the process is unref'd after the child is known to have exiting
18:45 hoelzro *exited
18:45 hoelzro the handle is unref'd first
18:46 FROGGS I have no idea what to try
18:47 hoelzro do you know if libuv has a channel?
18:47 FROGGS #libuv here on freenode
18:47 hoelzro figures =P
18:50 hoelzro hmm
18:50 hoelzro well
18:50 hoelzro I have an idea
18:50 hoelzro we don't do anything with the exit status
18:50 FROGGS we do
18:50 FROGGS ohh wait
18:50 FROGGS we dont
18:50 hoelzro not yet, anyway =)
18:51 FROGGS correct
18:51 hoelzro so we *could* just let the event loop wrap things up on its own for now
18:58 hoelzro I think that's the right thing atm
18:58 hoelzro and in the meantime, I'll try to figure out how signal handling is *actually* called
18:59 hoelzro but I'll be on vacation this week
19:14 FROGGS nwc10 / timotimo / jnthn: does this look like a valid patch for the varint bug? https://gist.github.com/FROGGS/46acab3b1f178b8196d6
19:17 hoelzro damn
19:17 hoelzro my patch has errors =/
19:17 FROGGS :(
19:21 dalek MoarVM/openpipe-waitpid-fix: 29b41ff | (Rob Hoelz)++ | src/ (3 files):
19:21 dalek MoarVM/openpipe-waitpid-fix: Attempt to fix waitpid issue on OS X
19:21 dalek MoarVM/openpipe-waitpid-fix:
19:21 dalek MoarVM/openpipe-waitpid-fix: This causes some failures on Rakudo (t/spec/S29-context/exit.t,
19:21 dalek MoarVM/openpipe-waitpid-fix: t/spec/S29-context/die.rakudo.moar), and leaves it to libuv to
19:21 dalek MoarVM/openpipe-waitpid-fix: figure out when to handle the child's exit, but we're not using the
19:21 dalek MoarVM/openpipe-waitpid-fix: exit status at the moment anyway, so that's ok (for now).
19:21 dalek MoarVM/openpipe-waitpid-fix: review: https://github.com/MoarVM/MoarVM/commit/29b41ffd6a
19:21 hoelzro that's my work
19:21 hoelzro if you're curious
19:21 hoelzro or if you have time this week
19:21 hoelzro (or if anyone else does)
19:22 FROGGS hmmm
19:23 FROGGS will think about it when my brane is not somewhere else :o)
19:23 hoelzro no rush =)
19:23 FROGGS :o)
19:31 timotimo okay i'm back to a system where i can develop
19:31 timotimo and see what's wrong with varintsize
19:31 timotimo (sorry about that)
19:32 FROGGS timotimo: would that be a valid patch? https://gist.github.com/FROGGS/46acab3b1f178b8196d6
19:32 timotimo not quite
19:33 FROGGS k
19:33 timotimo it has to handle negative values properly
19:33 FROGGS I thought doubling the value will care about the sign bit
19:34 timotimo er
19:34 timotimo the value is signed
19:35 FROGGS yes, I know
19:41 FROGGS ahh, I meant more like value = abs(value * 2);
19:42 FROGGS I updated the patch also
19:43 FROGGS I guess an LL here and there is needed too
19:45 FROGGS rakudo's stage parse is 50.5s atm... that is really lovely to see :o)
19:50 timotimo er ... i don't know if it should * 2
19:50 timotimo well, you will have checked against the existing implementation i bet! :)
19:53 FROGGS hmmm
19:53 FROGGS *2 only when it is negative makes more sense
19:54 timotimo er ... actually -1 would make more sense, no?
19:54 timotimo like sign_nudle used to do it
19:54 FROGGS but an extra bit doubles your value
19:55 timotimo yeah, but this is two's complement
19:55 timotimo you can get up to 127 or -128
19:55 timotimo not 127 to -256
19:56 FROGGS how many bytes does -63 and -64 take?
19:58 timotimo should be one, no?
19:58 timotimo oh, wait
19:58 timotimo doh :)
19:58 timotimo it's 7 bits of course
19:59 timotimo i made a handy thingie on my notebook, hold on
19:59 timotimo -64 and 63
19:59 timotimo -64 is 01000000 and 63 is 00111111
20:00 benabik -64 doesn't start with a 0
20:00 FROGGS yeah :(
20:00 benabik (Unless it's starting with 0b)
20:00 timotimo ... huh?
20:01 FROGGS okay, my code proposes two bytes for -64
20:01 timotimo that's wrong then
20:02 benabik "<timotimo> -64 is 01000000"  I think you mean either 64 is 01000000 or -64 is 11000000
20:02 timotimo hold on
20:02 timotimo i think i'm right, tbh
20:03 timotimo -64 has to be 01000000 because otherwise it would signalise that there's another byte incoming
20:03 timotimo i.e. 11000000 is not a valid varint
20:03 timotimo 11000000 00000000 would be
20:03 benabik Ahhhh...
20:04 FROGGS he is talking about the pre-varint representation
20:04 btyler joined #moarvm
20:04 timotimo ... oh
20:05 benabik Wasn't paying attention a half-hour ago when you mentioned it was varints, sorry.  ;-)
20:05 FROGGS how is the sign bit stored in a var-int anyway?
20:05 timotimo i'm glad i've already done varint and was able to stop thinking about that
20:05 timotimo it is not
20:05 timotimo var-int is 2's complement
20:07 FROGGS this passes my few tests: https://gist.github.com/FROGGS/46acab3b1f178b8196d6
20:09 timotimo you should run tests with almost all numbers :P
20:09 FROGGS and compare against what? :o)
20:09 timotimo you just have to write them out and make sure they get read back the same way :P
20:09 FROGGS >.<
20:10 FROGGS MVMP6int: Unsupported int size (-64bit)
20:10 FROGGS okay, that is some sort of answer
20:28 FROGGS that seems to work: https://gist.github.com/FROGGS/46acab3b1f178b8196d6
20:34 nwc10 FROGGS: you'll need LL
20:38 FROGGS yeah... for all of them? or just for the ll ones?
20:43 nwc10 for the ones where the constants are too large for a 32 bit long
20:43 nwc10 so I think that's the last 4
20:46 FROGGS k, thank you
20:47 timotimo whaaaat
20:47 timotimo value = abs(value++)
20:47 timotimo this is *crazy*
20:47 moritz it is also undefined
20:47 moritz in C
20:47 FROGGS hehe
20:47 FROGGS ohh
20:47 FROGGS :o9
20:47 FROGGS :o)
20:47 timotimo your compiler may now launch nethack
20:48 nwc10 yes, actually, I missed that
20:48 nwc10 you want value = -value + 1
20:48 nwc10 abs() is only defined on ints
20:49 nwc10 and our problem values are, um, larger than ints
20:49 dalek MoarVM/maybe-varintfix: 5dec933 | (Tobias Leich)++ | src/6model/serialization.c:
20:49 dalek MoarVM/maybe-varintfix: possible fix for varintsize(2147483647)
20:49 dalek MoarVM/maybe-varintfix: review: https://github.com/MoarVM/MoarVM/commit/5dec933fe7
20:49 FROGGS k
20:49 FROGGS -value -1 then, no?
20:50 nwc10 er, maybe. I have a cold. That's my excuse
20:50 FROGGS *g*
20:51 dalek MoarVM/maybe-varintfix: fbf2a00 | (Tobias Leich)++ | src/6model/serialization.c:
20:51 dalek MoarVM/maybe-varintfix: do not use abs(), nwc10++
20:51 dalek MoarVM/maybe-varintfix: review: https://github.com/MoarVM/MoarVM/commit/fbf2a00e8a
20:52 jnthn We should probably add some tests to t/serialization/ for this fix also.
20:53 jnthn I suspect just serializing a native int array with some interesting values in would do it.
20:56 FROGGS yeah, I'll do that tomorrow after $dayjob
20:57 jnthn Great, thanks :)
20:57 FROGGS :o)
20:58 FROGGS I really hope $dayjob sucks less tomorrow though
20:58 FROGGS spent most of the weekend to be sort of prepared for monday morning
20:59 FROGGS besides that it is nice that v5-m is running again and passed 50 more tests (single tests, not files)
21:03 timotimo \o/
21:06 timotimo you can use labs instead of -value + 1
21:06 timotimo labs is abs for long
21:08 timotimo actually llabs perhaps
21:09 jnthn Is labs available portably?
21:12 timotimo i would have suggested to try to compile it and see if msvc complains
21:13 timotimo but we know how that turned out for log2
21:14 timotimo ansi-c prescribes abs, labs, llabs, but does that help us?
21:14 timotimo c89 only includes labs, not llabs
21:15 FROGGS -value ftw!
21:15 timotimo yeah >_>
22:17 btyler joined #moarvm
22:20 jnthn 99.51% :)
22:24 timotimo ooooh very nice!
22:25 timotimo ah, we fail less arith tests, too!
22:25 colomon joined #moarvm
22:26 jnthn Yeah, only one left in that area is power.t iirc
22:27 timotimo ossum
22:27 timotimo we can maths!
22:31 jnthn Unless it's calculating sizes for varints... :P
22:33 timotimo :)
22:33 timotimo that was probably from using abs inside the log function actually
22:33 timotimo if it overflowed, it suddenly turned negative and got absed? or something like that?
22:33 timotimo so maybe the maybe-varintfix could be fixed by using labs instead of abs?
23:42 camelia joined #moarvm
23:48 FROGGS joined #moarvm

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