www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.Stream.InputStream convenience functions

reply "bitwise" <bitwise.pvt gmail.com> writes:
Thoughts?

private T readAndReturn(T)(InputStream stream)
{
     T ret;
     stream.read(ret);
     return ret;
}

alias readByte    = readAndReturn!byte;
alias readUByte   = readAndReturn!ubyte;
alias readShort   = readAndReturn!short;
alias readUShort  = readAndReturn!ushort;
alias readInt     = readAndReturn!int;
alias readUInt    = readAndReturn!uint;
alias readLong    = readAndReturn!long;
alias readULong   = readAndReturn!ulong;
alias readFloat   = readAndReturn!float;
alias readDouble  = readAndReturn!double;
alias readReal    = readAndReturn!real;
alias readIfloat  = readAndReturn!ifloat;
alias readIdouble = readAndReturn!idouble;
alias readIreal   = readAndReturn!ireal;
alias readCfloat  = readAndReturn!cfloat;
alias readCdouble = readAndReturn!cdouble;
alias readCreal   = readAndReturn!creal;
alias readChar    = readAndReturn!char;
alias readWchar   = readAndReturn!wchar;
alias readDchar   = readAndReturn!dchar;
Sep 03 2015
next sibling parent "bitwise" <bitwise.pvt gmail.com> writes:
On Friday, 4 September 2015 at 00:05:06 UTC, bitwise wrote:

 Thoughts?
 [...]


void main(string[] args)
{
     MemoryStream s = new MemoryStream();
     s.write(1);
     s.write(2);
     s.write(3);
     s.seek(0, SeekPos.Set);
     writeln(s.readInt());
     writeln(s.readInt());
     writeln(s.readInt());
}
Sep 03 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 4 September 2015 at 00:05:06 UTC, bitwise wrote:

 Thoughts?


std.stream is on the chopping block and has been for years, and 
it was decided at dconf that we'd actually get rid of it now 
rather than just have it say in the documentation that it's going 
away. As I understand it, the only reason that it wasn't 
deprecated in 2.068 was because of some sort of issue with the PR 
that forced it to be delayed. But there's no point in making any 
improvements to it, because that code is not going to be around 
for much longer.

- Jonathan M Davis
Sep 04 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Friday, 4 September 2015 at 14:40:43 UTC, Jonathan M Davis 
wrote:

 On Friday, 4 September 2015 at 00:05:06 UTC, bitwise wrote:

 Thoughts?


 std.stream is on the chopping block and has been for years, and 
 it was decided at dconf that we'd actually get rid of it now 
 rather than just have it say in the documentation that it's 
 going away. As I understand it, the only reason that it wasn't 
 deprecated in 2.068 was because of some sort of issue with the 
 PR that forced it to be delayed. But there's no point in making 
 any improvements to it, because that code is not going to be 
 around for much longer.

 - Jonathan M Davis


Wow...this is surprising. At first glance, the streams seemed to 
be fairly well done. What's the reason for them being removed? 
and what is meant to be the replacement?

    Bit
Sep 04 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 4 September 2015 at 22:36:01 UTC, bitwise wrote:

 On Friday, 4 September 2015 at 14:40:43 UTC, Jonathan M Davis 
 wrote:

 On Friday, 4 September 2015 at 00:05:06 UTC, bitwise wrote:

 Thoughts?


 std.stream is on the chopping block and has been for years, 
 and it was decided at dconf that we'd actually get rid of it 
 now rather than just have it say in the documentation that 
 it's going away. As I understand it, the only reason that it 
 wasn't deprecated in 2.068 was because of some sort of issue 
 with the PR that forced it to be delayed. But there's no point 
 in making any improvements to it, because that code is not 
 going to be around for much longer.

 - Jonathan M Davis


 Wow...this is surprising. At first glance, the streams seemed 
 to be fairly well done. What's the reason for them being 
 removed? and what is meant to be the replacement?


It's old (from D1) and does not follow the current best practices 
or idioms. If we're going to have a stream solution, it needs to 
be range-based. That being said, ranges in and of themselves get 
pretty close to streams, and there simply hasn't been a push to 
come up with a range-based stream solution where the pieces that 
aren't already part of ranges are taken care of. std.stream has 
been marked as scheduled for deprecation for years, and no one 
has bothered to replace it. It comes up periodically, but no one 
seems to care enough to do anything about it. So, rather than 
leave it in that state, we decided that it would be better off to 
just deprecate it and then get rid of it rather than leave it in 
limbo with the documentation saying that it's not up to our 
standards and that we're going to get rid of it at some point. At 
some point, someone may come up with a range-based stream 
solution and get it into Phobos, but until then, we'll just use 
straight up ranges, which come close enough for most cases. 
std.stdio and std.mmfile make it quite possible to operate on 
files with ranges in a manner similar to streams, and std.stdio 
allows you to operate on stdin and stdout in a similar manner 
(since they're std.stdio.Files).

That being said, std.stream is boost-licensed, and anyone is free 
to copy it or fork it so long as the copyright notice is left on 
it. So, anyone who wants to use std.stream in their own code even 
after it's no longer in Phobos is free to do so. It's just that 
the std.stream code is then going to have to be part of their 
project rather than Phobos.

- Jonathan M Davis
Sep 04 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Saturday, 5 September 2015 at 06:15:17 UTC, Jonathan M Davis 
wrote:

 On Friday, 4 September 2015 at 22:36:01 UTC, bitwise wrote:

 On Friday, 4 September 2015 at 14:40:43 UTC, Jonathan M Davis 
 wrote:

 [...]


 Wow...this is surprising. At first glance, the streams seemed 
 to be fairly well done. What's the reason for them being 
 removed? and what is meant to be the replacement?


 It's old (from D1) and does not follow the current best 
 practices or idioms. If we're going to have a stream solution, 
 it needs to be range-based. That being said, ranges in and of 
 themselves get pretty close to streams, and there simply hasn't 
 been a push to come up with a range-based stream solution where 
 the pieces that aren't already part of ranges are taken care 
 of. std.stream has been marked as scheduled for deprecation for 
 years, and no one has bothered to replace it. It comes up 
 periodically, but no one seems to care enough to do anything 
 about it. So, rather than leave it in that state, we decided 
 that it would be better off to just deprecate it and then get 
 rid of it rather than leave it in limbo with the documentation 
 saying that it's not up to our standards and that we're going 
 to get rid of it at some point. At some point, someone may come 
 up with a range-based stream solution and get it into Phobos, 
 but until then, we'll just use straight up ranges, which come 
 close enough for most cases. std.stdio and std.mmfile make it 
 quite possible to operate on files with ranges in a manner 
 similar to streams, and std.stdio allows you to operate on 
 stdin and stdout in a similar manner (since they're 
 std.stdio.Files).

 That being said, std.stream is boost-licensed, and anyone is 
 free to copy it or fork it so long as the copyright notice is 
 left on it. So, anyone who wants to use std.stream in their own 
 code even after it's no longer in Phobos is free to do so. It's 
 just that the std.stream code is then going to have to be part 
 of their project rather than Phobos.

 - Jonathan M Davis


Thanks for the explanation, but could you give an example of how 
Stream would be rangified?

In the containers I'm writing, I'm returning a range from the 
findAll() function instead of an array:
https://github.com/bitwise-github/d-containers/blob/master/collections/list.d#L901

I suppose any method returning an array/string could work like 
this...Is this what you mean?

It doesn't seem like the entire Stream class should have to be 
removed to make this change though.
Sep 05 2015
next sibling parent reply "BBasile" <bb.temp gmx.com> writes:
On Saturday, 5 September 2015 at 19:59:03 UTC, bitwise wrote:

 On Saturday, 5 September 2015 at 06:15:17 UTC, Jonathan M Davis 
 wrote:

 On Friday, 4 September 2015 at 22:36:01 UTC, bitwise wrote:

 On Friday, 4 September 2015 at 14:40:43 UTC, Jonathan M Davis 
 wrote:

 [...]


 Wow...this is surprising. At first glance, the streams seemed 
 to be fairly well done. What's the reason for them being 
 removed? and what is meant to be the replacement?


 It's old (from D1) and does not follow the current best 
 practices or idioms. If we're going to have a stream solution, 
 it needs to be range-based. That being said, ranges in and of 
 themselves get pretty close to streams, and there simply 
 hasn't been a push to come up with a range-based stream 
 solution where the pieces that aren't already part of ranges 
 are taken care of. std.stream has been marked as scheduled for 
 deprecation for years, and no one has bothered to replace it. 
 It comes up periodically, but no one seems to care enough to 
 do anything about it. So, rather than leave it in that state, 
 we decided that it would be better off to just deprecate it 
 and then get rid of it rather than leave it in limbo with the 
 documentation saying that it's not up to our standards and 
 that we're going to get rid of it at some point. At some 
 point, someone may come up with a range-based stream solution 
 and get it into Phobos, but until then, we'll just use 
 straight up ranges, which come close enough for most cases. 
 std.stdio and std.mmfile make it quite possible to operate on 
 files with ranges in a manner similar to streams, and 
 std.stdio allows you to operate on stdin and stdout in a 
 similar manner (since they're std.stdio.Files).

 That being said, std.stream is boost-licensed, and anyone is 
 free to copy it or fork it so long as the copyright notice is 
 left on it. So, anyone who wants to use std.stream in their 
 own code even after it's no longer in Phobos is free to do so. 
 It's just that the std.stream code is then going to have to be 
 part of their project rather than Phobos.

 - Jonathan M Davis


 Thanks for the explanation, but could you give an example of 
 how Stream would be rangified?


this was not addressed to me but here is how it should be done:

---
module runnable;

import std.stdio;
import std.stream;
import std.algorithm;

class RangifiedStream: MemoryStream
{
     auto range()
     {
         return Range(this);
     }

     private struct Range
     {
         MemoryStream _str;
         ulong _curr;

         this(MemoryStream str)
         {
             _str = str;
         }

         void popFront()
         {
             _curr += 1;
         }

          property ubyte front()
         {
             ubyte result;
             _str.position = _curr;
             _str.read(result);
             _str.position = _str.position - 1;
             return result;
         }

          property bool empty()
         {
             return _curr == _str.size;
         }
     }
}

void main(string[] args)
{

     import std.range;
     assert( isInputRange!(RangifiedStream.Range));

     RangifiedStream str = new RangifiedStream;
     ubyte[] src = [0,1,2,3,4,5,6,7,8,9];
     str.write(src);

     str.range.each!(a => a.writeln);
}
---

The range has a reference to a stream. The range uses its own 
position and this is important since several ranges may co-exist 
at the same time. Here you just have a byte InputRange but it 
works...

For FileStream the performances will be terrible (bad), because 
the position is hold by a a structure specific to the OS...

I think I'll add this to my iz streams classes.
Sep 05 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Saturday, 5 September 2015 at 23:00:43 UTC, BBasile wrote:

 On Saturday, 5 September 2015 at 19:59:03 UTC, bitwise wrote:

 On Saturday, 5 September 2015 at 06:15:17 UTC, Jonathan M 
 Davis wrote:

 [...]


 Thanks for the explanation, but could you give an example of 
 how Stream would be rangified?


 this was not addressed to me but here is how it should be done:

 ---
 module runnable;

 import std.stdio;
 import std.stream;
 import std.algorithm;

 class RangifiedStream: MemoryStream
 {
     auto range()
     {
         return Range(this);
     }

     private struct Range
     {
         MemoryStream _str;
         ulong _curr;

         this(MemoryStream str)
         {
             _str = str;
         }

         void popFront()
         {
             _curr += 1;
         }

          property ubyte front()
         {
             ubyte result;
             _str.position = _curr;
             _str.read(result);
             _str.position = _str.position - 1;
             return result;
         }

          property bool empty()
         {
             return _curr == _str.size;
         }
     }
 }

 void main(string[] args)
 {

     import std.range;
     assert( isInputRange!(RangifiedStream.Range));

     RangifiedStream str = new RangifiedStream;
     ubyte[] src = [0,1,2,3,4,5,6,7,8,9];
     str.write(src);

     str.range.each!(a => a.writeln);
 }
 ---

 The range has a reference to a stream. The range uses its own 
 position and this is important since several ranges may 
 co-exist at the same time. Here you just have a byte InputRange 
 but it works...

 For FileStream the performances will be terrible (bad), because 
 the position is hold by a a structure specific to the OS...

 I think I'll add this to my iz streams classes.


If all we had was a flat array of bytes(or any uniform type), 
then we wouldn't need a stream at all.

My typical usage is something like this:

int a = 1;
float b = 2;
string s = "3";

MemoryStream ms = new MemoryStream();
ms.write(a);
ms.write(b);
ms.write(s);

// stash ms in a file, or send/receive over socket..

int a = ms.readInt();
float b = ms.readFloat();
string s = ms.readString();

doSomething(a, b, s);

I'm not sure how you would go about rangifying something like 
this.
Sep 05 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Sunday, 6 September 2015 at 02:19:41 UTC, bitwise wrote:

 On Saturday, 5 September 2015 at 23:00:43 UTC, BBasile wrote:

 On Saturday, 5 September 2015 at 19:59:03 UTC, bitwise wrote:

 On Saturday, 5 September 2015 at 06:15:17 UTC, Jonathan M 
 Davis wrote:

 [...]


 Thanks for the explanation, but could you give an example of 
 how Stream would be rangified?


 this was not addressed to me but here is how it should be done:

 ---
 module runnable;

 import std.stdio;
 import std.stream;
 import std.algorithm;

 class RangifiedStream: MemoryStream
 {
     auto range()
     {
         return Range(this);
     }

     private struct Range
     {
         MemoryStream _str;
         ulong _curr;

         this(MemoryStream str)
         {
             _str = str;
         }

         void popFront()
         {
             _curr += 1;
         }

          property ubyte front()
         {
             ubyte result;
             _str.position = _curr;
             _str.read(result);
             _str.position = _str.position - 1;
             return result;
         }

          property bool empty()
         {
             return _curr == _str.size;
         }
     }
 }

 void main(string[] args)
 {

     import std.range;
     assert( isInputRange!(RangifiedStream.Range));

     RangifiedStream str = new RangifiedStream;
     ubyte[] src = [0,1,2,3,4,5,6,7,8,9];
     str.write(src);

     str.range.each!(a => a.writeln);
 }
 ---

 The range has a reference to a stream. The range uses its own 
 position and this is important since several ranges may 
 co-exist at the same time. Here you just have a byte 
 InputRange but it works...

 For FileStream the performances will be terrible (bad), 
 because the position is hold by a a structure specific to the 
 OS...

 I think I'll add this to my iz streams classes.


 If all we had was a flat array of bytes(or any uniform type), 
 then we wouldn't need a stream at all.

 My typical usage is something like this:

 int a = 1;
 float b = 2;
 string s = "3";

 MemoryStream ms = new MemoryStream();
 ms.write(a);
 ms.write(b);
 ms.write(s);

 // stash ms in a file, or send/receive over socket..

 int a = ms.readInt();
 float b = ms.readFloat();
 string s = ms.readString();

 doSomething(a, b, s);

 I'm not sure how you would go about rangifying something like 
 this.


Sorry but I just wanted to reply to your Q 'how Stream would be 
rangified?'. Put the primitives...period.

Obviously my previous example is not good because it's only for 
MemoryStream,
and OutputRange primitives miss.
Think more that the the Range will be defined for the Stream 
class:

---
struct StreamRange(ST, T)
if (is(ST : Stream))
{
     private:

         ulong _fpos, _bpos;
         ST _str;

     public:

         this(ST str)
         {
             _str = str;
             _bpos = str.size - T.sizeof;
         }

          property T front()
         {
             T result;
             _str.position = _fpos;
             _str.read(&result, T.sizeof);
             _str.position = _fpos;
             return result;
         }

          property T back()
         {
             T result;
             _str.position = _bpos;
             _str.read(&result, T.sizeof);
             _str.position = _bpos;
             return result;
         }

          safe void popFront()
         {
             _fpos += T.sizeof;
         }

          safe void popBack()
         {
             _bpos -= T.sizeof;
         }

          property bool empty()
         {
             return (_fpos == _str.size) || (_fpos + T.sizeof > 
_str.size)
                     || (_bpos == 0) || (_bpos - T.sizeof < 0);
         }

         typeof(this) save()
         {
             typeof(this) result = typeof(this)(_str);
             result._fpos = _fpos;
             return result;
         }
}

// ....

auto rng = StreamRange!(MemoryStream,long)(instance);
auto rng = StreamRange!(FileStream,float)(instance);
---

Actually I have nothing against your helper functions (except 
that they don't make Streams compatible with std.algorithm 
functions).
Sep 05 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Sunday, 6 September 2015 at 03:42:20 UTC, BBasile wrote:

 [...]
 auto rng = StreamRange!(MemoryStream,long)(instance);
 auto rng = StreamRange!(FileStream,float)(instance);
 ---

 Actually I have nothing against your helper functions (except 
 that they don't make Streams compatible with std.algorithm 
 functions).


Same problem... StreamRange(...) assumes that all data in the 
stream is of the same type.

   -Bit
Sep 05 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Sunday, 6 September 2015 at 04:48:56 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 03:42:20 UTC, BBasile wrote:

 [...]
 auto rng = StreamRange!(MemoryStream,long)(instance);
 auto rng = StreamRange!(FileStream,float)(instance);
 ---

 Actually I have nothing against your helper functions (except 
 that they don't make Streams compatible with std.algorithm 
 functions).


 Same problem... StreamRange(...) assumes that all data in the 
 stream is of the same type.

   -Bit


So Ranges are...
Sep 06 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Sunday, 6 September 2015 at 10:12:39 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 04:48:56 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 03:42:20 UTC, BBasile wrote:

 [...]
 auto rng = StreamRange!(MemoryStream,long)(instance);
 auto rng = StreamRange!(FileStream,float)(instance);
 ---

 Actually I have nothing against your helper functions (except 
 that they don't make Streams compatible with std.algorithm 
 functions).


 Same problem... StreamRange(...) assumes that all data in the 
 stream is of the same type.

   -Bit


 So Ranges are...


So tell me how you expect to read a stream containing mixed data 
types...
Sep 06 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Sunday, 6 September 2015 at 18:52:34 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 10:12:39 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 04:48:56 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 03:42:20 UTC, BBasile wrote:

 [...]
 auto rng = StreamRange!(MemoryStream,long)(instance);
 auto rng = StreamRange!(FileStream,float)(instance);
 ---

 Actually I have nothing against your helper functions 
 (except that they don't make Streams compatible with 
 std.algorithm functions).


 Same problem... StreamRange(...) assumes that all data in the 
 stream is of the same type.

   -Bit


 So Ranges are...


 So tell me how you expect to read a stream containing mixed 
 data types...


You should have got that's even not what i was talking about.
Basic summary of the conversation:

- you: hello what do you thing about my helpers functions?
- others: nothing, we won't add this because streams are 
deprecated. Maybe they'll come back one day if someone comes with 
a kind of "rangified" stream solution.
- you: how can I "rangify" a stream ?
- me: hello, you can add the ranges primitives.
- you: yes but it doesn't work for my particular case.
- me: (sigh) I know, I was talking about how streams can be 
rangified in a general way.

I think that the misunderstanding happens after 'others' 
intervention: 'other' did not suggested that your helper 
functions can be made in the "Range" fashion.
Sep 06 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Sunday, 6 September 2015 at 20:05:20 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 18:52:34 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 10:12:39 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 04:48:56 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 03:42:20 UTC, BBasile wrote:

 [...]


 Same problem... StreamRange(...) assumes that all data in 
 the stream is of the same type.

   -Bit


 So Ranges are...


 So tell me how you expect to read a stream containing mixed 
 data types...


 You should have got that's even not what i was talking about.
 Basic summary of the conversation:

 - you: hello what do you thing about my helpers functions?
 - others: nothing, we won't add this because streams are 
 deprecated. Maybe they'll come back one day if someone comes 
 with a kind of "rangified" stream solution.
 - you: how can I "rangify" a stream ?
 - me: hello, you can add the ranges primitives.
 - you: yes but it doesn't work for my particular case.
 - me: (sigh) I know, I was talking about how streams can be 
 rangified in a general way.

 I think that the misunderstanding happens after 'others' 
 intervention: 'other' did not suggested that your helper 
 functions can be made in the "Range" fashion.


The problem is, that you are concerned with who said what instead 
of addressing the problem.

The point is, streams can contain mixed data types. Any adopted 
solution should address this, and you haven't presented one.

I believe something like this could work:

http://dpaste.dzfl.pl/5f0ee693631a
Sep 06 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Sunday, 6 September 2015 at 20:17:32 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 20:05:20 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 18:52:34 UTC, bitwise wrote:

 [...]


 You should have got that's even not what i was talking about.
 Basic summary of the conversation:

 - you: hello what do you thing about my helpers functions?
 - others: nothing, we won't add this because streams are 
 deprecated. Maybe they'll come back one day if someone comes 
 with a kind of "rangified" stream solution.
 - you: how can I "rangify" a stream ?
 - me: hello, you can add the ranges primitives.
 - you: yes but it doesn't work for my particular case.
 - me: (sigh) I know, I was talking about how streams can be 
 rangified in a general way.

 I think that the misunderstanding happens after 'others' 
 intervention: 'other' did not suggested that your helper 
 functions can be made in the "Range" fashion.


 The problem is, that you are concerned with who said what 
 instead of addressing the problem.

 The point is, streams can contain mixed data types. Any adopted 
 solution should address this, and you haven't presented one.

 I believe something like this could work:

 http://dpaste.dzfl.pl/5f0ee693631a


I don't care about your problem, adding some type-specific 
readers & writers is quite straight forward and the solution you 
proposed initially is Ok.

But...at a particular point you asked how Streams can be 
rangified. That was the only reason why i posted here. Roger this 
?
Sep 06 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Sunday, 6 September 2015 at 21:33:36 UTC, BBasile wrote:

 I don't care about your problem


Then I suggest another thread.
Sep 06 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Sunday, 6 September 2015 at 21:40:08 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 21:33:36 UTC, BBasile wrote:

 I don't care about your problem


 Then I suggest another thread.


Another thread is useless.
It was a dead end since the beginning. std.streams are dead:

https://github.com/D-Programming-Language/phobos/commit/7a6e685ec924d198dd3b3a6856a635d1452b2c93
Sep 08 2015
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Tuesday, 8 September 2015 at 18:59:12 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 21:40:08 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 21:33:36 UTC, BBasile wrote:

 I don't care about your problem


 Then I suggest another thread.


 Another thread is useless.
 It was a dead end since the beginning. std.streams are dead:

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


Well, you're half right.
Streams do indeed appear to be dead ;)
Sep 08 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
On Tuesday, 8 September 2015 at 21:54:09 UTC, bitwise wrote:

 On Tuesday, 8 September 2015 at 18:59:12 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 21:40:08 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 21:33:36 UTC, BBasile wrote:

 I don't care about your problem


 Then I suggest another thread.


 Another thread is useless.
 It was a dead end since the beginning. std.streams are dead:

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


 Well, you're half right.
 Streams do indeed appear to be dead ;)


I guess that you deserve the remaining half of the truth...
If it was up to me i would rather take three quavers on the beat 
but it's fine like that.
Sep 08 2015
parent "bitwise" <bitwise.pvt gmail.com> writes:
On Tuesday, 8 September 2015 at 22:19:13 UTC, BBasile wrote:

 On Tuesday, 8 September 2015 at 21:54:09 UTC, bitwise wrote:

 On Tuesday, 8 September 2015 at 18:59:12 UTC, BBasile wrote:

 On Sunday, 6 September 2015 at 21:40:08 UTC, bitwise wrote:

 On Sunday, 6 September 2015 at 21:33:36 UTC, BBasile wrote:

 I don't care about your problem


 Then I suggest another thread.


 Another thread is useless.
 It was a dead end since the beginning. std.streams are dead:

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


 Well, you're half right.
 Streams do indeed appear to be dead ;)


 I guess that you deserve the remaining half of the truth...
 If it was up to me i would rather take three quavers on the 
 beat but it's fine like that.


Weelll.... says here that a Quaver is an eighth note..
https://www.google.ca/search?safe=off&espv=2&q=define%3A+quaver

So I suppose if you only wanna be 3/8 right instead of 1/2, I 
guess that's fine by me :)
Sep 08 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 5 September 2015 at 19:59:03 UTC, bitwise wrote:

 Thanks for the explanation, but could you give an example of 
 how Stream would be rangified?

 In the containers I'm writing, I'm returning a range from the 
 findAll() function instead of an array:
 https://github.com/bitwise-github/d-containers/blob/master/collections/list.d#L901

 I suppose any method returning an array/string could work like 
 this...Is this what you mean?

 It doesn't seem like the entire Stream class should have to be 
 removed to make this change though.


I would have to study the problem to give a good answer. It's 
been too long since I looked at the issue for me to remember the 
finer details at this point. IIRC, a big part of the problem had 
something to do with the fact that you essentially want a range 
of bytes, but the underlying C APIs really give something more 
like a range of a range of bytes, because you read the data into 
a buffer rather than reading it a byte at a time (which gets even 
further complicated by the fact that you generally want to reuse 
that buffer and not allocate extra memory if you can avoid it). 
On some level at least, that's the problem that byLine and 
byChunk in std.stdio run into. I really don't remember the 
details of what needed to be done differently for solid stream 
support though.

But all of the stuff relating to getting objects out of a byte 
stream can almost certainly be done by building it on top of a 
range of bytes rather than having any of that talk to the disk or 
generally care where the data comes from, and I very much doubt 
that std.stream does anything like that. So, at minimum, what 
std.stream does would have to be shifted so that all of the 
transformations are done on top of ranges of ubyte rather than 
talking to the disk or network stack or whatever. But I'd have to 
go digging through the code to even know what std.stream does 
right now, and I don't have the time right now to figure out how 
it should work. It's been discussed before, and it was decided 
that what's there was not what we wanted, though how far off it 
is, I really don't know other than the fact that it's not 
range-based. Any stream solution should be consuming and 
producing ranges and should be agnostic to wherever the data 
comes from unless it has a _really_ good reason not to be.

