Hi,

CVu is the member magazine for ACCU members ­– you have to be a member to read it. It is published every other month. In each issue there is a Code Critique. The submissions for the previous Code Critique are presented, analysed by the setter and a book prize given to the winner. The next Code Critique is announced. In the distant past, Code Critiques were all C++ codes, and often dealing with nasty dark corners. I often take it upon myself to totally ignore the C++ (usually because the code is horrible and used in an area where C++ should never be used, e.g. string manipulation) and submit Python and D solutions. In more recent past there have been C++ ones, but also some Python and Java ones. Also fairly recently, the Code Critiques have been published as the publication goes to press on the ACCU General, i.e. a public mailing list, not the member mailing list.

I believe we have a first, Code Critique 112 is a D code. And indeed a vibe.d one. I believe a number of people from this email list should volunteer themselves to do a constructive critique to help educate ACCU members. With the obvious subtext of D being a far, far better language than C++ ;-)

Below is the email from accu-general

-------------------------------------------------------------------


Code Critique 112

Hello all,
Below is the code for Code Critique number 112

As usual, please don't reply to the list with your entry but email scc@accu.org for collation.


------------------------------------------------------------------------
(Submissions to scc@accu.org by August 1st)

Further to articles introducing D, I am attempting to use the event-driven Vibe.d server library, which I understand to be like a native version of Python's Tornado and potentially a “killer app” of D as I haven't seen any other mature event-driven server library in a compiled language.

I would like to build a back-end server that performs some processing on the body of the HTTP request it receives.  To begin with, I would like it to simply echo the request body back to the client.

My code works but there are three problems: (1) when I issue a POST request with lynx, 3 spaces are added to the start of the response text, (2) I cannot test with nc because it just says 404 and doesn't log anything, and (3) I'm worried that reading and writing just one byte at a time is inefficient, but I can't see how else to do it: I raised a "more documentation needed" bug at https://github.com/vibe-d/vibe.d/issues/2139 but at the time of writing nobody has replied (should I have used a different forum?)

--- code ---
import vibe.d;
void main() {
    auto settings = new HTTPServerSettings;
    settings.port = 8080;
    listenHTTP(settings, (req, res) {
        ubyte[1] s;
        while(!req.bodyReader.empty()) {
          req.bodyReader.read(s);
          res.bodyWriter.write(s);
        }
      });
    runApplication();
}


-- 
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 Tuesday, 19 June 2018 at 08:56:05 UTC, Russel Winder wrote:
> I believe we have a first, Code Critique 112 is a D code. And indeed a vibe.d one. I believe a number of people from this email list should volunteer themselves to do a constructive critique to help educate ACCU members. With the obvious subtext of D being a far, far better language than C++ ;-)

I'm not quite sure constructive critique is possible in this case. It's just a bad piece of code poorly implementing something that is a part of the vibe-core.

>
> Below is the email from accu-general
>
> -------------------------------------------------------------------
>
>
> Code Critique 112
>
> Hello all,
> Below is the code for Code Critique number 112
>
> As usual, please don't reply to the list with your entry but email scc@accu.org for collation.
>
>
> ------------------------------------------------------------------------
> (Submissions to scc@accu.org by August 1st)
>
> Further to articles introducing D, I am attempting to use the event-driven Vibe.d server library, which I understand to be like a native version of Python's Tornado and potentially a “killer app” of D as I haven't seen any other mature event-driven server library in a compiled language.
>
> I would like to build a back-end server that performs some processing on the body of the HTTP request it receives.  To begin with, I would like it to simply echo the request body back to the client.

There is vibe.web.rest which covers 90% of everything one might need for their back-end application. There's practically no reason to bother with bodyReaders/Writers.

> My code works but there are three problems: (1) when I issue a POST request with lynx, 3 spaces are added to the start of the response text, (2) I cannot test with nc because it just says 404 and doesn't log anything, and (3) I'm worried that reading and writing just one byte at a time is inefficient, but I can't see how else to do it: I raised a "more documentation needed" bug at https://github.com/vibe-d/vibe.d/issues/2139 but at the time of writing nobody has replied (should I have used a different forum?)
>
> --- code ---
> import vibe.d;
> void main() {
>     auto settings = new HTTPServerSettings;
>     settings.port = 8080;
>     listenHTTP(settings, (req, res) {
>         ubyte[1] s;
>         while(!req.bodyReader.empty()) {
>           req.bodyReader.read(s);
>           res.bodyWriter.write(s);
>         }
>       });
>     runApplication();
> }


