buggable ???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 4 ballots submitted by 3 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 28! Congratulations to jnthn! You win a roll of duck tape!
tadzik :D 01:04
lizmat Files=1208, Tests=63592, 217 wallclock secs (13.08 usr 4.91 sys + 1312.49 cusr 133.75 csys = 1464.23 CPU) 09:53
m: dd 42.Set (<) ^Inf .Set # another case of badly handling failure 10:17
camelia Bool::False
lizmat m: dd 42.Set (<) ^100 .Set # another case of badly handling failure
camelia Bool::True
lizmat m: dd ^Inf .Set (<=) ^Inf .Set # so why is this False ??? :-) 10:39
camelia Bool::False
lizmat hint: the .WHICH of ^Inf .Set is not the same 10:40
AKA, should we allow a single Failure to coerce to a Set ?
jnthn A roll of duck tape! \o/ 10:41
timotimo duckroll?
jnthn :P 10:42
timotimo do you prefer your rolls with sweet toppings, or savory?
Geth rakudo/nom: 3058ba0d48 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Make the (<) and (<=) family handle lazy lists properly

jnthn Well, if there's duck inside of them, then it'd be sweet bean sauce or some such... :-) 10:44
Geth rakudo/nom: ee54dda30b | (Elizabeth Mattijsen)++ | 13 files
Split up set_operators.pm into separate files

  - the file was getting too large
  - by having different source files, execution errors become more meaningful
  - file names should match name of test-files in S03-operator
  - this will require running configure again
11:28
roast: f6e1418fa2 | (Elizabeth Mattijsen)++ | 2 files
Make filename same as in the core setting

11:40
rakudo/nom: 662794668b | (Elizabeth Mattijsen)++ | t/spectest.data
Track renaming of S03-operators/proper_subset.pm

11:41
rakudo/nom: cb80390f79 | (Elizabeth Mattijsen)++ | 10 files
Add list of operators implemented

As the files group families of set operators and it is not always clear at first sight which ones are implemented where.
11:52
roast/master: 7 commits pushed by (Elizabeth Mattijsen)++ 11:59
rakudo/nom: 1b56064b23 | (Elizabeth Mattijsen)++ | t/spectest.data
Follow renaming of S03-operators/set* test files

12:03
rakudo/nom: 099a84b4ac | (Elizabeth Mattijsen)++ | src/core/set_elem.pm
Make Str:D (elem) Map a teeny bit faster

  - 3% for normal Map/Hash
  - 10% for object hash
  - felt worthwhile for such an elementary operation
12:31
dogbert2 there is a method in the Channel class called 'receive-nil-on-close'. Did that slip through the cracks since I can't seem to find it it roast? 12:44
Geth roast: 979f2a88a4 | (Elizabeth Mattijsen)++ | S03-operators/set_addition.t
Fix some typoes

12:47
lizmat jnthn would know
timotimo what does git blame say? 12:50
dogbert2 it say something about someone name Timo :-) 12:51
just joking :-) will check
oops, git seems to be looking at lizmat (if I understand git blame correctly) 12:53
lizmat lizmat looks to see if it jogs any memory
jnthn It's used in the iterator impl 12:55
Probably wants to be made private if it's just for that
dogbert2 I'm really just interested if it's anything that should be doc'ed or hidden from view
lizmat jnthn: afaics, this construct is because !receive throws rather than return a Failure 12:56
perhaps !receive should just return a Failure and then have receive throw it if it gets a failure ? 12:57
jnthn That feels a bit roundabout 12:58
Given that a Failure contains the Exception so it's a throwaway Failure every time
lizmat well, I don't want to put a try block in the iterator
jnthn Surely it'd be faster if it was just calling !receive(0) by itself rather than going via an odd-seeming public method? :) 12:59
That or just pass $!queue to the iterator 13:00
lizmat ??
jnthn Though that'd lead to a bit of logic dupe
oh, it's already getting $!channel
Either way, there's loads of ways to do this without exposing a receive-nil-on-close 13:01
lizmat except maybe someone would like to receive and just get a Nil when the channel closes, rather than having an exception thrown? 13:02
pretty sure that was my thinking when I did that 13:03
jnthn While we do use Nil with .poll, it does mean that if you .send Nil on a Channel things will not go too well 13:05
It'd be nice of the iterator were not vulnerable to this
lizmat but would the Nil not just become an Any ?
jnthn Supply is vulnerable to this also 13:06
Channel.Supply that is
Where would that happen?
But so far as I can tell, "no" :)
lizmat with the push on $!queue ?
hmmm...guess not 13:07
jnthn No
lizmat dogbert2: could you ticket this vulnerability to Nil so it won't fall through the cracks ? 13:09
dogbert2 lizmat: sure
just so I understand, the vulnerability is that Nil can be sent on a Channel if you call receive-nil-on-close? 13:13
lizmat that the Nil would be taken as a close when using the iterator or .Supply 13:15
jnthn It's that iterator and Supply will early if Nil is sent on the Channel 13:16
We can just have that behavior on .poll as a "well, tough luck" :)
But for iterator and Supply we should do better
Geth roast: 6bcc903e55 | (Elizabeth Mattijsen)++ | S03-operators/set_multiply.t
Add thorough testing for (.) and friends

  - de-activated tests currently fail