Steven Schveighoffer has been working off and on on a replacement 
for std.stdio which supports streams and cleans up some of the 
uglier things with std.stdio.File, so we may get something out of 
that at some point, but he has yet to get far enough with it to 
actually present it for review and possible inclusion in Phobos. 
However, I haven't heard of any other work being done on streams, 
and it seems like everyone's simply making do without, for better 
or worse.

- Jonathan M Davis
Sep 08 2015
parent "bitwise" <bitwise.pvt gmail.com> writes:
On Tuesday, 8 September 2015 at 17:16:45 UTC, Jonathan M Davis 
wrote:

 On Saturday, 5 September 2015 at 19:59:03 UTC, bitwise wrote:

 [...]


 I would have to study the problem to give a good answer. It's 
 been too long since I looked at the issue for me to remember 
 the finer details at this point. IIRC, a big part of the 
 problem had something to do with the fact that you essentially 
 want a range of bytes, but the underlying C APIs really give 
 something more like a range of a range of bytes, because you 
 read the data into a buffer rather than reading it a byte at a 
 time (which gets even further complicated by the fact that you 
 generally want to reuse that buffer and not allocate extra 
 memory if you can avoid it). On some level at least, that's the 
 problem that byLine and byChunk in std.stdio run into. I really 
 don't remember the details of what needed to be done 
 differently for solid stream support though.

 But all of the stuff relating to getting objects out of a byte 
 stream can almost certainly be done by building it on top of a 
 range of bytes rather than having any of that talk to the disk 
 or generally care where the data comes from, and I very much 
 doubt that std.stream does anything like that. So, at minimum, 
 what std.stream does would have to be shifted so that all of 
 the transformations are done on top of ranges of ubyte rather 
 than talking to the disk or network stack or whatever. But I'd 
 have to go digging through the code to even know what 
 std.stream does right now, and I don't have the time right now 
 to figure out how it should work. It's been discussed before, 
 and it was decided that what's there was not what we wanted, 
 though how far off it is, I really don't know other than the 
 fact that it's not range-based. Any stream solution should be 
 consuming and producing ranges and should be agnostic to 
 wherever the data comes from unless it has a _really_ good 
 reason not to be.

 Steven Schveighoffer has been working off and on on a 
 replacement for std.stdio which supports streams and cleans up 
 some of the uglier things with std.stdio.File, so we may get 
 something out of that at some point, but he has yet to get far 
 enough with it to actually present it for review and possible 
 inclusion in Phobos. However, I haven't heard of any other work 
 being done on streams, and it seems like everyone's simply 
 making do without, for better or worse.

 - Jonathan M Davis


Ok, I guess I'll try rummaging through the archives and see if I 
can find the rest of the story... Or maybe just ask Steven where 
he's at if this becomes important.

2.070 seems quite a ways away though. I'm not sure if DMD is on a 
steady release schedule, but I imagine there is quite a lot of 
work to do in terms of optimization and refactoring before even 
2.069 comes out.

Anyways, Thanks for the info,

     Bit
Sep 08 2015