01:38 colomon joined 02:21 colomon joined 02:46 geekosaur joined
[Tux] test 21.861 09:01
test-t 12.330
csv-parser 25.651
09:15 RabidGravy joined
masak slightly better than yesterday 10:09
lizmat yeah, but without any significant changes, means it is within noise? 10:56
masak probably 11:19
dalek kudo/nom: 1d12563 | lizmat++ | src/core/operators.pm:
Fix for RT #127777

By basically giving it the same treatment as with combinations()
lizmat m: say "z" before "aa" # shouldn't this be True ?? 11:51
camelia rakudo-moar 1d1256: OUTPUT«False␤»
lizmat masak: ^^^ opinion ? 11:53
timotimo i think even though we have the magical behavior in the .. operator, i'd prefer the before/after operators to behave like lt and gt in general 11:56
masak lizmat: no, I think you're confusing the order postfix:<++> and .succ produces, with lexical order 11:59
I'd much prefer `before` to produce lexical order, just like `lt` does
lizmat then we have a great thinko in Range.iterator for strings :-) 12:00
lizmat looks at fixing this (instigated by RT #127753 12:04
timotimo ah, so that's what busted the order of ranges 12:10
lizmat yeah...
it's been like that for a while :-(
timotimo seems like a big oversight to not have that tested by roast :S
lizmat m: .print for ":" .. "?" # should this work at all ??? 12:11
camelia rakudo-moar 1d1256: OUTPUT«:;<=>?»
lizmat afaik, we only define .succ for a certain set of magical chars 12:12
(and .pred)
perhaps we should disallow and ranges in which the endpoints are not within the set of magical chars ? 12:13
timotimo no, i want ranges like that 12:16
dalek p: 28b7689 | (Pawel Murias)++ | src/vm/js/nqp-runtime/deserialization.js:
[js] Remove dead code.
p: afa5dbf | (Pawel Murias)++ | src/vm/js/nqp-runtime/deserialization.js:
[js] Remove code that support an old serialization version format.
p: bb7b097 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Implement nqp::{shift,unshift}_{s,i}. Remove legacy raw array support.
p: 8f2c3db | (Pawel Murias)++ | t/nqp/59-nqpop.t:
Test nqp::{unshift, shift}_{s,i}.
lizmat timotimo: ok, so if both endpoints are in a magical range, we use the .succ magic 12:18
else, we can only have 1 char as endpoints, and then we do this based on ord() 12:19
timotimo i'd expect that 12:20
dalek p: a58284d | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files):
[js] Run fixjsstyle.
timotimo an oversight it may be to haven't tested this, but it's also surprising nobody stumbled upon the bug in such a long time 12:23
lizmat yeah... :-( 12:26
the .succ / .pred logic is heavily embedded in Str
it would have to be moved to e.g. Rakudo::Internals to make it accesible in Range 12:27
timotimo imagines a tightly-packed yarnball
lizmat yeah...
sortiz "long time" now three months!
13:20 colomon joined
lizmat goes cycling while contemplating a solution that is both correct and order of magnitudes faster :-) 13:21
13:24 Skarsnik joined 13:47 skids joined
TimToady .. turns into ... semantics when evaluated as a list, so you're proably better off optimizing ... for known endpoints 15:48
in particular, magical ranges come into play *only* if the two strings are of unequal length (or if the right endpoint is *) 16:03
so 「.print for ":" .. "?"」 has nothing whatsoever to do with Str.succ, only Int.succ 16:05
and hence it has nothing to do with magical ranges either 16:06
timotimo ah, of course 16:41
19:30 FROGGS joined 19:40 geekosaur joined
dalek kudo/nom: e7a09e7 | lizmat++ | src/core/Bool.pm:
Make sure Bool can also .enums like any other Enum

The Bool refactor seems to have missed this particular method. Spotted while investigating RT #127789
lizmat m: say "9".succ # sorta expected Str "00" instead of Int 10 ?? 20:19
camelia rakudo-moar 1d1256: OUTPUT«10␤»
lizmat m: dd "9".succ # hmmm... it's a Str after all ?? 20:22
camelia rakudo-moar 1d1256: OUTPUT«"10"␤»
lizmat ah, I finally grok the reason for the carrydigit hash 20:25
21:01 colomon joined
nine lizmat: oh, indeed, I didn't even know .enums. Thanks for fixing :) 21:25
lizmat yw :-) 21:26
masak m: say "silly-image-of-cat-9.jpg".succ 21:28
camelia rakudo-moar e7a09e: OUTPUT«silly-image-of-cat-10.jpg␤»
masak lizmat: that's probably why "9".succ is "10"
lizmat yeah, I figured it out :-) 21:30
masak :)
dalek kudo/nom: ccc38a0 | lizmat++ | / (2 files):
Refactor the templating logic for native arrays

Before using it in other places.
22:04 geekosaur joined
dalek kudo/nom: 47d21b8 | lizmat++ | tools/build/makeMAGIC_INC_DEC.pl6:
WIP on generating hashes for .succ/.pred
lizmat good night, #p6dev! 22:26
timotimo gnite lizmat!
.oO( it's going to be a short night )