1. It has something to do with lynx, curl works flawlessly
2. Writing HTTP manually is somewhat painful. Request should look something like this:

$ echo -ne "POST / HTTP/1.1\r\nHost: localhost:8080\r\nContent-Length: 3\r\n\r\nHey" | nc localhost 8080

3. There's `pipe` function in `vibe.core.stream` which does exactly that. I haven't looked at its code but I'm pretty sure it's far more efficient than byte-by-byte approach:

```
import vibe.d;

void main() {
	auto settings = new HTTPServerSettings;
	settings.port = 8080;
	listenHTTP(settings, (req, res) {
		req.bodyReader.pipe(res.bodyWriter);
	});
	runApplication();
}
```

On 6/19/18 9:43 AM, Anton Fediushin wrote:
> On Tuesday, 19 June 2018 at 08:56:05 UTC, Russel Winder wrote:
>> I would like to build a back-end server that performs some processing on the body of the HTTP request it receives.  To begin with, I would like it to simply echo the request body back to the client.
> 
> There is vibe.web.rest which covers 90% of everything one might need for their back-end application. There's practically no reason to bother with bodyReaders/Writers.

The one reason I found is that the REST interface must serialize everything before returning.

For example, if you are looking for ALL the data from your database, instead of streaming it while parsing the database, you have to serialize the entire database to an in-memory array, and return that, which the REST interface will then serialize to JSON.

In my case, I had to output the data manually to avoid insane memory consumption.

-Steve

On Tue, 2018-06-19 at 13:43 +0000, Anton Fediushin via Digitalmars-d wrote:
> 
[…]
> I'm not quite sure constructive critique is possible in this case. It's just a bad piece of code poorly implementing something that is a part of the vibe-core.

Constructive criticism is always possible. The second sentence followed by a paragraph or two providing evidence as to why and what is better,would be ideal.

A hidden agenda here is to get C++ people to ignore all the C++ offerings and use D/vibe.d instead. That a crap example has been posted should be ideal material to get stuck in to the technical marketing.

[…]
> 
> There is vibe.web.rest which covers 90% of everything one might need for their back-end application. There's practically no reason to bother with bodyReaders/Writers.

So the person did not properly RTFM. Not surprising, the person did say they were a beginner.

> > 
[…]
> 
> 1. It has something to do with lynx, curl works flawlessly
> 2. Writing HTTP manually is somewhat painful. Request should look
> something like this:
> 
> $ echo -ne "POST / HTTP/1.1\r\nHost: localhost:8080\r\nContent-Length: 3\r\n\r\nHey" | nc localhost 8080
> 
> 3. There's `pipe` function in `vibe.core.stream` which does exactly that. I haven't looked at its code but I'm pretty sure it's far more efficient than byte-by-byte approach:
> 
> ```
> import vibe.d;
> 
> void main() {
> 	auto settings = new HTTPServerSettings;
> 	settings.port = 8080;
> 	listenHTTP(settings, (req, res) {
> 		req.bodyReader.pipe(res.bodyWriter);
> 	});
> 	runApplication();
> }
> ```
> 

This is clearly getting well stuck in to the task. Can I suggest finishing this off and sending it to scc@accu.org

-- 
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 Tue, 2018-06-19 at 09:55 -0400, Steven Schveighoffer via Digitalmars-d wrote:

There is no rule against a two person review.

> On 6/19/18 9:43 AM, Anton Fediushin wrote:
> > On Tuesday, 19 June 2018 at 08:56:05 UTC, Russel Winder wrote:
> > > I would like to build a back-end server that performs some processing on the body of the HTTP request it receives.  To begin with, I would like it to simply echo the request body back to the client.
> > 
> > There is vibe.web.rest which covers 90% of everything one might need for their back-end application. There's practically no reason to bother with bodyReaders/Writers.
> 
> The one reason I found is that the REST interface must serialize everything before returning.
> 
> For example, if you are looking for ALL the data from your database, instead of streaming it while parsing the database, you have to serialize the entire database to an in-memory array, and return that, which the REST interface will then serialize to JSON.
> 
> In my case, I had to output the data manually to avoid insane memory consumption.
> 
> -Steve
-- 
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 06/19/2018 01:56 AM, Russel Winder wrote:

> CVu is the member magazine for ACCU members ­– you have to be a member to read
> it.

Yeah, I still receive CVu and Overload. :) (Although, it feels as if it's been a while since I've seen one. I may have lapsed my membership. (?)) I remember hearing somewhere that CVu and Overload might the only remaining print software magazines.

> In each issue there is a Code Critique.

It gets repetitive after a while but I always enjoyed that section. Are you managing Code Critique now? If not, I wonder why a piece of D code was chosen.

Ali

On 06/19/2018 01:56 AM, Russel Winder wrote:

> Further to articles introducing D,

Please tell more about those articles. Were they in print?

Ali

On Tue, 2018-06-19 at 10:26 -0700, Ali Çehreli via Digitalmars-d wrote:
> On 06/19/2018 01:56 AM, Russel Winder wrote:
> 
>  > CVu is the member magazine for ACCU members ­– you have to be a
> member to read
>  > it.
> 
> Yeah, I still receive CVu and Overload. :) (Although, it feels as if it's been a while since I've seen one. I may have lapsed my membership. (?)) I remember hearing somewhere that CVu and Overload might the only remaining print software magazines.

ACCU provides them as in e-pub formats as well as print. Members still want print, I guess to read during journeys to and from work.

>  > In each issue there is a Code Critique.
> 
> It gets repetitive after a while but I always enjoyed that section. Are you managing Code Critique now? If not, I wonder why a piece of D code was chosen.

I am not the person doing this, but I am the person noticing the ones that are not C++ :-)

I have no idea why this one is in D, perhaps the "drip, drip" of "there is D and Rust, also Python, Kotlin, Java, Clojure, JRuby, etc. as well as C++" is hitting home. Though it is the case that ACCU is still a C++ oriented group. But ACCU members have asked for breadth not just depth.

-- 
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 Tue, 2018-06-19 at 10:29 -0700, Ali Çehreli via Digitalmars-d wrote:
> On 06/19/2018 01:56 AM, Russel Winder wrote:
> 
>  > Further to articles introducing D,
> 
> Please tell more about those articles. Were they in print?
> 

I am fairly sure some people got article on D topics published in the past as well as me doing D solutions to Code Critiques, but I do not have links immediately to hand. Or maybe the articles were in Overload?

-- 
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 Tuesday, 19 June 2018 at 13:55:34 UTC, Steven Schveighoffer wrote:
> On 6/19/18 9:43 AM, Anton Fediushin wrote:
>> On Tuesday, 19 June 2018 at 08:56:05 UTC, Russel Winder wrote:
>>> I would like to build a back-end server that performs some processing on the body of the HTTP request it receives.  To begin with, I would like it to simply echo the request body back to the client.
>> 
>> There is vibe.web.rest which covers 90% of everything one might need for their back-end application. There's practically no reason to bother with bodyReaders/Writers.
>
> The one reason I found is that the REST interface must serialize everything before returning.
>
> For example, if you are looking for ALL the data from your database, instead of streaming it while parsing the database, you have to serialize the entire database to an in-memory array, and return that, which the REST interface will then serialize to JSON.
>
> In my case, I had to output the data manually to avoid insane memory consumption.
>
> -Steve

Indeed, that's one of the cases where vibe.web.rest isn't as helpful. Interesting thing is, vibe.web.web provides such functionality (methods can return InputStream) even though:

> Module vibe.web.web
> Implements a declarative framework for building web interfaces.

> This module contains the sister funtionality to the vibe.web.rest module. While > the REST interface generator is meant for stateless machine-to-machine  communication, this module aims at implementing user facing web services. Apart from that, both systems use the same declarative approach.

I have no idea why machine-to-machine communication can't have InputStream and machine-to-user can.