13:18
rakudo/nom: 75e87d1f52 | (Elizabeth Mattijsen)++ | t/spectest.data
Make sure we run the (.) tests

13:19
dogbert2 will this do? RT #131684 13:21
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131684
lizmat dogbert2++ 13:26
dogbert2 I guess I have to find another method in need of docs then :) 13:29
AlexDaniel AlexDaniel looks at 263 open issues 13:30
lizmat hmmm... is there a way that MAIN(@a) can match parameters from the CLI ? 13:33
if not, maybe we should croak on such a signature ?
dogbert2 AlexDaniel: sometimes I pick stuff from there as well but for every one fixed two or three new ones pop up :( 13:36
on the positive side, I guess that more and more people are actually using the docs 13:37
[Tux] This is Rakudo version 2017.06-126-g75e87d1f5 built on MoarVM version 2017.06-30-g389e9732 13:57
csv-ip5xs 2.701
test 12.654
test-t 4.050 - 4.087
csv-parser 12.451
jnthn dogbert2: It's the same situation in the Rakudo RT queue
[Tux] sorry for being late.
[Tux] works on YAPC Schedule
mst I love how you're working on the schedule but neither the website, facebook or twitter ever announced the CFP or the CFP deadline 14:07
mst wonders how many people haven't submitted yet because of that
Geth rakudo/nom: c56f0af9a8 | (Elizabeth Mattijsen)++ | src/core/set_multiply.pm
Fix outstanding (.) issues

14:21
roast: a6501d3041 | (Elizabeth Mattijsen)++ | S03-operators/set_multiply.t
Activate now passing tests

14:22
lizmat mst: act.perlconference.org/tpc-2017-ams...apers.html # been there for a while 14:23
mst lizmat: act.perlconference.org/tpc-2017-amsterdam/ makes no reference to it 14:24
lizmat: act.perlconference.org/tpc-2017-amsterdam/news/ makes no reference to it
lizmat: there is a page there, but, as I said, quite specifically, the website never announced it
lizmat under Talks & events, call for papers
mst lizmat: in fact, I know a number of people who only managed to find that page via a 'site:' google search
right, which is completely useless and an utter botch 14:25
lizmat that it's missing in news, is indeed sub-optimal :-(
mst and that it was never on social media
lizmat noted
mst I feel like it would've been better to have a final social media push giving people a week or so then close submissions
lizmat meanwhile, 75 talks were submitted 14:26
mst which is stupidly low, yes, which is precisely my point 14:28
compare to the last few years' stats 14:29
AlexDaniel dogbert2: github.com/perl6/doc/issues/561 :) 14:33
[Tux] mst: current plan is to make a deadline of fri Jun 7 midnight and start a campaign on twitter/facebook/linkedin asap 14:43
mst [Tux]: that would be excellent 14:44
lizmat [Tux] July 7 I hope ?
mst ... heh, hadn't notice that typo 14:45
Geth roast: 1510943d97 | (Elizabeth Mattijsen)++ | 2 files
Remove now superfluous (.) tests

15:27
roast: 2fcb4f93da | (Elizabeth Mattijsen)++ | S03-operators/set_multiply.t
Oops, forgot to de-activate debug helper

15:34
[Tux] lizmat, yes, of course 15:40
dogbert2 m: my ($a, $b) = BagHash.new(2, 2, 4), BagHash.new(2, 3, 3, 4); say $a (<) $b # correct ? 16:43
camelia False
dogbert2 commit: 2016.03 my ($a, $b) = BagHash.new(2, 2, 4), BagHash.new(2, 3, 3, 4); say $a (<) $b
committable6 dogbert2, ¦2016.03: «True»
AlexDaniel AlexDaniel feels like a bot that posts related links 19:29
cog_ m: sub a($) { say ++$ }; a('foo'); a('foo') 22:43
camelia 1
2
cog_ I would expect using a placeholder variable to blow up instead of becoming a $ state variable 22:44
timotimo outside of signatures $ is always an anonymous state variable 22:45
also, a($) gives you an anonymous variable, too, which means you can't reference it anyway 22:48
cog_ ok, same name, different things 22:57
in a sense that the very purpose of $ as a variable, where each instance is a different variable. But that's piling magic over magic, I still thinks that deserves a warning for someone who would think $ in a signature could be a normal parameter instead of a placeholder 23:01
timotimo and to defuse the warning you'd have to spell out (state $) every time? 23:04
cog_ maybe 23:06