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 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 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 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 |