On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
> On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
>> On Monday, 17 August 2020 at 15:45:05 UTC, aberba wrote:
>>> [...]
>>
>> After 18 years following DLang, and some disagrees about productivity lacks at the beggining (no IDE, Debugging?, an standard library battle, not a good database connection library, missing web framework) and Walter adding more and more compiler functionalities (all of them nice ones) I decided to forget DLang for a time (C# covered my needs really well).
>>
>> Last month I decided it was time to start a new project (my own company) and I reviewed some languages/frameworks for web development (REST services, image processing, PDF generation, ...):  Java based ones (I'm experienced with scala/playframework and spring/java, and Kotlin is really nice), c# and Net core, Node/Typescript (Last 6 years I have been mainly a node backend developer) and,  finally, native ones (GO, Rust and D... I developed some windows apps in 90's using Symantec C++ but 20 years are a really long time).
>>
>> I really wanted to give D an opportunity: lets go with vibe.d
>>
>> I tested vibe.d on my ubuntu 20.04 and SURPRISE: the hello world project began to eat all my machine memory (just requesting with Firefox and CTRL+F5 pressed continuosly).  Using an HAPROXY between calls and backend memory problems disappeared.
>>
>> Process doesn't stop properly after CTRL+C... but I decided not to be so demanding.
>>
>> I discovered hunt-framework (with a fantastic ORM implementation) and my eyes shinned. I tried an example project. Like vibe.d, I began to perform requests with Firefox and CTRL+F5 pressed and application stopped immediately (yesterday I discovered it is a SIGPIPE unmanaged signal that stops the process).  I'm quite sure if I use HAPROXY to intermediate between requests and backend, the problem will disappear, but I don't want to perform this test, because I decided not to use hunt-framework neither.
>>
>> Finally I'm using Rust (with Rocket and Diesel):  it's my money folks :).
>>
>> Sorry for this not constructive post.
>>
>> DLang needs to bright in some market niche to attract developers and to solve the actual most demanded needs:  a lot of developers, like me, expect a good/robust framework for backend development (web/rest/microservices/data processing) and a de-facto standard library for Database integration.
>>
>> In my opinion, "hunt-framework" (or similar) should be one of the central projects of DLang next years (like vibe.d in the past) with a really impressive documentation (English, please!!!) demonstrating how robust, performant and expressive D lang is.
>
> Actually your feedback is very constructive, thanks a lot. The ctrl+c issue can be solved with a work around, by adding the version "VibeHighEventPriority".
>
> I have only a very small vibed backend application (websockset) and never noticed the memory issue. Also another forum user which has a quite large web application in productive use didn't mentioned this issue.
>
> Could I ask you to open a github issue for vibe-d describing your findings regarding the memory issue?
> As far as I remember the GC does not immediately runs, but only at a certain limit. Maybe your memory issue isn't really an issue but the desired behavior. (Not an expert here, just what I remember).
>
> Kind regards
> Andre
Thanks a lot Andre,

I opened immediately the issues to receive some feedback:

In vibe.d
https://github.com/vibe-d/vibe.d/issues/2459

In hunt-framework
https://github.com/huntlabs/hunt-framework/issues/161

With vibe.d case, memory is never recalled.

Problems disappear in vibe.d when I introduce an intermediate HAPROXY... this gave me an idea about the origin of the problem:  Local pipe closed by destination (that haproxy manages nicely)

Linux man page about write and EPIPE: https://linux.die.net/man/2/write
> EPIPE
>    fd is connected to a pipe or socket whose reading end is closed. When this happens
>    the writing process will also receive a SIGPIPE signal. (Thus, the write return
>    value is seen only if the program catches, blocks or ignores this signal.)

I have to recognize I learned this last days (I am not a native linux developer, but I began to recall my past knowledge about it :-)

The main reason I have dropped the 2 frameworks for my new project:

* Entry "ready for use" projects simple examples must work (I can't be confident that projects based on them will be stable on production if basic projects fail in development)

On Friday, 21 August 2020 at 08:48:34 UTC, ddcovery wrote:
> On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
>> [...]
> Thanks a lot Andre,
>
> I opened immediately the issues to receive some feedback:
>
> [...]

EDIT: 23 days ago new vibe.d (0.9.0) was released... Testing with it memory problem has disappeared!!!

+1 to vibe.d :-)

On Friday, 21 August 2020 at 09:50:38 UTC, ddcovery wrote:
> On Friday, 21 August 2020 at 08:48:34 UTC, ddcovery wrote:
>> On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
>>> [...]
>> Thanks a lot Andre,
>>
>> I opened immediately the issues to receive some feedback:
>>
>> [...]
>
> EDIT: 23 days ago new vibe.d (0.9.0) was released... Testing with it memory problem has disappeared!!!
>
> +1 to vibe.d :-)

I'm glad you came around.

On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
> Last month I decided it was time to start a new project (my own company) and I reviewed some languages/frameworks for web development (REST services, image processing, PDF generation, ...):  Java based ones (I'm experienced with scala/playframework and spring/java, and Kotlin is really nice), c# and Net core, Node/Typescript (Last 6 years I have been mainly a node backend developer) and,  finally, native ones (GO, Rust and D... I developed some windows apps in 90's using Symantec C++ but 20 years are a really long time).
> [...]
> Finally I'm using Rust (with Rocket and Diesel):  it's my money folks :).

Recently I too started to look at web frameworks for compiled languages. Currently playing with Free Pascal - fast compiler, several web frameworks to evaluate, and Object Pascal is easy to pick up. At the same time I checked out D and Vibe, and was put off by the control-c thing.

I prefer to deploy my programs as Alpine Linux Docker containers. Good that D is already available for Alpine. For the hello world Vibe example, on my Ubuntu 20.04 laptop:

% ls -l helloworld.*
-rwxr-xr-x 3 pierce pierce 8664832 Aug 23 14:04 helloworld.dmd*
-rwxr-xr-x 3 pierce pierce 2858944 Aug 23 14:04 helloworld.ldc*

The Docker images created by multistage builds:

% sudo docker images | egrep hellow
helloworld    ldc                   86be59503802        6 hours ago         114MB
helloworld    dmd                   d377c0ab97ec        6 hours ago         19.6MB

Is the huge size difference to be expected?

For both DMD and LDC, the Docker image building process took long. Does the following mean that everything was downloaded and built each time? Possible to structure the Dockerfile so that some bits get cached, as per "the Docker way"? (For Free Pascal, executables built on Ubuntu run on Alpine as is with the libc6-compat package, so building Docker images is really fast since it just involves copying a few files and reuses some cached Docker layers.)

 ---> Running in a95e6ef7a8c1
