On 7/31/18 7:49 AM, Russel Winder wrote:
> On Tue, 2018-07-31 at 13:10 +0200, Daniel Kozak via Digitalmars-d-learn wrote:
>> On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via
>> Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>>
>>>>
>>>> Maybe IOMode.immediate or .once?
>>>> https://vibed.org/api/eventcore.driver/IOMode
>>>
>>> Oh, it looks like you specified once. Hm... that seems to me like it
>>> should work.
>>>
>>> Looks like IOMode is ignored:
>>>
>>>
>>> https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa
>>> 8246/core/vibe/core/drivers/libevent2_tcp.d#L285
>>>
>>> So, no, there isn't a correct way to do this, it's unimplemented.
>>>
>>>
>>
>> It is implemented with vibe-core driver which should be default now
>> https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9
>> f4a34/source/vibe/core/net.d#L665
> 
> Sadly as of vibe.d 0.8.4 the behaviour of read(buffer, IOMode) is to either
> fill the buffer completely or throw an exception. On the forum, Sönke has
> agreed it really does seem like a bug in the implementation.
> 
> I found a workaround to the problem for my entry to CVu Code Critique 112,
> which actually is nicer code to the one that highlighted the problem – except
> that it relies on a property that has been marked deprecated.
> 
> Deadline for entries is tomorrow, so I am not now in a position to change the
> article, it has to appear as it is now. Obviously once published, people are
> most welcome to write an article for CVu reporting how naïve/crap my code is,
> and providing better answers.
> 

Hm.. it appears that there is a timeout exception thrown if there is no data within a certain time period. Are you getting that instead?

I'm not completely familiar with the mechanisms here, but it does appear to obey the other modes properly in this iteration of the library.

-Steve

On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
> 
[…]
> Hm.. it appears that there is a timeout exception thrown if there is
> no
> data within a certain time period. Are you getting that instead?

To be honest, I am not sure. From a "I haven't looked at the library source, it's just a black box" all I can say is that if the buffer is 256 and there are >256 ubytes left the function returns but if there are <256 ubytes left an exception is thrown. I haven't checked the type of the exception or the exception message. Basically I got too annoyed that the documentation was sensible and the implementation wasn't meeting the documentation, I lost interest.

> I'm not completely familiar with the mechanisms here, but it does
> appear
> to obey the other modes properly in this iteration of the library.

I tried IOMode.all and IOMode.once but they both appeared to behave the same. I can't remember trying IOMode.immediate.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 7/31/18 11:20 AM, Russel Winder wrote:
> On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via
> Digitalmars-d-learn wrote:
>>
> […]
>> Hm.. it appears that there is a timeout exception thrown if there is
>> no
>> data within a certain time period. Are you getting that instead?
> 
> To be honest, I am not sure. From a "I haven't looked at the library
> source, it's just a black box" all I can say is that if the buffer is
> 256 and there are >256 ubytes left the function returns but if there
> are <256 ubytes left an exception is thrown. I haven't checked the type
> of the exception or the exception message. Basically I got too annoyed
> that the documentation was sensible and the implementation wasn't
> meeting the documentation, I lost interest.

Understandable. I actually don't think you ever posted the real message that comes out, just a link to the source code, from which I found it wasn't obeying the mode variable.

But now, it looks like it should be obeying the variable, yet you get an execption. Knowing what the actual message is would be helpful, at least for filing a bug or fixing it.

> 
>> I'm not completely familiar with the mechanisms here, but it does
>> appear
>> to obey the other modes properly in this iteration of the library.
> 
> I tried IOMode.all and IOMode.once but they both appeared to behave the
> same. I can't remember trying IOMode.immediate.
> 

What I mean is, I can't see why it would be throwing an exception when you supply the IOMode.once. But possibly if there is a timeout, it might be doing that.

Or maybe there is another issue.

-Steve

On Tue, 2018-07-31 at 11:54 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
> […]
> 
> Understandable. I actually don't think you ever posted the real
> message
> that comes out, just a link to the source code, from which I found
> it
> wasn't obeying the mode variable.
> 
> But now, it looks like it should be obeying the variable, yet you get
> an
> execption. Knowing what the actual message is would be helpful, at
> least
> for filing a bug or fixing it.

Separate from the CVu Code Critique 112 stuff, I'll see if I can create a suitable test case to try and provide details. It seems like the right thing to do in the circumstances. :-)

I guess I should post an issue on the vibe.d GitHub mainline repository rather than post things here.

[…]
> What I mean is, I can't see why it would be throwing an exception
> when
> you supply the IOMode.once. But possibly if there is a timeout, it
> might
> be doing that.
> 
> Or maybe there is another issue.

Hopefully the actual exception message can reveal the truth!

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

I have posted issue 2194 on the Vibe.d GitHub issues.

https://github.com/vibe-d/vibe.d/issues/2194

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 7/31/18 1:22 PM, Russel Winder wrote:
> 
> I have posted issue 2194 on the Vibe.d GitHub issues.
> 
> https://github.com/vibe-d/vibe.d/issues/2194
> 

Thanks, that should be good enough to figure out the bug in either your code or vibe.d

-Steve