www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Introducing vibe.d!

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
During the last few months, we have been working on a new
framework for general I/O and especially for building
extremely fast web apps. It combines asynchronous I/O with
core.thread's great fibers to build a convenient, blocking
API which can handle insane amounts of connections due to
the low memory and computational overhead.

Some of its key fatures are:

  - Very fast but no endless callback chains as in node.js
    and similar frameworks
  - Concise API that tries to be as efficient and intuitive
    as possible
  - Built-in HTTP server and client with support for HTTPS,
    chunked and compressed transfers, keep-alive connections,
    Apache-style logging, a reverse-proxy, url routing and
    more
  - Jade based HTML/XML template system with compile-time
    code generation for the fastest dynamic page generation
    times possible
  - Built-in support for MongoDB and Redis databases
  - WebSocket support
  - Natural Json and Bson handling
  - A package manager for seemless use of extension libraries

See http://vibed.org/ for more information and some example
applications (there are some things in the works such as an
etherpad clone and an NNTP server).

vibe.d is in a working state and enters its first beta-phase
now to stabilize the current feature set. After that, a
small list of additional features is planned before the 1.0
release.

The framework can be downloaded or GIT cloned from
http://vibed.org/ and is distributed under the terms of the
MIT license.

Note that the website including the blog is fully written
in vibe and provides the first stress test for the
implementation.

Regards,
Sönke
Apr 26 2012
next sibling parent reply ponce <spam spam.org> writes:
Wow, thanks :)
Definately going to play with it.
Apr 26 2012
parent David <d dav1d.de> writes:
Am 26.04.2012 23:18, schrieb ponce:

 Wow, thanks :)
 Definately going to play with it.


Same here, I think using vibe with nginx as reverse proxy will work great!
Apr 26 2012
prev sibling next sibling parent reply Trass3r <un known.com> writes:
Looks promising.

Though I wouldn't know how to choose between Adam's web framework,  
Cybershadow's code (seemed like he coded the newsreader in no time and it  
works very nicely) and yours.
Any advice?
Apr 26 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 26.04.2012 23:54, schrieb Trass3r:

 Looks promising.

 Though I wouldn't know how to choose between Adam's web framework,
 Cybershadow's code (seemed like he coded the newsreader in no time and
 it works very nicely) and yours.
 Any advice?


I guess it just comes down to tast and requirements. If you need high 
performance in high load situations or if you are used to the 
router-view-template system (with HAML or Jade templates) vibe should be 
a good choice.

But although I haven't looked very deep into the other two, I know that 
at least Adam's code contains a lot of features that are not yet 
available in vibe or are maybe not planned at all (e.g. the handy DOM 
manipulations). Of course, since vibe is also usable as a simple 
library, its also possible to combine parts of each framework.
Apr 27 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Sönke Ludwig:


 See http://vibed.org/ for more information and some example


I see the code:


 import vibe.d;
 ...
 static this()
 {
 	listenTcp(7, (conn){ conn.write(conn) });
 }


Isn't it better to use this?

import vibe.all;

And in the last line is a semicolon missing?

listenTcp(7, (conn){ conn.write(conn); });

Bye,
bearophile
Apr 26 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 26.04.2012 23:59, schrieb bearophile:

 Sönke Ludwig:


 See http://vibed.org/ for more information and some example


 I see the code:


 import vibe.d;
 ...
 static this()
 {
 listenTcp(7, (conn){ conn.write(conn) });
 }


 Isn't it better to use this?

 import vibe.all;

 And in the last line is a semicolon missing?

 listenTcp(7, (conn){ conn.write(conn); });

 Bye,
 bearophile


Ah yes, the semicolon got lost while transforming "conn => 
conn.write(conn)" to "(conn){ conn.write(conn); }" because the lamdba 
syntax was a bit surprising there.

The "import vibe.d;" is actually just a play on the frameworks name and 
just should be easy to remember. In addition to importing all modules, 
it also imports a module containing the main function, so this is a 
special beast. But there is actually a "import vibe.vibe;" which is the 
equivalent to the "vibe.all".

Sönke
Apr 26 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Sönke Ludwig:


 The "import vibe.d;" is actually just a play on the frameworks 
 name and just should be easy to remember. In addition to 
 importing all modules, it also imports a module containing the 
 main function, so this is a special beast. But there is 
 actually a "import vibe.vibe;" which is the equivalent to the 
 "vibe.all".


But isn't ".all" a kind of standard D convention (that is better 
to generally use)? (I am not sure).

Bye,
bearophile
Apr 27 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 27 April 2012 at 15:26:02 UTC, bearophile wrote:

 But isn't ".all" a kind of standard D convention (that is 
 better to generally use)? (I am not sure).


No, not at this point. Some people prefer somepackage._, and 
there recently has been a proposal by Andrei (DIP16) to allow a 
special »somepackage.package« module.

David
Apr 27 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 27/04/2012 17:29, David Nadlinger a écrit :

 On Friday, 27 April 2012 at 15:26:02 UTC, bearophile wrote:

 But isn't ".all" a kind of standard D convention (that is better to
 generally use)? (I am not sure).


 No, not at this point. Some people prefer somepackage._, and there
 recently has been a proposal by Andrei (DIP16) to allow a special
 »somepackage.package« module.

 David


Both are very used.
Apr 27 2012
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


This looks awesome!

Also on reddit:
http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/

and hacker news:
https://news.ycombinator.com/item?id=3896197

-- 
Robert
http://octarineparrot.com/
Apr 26 2012
parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:

 On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


 This looks awesome!

 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/

 and hacker news:
 https://news.ycombinator.com/item?id=3896197


Now look what you did, you killed it.
Apr 26 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/26/12 3:30 PM, Jesse Phillips wrote:

 On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:

 On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


 This looks awesome!

 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/


 and hacker news:
 https://news.ycombinator.com/item?id=3896197


 Now look what you did, you killed it.


Are the Vibe people on this? Though the intent is very nice, this is not 
looking great right now.

Andrei
Apr 26 2012
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 27 April 2012 at 02:19:23 UTC, Andrei Alexandrescu 
wrote:

 On 4/26/12 3:30 PM, Jesse Phillips wrote:

 On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham 
 wrote:

 On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


 This looks awesome!

 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/


 and hacker news:
 https://news.ycombinator.com/item?id=3896197


 Now look what you did, you killed it.


 Are the Vibe people on this? Though the intent is very nice, 
 this is not looking great right now.

 Andrei


It's back up. It went down while he was asleep.

Regards,
Brad Anderson
Apr 26 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 04:19, schrieb Andrei Alexandrescu:

 On 4/26/12 3:30 PM, Jesse Phillips wrote:

 On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:

 On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


 This looks awesome!

 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/



 and hacker news:
 https://news.ycombinator.com/item?id=3896197


 Now look what you did, you killed it.


 Are the Vibe people on this? Though the intent is very nice, this is not
 looking great right now.

 Andrei



It's back up now and I've made a small watchdog script to avoid this in 
the future.

The problem is that I'm currently using a vibe based reverse proxy 
instead of nginx and it rarely has an uncaught exception that 
unfortunately has never been logged with stack trace. I wish I could 
have made this part rock solid before going live but someone else 
annouced it before me so it was too late.
Apr 26 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
In _d_throw call abort().  That'll give you a core file.=20

On Apr 26, 2012, at 11:13 PM, S=C3=B6nke Ludwig <sludwig outerproduct.org> w=
rote:


 Am 27.04.2012 04:19, schrieb Andrei Alexandrescu:

 On 4/26/12 3:30 PM, Jesse Phillips wrote:

 On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:

 On 26/04/2012 21:46, S=C3=B6nke Ludwig wrote:

 vibe.d


=20
 This looks awesome!
=20
 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_i=








o_that_doesnt_get_in_your_way/

=20
=20
=20
 and hacker news:
 https://news.ycombinator.com/item?id=3D3896197


=20
 Now look what you did, you killed it.


=20
 Are the Vibe people on this? Though the intent is very nice, this is not
 looking great right now.
=20
 Andrei


=20
=20
 It's back up now and I've made a small watchdog script to avoid this in th=


e future.

=20
 The problem is that I'm currently using a vibe based reverse proxy instead=


 of nginx and it rarely has an uncaught exception that unfortunately has nev=
er been logged with stack trace. I wish I could have made this part rock sol=
id before going live but someone else annouced it before me so it was too la=
te.
Apr 27 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 27-04-2012 16:50, Sean Kelly wrote:

 In _d_throw call abort().  That'll give you a core file.

 On Apr 26, 2012, at 11:13 PM, Sönke Ludwig<sludwig outerproduct.org>  wrote:


 Am 27.04.2012 04:19, schrieb Andrei Alexandrescu:

 On 4/26/12 3:30 PM, Jesse Phillips wrote:

 On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote:

 On 26/04/2012 21:46, Sönke Ludwig wrote:

 vibe.d


 This looks awesome!

 Also on reddit:
 http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/



 and hacker news:
 https://news.ycombinator.com/item?id=3896197


 Now look what you did, you killed it.


 Are the Vibe people on this? Though the intent is very nice, this is not
 looking great right now.

 Andrei



 It's back up now and I've made a small watchdog script to avoid this in the
future.

 The problem is that I'm currently using a vibe based reverse proxy instead of
nginx and it rarely has an uncaught exception that unfortunately has never been
logged with stack trace. I wish I could have made this part rock solid before
going live but someone else annouced it before me so it was too late.




Why don't we make that some kind of function in druntime? like 
setAbortOnThrow(bool) or whatever.

-- 
- Alex
Apr 27 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.


Thanks, I've tracked it down to an assertion by logging stderr for now, 
but next time I will try the abort method (with __d_assert*), because 
just a call stack without line numbers was a bit sparse on information.
Apr 30 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 30, 2012, at 1:03 AM, S=F6nke Ludwig wrote:


 Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.
=20


=20
 Thanks, I've tracked it down to an assertion by logging stderr for =


now, but next time I will try the abort method (with __d_assert*), =
because just a call stack without line numbers was a bit sparse on =
information.

What platform are you on?  You should be getting stack traces.=
Apr 30 2012
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 30.04.2012 15:48, schrieb Sean Kelly:

 On Apr 30, 2012, at 1:03 AM, Sönke Ludwig wrote:


 Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.


 Thanks, I've tracked it down to an assertion by logging stderr for now, but
next time I will try the abort method (with __d_assert*), because just a call
stack without line numbers was a bit sparse on information.


 What platform are you on?  You should be getting stack traces.


I get a stack trace with function names but no line numbers (just byte 
offsets). It's Linux/64bit, compiled with -g.
Apr 30 2012
next sibling parent simendsjo <simendsjo gmail.com> writes:
On Mon, 30 Apr 2012 17:26:54 +0200, S=C3=B6nke Ludwig  =

<sludwig outerproduct.org> wrote:


 Am 30.04.2012 15:48, schrieb Sean Kelly:

 On Apr 30, 2012, at 1:03 AM, S=C3=B6nke Ludwig wrote:


 Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.


 Thanks, I've tracked it down to an assertion by logging stderr for  =







 now, but next time I will try the abort method (with __d_assert*),  =







 because just a call stack without line numbers was a bit sparse on  =







 information.


 What platform are you on?  You should be getting stack traces.


 I get a stack trace with function names but no line numbers (just byte=


  =


 offsets). It's Linux/64bit, compiled with -g.


