00:46 sortiz joined
|timotimo||i hate when Configure.pl forbids me from using my branched nqp or moarvm _<||01:01|
|at least git rebase exists||01:03|
02:13 colomon joined 03:19 dalek joined 05:50 dalek joined 06:07 dalek joined
|dalek||p: c4743fe | (Pawel Murias)++ | src/vm/js/nqp-runtime/io.js:
[js] Fix a bug in printf.
Was unnoticed before due to positional writes in append mode being ignored on linux in node.js.
|p: 88f4603 | (Pawel Murias)++ | t/nqp/19-file-ops.t:
Test multiple nqp::printfh calls on a file opended in 'w' mode.
|p: 86d6fed | (Pawel Murias)++ | src/vm/js/SerializeOnce.nqp:
[js] Unbitrot after 5232c5e99086ecffcd888e23f22e01f31b91057
08:18 dalek joined 08:29 dalek joined
|masak||[Tux]++ # persistence||09:42|
|[Tux]||I can automate the testing without the posts here, so the graphs are always up-to-datre, but that would mean less eyes to check if the tests were successful||09:43|
|masak||no, I like seeing the daily reports here.|
|please do keep them.||09:44|
|[Tux] will be away the first week of april, so no reports in that period|
09:50 Woodi_ joined 10:08 FROGGS joined 10:28 RabidGravy joined 10:43 Ven joined 13:11 skids joined
|dalek||kudo/nom: f220a5e | lizmat++ | src/core/List.pm:
Fix RT #127778 by limiting to 32bit values
We could probably go for a non-native combinations implementation for larger values in the future if we see a too large value of n or k, but I think we will need a lot of performance enhancements to make that really workable.
|lizmat||jnthn: nqp::isbig_I seems to limit to 32 bit values, even on a 64 bit build. Is that intentional ?||13:15|
13:17 pmurias joined
|dalek||p: 87595f1 | (Pawel Murias)++ | src/QAST/C (2 files):
Dump the main and load for CompUnits.
Report errors while dumping better and relax the expectations on extra_children().
|p: bcbc07f | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Handle QAST::BVal more properly, make the setting available when blocks are run statically.
|p: 8870fe4 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Update hack.
|nqp: c6e2dcd | (Pawel Murias)++ | src/vm/js/nqp-runtime/serialization.js:|
|lizmat||jnthn: RT #127782 seems to refer to a nice small example of a MoarVM rope bug (on StackOverflow)||13:19|
|jnthn||lizmat: I think so, though I can't remember the whole history on that|
|lizmat||afk for a few hours&||13:25|
|masak refreshes jnthn's memory: rt.perl.org/Public/Bug/Display.html?id=123602||14:49|
|jnthn||masak: I remembered that, I was answering the isbig_I history||14:50|
|masak||oh, I see.|
17:52 colomon joined 18:36 AlexDaniel joined 18:41 colomon joined
|dalek||kudo/nom: 81558b8 | moritz++ | src/core/Signature.pm:
RT #127223: Fix smartmatching an (or against) and empty signature
|ast: 1f2ad00 | moritz++ | S03-smartmatch/signature-signature.t:
RT #127223: smart matching and empty signatures
|moritz||that was easy :-)||20:21|
|having a fast laptop reall makes rakudo hacking more fun :-)||20:25|
|moritz||how do I check from NQP if an object is invocable?||20:32|
|masak||almost too easy||20:39|
|we should rename that to something less obvious|
|otherwise who knows who might contribute|
|moritz||doesn't help me though: rt.perl.org/Ticket/Display.html?id...xn-1393486||20:45|
22:35 skids joined
|timotimo||oh lord. here an instance of =:= is being speshed into a call into find_best_dispatchee (after a multicachefind on the dispatcher cache, at least)||22:50|
|but really, that operator should really want to be ridiculously fast||22:51|
|i wonder if it's also weird like that when used by our infrastructure for iteration and such|
|lizmat||timotimo: =:= is basically an nqp::iseqaddr or so?||22:54|
|i don't understand why we don't spesh directly to that||22:58|