timotimo thank you, that'll either ease my mind or crush me with guilt :P 00:01
hoelzro we shall see >:)
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?
if it's mine, you can consider it abandoned =)
btyler hm, ok. maybe FROGGS++ would be a better poke then, sorry 00:07
hoelzro np =) 00:09
I don't know if FROGGS' patch ever calls waitpid, though
timotimo: backing out this branch is proving difficult =/ 00:10
timotimo your stuff probably requires newer wommits to be in place? :( 00:15
hoelzro I'll try just moving back to that commit 00:16
I'll try
testing URI shouldn't be *too* bad
hoelzro crosses his fingers
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:21
hoelzro timotimo: well, it's hard to tell; I get a different error entirely when using an older moar 00:26
btyler: I'll have a look 00:27
well, I believe those waitpids are redundant, since libuv calls waitpid on its own 00:29
I'll try playing around (tomorrow) to see if I can fix that 00:30
btyler woo 00:31
01:59 FROGGS_ joined
JimmyZ FROGGS: I think github.com/MoarVM/MoarVM/commit/c2...10657cb0bb is not needed 02:28
FROGGS: MVM_string_utf8_encode_C_string won't trigger GC 02:30
03:00 colomon joined, FROGGS__ joined 05:13 jvicondoa joined 05:29 rurban_ joined 05:35 cognominal joined 06:21 cognominal joined 06:36 japhb_ joined 06:39 japhb joined
FROGGS__ morning 07:22
JimmyZ FROGGS: morning, I had a message for you 07:27
FROGGS JimmyZ: morning
do you still have a msg for me?
JimmyZ FROGGS: see irclog 07:28
FROGGS ahh, yeah :o)
ahh, it was only the other way around 07:29
feel free to revert or I will do it when I am actually awake 07:34
/home/froggs/dev/MoarVM/src/6model/reprs/MVMOSHandle.c:65: waitpid(handle->body.u.process->pid); 07:40
/home/froggs/dev/MoarVM/src/io/fileops.c:297: waitpid(handle->body.u.process->pid);
hoelzro: note that waitpid is called twice ---^ 07:41
would be cool if libuv would call it internally...
dalek arVM: 784dfdd | jimmy++ | src/io/procops.c:
Revert "protect objects against movement"

This reverts commit c2b3c94486e9db6dbf7185f1eb05c610657cb0bb.		 09:46
arVM: 7ab3433 | jnthn++ | src/io/fileops.c:
Enable writing of uint8 buffers.

Unbreaks some regressed Rakudo spectests.		 11:39
arVM: e1ff37a | jnthn++ | src/math/bigintops.c:
Code clarity/consistency improvement; japhb++.
jnthn m: print ~(1..10).pick(5) 11:48
camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
jnthn m: print ~(1..10).pick(5)
camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
jnthn m: print ~(1..10).pick(5)
camelia rakudo-moar ba1cc3: OUTPUT«5 8 9 6 2»
jnthn I...think we need to be a little more random than that ;)
JimmyZ :) 11:49
moritz yes, misses some srand call, I guess :-) 11:52
dalek arVM: 353a47f | jnthn++ | src/core/threadcontext.c:
Initialize random seed differently each time.
 12:06