Yup, pretty annoying. Use addr2line.
Apr 30 2012
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 30, 2012, at 8:26 AM, S=F6nke Ludwig wrote:


 Am 30.04.2012 15:48, schrieb Sean Kelly:

 On Apr 30, 2012, at 1:03 AM, S=F6nke Ludwig wrote:
=20

 Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.
=20


=20
 Thanks, I've tracked it down to an assertion by logging stderr for =






now, but next time I will try the abort method (with __d_assert*), =
because just a call stack without line numbers was a bit sparse on =
information.

=20
 What platform are you on?  You should be getting stack traces.


=20
 I get a stack trace with function names but no line numbers (just byte =


offsets). It's Linux/64bit, compiled with -g.

Druntime uses backtrace() on Linux, and I've seen it give offsets at =
times instead of line numbers.  Can't say exactly why.  You may already =
know this, but you can figure out the offending line by calling "objdump =
-d -S" on the executable, then doing some hex math from the address of =
the reported function.=
Apr 30 2012
parent Johannes Pfau <nospam example.com> writes:
Am Mon, 30 Apr 2012 15:52:36 -0700
schrieb Sean Kelly <sean invisibleduck.org>:


 On Apr 30, 2012, at 8:26 AM, S=C3=B6nke Ludwig wrote:
=20

 Am 30.04.2012 15:48, schrieb Sean Kelly:

 On Apr 30, 2012, at 1:03 AM, S=C3=B6nke Ludwig wrote:
=20

 Am 27.04.2012 16:50, schrieb Sean Kelly:

 In _d_throw call abort().  That'll give you a core file.
=20


=20
 Thanks, I've tracked it down to an assertion by logging stderr
 for now, but next time I will try the abort method (with
 __d_assert*), because just a call stack without line numbers was
 a bit sparse on information.


=20
 What platform are you on?  You should be getting stack traces.


=20
 I get a stack trace with function names but no line numbers (just
 byte offsets). It's Linux/64bit, compiled with -g.


=20
 Druntime uses backtrace() on Linux, and I've seen it give offsets at
 times instead of line numbers.  Can't say exactly why.  You may
 already know this, but you can figure out the offending line by
 calling "objdump -d -S" on the executable, then doing some hex math
 from the address of the reported function.


backtrace internally uses dladdr to get the function name for the
address. This has certain limits, for example dladdr _doesn't use
debug info at all_, so it only finds functions which are dynamically
exported (this means only those which could be loaded by dlsym).
This is also the reason why --export-dynamic is needed (when building a
static executable/library).
Apr 30 2012
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps.


Very nice, amazing job! This is like my personal plans and hopes 
coming to life.
Apr 26 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 26 April 2012 at 22:25:33 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps.


 Very nice, amazing job! This is like my personal plans and 
 hopes coming to life.


+1, although I didn't have the chance to look at it in detail 
yet. How should we submit »bug reports« for the website?

David
Apr 27 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 10:16, schrieb David Nadlinger:

 On Thursday, 26 April 2012 at 22:25:33 UTC, Vladimir Panteleev wrote:

 On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps.


 Very nice, amazing job! This is like my personal plans and hopes
 coming to life.


 +1, although I didn't have the chance to look at it in detail yet. How
 should we submit »bug reports« for the website?

 David


Initially I wanted to have a page-comment feature ready as on dlang.org. 
But for now I guess the github issue tracker should do the job: 
https://github.com/rejectedsoftware/vibe.d/issues

Sönke
Apr 27 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 27 April 2012 at 08:47:23 UTC, Sönke Ludwig wrote:

 Initially I wanted to have a page-comment feature ready as on 
 dlang.org. But for now I guess the github issue tracker should 
 do the job: https://github.com/rejectedsoftware/vibe.d/issues


Oh, and another thing, is vpm live yet? I though about starting 
to hack on a Socket.io implementation for Vibe this weekend…

David
Apr 27 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 13:57, schrieb David Nadlinger:

 On Friday, 27 April 2012 at 08:47:23 UTC, Sönke Ludwig wrote:

 Initially I wanted to have a page-comment feature ready as on
 dlang.org. But for now I guess the github issue tracker should do the
 job: https://github.com/rejectedsoftware/vibe.d/issues


 Oh, and another thing, is vpm live yet? I though about starting to hack
 on a Socket.io implementation for Vibe this weekend…

 David


It's live but currently projects can only be registered manually and 
there is no user web frontend - not a big deal though. But it still 
needs some testing and misses some features (e.g. package signing, 
updating and machine-wide installs).

Btw. there is already a WebSocket implementation in 
vibe.http.websockets, although still undocumented (vibenotes uses it). 
Jan, who has written it also planned on doing a fallback for older 
browsers using long polling. But socket.io compatibility was not on the 
table yet..
Apr 27 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-26 22:46, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


Wow, that's impressive.

-- 
/Jacob Carlborg
Apr 26 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Great work!

This is the the type of server side frameworks we need.

--
Paulo

On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

  - Very fast but no endless callback chains as in node.js
    and similar frameworks
  - Concise API that tries to be as efficient and intuitive
    as possible
  - Built-in HTTP server and client with support for HTTPS,
    chunked and compressed transfers, keep-alive connections,
    Apache-style logging, a reverse-proxy, url routing and
    more
  - Jade based HTML/XML template system with compile-time
    code generation for the fastest dynamic page generation
    times possible
  - Built-in support for MongoDB and Redis databases
  - WebSocket support
  - Natural Json and Bson handling
  - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke
Apr 26 2012
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

  - Very fast but no endless callback chains as in node.js
    and similar frameworks
  - Concise API that tries to be as efficient and intuitive
    as possible
  - Built-in HTTP server and client with support for HTTPS,
    chunked and compressed transfers, keep-alive connections,
    Apache-style logging, a reverse-proxy, url routing and
    more
  - Jade based HTML/XML template system with compile-time
    code generation for the fastest dynamic page generation
    times possible
  - Built-in support for MongoDB and Redis databases
  - WebSocket support
  - Natural Json and Bson handling
  - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke


I had to copy the included .lib files into bin in order to build 
the examples but so far, so good.  This is awesome.

Regards,
Brad Anderson
Apr 26 2012
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
 I had to copy the included .lib files into bin in order to build the
 examples but so far, so good. This is awesome.

 Regards,
 Brad Anderson


There is some really strange behavior of Windows batch files where it 
sometimes fails with environment variables set with quotes and sometimes 
without...
Now I changed the line "SET LIBDIR=..\lib\win-i386" in run_example.cmd 
from quoted to non-quoted and for me it seems to work.

Any idea what might cause this erratic behavior?
Apr 27 2012
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 27 April 2012 at 07:00:23 UTC, Sönke Ludwig wrote:

 I had to copy the included .lib files into bin in order to 
 build the
 examples but so far, so good. This is awesome.

 Regards,
 Brad Anderson


 There is some really strange behavior of Windows batch files 
 where it sometimes fails with environment variables set with 
 quotes and sometimes without...
 Now I changed the line "SET LIBDIR=..\lib\win-i386" in 
 run_example.cmd from quoted to non-quoted and for me it seems 
 to work.

 Any idea what might cause this erratic behavior?


I haven't a clue.

Are these diet templates static?  I was looking for more 
information but this page doesn't exist: 
http://vibed.org/templates
Apr 27 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 09:08, schrieb Brad Anderson:

 On Friday, 27 April 2012 at 07:00:23 UTC, Sönke Ludwig wrote:

 I had to copy the included .lib files into bin in order to build the
 examples but so far, so good. This is awesome.

 Regards,
 Brad Anderson


 There is some really strange behavior of Windows batch files where it
 sometimes fails with environment variables set with quotes and
 sometimes without...
 Now I changed the line "SET LIBDIR=..\lib\win-i386" in run_example.cmd
 from quoted to non-quoted and for me it seems to work.

 Any idea what might cause this erratic behavior?


 I haven't a clue.

 Are these diet templates static? I was looking for more information but
 this page doesn't exist: http://vibed.org/templates


Yes, they are compiled to D code at compile time but you can use dynamic 
expressions and statements inside. The result is a bunch of calls of the 
form:
'write("<html><head><title>"); write(htmlEscape(myDynamicVariable)); ...".

The features page* has a paragraph about them but the syntax reference 
is still missing. I will add a notice that the Jade reference** can be 
used instead for now.

* http://vibed.org/features#diet-templates
** https://github.com/visionmedia/jade
Apr 27 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/27/12, S=F6nke Ludwig <sludwig outerproduct.org> wrote:

 Now I changed the line "SET LIBDIR=3D..\lib\win-i386" in run_example.cmd
 from quoted to non-quoted and for me it seems to work.


Maybe try:
SET "LIBDIR=3D..\lib\win-i386"

IOW quotes after SET.
Apr 27 2012
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 10:26, schrieb Andrej Mitrovic:

 On 4/27/12, Sönke Ludwig<sludwig outerproduct.org>  wrote:

 Now I changed the line "SET LIBDIR=..\lib\win-i386" in run_example.cmd
 from quoted to non-quoted and for me it seems to work.


 Maybe try:
 SET "LIBDIR=..\lib\win-i386"

 IOW quotes after SET.


Thanks, that also seems to work. I will try that next as soon as the 
current non-quoted version fails for someone.
Apr 27 2012
prev sibling parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/27/12 2:50 PM, Brad Anderson wrote:

 On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

 - Very fast but no endless callback chains as in node.js
 and similar frameworks
 - Concise API that tries to be as efficient and intuitive
 as possible
 - Built-in HTTP server and client with support for HTTPS,
 chunked and compressed transfers, keep-alive connections,
 Apache-style logging, a reverse-proxy, url routing and
 more
 - Jade based HTML/XML template system with compile-time
 code generation for the fastest dynamic page generation
 times possible
 - Built-in support for MongoDB and Redis databases
 - WebSocket support
 - Natural Json and Bson handling
 - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke


 I had to copy the included .lib files into bin in order to build the
 examples but so far, so good. This is awesome.


How did you install it? I can't find the install.sh script anywhere...
Apr 27 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
On Thu, 26 Apr 2012 22:46:37 +0200, S=C3=B6nke Ludwig  =

<sludwig outerproduct.org> wrote:


 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.


Wow, thanks. Really looking forward to testing this.
I have a contract job coming up this summer. I had dismissed D altogethe=
r  =

for this app, but now I see some new hope :)
Apr 27 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
Sounds great! And the site's very speedy :)  I'm especially excited about 
this:

"(Work-in-progress) An integrated load balancer is able to dynamically 
compile, run and test new processes before switching them live after the 
code has been modified."

A few questions:

- Does the web framework work with other web servers, or is it tied to the 
built-in server?

- I don't suppose you have a feature comparison between the built-in server 
and Nginx? Is it one o' them fancy C10k servers? (Not that I'm likely to 
ever get that kind of traffic outside of a DDoS attack ;) )

- Why "static this"? Seems like a strange choice since it'll run before the 
main that (I assume) vibed automatically provides - and in an undefined 
order relative to all other module ctors.
Apr 27 2012
next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 10:01, schrieb Nick Sabalausky:

 Sounds great! And the site's very speedy :)  I'm especially excited about
 this:

 "(Work-in-progress) An integrated load balancer is able to dynamically
 compile, run and test new processes before switching them live after the
 code has been modified."


Me too, me too, it would have saved my ass last night when the server 
went down ;)


 A few questions:

 - Does the web framework work with other web servers, or is it tied to the
 built-in server?


You can put it behind an nginx reverse proxy (beginning with the new 
v1.2 that supports HTTP/1.1).

You could also just use everything except the HTTP server component and 
use classic CGI/FastCGI to communicate to the Web server. However, there 
is currently no FastCGI server built in, so something like libfcgi would 
have to do.


 - I don't suppose you have a feature comparison between the built-in server
 and Nginx? Is it one o' them fancy C10k servers? (Not that I'm likely to
 ever get that kind of traffic outside of a DDoS attack ;) )


We still have a more comprehensive benchmark on the table but it seemed 
to get along happily with about 60MB of RAM usage during a C10k test. 
The average request time went down to about 6s if I remember correctly. 
The test was using a dual-core Atom server over a WiFI connection so the 
results may have been skewed a litte.

I'm also planning to implement a core driver based on libuv in addition 
to the current libevent based one, which should gain a little more 
performance.

In terms of HTTP/1.1 implementation it is most importantly lacking 
multipart form uploads (will be added shortly). Otherwise the protocol 
supports most HTTP features. I'll put a more detailed comparison on my 
TODO list.


 - Why "static this"? Seems like a strange choice since it'll run before the
 main that (I assume) vibed automatically provides - and in an undefined
 order relative to all other module ctors.


The order of module constructors should be defined to be a valid order 
wrt. the import tree right?

The main reason is to have a lean and mean way to write small 
applications. A default main() is compiled in which handles command line 
parsing, connection to a load-balancer/reverse proxy etc.

However, it is also possible to just implement a custom main() and start 
from there - you just have to include vibe.vibe instead of vibe.d so 
that the built-in main() is not compiled. I will put an example on the 
website later.
Apr 27 2012
next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Sönke Ludwig" <sludwig outerproduct.org> wrote in message 
news:jndl9l$26eh$1 digitalmars.com...

 We still have a more comprehensive benchmark on the table but it seemed to 
 get along happily with about 60MB of RAM usage during a C10k test. The 
 average request time went down to about 6s if I remember correctly. The 
 test was using a dual-core Atom server over a WiFI connection so the 
 results may have been skewed a litte.


I guess I don't have much of a frame of reference, but that certainly sounds 
very impressive. Especially the RAM usage (you could probably kill lighttpd, 
from what I've heard about it) and also the fact that was all over WiFi.

Have you looked at long-term memory usage? I wonder if D's imprecise GC 
could be a liability and would need to be ?


 In terms of HTTP/1.1 implementation it is most importantly lacking 
 multipart form uploads (will be added shortly). Otherwise the protocol 
 supports most HTTP features. I'll put a more detailed comparison on my 
 TODO list.


Thanks, I'm anxious to take a look. I'm particulary curious how much of your 
intended scope does/doesn't overlap with Nginx's domain and it's (rather 
Apache-competetive) suite of modules: http://wiki.nginx.org/Modules

Do you see this as eventually (or even currently) competing with Nginx in 
general? Or is it more focused on web framework and general async I/O? 
(Actually that's another thing, how general is the async I/O in it? Is it 
intended to be used for just...whatever general I/O uses...or is it more 
intended as a means-to-an-end for web?)

The way it's designed, I suppose the features of many of Nginx's modules 
could simply be implemented using vibed, for example directory listings.

I hope it doesn't sound like I'm trying to tear vibed apart. I'm genuinely 
impressed with it so far. Just trying to get a good feel for it and how best 
to use it effectively.


 - Why "static this"? Seems like a strange choice since it'll run before 
 the
 main that (I assume) vibed automatically provides - and in an undefined
 order relative to all other module ctors.


 The order of module constructors should be defined to be a valid order 
 wrt. the import tree right?


Oops, yea. Not sure what I was thinking.


 However, it is also possible to just implement a custom main() and start 
 from there - you just have to include vibe.vibe instead of vibe.d so that 
 the built-in main() is not compiled. I will put an example on the website 
 later.


Cool.
Apr 27 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
news:jndnic$2b5u$1 digitalmars.com...

 Have you looked at long-term memory usage? I wonder if D's imprecise GC 
 could be a liability and would need to be ?


...would need to be managed carefully?
Apr 27 2012
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 11:06, schrieb Nick Sabalausky:

 "Sönke Ludwig"<sludwig outerproduct.org>  wrote in message
 news:jndl9l$26eh$1 digitalmars.com...

 We still have a more comprehensive benchmark on the table but it seemed to
 get along happily with about 60MB of RAM usage during a C10k test. The
 average request time went down to about 6s if I remember correctly. The
 test was using a dual-core Atom server over a WiFI connection so the
 results may have been skewed a litte.


 I guess I don't have much of a frame of reference, but that certainly sounds
 very impressive. Especially the RAM usage (you could probably kill lighttpd,
 from what I've heard about it) and also the fact that was all over WiFi.

 Have you looked at long-term memory usage? I wonder if D's imprecise GC
 could be a liability and would need to be ?


I'm starting to monitor it now. Directly after startup, the website is 
at 32 MB. The traffic has dropped a bit but hopefully it's enough to see 
something if there is a hidden leak.

After the C10k test, the memory usage dropped back to normal if I 
remember right so there should be nothing too bad in the core.


 In terms of HTTP/1.1 implementation it is most importantly lacking
 multipart form uploads (will be added shortly). Otherwise the protocol
 supports most HTTP features. I'll put a more detailed comparison on my
 TODO list.


 Thanks, I'm anxious to take a look. I'm particulary curious how much of your
 intended scope does/doesn't overlap with Nginx's domain and it's (rather
 Apache-competetive) suite of modules: http://wiki.nginx.org/Modules


 From going just over the module index, the features that are in or 
planned are:

  - most of Core is there
  - Basic auth - check
  - Auto index - part of a separate library that is still in dev.
  - FastCGI client is planned, possible also a server
  - Gzip responses (the static file server componen does this)
  - Headers - check
  - Limit Requests/Zone is planned
  - Limit Conn is planned
  - Log - check
  - Proxy - check
  - scgi - maybe instead of FastCGI
  - Split Clients - easy to do programmatically
  - Upstream - planned
  - SSL - check
  - WebDAV - planned
  - simplistic SMTP - check


 Do you see this as eventually (or even currently) competing with Nginx in
 general? Or is it more focused on web framework and general async I/O?
 (Actually that's another thing, how general is the async I/O in it? Is it
 intended to be used for just...whatever general I/O uses...or is it more
 intended as a means-to-an-end for web?)

 The way it's designed, I suppose the features of many of Nginx's modules
 could simply be implemented using vibed, for example directory listings.



In general it's more a general application framework or an extension 
library. But a stand-alone webserver would be an easy project - nothing 
that I have directly planned myself though.

The I/O is supposed to be as general as possible. Right now the focus 
has been on web applications but we also plan a desktop application that 
is going to use it for all of its I/O. For this I'm also looking into 
how to integrate the event loop with the OS message queue efficiently on 
all platforms.

There are still some things missing for the libevent driver but with the 
upcoming libuv driver everything that libuv provides should be available.
Apr 27 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 11:34, schrieb Sönke Ludwig:

 I'm starting to monitor it now. Directly after startup, the website is
 at 32 MB. The traffic has dropped a bit but hopefully it's enough to see
 something if there is a hidden leak.


A mid-term test now shows that shortly after startup the virtual memory 
usage went up from 32MB to about 44MB. After 24h and about 50k requests 
it stays at 43.5MB. Real memory usage is 15MB.
Apr 28 2012
parent reply Rory McGuire <rjmcguire gmail.com> writes:
Awesome! that was one of my concerns with D in general with server software
and its long running nature.
I've been thinking about fibers and socket.d this week. Glad you anounced
this before I started working on something :D.

How difficult would it be for you to split the async IO parts into a
separate library? This would be very much like gevent (python:
http://www.gevent.org/).

Any chance of supporting WSGI?

On Sat, Apr 28, 2012 at 2:36 PM, S=C3=B6nke Ludwig <sludwig outerproduct.or=
g>wrote:


 Am 27.04.2012 11:34, schrieb S=C3=B6nke Ludwig:



 I'm starting to monitor it now. Directly after startup, the website is
 at 32 MB. The traffic has dropped a bit but hopefully it's enough to see
 something if there is a hidden leak.


 A mid-term test now shows that shortly after startup the virtual memory
 usage went up from 32MB to about 44MB. After 24h and about 50k requests i=


t

 stays at 43.5MB. Real memory usage is 15MB.
Apr 28 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 28.04.2012 20:47, schrieb Rory McGuire:

 Awesome! that was one of my concerns with D in general with server
 software and its long running nature.
 I've been thinking about fibers and socket.d this week. Glad you
 anounced this before I started working on something :D.


Yeah I've also tought about this for a while before I was finally fed up 
with a REST-server project and finally started vibe. Of course it's much 
more work now in total but making web applications is finally fun now :)


 How difficult would it be for you to split the async IO parts into a
 separate library? This would be very much like gevent (python:
 http://www.gevent.org/).


That would basically be vibe.core and vibe.stream. Those have no 
dependencies to other modules so they can already be used without the 
rest of the code adding overhead of any kind.


 Any chance of supporting WSGI?


It's not directly planned from our side but either eventually or if 
someone else writes a version I think it will get in.


 On Sat, Apr 28, 2012 at 2:36 PM, Sönke Ludwig <sludwig outerproduct.org
 <mailto:sludwig outerproduct.org>> wrote:

     Am 27.04.2012 11 <tel:27.04.2012%2011>:34, schrieb Sönke Ludwig:


         I'm starting to monitor it now. Directly after startup, the
         website is
         at 32 MB. The traffic has dropped a bit but hopefully it's
         enough to see
         something if there is a hidden leak.


     A mid-term test now shows that shortly after startup the virtual
     memory usage went up from 32MB to about 44MB. After 24h and about
     50k requests it stays at 43.5MB. Real memory usage is 15MB.
Apr 30 2012
parent Rory McGuire <rjmcguire gmail.com> writes:
On Mon, Apr 30, 2012 at 9:57 AM, S=C3=B6nke Ludwig <sludwig outerproduct.or=
g>wrote:


 How difficult would it be for you to split the async IO parts into a
 separate library? This would be very much like gevent (python:
 http://www.gevent.org/).


 That would basically be vibe.core and vibe.stream. Those have no
 dependencies to other modules so they can already be used without the res=


t

 of the code adding overhead of any kind.



Thanks.

I wonder how vibe.d performs vs a gevent based web server.
Apr 30 2012
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 27, 2012, at 1:27 AM, S=C3=B6nke Ludwig <sludwig outerproduct.org> wr=
ote:

=20
 We still have a more comprehensive benchmark on the table but it seemed to=


 get along happily with about 60MB of RAM usage during a C10k test. The aver=
age request time went down to about 6s if I remember correctly. The test was=
 using a dual-core Atom server over a WiFI connection so the results may hav=
e been skewed a litte.

6s?  Not 6ms?  Why so slow?=
Apr 27 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 18:54, schrieb Sean Kelly:

 On Apr 27, 2012, at 1:27 AM, Sönke Ludwig<sludwig outerproduct.org>  wrote:

 We still have a more comprehensive benchmark on the table but it seemed to get
along happily with about 60MB of RAM usage during a C10k test. The average
request time went down to about 6s if I remember correctly. The test was using
a dual-core Atom server over a WiFI connection so the results may have been
skewed a litte.


 6s?  Not 6ms?  Why so slow?


With 10000 connections concurrently.. not exactly sure who is reposible 
but probably either the network or libevent. But some diagnostic 
benchmarking is in order.
Apr 27 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/27/2012 10:01 AM, Nick Sabalausky wrote:

 ...
 - Why "static this"? Seems like a strange choice since it'll run before the
 main that (I assume) vibed automatically provides - and in an undefined
 order relative to all other module ctors.


This is not true. The order is defined as far it matters for static 
initialisation. I think this is perfectly fine.
Apr 27 2012
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Sönke Ludwig wrote:


 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.
 
 Some of its key fatures are:
 
   - Very fast but no endless callback chains as in node.js
     and similar frameworks
   - Concise API that tries to be as efficient and intuitive
     as possible
   - Built-in HTTP server and client with support for HTTPS,
     chunked and compressed transfers, keep-alive connections,
     Apache-style logging, a reverse-proxy, url routing and
     more
   - Jade based HTML/XML template system with compile-time
     code generation for the fastest dynamic page generation
     times possible
   - Built-in support for MongoDB and Redis databases
   - WebSocket support
   - Natural Json and Bson handling
   - A package manager for seemless use of extension libraries
 
 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).
 
 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.
 
 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.
 
 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.
 
 Regards,
 Sönke


Sönke, vibed is truly amazing! I am interested in the web server's internal 
architecture. I always wanted to do an implementation of a web server using
a form of asymmetric, multi-process event-driven architecture. A web server 
which utilises fibers. It would be nice if you explain the web-server 
architecture of vibed in more details.

Keep up with good work!

Regards
Apr 27 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
 Sönke, vibed is truly amazing! I am interested in the web server's internal
 architecture. I always wanted to do an implementation of a web server using
 a form of asymmetric, multi-process event-driven architecture. A web server
 which utilises fibers. It would be nice if you explain the web-server
 architecture of vibed in more details.

 Keep up with good work!

 Regards


Thanks! I will add a page with graphical explanation on the website when 
I have some time. But in short all fibers are currently living in the 
same thread. Each fiber is registered with one or multiple events inside 
of the event driver (libevent based currently). As soon as an event 
arrives, the corresponding fiber is resumed. The fiber will then simply 
do conceptually this for every blocking operation:

blockingOperation(){
	requestOperation();
	while( !operationFinished() ) yield();
}

I've thought about sharing fibers across threads but came to the 
conclusion that this is probably more trouble than it's worth. An 
alternative would be to start multiple event loops in separate threads 
and then distribute incoming connections to these loops before starting 
a corresponding fiber.

Right now its at least possible to off-load all computational tasks 
using std.concurrency or std.parallelism or similar. An efficient 
asynchronous wait function for a std.concurrency message or for a 
std.parallelism task would be useful though.
Apr 27 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 27.04.2012 0:46, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


In short: meet the new boss of the web development :)

