Thread overview | ||||||
---|---|---|---|---|---|---|
|
January 01, 2013 [Issue 9253] New: Review Phobos algorithms and make them transient-safe where possible | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=9253 Summary: Review Phobos algorithms and make them transient-safe where possible Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody@puremagic.com ReportedBy: hsteoh@quickfur.ath.cx --- Comment #0 from hsteoh@quickfur.ath.cx 2013-01-01 12:09:55 PST --- This bug is to have a central place to keep the list of Phobos algorithms found to be transient-incompatible but could potentially be made transient-compatible, so that the list doesn't get lost in the dust of forum history. - std.algorithm.reduce (when no seed is given) - std.algorithm.joiner (both variants have been fixed in git HEAD) - std.algorithm.group - std.algorithm.minCount - std.algorithm.minPos (takes forward range; should use .save) - std.algorithm.Levenshtein (takes forward range; should use .save) - std.algorithm.makeIndex (takes forward range; should use .save) - std.algorithm.splitter (takes slices without checking for isSlicable) - std.algorithm.topNCopy - std.algorithm.NWayUnion - std.array.array (probably not fixable) - std.array.insertInPlace (probably not fixable) - std.array.join (copies input range; may not be fixable) - std.stdio.writeln & friends (need more testing, there are some deep bits that fail with transient ranges) While the whole transience issue hasn't been decided yet, Andrei has agreed that those algorithms that *can* be made transience-compatible, should be. The fate of the rest will be determined when this issue has been decided on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 01, 2013 [Issue 9253] Review Phobos algorithms and make them transient-safe where possible | ||||
---|---|---|---|---|
| ||||
Posted in reply to hsteoh@quickfur.ath.cx | http://d.puremagic.com/issues/show_bug.cgi?id=9253 monarchdodra@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra@gmail.com --- Comment #1 from monarchdodra@gmail.com 2013-01-01 13:05:23 PST --- (In reply to comment #0) > - std.algorithm.splitter (takes slices without checking for isSlicable) For the record, I'm on splitter. I had a pull ready, but closed it for further improvements. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 14, 2013 [Issue 9253] Review Phobos algorithms and make them transient-safe where possible | ||||
---|---|---|---|---|
| ||||
Posted in reply to hsteoh@quickfur.ath.cx | http://d.puremagic.com/issues/show_bug.cgi?id=9253 --- Comment #2 from monarchdodra@gmail.com 2013-01-14 13:30:18 PST --- (In reply to comment #0) > This bug is to have a central place to keep the list of Phobos algorithms found to be transient-incompatible but could potentially be made transient-compatible, so that the list doesn't get lost in the dust of forum history. > > - std.algorithm.reduce (when no seed is given) > - std.algorithm.joiner (both variants have been fixed in git HEAD) > - std.algorithm.group > - std.algorithm.minCount > - std.algorithm.minPos (takes forward range; should use .save) > - std.algorithm.Levenshtein (takes forward range; should use .save) > - std.algorithm.makeIndex (takes forward range; should use .save) > - std.algorithm.splitter (takes slices without checking for isSlicable) > - std.algorithm.topNCopy > - std.algorithm.NWayUnion > - std.array.array (probably not fixable) > - std.array.insertInPlace (probably not fixable) > - std.array.join (copies input range; may not be fixable) > - std.stdio.writeln & friends (need more testing, there are some deep bits that > fail with transient ranges) > > While the whole transience issue hasn't been decided yet, Andrei has agreed that those algorithms that *can* be made transience-compatible, should be. The fate of the rest will be determined when this issue has been decided on. I just fixed minPos to use safe, and it should now be transient safe. No unittest though (yet) to prevent future breakage. I'm fixing minCount: It will be transient safe for forward ranges. Input ranges will the thoroughly unsafe though, with no possibility of workaround. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 15, 2013 [Issue 9253] Review Phobos algorithms and make them transient-safe where possible | ||||
---|---|---|---|---|
| ||||
Posted in reply to hsteoh@quickfur.ath.cx | http://d.puremagic.com/issues/show_bug.cgi?id=9253 --- Comment #3 from hsteoh@quickfur.ath.cx 2013-01-14 21:44:56 PST --- Yeah, some algorithms will have to be transient-unsafe, because it will either introduce unacceptable overhead, or it's plain impossible due to the nature of the algorithm. These cases will just have to be left as-is. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation