On Friday, 19 February 2016 at 01:29:15 UTC, Steven Schveighoffer
wrote:
On 2/18/16 6:52 PM, Chad Joan wrote:
...
This is why I think it will be much more important to have at
least
these two interfaces take front-and-center:
A. The presence of a .popAs!(...) operation (mentioned by
Wyatt i
On 2/19/16 6:27 AM, Dejan Lekic wrote:
Steven, this is superb!
Some 10+ years ago, I talked to Tango guys when they worked on I/O part
of the Tango library and told them that in my head ideal abstraction for
any I/O work is pipe and that I would actually build an I/O library
around this abstract
On 2/19/16 5:22 AM, Kagamin wrote:
On Thursday, 18 February 2016 at 18:27:28 UTC, Steven Schveighoffer wrote:
The philosophy that I settled on is to create an iopipe that extends
one "item" at a time, even if more are available. Then, apply the
range interface on that.
When I first started to w
Steven, this is superb!
Some 10+ years ago, I talked to Tango guys when they worked on
I/O part of the Tango library and told them that in my head ideal
abstraction for any I/O work is pipe and that I would actually
build an I/O library around this abstraction instead of the
Channel in Java o
On Thursday, 18 February 2016 at 18:27:28 UTC, Steven
Schveighoffer wrote:
The philosophy that I settled on is to create an iopipe that
extends one "item" at a time, even if more are available. Then,
apply the range interface on that.
When I first started to write byLine, I made it a range. Th
On 2/18/16 6:52 PM, Chad Joan wrote:
Steve: My apologies in advance if I a misunderstood any of the
functionality of your IO library. I haven't read any of the
documentation, just this thread, and I my time is over-committed as usual.
Understandable.
Anyhow...
I believe that when I am deal
On Wednesday, 17 February 2016 at 06:45:41 UTC, Steven
Schveighoffer wrote:
It's no secret that I've been looking to create an updated io
library for phobos. In fact, I've been working on one on and
off since 2011 (ouch).
...
Hi everyone, it's been a while.
I wanted to chime in on the strea
On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/18/16 2:53 PM, Wyatt wrote:
> >On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
>
> >>But the concept of what constitutes an "item" in a stream may not be
> >>the "element type
On 2/18/16 4:02 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/18/16 2:53 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
But the concept of what constitutes an
On 2/18/16 2:53 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
But the concept of what constitutes an "item" in a stream may not be
the "element type". That's what I'm getting at.
Hmm, I guess I'm not seeing it. Like, what even is an "item" in a
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven
Schveighoffer wrote:
On 2/18/16 12:08 PM, Wyatt wrote:
I hadn't thought of this before, but if we accept that a
stream is raw,
untyped data, it may be best _not_ to provide a range interface
directly. It's easy enough to
alias source = s
On 2/18/16 12:08 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 15:44:00 UTC, Steven Schveighoffer wrote:
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven Schveighoffer
wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://gi
On 2/18/16 12:16 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 16:36:37 UTC, Steven Schveighoffer wrote:
Note, asInputRange may not do what you want here. If multiple
zmqPollItems come in at once (I'm not sure how your socket works), the
input range's front will provide the entire window of
On Thursday, 18 February 2016 at 16:36:37 UTC, Steven
Schveighoffer wrote:
On 2/18/16 11:07 AM, Wyatt wrote:
This looks pretty all-right so far. Would something like this
work?
foreach(pollItem; zmqSocket.bufferedInput
.as!(zmqPollItem)
.asInputRange)
Yes, that is the intent. All
On Thursday, 18 February 2016 at 15:44:00 UTC, Steven
Schveighoffer wrote:
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven
Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/mast
On 2/18/16 11:07 AM, Wyatt wrote:
On Wednesday, 17 February 2016 at 06:45:41 UTC, Steven Schveighoffer wrote:
foreach(line; (new IODevice(0)).bufferedInput
.asText!(UTFType.UTF8)
.byLine
.asInputRange)
// handle line
This looks pretty all-right so far. Would something like thi
On 2/17/16 5:47 PM, deadalnix wrote:
First, I'm very happy to see that. Sounds like a good project. Some
remarks:
- You seems to be using classes. These are good to compose at runtime,
I have one class, the IODevice. As I said in the announcement, this
isn't a focus of the library, just a wa
On Wednesday, 17 February 2016 at 06:45:41 UTC, Steven
Schveighoffer wrote:
foreach(line; (new IODevice(0)).bufferedInput
.asText!(UTFType.UTF8)
.byLine
.asInputRange)
// handle line
This looks pretty all-right so far. Would something like this
work?
foreach(pollItem; zmqSock
On 2/17/16 9:52 AM, Adam D. Ruppe wrote:
On Wednesday, 17 February 2016 at 10:54:56 UTC, John Colvin wrote:
Why not just say it's a ubyte and then compose with ranges from there?
You could put a range interface on it... but I think it would be of very
limited value. For one, what about fseek?
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
why isn't that used more especially with e.g
On 2/17/16 3:54 AM, yawniek wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
What would be the benefit of having it an input range by default?
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
something t
On Wednesday, 17 February 2016 at 23:15:51 UTC, Jonathan M Davis
wrote:
On Wednesday, 17 February 2016 at 22:47:27 UTC, deadalnix wrote:
See async/await in C#
(https://msdn.microsoft.com/fr-fr/library/hh191443.aspx)
Or for those poor souls who can't read French... ;)
https://msdn.microsoft.co
On Wednesday, 17 February 2016 at 22:47:27 UTC, deadalnix wrote:
See async/await in C#
(https://msdn.microsoft.com/fr-fr/library/hh191443.aspx)
Or for those poor souls who can't read French... ;)
https://msdn.microsoft.com/en-us/library/hh191443.aspx
- Jonathan M Davis
First, I'm very happy to see that. Sounds like a good project.
Some remarks:
- You seems to be using classes. These are good to compose at
runtime, but we can do better at compile time using value types.
I suggest using value types and have a class wrapper that can be
used to make things compo
On Wednesday, 17 February 2016 at 10:54:56 UTC, John Colvin wrote:
Why not just say it's a ubyte and then compose with ranges from
there?
You could put a range interface on it... but I think it would be
of very limited value. For one, what about fseek? How does that
interact with the range in
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven
Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
why isn't that used more especially with e.g. window?
After all, window seems like a
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven
Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
What would be the benefit of having it an input range by
default?
-Steve
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
something the D community is lacking
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
why isn't that used more especially with e.g. window?
After all, window seems like a very well used word...
Not sure what you mean.
I don't like that a stream
On 17/02/16 7:45 PM, Steven Schveighoffer wrote:
It's no secret that I've been looking to create an updated io library
for phobos. In fact, I've been working on one on and off since 2011 (ouch).
After about 5 iterations of API and design, and testing out ideas, I
think I have come up with someth
It's no secret that I've been looking to create an updated io library
for phobos. In fact, I've been working on one on and off since 2011 (ouch).
After about 5 iterations of API and design, and testing out ideas, I
think I have come up with something pretty interesting. It started out
as a pla
30 matches
Mail list logo
