[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --

[Issue 21201] let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7607 "Fix Issue 21201 - let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar" was merged into master: - ef33b5352fc1ab551def7f342906b78b769c7bd0 by Nathan Sashihara:

[Issue 21201] let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar

created dlang/phobos pull request #7607 "Fix Issue 21201 - let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar" fixing this issue: - Fix Issue 21201 - let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar All

[Issue 21201] New: let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar

https://issues.dlang.org/show_bug.cgi?id=21201 Issue ID: 21201 Summary: let std.uuid.parseUUID accept input ranges whose elements are char or wchar, not just dchar Product: D Version: D2 Hardware: All OS: All

[Issue 21131] Appender with string does not process UTF input ranges properly

https://issues.dlang.org/show_bug.cgi?id=21131 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Issue 21131] Appender with string does not process UTF input ranges properly

https://issues.dlang.org/show_bug.cgi?id=21131 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot ---

[Issue 21131] Appender with string does not process UTF input ranges properly

https://issues.dlang.org/show_bug.cgi?id=21131 Steven Schveighoffer changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X

[Issue 21131] New: Appender with string does not process UTF input ranges properly

https://issues.dlang.org/show_bug.cgi?id=21131 Issue ID: 21131 Summary: Appender with string does not process UTF input ranges properly Product: D Version: D2 Hardware: x86 OS: Mac OS X Status

[Issue 19532] chunkBy assert error involving non-forward input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 19532] chunkBy assert error involving non-forward input ranges.

input ranges https://github.com/dlang/phobos/commit/98d74d5c16923ca0460594b8e230dea885cf591d Merge pull request #6841 from jondegenhardt/fix-19532-chunkBy-input-range Fix Issue 19532 - chunkBy errors involving non-forward input ranges merged-on-behalf-of: Nicholas Wilson --

[Issue 19532] chunkBy assert error involving non-forward input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #6 from Jon Degenhardt --- PR 6841 (https://github.com/dlang/phobos/pull/6841) --

[Issue 19532] chunkBy assert error involving non-forward input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #5 from Jon Degenhardt --- It turns out that chunkBy has several issues with non-forward input ranges. I am working on a PR to address them. --

[Issue 19532] chunkBy assert error involving non-forward input ranges.

|involving reference input |involving non-forward input |ranges. |ranges. --

[Issue 19532] chunkBy assert error involving reference input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #4 from Jon Degenhardt --- A bit more explanation - I encountered problems with chunkBy when writing an merge and aggregation of sorted files. Basically, an external merge sort, except also combining equivalent key entries and

[Issue 19532] chunkBy assert error involving reference input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #3 from Jon Degenhardt --- One more: -- case4.d -- import std.stdio; import std.range; import std.algorithm : chunkBy, fold, map; import std.container.binaryheap; void main(string[] args) { auto x = [3, 1, 0, 6, 0, 2, 4, 7,

[Issue 19532] chunkBy assert error involving reference input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 --- Comment #2 from Jon Degenhardt --- Another example, this one involving multiwayMerge. case3.d - import std.stdio; import std.range; import std.algorithm : chunkBy, multiwayMerge; auto inputRangeStruct(R)(R range) { return

[Issue 19532] chunkBy assert error involving reference input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 Jon Degenhardt changed: What|Removed |Added Severity|enhancement |normal --

[Issue 19532] chunkBy assert error involving reference input ranges.

https://issues.dlang.org/show_bug.cgi?id=19532 Jon Degenhardt changed: What|Removed |Added Summary|chunkBy assert error|chunkBy assert error

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 --- Comment #4 from Eyal --- Indeed, and both are worth fixing. So I think it makes sense to keep these 2 issues: issue 14619 should fix compiler's foreach behavior (calling opSlice unnecessarily) this issue should fix RefRange in

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 Steven Schveighoffer changed: What|Removed |Added CC|

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 --- Comment #2 from Eyal --- It's related -- but that issue is about "foreach" behavior, and this issue is about RefRange behavior, which probably should not define opSlice (as mentioned in passing in issue 14619). --

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com

[Issue 18807] New: RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 Issue ID: 18807 Summary: RefRange behaves very differently for Input Ranges and Forward Ranges Product: D Version: D2 Hardware: All URL: http://dlang.org

[Issue 14373] std.range.refRange doesn't work on mere input ranges

on mere input ranges https://github.com/dlang/phobos/commit/f4894c6302286c95fc63b48bdffeb1d658f5cd7a Merge pull request #3123 from aG0aep6G/14373 --

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: Swap front for char[] input ranges

On Monday, 19 December 2016 at 20:26:26 UTC, Ali Çehreli wrote: On 12/19/2016 06:09 AM, RazvanN wrote: > [...] wrote: >> [...] InputRanges. >> [...] following > [...] char[] > [...] function, so > [...] http://dlang.org/phobos/std_algorithm_mutation.html#bringToFront [...] No need to mention

Re: Swap front for char[] input ranges

; swapping code >> > [...] >> >> Obivously, tmp1 and tmp2 are unusued there. :) >> >> > [...] >> passed. >> > [...] >> state >> > [...] >> is: >> > [...] >> input ranges >> > [...] >> >&

Re: Swap front for char[] input ranges

[...] passed. > [...] state > [...] is: > [...] input ranges > [...] Not possible... It's ok to use something similar to the following template constraint: void foo(R1, R2)(R1 r1, R2 r2) if ((hasSwappableElements!R1 && hasSwappableElements!R2) || (hasLvalueElements!R1 && ha

Re: Swap front for char[] input ranges

On Monday, 19 December 2016 at 10:41:46 UTC, RazvanN wrote: Hi, I have a function which accepts 2 input Ranges and swaps the first element in Range1 with the first element in Range2. The swapping code looks something like this : static if (is(typeof(swap(r1.front, r2.front

Swap front for char[] input ranges

Hi, I have a function which accepts 2 input Ranges and swaps the first element in Range1 with the first element in Range2. The swapping code looks something like this : static if (is(typeof(swap(r1.front, r2.front { swap(r1.front, r2.front); } else

Re: I wrote a function that accepts input ranges, and I get compile errors when passing an array

On Saturday, 28 May 2016 at 20:43:00 UTC, pineapple wrote: On Saturday, 28 May 2016 at 16:25:02 UTC, Seb wrote: If you are interested how it works under the hood - it's pretty simple & elegant: I checked up on the phobos implementation and found that arrays are mutated when iterated over as

Re: I wrote a function that accepts input ranges, and I get compile errors when passing an array

On Saturday, 28 May 2016 at 16:25:02 UTC, Seb wrote: If you are interested how it works under the hood - it's pretty simple & elegant: I checked up on the phobos implementation and found that arrays are mutated when iterated over as ranges, which didn't rest well with me. Nor did the idea of

Re: I wrote a function that accepts input ranges, and I get compile errors when passing an array

On Friday, 27 May 2016 at 14:59:25 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 14:54:30 UTC, pineapple wrote: I've encountered one remarkable difference: The phobos function accepts arrays and mine does not. add `import std.array;` i think to your module and it should make arrays

Re: I wrote a function that accepts input ranges, and I get compile errors when passing an array

On Friday, 27 May 2016 at 14:54:30 UTC, pineapple wrote: I've encountered one remarkable difference: The phobos function accepts arrays and mine does not. add `import std.array;` i think to your module and it should make arrays ranges

I wrote a function that accepts input ranges, and I get compile errors when passing an array

I'm writing my own map function modeled after the one in phobos. (because I feel like it, that's why. good learning experience.) I've encountered one remarkable difference: The phobos function accepts arrays and mine does not. I understand why - I'm calling methods that arrays don't have - but

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #10 from sigod --- (In reply to Jack Stouffer from comment #9) > (In reply to sigod from comment #8) > > I'm not betting on anything. It was a figure of speech. > > The best way to call someone's bluff is to put

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #9 from Jack Stouffer --- (In reply to sigod from comment #8) > I'm not betting on anything. It was a figure of speech. The best way to call someone's bluff is to put money on the table. If you were sure that no

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #8 from sigod --- I'm not betting on anything. It was a figure of speech. --

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #6 from ag0ae...@gmail.com --- (In reply to ag0aep6g from comment #5) > Here's a little generic function that relies on std.array.array's current > behavior: > > immutable(ElementType!R)[] toImmutableArray(R)(R range) > if

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #5 from ag0ae...@gmail.com --- (In reply to sigod from comment #4) > I bet no one uses `array()` for duplicating > arrays. I don't think betting on these things is a good course of action. The function is documented to allocate a new

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #4 from sigod --- (In reply to ag0aep6g from comment #3) > (In reply to sigod from comment #2) > > It's meaningless for dynamic arrays. > > Currently std.array.array guarantees one level of duplication. So when I >

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #3 from ag0ae...@gmail.com --- (In reply to sigod from comment #2) > It's meaningless for dynamic arrays. Currently std.array.array guarantees one level of duplication. So when I call it on an int[], I can rely on the new array being

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #2 from sigod --- It's meaningless for dynamic arrays. Currently, if you change you code from ranges to arrays you have to remove use of `array()` or it just adds hidden cost. --

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from

[Issue 15982] New: std.array.array treats dynamic arrays as input ranges and allocates new memory

https://issues.dlang.org/show_bug.cgi?id=15982 Issue ID: 15982 Summary: std.array.array treats dynamic arrays as input ranges and allocates new memory Product: D Version: D2 Hardware: All OS: All

[Issue 14373] std.range.refRange doesn't work on mere input ranges

https://issues.dlang.org/show_bug.cgi?id=14373 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --

Re: oversight with input ranges

On 4/23/15 5:52 AM, Steven Schveighoffer wrote: I'd really like to hear from Andrei on this. Such an abstraction (a range without the ability to copy its front) is a bit of a rarity so only a small subset of algorithms would work with it. So probably it deserves its name e.g.

Re: oversight with input ranges

algorithm taking input ranges to check if the range is copyable - exactly what we don't wanted! I would name it clumsy isNonCopyableInputRange, and change only those algorithms that can cope with such a thing. I've given some more thought to how this is playing out. If you look around std.algorithm, etc

Re: oversight with input ranges

that some algorithms happen to work also on this crippled input range. And option would indicate that it has some extra features over and above what a general input range provides, which is not the case. This would require to change the code of every algorithm taking input ranges to check if the range

Re: oversight with input ranges

/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) This does seem like an incorrect limitation, and I'm not sure if it was intentional. However, there is a lot of code out there that expects this to work when isInputRange is true. I don't know if we

Re: oversight with input ranges

On Wed, 22 Apr 2015 12:02:51 -0400, Steven Schveighoffer wrote: So what should be the name of this beast? isRestrictedInputRange? ;-) no, really, it's not a fully valid input range, so let's name the trait with a long word to indicate that something is very unusual with it. signature.asc

Re: oversight with input ranges

other code may depend on that requirement of copyability, but it is probably possible to alter algorithms so they can accept these not-quite input ranges. Definitely proxy or decorator type adapters that provide a proxy for front shouldn't be restricted to using only copyable range elements

Re: oversight with input ranges

On Wed, 22 Apr 2015 08:41:38 +, Dominikus Dittes Scherkl wrote: On Tuesday, 21 April 2015 at 23:33:38 UTC, ketmar wrote: On Tue, 21 Apr 2015 15:48:25 -0700, Jonathan M Davis via Digitalmars-d wrote: auto h = r.front; the thing is that chain, or filter, or other algorithms are perfectly

Re: oversight with input ranges

On Wednesday, 22 April 2015 at 05:31:03 UTC, ketmar wrote: many algorithms in std.algo doesn't copy if you'll use `(ref a)` labmdas. I understand that, but the compiler won't complain hey that isn't valid for all input ranges! when it sees that someone copied front.

Re: oversight with input ranges

On Wed, 22 Apr 2015 18:32:55 +, Jesse Phillips wrote: On Wednesday, 22 April 2015 at 05:31:03 UTC, ketmar wrote: many algorithms in std.algo doesn't copy if you'll use `(ref a)` labmdas. I understand that, but the compiler won't complain hey that isn't valid for all input ranges! when

Re: oversight with input ranges

to alter algorithms so they can accept these not-quite input ranges. Definitely proxy or decorator type adapters that provide a proxy for front shouldn't be restricted to using only copyable range elements. 1st step is we need a trait to define what we are looking for, then the next step is to simply

Re: oversight with input ranges

snip from the very beginning. This isn't new. And given that the C++ STL gets away with its containers not working with non-copyable elements, I think that that proves that you can have a major component in the standard library - containers no less - not support copyable elements and have it

Re: oversight with input ranges

On Tuesday, 21 April 2015 at 23:33:38 UTC, ketmar wrote: On Tue, 21 Apr 2015 15:48:25 -0700, Jonathan M Davis via Digitalmars-d wrote: auto h = r.front; the thing is that chain, or filter, or other algorithms are perfectly able to work with such ranges, yet it is forbidden now. it looks

oversight with input ranges

here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) signature.asc Description: PGP signature

Re: oversight with input ranges

aren't input ranges for now. ;-) If auto h = r.front; doesn't work, then I don't think that it can be a range. And if that means that elements have to be copyable to be in a range, then I think that they're going to have to be copyable. There is going to be _way_ too much code out

Re: oversight with input ranges

On Tuesday, 21 April 2015 at 19:53:47 UTC, ketmar wrote: here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) The problem with allowing the inability to copy

Re: oversight with input ranges

On Tue, 21 Apr 2015 18:30:44 -0700, Jonathan M Davis via Digitalmars-d wrote: And since isInputRange has guaranteed that elements have been copyable, I think that it's perfectly reasonable that it's been assumed that they would be, and changing that at this point just isn't worth it. yet

Re: oversight with input ranges

On Wednesday, April 22, 2015 02:05:38 ketmar via Digitalmars-d wrote: On Tue, 21 Apr 2015 18:30:44 -0700, Jonathan M Davis via Digitalmars-d wrote: And since isInputRange has guaranteed that elements have been copyable, I think that it's perfectly reasonable that it's been assumed that they

Re: oversight with input ranges

/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) If auto h = r.front; doesn't work, then I don't think that it can be a range. And if that means that elements have to be copyable to be in a range, then I think that they're

Re: oversight with input ranges

I should also point out that std.array.array can't work with non-copyable elements, and that's a pretty major function in Phobos. So, if we _were_ going to support non-copyable elements, we couldn't do it simply by making isInputRange accept them, but regardless, I don't think that it's worth the

Re: oversight with input ranges

On Wed, 22 Apr 2015 03:00:18 +, Jesse Phillips wrote: On Tuesday, 21 April 2015 at 19:53:47 UTC, ketmar wrote: here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now

Re: oversight with input ranges

On Tuesday, April 21, 2015 19:53:47 ketmar via Digitalmars-d wrote: here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) If auto h = r.front; doesn't work, then I

Re: oversight with input ranges

On 4/21/15 3:53 PM, ketmar wrote: here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) This does seem like an incorrect limitation, and I'm not sure

Re: oversight with input ranges

On Tue, 21 Apr 2015 18:57:50 -0400, Steven Schveighoffer wrote: On 4/21/15 3:53 PM, ketmar wrote: here's the interesting oversight for isInputRange: https://issues.dlang.org/show_bug.cgi?id=14478 so be careful: ranges with non-copyable elements aren't input ranges for now. ;-) This does

Re: Input ranges

On Monday, April 20, 2015 07:54:32 via Digitalmars-d wrote: Hi, I tried to learn about input ranges and got some anonymous advice http://forum.dlang.org/thread/dezlxxygufocmafvl...@forum.dlang.org , still the topic seems to warrant broader attention. The question is how pure input ranges

Re: Input ranges

On Sunday, 19 April 2015 at 23:49:08 UTC, anonymous wrote: On Sunday, 19 April 2015 at 21:42:23 UTC, Ulrich Küttler wrote: groupBy is a nice example as it laboriously adds reference semantics to forward ranges but assumes input ranges to posses reference semantics by themselves. All ranges

Input ranges

Hi, I tried to learn about input ranges and got some anonymous advice http://forum.dlang.org/thread/dezlxxygufocmafvl...@forum.dlang.org , still the topic seems to warrant broader attention. The question is how pure input ranges (as in non-forward) should be build. Algorithms like take

Re: Input ranges

On Saturday, 18 April 2015 at 22:01:56 UTC, Ulrich Küttler wrote: Input ranges from std.stdio are used for reading files. So assuming we create a file auto f = File(test.txt, w); f.writeln(iota(5).map!(a = repeat(to!string(a), 4)).joiner.joiner(\n)); f.close(); We should be able

Re: Input ranges