Few things I think worth looking at.
1. Add cool auto-magic API generator in Adam's style:
route.wrapModule!(module_name)("/url");
The effect is that it "binds" /url/function_name for each function found 
in module, automatically gets parameters from post (or get) using 
arguments names of function. Last but not least it issues necessary 
calls to std.conv.to as needed.
Ah and the result is again converted to string (if needed) and packed 
into response body.

Example:
module factorial;

long fact(int k)
{
	return k > 1 ? k*fact(k-1) : 1;
}

Wrapped via wrapModule!(factorial)("/"); will work as
/fact?k=10 will out the result in plain-text. MIME type and conversion 
should be configurable of course.

2. By the very nature of your framework you should be well prepared to 
small-scale DDoS attacks.  But there is much more in DoS assortment 
these days. It would be shame if your framework doesn't handle e.g. 
slow-writer attack. Imagine attacker spoon-feeds HTTP request to your 
server by 1 byte per 10msec. Bump simultaneous request count to few 
thousands and your nice event loop freezes to a crawl. You gotta check 
upload rates ;)

-- 
Dmitry Olshansky
Apr 27 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 10:10, schrieb Dmitry Olshansky:

 On 27.04.2012 0:46, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


 In short: meet the new boss of the web development :)

 Few things I think worth looking at.
 1. Add cool auto-magic API generator in Adam's style:
 route.wrapModule!(module_name)("/url");
 The effect is that it "binds" /url/function_name for each function found
 in module, automatically gets parameters from post (or get) using
 arguments names of function. Last but not least it issues necessary
 calls to std.conv.to as needed.
 Ah and the result is again converted to string (if needed) and packed
 into response body.

 Example:
 module factorial;

 long fact(int k)
 {
 return k > 1 ? k*fact(k-1) : 1;
 }

 Wrapped via wrapModule!(factorial)("/"); will work as
 /fact?k=10 will out the result in plain-text. MIME type and conversion
 should be configurable of course.


Now on the TODO list!


 2. By the very nature of your framework you should be well prepared to
 small-scale DDoS attacks. But there is much more in DoS assortment these
 days. It would be shame if your framework doesn't handle e.g.
 slow-writer attack. Imagine attacker spoon-feeds HTTP request to your
 server by 1 byte per 10msec. Bump simultaneous request count to few
 thousands and your nice event loop freezes to a crawl. You gotta check
 upload rates ;)


There is already a HttpServerOptions.maxRequestTime that would help - 
but this is currently still ignored. Also, keep-alive connections are 
kept open too long right now. But both is on the list.

Maybe something like a LRU limiter that closes old connections in case 
of too many open connections would also be a good alternative barrier...

My plan is also to switch all modules to  safe as soon as Phobos and 
Druntime have a bit better support. I guess this is type of application 
can be considered the prototype for which SafeD is useful.
Apr 27 2012
prev sibling next sibling parent reply David <d dav1d.de> writes:
I am not sure if you're aware of Flask, Flask is a microframework for 
Python.

It provides something called "Blueprints", you can register e.g. 
"routes" to this Blueprint and to use them you've to add them to the 
main application. This makes code way more readable!
Also some kind of after_request and before_request handlers would be 
great, you could use them e.g. fetching a user from the database and 
providing it to the handler (over a thread-local?).
Apr 27 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.04.2012 11:57, schrieb David:

 I am not sure if you're aware of Flask, Flask is a microframework for
 Python.

 It provides something called "Blueprints", you can register e.g.
 "routes" to this Blueprint and to use them you've to add them to the
 main application. This makes code way more readable!
 Also some kind of after_request and before_request handlers would be
 great, you could use them e.g. fetching a user from the database and
 providing it to the handler (over a thread-local?).


I didn't know flask before and the website seems to be down currently ;)

But is the UrlRouter (see http://vibed.org/docs#http-routing and 
http://vibed.org/api/vibe.http.router#UrlRouter) something equivalent?

It allows you to specify multiple patterns that are matched in sequence 
until a request handler writes a response:

auto r = new UrlRouter;
r.any("*", &performAuth);
r.get("/", &renderHomePage);
listenHttp(settings, r);

This would first always match performAuth, which could check the user 
credentials and write out a message if the user is not authenticated. 
Otherwise it just does nothing and the router will continue to the next 
match, which is renderHomePage() in this case for "GET /".

Whats not directly possible in the router is something like 
after_request. But you can do it easily by wrapping the call:

auto r = new UrlRouter;
//...
listenHttp(settings, (req, res){
	before_request(req, res);
	r.handleRequest(req, res);
	after_request(req, res);
});
Apr 27 2012
parent reply David <d dav1d.de> writes:
Am 27.04.2012 13:18, schrieb Sönke Ludwig:

 Am 27.04.2012 11:57, schrieb David:

 I am not sure if you're aware of Flask, Flask is a microframework for
 Python.

 It provides something called "Blueprints", you can register e.g.
 "routes" to this Blueprint and to use them you've to add them to the
 main application. This makes code way more readable!
 Also some kind of after_request and before_request handlers would be
 great, you could use them e.g. fetching a user from the database and
 providing it to the handler (over a thread-local?).


 I didn't know flask before and the website seems to be down currently ;)


Yes :(
Admin paused the server, too much IO or something.


 But is the UrlRouter (see http://vibed.org/docs#http-routing and
 http://vibed.org/api/vibe.http.router#UrlRouter) something equivalent?

 It allows you to specify multiple patterns that are matched in sequence
 until a request handler writes a response:

 auto r = new UrlRouter;
 r.any("*", &performAuth);
 r.get("/", &renderHomePage);
 listenHttp(settings, r);

 This would first always match performAuth, which could check the user
 credentials and write out a message if the user is not authenticated.
 Otherwise it just does nothing and the router will continue to the next
 match, which is renderHomePage() in this case for "GET /".


This is useful!


 Whats not directly possible in the router is something like
 after_request. But you can do it easily by wrapping the call:

 auto r = new UrlRouter;
 //...
 listenHttp(settings, (req, res){
 before_request(req, res);
 r.handleRequest(req, res);
 after_request(req, res);
 });


Awesome!
Apr 27 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
The server is back up and I've looked at Flask's blueprints. So they 
have a more implicit approach with annotations (once D has these, it 
would be a possible extension for vibe). Right now my corresponding 
pattern looks like this:

// create a global url router
auto r = new UrlRouter

// create application specific routes
r.get("/", &showHomePage);

// let each sub-component register its routes, possibly in a sub-path
registerVibeLog(settings, router);
registerTicker(router, "/ticker");
Apr 27 2012
prev sibling next sibling parent reply "mist" <none none.none> writes:
Can't wait to go home and get my greedy hands on it.
Sounds.. amazing. Hell, if all of this stuff really works and 
works on par with nginx+fastcgi performance, it can be the very 
killer app for D waited so long.
Apr 27 2012
parent reply "Puming" <zhaopuming gmail.com> writes:
Excellent work Sönke! Vibe.d seems very promising :)

I've played with vibe.d with a hello project as described in the
document, and downloaded vibenotes and vibeblog from git and
poked around a little.

vibe.d gives me a very smooth experience, and I'll try learn
about it more :)

two little things to note:

1. In the tutorial it didn't say how to start vibe.d project. I
spent some minutes to find it: by running vibe at the root of a
project. Maybe its clear to state that in the tutorial

2. It seems that diet templates doesn't support soft tab. I
looked into the code, and in indentLevel(line) it only dectects
'\t'. Will vibe.d support soft tab?
Apr 27 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 27.04.2012 13:07, schrieb Puming:

 Excellent work Sönke! Vibe.d seems very promising :)


Thanks :)


 I've played with vibe.d with a hello project as described in the
 document, and downloaded vibenotes and vibeblog from git and
 poked around a little.

 vibe.d gives me a very smooth experience, and I'll try learn
 about it more :)

 two little things to note:

 1. In the tutorial it didn't say how to start vibe.d project. I
 spent some minutes to find it: by running vibe at the root of a
 project. Maybe its clear to state that in the tutorial


It definitely needs some improvements. My idea would be to change it to 
a step-by-step tutorial and also add support for something like "vibe 
init <appname>" to generate the basic app skeleton.


 2. It seems that diet templates doesn't support soft tab. I
 looked into the code, and in indentLevel(line) it only dectects
 '\t'. Will vibe.d support soft tab?


I put an item in the TODO list to detect the indent style from the first 
indented line. This indent style would then be used for the rest of the 
document.
Apr 27 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:
 ...


vibe.d looks great! Looking through the docs, it feels clean and 
"hip" like node.js

However, there are a couple refactoring choices I think would 
have made it even more "hip", consider the home page example:

     import vibe.d;

     void handleRequest(HttpServerRequest req,
                        HttpServerResponse res)
     {
         res.writeBody("Hello, World!", "text/plain");
     }

     static this()
     {
         auto settings = new HttpServerSettings;
         settings.port = 8080;

         listenHttp(settings, &handleRequest);
     }

"vibe.d" as the project name is great, but why have module vibe.d 
and not simply vibe? Or, why prefix all the types with 
"HttpServer" when you could separate those objects into a new 
module and drop the prefix. I think those simple changes would 
make an already polished library shine a bit brighter:

     import vibe.http;

     void handleRequest(Request req, Response res) {
         res.writeBody("Hellow, World!", "text/plain");
     }

     static this() {
         auto settings = new Settings;
         settings.port = 8080;

         listen(settings, &handleRequest);
     }

the echo server would look like:

     import vibe.tcp;

     static this()
     {
         listen(7, (conn){ conn.write(conn) });
     }

Also, it's great to see MongoDB support built in :D, but isn't 
there a way to trim down the query object from:

     BSON({"name": BSON("Peter")})

to:

     BSON({"name":"Peter"})

by writing a generic AssosiativeArrayToBSON function? That way 
you could overload MongoDB's find/save/etc functions to accept 
arbitrary AAs as queries, which would end up looking a lot 
slicker in the docs I think. Plus, through CTFE it's possible 
this conversion could happen at both compile-time and run-time:

     auto db = new MongoDB;
     auto col = db["test.collection"];

     foreach (doc; col.ctFind!(["name":"Peter"])) {

         ...
     }

Just some ideas in case you haven't thought of them already :)


Overall vibe.d looks like a fantastic library. Thank you and 
Congrats!
Apr 27 2012
next sibling parent reply "Tove" <tove fransson.se> writes:
On Friday, 27 April 2012 at 19:40:53 UTC, F i L wrote:

 "vibe.d" as the project name is great, but why have module 
 vibe.d and not simply vibe? Or, why prefix all the types with


More complicated projects/frameworks ontop of vibe which 
implements it's own main is free to use vibe.all.

But I think...
   import vibe.d;
... makes perfect sense because it contains main()!
Apr 27 2012
parent "F i L" <witte2008 gmail.com> writes:
On Friday, 27 April 2012 at 20:15:05 UTC, Tove wrote:

 On Friday, 27 April 2012 at 19:40:53 UTC, F i L wrote:

 "vibe.d" as the project name is great, but why have module 
 vibe.d and not simply vibe? Or, why prefix all the types with


 More complicated projects/frameworks ontop of vibe which 
 implements it's own main is free to use vibe.all.

 But I think...
   import vibe.d;
 ... makes perfect sense because it contains main()!


Ah I see, I was thinking the example wasn't the full code. Still, 
I think doing something like:

     import vibe, vibe.html;

