Re: A vibe.d thing
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
Re: A vibe.d thing
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 Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
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 Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
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
Re: A vibe.d thing
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 Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
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 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
Re: A vibe.d thing
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 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. > > > > -Steve > > > > 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. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via Digitalmars-d-learn 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/a9589d955f10bd076a67d47ace0c78cfd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > So, no, there isn't a correct way to do this, it's unimplemented. > > -Steve > It is implemented with vibe-core driver which should be default now https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9f4a34/source/vibe/core/net.d#L665
Re: A vibe.d thing
On 2018-07-27 21:02, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, FYI, it's possible to access the vibe.d forum through a news reader by using the following URL [1]. This is noted at the bottom of the forum [2]. [1] nntp://forum.rejectedsoftware.com/ [2] http://forum.rejectedsoftware.com -- /Jacob Carlborg
Re: A vibe.d thing
On Fri, 2018-07-27 at 15:58 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > Haha, I don't blame you. The docs should say in bold letters (NOT > IMPLEMENTED). In the end I used the deprecated leastSize property to create a right size buffer so the read function never tries to read more data than it has. This gets round the exception being thrown and makes for quite a nice solution. The problem is of course the leastSize property is being deprecated. This seems like a bad idea to me, especially given the read function is actually broken with respect reads shorter than the buffer. […] > > I'd be surprised if there isn't some better I/O options in vibe.d. I > mainly use the higher-level features. Any chance of you doing an article on D and vibe.d proper use prompted by this Code Critique so as to show CVu readers what vibe.d is really like – as opposed to the rather negative image readers will get from this Code Critique. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
On Fri, 2018-07-27 at 15:58 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > > I'm guessing they don't use it, but use peek instead (or maybe peek > to > get the size, and then read to get the data). I tried using req.bodyReader.peek, but that only works for situations where there is only a small amount of data. In particular it fails spectacularly if there is a large amount of data, but for what reason I cannot infer. Do you have an example of getting the body data size so as to do that, I can't see non-deprecated things to do that. > I'd be surprised if there isn't some better I/O options in vibe.d. I > mainly use the higher-level features. The CVu Code Critique 112 code isn't doing anything actually sensible, it is about echoing POSTed data. I suspect vibe.d is only reqlly working when used in an idiomatic way for stuff that is normal in the single threaded asynchronous server world. If you can point me at a few examples, I have today and Tuesday to try and put together a working example solving the CC112 problem that is not totally crap. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
On 7/27/18 3:44 PM, Russel Winder wrote: On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] 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/a9589d955f10bd076a67d47ace0c78c fd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. Present a function with implied UNIX style system call behaviour and then don't bother doing it properly. Just a wee bit annoying. I shall go away and be grumpy. Haha, I don't blame you. The docs should say in bold letters (NOT IMPLEMENTED). As for systems implemented using vibe.d, how the do they deal with this crap? I'm guessing they don't use it, but use peek instead (or maybe peek to get the size, and then read to get the data). I'd be surprised if there isn't some better I/O options in vibe.d. I mainly use the higher-level features. -Steve
Re: A vibe.d thing
On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] > > 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/a9589d955f10bd076a67d47ace0c78c > fd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > So, no, there isn't a correct way to do this, it's unimplemented. Present a function with implied UNIX style system call behaviour and then don't bother doing it properly. Just a wee bit annoying. I shall go away and be grumpy. As for systems implemented using vibe.d, how the do they deal with this crap? I may be better able to deal with this in the morning. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
On 7/27/18 3:18 PM, Steven Schveighoffer wrote: On 7/27/18 3:02 PM, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? 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/a9589d955f10bd076a67d47ace0c78cfd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. -Steve
Re: A vibe.d thing
On 7/27/18 3:02 PM, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? Maybe IOMode.immediate or .once? https://vibed.org/api/eventcore.driver/IOMode -Steve
A vibe.d thing
I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
