www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8085] New: std.algorithm.joiner makes invalid assumptions about front()

reply d-bugmail puremagic.com writes:
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



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
next sibling parent d-bugmail puremagic.com writes:
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



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8085


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8085




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8085




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8085




Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/baf5737beb196ba84f16440ab53a191a6958e5aa


Fix issue 8085

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 17 2012
prev sibling parent d-bugmail puremagic.com writes:
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