where vibe has main() and vibe.html has html is still better 
semantics.
Apr 27 2012
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
[my previous anwer got lost because of an high-load error on the NG 
server. hope I didn't forget anything..]

Am 27.04.2012 21:40, schrieb F i L:

 Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:
 ...


 vibe.d looks great! Looking through the docs, it feels clean and "hip"
 like node.js

 However, there are a couple refactoring choices I think would have made
 it even more "hip", consider the home page example:

 import vibe.d;

 void handleRequest(HttpServerRequest req,
 HttpServerResponse res)
 {
 res.writeBody("Hello, World!", "text/plain");
 }

 static this()
 {
 auto settings = new HttpServerSettings;
 settings.port = 8080;

 listenHttp(settings, &handleRequest);
 }

 "vibe.d" as the project name is great, but why have module vibe.d and
 not simply vibe? Or, why prefix all the types with "HttpServer" when you
 could separate those objects into a new module and drop the prefix. I
 think those simple changes would make an already polished library shine
 a bit brighter:

 import vibe.http;

 void handleRequest(Request req, Response res) {
 res.writeBody("Hellow, World!", "text/plain");
 }

 static this() {
 auto settings = new Settings;
 settings.port = 8080;

 listen(settings, &handleRequest);
 }

 the echo server would look like:

 import vibe.tcp;

 static this()
 {
 listen(7, (conn){ conn.write(conn) });
 }


The objects are already in different modules, albeit a level deeper 
(e.g. vibe.http.server). "import vibe;" cannot currently work without 
something like DIP15 or DIP16 because vibe is a package.
-> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

There are two reasons, why I made the names unique: 
readability/understandability and ease of use (not having to look up all 
the sub modules to find a certain function).

I am not really happy with the long names but on the other hand I found 
this was not really much of an issue, because often you can avoid it 
alltogether with things like staticTemplate!"file.dt" 
(http://vibed.org/api/vibe.http.server#staticTemplate) or by using a 
closure with inferred parameter arguments.


 Also, it's great to see MongoDB support built in :D, but isn't there a
 way to trim down the query object from:

 BSON({"name": BSON("Peter")})

 to:

 BSON({"name":"Peter"})

 by writing a generic AssosiativeArrayToBSON function? That way you could
 overload MongoDB's find/save/etc functions to accept arbitrary AAs as
 queries, which would end up looking a lot slicker in the docs I think.
 Plus, through CTFE it's possible this conversion could happen at both
 compile-time and run-time:

 auto db = new MongoDB;
 auto col = db["test.collection"];

 foreach (doc; col.ctFind!(["name":"Peter"])) {

 ...
 }


The MongoDB functions can actually take any of Bson, Json, 
Bson[ObjectID,Date,...], arrays, AAs, strings and scalars and structs 
and classes, in any nesting. They use serializeToBson() internally to 
convert to Bson.

The examples and the documentation need some updates there.


 Just some ideas in case you haven't thought of them already :)


 Overall vibe.d looks like a fantastic library. Thank you and Congrats!


Thanks! I hope the remaining rough edges get smoothed out quickly in the 
next time.
Apr 28 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 26/04/2012 22:46, Sönke Ludwig a écrit :

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

 - Very fast but no endless callback chains as in node.js
 and similar frameworks
 - Concise API that tries to be as efficient and intuitive
 as possible
 - Built-in HTTP server and client with support for HTTPS,
 chunked and compressed transfers, keep-alive connections,
 Apache-style logging, a reverse-proxy, url routing and
 more
 - Jade based HTML/XML template system with compile-time
 code generation for the fastest dynamic page generation
 times possible
 - Built-in support for MongoDB and Redis databases
 - WebSocket support
 - Natural Json and Bson handling
 - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke


It is awesome. I think some part of this could be integrated into phobos 
after some refactoring. I think about databases for instance, or some 
http libraries.
Apr 27 2012
parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 4/27/12 1:42 PM, deadalnix wrote:

 It is awesome. I think some part of this could be integrated into phobos
 after some refactoring. I think about databases for instance, or some
 http libraries.


This is an ignorant question, but why not the async IO stuff?  It seems 
like it could be widely useful.  Or is it only designed for this kind of 
use?
Apr 27 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 27/04/2012 22:42, David Gileadi a écrit :

 On 4/27/12 1:42 PM, deadalnix wrote:

 It is awesome. I think some part of this could be integrated into phobos
 after some refactoring. I think about databases for instance, or some
 http libraries.


 This is an ignorant question, but why not the async IO stuff? It seems
 like it could be widely useful. Or is it only designed for this kind of
 use?


This is an ignorant answer, because I didn't looked at the source code, 
but I guess most of it is highly dependent on vide itself.
Apr 27 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/27/12 4:46 AM, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


Impressive. The website also looks really nice, and it's very fast.

I'll definitely play with it and slowly try to make it into my 
workplace, hehe.
Apr 27 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/28/12 8:12 AM, Ary Manzana wrote:

 On 4/27/12 4:46 AM, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


 Impressive. The website also looks really nice, and it's very fast.

 I'll definitely play with it and slowly try to make it into my
 workplace, hehe.


How to use it?


 ./bin/vibe


usage: dirname path
sh: /vpm.d.deps: Permission denied
Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent' 
'-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v' 
'-o-' '/vpm.d' '-I/'
Error: cannot read file source/app.d
Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent' 
'-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v' 
'-o-' 'source/app.d' '-Isource'

I also can't find the install.sh script...
Apr 27 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 28.04.2012 06:16, schrieb Ary Manzana:

 On 4/28/12 8:12 AM, Ary Manzana wrote:

 On 4/27/12 4:46 AM, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:


 Impressive. The website also looks really nice, and it's very fast.

 I'll definitely play with it and slowly try to make it into my
 workplace, hehe.


 How to use it?

  > ./bin/vibe
 usage: dirname path
 sh: /vpm.d.deps: Permission denied
 Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent'
 '-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v'
 '-o-' '/vpm.d' '-I/'
 Error: cannot read file source/app.d
 Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent'
 '-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v'
 '-o-' 'source/app.d' '-Isource'

 I also can't find the install.sh script...


Making the installation more automated is planned next, and the 
install.sh was unfortunately documented before it was written. For now I 
would recommend to create a symlink to the vibe script in /usr/bin and 
then create a new project along the lines of the 'first steps' section 
(http://vibed.org/docs#first-steps). In particular, there should be a 
source/app.d file.

It's possible that bin directory also needs to be writable because of 
how rdmd stores its .deps file, which is a bug that will get fixed. 
Sorry for the slightly bumpy start.
Apr 28 2012
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
Very nice to see that someone took the async/Fiber idea that far.

Some observations:
- Wouldn't wrapping code in "void main()" instead of "static this()" make  
better front page examples.
- It would be interesting to know what made you write your own Stream/JSON  
implementations.
- I think there is some interest in having the HTTP handling and the  
templates in a separate library.
Apr 28 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 06:18, schrieb Martin Nowak:

 Very nice to see that someone took the async/Fiber idea that far.

 Some observations:
 - Wouldn't wrapping code in "void main()" instead of "static this()"
 make better front page examples.


The static this() pattern is mainly there to appeal to users of similar 
systems in script languages, where you don't have a main function at all 
and just happily hack away. For larger projects it doesn't make a 
difference but for small projects it can actually be quite convenient.

Maybe it would be a good idea to place a prominent example of how it's 
possible to define your own main() to gain additional control.


 - It would be interesting to know what made you write your own
 Stream/JSON implementations.


Stream has a number of additional functions or parameters such as 
leastSize() that are required or extremely convenient in this context. 
Also to avoid dragging in something like std.stream.File which has 
sychronous behavior and would block the event loop without anyone 
noticing it until the resulting bad performance under high-load 
conditions shows.

The reasons for writing an own Json implementation is that the interface 
of std.json is.. well.. nice if you write something in C. The 
implementation in vibe tries to let Json seem like a natural dynamic 
type of the language as far as it makes sense. The std.json parser can 
also only parse string buffers and I wanted to have something that can 
easily be used to work efficiently on a stream. Support for pretty 
printing was another reason (would of course also easy to add on top of 
std.json).


 - I think there is some interest in having the HTTP handling and the
 templates in a separate library.


My considerations are that if you don't use the HTTP/... parts, it will 
neither occupy space in your app, nor will it drag in any additional 
dependencies. That separate library would basically be vibe.core and 
vibe.stream vs. the rest of modules. And dependency-wise they are 
already separate (core and stream have no outside dependencies to the 
library).

If on the other hand you wanted to use the HTTP/... stuff together with 
other libraries in a blocking, non-fiber environment, it would also just 
work - all operations are also working and blocking outside of the event 
loop.
Apr 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-29 10:07, Sönke Ludwig wrote:


 The static this() pattern is mainly there to appeal to users of similar
 systems in script languages, where you don't have a main function at all
 and just happily hack away. For larger projects it doesn't make a
 difference but for small projects it can actually be quite convenient.


Since you can't have code (besides declarations) at the module level I 
don't see how "static this" would be than "main".

-- 
/Jacob Carlborg
Apr 29 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 15:22, schrieb Jacob Carlborg:

 On 2012-04-29 10:07, Sönke Ludwig wrote:


 The static this() pattern is mainly there to appeal to users of similar
 systems in script languages, where you don't have a main function at all
 and just happily hack away. For larger projects it doesn't make a
 difference but for small projects it can actually be quite convenient.


 Since you can't have code (besides declarations) at the module level I
 don't see how "static this" would be than "main".


You just don't have to care about how to parse command line arguments, 
how to initialize the library and to start the event loop.
Apr 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-29 20:29, Sönke Ludwig wrote:


 You just don't have to care about how to parse command line arguments,
 how to initialize the library and to start the event loop.


Right, didn't thought of that. Would it be a good idea to allow top 
level code and use "import" and mixin the code in some context, i.e. :

// foo.d

auto settings = new HttpServerSettings;
settings.port = 8080;
listenHttp(settings, &handleRequest);

Then somewhere:

// vibe.d

void main (string[] args)
{
     handleCommandLine(args);
     init();
     mixin(import("foo.d"));
}

-- 
/Jacob Carlborg
Apr 29 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 30.04.2012 08:22, schrieb Jacob Carlborg:

 On 2012-04-29 20:29, Sönke Ludwig wrote:


 You just don't have to care about how to parse command line arguments,
 how to initialize the library and to start the event loop.


 Right, didn't thought of that. Would it be a good idea to allow top
 level code and use "import" and mixin the code in some context, i.e. :

 // foo.d

 auto settings = new HttpServerSettings;
 settings.port = 8080;
 listenHttp(settings, &handleRequest);

 Then somewhere:

 // vibe.d

 void main (string[] args)
 {
 handleCommandLine(args);
 init();
 mixin(import("foo.d"));
 }


Interesting haven't thought about going that far :)

Somehow that reminds me of:
#define IF if(
#define THEN ){
#define ELSE } else {
#define ENDIF }

to transform C into BASIC. The scripting-only people would probably be 
thrilled ;) But I have the tendency to think that this bends the 
language a bit too far. They will also soon wonder why they cannot put 
top-level code in their other files.

Sönke
Apr 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 09:00, Sönke Ludwig wrote:


 Interesting haven't thought about going that far :)

 Somehow that reminds me of:
 #define IF if(
 #define THEN ){
 #define ELSE } else {
 #define ENDIF }

 to transform C into BASIC. The scripting-only people would probably be
 thrilled ;) But I have the tendency to think that this bends the
 language a bit too far. They will also soon wonder why they cannot put
 top-level code in their other files.

 Sönke


Yeah, I guess that will most likely be a problem.

-- 
/Jacob Carlborg
Apr 30 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote:

 On 2012-04-30 09:00, Sönke Ludwig wrote:

 They will also soon wonder why they cannot put
 top-level code in their other files.


 Yeah, I guess that will most likely be a problem.


Also, doesn't ImportExpression require passing -J to the 
compiler? That'd potentially only add another source of confusion 
for newcomers.

David
Apr 30 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 13:05, David Nadlinger wrote:

 On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote:

 On 2012-04-30 09:00, Sönke Ludwig wrote:

 They will also soon wonder why they cannot put
 top-level code in their other files.


 Yeah, I guess that will most likely be a problem.


 Also, doesn't ImportExpression require passing -J to the compiler?
 That'd potentially only add another source of confusion for newcomers.

 David


You're correct, it does.

-- 
/Jacob Carlborg
Apr 30 2012
prev sibling next sibling parent reply "bls" <bls orange.fr> writes:
Great job. Thanks Soenke et al;


  - Built-in support for MongoDB and Redis databases


MySQL.
Like other folks here I need a SQL db, At least for MyQL 5.1 
there is a socket based solution from Steve Teale.
https://github.com/britseye/mysqln
Means no licence trouble, and probably easier to establish async 
support.

Quote
Additional drivers are easy to port to vibe.d because of the 
blocking API - basically the only thing that has to be done is to 
replace the socket calls (send(), recv(), connect() etc.) with 
the corresponding vibe functions.
EndQuote

Can you elaborate a bit more ? Maybe using the vibe.d blog.

There is also a socket based PostgreSQL driver available, but I 
have lost the link and dunno about the status quo.

----
A MIT licenced *D2 crypto lib worth a look :
http://www.dsource.org/projects/dcrypt/wiki/Features

*not up to date

----
Whishes:
diet template documentation.
diet template javascript example
server side QR-code generation.  (well may be I am able to 
contribute)
Apr 28 2012
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 08:13, schrieb bls:

 Great job. Thanks Soenke et al;


 - Built-in support for MongoDB and Redis databases


 MySQL.
 Like other folks here I need a SQL db, At least for MyQL 5.1 there is a
 socket based solution from Steve Teale.
 https://github.com/britseye/mysqln
 Means no licence trouble, and probably easier to establish async support.


This looks like an ideal starting point. The license is of course very 
similar to the MIT license, but I would like to keep everything in the 
core library under a uniform license. Otherwise it could of course also 
be a VPM package. But in general this looks so simple to port that I 
would even just do it if no one else wants to have a shot.


 Quote
 Additional drivers are easy to port to vibe.d because of the blocking
 API - basically the only thing that has to be done is to replace the
 socket calls (send(), recv(), connect() etc.) with the corresponding
 vibe functions.
 EndQuote

 Can you elaborate a bit more ? Maybe using the vibe.d blog.


Good idea, it will put something together.


 There is also a socket based PostgreSQL driver available, but I have
 lost the link and dunno about the status quo.

 ----
 A MIT licenced *D2 crypto lib worth a look :
 http://www.dsource.org/projects/dcrypt/wiki/Features

 *not up to date


Looks nice. If it had support for SSL/TLS, we could even drop the libssl 
dependency. However, I'm currently leaning towards just wrapping 
libcrypto since we need it anyway for libssl and it's actively maintained.


 ----
 Whishes:
 diet template documentation.


This is the next point on the documentation todo list.


 diet template javascript example


I will add one. You can use something like
head
	:javascript
		function myFunction(){
			...
		}
But this was just added yesterday so you need a current GIT snapshot.


 server side QR-code generation. (well may be I am able to contribute)


Would be great. If you want, you could also make a github repository for 
this with a package.json file and I will put it into the VPM registry. 
The registry is currently still a manual process but it will be extended 
so that anyone can register and publish packages. Some features such as 
package signing are still missing for that.
Apr 29 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Sun, 29 Apr 2012 10:31:07 +0200, S=C3=B6nke Ludwig  =

<sludwig outerproduct.org> wrote:


 Quote
 Additional drivers are easy to port to vibe.d because of the blocking
 API - basically the only thing that has to be done is to replace the
 socket calls (send(), recv(), connect() etc.) with the corresponding
 vibe functions.
 EndQuote
  Can you elaborate a bit more ? Maybe using the vibe.d blog.
  Good idea, it will put something together.


Something wrong with the blog engine? The published post doesn't show in=
  =

the list, and it's cut off in the middle without any way to expand it:  =

http://vibed.org/blog/posts/writing-native-db-drivers
Apr 29 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 11:52, schrieb simendsjo:

 On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig
 <sludwig outerproduct.org> wrote:


 Quote
 Additional drivers are easy to port to vibe.d because of the blocking
 API - basically the only thing that has to be done is to replace the
 socket calls (send(), recv(), connect() etc.) with the corresponding
 vibe functions.
 EndQuote
 Can you elaborate a bit more ? Maybe using the vibe.d blog.
 Good idea, it will put something together.


 Something wrong with the blog engine? The published post doesn't show in
 the list, and it's cut off in the middle without any way to expand it:
 http://vibed.org/blog/posts/writing-native-db-drivers


It was a bug in the RSS generator. I just added the article without 
content to not forget about it but didn't publish it yet. The RSS 
generator, however, published it anyway.
Apr 29 2012
parent simendsjo <simendsjo gmail.com> writes:
On Sun, 29 Apr 2012 20:28:38 +0200, S=C3=B6nke Ludwig  =

<sludwig outerproduct.org> wrote:

 It was a bug in the RSS generator. I just added the article without  =



 content to not forget about it but didn't publish it yet. The RSS  =



 generator, however, published it anyway.


Yeah, I was pretty quick to find out how to subscribe to the RSS feed :)=
Apr 29 2012
prev sibling next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On Sun, 29 Apr 2012 08:13:40 +0200, bls <bls orange.fr> wrote:


 There is also a socket based PostgreSQL driver available, but I have  
 lost the link and dunno about the status quo.


This? https://github.com/pszturmaj/ddb
Apr 29 2012
parent "bls" <bls orange.fr> writes:
On Sunday, 29 April 2012 at 08:52:09 UTC, simendsjo wrote:

 On Sun, 29 Apr 2012 08:13:40 +0200, bls <bls orange.fr> wrote:


 There is also a socket based PostgreSQL driver available, but 
 I have lost the link and dunno about the status quo.


 This? https://github.com/pszturmaj/ddb


Exactly. Thanks for the pointer, It is pretty hard to create a 
common db- interface.
Apr 29 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 08:13, schrieb bls:

 Great job. Thanks Soenke et al;


 - Built-in support for MongoDB and Redis databases


 MySQL.
 Like other folks here I need a SQL db, At least for MyQL 5.1 there is a
 socket based solution from Steve Teale.
 https://github.com/britseye/mysqln
 Means no licence trouble, and probably easier to establish async support.

 Quote
 Additional drivers are easy to port to vibe.d because of the blocking
 API - basically the only thing that has to be done is to replace the
 socket calls (send(), recv(), connect() etc.) with the corresponding
 vibe functions.
 EndQuote

 Can you elaborate a bit more ? Maybe using the vibe.d blog.

 There is also a socket based PostgreSQL driver available, but I have
 lost the link and dunno about the status quo.

 ----
 A MIT licenced *D2 crypto lib worth a look :
 http://www.dsource.org/projects/dcrypt/wiki/Features

 *not up to date

 ----
 Whishes:
 diet template documentation.
 diet template javascript example
 server side QR-code generation. (well may be I am able to contribute)


I made a post with Steve Teale's MySQL driver as an example:
http://vibed.org/blog/posts/writing-native-db-drivers

