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.
07:11
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
07:42
08:18 dalek joined 08:29 dalek joined
[Tux] test 22.502 09:03
test-t 12.656
csv-parser 25.642
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.
13:13
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().
13:17
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
[Coke] stackoverflow.com/questions/362085...e-this-way 14:03
masak refreshes jnthn's memory: rt.perl.org/Public/Bug/Display.html?id=123602 14:49
via strangelyconsistent.org/blog/youre-...-all-alike
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
20:14
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
RabidGravy yay! 20:28
moritz how do I check from NQP if an object is invocable? 20:32
ah, nqp::isinvokable 20:33
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
timotimo yes 22:57
i don't understand why we don't spesh directly to that 22:58