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: «»