Geth rakudo: af9812fa73 | (Zoffix Znet)++ | src/core/Rakudo/Iterator.pm
Fix incorrect .count-only/.bool-only impls

My undertstanding is these methods need to account for the items already pulled from the iterator; that is, a consumer can always do `.pull-one xx .count-only` (if .count-only is implemented) to legally pull all of the remaining elements from the iterator.
... (5 more lines)		 01:52
roast: 88a12f6984 | (Zoffix Znet)++ | MISC/bug-coverage.t
Add coverage for .bool-only/.count-only iterator methods

Covers bugs fixed by github.com/rakudo/rakudo/commit/af9812fa73		 01:53
rakudo: 1dbf5f589d | (Zoffix Znet)++ | t/spectest.data
Add MISC/bug-coverage.t to list of tests to run
roast: 1743894c03 | (Zoffix Znet)++ | S32-list/tail.t
Add more explicit test for .tail(5).tail bug

RT#132543: rt.perl.org/Ticket/Display.html?id=132543
More tests for the underlying cause in:
  github.com/perl6/roast/commit/88a12f6984		 02:16
synopsebot RT#132543 [new]: rt.perl.org/Ticket/Display.html?id=132543 Can't tail a tail.
Geth rakudo: jstuder-gh++ created pull request #1299:
Issue 1268: Fix lazy slicing stopping at the first deleted		 03:18
synopsebot RAKUDO#1299 [open]: github.com/rakudo/rakudo/pull/1299 Issue 1268: Fix lazy slicing stopping at the first deleted
lizmat Files=1229, Tests=75884, 316 wallclock secs (14.64 usr 5.21 sys + 2181.65 cusr 213.45 csys = 2414.95 CPU) 10:25
yoleaux 02:01Z <Zoffix> lizmat: I stole the .tail(5).tail bug. Would you be able review my fix in that and other iterators github.com/rakudo/rakudo/commit/af9812fa73 ? Unless I'm misunderstanding iterator protocol, the .count-only/.bool-only need to account for iterator's consumation and adjust their values. I removed some of the impls because I assumed they weren't worth it. The one (IIRC only one...) exception is
02:02Z <Zoffix> lizmat: RI::I.Combinations; I couldn't figure out how to impl them. I also added tests in github.com/perl6/roast/commit/88a12f6984
lizmat .tell Zoffix will look at this, but am not sure I can look at it today: meanwhile count-only / bool-only should only work on iterators that can determine whether they *will* produce something without actually producing anything 10:28
yoleaux lizmat: I'll pass your message to Zoffix.
lizmat .tell Zoffix count-only / bool-only should *never* be implemented for an iterator if they need to produce something to determine whether they can produce something 10:29
yoleaux lizmat: I'll pass your message to Zoffix.
lizmat .tell Zoffix hope this made sense
yoleaux lizmat: I'll pass your message to Zoffix.
Zoffix . 10:33
yoleaux 10:28Z <lizmat> Zoffix: will look at this, but am not sure I can look at it today: meanwhile count-only / bool-only should only work on iterators that can determine whether they *will* produce something without actually producing anything
10:29Z <lizmat> Zoffix: count-only / bool-only should *never* be implemented for an iterator if they need to produce something to determine whether they can produce something
10:29Z <lizmat> Zoffix: hope this made sense
Zoffix Yeah. They just calculate.
Also the one more where I removed and couldn't figure out a way to provide them is Mappy iterator. It did just nqp::elems($!hash) and don't seem it tracks how many things it produced 10:34
and Mappy-kv-from-pairs
lizmat Zoffix: my mind is on a lot of other, family, things at the moment 10:35
Zoffix Sure. No problem. 10:36
lizmat won't probably have the quality time to look at it before Saturday
iterators need quality time :-)
Zoffix :)
tbrowder .tell samcv i have answered your question at roast PR #361 11:23
yoleaux tbrowder: I'll pass your message to samcv.
dogbert2 Zoffix: still playing the car crash simulator? 12:10
lizmat .tell Zoffix not really looked at the patch yet, but it feels to me it changes the semantic of "count-only": I intended it as "number of elements the iterator can produce in total", whereas your patch turned it into "number of elements the iterator can produce still" 13:27
yoleaux lizmat: I'll pass your message to Zoffix.
lizmat .tell Zoffix still in two minds about that whether that is a good thing or not
yoleaux lizmat: I'll pass your message to Zoffix.
lizmat afk for a while&
pmurias When we match a unicode property with an argument like: /<:Numeric_Type<Digit>>/ 13:28
it seems we use match against the short name for some properties like bc, and the long names for others like nt/Numeric_Type
how do we want to fix that? 13:29
Zoffix dogbert17: no. It's still early access and it's pretty empty. There's no traffic or.. anything dynamic really, so gets kinda lonely
yoleaux 13:27Z <lizmat> Zoffix: not really looked at the patch yet, but it feels to me it changes the semantic of "count-only": I intended it as "number of elements the iterator can produce in total", whereas your patch turned it into "number of elements the iterator can produce still"
13:27Z <lizmat> Zoffix: still in two minds about that whether that is a good thing or not
pmurias one possible solution would be to use the long name when matching against the prop in long form and the short value alias when we have the prop in the shor form 13:30
so we would have /<:Numeric_Type<Digit>>/ and /<:nt<Di>>/ 13:31
does this sound sane?
Zoffix .tell lizmat Yeah, my patch changed .count-only to be "how many can you produce". The original semantic of total is kinda pointless isn't it? Unless, I keep track and know for sure the iterator has never been iterated yet, I can't use that method. That's exactly was the reason for the bug in .tail(5).tail; if .count-only doesn't actually indicate the number of elements the iterator will produce, we can't 13:32
yoleaux Zoffix: I'll pass your message to lizmat.
Zoffix use it to perform the optimization
.tell lizmat use it to perform the optimization 13:33
yoleaux Zoffix: I'll pass your message to lizmat.
pmurias other example would be /<:bc<AL>>/ and /<:Bidi_Class<Arabic_Letter>>/
the other thing I suggest we do is to make unknown unicode properties cause compile time errors 16:14
m: say 9 ~~ /<:no_such_property_for_real>/
camelia Nil
pmurias m: say 9 ~~ /<:!no_such_property_for_real>/
camelia ļ½¢9ļ½£
pmurias how do we remove something from Perl 6? 16:38
"The contributory properties (those of the form Other_XXX) are sets of exceptions used to generate properties in DerivedCoreProperties.txt. They are incomplete by themselves and not intended for independent use, for example an API returning property values would implement the corresponding derived core property instead." 16:39
we have those in roast unfortunately :(
Geth roast: 61c1181c7b | pmurias++ | S05-mass/properties-general.t
Add a test for a default value of a unicode property
 16:48
roast: 1d3b5726cb | pmurias++ | S05-mass/properties-general.t
Skip strongly suspected wrong test on js
pmurias I guess I'll just move them to a separate file so that they can be deprecated as they seem useless 16:50
timotimo .tell zoffix all we can do is use a proper iterator for List.tail, i.e. not give a ReifiedList iterator that had pieces skipped. 16:54
yoleaux timotimo: I'll pass your message to zoffix.
[TuxCM] Hmm, I cannot imagine why working from england would cause this: 16:56
Rakudo version 2017.11-78-g1dbf5f589 - MoarVM version 2017.11-28-gba1fb9542
csv-ip5xs1.089 - 1.116
csv-ip5xs-2012.510 - 12.874
csv-parser11.832 - 12.039
csv-test-xs-200.448 - 0.456
test11.332 - 11.361
test-t2.833 - 2.839
test-t --race1.235 - 1.254
test-t-2051.263 - 51.310
test-t-20 --race17.204 - 17.475
[TuxCM] put up glasses and sees nothinh irregular. 16:57
eater it's just
all slower
oh no
Zoffix .
yoleaux 16:54Z <timotimo> Zoffix: all we can do is use a proper iterator for List.tail, i.e. not give a ReifiedList iterator that had pieces skipped.
eater faster!
Zoffix timotimo: I'm not following at all. What is that in reference to? 16:58
timotimo: I mean I know it's about .tail(5).tail, but that's already fixed and the discussion is about whether the user of `.count-only` optimization method must have the responsibility of carrying state information about whether iterator was ever .pulled, .pushed, or .skipped. IMO no, that severely cripples .count-only; if the user has ability to carry that state, often they'd be able to derive count 17:03
along with it.
Especially since a large point of iterators is not having to keep previously consumed values around, so makes little sense to me to have two methods that supposed to offer would optimizations require the user to track entire lifetime of the iterator and risk getting invalid data from the methods if they didn't track everything. 17:05
+ implementor of .count-only that adjusts can either track count or derive it in place or not implement .count-only if tracking ain't worth it, whereas a user of static .count-only must always keep tracking and has less precise idea of whether it's worth it 17:18
.count-only/.bool-only adjusting to what's available in the iterator is a clear winner to my mind. By FAR less chance of getting incorrect result, easier use for the user, more optimization wins. 17:19
Zoffix &
Geth roast: 832ab077c5 | (Tom Browder)++ (committed by Samantha McVey) | 2 files
Add new tests for POD tables rakudo/rakudo/#1282

Add new tests for fix to rakudo/rakudo#1282		 21:48
synopsebot RAKUDO#1282 [closed]: github.com/rakudo/rakudo/issues/1282 [POD] need to handle table cells with char column separators as data
pmurias samcv: what do you think about making unrecognized unicode properties cause an error at compile time instead of failing silently? 21:51
samcv well. hmm. 21:52
might be easier to make it a warning to start with. 21:53
Geth rakudo: softmoth++ created pull request #1300:
Untwine Pod		 23:59
synopsebot RAKUDO#1300 [open]: github.com/rakudo/rakudo/pull/1300 Untwine Pod

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!