Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-16

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

All times shown according to UTC.

Time Nick Message
00:27 leont joined #moarvm
01:23 colomon joined #moarvm
01:34 geekosaur joined #moarvm
01:44 geekosaur joined #moarvm
01:46 geekosaur joined #moarvm
02:56 vendethiel joined #moarvm
04:18 geekosaur joined #moarvm
06:26 japhb joined #moarvm
07:34 nwc10 good *, #moarvm
07:48 zakharyas joined #moarvm
07:56 patrickz joined #moarvm
08:05 FROGGS joined #moarvm
08:23 zakharyas joined #moarvm
08:49 ShimmerFairy joined #moarvm
09:54 zakharyas joined #moarvm
10:04 brrt joined #moarvm
10:06 leont joined #moarvm
10:06 brrt ohhai #moarvm
10:06 brrt i just had a mildly evil idea that i just can't find the flaw on yet
10:07 brrt you might know that i've added a facility to extract the values used into a single tile out of the tree into a linear array; that is very useful for ensuring that values which should be in a register are actually there
10:08 brrt as well as ensuring that values which are never further used are 'killed'
10:11 brrt anyway, a very simple and practical difficulty in tiler linearisation is that i want to interleave the tiles with nodes representing the 'inter-tile-work' that is done by the compiler
10:11 brrt that is to say, i want to insert loads, stores, labels, and conditional jumps, because that is all there is
10:11 brrt bear with me; i'll get to the point :-)
10:12 brrt these things all take integer values as arguments
10:12 brrt i can store any number of integers in the expression tree as arguments
10:12 brrt i can extract a number of intergers out of the expression tree, by the above-mentioned mechanism
10:13 brrt hence, i can insert the arguments for these functions into the tree, and deal with them as i would with regular tiles
10:13 brrt i can create fake pseudotiles, and all will be well....
10:14 brrt but it's conflating of the tree and its' storage mechanism, for one thing, and reusing that storage mechanism for nefarious purposes, too
10:15 brrt hence, big software engineering red flag
10:15 brrt but, it will work
10:15 brrt you may understand my dillema :-)
10:28 stmuk do I open MoarVM bugs on RT or GH?
10:29 brrt both are fine i think
10:29 brrt RT is used a little more? but I use github personally
10:29 brrt stmuk: what's the bug?
10:29 stmuk the build has recently broken on FreeBSD
10:30 stmuk I have a crude fix
10:30 stmuk but not sure putting an #ifndef __FreeBSD__ in is that good nice
10:32 stmuk ah its reported with a similar fix anyway
10:32 stmuk https://github.com/MoarVM/MoarVM/issues/311
10:36 brrt oh, yes, i can recall that
10:39 brrt i don't like the suggested fix; it'll end up with a long list of platforms that have fileno defined as a macro
10:39 brrt iirc, jnthn recently added the native-fileno method on file handles
10:40 brrt i'd prefer renaming the function fileno to native_fileno or something like that
10:46 virtualsue joined #moarvm
10:46 Peter_R joined #moarvm
10:57 jnthn It ended up as native-descriptor
10:58 jnthn I think we'll go with something like that as the name in Moar too
11:04 brrt descriptor, that's the right term
11:12 timotimo yeah
11:12 timotimo brrt: if you have design decisions like that, why not "plan to throw one away"? ;P
11:12 timotimo see where it leads you?
11:12 brrt hmmm
11:13 brrt good enough point....
11:13 timotimo i don't really see the big trouble with using a pseudotile for the inter-tile compiler work
11:14 timotimo it reminds me a tiny bit of how PHI nodes are handled in spesh
11:14 timotimo those are fake, too, in that they have an opcode of MVM_SSA_PHI, but there's actually multiple info structs allocated for them, because every PHI node can have a different number of arguments
11:14 brrt well, there's another option, and i would like it best if it didn't involve a whole bunch of allocation work
11:15 brrt which is, copy the arguments into an array.....
11:15 brrt oh
11:15 brrt that is not even a really bad idea
11:15 brrt now that i think of it
11:16 brrt i can just use a fixed-size array internal to the 'linear tile node' and pass it to the tile when it is time to emit it
11:16 brrt that... fixes all my objections, which were (among other things) 'gee, isn't it a pain to manage a billion pointers for such a simple thing'
11:17 brrt timotimo++ # you've just made my day :-D
11:17 timotimo <3
11:18 brrt (urgh, i'm entering the relative-overcaffeniation/under-caloric state, which means it is time for lunch)
11:25 timotimo i just had a tiny noms break my own self
11:25 timotimo i'm amazed i could pump out such good advice while nomming on some toast
11:29 * jnthn is still on breakfast... :)
11:30 timotimo i've only had a miniature breakfast so far :)
11:43 dalek MoarVM: 1a896ff | jnthn++ | src/io/io. (2 files):
11:43 dalek MoarVM: Fix build bustage where fileno is a macro.
11:43 dalek MoarVM:
11:43 dalek MoarVM: Turns out that C macros don't C so well.
11:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1a896ff083
11:44 nwc10 jnthn: "still"? surely any meal is correct when one is in UGT?
11:45 jnthn True :)
11:48 stmuk with regard to https://github.com/MoarVM/MoarVM/issues/311 the parans fix of cygx might be a good temporary solution allowing *BSD  until fileno is renaming (which appears to be in multiple places?)
11:48 stmuk s/ing/ed
11:50 jnthn stmuk: I already did it above
11:50 stmuk d'uh
11:50 jnthn :)
11:50 stmuk :)
11:50 jnthn Don't have a BSD to test it on though, so that'd be appreciated by anyone who does
11:51 stmuk oh I thought it was renaming the opcode as well
11:51 stmuk I can test
11:51 jnthn opcode should be harmless
12:06 * brrt has a bsd vm stashed somewhere
12:10 nwc10 1cc1: error: unrecognized command line option "-Wno-logical-op-parentheses"
12:10 nwc10 ops
12:10 nwc10 cc1: error: unrecognized command line option "-Wno-logical-op-parentheses"
12:11 nwc10 OK, how do I get round that one...
12:12 nwc10 --compiler=gcc
12:12 jnthn Upgrade to a newer clang? :P
12:12 nwc10 OK, bigger F-up
12:12 nwc10 no, really, what we need is someone who understands Win32 and *nix to produce (or "buy in") a better configuration system that doesn't pre-code a bunch of assumptions
12:12 nwc10 but, failing that
12:12 nwc10 I get to fix the gnu-make assumptions
12:12 nwc10 oh wait
12:12 nwc10 gmake is installed
12:12 stmuk it works on NetBSD I'm just waiting for the old clunky clang to finish
12:13 nwc10 I'll ignore that bug for now too
12:13 stmuk clang36+ on FreeBSD is much faster than the default one
12:13 nwc10 I'm not root
12:14 stmuk nwc10: which platform is this?
12:15 nwc10 7.2-RELEASE FreeBSD
12:15 nwc10 and I'm not going to say *where*, as IIRC that's out of security
12:16 stmuk hahaha
12:16 nwc10 OK
12:16 nwc10 sorry,
12:16 nwc10 build FAIL
12:16 nwc10 there are gmake assumptions in the top level Makefile
12:16 stmuk it works (or worked) on FreeBSD 8.x
12:16 nwc10 and some sort of "doesn't like gmake" assumptions somewhere lower
12:17 nwc10 oh, odd
12:18 nwc10 `gmake -` *works*
12:18 nwc10 MoarVM builds
12:21 stmuk nwc10: if you wanted a modern toolchain you could probably use pkgsrc with a prefix of $HOME/pkg or whatever
12:22 nwc10 I didn't know one could do that
12:23 stmuk its useful for people stranded on obsolete systems in industry :/
12:24 nwc10 for now, I seem to be getting a viable build with the default ancient(ish) toolchain
12:32 stmuk an old gcc is probably faster than an old clang anyway :)
12:40 brrt nwc10, current version is 10.2 ? :-o
12:40 brrt and yes, there are gmake assumptions
12:40 nwc10 something like that
12:40 brrt there is also special nmake magic i think
12:41 brrt i wonder if the state-of-the-art in perl5 Configure.pl scripts has improved
12:41 brrt i would *hate* to lose make, fwiw
12:41 brrt also, i would equally hate to lose perl5-as-a-guaranteed-property-of-the-build process
12:42 nwc10 I'd love to see the assumption of perl *5* gone from the build process.
12:42 brrt but but but
12:42 nwc10 I'm biased.
12:42 brrt i use perl5 for my preprocessors
12:42 brrt i'd have to rewrite everything in minilua :-P
12:42 nwc10 "rebuild" is different from bootstrap
12:42 brrt hmmm
12:43 stmuk I think removing perl 5 dependency from panda type installs should be first
12:43 brrt lets just say i wouldn't like to checkin the generated headers from preprocessing templates / tile descriptions
12:43 stmuk I don't think needing perl 5 to build is unreasonable
12:44 brrt thing is, something like luajit gets by *just fine* with a single makefile, no preconfiguring necessary
12:44 nwc10 I *do*
12:44 brrt configuring is imho an autotools legacy, and if we *can* get away without it, that would be better
12:45 nwc10 but that's because I don't want to mandate that someone keeps having to maintain Perl 5, just so that Perl 6 can build
12:45 nwc10 but this is at the 10 year timescale.
12:45 nwc10 but you're right that Panda is the thing to start with
12:45 nwc10 work from that end backwards, and see where things go
12:48 stmuk anyway moarvm builds on all 3 major BSDs (I deleted my DragonFlyBSD sadly)
12:50 nwc10 stmuk++
12:50 nwc10 doing better than me
12:51 stmuk virtualbox++
13:02 brrt i think people will be maintaining perl5 for such timescales whether we want them to or not
13:02 nwc10 oh yes, I don't disagree with *that*
13:03 nwc10 but it shouldn't be forever
13:03 nwc10 but start with Panda and work back
13:04 nwc10 it should be viable for everything from NQP onwards to build without Perl 5, given that NQP already self-bootstraps with code written in NQP
13:04 nwc10 and we're a long way from getting to that
13:04 nwc10 which is "easy" (for a dubious value of easy)
13:04 nwc10 "we" also need to address the toolchain code duplication between NQP and Rakudo
13:05 nwc10 and all of that is probably more important and easier than any (semi) ideological purge of Perl 5
13:05 stmuk I rather liked the current perl configure scripts since they were very clear and better than most perl 5 I've seen
13:05 nwc10 they are pretty clear, but there are too many copies of the same code in 2 or 3 repositories
13:05 nwc10 and there's too much assupmtion/not enough probing
13:06 nwc10 (I'm biased)
13:06 nwc10 but, as you said, start with Panda
13:06 stmuk certainly nicer than the usual auto* and the increasingly popular cmake
13:08 stmuk I think leont has a prove6 type thing already
13:17 * brrt nods
13:17 brrt yeah, the whole thing can be made much more robust
13:17 brrt but there is so much encoded knowledge there....
13:18 brrt pretty much nobody knows all that about all platforms
13:39 * jnthn back
13:40 geekosaur joined #moarvm
13:41 geekosaur joined #moarvm
13:54 brrt ohai jnthn
13:54 jnthn o/ brrt
13:57 dalek MoarVM: 8aa4cd4 | jnthn++ | / (3 files):
13:57 dalek MoarVM: Configure bits for \n -> \r\n on output.
13:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8aa4cd48e3
14:23 dalek MoarVM: e7ebeb9 | jnthn++ | src/ (12 files):
14:23 dalek MoarVM: Implement input newline translation.
14:23 dalek MoarVM:
14:23 dalek MoarVM: Applies to all I/O handles except sockets.
14:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e7ebeb957a
14:36 travis-ci joined #moarvm
14:36 travis-ci MoarVM build failed. jnthn 'Implement input newline translation.
14:36 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/97224178 https://github.com/MoarVM/MoarVM/compare/8aa4cd48e324...e7ebeb957a29
14:36 travis-ci left #moarvm
14:36 jnthn I bet that'll be heisenbuild... :P
15:01 dalek MoarVM: 6935e94 | jnthn++ | / (30 files):
15:01 dalek MoarVM: Translate newline \n -> \r\n on output.
15:01 dalek MoarVM:
15:01 dalek MoarVM: When doing I/O for anything except sockets, and only when configured
15:01 dalek MoarVM: to do so (meaning "on Windows builds").
15:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6935e941df
15:05 jnthn heh, not heisenbuild :)
15:07 dalek MoarVM: 49f10b9 | jnthn++ | src/strings/normalize.c:
15:07 dalek MoarVM: Fix missing intialization.
15:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/49f10b9b86
15:16 travis-ci joined #moarvm
15:16 travis-ci MoarVM build failed. jnthn 'Translate newline \n -> \r\n on output.
15:16 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/97232730 https://github.com/MoarVM/MoarVM/compare/e7ebeb957a29...6935e941dfc1
15:16 travis-ci left #moarvm
15:16 nwc10 jnthn: t/moar/03-line-seps.t fails
15:16 nwc10 not ok 14 - \r\n separator used
15:17 jnthn Yeah, that test is now wrong
15:17 jnthn Fixed locally
15:27 travis-ci joined #moarvm
15:27 travis-ci MoarVM build failed. jnthn 'Fix missing intialization.'
15:27 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/97233863 https://github.com/MoarVM/MoarVM/compare/6935e941dfc1...49f10b9b8651
15:27 travis-ci left #moarvm
16:20 domidumont joined #moarvm
16:21 zakharyas joined #moarvm
16:22 brrt commute &
16:25 zakharyas joined #moarvm
16:53 zakharyas joined #moarvm
16:59 jnthn Seems we we aren't especially validating typevars properly
16:59 jnthn In the bytecode validator
16:59 jnthn Meaning we get away with spitting out bytecode for various things with very dubious behaviors
17:00 jnthn Like num32 lex being read into a num64 register, and vice versa
17:00 jnthn Without the appropriate coercion
17:01 timotimo that could be kinda bad
17:02 jnthn Yes, it's why num32 mis-behaves in https://rt.perl.org/Ticket/Display.html?id=124084
17:03 jnthn oh, it seems it does happen for reg reg, but not for lex reg or reg lex
17:10 jnthn I wonder how much chaos fixing this will cause
17:19 jnthn Well, nqp's make test still passes
17:19 jnthn And it catches the issue
17:19 jnthn C:\consulting\rakudo>perl6-m -e "my num32 $n; say $n;"
17:19 jnthn Bytecode validation error at offset 18, instruction 4:
17:19 jnthn operand type 40 does not match register type 48
17:21 timotimo ideally we'd complain at the compiler stage rather than at the bytecode validation stage
17:21 jnthn That's a nice to have :)
17:22 jnthn Running bytecode that's full of it is just really wrong :)
17:22 timotimo right!
17:22 jnthn Feel free to patch mast/compiler.c or so
17:22 jnthn (I'll probably only do that now if it makes debugging easier)
17:24 jnthn Well, NQP builds and passes tests with the patch. Now to see if Rakudo builds.
17:25 jnthn Phew, yes, it does :)
17:26 jnthn Blows up make test in a couple of places
17:33 zakharyas joined #moarvm
17:34 jnthn And a couple of spectests, it seems
17:34 jnthn But seems everything it catches is genuine bad code-gen
17:35 timotimo very good
17:35 jnthn I'd guess the nativecall fails that it results in match up with native call fails on BE
17:40 virtualsue joined #moarvm
17:44 dalek MoarVM/sized-native-fixes: ee0afc2 | jnthn++ | src/core/validation.c:
17:45 dalek MoarVM/sized-native-fixes: Validate lexical types properly.
17:45 dalek MoarVM/sized-native-fixes:
17:45 dalek MoarVM/sized-native-fixes: This means that we catch invalid code-gen for storing wrongly sized
17:45 dalek MoarVM/sized-native-fixes: values into lexicals, and vice versa.
17:45 dalek MoarVM/sized-native-fixes: review: https://github.com/MoarVM/MoarVM/commit/ee0afc28ab
17:45 dalek MoarVM/sized-native-fixes: d23cbe2 | jnthn++ | src/core/interp.c:
17:45 dalek MoarVM/sized-native-fixes: Implement truncate/extend ops for num32.
17:45 dalek MoarVM/sized-native-fixes: review: https://github.com/MoarVM/MoarVM/commit/d23cbe23b8
17:45 nwc10 *aha*, them
17:45 jnthn .oO( The sun never sets on Big Endian )
17:46 jnthn Enough for now...will look at the code-gen fixes we need later
17:48 JimmyZ (MVMnum64)GET_REG(cur_op, 2).n64; # do you mean MVMnum32 here?
17:48 jnthn yes
17:49 dalek MoarVM/sized-native-fixes: d6544f5 | jnthn++ | src/core/interp.c:
17:49 dalek MoarVM/sized-native-fixes: Fix cast; JimmyZ++.
17:49 dalek MoarVM/sized-native-fixes: review: https://github.com/MoarVM/MoarVM/commit/d6544f54d9
17:49 jnthn That's exactly why I'll worry about the rest later :P
17:50 JimmyZ ;)
17:50 jnthn dinner &
18:35 diakopter jnthn: dare I suggest the nativecall fails are also related to what you saw on windows with the deserialization cache thing XD XD XD XD *Christmas Cheer***
18:35 diakopter (yes I'm still gonna try to repro on windows)
18:52 leont joined #moarvm
18:55 zakharyas joined #moarvm
19:04 zakharyas joined #moarvm
19:05 vendethiel joined #moarvm
19:19 zakharyas1 joined #moarvm
19:35 virtualsue joined #moarvm
19:37 jnthn diakopter: Sadly, I highly doubt it...the bustage I've uncovered will be cross-platform.
19:49 FROGGS joined #moarvm
19:52 diakopter oh
20:00 virtualsue joined #moarvm
20:01 nwc10 jnthn: ASAN likes (OK, tolerates with the usual disdain) your branch so far
20:02 jnthn :)
20:25 virtualsue joined #moarvm
20:54 virtualsue joined #moarvm
20:58 zakharyas joined #moarvm
21:25 ilmari wow, just running nqp's Configure on an ubsan-enabled moar spews tons of errors
21:25 ilmari it didn't do that a few weeks ago, iirc
21:26 ilmari laods of misaligned loads
21:26 ilmari src/core/validation.c:156:12: runtime error: load of misaligned address 0x7fcb21c463d9 for type 'MVMuint16', which requires 2 byte alignment
21:27 ilmari that's opcode = *(MVMuint16 *)val->cur_op;
21:28 ilmari and callsites_equal() passing null pointers to memcmp
21:29 hoelzro https://github.com/joyent/libuv/issues/414
21:29 hoelzro that explains the UDP issues
21:30 FROGGS jnthn: could that explain the blowup? https://gist.github.com/FROGGS/bc20e5799a39d97b94f2#file-gistfile1-txt-L16-L23
21:30 TimToady went to bed
21:33 FROGGS ahh :o)
21:37 colomon joined #moarvm
21:38 ilmari ubsan output from nqp Configure.pl run: http://paste.scsys.co.uk/502894
21:39 hoelzro wow
21:39 ilmari gcc 5.2.1-23 on debian testing
21:39 hoelzro these sanitizers are so cool
21:40 dalek MoarVM: 016bb5e | FROGGS++ | src/core/bytecode.c:
21:40 dalek MoarVM: init cd->arg_flags so callsites_equal wont complain
21:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/016bb5ec9c
21:40 FROGGS sadly, this does not help
21:41 ilmari well, no, it's still passing null pointers to memcmp
21:41 ilmari if arg_flags == NULL is a valid state, callsite_equals needs to guard against that
21:46 diakopter ilmari: nopaste the error list?
21:46 ilmari diakopter: 21:38 < ilmari> ubsan output from nqp Configure.pl run: http://paste.scsys.co.uk/502894
21:47 diakopter ahah
21:48 diakopter gah
21:52 ilmari FROGGS: there are other places where arrays that would be zero-sized are not allocated, then add_foo functions blindly memcpy them
21:55 travis-ci joined #moarvm
21:55 travis-ci MoarVM build passed. Tobias Leich 'init cd->arg_flags so callsites_equal wont complain'
21:55 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/97320646 https://github.com/MoarVM/MoarVM/compare/49f10b9b8651...016bb5ec9cae
21:55 travis-ci left #moarvm
21:56 ilmari although in other places it does malloc(0)
22:27 ilmari but malloc(0) is allowed to return NULL anyway, so we can't rely on that
22:28 colomon joined #moarvm
22:54 ilmari FROGGS: https://github.com/MoarVM/MoarVM/pull/312
22:55 ilmari FROGGS: fixes all null pointer memc(py|mp) in callsite.c and spesh/
23:13 dalek MoarVM: 31bdb0f | (Dagfinn Ilmari Mannsåker)++ | src/spesh/ (3 files):
23:13 dalek MoarVM: Avoid memcpy(x, NULL, 0) in spesh
23:13 dalek MoarVM:
23:13 dalek MoarVM: Although most compilers sensibly do nothing in this case, it is
23:13 dalek MoarVM: undefined behaviour according to the standard, and UBSAN complains.
23:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/31bdb0f7b4
23:13 dalek MoarVM: c571752 | (Dagfinn Ilmari Mannsåker)++ | src/core/callsite.c:
23:13 dalek MoarVM: Don't try to compare empty flag sets
23:13 dalek MoarVM:
23:13 dalek MoarVM: This avoids calling memcmp() with NULL pointers, which is undefined
23:13 dalek MoarVM: behaviour, even is the count is zero.
23:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c5717527a2
23:13 diakopter ilmari: I merged it
23:14 diakopter show me a couple of the 6model ones you're not sure about
23:26 diakopter ilmari: which 6model things
23:32 ilmari diakopter: the ones in src/6model/serialization.c:concatenate_outputs
23:33 ilmari diakopter: ubsan only flagged the one for repos_table
23:33 ilmari this was just during 'make' of nqp
23:34 diakopter maybe ubscan divined that it couldn't definitively determine that the size sent to memcpy would always be zero when the pointer was invalid
23:35 ilmari I don't think ubsan does that kind of analysis
23:35 diakopter oh
23:35 ilmari null pointers to memc(py|mp) are undefined even when size == 0
23:35 diakopter well, is it a problem to send invalid pointers to memcpy when the size is 0? oh
23:35 diakopter I see
23:35 ilmari yes, it's explicitly undefined, presumably for speed/ease of implementation
23:38 diakopter yeah, the check for zero would need to be *somewhere*; might as well make the caller do it
23:39 ilmari and often you know that it can't be zero, so don't need to check
23:40 diakopter but yes, should add those checks to the 6model serialization too
23:41 diakopter most of those memcpy usages could theoretically be zero
23:51 ilmari 'nqp make' is up over 200k lines of ubsan output
23:51 ilmari mostly misaligned access
23:51 diakopter well hopefully it decreases non-linearly XD
23:52 ilmari I'll upload the full output pluss deduplicated by source code line

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