Major changes:

 - Compiles on DMD 2.063.2 and DMD HEAD

 - Deprecates/removes a lot of non-conforming parts of the API (resp.
   naming convention)

 - New TaskLocal!T for more efficient and type safe task local storage

 - New TaskPipe class for stream based inter-fiber communication (can
   be used to connect classic blocking I/O with asynchronous I/O using a
   separate thread)

 - New SyslogLogger class by Jens Mueller

 - A bunch of smaller fixes/additions


Full change log:

  http://vibed.org/blog/posts/vibe-release-0.7.17

Download:

  http://vibed.org/download

GitHub:

  https://github.com/rejectedsoftware/vibe.d

On Monday, 9 September 2013 at 08:03:46 UTC, Sönke Ludwig wrote:
> Major changes:
>
>  - Compiles on DMD 2.063.2 and DMD HEAD
>
>  - Deprecates/removes a lot of non-conforming parts of the API (resp.
>    naming convention)
>
>  - New TaskLocal!T for more efficient and type safe task local storage
>
>  - New TaskPipe class for stream based inter-fiber communication (can
>    be used to connect classic blocking I/O with asynchronous I/O using a
>    separate thread)
>
>  - New SyslogLogger class by Jens Mueller
>
>  - A bunch of smaller fixes/additions
>
>
> Full change log:
>
>   http://vibed.org/blog/posts/vibe-release-0.7.17
>
> Download:
>
>   http://vibed.org/download
>
> GitHub:
>
>   https://github.com/rejectedsoftware/vibe.d

Cool! Great work!
Any progress on allowing other templating engines?

Am 09.09.2013 12:35, schrieb Volcz:
>
> Cool! Great work!
> Any progress on allowing other templating engines?

I know of these three template engines in addition to included Diet system:

 - https://github.com/repeatedly/mustache-d
 - https://github.com/carlor/embd
 - https://github.com/dymk/templ-d

All three can be used with vibe.d without issues. AFAICS embd and mutache-d (using OutputStream's output range interface) can be used without preallocating the output buffer. templ-d seems to always build a string in memory and as such is also trivially usable.

Disclaimer: Although I wanted to do that since a long time, I still didn't practically test any of these engines.

On Monday, 9 September 2013 at 08:03:46 UTC, Sönke Ludwig wrote:
> Major changes:
>
>  - Compiles on DMD 2.063.2 and DMD HEAD
>
>  - Deprecates/removes a lot of non-conforming parts of the API (resp.
>    naming convention)
>
>  - New TaskLocal!T for more efficient and type safe task local storage
>
>  - New TaskPipe class for stream based inter-fiber communication (can
>    be used to connect classic blocking I/O with asynchronous I/O using a
>    separate thread)
>
>  - New SyslogLogger class by Jens Mueller
>
>  - A bunch of smaller fixes/additions
>
>
> Full change log:
>
>   http://vibed.org/blog/posts/vibe-release-0.7.17
>
> Download:
>
>   http://vibed.org/download
>
> GitHub:
>
>   https://github.com/rejectedsoftware/vibe.d

Thanks for all your work on this.  A great product.

On Monday, 9 September 2013 at 08:03:46 UTC, Sönke Ludwig wrote:
> Major changes:
>
>  - Compiles on DMD 2.063.2 and DMD HEAD
>
>  - Deprecates/removes a lot of non-conforming parts of the API (resp.
>    naming convention)
>
>  - New TaskLocal!T for more efficient and type safe task local storage
>
>  - New TaskPipe class for stream based inter-fiber communication (can
>    be used to connect classic blocking I/O with asynchronous I/O using a
>    separate thread)
>
>  - New SyslogLogger class by Jens Mueller
>
>  - A bunch of smaller fixes/additions
>
>
> Full change log:
>
>   http://vibed.org/blog/posts/vibe-release-0.7.17
>
> Download:
>
>   http://vibed.org/download
>
> GitHub:
>
>   https://github.com/rejectedsoftware/vibe.d

Thanks for the great work!

Do you think you are closer to feeling comfortable including in some benchmark sites (e.g. maybe add to http://www.techempower.com/benchmarks/#section=data-r5)?

Thanks
Dan

On Tuesday, 10 September 2013 at 17:13:09 UTC, Daniel Davidson wrote:
> Thanks for the great work!
>
> Do you think you are closer to feeling comfortable including in some benchmark sites (e.g. maybe add to http://www.techempower.com/benchmarks/#section=data-r5)?
>
> Thanks
> Dan

I think I can safely answer this question in absence of Sonke as someone subscribed to vibe.d commit log :)

It was asked and answered: forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670 - not much has changed since then. Basically, almost all popular benchmarks tends to focus on speed of utility modules, not speed of HTTP server / application router itself. That is something that has never been tested or put serious efforts into.

Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain.

Now, if someone takes the time to run those tests manually and tell how bad situation really is - that stuff would have been really interesting to learn :)

On Tuesday, 10 September 2013 at 17:37:21 UTC, Dicebot wrote:

> I think I can safely answer this question in absence of Sonke as someone subscribed to vibe.d commit log :)
>

