www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CVu, Code Critique, and D

reply Russel Winder <russel winder.org.uk> writes:
Hi,

CVu is the member magazine for ACCU members =C2=AD=E2=80=93 you have to be =
a member to read
it. It is published every other month. In each issue there is a Code Critiq=
ue.
The submissions for the previous Code Critique are presented, analysed by t=
he
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 ofte=
n
dealing with nasty dark corners. I often take it upon myself to totally ign=
ore
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 Pyth=
on
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 li=
st,
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 =E2=80=9Ckiller app=E2=
=80=9D 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 =3D new HTTPServerSettings;
    settings.port =3D 8080;
    listenHTTP(settings, (req, res) {
        ubyte[1] s;
        while(!req.bodyReader.empty()) {
          req.bodyReader.read(s);
          res.bodyWriter.write(s);
        }
      });
    runApplication();
}


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jun 19 2018
next sibling parent reply Anton Fediushin <fediushin.anton yandex.ru> writes:
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();
}
```
Jun 19 2018
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jun 19 2018
next sibling parent Russel Winder <russel winder.org.uk> writes:
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=






=20

 on the body of the HTTP request it receives.  To begin with, I would=






=20

 like it to simply echo the request body back to the client.


=20
 There is vibe.web.rest which covers 90% of everything one might need fo=




r=20

 their back-end application. There's practically no reason to bother wit=




h=20

 bodyReaders/Writers.


=20
 The one reason I found is that the REST interface must serialize=20
 everything before returning.
=20
 For example, if you are looking for ALL the data from your database,=20
 instead of streaming it while parsing the database, you have to=20
 serialize the entire database to an in-memory array, and return that,=20
 which the REST interface will then serialize to JSON.
=20
 In my case, I had to output the data manually to avoid insane memory=20
 consumption.
=20
 -Steve


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jun 19 2018
prev sibling parent Anton Fediushin <fediushin.anton yandex.ru> writes:
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.
Jun 19 2018
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-06-19 at 13:43 +0000, Anton Fediushin via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I'm not quite sure constructive critique is possible in this=20
 case. It's just a bad piece of code poorly implementing something=20
 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 a=
nd
use D/vibe.d instead. That a crap example has been posted should be ideal
material to get stuck in to the technical marketing.

[=E2=80=A6]

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


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


=20




[=E2=80=A6]

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


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

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jun 19 2018
parent reply Anton Fediushin <fediushin.anton yandex.com> writes:
On Tuesday, 19 June 2018 at 14:42:20 UTC, Russel Winder wrote:

 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.


Thanks, maybe I'll try and write something as constructive as 
possible.


 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.


Using C++ sometimes can be a bad idea. Using C++ for web is 
always a bad idea. Can't agree more, D is a great language by 
itself and there are smart people working on it. The only thing 
missing is somewhat good marketing for all of that.


 
 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


I will try and do so. I can't see a reason to not give it a try. 
I'd like more people to participate. Maybe then we'll see more D 
in the Code Critique.
Jun 19 2018
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-06-19 at 19:22 +0000, Anton Fediushin via Digitalmars-d
wrote:

 On Tuesday, 19 June 2018 at 14:42:20 UTC, Russel Winder wrote:

=20




[=E2=80=A6]

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


=20
 I will try and do so. I can't see a reason to not give it a try.=20
 I'd like more people to participate. Maybe then we'll see more D=20
 in the Code Critique.


I am just putting together a piece in answer to the original question,
it would be great if you were able to submit something as well. 2018-
08-01 submission deadline.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jul 18 2018
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jun 19 2018
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-06-19 at 10:26 -0700, Ali =C3=87ehreli via Digitalmars-d wrote=
:

 On 06/19/2018 01:56 AM, Russel Winder wrote:
=20
  > CVu is the member magazine for ACCU members =C2=AD=E2=80=93 you have t=


o be a=20

 member to read
  > it.
=20
 Yeah, I still receive CVu and Overload. :) (Although, it feels as if=20
 it's been a while since I've seen one. I may have lapsed my membership.=


=20

 (?)) I remember hearing somewhere that CVu and Overload might the only=


=20

 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.
=20
 It gets repetitive after a while but I always enjoyed that section. Are=


=20

 you managing Code Critique now? If not, I wonder why a piece of D code=


=20

 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++" i=
s
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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jun 19 2018
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jun 19 2018
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-06-19 at 10:29 -0700, Ali =C3=87ehreli via Digitalmars-d wrote=
:

 On 06/19/2018 01:56 AM, Russel Winder wrote:
=20
  > Further to articles introducing D,
=20
 Please tell more about those articles. Were they in print?
=20


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?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Jun 19 2018