arVM: 5792266 | jnthn++ | src/io/procops.c:
Ensure srand op controls rand_I also.
hoelzro FROGGS: it does 13:21
timotimo m: print ~(1..10).pick(5) 15:38
camelia rakudo-moar 46234b: OUTPUT«5 8 9 6 2»
timotimo m: print ~(1..10).pick(5)
camelia rakudo-moar 46234b: OUTPUT«5 8 9 6 2»
timotimo huh.
revision not bumped?
jnthn yeah, didn't bother bumping it, figured we'd have another reason to soon enough :) 15:39
timotimo that's probably fair 15:40
FROGGS jnthn: you've seen this already? gist.github.com/FROGGS/a78e5ce755315e879065 16:21
I am currently trying to bisect that error in Perl5::Terms 16:22
jnthn FROGGS: No, not seen that... 16:23
Simplest case, it's a failure to check if the buffer has enough space..but I doubt it's that. 16:24
FROGGS seems to be in a sub P5unpack 16:26
jnthn FROGGS: Maybe try this: gist.github.com/jnthn/da10a4abd2199c91f8a0 16:31
FROGGS jnthn: no, still crashes 16:33
jnthn OK, I've no idea then. 16:34
FROGGS seems like I can gold it down
golf*
timotimo morgenstund' hat golf im mund 16:42
FROGGS m: sub loop( $c ) { }; loop( -> $a { $a -= 4294967296 if $a > 2147483647 } ) 16:43
camelia ( no output )
FROGGS jnthn: this fails when you precompile it^^
hoelzro hmm 16:46
so, for the waitpid thing
libuv calls waitpid and passes the info to the exit_cb 16:47
so I think that *maybe* the right thing to do is to run the event loop until it's called?
jnthn FROGGS: Do the exact values of the constants matter? 16:50
FROGGS lets see 16:51
jnthn: yes 16:52
1 if $a > 2147483647 fails
1 if $a > 2147483648 passes
1 if $a > 2147483646 passes
jnthn eeks 16:53
jnthn wonders a little if varint is to blame
FROGGS yeah, that sounds at least plausible 16:54
nwc10 was wondering *exactly* that, but with little real evidence
FROGGS MoarVM/src/6model/reprs/P6bigint.h:5:#define MVM_IS_32BIT_INT(i) (i >= -2147483648LL && i <= 2147483647LL) 16:55
should it be i < 2147483647LL ?
yeah, that passes 16:56
jnthn 2147483647 is representable in 31 bits, I thought? 16:57
And is max val for 32-bit int?
FROGGS perl -E 'say length sprintf "%b", 2147483647' 16:58
31
jnthn If you tweak that you'll force it to use a big integer, and so it'll serialize the number as a string.
Thus avoiding the varint code I suspect may be to blame.
So I think changing that hides the real issue. 16:59
FROGGS k
nwc10 (gdb) call varintsize(2147483646) 17:02
$13 = 5
(gdb)
(gdb) call varintsize(2147483647)
$14 = 1317624576693539328
I think we have a winner.
I never was completely comfortable with that floating point based code, but confess that I did nothing to look harder at it 17:03
also, I'm a bit surprised by this: 17:04
(gdb) call varintsize(64)
$17 = 2
(gdb) call varintsize(63)
$18 = 1
I thought that the change from 1 to 2 bytes should be from 127 to 128
also, sorry, my head is still too full of cold to do anything useful to help figure this out further 17:06
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
and then special case the 1 byte and 2 byte forms. 17:09
ie - special case them to write directly and not use a temporary buffer 17:16
FROGGS ahh 17:19
nwc10 aha yes, signed integers. That's why it's 63 17:26
FROGGS dinner & 17:29
timotimo >_< 17:35
did i implement varintsize wrong?
there was already a wrongness in it before, wasn't it?
wasn't there?
jnthn Well, the first cut didn't work on Windows 17:48
But yeah, it certainly looks like something's wrong with it. 17:49
nwc10 timotimo: it looks to be "unhappy" with values of 2147483647 and over 17:56
hoelzro ok, I don't think my libuv fu is good enough to fix this 18:01
I tried something like this: while(! handle->u.process.data) { uv_run(tc->loop, UV_DEFAULT); }
but apparently libuv stops caring about the signal handling pipe after the first run? 18:02
so I don't know how to reset its notion of whether it should be checking that handle
working on this makes me wonder how the heck signal handling actually works in libuv 18:37
FROGGS I dunno 18:38
but while(! handle->u.process.data) feels icky
because handle->u.process.data is a pointer to an int, no?
hoelzro it's really icky
oh, I changed that
there was this code in openpipe:
MVMint64 result = 0; process->data = &result; 18:39
FROGGS right
hoelzro so it's pointing to the stack data =/
so that *could* blow things up
but
because you called waitpid by hand
libuv's exit_cb is never called
so that pointer is never written to
FROGGS hmmm 18:40
hoelzro so I had the exit handler allocate the data pointer
but yes, the busy waiting is gross
FROGGS but at least I understand the issue now :o) 18:41
hoelzro that helps =)
I think we may have to resort to busy waiting at the moment 18:42
at least, in order to get libuv to play ball
the problem *seems* to be 18:43
that libuv exits its run loop early if it has nothing to do
we close one end of the pipe to signal the child process that things are done
and then I do that busy waiting thing
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?
hoelzro I believe so 18:45
I tried moving that around
oh, wait, no
the process is unref'd after the child is known to have exiting
*exited
the handle is unref'd first
FROGGS I have no idea what to try 18:46
hoelzro do you know if libuv has a channel? 18:47
FROGGS #libuv here on freenode
hoelzro figures =P
hmm 18:50
well
I have an idea
we don't do anything with the exit status
FROGGS we do
ohh wait
we dont
hoelzro not yet, anyway =)
FROGGS correct 18:51
hoelzro so we *could* just let the event loop wrap things up on its own for now
I think that's the right thing atm 18:58
and in the meantime, I'll try to figure out how signal handling is *actually* called
but I'll be on vacation this week 18:59
FROGGS nwc10 / timotimo / jnthn: does this look like a valid patch for the varint bug? gist.github.com/FROGGS/46acab3b1f178b8196d6 19:14
hoelzro damn 19:17
my patch has errors =/
FROGGS :(
dalek arVM/openpipe-waitpid-fix: 29b41ff | (Rob Hoelz)++ | src/ (3 files):
Attempt to fix waitpid issue on OS X

This causes some failures on Rakudo (t/spec/S29-context/exit.t, t/spec/S29-context/die.rakudo.moar), and leaves it to libuv to figure out when to handle the child's exit, but we're not using the exit status at the moment anyway, so that's ok (for now).		 19:21
hoelzro that's my work
if you're curious
or if you have time this week
(or if anyone else does)
FROGGS hmmm 19:22
will think about it when my brane is not somewhere else :o) 19:23
hoelzro no rush =)
FROGGS :o)
timotimo okay i'm back to a system where i can develop 19:31
and see what's wrong with varintsize
(sorry about that)
FROGGS timotimo: would that be a valid patch? gist.github.com/FROGGS/46acab3b1f178b8196d6 19:32
timotimo not quite
FROGGS k 19:33
timotimo it has to handle negative values properly
FROGGS I thought doubling the value will care about the sign bit
timotimo er 19:34
the value is signed
FROGGS yes, I know 19:35
ahh, I meant more like value = abs(value * 2); 19:41
I updated the patch also 19:42
I guess an LL here and there is needed too 19:43
rakudo's stage parse is 50.5s atm... that is really lovely to see :o) 19:45
timotimo er ... i don't know if it should * 2 19:50
well, you will have checked against the existing implementation i bet! :)
FROGGS hmmm 19:53
*2 only when it is negative makes more sense
timotimo er ... actually -1 would make more sense, no? 19:54
like sign_nudle used to do it
FROGGS but an extra bit doubles your value
timotimo yeah, but this is two's complement 19:55
you can get up to 127 or -128
not 127 to -256
FROGGS how many bytes does -63 and -64 take? 19:56
timotimo should be one, no? 19:58
oh, wait
doh :)
it's 7 bits of course
i made a handy thingie on my notebook, hold on 19:59
-64 and 63
-64 is 01000000 and 63 is 00111111
benabik -64 doesn't start with a 0 20:00
FROGGS yeah :(
benabik (Unless it's starting with 0b)
timotimo ... huh?
FROGGS okay, my code proposes two bytes for -64 20:01
timotimo that's wrong then
benabik "<timotimo> -64 is 01000000" I think you mean either 64 is 01000000 or -64 is 11000000 20:02
timotimo hold on
i think i'm right, tbh
-64 has to be 01000000 because otherwise it would signalise that there's another byte incoming 20:03
i.e. 11000000 is not a valid varint
11000000 00000000 would be
benabik Ahhhh...
FROGGS he is talking about the pre-varint representation 20:04
20:04 btyler joined
timotimo ... oh 20:04
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?
timotimo i'm glad i've already done varint and was able to stop thinking about that
it is not
var-int is 2's complement
FROGGS this passes my few tests: gist.github.com/FROGGS/46acab3b1f178b8196d6 20:07
timotimo you should run tests with almost all numbers :P 20:09
FROGGS and compare against what? :o)
timotimo you just have to write them out and make sure they get read back the same way :P
FROGGS >.<
MVMP6int: Unsupported int size (-64bit) 20:10
okay, that is some sort of answer
that seems to work: gist.github.com/FROGGS/46acab3b1f178b8196d6 20:28
nwc10 FROGGS: you'll need LL 20:34
FROGGS yeah... for all of them? or just for the ll ones? 20:38
nwc10 for the ones where the constants are too large for a 32 bit long 20:43
so I think that's the last 4
FROGGS k, thank you 20:46
timotimo whaaaat 20:47
value = abs(value++)
this is *crazy*
moritz it is also undefined
in C
FROGGS hehe
ohh
:o9
:o)
timotimo your compiler may now launch nethack
nwc10 yes, actually, I missed that 20:48
you want value = -value + 1
abs() is only defined on ints
and our problem values are, um, larger than ints 20:49
dalek arVM/maybe-varintfix: 5dec933 | (Tobias Leich)++ | src/6model/serialization.c:
possible fix for varintsize(2147483647)
FROGGS k
-value -1 then, no?
nwc10 er, maybe. I have a cold. That's my excuse 20:50
FROGGS *g*
dalek arVM/maybe-varintfix: fbf2a00 | (Tobias Leich)++ | src/6model/serialization.c:
do not use abs(), nwc10++
 20:51
