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