On 06/19/2015 07:28 AM, Etienne Cimon wrote:
>
> The dub.json uses relative paths though while I'm developing. You're
> free to adjust the file and try it,

You may want to consider just using dub's (add|remove)-local for that instead. You can rip those "path" elements out of dub.json completely, then just do:

$ dub add-local ../botan
$ dub add-local ../libasync

And it will use those paths on your machine only, without mucking up the dub.json.

Then when you're done (or if you want to change paths):

$ dub remove-local ../botan
$ dub remove-local ../libasync

On Friday, 19 June 2015 at 15:31:19 UTC, Nick Sabalausky wrote:
> On 06/19/2015 07:28 AM, Etienne Cimon wrote:
>>
>> The dub.json uses relative paths though while I'm developing. You're
>> free to adjust the file and try it,
>
> You may want to consider just using dub's (add|remove)-local for that instead. You can rip those "path" elements out of dub.json completely, then just do:
>
> $ dub add-local ../botan
> $ dub add-local ../libasync
>
> And it will use those paths on your machine only, without mucking up the dub.json.
>
> Then when you're done (or if you want to change paths):
>
> $ dub remove-local ../botan
> $ dub remove-local ../libasync

I don't know why so many people take it personal, I love being corrected. Thanks so much for the tip :)

On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
> On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
>> On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:

>>
>> Will you explain how it is different to Vibe.d ?
>
> It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent.


Etienne

Can you explain the benefits of writing these libraries in D, as against just linking to  these libraries. Is it for faster execution, or better debugging, or some other reason ?

On Sunday, 21 June 2015 at 03:16:31 UTC, Nick B wrote:
> On Friday, 19 June 2015 at 11:28:30 UTC, Etienne Cimon wrote:
>> On Thursday, 18 June 2015 at 05:23:25 UTC, Nick B wrote:
>>> On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
>
>>>
>>> Will you explain how it is different to Vibe.d ?
>>
>> It has HTTP/2, a new encryption library, it uses a native TCP event library, lots of refactoring. In short, the entire thing is in D rather than linking with OpenSSL and libevent.
>
>
> Etienne
>
> Can you explain the benefits of writing these libraries in D, as against just linking to  these libraries. Is it for faster execution, or better debugging, or some other reason ?

When writing bindings, you need to write unit tests for your bindings and an interface. You're adding a layer of software with its own propensity for errors. You also don't have access to the underlying implementation in the IDE. You also can't add features to facilitate your own programs unless you control the repository.

Honestly, I can't stand having layers and layers of garbage to make up for language differences. I like the cleanliness of it all and it probably ended up taking me half the time because I avoided debugging new code.

On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
> On Wednesday, 17 June 2015 at 18:40:01 UTC, Laeeth Isharc wrote:
>>  Any idea how far away it might be from being something that someone could use in an enterprise environment simply, in the same kind of way that vibed is easy?  I appreciate that making it broadly usable may not be what interests you, and may be a project for someone else.
>
> I would say 3 months. So it'll probably be a year considering how off my last estimates were. Of course, I never calculated any help (and haven't gotten any really)
>

Etienne

Would you like to detail what still needs to be completed/on the to-do list  ?

What would be the best way to learn it ?

Does it need documentation as well ?

Nick

you should stay with PHP + C# or migrated to pure C# if you need to ask such a question here (without giving any infos about what the co-workers understand, the real size of the project is, etc.)

Am 16.06.2015 um 01:53 schrieb Nick B:
> Hi.
>
> There is a startup in New Zealand that I have some dealings with
> at present. They have build most of their original code in PHP,
> (as this was quick and easy) but they also use some C#.net for
> interfacing to accounting appls on clients machines. The core PHP
> application runs in the cloud at present and talks to accountings
> applications in the cloud. They use the PHP symfony framework.
>
> High speed in not important, but accuracy, error handling, and
> scalability is, as they are processing accounting transactions.
> They have a new CEO on board, and he would like to review the
> companies technical direction.
>
> Their client base is small but growing quickly.  I know that PHP
> is not a great language, and my knowledge of D is reasonable,
> while I have poor knowledge of C#.net.
>
> Looking to the future, as volumes grow, they could:
> 1.  Stay with PHP & C#.net, and bring on servers as volumes grow.
> 2.  Migrate to C#.net in time
> 3.  Migrate to D in time.
>
> Any comments or suggestions on the above?
>

On Monday, 22 June 2015 at 06:32:31 UTC, Nick B wrote:
> On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:

> Etienne
>
> Would you like to detail what still needs to be completed/on the to-do list  ?
>
> What would be the best way to learn it ?
>
> Does it need documentation as well ?
>
> Nick

The docs should be the same as the ones on vibed.org

As for the todo list, It's a little long to detail it. Depends also on where you want to go.

Urgent:
- Update libhttp2 and botan with recent changes from the original repos (nghttp2, botan). No stability issues, only new algorithms mostly.
- Write a Windows/Mac/linux daemon utility with rights elevation to have support for desktop application development (currently finishing up windows)
   - The Mac daemon requires launchd, which compiles only with DMD pull request to be merged: https://github.com/D-Programming-Language/dmd/pull/4321
   - Uses the http://diveframework.com/ to elevate
- Test the live debugging features with third party applications (similar to packet-capturing but server-side).
   - This is completed and available on my fork of vibe.d and a reverse proxy request looks like this: http://htmlpreview.github.io/?https://github.com/etcimon/vibe.d/blob/master/views/capture.html => http://pastebin.com/raw.php?i=E51RXyt2
   - Also includes json req/response or call stack in builds compiled with release
- Try running with LDC and debug the libraries until everything completely compiles with it (2.067+)
- Find a way to add a thread-local GC in druntime or at least make dub compile the projects with it.

Less urgent:
- Implement administration interface for the new redis 3.0 clustering feature
- Write a DNS server with A-record scheduling for distribution
- Adapt VibeDist to send requests to worker tasks
- Add support for runtime loading of DLL plugins that auto-register/unregister to the router.
- Test lua bindings to develop runtime themes

I also have private application development on the todo list which ends up testing the library. Lots of testing is still needed but I think the server exceeds what I could make any other server do. It compiles in a single portable executable 2mb packed after all.

On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:

> So now I can build a full web application/server executable in less than 2mb packed, and it runs faster than anything out there.

Etienne

Do you have an performance numbers, as to how fast your web application/server is, or is this based on your personal experience ?

Nick

On Tuesday, 23 June 2015 at 06:26:39 UTC, Nick B wrote:
> On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote:
>
>> So now I can build a full web application/server executable in less than 2mb packed, and it runs faster than anything out there.
>
> Etienne
>
> Do you have an performance numbers, as to how fast your web application/server is, or is this based on your personal experience ?
>
> Nick

I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version:

https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/

On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote:

>>
>> Nick
>
> I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version:
>
> https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/

Etienne

Thanks for the responses and your details replies.
I'm going to talk to the CEO of the company described, at the beginning of this long thread, and find out they are willing to consider a proof of concept web site based on your work.
This could take a couple of weeks.  What is the best way to get in touch with you if I have more questions ?

Nick