www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe.d 0.7.17 released

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
Sep 09 2013
next sibling parent reply "Volcz" <volcz kth.se> writes:
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?
Sep 09 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Sep 09 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
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.
Sep 09 2013
prev sibling next sibling parent reply "Daniel Davidson" <nospam spam.com> writes:
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
Sep 10 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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 :)
Sep 10 2013
parent reply "Daniel Davidson" <nospam spam.com> writes:
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!
Sep 10 2013
parent "Dicebot" <public dicebot.lv> writes:
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).
Sep 10 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 10 2013