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