There were some hidden gotchas, but I hope the current port doesn't 
break anything from the original code.
May 01 2012
next sibling parent reply "Matt Peterson" <ricochet1k gmail.com> writes:
On Tuesday, 1 May 2012 at 21:46:42 UTC, Sönke Ludwig wrote:

 I made a post with Steve Teale's MySQL driver as an example:
 http://vibed.org/blog/posts/writing-native-db-drivers

 There were some hidden gotchas, but I hope the current port 
 doesn't break anything from the original code.


The table in that post has no styling, which makes it a bit 
annoying to read.
May 01 2012
parent Brad Anderson <eco gnuk.net> writes:
On Tue, May 1, 2012 at 5:04 PM, Matt Peterson <ricochet1k gmail.com> wrote:


 On Tuesday, 1 May 2012 at 21:46:42 UTC, S=F6nke Ludwig wrote:


 I made a post with Steve Teale's MySQL driver as an example:
 http://vibed.org/blog/posts/**writing-native-db-drivers<http://vibed.org=




/blog/posts/writing-native-db-drivers>

 There were some hidden gotchas, but I hope the current port doesn't brea=




k

 anything from the original code.


 The table in that post has no styling, which makes it a bit annoying to
 read.


Seems to be cached.  Forcing a refresh fixed it for me.
May 01 2012
prev sibling parent reply bls <bls orange.fr> writes:
Am 01.05.2012 23:46, schrieb Sönke Ludwig:

 I made a post with Steve Teale's MySQL driver as an example:
 http://vibed.org/blog/posts/writing-native-db-drivers

 There were some hidden gotchas, but I hope the current port doesn't
 break anything from the original code.


Looks good. Unfortunately I spend some time with MongoDB and I have to 
say : Amazing db. I thought key/value databases are just toys. At least 
regarding MongoDB is was completely wrong.


I have a problem with diet templates.
In order to use dojo dijit I need :

<div class="mainlayout" id="appLayout"
        data-dojo-props="region: 'center', tabPosition: 'bottom'"
        data-dojo-type="dijit.layout.TabContainer">
</div>

Is this doable in diet templates ?
May 02 2012
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 03.05.2012 00:18, schrieb bls:

 Am 01.05.2012 23:46, schrieb Sönke Ludwig:

 I made a post with Steve Teale's MySQL driver as an example:
 http://vibed.org/blog/posts/writing-native-db-drivers

 There were some hidden gotchas, but I hope the current port doesn't
 break anything from the original code.


 Looks good. Unfortunately I spend some time with MongoDB and I have to
 say : Amazing db. I thought key/value databases are just toys. At least
 regarding MongoDB is was completely wrong.


;)


 I have a problem with diet templates.
 In order to use dojo dijit I need :

 <div class="mainlayout" id="appLayout"
 data-dojo-props="region: 'center', tabPosition: 'bottom'"
 data-dojo-type="dijit.layout.TabContainer">
 </div>

 Is this doable in diet templates ?


This line seems to work for me:
#appLayout.mainlayout(data-dojo-props="region: 'center', tabPosition: 
'bottom'", data-dojo-type="dijit.layout.TabContainer")

gives me this HTML:
<div id="appLayout" class="mainlayout" data-dojo-props="region: 

data-dojo-type="dijit.layout.TabContainer"></div>
May 03 2012
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 2 May 2012 at 22:18:12 UTC, bls wrote:

 Am 01.05.2012 23:46, schrieb Sönke Ludwig:

 I made a post with Steve Teale's MySQL driver as an example:
 http://vibed.org/blog/posts/writing-native-db-drivers

 There were some hidden gotchas, but I hope the current port 
 doesn't
 break anything from the original code.


 Looks good. Unfortunately I spend some time with MongoDB and I 
 have to say : Amazing db. I thought key/value databases are 
 just toys. At least regarding MongoDB is was completely wrong.


It does have its scaling problems, though. As soon as RAM is 
full, performance drops drastically, as it's essentially a disk 
backed in memory database.
May 03 2012
prev sibling next sibling parent reply Mirko Pilger <pilger cymotec.de> writes:
i would like to know a bit more about those "extension modules for vibe" 
and the "vpm registry". e.g. can i write yet another web framework on 
top of the vibe io modules as an "vibe extension" and would you even 
encourage this?
Apr 29 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 29.04.2012 21:57, schrieb Mirko Pilger:

 i would like to know a bit more about those "extension modules for vibe"
 and the "vpm registry". e.g. can i write yet another web framework on
 top of the vibe io modules as an "vibe extension" and would you even
 encourage this?


Essentially a VPM module nothing more that a normal library that has 
vibe.d as a dependency. It can also have additional VPM dependencies and 
can bring its own template files and resources. What you do with it is 
basically not really limited. I wouldn't say it really is a good idea to 
implement alternatives to large parts of the existing libraries, as that 
would just fragment everything (->tango/phobos). But in general its 
definitely possible.

Currently VPM modules should just adhere to the structure in 
http://vibed.org/docs#first-steps and have to have an additional URL 
field in the package.json with a direct download link (at least for now 
it must be a github repository zipball link). I can then put it manually 
into the registry so that anyone automatically gets it as soon as some 
project adds it as a dependency.

A proper user inferface for registry.vibed.org is planned as the next 
step, as well as TAG support for github repositories to mark release 
versions.
Apr 29 2012
prev sibling next sibling parent reply "bls" <bls orange.fr> writes:
Seems that my last reply was jammned or whatever .. so in short
x509 certificate support...  Why not ?

SOAP/WSDL
SOAP service consuming is what makes my bread and butter nowadays 
but
to face it : Parsing a WSDL stream sucks
Creating a SOAP service in D is .... Ouch..  Consuming a 
SOAP/WSDL in D is  super...... anyway,  Smart Devices are not 
realy interested in SOAP/WSDL...
Means Vibe.d should support REST out of the box.

I hope that you give ---- Interface to REST ------ 
(code-gen-wise) a try..
Bjoern
Apr 29 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 29.04.2012 23:41, schrieb bls:

 Seems that my last reply was jammned or whatever .. so in short
 x509 certificate support... Why not ?


Do you mean for SSL or package signing or something else? They are 
currently used for SSL, but currently there is no certificate validation 
on the client side.


 SOAP/WSDL
 SOAP service consuming is what makes my bread and butter nowadays but
 to face it : Parsing a WSDL stream sucks
 Creating a SOAP service in D is .... Ouch.. Consuming a SOAP/WSDL in D
 is super...... anyway, Smart Devices are not realy interested in
 SOAP/WSDL...
 Means Vibe.d should support REST out of the box.

 I hope that you give ---- Interface to REST ------ (code-gen-wise) a try..
 Bjoern


If you mean automatic generation of a REST interface for an existing D 
interface, then it's definitely planned. I can imagine a sloppy version 
where the HTTP method is always POST or can be POST/GET as desired by 
the client. But I would also like to have a more expressive version, 
where the HTTP method is inferred from the D method somehow and maybe it 
would also be possible to specify a sub path for each method.

Sönke
Apr 29 2012
parent reply bls <bls orange.fr> writes:
Am 30.04.2012 08:38, schrieb Sönke Ludwig:

 If you mean automatic generation of a REST interface for an existing D
 interface, then it's definitely planned. I can imagine a sloppy version
 where the HTTP method is always POST or can be POST/GET as desired by
 the client. But I would also like to have a more expressive version,
 where the HTTP method is inferred from the D method somehow and maybe it
 would also be possible to specify a sub path for each method.

 Sönke


Yes, this is what I am asking for. I think POST/GET is not enough.

Should be POST GET PUT DELETE

I would be fantastic if vibe.d can implement a REST SERVER following 
this guideline :

The JsonRestStore follows
RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt) whenever possible to 
define to interaction with server. JsonRestStore uses an HTTP GET 
request to retrieve data, a PUT request to change items, a DELETE 
request to delete items, and a POST request to create new items. It is 
recommended that the server follow a URL structure for resources:

     /{Table}/{id}

This URL will be used to retrieve items by identity and make 
modifications (PUT and DELETE). It is also recommended that a /{Table}/ 
URL is used to represent the collection of items for the store. When a 
query is performed, any query string is appended to the target URL to 
retrieve the results of the query. The JsonRestStore expects the results 
to be returned in an array (not in an object with an items property like 
some stores). The store will also POST to that URL to create new items.

When creating new items, the JsonRestStore will POST to the target URL 
for the store. If your server wants to assign the URL/location for the 
newly created item, it can do so by including a Location header in the 
response:

     Location: http://mysite.com/Table/newid

The server can also assign or change properties of the object (such an 
id or default values) in the response to a POST (or any other request), 
by simply returning the updated JSON representation of the item in the 
body of the response.

Note that in PHP, sometimes setting the Location will erroneously 
trigger a 302 status code which will cause JsonRestStore to fail. Per 
RFC 2616, the correct response to a POST that creates a new resource is 
to return a 201 status code with the Location header. In PHP, you must 
set the status code as well as the Location header if you want to avoid 
a 302 response.
May 03 2012
next sibling parent bls <bls orange.fr> writes:
Am 03.05.2012 11:22, schrieb bls:

 Should be POST GET PUT DELETE

 I would be fantastic if vibe.d can implement a REST SERVER following
 this guideline :


A very interesting read regarding implementing a rest server (PHP)

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Bjoern
May 03 2012
prev sibling next sibling parent "Chris NS" <ibisbasenji gmail.com> writes:
I've been playing around with vibe in my free time the last few 
days, and here are the beginnings of a stab at REST:
https://github.com/csauls/zeal.d/blob/master/source/zeal/http/router.d

Admittedly it rips off the Rails way of recognizing and pathing 
the REST actions, but I admit a small bias as someone who uses 
Rails often.  That said, I've been trying to dream up a "more 
D-like" way to do it.
May 03 2012
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 3 May 2012 at 09:22:23 UTC, bls wrote:

 Should be POST GET PUT DELETE


I'm afraid, some proxies may cut unusual http verbs. SVN relies 
on them and if a proxy is not nice, it gets broken.
May 03 2012
parent reply "James Miller" <james aatch.net> writes:
I'm currently building a site in vibe and love it. There are 
still a few bugs around, and a few useful features to come, but 
I've been patching and writing features as I go, so its all good.

I am curious about your policy on big features though, I have 
been working an implementation for using forms simply. Its 
nowhere near being ready for release yet, but is it the kind of 
thing you'd want as a module, or as a part of the main vibe 
codebase? There are also a lot of more producing-friendly 
features that could be done (IOW, allowing fine-grained 
configuration of server params, and supporting 8 different 
load-balancing schemes is great, but doesn't help me produce a 
website...), would they be mostly modules, or more core parts?

--
James Miller
May 06 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 07.05.2012 01:12, schrieb James Miller:

 I'm currently building a site in vibe and love it. There are still a few
 bugs around, and a few useful features to come, but I've been patching
 and writing features as I go, so its all good.

 I am curious about your policy on big features though, I have been
 working an implementation for using forms simply. Its nowhere near being
 ready for release yet, but is it the kind of thing you'd want as a
 module, or as a part of the main vibe codebase? There are also a lot of
 more producing-friendly features that could be done (IOW, allowing
 fine-grained configuration of server params, and supporting 8 different
 load-balancing schemes is great, but doesn't help me produce a
 website...), would they be mostly modules, or more core parts?

 --
 James Miller


