> I'm kinda tempted to offer a pre-packaged compiler download with my libs and some other useful stuff. PHP has done that before, with the LAMP packages.
>
> And now that dmd is fully Boost, there's no legal barrier, but I question if it is really worth it because someone could just download the files themselves easily enough.
>
> But still, the compiler+libs+samples and docs and maybe one of the ides could be kinda useful.

I'm also in favor that some of your personal developments be converted into std libs.

For instance, being able to natively implement a small web server with a few lines of standard code, like we can easily do in Go or Node.js, would be great.

And I know that you already have implemented that :)

So I can't talk for everybody, but I can at least say that having such stuff working out of the box would indeed make a huge difference for newbies like me, who'd prefer not having to chase for open source code which does what the std libraries provide in other languages.

On Friday, 23 June 2017 at 18:26:43 UTC, Ecstatic Coder wrote:
> I'm also in favor that some of your personal developments be converted into std libs.

Eh, std libs is where you lose me. I don't mind offering a "just works" dmd download on my website, with my packaging dmd for some particular purposes, or on the official site, that includes all the stuff. But I have no interest in being part of Phobos and losing control of my projects.

Now, I think Phobos should be open to those things, where the modules are owned by third parties and just packaged as a standard library. The phobos devs might fork it or whatever, of course, but this would be more like a Linux distribution than a corporate merger - the individual packages in a Linux distro are still owned by outside parties, and the distro maintainers just bring them in and might slightly modify them to fit their thing better.

From the user side, it looks like a traditional std lib, but from the developer side, it is more of a bazaar than a cathedral.

On Saturday, 24 June 2017 at 18:10:54 UTC, Adam D. Ruppe wrote:
> On Friday, 23 June 2017 at 18:26:43 UTC, Ecstatic Coder wrote:
>> I'm also in favor that some of your personal developments be converted into std libs.
>
> Eh, std libs is where you lose me. I don't mind offering a "just works" dmd download on my website, with my packaging dmd for some particular purposes, or on the official site, that includes all the stuff. But I have no interest in being part of Phobos and losing control of my projects.
>
> Now, I think Phobos should be open to those things, where the modules are owned by third parties and just packaged as a standard library. The phobos devs might fork it or whatever, of course, but this would be more like a Linux distribution than a corporate merger - the individual packages in a Linux distro are still owned by outside parties, and the distro maintainers just bring them in and might slightly modify them to fit their thing better.
>
> From the user side, it looks like a traditional std lib, but from the developer side, it is more of a bazaar than a cathedral.

what is the barest minimum we need to enable that?

someone to organise conventions about module organisation and some kind of package grouping in dub?  so you can specify "adamandfriends" as a dependency to bring in the repackaged library under that group name?  like yum groupinstall 'blahblah' but more personal.

On Saturday, 24 June 2017 at 18:10:54 UTC, Adam D. Ruppe wrote:
> On Friday, 23 June 2017 at 18:26:43 UTC, Ecstatic Coder wrote:
>> I'm also in favor that some of your personal developments be converted into std libs.
>
> Eh, std libs is where you lose me. I don't mind offering a "just works" dmd download on my website, with my packaging dmd for some particular purposes, or on the official site, that includes all the stuff. But I have no interest in being part of Phobos and losing control of my projects.
>
> Now, I think Phobos should be open to those things, where the modules are owned by third parties and just packaged as a standard library. The phobos devs might fork it or whatever, of course, but this would be more like a Linux distribution than a corporate merger - the individual packages in a Linux distro are still owned by outside parties, and the distro maintainers just bring them in and might slightly modify them to fit their thing better.
>
> From the user side, it looks like a traditional std lib, but from the developer side, it is more of a bazaar than a cathedral.

+1 :)

Actually D doesn't need hundreds of additional types and functions in the libraries.

Look for instance this Go code :

package main

import (
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        http.ServeFile(w, r, r.URL.Path[1:]);
    });

    log.Fatal(http.ListenAndServe(":80", nil));
}

Two lines of code, that's all that's needed to serve an entire website, with all sorts of files (html, css, js, jpg, png, etc) located in plenty of directories.