Fetching vibe-core 1.9.3 (getting selected version)...
Fetching botan-math 1.0.3 (getting selected version)...
Fetching taggedalgebraic 0.11.16 (getting selected version)...
Fetching vibe-d 0.9.0 (getting selected version)...
Fetching memutils 1.0.4 (getting selected version)...
Fetching stdx-allocator 2.77.5 (getting selected version)...
Fetching botan 1.12.18 (getting selected version)...
Fetching diet-ng 1.7.2 (getting selected version)...
Fetching openssl 1.1.6+1.0.1g (getting selected version)...
Fetching eventcore 0.9.7 (getting selected version)...
Fetching mir-linux-kernel 1.0.1 (getting selected version)...
Fetching libasync 0.8.6 (getting selected version)...
Running pre-generate commands for vibe-d:tls...
Performing "release" build using ldc2 for x86_64.
taggedalgebraic 0.11.16: building configuration "library"...
eventcore 0.9.7: building configuration "epoll"...
stdx-allocator 2.77.5: building configuration "library"...
vibe-core 1.9.3: building configuration "epoll"...
vibe-d:utils 0.9.0: building configuration "library"...
vibe-d:data 0.9.0: building configuration "library"...
mir-linux-kernel 1.0.1: building configuration "library"...
vibe-d:crypto 0.9.0: building configuration "library"...
diet-ng 1.7.2: building configuration "library"...
vibe-d:stream 0.9.0: building configuration "library"...
vibe-d:textfilter 0.9.0: building configuration "library"...
vibe-d:inet 0.9.0: building configuration "library"...
vibe-d:tls 0.9.0: building configuration "openssl"...
vibe-d:http 0.9.0: building configuration "library"...
/usr/include/d/std/conv.d(4614,38): Deprecation: constructor `vibe.stream.wrapper.ProxyStream.this` is deprecated - Use createProxyStream instead.
/usr/include/d/std/conv.d(4618,21): Deprecation: constructor `vibe.stream.wrapper.ProxyStream.this` is deprecated - Use createProxyStream instead.
/usr/include/d/std/range/primitives.d(174,38): Deprecation: `alias byKeyValue this` is deprecated - Iterate over .byKeyValue instead.
/usr/include/d/std/range/primitives.d(176,27): Deprecation: `alias byKeyValue this` is deprecated - Iterate over .byKeyValue instead.
/usr/include/d/std/range/primitives.d(174,38): Deprecation: `alias byKeyValue this` is deprecated - Iterate over .byKeyValue instead.
/usr/include/d/std/range/primitives.d(176,27): Deprecation: `alias byKeyValue this` is deprecated - Iterate over .byKeyValue instead.
vibe-d:mail 0.9.0: building configuration "library"...
vibe-d:mongodb 0.9.0: building configuration "library"...
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!string.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!(Alternate).Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!(MaxVariable).Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!string.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!(Alternate).Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
/usr/include/d/std/format.d(3645,26): Deprecation: function `std.typecons.Nullable!(MaxVariable).Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly.
vibe-d:redis 0.9.0: building configuration "library"...
vibe-d:web 0.9.0: building configuration "library"...
vibe-d 0.9.0: building configuration "vibe-core"...

On Sunday, 23 August 2020 at 06:41:03 UTC, Pierce Ng wrote:
> On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
>> [...]
>
> Recently I too started to look at web frameworks for compiled languages. Currently playing with Free Pascal - fast compiler, several web frameworks to evaluate, and Object Pascal is easy to pick up. At the same time I checked out D and Vibe, and was put off by the control-c thing.
>
> [...]

Please have a look at the end of this site: https://d-land.sepany.de/tutorials/cloud/sichere-docker-images-fuer-cloud-anwendungen-erstellen/
It describes how to build really small vibed applications on Alpine by using docker scratch image.

Also it is possible to cache the dub package builds, but i am writing from my mobile and have currently no example: you copy dub.json / dub.selections.json first into your docker image. Dub.json contains a configuration with name e.g. "prebuild" and as far as I remember targetType "None". You execute dub build with this configuration and after that you copy all source code files into your docker image and build the complete application.
This will give you a lot faster docker builds.

Kind regards
Andre

On Sunday, 23 August 2020 at 09:56:25 UTC, Andre Pany wrote:
> Please have a look at the end of this site: https://d-land.sepany.de/tutorials/cloud/sichere-docker-images-fuer-cloud-anwendungen-erstellen/
> It describes how to build really small vibed applications on Alpine by using docker scratch image.
>
> Also it is possible to cache the dub package builds, but i am writing from my mobile and have currently no example: you copy dub.json / dub.selections.json first into your docker image. Dub.json contains a configuration with name e.g. "prebuild" and as far as I remember targetType "None". You execute dub build with this configuration and after that you copy all source code files into your docker image and build the complete application.
> This will give you a lot faster docker builds.


Thank you, Andre. I'll try these.

On 8/12/20 9:46 AM, James Blachly wrote:
> On 7/18/20 8:16 AM, Andre Pany wrote:
>> On Saturday, 18 July 2020 at 09:10:04 UTC, Mr. Backup wrote:
>  >> ...
>>> I started the program with "dub" command and everything worked as I expected. Except that there were a lot "deprecation" warnings and long time to compile.But when I exit the service by ctrl + c and start again the program cannot start again with error message:
>>> ...
>>
>> I assume you are using vibe.d 0.8.4 or older. Please check whether adding this to dub.json solves your problem:
>>
>> ​"versions": [ "VibeHighEventPriority" ]
>>
>> (Restart your pc)
>>
>> Vibe.d 0.9 0 will be released soon. I hope it will work out of the box there.
> 
> Unfortunately the problem still occurs with Vibe.d 0.9.0
> 
> IMO **this is the single most important problem to fix** for vibe.d -- if the most basic of examples (indeed, supplied by dub itself) fails so spectacularly, the casual new user will not spend the time to find out why this is happening, but instead move on. The ctrl-C non-termination bug has existed since at least 2015 from what I can tell from the forums.
> 
> Tangent:
> 
> Does Sönke have a Patreon or the project an OpenCollective etc. ? I would be willing to support fixing of some of these bugs.
> 
> Alternatively, could we vote on whether a web framework is worthy of foundation support? Having an ergonomic, workable web framework is absolutely essential to surviving as a language in 2020 (notable exception being 800# gorilla incumbents C/C++).

FYI, this bug was just fixed (eventcore version 0.9.11). I tested it and it works.

Thanks Sönke for fixing this!

-Steve

https://github.com/vibe-d/vibe-core/issues/205

On 11/27/20 12:05 PM, Steven Schveighoffer wrote:
> 
> FYI, this bug was just fixed (eventcore version 0.9.11). I tested it and it works.
> 
> Thanks Sönke for fixing this!
> 
> -Steve
> 
> https://github.com/vibe-d/vibe-core/issues/205

Hooray and congrats to Soenke and team!