| ugexe | $++ is too useful imo | 02:41 | |
| BenGoldberg | m: print $+^=1 for 1..5; | 03:10 | |
| camelia | 10101 | ||
| lizmat | commit: 2016.03 dd <a a c>.Bag (<) <a b b c>.Bag | 09:39 | |
| committable6 | lizmat, ¦2016.03: «Bool::True» | ||
| lizmat | that is incorrect in my view, as there are more a's on the left than on the right | ||
| hmmm... | 09:40 | ||
| unless we think Setty semantics | |||
| commit: 2016.03 dd <a a c>.Bag.Set (<) <a b b c>.Bag.Set | 09:41 | ||
| committable6 | lizmat, ¦2016.03: «Bool::True» | ||
| lizmat | hmmm.. perhaps I have conflated (<+) and (<) | 09:42 | |
| Geth | rakudo/nom: 43fc751be2 | (Elizabeth Mattijsen)++ | src/core/Failure.pm Make sure unhandled failures don't coerce QuantHashy |
10:04 | |
| dogbert2 | lizmat: just ran a few code examples from docs and stumbled upon the difference | 10:22 | |
| lizmat | dogbert2: yeah, you probably found a bug I introduced :-( | 10:23 | |
| lizmat is watching www.youtube.com/watch?v=VqhLWgvIbz0 | |||
| dogbert2 | m: my ($a, $b) = BagHash.new(2, 2, 4), BagHash.new(2, 3, 3, 4); say $a (^) $b # what about this | 10:26 | |
| camelia | bag(3(2), 2) | ||
| dogbert2 | commit: 2016.12 my ($a, $b) = BagHash.new(2, 2, 4), BagHash.new(2, 3, 3, 4); say $a (^) $b | ||
| committable6 | dogbert2, ¦2016.12: «set(3)» | ||
| dogbert2 | interesting, is that jnthn | 10:27 | |
| masak | aye | 11:50 | |
| lizmat | dogbert2: maybe adding baggy semantics to (<) and (^) wasn't such a good idea | 11:54 | |
| dogbert2: thing is, when I did it, it did not break any spectests :-( | 11:55 | ||
| except the one in mix.t atm | |||
| Geth | rakudo/nom: 06379113bd | (Elizabeth Mattijsen)++ | src/core/Failure.pm We probably want to QuantHash handled Failures |
11:58 | |
| dogbert2 | perhaps we should 'borrow' some of the docs examples | 12:12 | |
| as for the semantics perhaps we need more input wrt those | 12:14 | ||
| lizmat | well, for now I'm reverting the baggy semantics for (<) and (<=) and (^) | 12:17 | |
| baggy semantics for (^) was troublesome anyway, specially in the [(^)] @a case | |||
| dogbert2 | begone with it then :) | 12:27 | |
| I can add those test if you want, have to go out on an errand first though & | 12:30 | ||
| lizmat | dogbert2: tests are not the issue *now* :-) | 12:32 | |
| dogbert2 | I know, but if you revert it can be good to have them there :) | 12:33 | |
| Geth | rakudo/nom: 724cbca710 | (Elizabeth Mattijsen)++ | 2 files Revert to Setty semantics for (<=) Documentation assumes Setty semantics, as dogbert2++ pointed out. Also, there *is* a Baggy equivalent of (<=) already, it's called (<+) which I hadn't realized at the time of adding Baggy semantics to (<=) around March 2016. |
12:34 | |
| roast: 3bab9ac2a3 | (Elizabeth Mattijsen)++ | S03-operators/set_subset.t Follow revert to Setty semantics of (<=) As done in github.com/rakudo/rakudo/commit/724cbca710 |
12:35 | ||
| rakudo/nom: d4436e18ce | (Elizabeth Mattijsen)++ | src/core/set_proper_subset.pm Revert to Setty semantics for (<) Because we also did this for (<=). |
12:57 | ||
| roast: f8d8bff1cc | (Elizabeth Mattijsen)++ | S03-operators/set_proper_subset.t Follow revert to Setty semantics of (<) As done in github.com/rakudo/rakudo/commit/d4436e18ce |
12:59 | ||
| lizmat | hmmm.. seems reverting now breaks 4 tests in mix.t :-( | 13:30 | |
| maybe we should think about deprecating (<+) and allow baggy semantics for (<) and (<=) after all ?? | 13:31 | ||
| afk& | |||
| dogbert2 | commit: 2016.01 #` | 13:57 | |
| committable6 | dogbert2, ¦2016.01: «» | ||
| dogbert2 | commit: 2015.01 #` | ||
| committable6 | dogbert2, ¦2015.01: «» | ||
| dogbert2 | commit: 2014.08 #` | ||
| committable6 | dogbert2, ¦2014.08: «» |