NO framework required. Nada. Just a standard Go installation.

Same for Node.js. It's 100% batteries included...

So having just a few types and functions similar to those of Go and Node.js, without requiring to install a complete framework like vibe.d for such basic cases would definitely make a HUGE difference in terms of IMMEDIATE usability for D.

Go is very popular for web development because most developer can already do 99% of their work JUST with the standard libraries.

These few web server functions are generally more than enough to quickly build most functionalities with just a few lines of code.

Unfortunately, D lacks these few "standard building blocks".

We can implement the same functionalities in D with a THIRDPARTY FRAMEWORK, but not with the few "building blocks" provided by standard libraries functions.

Which is very sad, because webserver development is a domain where D can be a perfect contender to Go, Java and C#, and not everybody is willing to use a full framework just to have the same functionalities as these two simple lines of Go code.

Am 24.06.2017 um 21:22 schrieb Ecstatic Coder:
> package main
>
> import (
>     "log"
>     "net/http"
> )
>
> func main() {
>     http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
>         http.ServeFile(w, r, r.URL.Path[1:]);
>     });
>
>     log.Fatal(http.ListenAndServe(":80", nil));
> }

/++ dub.sdl
    name "webserver"
    dependency "vibe-d:http" version="~>0.7.31"
+/
module main;

import vibe.core.core;
import vibe.http.fileserver;
import vibe.http.server;

void main()
{
    listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
    runApplication();
}

$ dub main.d

Although of course vibe.d is not included with the compiler, this works out of the box for a standard DMD/LDC installation.

On Saturday, 24 June 2017 at 20:29:23 UTC, Sönke Ludwig wrote:
> Am 24.06.2017 um 21:22 schrieb Ecstatic Coder:
>> package main
>>
>> import (
>>     "log"
>>     "net/http"
>> )
>>
>> func main() {
>>     http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
>>         http.ServeFile(w, r, r.URL.Path[1:]);
>>     });
>>
>>     log.Fatal(http.ListenAndServe(":80", nil));
>> }
>
> /++ dub.sdl
>     name "webserver"
>     dependency "vibe-d:http" version="~>0.7.31"
> +/
> module main;
>
> import vibe.core.core;
> import vibe.http.fileserver;
> import vibe.http.server;
>
> void main()
> {
>     listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
>     runApplication();
> }
>
> $ dub main.d
>
> Although of course vibe.d is not included with the compiler, this works out of the box for a standard DMD/LDC installation.

Exactly what I mean.

Just rename the three imports into std.*, make this available at installation, et voilà :)

Should not require too much work...

On Saturday, 24 June 2017 at 21:04:36 UTC, Ecstatic Coder wrote:
> Just rename the three imports into std.*, make this available at installation, et voilà :)

Or just leave it how it is and let it download the package automatically!

I'm pretty sure that always works with an out-of-the box dmd installation today.

It isn't ideal to me yet, but I do think it is closer to what you want than you think...

On 6/24/17 9:29 PM, Sönke Ludwig wrote:
> Am 24.06.2017 um 21:22 schrieb Ecstatic Coder:
>> package main
>>
>> import (
>>     "log"
>>     "net/http"
>> )
>>
>> func main() {
>>     http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
>>         http.ServeFile(w, r, r.URL.Path[1:]);
>>     });
>>
>>     log.Fatal(http.ListenAndServe(":80", nil));
>> }
> 
> /++ dub.sdl
>      name "webserver"
>      dependency "vibe-d:http" version="~>0.7.31"
> +/
> module main;
> 
> import vibe.core.core;
> import vibe.http.fileserver;
> import vibe.http.server;
> 
> void main()
> {
>      listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
>      runApplication();
> }
> 
> $ dub main.d
> 
> Although of course vibe.d is not included with the compiler, this works out of the box for a standard DMD/LDC installation.

This should be a blog post. -- Andrei

