Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-01-08

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

All times shown according to UTC.

Time Nick Message
00:20 virtualsue joined #moarvm
01:38 flussence joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:31 hoelzro joined #moarvm
03:33 hoelzro diakopter: well, I figured out some more stuff about that bug
03:33 hoelzro namely, that calling methods is fine, but calling subs triggers the bug
05:16 TimToady joined #moarvm
05:39 vendethiel joined #moarvm
06:04 timotimo so, uhm ...
06:04 timotimo i can't sleep, so i'm playing around with the garbage collector
06:04 timotimo i've put a print of the address we're popping off of a worklist into process_worklist
06:04 timotimo putting that through sort | uniq -c | sort -n gives me a surprising result
06:05 timotimo 1201 0x7f38e2bea0e0
06:05 timotimo 2407 0x7f38e27e6e70
06:05 timotimo 12934 0x7f38e2be9c68
06:05 timotimo 100023 0x7f38e28a63f0
06:05 timotimo timo@schmetterling ~> wc -l garbage_collection_order.txt
06:05 timotimo 132296 garbage_collection_order.txt
06:06 timotimo m: say "{ 100 * 100023 / 132296 }% of addresses are just one single address over and over"
06:06 camelia rakudo-moar f1dd49: OUTPUT«75.605460% of addresses are just one single address over and over␤»
06:07 timotimo without sorting the outputted lines first, i still get:
06:07 timotimo 371 0x7f38e2bea190
06:07 timotimo 1051 0x7f38e2bea0e0
06:07 timotimo 10202 0x7f38e2be9c68
06:07 timotimo 100000 0x7f38e28a63f0
06:07 timotimo ah, haha
06:07 timotimo i know what this is about
06:07 timotimo my dumb test script %)
06:07 timotimo "hi" xx 100000
06:08 timotimo unsurprisingly puts the "hi" string in there about 100000 times in a row
06:08 timotimo who would have thought %)
06:16 timotimo my ideas of deduplicating things in the worklist were bogus anyway, because we're caring about pointers to pointers to objects
06:17 timotimo what an unexpected turn of events: an overtired timotimo is coming up with not-so-clever ideas
06:20 timotimo luckily, instead of coding, i can ease my mind with a few funny pictures and gifs: http://iks.soup.io/post/652386942/Image
06:30 timotimo let's try sleeping one more time
06:35 vendethiel joined #moarvm
06:56 domidumont joined #moarvm
07:02 domidumont joined #moarvm
07:07 virtualsue joined #moarvm
07:21 FROGGS joined #moarvm
08:01 vendethiel joined #moarvm
08:40 brrt joined #moarvm
08:53 zakharyas joined #moarvm
10:24 stmuk_ joined #moarvm
10:45 FROGGS joined #moarvm
10:45 donaldh joined #moarvm
11:21 stmuk__ joined #moarvm
11:26 leont joined #moarvm
12:10 virtualsue joined #moarvm
12:19 dalek MoarVM: d06a0c3 | (Dagfinn Ilmari Mannsåker)++ | src/io/fileops.c:
12:19 dalek MoarVM: Fix stat CREATETIME return value
12:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d06a0c35b9
12:19 dalek MoarVM: 292785f | FROGGS++ | src/io/fileops.c:
12:19 dalek MoarVM: Merge pull request #332 from ilmari/fix-stat-createtime
12:19 dalek MoarVM:
12:19 dalek MoarVM: Fix stat CREATETIME return value
12:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/292785f17e
12:27 patrickz joined #moarvm
13:21 virtualsue joined #moarvm
13:41 brrt joined #moarvm
13:47 brrt huh, read an article on 'modern c', and the first  thing it says is, 'clang will compile your files faster'
13:47 brrt wat
13:50 nwc10 that certainly was true (and it had better diagnostics than gcc) but I think that gcc raised its game
13:50 nwc10 [other compilers are available]
13:50 nwc10 but, yes, really, is that relevant for "modern C" ?
13:51 brrt i compile moar typically much faster on gcc than on clang...
13:52 nwc10 oh OK. Interesting
13:52 brrt it's may be true for 'regular' projects, its just weird its so different from my experience
13:52 brrt https://matt.sh/howto-c
13:53 brrt anyway, it's interesting, but it probably shouldn't be treated as canon
13:55 arnsholt Yeah, that was an interesting write-up
13:55 arnsholt The C99 recommendation doesn't fly for Moar, but I think most of the others are already followed by Moar
13:56 dalek MoarVM: 14d2575 | (Dagfinn Ilmari Mannsåker)++ | / (8 files):
13:56 dalek MoarVM: Add subsecond file time ops stat_time and lstat_time
13:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/14d257536e
13:56 dalek MoarVM: 8079ca5 | lizmat++ | / (8 files):
13:56 dalek MoarVM: Merge pull request #331 from ilmari/stat-subsecond
13:56 dalek MoarVM:
13:56 dalek MoarVM: Add subsecond file time ops stat_time and lstat_time
13:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8079ca54aa
14:03 brrt i'm slightly annoyed by the idea that everything c99 introduced is automaitcally better
14:03 brrt but yeah, mostly interesting
14:03 JimmyZ lizmat: pr #331 have wrong op order in interp.c,  it didn't follow the oplists order.
14:04 [Coke] brrt: Imagine how perl 5 people feeel about perl 6! ;)
14:04 brrt i can imagine that yes :-)
14:04 lizmat JimmyZ: suggestions for fixing other than reverting ?
14:05 ilmari JimmyZ: I didn't realise that mattered. is it documented anywhere?
14:06 lizmat FWIW, it builds ok
14:06 JimmyZ lizmat: if the answer of my question in #331 is yes, I would like to suggest fixing it.
14:06 lizmat all the way to Perl 6
14:07 JimmyZ ilmari: It may disallow optimazation for big switch
14:07 JimmyZ ilmari: wrong op order :)
14:08 ilmari if it matters, there should be a test
14:08 ilmari or at the very least a comment
14:08 JimmyZ well patch for comment welcome
14:09 JimmyZ or test :)
14:09 arnsholt What's the problem though? Is it just that the new ops should be added at a different place in the list?
14:10 JimmyZ just same order as oplist file
14:10 ilmari arnsholt: they're in the right place in the list, but they should be in the same order in the dispatch switch()
14:11 arnsholt Oh, right!
14:11 arnsholt That's probably non-trivial to write a test for
14:11 lizmat in any case, it builds Perl 6 ok and spectests ok
14:11 lizmat so I'm not going to revert anything
14:12 lizmat patches for fixes in MoarVM welcome!  :-)
14:12 ilmari arnsholt: grep out the OP(): labels from interp.c and make sure theyre in the same order as in oplist...
14:12 ilmari doesn't seem too hard
14:12 leont Related to that, I recently observed some stat entries being available from nqp and others not
14:13 leont I didn't dive into it yet, but it was odd
14:13 arnsholt I guess. I'm just by nature wary of manupulating source code with that kind of tool. I've done too much parsing, probably =)
14:13 leont E.g. nqp::const::STAT_PLATFORM_INODE worked, but nqp::const::STAT_PLATFORM_NLINK didn't
14:17 ilmari leont: WFM
14:17 ilmari it's spelled NLINKS
14:17 ilmari m: use nqp; say nqp::stat(".", nqp::const::STAT_PLATFORM_NLINKS)
14:17 camelia rakudo-moar 5c0631: OUTPUT«1␤»
14:17 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_PLATFORM_NLINKS)
14:17 camelia rakudo-moar 5c0631: OUTPUT«1␤»
14:18 ilmari JimmyZ, lizmat: https://github.com/MoarVM/MoarVM/pull/333
14:19 leont Ah, just a case of PEBKAC
14:20 arnsholt NQP doesn't complain about non-existent consts? That's a bit LTA
14:20 leont Probably made that conclusion because some other entries also didn't exist (e.g. UID, GID, RDEV)
14:20 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_PLATFORM_UID)
14:20 camelia rakudo-moar 5c0631: OUTPUT«===SORRY!===␤Unknown constant 'STAT_PLATFORM_UID'␤»
14:20 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_UID)
14:20 camelia rakudo-moar 5c0631: OUTPUT«0␤»
14:20 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_PLATFORM_DEVICETYPE)
14:20 camelia rakudo-moar 5c0631: OUTPUT«===SORRY!===␤Unknown constant 'STAT_PLATFORM_DEVICETYPE'␤»
14:20 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_PLATFORM_DECTYPE)
14:20 camelia rakudo-moar 5c0631: OUTPUT«===SORRY!===␤Unknown constant 'STAT_PLATFORM_DECTYPE'␤»
14:21 ilmari m: use nqp; say nqp::stat("/", nqp::const::STAT_PLATFORM_DEVTYPE)
14:21 camelia rakudo-moar 5c0631: OUTPUT«0␤»
14:22 leont What does the PLATFORM_ namespace mean?
14:22 leont Can I safely use the other one?
14:24 dalek MoarVM: 82eb5fc | (Dagfinn Ilmari Mannsåker)++ | src/core/interp.c:
14:24 dalek MoarVM: Move stat_time ops to the right place in dispatch loop
14:24 dalek MoarVM:
14:24 dalek MoarVM: They should be in in the same order as in the oplist file, so that the
14:24 dalek MoarVM: compiler can optimese the switch properly.
14:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/82eb5fc722
14:24 dalek MoarVM: e2d6f75 | (Jimmy Zhuo)++ | src/core/interp.c:
14:24 dalek MoarVM: Merge pull request #333 from ilmari/fix-op-order
14:24 dalek MoarVM:
14:24 dalek MoarVM: Move stat_time ops to the right place in dispatch loop
14:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e2d6f75c00
14:25 ilmari oh, moarvm doesn't have any tests of its own
14:25 ilmari I guess update_ops.p6 could do the checking
14:27 JimmyZ ilmari: moarvm will have test in the future ;)
14:27 leont nqp is effectively the test suite, AFAIK
14:28 JimmyZ moarvm will have its own tests.
14:29 JimmyZ so anyone adding test to t/ is welcome
14:30 ilmari JimmyZ: this only needs to run when modifying the so adding it top update_ops.c makes sense
14:31 ilmari s/modifying the/adding ops/
14:32 JimmyZ I think it's fine too :)
14:36 virtualsue joined #moarvm
14:45 ilmari there's lots of other ops that are out of order in intepr.c
14:45 ilmari s/pr/rp/
14:49 ilmari http://paste.scsys.co.uk/504121
14:50 donaldh joined #moarvm
14:54 ilmari JimmyZ: ^^
15:20 JimmyZ .o_O
15:30 JimmyZ looks like need to be fixed .
15:31 ilmari have you actually compared/benchmared the generated code to see if it matters?
15:32 JimmyZ ilmari: just in case of some compilers is not clever enough
15:32 JimmyZ ilmari: by default, it uses CGOTO on gcc and SWITCH on MSVC
15:46 ilmari ah
16:06 * donaldh is loving the < massive cop out prose-val > ABNF rule which Grammar::BNF can't magically handle ;-)
16:11 pyrimidine joined #moarvm
16:13 colomon joined #moarvm
16:16 donaldh left #moarvm
17:45 domidumont joined #moarvm
18:14 vendethiel joined #moarvm
21:39 vendethiel joined #moarvm

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