On Wednesday, 18 February 2015 at 12:28:11 UTC, Etienne Cimon wrote:
> On 2015-02-18 07:17, Jacob Carlborg wrote:
>> On 2015-02-18 02:14, Etienne Cimon wrote:
>>
>>> My favorite part is: vibe.d projects now compiles the entire software
>>> stack into a
>>> fully-featured standalone executable without any license issues.
>>
>> Isn't libevent required?
>>
>
> Not anymore. I also wrote libasync and a vibe.d driver for it
>
> https://github.com/etcimon/libasync

And libasync is another amazing piece of work, we are using it in a product we are developing.
I must also add that, IMHO, it's a strategic error not having something like that in the standard library, but well, I know...

---
Paolo

On 02/18/2015 02:14 AM, Etienne Cimon wrote:
> I'll be working on HTTP/2 with websocket-style full duplex communications

Glad to hear that.

On 2/18/15 3:43 AM, Craig Dillabaugh wrote:
> Having said that I am really busy this week and have been having trouble
> finding the time simply to fill out the Melange form and submit the
> proposal, I will get it done, so no need to worry.

Thanks Craig for taking this and running with it! -- Andrei

On 2/18/15 5:46 AM, Paolo Invernizzi wrote:
> On Wednesday, 18 February 2015 at 12:28:11 UTC, Etienne Cimon wrote:
>> On 2015-02-18 07:17, Jacob Carlborg wrote:
>>> On 2015-02-18 02:14, Etienne Cimon wrote:
>>>
>>>> My favorite part is: vibe.d projects now compiles the entire software
>>>> stack into a
>>>> fully-featured standalone executable without any license issues.
>>>
>>> Isn't libevent required?
>>>
>>
>> Not anymore. I also wrote libasync and a vibe.d driver for it
>>
>> https://github.com/etcimon/libasync
>
> And libasync is another amazing piece of work, we are using it in a
> product we are developing.
> I must also add that, IMHO, it's a strategic error not having something
> like that in the standard library, but well, I know...

I'd love to add libasync to Phobos! -- Andrei

On 2/18/15 6:18 AM, Martin Nowak wrote:
> On 02/18/2015 02:14 AM, Etienne Cimon wrote:
>> I'll be working on HTTP/2 with websocket-style full duplex communications
>
> Glad to hear that.

Please consider proposing stdlib additions. We need more of that stuff! -- Andrei

On 2015-02-18 11:41, Andrei Alexandrescu wrote:
> I'd love to add libasync to Phobos! -- Andrei
>

Even as I add this as a dependency? : https://github.com/etcimon/memutils

Instead of a single ScopedFiberPool, I intend to have ScopedPools with one stack in fiber, another in thread, and using the GC as a fallback.

You can find a code example of the idea here:

https://github.com/rejectedsoftware/vibe.d/issues/978#issuecomment-73819358

On 2/18/15 9:32 AM, Etienne Cimon wrote:
> On 2015-02-18 11:41, Andrei Alexandrescu wrote:
>> I'd love to add libasync to Phobos! -- Andrei
>>
>
> Even as I add this as a dependency? : https://github.com/etcimon/memutils
>
> Instead of a single ScopedFiberPool, I intend to have ScopedPools with
> one stack in fiber, another in thread, and using the GC as a fallback.
>
> You can find a code example of the idea here:
>
> https://github.com/rejectedsoftware/vibe.d/issues/978#issuecomment-73819358

This is integration tactics that will need to be resolved. I don't see them as showstoppers. -- Andrei

On Windows, both x64 and x86 builds return a corrupt symbol table when building with debug symbols, and x64 doesn't work in release. For now I can build release/x86 only (although I get some unrelated bugs).

I'm not sure but it seems like a problem with DMD for which I could use some help :-p

On 2015-02-18 14:50, Andrei Alexandrescu wrote:
> This is integration tactics that will need to be resolved. I don't see
> them as showstoppers. -- Andrei

You're right it did sound like that. It was partly preference and partly a need for the circular buffer to solve futures and promises following this issue:

https://github.com/etcimon/libasync/pull/11#issue-57401462

I'm going to remove the custom memory stuff and start moving the library into Phobos after I'm done debugging the linking issues for Botan on Windows.

> You're right it did sound like that. It was partly preference and partly a need for the circular buffer to solve futures and promises following this issue:

Some weeks ago I made a PR [1] which adds popFrontN to std.array.Appender transforming it in a circular buffer. Please provide your feedback, if you find it useful. At the moment the PR is somehow stalled.


[1] - https://github.com/D-Programming-Language/phobos/pull/2928