On Saturday, 24 June 2017 at 20:29:23 UTC, Sönke Ludwig wrote:
> /++ dub.sdl
>     name "webserver"
>     dependency "vibe-d:http" version="~>0.7.31"
> +/
> module main;
>
> import vibe.core.core;
> import vibe.http.fileserver;
> import vibe.http.server;
>
> void main()
> {
>     listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
>     runApplication();
> }
>
> $ dub main.d
>
> Although of course vibe.d is not included with the compiler, this works out of the box for a standard DMD/LDC installation.

No it does not...

Attempt 1:
=========

Create main.d file, insert code. dub main.d

> readPackageRecipe called with filename with unknown extension: + dub.sdl
>      name "webserver"
>      dependency "vibe-d

Attempt 2:
=========

Dub init xxxxx
-> enter sdl
-> ...

Update xxxxx/src/app.d, insert code. Run dub ...

> Performing "debug" build using dmd for x86.
> webser ~master: building configuration "application"...
> source\app.d(7,8): Error: module core is in file 'vibe\core\core.d' which cannot be read
> import path[0] = source
> import path[1] = C:\D\dmd2\windows\bin\..\..\src\phobos
> import path[2] = C:\D\dmd2\windows\bin\..\..\src\druntime\import
> dmd failed with exit code 1.

Attempt 3:
=========

dub init xxxxx
-> enter sdl
-> ...

Insert dependency into xxxxx/dub.sdl.
Update file xxxxx/src/app.d, insert code. Run dub ...

Works

Attempt 4:
=========

Place dub.sdl into main project root directory.

Add the dependency information into the file.

workspaces-d ( Visual Studio Code ) crash, crash, crash, crash. Reason. Already a folder called Webserver present and this creates a conflic.

Attempt 5:
=========

Place dub.sdl into main project root directory.

Add the dependency information into the file ( now with different project file ).

Create WebTest2.d file, insert code. dub WebTest2.d

> dub .\WebTest2.d
> readPackageRecipe called with filename with unknown extension: + dub.sdl
>      name "webserver"
>     dependency "vibe-d

Conclusion:
===========

From 5 different attempt, only one works. All the rest are how people may attempt it and will run into a crash or other non-working issues.

It requires knowledge of dub.
It requires selecting the correct sdl format, when running dub init
It requires knowing that the dependency needs to be in a dub.sdl file, in a actual project.
...

Go idiomatic it is not unfortunately.

As Ecstatic Coder pointed out. The Go http is a default core package of Go. For D it means depending on a 3th party solution. Currently vibe.d 0.8 is undergoing a rewrite. This breaks some basic functionally with the more module design. A issue if a user had installed a 0.7.30 or earlier version.

There is this bad habit with assuming that people will understand how to run the samples posted or provided on there first attempt at using D. As seen above, its very easy to make mistakes. A programming language is like a drug. If people like there first experience, they may get hooked. If its a bad "trip", most will not mention a word and simply not try again.

On 24.06.2017 22:29, Sönke Ludwig wrote:
> Am 24.06.2017 um 21:22 schrieb Ecstatic Coder:
>> package main
>>
>> import (
>>     "log"
>>     "net/http"
>> )
>>
>> func main() {
>>     http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
>>         http.ServeFile(w, r, r.URL.Path[1:]);
>>     });
>>
>>     log.Fatal(http.ListenAndServe(":80", nil));
>> }
> 
> /++ dub.sdl
>      name "webserver"
>      dependency "vibe-d:http" version="~>0.7.31"
> +/
> module main;
> 
> import vibe.core.core;
> import vibe.http.fileserver;
> import vibe.http.server;
> 
> void main()
> {
>      listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
>      runApplication();
> }
> 
> $ dub main.d
> 
> Although of course vibe.d is not included with the compiler, this works out of the box for a standard DMD/LDC installation.
> 

$ cat main.d
/++ dub.sdl
    name "webserver"
    dependency "vibe-d:http" version="~>0.7.31"
+/
module main;

import vibe.core.core;
import vibe.http.fileserver;
import vibe.http.server;

void main()
{
    listenHTTP(new HTTPServerSettings, serveStaticFiles("./"));
    runApplication();
}
$ dub main.d
readPackageRecipe called with filename with unknown extension: + dub.sdl
    name "webserver"
    dependency "vibe-d

What am I doing wrong?