digitalmars.D.learn - slidingSplitter + retro
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (15/15) Oct 06 2014 I've almost satisfied with my new range slidingSplitter at
- monarch_dodra (5/20) Oct 06 2014 I don't have time to investigate tonight, and it's probably not
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (7/11) Oct 06 2014 I've added some extra asserts in the last hour.
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (3/5) Oct 06 2014 No, that wasn't the current problem.
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (8/10) Oct 06 2014 I nailed it!
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (6/7) Oct 06 2014 One more thing: I'm unsure how the indexes lower and upper should
I've almost satisfied with my new range slidingSplitter at https://github.com/nordlow/justd/blob/master/range_ex.d#L19 All unittest work as expected except my radial test https://github.com/nordlow/justd/blob/master/range_ex.d#L243 which, I believe, incorrectly prints Tuple!(int[], int[])([1, 2], [3]) Tuple!(int[], int[])([1, 2], [3]) Tuple!(int[], int[])([1], [2, 3]) Tuple!(int[], int[])([1, 2, 3], []) Tuple!(int[], int[])([], [1, 2, 3]) I cannot understand why the line Tuple!(int[], int[])([1, 2], [3]) is printed twice at the beginning. Have I done something wrong in my implementation of opIndex or opSlice?
Oct 06 2014
On Monday, 6 October 2014 at 20:06:41 UTC, Nordlöw wrote:I've almost satisfied with my new range slidingSplitter at https://github.com/nordlow/justd/blob/master/range_ex.d#L19 All unittest work as expected except my radial test https://github.com/nordlow/justd/blob/master/range_ex.d#L243 which, I believe, incorrectly prints Tuple!(int[], int[])([1, 2], [3]) Tuple!(int[], int[])([1, 2], [3]) Tuple!(int[], int[])([1], [2, 3]) Tuple!(int[], int[])([1, 2, 3], []) Tuple!(int[], int[])([], [1, 2, 3]) I cannot understand why the line Tuple!(int[], int[])([1, 2], [3]) is printed twice at the beginning. Have I done something wrong in my implementation of opIndex or opSlice?I don't have time to investigate tonight, and it's probably not it, but your "save" isn't saving "_upper". I don't know how your "radial" works. Does the first "back" print "([1, 2, 3], [])" as it should?
Oct 06 2014
=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> On Monday, 6 October 2014 at 21:15:10 UTC, monarch_dodra wrote:I don't have time to investigate tonight, and it's probably not it, but your "save" isn't saving "_upper". I don't know how your "radial" works. Does the first "back" print "([1, 2, 3], [])" as it should?I've added some extra asserts in the last hour. I believe the problem remaining now lies in the definition of opSlice. I'm currently trying to figure out how it should be defined. Just uncomment line 263 and 264 and run it. Thanks anyway, for now!
Oct 06 2014
On Monday, 6 October 2014 at 21:15:10 UTC, monarch_dodra wrote:I don't have time to investigate tonight, and it's probably not it, but your "save" isn't saving "_upper".No, that wasn't the current problem. Thanks for catching it anyway.
Oct 06 2014
On Monday, 6 October 2014 at 21:15:10 UTC, monarch_dodra wrote:I don't know how your "radial" works. Does the first "back" print "([1, 2, 3], [])" as it should?I nailed it! The problem was the definition of opSlice. I had to add an extra internal state lower == upper + 1 to represent SlidingSplitter emptyness. You're welcome to review again now if you feel like :) https://github.com/nordlow/justd/blob/master/range_ex.d#L18
Oct 06 2014
On Monday, 6 October 2014 at 22:11:50 UTC, Nordlöw wrote:https://github.com/nordlow/justd/blob/master/range_ex.d#L18One more thing: I'm unsure how the indexes lower and upper should be treated for narrow strings. Should an index represent a code point or a code unit? I'm not sure. In either way I would really like this range to just work for narrow strings. What do you say monarch_dodra? What's standard D-style way of handling this?
Oct 06 2014