Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-10

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

All times shown according to UTC.

Time Nick Message
00:15 robertle_ joined #moarvm
00:37 robertle joined #moarvm
01:09 robertle_ joined #moarvm
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:50 geekosaur joined #moarvm
05:49 domidumont joined #moarvm
05:52 geekosaur joined #moarvm
05:54 domidumont joined #moarvm
05:58 domidumont joined #moarvm
06:34 brrt joined #moarvm
06:34 brrt good * #moarvm
06:35 brrt i've changed my mind wrt to the holes
06:35 brrt i'm not going to do any data structures at all
06:35 brrt we're just going to do a linear search
06:35 nine Godd morning, brrt!
06:35 nine s/Godd/Good/
06:36 nine Though there's got to be a language where godd actually means good.
06:36 nine Anyway, why the change of heart?
06:36 brrt two reasons
06:37 brrt one, writing a 'generic' heap in C is actually not so hard, but the naive way requires quite a bit of allocation, which i try to avoid
06:38 brrt but two, and much more importantly, i only need them for answering 'is there a hole in this live range at point X'
06:40 brrt and that only at a few points, and so simplicity is well served by having a linear search rather than maintaining some lookup mechanism :-)
06:41 nine So that code is simply not hot enough to warrant an elaborate optimization?
06:42 brrt probably not
06:43 nine Well....then get on with making it just work :D
06:43 brrt :-D
06:43 nwc10 to the coffee machine!
06:43 nine nwc10: an excellent idea!
06:44 nwc10 (I thought this too, but I've dropped part of it and dropped the kitchen roll when trying to clean up)
06:44 nwc10 (a metal part. it's fine. I now have coffee)
06:46 nine Yep, it's a serious design flaw in humans. How are you supposed to be able to make coffee before having coffee? That we've made it so far is a miracle.
06:58 brrt joined #moarvm
07:15 lizmat some coffee machines have timers so that you can prepare it before going to bed
07:58 zakharyas joined #moarvm
08:31 brrt joined #moarvm
08:34 brrt joined #moarvm
08:36 * jnthn will soon be faced with the job of ordering a coffee machine for $new-office :)
08:36 jnthn (For now I drink at home before going there...)
08:36 nwc10 install a pipeline?
08:52 colomon_ joined #moarvm
08:53 dogbert11 sounds borderline traumatic :)
08:53 * dogbert11 sips coffee at $work :)
08:54 jnthn I believe one Czech city got fed up of beer trucks damaging/clogging the roads in their quaint old city center where the brewery was situated, so they built a beer pipeline to carry the beer out of town a bit. :-)
08:54 jnthn oh wait, it wasn't a Czech city
08:55 jnthn Bruges. http://www.geek.com/geek-cetera/belgian-citys-beer-pipeline-is-the-best-infrastructure-upgrade-ever-1605541/
08:55 nwc10 "back then?" or "even today?"
08:55 jnthn 2 miles
08:55 jnthn Of beer
08:56 nwc10 "As a Canadian, it saddens me deeply to think that we could be doing this instead of trying to use Keystone XL to pump boring old oil across the country."
08:56 nwc10 does Canada produce enough good beer to fill a pipeline? even if it's only 2 miles long?
08:57 nwc10 and given that the US is talking about reversing the flow on one of the oil piplines, surely having a beer pipeline is opening yourself up to that sort of a risk
08:57 nwc10 "We've turned it round and now we're pumping Bud Light at you as fast as we can"
08:57 moritz .oO( maple sirup pipeline! )
08:57 dogbert11 nwc10: as a Canadian, shouldn't you be asleep?
08:58 nwc10 I was quoting the article
08:58 nwc10 I think I'm 100% not Canadian
08:58 dogbert11 indeed you were :) my bad
09:00 robertle joined #moarvm
09:02 * dogbert11 obviously I need another cup of coffee
09:25 brrt yeah, /me too
09:29 nine .tell lizmat I do in fact have a filter machine with a timer :) Guess what? In the sleepy state before going to bed, errors are made. Like...forgetting to put the pot in its place. Great way to ensure the next day starts as badly as possible ;)
09:29 yoleaux nine: I'll pass your message to lizmat.
10:01 domidumont joined #moarvm
10:46 brrt joined #moarvm
11:08 brrt joined #moarvm
11:40 brrt joined #moarvm
12:13 domidumont joined #moarvm
12:20 domidumont joined #moarvm
12:51 colomon_ joined #moarvm
12:58 colomon joined #moarvm
13:25 colomon joined #moarvm
13:33 Geth ¦ MoarVM: zoffixznet++ created pull request #593: Use -1 instead of 0 when long right-shifting negative smallints
13:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/593
13:34 geekosaur joined #moarvm
14:28 Zoffix Is there a small-int version of store_bigint_result() ?
14:28 Zoffix Ah, I'd just use MVM_repr_box_int I guess
14:29 timotimo it's a very different thing
14:30 timotimo you want store_int64_result
14:30 timotimo store_*_result works with an MVMBigintBody, MVM_repr_box_int creates a completely new object
14:31 timotimo so you'd call it on different things
14:31 Zoffix Yeah, on diff things yeah
14:36 Zoffix I don't get, what's this conditional supposed to check? https://github.com/MoarVM/MoarVM/blob/master/src/math/bigintops.c#L652-L653 I'm reading docs and mp_get_int says it returns 32 least significant bits of mp_int and docs for mp_cmp_d say they compare a number against a single digit... but the "single digit" given in that conditional is the 32-least-significant-bits. Is that one digit?
14:36 Zoffix m: say 2**32
14:36 camelia rakudo-moar 643593: OUTPUT: «4294967296␤»
14:37 Zoffix Is it just checking if exponent is over 32bits?
14:38 Zoffix Seems that conditional is wrong 'cause the reason -15**1 is MVM_IS_BIG_BIG_INT is because that conditional ends up being false and judging by the stuff in its true branch, -15**1 is supposed to go into that branch
14:38 timotimo mp_int refers to one chunk as a "digit"
14:39 timotimo how big exactly these digits are can be influenced by #define
14:39 Zoffix Ah ok
14:41 Zoffix k, so the conditional is "if exponent is larger than its 32-LSB" and it checks if it's over 32bits and the branches of conditional need to be swapped
14:41 * Zoffix does so and tests
14:44 Zoffix heh
14:45 Zoffix Well, I'm hitting the right branch for -15**1 now but Rakudo don't wanna run :P crashes in def of $UINT64_UPPER
14:45 * Zoffix looks at it
14:48 Zoffix I see, my fix is no good, I think.
14:49 stmuk joined #moarvm
14:49 timotimo smallbigint was supposed to just be an optimization; i wasn't so happy when code in rakudo started relying on it (if i'm not mistaken?)
14:52 Zoffix Never mind. What I said above don't apply 'cause I read `base` as `exponent` :P
14:52 Zoffix timotimo: so you're saying MVM_ISBIG_BIG_INT giving true for -15**1 is not a bug?
14:53 timotimo it'd be better if it gave false
14:55 Zoffix Oh, it's actually always false
14:55 Zoffix m: use nqp; say nqp::pow_I(-15, nqp::unbox_i(Int(2**32)), Num, Int)
14:55 camelia rakudo-moar 643593: OUTPUT: «Inf␤»
14:55 Zoffix cause that op gives Inf for anything bigger than big int
14:56 timotimo oh?
14:56 Zoffix Well, whats' MVM_ISBIG_BIGINT? >32bits?
14:56 timotimo well, if you're exponentiating with a number that big, you're bound to run into trouble unless you're exponentiating 1
14:57 Zoffix Ah, right
14:57 Zoffix Oh right, it's not always smaller never mind
15:01 timotimo and numbers below 1 are another thing again
15:02 Zoffix will NOT MVM_ISBIG_BIGINT always fit into MVM_repr_box_int ?
15:02 timotimo since we also have 64bit int on 32bit systems, yes
15:08 brrt joined #moarvm
15:09 Zoffix Well, if fixed -15**1 being MVM_ISBIG_BIGINT true :)
15:10 Zoffix But the fix is bogus... it just does it for <32-bit ints. I've no idea what's MVM_ISBIG_BIGINT  can't do MVM_ISBIG_BIGINT(ic) in that op 'cause it don't got that property or whatever
15:11 timotimo i didn't parse that sentence
15:12 Zoffix "I don't know what I'm doing"
15:12 Zoffix :)
15:12 Zoffix I think the fix needs to be in src/6model/reprs/P6bigint.c somewhere or something
15:14 Zoffix or maybe not
15:15 timotimo there's two different concerns for the bigint is_big stuff, really
15:15 timotimo one is "is the number a big number?"
15:15 timotimo the other is "are we storing an actual mp_int struct or just a 32bit integer?"
15:16 timotimo where the 32bit integer goes into the lower half of the pointer that'd otherwise point at the mp_int struct
15:17 timotimo you can store small numbers in an mp_int even if it could fit into the 32bit integer in the lower half of the pointer
15:17 timotimo but it's some memory overhead you could save
15:17 timotimo so really, if the number's stored in those 32bits, it has to be small, but the other way around isn't guaranteed
15:27 Zoffix Thanks.
15:32 Zoffix What's mp_int->used? libtommah docs in datatypes don't really say what it it's for in 2.3 Data Types and that name is tough to search for
15:33 timotimo i expect it's one third of the typical "allocated, used, data" pattern for dynamic arrays and such
15:33 timotimo i.e. two counters and one pointer
15:34 Zoffix In mp_int struct it's got `int used, alloc, sign;`
15:34 timotimo well, yeah, there also has to be a pointer to the data
15:34 timotimo that's the third part
15:34 Zoffix Yeah mp_digit
15:34 Zoffix So what's `used` for?
15:35 timotimo so it knows how many entries in the mp_digit array are valid
15:36 Zoffix Ok. Thanks.
15:38 timotimo hm. we use mp_int in an immutable pattern, i wonder if we ever waste much data from libtommath allocating too much so it could in theory grow
15:48 Zoffix Well, I see why nqp::pow_I(-15, 1...) doesn't set the smallint flag. The MVM_IS_32BIT_INT(DIGIT(i, 0)) macro returns false.
15:49 Zoffix I think it needs a cast or something? Digit is `DIGIT(m,k) ((m)->dp[(k)])` and if I printf("%d") it tells me "15", but the comparison (i >= -2147483648LL && i <= 2147483647LL) gives 0. but if I set `int i = 15` then it gives true
15:49 Zoffix and ->dp is `mp_digit *dp` and no idea what that is
15:50 timotimo yeah, mp_digit is different depending on the #defines and #ifdefs it has at the beginning of mp_int.h or what it's called
15:50 timotimo i'd expect you'd get better info from gdb or something
15:51 * Zoffix doesn't know how to use gdb
15:51 Zoffix Changing it to MVM_IS_32BIT_INT((long long)DIGIT(i, 0))) seems to work, but I don't know if that's right or what
15:53 zakharyas joined #moarvm
15:54 Zoffix mp_digit looks to be a uint*_t
15:57 Zoffix I'll just file an Issue
15:58 timotimo i'm trying to figure it out from the output of dwarfdump but it's really unhelpful
15:58 Zoffix travis OKed PR https://github.com/MoarVM/MoarVM/pull/593
16:02 Zoffix Filed: https://github.com/MoarVM/MoarVM/issues/594
16:02 brrt joined #moarvm
16:15 domidumont joined #moarvm
16:18 domidumont joined #moarvm
16:32 stmuk_ joined #moarvm
17:28 robertle_ joined #moarvm
17:36 lizmat joined #moarvm
18:34 TimToady joined #moarvm
19:12 Geth ¦ MoarVM: 9d7bee40e4 | (Zoffix Znet)++ | src/math/bigintops.c
19:12 Geth ¦ MoarVM: Use -1 instead of 0 when long right-shifting negative smallints
19:12 Geth ¦ MoarVM:
19:12 Geth ¦ MoarVM: - The value of -1 is what falls out when you calculate with
19:12 Geth ¦ MoarVM:     fakely-big big ints, like -15**1 (that ends up going through the
19:12 Geth ¦ MoarVM:     "big int" path 'cause the flag is apparently set)
19:12 Geth ¦ MoarVM: - This is also the value you get with `div` (e.g. dd -12 div 2**32)
19:12 Geth ¦ MoarVM: - This is also the value you get on JVM backend
19:12 Geth ¦ MoarVM: <…commit message has 6 more lines…>
19:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9d7bee40e4
19:12 Geth ¦ MoarVM: f8bc328725 | timo++ (committed using GitHub Web editor) | src/math/bigintops.c
19:12 Geth ¦ MoarVM: Merge pull request #593 from zoffixznet/fix-bitshiftr_I
19:12 Geth ¦ MoarVM:
19:12 Geth ¦ MoarVM: Use -1 instead of 0 when long right-shifting negative smallints
19:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f8bc328725
19:14 timotimo Zoffix: i'm not actually sure the code is correct, but i don't know enough to really argue eithe rway
19:14 timotimo nah, i think it's fine
19:15 * Zoffix is fairly sure it's right
19:16 timotimo cool
19:17 timotimo so you'll bump moar and nqp revisions and finish up the work in rakudo for this?
19:17 Zoffix Yeah
19:19 timotimo a nice speed improvement we got there
19:25 samcv i heard speed improvement. did someone say speed improvement?
19:25 samcv good morning everyone o/
19:25 Zoffix \o
19:25 Zoffix just minor improvement to +>
19:25 Zoffix and I think to <+ too
19:26 Zoffix or whatver it was +<
19:27 Zoffix hhmmm
19:27 samcv so our values were incorrect?
19:27 samcv hmm i see
19:27 Zoffix shit. I'm fairly sure that's the right answer for negative numbers, but might not be for positive :}
19:27 samcv Zoffix, do we have enough tests :)
19:27 Zoffix but I stresstested that patch...
19:28 samcv have you checked what tests actually exist?
19:28 * Zoffix checks for positives
19:28 samcv can stresstest 1000 times but if there's only like 8 tests for something
19:28 nwc10 real positives or false positives?
19:28 nwc10 (not sure if that joke works)
19:28 Zoffix yeah, oops
19:28 Zoffix Zoffix--
19:29 Zoffix 1 sec; I'll finish the bumpage I already started and fix my bug
19:29 samcv there's like
19:29 samcv no tests for +>
19:30 Zoffix Are you for real? :S That sucks
19:30 samcv if i grep ' \+>'
19:30 samcv yes!
19:30 samcv same with +> as well
19:30 Zoffix I see a few in S03-operators/bit.t
19:31 Zoffix with grep -FR '+>'
19:31 samcv 5 tests in bit.t
19:31 samcv for +>
19:31 timotimo so was there no proper check for non-negative values?
19:31 timotimo and we should have set 0 sometimes?
19:31 timotimo that was what was tingling in the back of my mind
19:32 Zoffix timotimo: yeah, for positive numbers 0 is good but for negatives it was supposed to be -1 but we were setting to 0 in all cases
19:32 timotimo OK
19:32 timotimo you didn't push any bumps yet, right?
19:34 Zoffix no.
19:34 Zoffix I guess I shouldn't
19:36 samcv yeah let's get some good tests added to roast :)
19:38 Zoffix trying to find the right way to find if MVMP6bigintBody is negative...
19:40 Zoffix Any tips?
19:40 Zoffix Just  < 0 ?
19:40 samcv uh
19:40 samcv it uses libtommath
19:40 Zoffix I mean foo->bigint.value < 0
19:40 samcv if it's too big i don't think that will work
19:41 samcv though i haven't played with the number stuff too much
19:41 Zoffix MP_NEG == SIGN(foo->u.bigint) ?
19:41 Zoffix That?
19:43 samcv yeah that sounds good
19:43 Zoffix "Segmentation fault"
19:44 samcv it's a bigintBody or a MVMP6bigint you need to get it from
19:44 Zoffix foo is a MVMP6bigintBody
19:45 samcv MVMP6bigintBody.bigint
19:45 samcv where did the -> and u come from
19:45 samcv er you'r right it is part of the union
19:45 samcv it seems
19:45 Zoffix ‘MVMP6bigintBody’ has no member named ‘bigint’
19:46 Zoffix I think it's the first time in my life did I spend so much time figuring out if a number is negastive...
19:46 Zoffix C sucks
19:46 samcv well then it mus have foo->u.value
19:46 samcv since it can have multiple things
19:47 Zoffix ‘union <anonymous>’ has no member named ‘value’
19:47 Zoffix I need to relocate
19:47 samcv Zoffix, where are you editing? which var?
19:47 samcv i will try it
19:47 samcv same as in that commit?
19:48 samcv bb/
19:48 samcv ?
19:49 Zoffix samcv: this line needs to be changed to store_int64_result(bb, IF-NEGATIVE(ba) ? -1 : 0);  https://github.com/MoarVM/MoarVM/blob/master/src/math/bigintops.c#L744
19:50 Zoffix And ba is MVMP6bigintBody *ba
19:50 Zoffix I've no idea how to check if it's negative
19:50 * Zoffix relocates
19:50 samcv ok great
19:50 samcv thx :)
19:51 Zoffix And in rakudo `./perl6 -e '2 +> 100'` should give 0 and `./perl6 -e '-2 +> 100'` needs to give -1
19:51 samcv write some roast tests and i'll work on this for a bit
19:53 Zoffix Oh, they might not give that without my rakudo patch, but, this will:
19:53 Zoffix m: use nqp; say nqp::bitshiftr_I(-2, 50, Int); # wrong; should give -1
19:53 camelia rakudo-moar 65c078: OUTPUT: «0␤»
19:53 Zoffix m: use nqp; say nqp::bitshiftr_I(2, 50, Int); # right; should give 0
19:53 camelia rakudo-moar 65c078: OUTPUT: «0␤»
19:53 Zoffix And on Moar master it gives -1 for both; and when that line is fixed the two will give right results
19:53 * Zoffix &
19:54 AlexDaniel joined #moarvm
20:05 Ven joined #moarvm
20:16 praisethemoon joined #moarvm
20:16 praisethemoon joined #moarvm
20:23 samcv Zoffix, i think i may have got it
20:24 Zoffix sweet
20:24 timotimo Zoffix: you need to have different code for when the bigint has the smallbigint flag set
20:24 timotimo because otherwise you'd be dereferencing a pointer with a bunch of fs at the start
20:24 timotimo and very unlikely an actually mapped address
20:25 samcv that code doesn't work though. the ternary thingy
20:25 samcv yeah i wrote some timotimo
20:25 timotimo i didn't read enough of backscroll, and i have to afk again right now
20:25 Zoffix samcv: doesn't work how?
20:26 samcv Zoffix, just give me some tests i can test
20:26 samcv use nqp; say nqp::bitshiftr_I(-2, 50, Int); # wrong; should give -1
20:26 samcv that gives 0
20:26 * Zoffix is on the bus atm
20:26 samcv oh no
20:26 samcv it works
20:26 samcv nvm
20:26 samcv perfect
20:26 samcv \o/ success
20:27 Zoffix cool samcv++
20:27 samcv but i had to do the opposite of your ternary
20:27 samcv !IS_NEGATIVE(ba) ? -1 : 0)
20:27 samcv unless my is negative function is broken
20:28 samcv oh yeah it was. heh
20:30 samcv gonna run roast now
20:34 colomon joined #moarvm
20:38 timotimo do we have more tests for shr on positive numbers also giving 0? on top of shr on negatives giving -1?
20:38 samcv we only have like 5 tests
20:38 Zoffix I have negatives covered in a branch in roast
20:39 samcv good
20:39 Zoffix fix-bitshift_r or whatver it was
20:42 Geth ¦ MoarVM: 362277b79f | (Samantha McVey)++ | src/math/bigintops.c
20:42 Geth ¦ MoarVM: Better version of patch to fix right shifting negative smallints
20:42 Geth ¦ MoarVM:
20:42 Geth ¦ MoarVM: The previous patch did not check what sign was there and didn't fully
20:42 Geth ¦ MoarVM: handle big/smallint containing P6int's. This one adds a new
20:42 Geth ¦ MoarVM: BIGINT_IS_NEGATIVE() function to check if it is negative.
20:42 Geth ¦ MoarVM:
20:42 Geth ¦ MoarVM: This function may be very useful other places we need to check if a
20:42 Geth ¦ MoarVM: p6int is negative.
20:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/362277b79f
20:42 samcv ok. all is now good :)
20:43 samcv maybe a variable extra i don't need there. though wanted zoffix to put it through the paces with his tests
20:43 samcv so let me know how it goes Zoffix
20:43 * samcv grabs some tea
20:46 colomon joined #moarvm
21:00 Ven joined #moarvm
21:32 jnthn I'm a tad surprised https://github.com/MoarVM/MoarVM/commit/362277b79f#diff-da7d01bcfced11bccf24e9234758e807R726 compiles without parens around the condition
21:32 jnthn Oh, but maybe the macro provides them
21:32 jnthn But still, that's cheeky :P
21:34 Ven_ joined #moarvm
21:35 samcv it's not a macro
21:35 samcv https://github.com/MoarVM/MoarVM/commit/362277b79f#diff-da7d01bcfced11bccf24e9234758e807R722 you commented on it ;)
21:36 jnthn I meant
21:36 jnthn if MVM_BIGINT_IS_BIG(ba) {
21:36 jnthn Either I'm really tired, or in C we normally put parens around conditions :)
21:38 jnthn heh, yes: https://github.com/MoarVM/MoarVM/blob/2eedba88d2b0c08f94dd4426a60d0bc7f8effa13/src/6model/reprs/P6bigint.h#L4 :)
21:38 timotimo oh lord, hahaha
21:38 timotimo perfect
21:39 timotimo textual macros are so amazing sometimes

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