Thanks

> It was asked and answered: forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670 - not much has changed since then. Basically, almost all popular benchmarks tends to focus on speed of utility modules, not speed of HTTP server / application router itself. That is something that has never been tested or put serious efforts into.
>

In that thread Sonke said:

   "Agreed, I'd say we should start to prepare the benchmark cases and see how they actually compare against the others".

I can understand reservations about not wanting to publish benchmarks too early before some chance at optimization. OTOH, if it is "utility modules" that distort the numbers then maybe they need attention and data is the best way to draw it. And, just maybe, you and Sonke are too pessimistic? For example, shouldn't Json serialization be a win for D with its compile time approach?

> Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain.
>

I bet you are correct. But then, how can you know if there is no public benchmark game in that domain  :-)

Maybe the best approach is to find a way to work more sophisticated tests into the benchmark that show where vibe/D shines. Without benchmarks it is all guesswork... but I'll bet the compile time diet templates shine. Other guesses?

> Now, if someone takes the time to run those tests manually and tell how bad situation really is - that stuff would have been really interesting to learn :)

Agreed!

On 9/9/13 1:03 AM, Sönke Ludwig wrote:
[snip]

http://www.reddit.com/r/programming/comments/1m4eon/vibed_web_application_toolkit_in_d_0717_has_been/

VOTE UP!!!


Andrei

On Tuesday, 10 September 2013 at 18:10:40 UTC, Daniel Davidson wrote:
> I can understand reservations about not wanting to publish benchmarks too early before some chance at optimization. OTOH, if it is "utility modules" that distort the numbers then maybe they need attention and data is the best way to draw it. And, just maybe, you and Sonke are too pessimistic? For example, shouldn't Json serialization be a win for D with its compile time approach?

Well, we don't know. Now one has been ever benchmarking this. Ever. Someone needs to step up and provide the data. I will do it eventually, but that will happen later rather than sooner.

>> Area where vibe.d truly shines performance-wise is core request handling framework and I am not aware of any public benchmark game in that domain.
>>
>
> I bet you are correct. But then, how can you know if there is no public benchmark game in that domain  :-)

I've done some testing on my own ;) https://github.com/Dicebot/web-performance-tests - unfortunately, I was not able to get meaningful results for high concurrency cases because of h/w limits generic crappy laptop network cards have (should probably delete existing ones as they are mostly useless), but it provides all the tools for one to try and see :P

> Maybe the best approach is to find a way to work more sophisticated tests into the benchmark that show where vibe/D shines. Without benchmarks it is all guesswork... but I'll bet the compile time diet templates shine. Other guesses?

There is always an option to create your own benchmarking game :P All you need is production-grade networking hardware and pair of PC's (with client being considerably more powerful than server).