I think one of us (Jan) has something for better form handling locally, 
not yet committed, and I would count that as something that would still 
fit well into the core package. But in general, I think the number of 
features should not grow too much anymore - the core should contain all 
that is necessary for _most_ applications and that with an interface 
that is as comfortable as possible.

The main scope of modules, I would say, are higher level features, 
features that are not as widely used or those which provide alternatives 
to the functions in the core library. Basic, common functionality, 
however, is always a candidate for the core (OAuth(2) is on the way for 
example).

Another - quite banal - criterion could be if we would actually use a 
feature ourselves, at least a bit; simply because if we don't use it, we 
cannot test it without further time investments and it could be unclear 
(to us) how well such a component actually works (e.g. wrt. stable 
releases). Also, the implementation/API style of a feature should match 
the rest of the core library. The MySQL driver would be an example that 
currently fails both criterions and thus is a module.

Maybe it would also be good to establish a defined procedure such as: 
New features are implemented as modules first and after a review it's 
decided if they should go in for the next release. I don't have a real 
opinion on this yet and I'm basically completely open for suggestions.
May 07 2012
parent "James Miller" <james aatch.net> writes:
On Monday, 7 May 2012 at 18:51:26 UTC, Sönke Ludwig wrote:

 I think one of us (Jan) has something for better form handling 
 locally, not yet committed, and I would count that as something 
 that would still fit well into the core package. But in 
 general, I think the number of features should not grow too 
 much anymore - the core should contain all that is necessary 
 for _most_ applications and that with an interface that is as 
 comfortable as possible.

 The main scope of modules, I would say, are higher level 
 features, features that are not as widely used or those which 
 provide alternatives to the functions in the core library. 
 Basic, common functionality, however, is always a candidate for 
 the core (OAuth(2) is on the way for example).

 Another - quite banal - criterion could be if we would actually 
 use a feature ourselves, at least a bit; simply because if we 
 don't use it, we cannot test it without further time 
 investments and it could be unclear (to us) how well such a 
 component actually works (e.g. wrt. stable releases). Also, the 
 implementation/API style of a feature should match the rest of 
 the core library. The MySQL driver would be an example that 
 currently fails both criterions and thus is a module.

 Maybe it would also be good to establish a defined procedure 
 such as: New features are implemented as modules first and 
 after a review it's decided if they should go in for the next 
 release. I don't have a real opinion on this yet and I'm 
 basically completely open for suggestions.


Sound good, now I'm just hoping that porting my forms stuff to 
the core forms isn't going to be too hard :D.

Otherwise it seems you have a rough idea of what constitutes a 
module and what is a feature, and that is a good start. I think 
an informal review process for module -> feature promotion would 
be good, since then the code can be available for use earlier. 
Also, there is something to be said for making "official" vibe 
modules, ones maintained, or at least, approved by the vibe team 
and given slightly more prominence. This can keep the core system 
small, but still allow the vibe team to provide more 
functionality, especially if it is common functionality.

--
James Miller
May 08 2012
prev sibling next sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
How do a manual install on linux ?
I am a fedora user they are no specialized or common install
documentation!
May 19 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 19.05.2012 12:50, schrieb bioinfornatics:

 How do a manual install on linux ?
 I am a fedora user they are no specialized or common install
 documentation!


Something like

yum install libevent-devel
yum install openssl-devel

instead of "apt-get install libevent-dev openssl-dev" should work. You 
then only need dmd (with rdmd) installed and unzip or git clone vibe. 
You can then optionally put a symbolic link in /usr/bin:

ln -s /path/to/vibe/bin/vibe /usr/bin/vibe

Hope this helps.

(if it does, I will add it as instructions to the README)
May 19 2012
prev sibling parent reply "Alexandre Riveira" <alexandre objectdata.com.br> writes:
Hi Sönke,


Congratulations for your hard work.


One question,
How do you think your framework running in development mode where 
a huge amount of models with many business rules exist. A system 
under development can be slow, like java where a signature change 
in the method requires reload of the whole application.

Alexandre Riveira


On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

  - Very fast but no endless callback chains as in node.js
    and similar frameworks
  - Concise API that tries to be as efficient and intuitive
    as possible
  - Built-in HTTP server and client with support for HTTPS,
    chunked and compressed transfers, keep-alive connections,
    Apache-style logging, a reverse-proxy, url routing and
    more
  - Jade based HTML/XML template system with compile-time
    code generation for the fastest dynamic page generation
    times possible
  - Built-in support for MongoDB and Redis databases
  - WebSocket support
  - Natural Json and Bson handling
  - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke
Nov 04 2013
next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira
wrote:

 Hi Sönke,


 Congratulations for your hard work.


 One question,
 How do you think your framework running in development mode 
 where a huge amount of models with many business rules exist. A 
 system under development can be slow, like java where a 
 signature change in the method requires reload of the whole 
 application.

 Alexandre Riveira


Alexandre,
Vibe.D now has its own forum, might be a better place to post
your question.

http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/



 On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

 - Very fast but no endless callback chains as in node.js
   and similar frameworks
 - Concise API that tries to be as efficient and intuitive
   as possible
 - Built-in HTTP server and client with support for HTTPS,
   chunked and compressed transfers, keep-alive connections,
   Apache-style logging, a reverse-proxy, url routing and
   more
 - Jade based HTML/XML template system with compile-time
   code generation for the fastest dynamic page generation
   times possible
 - Built-in support for MongoDB and Redis databases
 - WebSocket support
 - Natural Json and Bson handling
 - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke
Nov 04 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira 
wrote:

 Hi Sönke,


 Congratulations for your hard work.


 One question,
 How do you think your framework running in development mode 
 where a huge amount of models with many business rules exist. A 
 system under development can be slow, like java where a 
 signature change in the method requires reload of the whole 
 application.

 Alexandre Riveira


I might recommend to wait a bit before trying it in production 
until CI suite is figured out (it is work in progress), there are 
some concerns with stability/regressions right now because it 
grows just too fast.

Once this stuff is back under control though, there is no reason 
why it shouldn't scale to complex business logic scenarios. It 
may require writing own modules for something like XML-based 
configuration or similar Java-ish stuff as vibe.d itself is more 
declarative / procedural in style but foundation is pretty solid.

I also recommend asking more specific questions in vibe.d own 
newsgroup as Sonke pays more attention to it, he is obviously 
quite a busy guy :)
Nov 04 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 04.11.2013 18:35, schrieb Dicebot:

 On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote:

 Hi Sönke,


 Congratulations for your hard work.


 One question,
 How do you think your framework running in development mode where a
 huge amount of models with many business rules exist. A system under
 development can be slow, like java where a signature change in the
 method requires reload of the whole application.

 Alexandre Riveira


 I might recommend to wait a bit before trying it in production until CI
 suite is figured out (it is work in progress), there are some concerns
 with stability/regressions right now because it grows just too fast.


Seconded, some parts are still moving fast and some parts still don't 
have good enough test coverage. And while it can already be used for 
many production tasks when used with some care, I wouldn't suggest to 
start a million+ user service in the next 6 months or so, before a 
rigorous regression free stabilization process is in effect.
Nov 05 2013
parent "Alexandre Riveira" <alexandre objectdata.com.br> writes:
Hi Sönke,

My concern is actually in development time. Compilation, 
debugging, etc.. Ruby on rails applications had their reload 
classes optimized effecting only reload the classes changed 
instead of the entire environment. Today we have the application 
of ERP type integrated e-commerce with 342 models, reload wait 
around this set can be a really time consuming process for 
development.

I appreciate your work, appreciate languagem d, successful 
community



On Tuesday, 5 November 2013 at 15:35:19 UTC, Sönke Ludwig wrote:

 Am 04.11.2013 18:35, schrieb Dicebot:

 On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira 
 wrote:

 Hi Sönke,


 Congratulations for your hard work.


 One question,
 How do you think your framework running in development mode 
 where a
 huge amount of models with many business rules exist. A 
 system under
 development can be slow, like java where a signature change 
 in the
 method requires reload of the whole application.

 Alexandre Riveira


 I might recommend to wait a bit before trying it in production 
 until CI
 suite is figured out (it is work in progress), there are some 
 concerns
 with stability/regressions right now because it grows just too 
 fast.


 Seconded, some parts are still moving fast and some parts still 
 don't have good enough test coverage. And while it can already 
 be used for many production tasks when used with some care, I 
 wouldn't suggest to start a million+ user service in the next 6 
 months or so, before a rigorous regression free stabilization 
 process is in effect.
Nov 05 2013
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Hi Alexandre,

I'll try to answer as good as I can, please excuse if I got part of your 
question wrong. So I see two parts that can be slow:

1. The application runtime performance. Due to additional debug checks 
and less optimization, debug builds will run slower than release builds, 
but this usually gets important only for very high load scenarios for 
typical vibe.d/D applications. So this is usually nothing to worry about 
during development. If, however, a release build is required to get 
acceptable performance, it can easily double the build time.

2. The edit->compile->run->test cycle during development. This will be 
similar to Java in that it will usually require the whole application to 
be rebuilt and restarted. Building a vibe.d application currently takes 
about 12 s for most applications. It can get much slower, though, if the 
application makes heavy use of templates or compile-time function 
execution (this is the case for Diet templates [1], for example).

    Having said that, there are ways to get around this in certain 
situations. At least on Linux (on DMD 2.064 and up) this is now possible 
relatively easily using core.runtime.Runtime.loadLibrary. Using that, 
individual components can be built as small shared libraries and loaded 
dynamically into the running process. Remedy Entertainment has done 
something similar before Runtime.loadLibrary was available [2].

Best regards,
Sönke

[1]: http://vibed.org/docs#html-templates
[2]: http://www.youtube.com/watch?v=FKceA691Wcg


Am 04.11.2013 17:40, schrieb Alexandre Riveira:

 Hi Sönke,


 Congratulations for your hard work.


 One question,
 How do you think your framework running in development mode where a huge
 amount of models with many business rules exist. A system under
 development can be slow, like java where a signature change in the
 method requires reload of the whole application.

 Alexandre Riveira


 On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:

 During the last few months, we have been working on a new
 framework for general I/O and especially for building
 extremely fast web apps. It combines asynchronous I/O with
 core.thread's great fibers to build a convenient, blocking
 API which can handle insane amounts of connections due to
 the low memory and computational overhead.

 Some of its key fatures are:

  - Very fast but no endless callback chains as in node.js
    and similar frameworks
  - Concise API that tries to be as efficient and intuitive
    as possible
  - Built-in HTTP server and client with support for HTTPS,
    chunked and compressed transfers, keep-alive connections,
    Apache-style logging, a reverse-proxy, url routing and
    more
  - Jade based HTML/XML template system with compile-time
    code generation for the fastest dynamic page generation
    times possible
  - Built-in support for MongoDB and Redis databases
  - WebSocket support
  - Natural Json and Bson handling
  - A package manager for seemless use of extension libraries

 See http://vibed.org/ for more information and some example
 applications (there are some things in the works such as an
 etherpad clone and an NNTP server).

 vibe.d is in a working state and enters its first beta-phase
 now to stabilize the current feature set. After that, a
 small list of additional features is planned before the 1.0
 release.

 The framework can be downloaded or GIT cloned from
 http://vibed.org/ and is distributed under the terms of the
 MIT license.

 Note that the website including the blog is fully written
 in vibe and provides the first stress test for the
 implementation.

 Regards,
 Sönke
Nov 05 2013