digitalmars.D.bugs - [Issue 8085] New: std.algorithm.joiner makes invalid assumptions about front()
- d-bugmail puremagic.com (58/58) May 11 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (22/22) Jul 06 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (12/12) Oct 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (7/7) Oct 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (6/6) Dec 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (9/9) Dec 17 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
- d-bugmail puremagic.com (9/9) Dec 17 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8085
http://d.puremagic.com/issues/show_bug.cgi?id=8085 Summary: std.algorithm.joiner makes invalid assumptions about front() Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: bugzilla digitalmars.com --- Comment #0 from Walter Bright <bugzilla digitalmars.com> 2012-05-11 12:05:54 PDT --- Given the program: ========================= import std.stdio; import std.ascii; import std.algorithm; import std.string; void main() { //stdin.byChunk(1024).joiner().map!(a => toUpper(a)).copy(stdout.lockingTextWriter()); stdin.byLine(KeepTerminator.yes).joiner().map!(a => toUpper(a)).copy(stdout.lockingTextWriter()); //stdin.byLine(KeepTerminator.yes).joiner().copy(stdout.lockingTextWriter()); //stdin.byLine(KeepTerminator.yes).copy(stdout.lockingTextWriter()); } ============================== Compile & run with: foo <foo.d trying one of the 4 versions. Versions 1 and 4 work, 2 and 3 fail horribly. The output is all scrambled, like this: IMPORT STD.ASCII; IMPORT STD.ALGORITIMPORT STD.STRING; M; MPORT STD.STRING; VVOID MAIN() { STDIN.BYLINE(KEEPTERMINATOR.YES).JOINER().MAP!(A => TOUPPER(A)).COPY(STDOUT.LOCKINGTEXT //STDIN.B YLINE(KEEPTERMINATOR.YES).JOINER().COPY(STDOUT.LOCKINGTEXTWRITER()); CKINGTEXTWRITER()); //STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER()); ITER()); } //STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER()); } Analysis from Andrei: Go to algorithm.d line 2370, when joiner() is defined. Then go down to method prepare(). That method calls _items.front.empty, i.e. it assumes _items.front "works" but at the same time saves _current. At the moment _items.front is called, _current gets overwritten. The code should be changed to not assume that _items.front is independent from _current. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 11 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 jens.k.mueller gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jens.k.mueller gmx.de --- Comment #1 from jens.k.mueller gmx.de 2012-07-06 13:01:33 PDT --- I'm thinking about fixing this issue but there are several approaches: 1. Fix joiner (BTW why name it joiner and not just join; same for splitter; Is this because there used to be a string.split or and std.path.join?) 2. Fix ByLine to not invalidate front when doing a popFront Is it common in Phobos for a range to invalidate front? ByLine and probably also ByChunk (haven't checked) are the only ranges that invalidate front, aren't they. There is also ByRecord which does not show up in the documentation. 3. If it is a common scheme to invalidate front then one could implement an adapter to store a copy of front even though that is less efficient. I prefer option 2 because it can be implemented with little space overhead but you seem to prefer option 1 which suggests that a range *usually* invalidates front. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 06 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 hsteoh quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hsteoh quickfur.ath.cx --- Comment #2 from hsteoh quickfur.ath.cx 2012-10-27 13:34:22 PDT --- I think that Phobos code, where possible, should not depend on .front not being invalidated, whether or not that's a common occurrence; that way it will work correctly for more range types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 --- Comment #3 from jens.k.mueller gmx.de 2012-10-28 03:50:16 PDT --- That is also Andrei's stand point. There was a discussion about it on the newsgroup recently. But I'm not sure that this is the consensus. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 28 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 --- Comment #4 from hsteoh quickfur.ath.cx 2012-12-01 18:22:56 PST --- https://github.com/D-Programming-Language/phobos/pull/987 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 --- Comment #5 from github-bugzilla puremagic.com 2012-12-17 09:08:49 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/baf5737beb196ba84f16440ab53a191a6958e5aa Merge pull request #987 from quickfur/new_joiner Fix issue 8085 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 17 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8085 hsteoh quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 17 2012