jnthn We should probably add some tests to t/serialization/ for this fix also. 20:52
I suspect just serializing a native int array with some interesting values in would do it. 20:53
FROGGS yeah, I'll do that tomorrow after $dayjob 20:56
jnthn Great, thanks :) 20:57
FROGGS :o)
I really hope $dayjob sucks less tomorrow though 20:58
spent most of the weekend to be sort of prepared for monday morning
besides that it is nice that v5-m is running again and passed 50 more tests (single tests, not files) 20:59
timotimo \o/ 21:03
you can use labs instead of -value + 1 21:06
labs is abs for long
actually llabs perhaps 21:08
jnthn Is labs available portably? 21:09
timotimo i would have suggested to try to compile it and see if msvc complains 21:12
but we know how that turned out for log2 21:13
ansi-c prescribes abs, labs, llabs, but does that help us? 21:14
c89 only includes labs, not llabs
FROGGS -value ftw! 21:15
timotimo yeah >_>
22:17 btyler joined
jnthn 99.51% :) 22:20
timotimo ooooh very nice! 22:24
ah, we fail less arith tests, too! 22:25
22:25 colomon joined
jnthn Yeah, only one left in that area is power.t iirc 22:26
timotimo ossum 22:27
we can maths!
jnthn Unless it's calculating sizes for varints... :P 22:31
timotimo :) 22:33
that was probably from using abs inside the log function actually
if it overflowed, it suddenly turned negative and got absed? or something like that?
so maybe the maybe-varintfix could be fixed by using labs instead of abs?
23:42 camelia joined 23:48 FROGGS 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!