On Sunday, 19 April 2015 at 21:42:23 UTC, Ulrich Küttler wrote: groupBy is a nice example as it laboriously adds reference semantics to forward ranges but assumes input ranges to posses reference semantics by themselves. All ranges are input ranges, though. Input ranges are the least

Re: Input ranges

convinced most (all?) proper input ranges read input from an external source. (Reference semantic right there.) Input ranges are one-pass ranges after all. Therefore, reference semantics are required in any case (unless the use of the range is known beforehand.) groupBy is a nice example

Input ranges

It seems input ranges without any indirection in memory are not working well with algorithms. This seems to be understood by the D community. I did not know. Here is my story on the topic so far: Recently, I learned that I did not know input ranges much at all, totally misjudging

[Issue 14373] std.range.refRange doesn't work on mere input ranges

https://issues.dlang.org/show_bug.cgi?id=14373 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 14373] std.range.refRange doesn't work on mere input ranges

- std.range.refRange doesn't work on mere input ranges https://github.com/D-Programming-Language/phobos/commit/f4894c6302286c95fc63b48bdffeb1d658f5cd7a Merge pull request #3123 from aG0aep6G/14373 fix Issue 14373 - std.range.refRange doesn't work on mere input ranges --

[Issue 14373] New: std.range.refRange doesn't work on mere input ranges

https://issues.dlang.org/show_bug.cgi?id=14373 Issue ID: 14373 Summary: std.range.refRange doesn't work on mere input ranges Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity

Re: Using input ranges with std.regex?

On Wednesday, 25 April 2012 at 21:43:11 UTC, Dmitry Olshansky wrote: On 25.04.2012 23:08, H. S. Teoh wrote: Does std.regex support input ranges to match()? Or do I need to convert to string first? For now, yes you have to convert them. Any random access range of code units should do

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

What compiler options is that with? I used DMD and compiler flags -O -inline -release on x86_64 linux.

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

On Wed, May 2, 2012 at 9:38 AM, jerro a...@a.com wrote: What compiler options is that with? I used DMD and compiler flags -O -inline -release on x86_64 linux. It may be slow relative to incrementing a integer: 65 seconds without any command line options. 54 seconds with -O -inline

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

SomeDude lovelyd...@mailmetrash.com wrote in message news:ypakkndfsibcbgelj...@forum.dlang.org... On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

It may be slow relative to incrementing a integer: The opApply isn't just incrementing an integer - it's calling a function through a pointer. A loop that just increments an integer is an order of magnitude faster. This code (I used assembly because a compiler would optimize away such a simple

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Call me stupid, but I've absolutely no idea what you're doing. What

Combine Coroutines and Input Ranges for Dead-Simple D Iteration

A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

On 2012-05-01 10:27, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

On 01/05/2012 09:27, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

jerro a...@a.com wrote in message news:sxfngaqnhwxqookrv...@forum.dlang.org... On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote: A little write-up I just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration This is fun and all, but because of the horrible performance we really shouldn't be recommending people to use it. So it is bad performance

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration This is fun and all, but because of the horrible performance we really shouldn't be recommending people to use it. So it is bad

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

Compared to normal iteration schemes, yes. It may be comparable to opApply in terms of performance though. If you're curious, look at the Fiber context switching code (starting at switchIn and switchOut). It's much slower than opApply. This loop takes 70s on my machine: foreach(el;

Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration

jerro a...@a.com wrote in message news:qpipqzzdbpkoxtzvh...@forum.dlang.org... Compared to normal iteration schemes, yes. It may be comparable to opApply in terms of performance though. If you're curious, look at the Fiber context switching code (starting at switchIn and switchOut). It's

Using input ranges with std.regex?

Does std.regex support input ranges to match()? Or do I need to convert to string first? Thanks! T -- Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin

Re: Using input ranges with std.regex?

On 25.04.2012 23:08, H. S. Teoh wrote: Does std.regex support input ranges to match()? Or do I need to convert to string first? For now, yes you have to convert them. Any random access range of code units should do the trick but stringish template constraints might kill that. I plan

[Issue 5811] [patch] std.conv.parse isFloatingPoint!Target doesn't parse inf/-inf with input ranges

http://d.puremagic.com/issues/show_bug.cgi?id=5811 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

  1   2   >