| [Tux] | This is Rakudo version 2016.09-142-g605f272 built on MoarVM version 2016.09-27-g0bdbd6e | 07:42 | |
| csv-ip5xs 3.100 | |||
| test 16.805 | |||
| test-t 7.370 | |||
| csv-parser 18.366 | |||
| lizmat | Files=1146, Tests=53274, 234 wallclock secs (14.15 usr 3.94 sys + 1454.00 cusr 134.71 csys = 1606.80 CPU) | 09:35 | |
| dalek | ast: 03380fe | lizmat++ | S06-signature/types.t: Make test less specific to accommodate more specificity |
09:51 | |
| ast/6.c-errata: 9dd5444 | lizmat++ | S06-signature/types.t: Make test less specific to accommodate more specificity |
09:53 | ||
| nine | lizmat: I just love that commit message :) | 10:30 | |
| I now have a fully automated script for creating updated nqp RPMs on the Open Build Service including writing of the changelog :) Now only automation for rakudo itself is missing | 11:57 | ||
| Soon we'll have fresh openSUSE packages on every release day :) | |||
| p3rln00b | NeuralAnomaly: stats | 12:03 | |
| NeuralAnomaly | p3rln00b, [ā] Next release will be in 1 day and 1 week. Since last release, there are 36 new still-open tickets (33 unreviewed and 0 blockers) and 142 unreviewed commits. See perl6.fail/release/stats for details | ||
| nine | Rakudo's ChangeLog will be harder as that's just too much to put into the .spec file :/ Maybe I should just write that it's a new version | 12:04 | |
| p3rln00b | Files=1194, Tests=129670, 133 wallclock secs (20.40 usr 2.73 sys + 2306.51 cusr 220.83 csys = 2550.47 CPU) | 14:55 | |
| (guess it doesn't hurt for me to post these once in a while, so we get some sort of historical benchmark going in the logs) | 14:56 | ||
| nine | lizmat++ does that, too | ||
| p3rln00b | ZOFVM: Files=1194, Tests=129670, 133 wallclock secs (20.40 usr 2.73 sys + 2306.51 cusr 220.83 csys = 2550.47 CPU) | 15:00 | |
| (I just realized, it may be hard to grep for them :P, so I'll be using a prefix) | |||
| m: sub { 42.return }() | 15:17 | ||
| camelia | rakudo-moar 605f27: OUTPUTĀ«Attempt to return outside of any Routineā¤ in sub at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
| p3rln00b | That's broken innit... | ||
| jnthn | Looks like | 16:10 | |
| timotimo | it looks for a return in the wrong position? | 16:19 | |
| p3rln00b | m: say (-125)**(1/3) | 16:57 | |
| camelia | rakudo-moar 605f27: OUTPUTĀ«NaNā¤Ā» | ||
| p3rln00b | m: say (-125+0i)**(1/3) | ||
| camelia | rakudo-moar 605f27: OUTPUTĀ«2.5+4.33012701892219iā¤Ā» | ||
| p3rln00b | :S | ||
| m: say (-1+0i) ** .5 | 16:58 | ||
| camelia | rakudo-moar 605f27: OUTPUTĀ«6.12323399573677e-17+1iā¤Ā» | ||
| p3rln00b | For the curious, that was rt.perl.org/Ticket/Display.html?id...xn-1430565 | 17:22 | |
| p3rln00b puts away his pretend Math Degree back in the drawer. | |||
| timotimo | do other systems try to give 0+1i for that by finding out if it's that special case? | 17:23 | |
| p3rln00b | Why is that a special case? | 17:24 | |
| Oh the first one you mean | |||
| Perl 5 gives NaN | 17:25 | ||
| timotimo | i meant getting the sqrt of -1+0i | ||
| giving NaN for -125 is correct. we only give you complex out if you put complex in | |||
| p3rln00b | m: say sqrt(-1+0i) | ||
| camelia | rakudo-moar 605f27: OUTPUTĀ«0+1iā¤Ā» | ||
| p3rln00b | timotimo: but it's not a complex. The result is -5 | 17:26 | |
| heh, python gives (2.5+4.330127018922192j) for it :} | 17:28 | ||
| timotimo | oh! | 17:29 | |
| it's the third root | |||
| p3rln00b | Yeah | ||
| timotimo | why didn't i look closely enough ... | ||
| dogbert17 | o/ | 17:32 | |
| p3rln00b | \o | 17:33 | |
| dogbert17 | is everyone valgrinding? | ||
| p3rln00b is working... (well supposed to) | |||
| Speaking of which. Perhaps I should do a couple of hours of honest labour this week.. | |||
| p3rln00b & | |||
| :) | |||
| dogbert17 | :) | 17:34 | |
| when running valgrind on some perl6 code the Leak Summary often looks like below. Are those the expected numbers? | 17:35 | ||
| ==29364== LEAK SUMMARY: definitely lost: 5,454 bytes in 181 blocks; indirectly lost: 14,112 bytes in 668 blocks; possibly lost: 120,032 bytes in 3,751 blocks; still reachable: 13,409 bytes in 9 blocks | |||
| most spectests I have valgrinded have given the number above but 't/spec/S17-procasync/stress.t' stands out with | 17:43 | ||
| LEAK SUMMARY: definitely lost: 88,106 bytes in 957 blocks; indirectly lost: 65,868 bytes in 1,229 blocks; possibly lost: 251,384 bytes in 7,228 blocks | |||
| dalek | p: b258244 | usev6++ | src/vm/jvm/QAST/Compiler.nqp: Bulletproof against nodes without .orig on JVM ... as it was done with d6370eb8be for MoarVM. Makes this type of code pass (and fixes RT #126899): my $side-effect = 0; [andthen] Int, ++$side-effect |
17:49 | |
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126899 | ||
| FROGGS | dogbert17: moarvm does an unclean shutdown, so yes, it is expected to leak | 18:16 | |
| dogbert17: though you can alter your perl6 runner and add a moar switched called: --full-cleanup | 18:17 | ||
| dogbert17 | FROGGS: I have --full-cleanup set | 18:43 | |
| FROGGS | well, then it is meant to be very nice to valgrind I suppose | 18:44 | |
| dogbert17 | here's an piece of the leak report for t/spec/S17-procasync/stress.t | 18:46 | |
| ==30680== 4,556 (4,020 direct, 536 indirect) bytes in 67 blocks are definitely lost in loss record 1,413 of 1,780 | |||
| ==30680== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) | |||
| ==30680== by 0x4121A27: MVM_calloc (alloc.h:11) | |||
| ==30680== by 0x4121CB3: MVM_io_syncpipe (syncpipe.c:115) | |||
| ==30680== by 0x40E0D7F: MVM_interp_run (interp.c:4598) | |||
| ==30680== by 0x41C8A22: MVM_vm_run_file (moar.c:304) | |||
| ==30680== by 0x8048EA5: main (main.c:191) | |||
| AlexDaniel | What's the easiest way to provide fallback subroutines if some module is not installed? | 19:33 | |
| ah, wrong channel | |||
| dalek | kudo/nom: 0d9b547 | usev6++ | src/core/metaops.pm: Remove bandaid for JVM Looks like back in 2015 those unbound closures caused NPE. This seems to be fixed now. |
22:24 | |
| kudo/nom: 2285d35 | (Zoffix Znet)++ | src/core/metaops.pm: Merge pull request #898 from usev6/jvm_cleanup Remove bandaid for JVM |