Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-16

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

All times shown according to UTC.

Time Nick Message
00:15 timotimo if i also require facts->type to be non-null, it no longer segfaults, but why would i need to?!
00:28 timotimo well, at least with that check i can reach through most of the spec tests, maybe all of them
00:37 timotimo seems like my changes made t/spec/integration/advent2012-day24.t infiniloop and gobble up memory or something :(
00:39 timotimo and of course i can't get it to do that without the fudger
00:44 timotimo well, the fudger doesn't do anything to that file; i meant the test runner
00:44 timotimo my brane seems to be suffering from my flu-type-thingie by now, so i'll get some rest
00:45 dalek MoarVM/merge_facts_at_phi: 8b2c7e7 | timotimo++ | src/spesh/optimize.c:
00:45 dalek MoarVM/merge_facts_at_phi: make optimize_smart_coerce more robust to wrong facts
00:45 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/8b2c7e7474
00:45 dalek MoarVM/merge_facts_at_phi: 1b174d4 | timotimo++ | src/spesh/optimize.c:
00:45 dalek MoarVM/merge_facts_at_phi: at PHI ops, we may be able to merge common facts
00:45 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/1b174d4837
01:00 flussence joined #moarvm
01:32 zakharyas joined #moarvm
02:02 xiaomiao joined #moarvm
02:45 flussence joined #moarvm
02:46 zakharyas1 joined #moarvm
02:57 colomon joined #moarvm
03:06 colomon joined #moarvm
05:10 vendethiel joined #moarvm
05:36 nwc10 jnthn: http://paste.scsys.co.uk/469517 -- origin/spesh-value-prop setting build ASAN barf
06:22 vendethiel joined #moarvm
06:47 FROGGS joined #moarvm
06:50 vendethiel joined #moarvm
07:41 vendethiel joined #moarvm
07:49 zakharyas joined #moarvm
07:58 Ven joined #moarvm
08:20 vendethiel joined #moarvm
08:45 kjs_ joined #moarvm
08:46 vendethiel joined #moarvm
08:57 rurban joined #moarvm
09:24 vendethiel joined #moarvm
10:20 vendethiel joined #moarvm
10:37 nwc10 FROGGS: is this the output you wanted? http://paste.scsys.co.uk/469546 http://paste.scsys.co.uk/469547
10:49 donaldh joined #moarvm
10:55 Ven joined #moarvm
11:31 vendethiel joined #moarvm
11:57 Ven joined #moarvm
11:58 vendethiel joined #moarvm
14:11 kjs_ joined #moarvm
15:36 FROGGS nwc10: aye it is, thank you :o)
15:37 FROGGS so we seem to read the long portion of the union exactly like C does... that's not too bad
15:38 nwc10 my assumption (not backed up by actual testing) is that on a big endian machine, the union layout will have the short, char (etc) at the *start* of the memory used by the long (just like L.E.)
15:38 FROGGS I already thought that union members that are smaller as ptrsize or intsize have a padding...
15:38 nwc10 but of course, as it's B.E
15:38 nwc10 those short, char etc show up as the most-significant bits of the long value, not the least significant.
15:38 FROGGS yeah
15:39 nwc10 and ("of course") you'll have them in (seemingly) different places on 32 and 64 bit B.E. machins
15:39 nwc10 because they will appear at <<24 and <<16 or <<48 and <<56
15:39 nwc10 nor <<0 and <<0 :-/
15:39 nwc10 er,
15:39 nwc10 not <<0 and <<0 :-/
15:40 nwc10 (like that fun with the bitintrepr, which has to be different for 32 and 64 bit B.E.)
15:40 nwc10 anyway, I need to decommute
16:06 Ven joined #moarvm
16:09 colomon joined #moarvm
17:21 kjs_ joined #moarvm
17:35 kjs_ joined #moarvm
18:22 timotimo damn it
18:22 timotimo my branch makes XML not compile any more
18:23 timotimo oh wow
18:23 timotimo massive failures all over
18:23 timotimo even on the master branch?!
18:25 kjs_ joined #moarvm
18:26 FROGGS O.o
18:43 sivoais joined #moarvm
18:53 sivoais joined #moarvm
18:59 kjs_ joined #moarvm
19:03 sivoais joined #moarvm
19:05 colomon joined #moarvm
19:13 sivoais joined #moarvm
19:23 sivoais joined #moarvm
19:33 sivoais joined #moarvm
19:43 sivoais joined #moarvm
19:49 timotimo hm, false alarm apparently
19:49 timotimo not sure what i did wrong
19:49 timotimo maybe i make'd instead of make installing
19:53 sivoais joined #moarvm
20:02 kjs_ joined #moarvm
20:03 sivoais joined #moarvm
20:13 sivoais joined #moarvm
20:18 timotimo but in my branch i get XML failing to install unless i disable spesh
20:23 sivoais joined #moarvm
20:33 sivoais joined #moarvm
20:43 sivoais joined #moarvm
20:44 dalek joined #moarvm
20:49 sivoais joined #moarvm
20:49 * timotimo is not amusified
20:49 timotimo but i'll just let that branch rest for a bit
20:55 brrt joined #moarvm
20:57 brrt \o
21:14 dalek MoarVM/cpp2: c435813 | FROGGS++ | src/core/nativecall.c:
21:14 dalek MoarVM/cpp2: fix return value of C++ constructore calls
21:14 dalek MoarVM/cpp2: review: https://github.com/MoarVM/MoarVM/commit/c435813a8e
21:14 dalek MoarVM/cpp2: fa4019a | FROGGS++ | src/core/nativecall.c:
21:14 dalek MoarVM/cpp2: allow to natviecast from CPPStruct
21:14 dalek MoarVM/cpp2: review: https://github.com/MoarVM/MoarVM/commit/fa4019a19f
21:14 FROGGS such typo
21:14 FROGGS -.-
21:18 nebuchadnezzar nice to see that next moarvm release will permit to drop the debian patch ;-)
21:19 kjs_ joined #moarvm
21:22 dalek MoarVM: 75e5909 | FROGGS++ | Configure.pl:
21:22 dalek MoarVM: use CPPFLAGS if set, baby-gnu++
21:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/75e5909cce
21:22 FROGGS nebuchadnezzar: we should be fine now
21:23 nebuchadnezzar thanks a lot
21:25 FROGGS you're welcome
22:15 nebuchadnezzar FROGGS: I have a doubt, shouldn't the CPPFLAGS be pushed in cflags instead of ldflags?
23:04 brrt joined #moarvm
23:13 dalek MoarVM: 1a551dc | timotimo++ | src/spesh/facts.c:
23:13 dalek MoarVM: fix a sort of bad thinko in iter_facts
23:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1a551dc4a7
23:35 timotimo so it seems like this happened:
23:35 timotimo we were looking for $!poisoned, which used to be a getattr_o
23:35 timotimo then we deconted that and if_o'd it to figure out if it'd be true-ish
23:35 timotimo spesh - for some reason - thought it knew it was going to be an Int box and turned that decont + if_o into a set, unbox and if_i
23:36 timotimo that gives rise to the "cannot unbox a type object" error that triggered inside the optimizer
23:37 timotimo i don't currently know why it thinks it knows the type; perhaps from logging? but there's no guard for that in the resulting code, so maybe we're not marking a guard properly?
23:37 timotimo anyway, for a hotfix i turned that $!poisoned attribute into a native int attribute
23:43 timotimo hum. optimize_iffy seems to be using the facts properly, so the guard ought to have been kept alive. huh.
23:43 timotimo ah, but if facts are merged at a PHI, the guard a fact comes from isn't marked as used when the result is used!
23:43 timotimo that could be the issue here
23:51 timotimo yeah, i've got a fix that prevents breakage, but no implementation of "using facts from guards through a PHI node"
23:51 timotimo i'll probably leave that for tomorrow and have some rest

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