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.

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 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
next sibling 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
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
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 =?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
prev sibling 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 next sibling parent 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

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




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

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. =20 Andrei

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

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

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
prev sibling next sibling parent 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

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

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
prev sibling 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 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

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



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.

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

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
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 =?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 =?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 =?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 =?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 "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
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

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 =?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
prev sibling 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 next 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 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=

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
prev sibling next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
--e89a8f64715bee2ad404bec1a588
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

usage went up from 32MB to about 44MB. After 24h and about 50k requests i=

 stays at 43.5MB. Real memory usage is 15MB.

--e89a8f64715bee2ad404bec1a588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Awesome! that was one of my concerns with D in general with server software= and its long running nature.<br> I&#39;ve been thinking about fibers and socket.d this week. Glad you anounc= ed this before I started working on something :D.<div><br></div><div>How di= fficult would it be for you to split the async IO parts into a separate lib= rary? This would be very much like gevent (python: <a href=3D"http://www.ge= vent.org/">http://www.gevent.org/</a>).</div> <div><br></div><div>Any chance of supporting WSGI?<br><br><div class=3D"gma= il_quote">On Sat, Apr 28, 2012 at 2:36 PM, S=C3=B6nke Ludwig <span dir=3D"l= tr">&lt;<a href=3D"mailto:sludwig outerproduct.org" target=3D"_blank">sludw= ig outerproduct.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Am <a href=3D"tel:27.04.2012%2011" value=3D"= +12704201211" target=3D"_blank">27.04.2012 11</a>:34, schrieb S=C3=B6nke Lu= dwig:<div class=3D"im"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I&#39;m starting to monitor it now. Directly after startup, the website is<= br> at 32 MB. The traffic has dropped a bit but hopefully it&#39;s enough to se= e<br> something if there is a hidden leak.<br> <br> </blockquote> <br></div> A mid-term test now shows that shortly after startup the virtual memory usa= ge went up from 32MB to about 44MB. After 24h and about 50k requests it sta= ys at 43.5MB. Real memory usage is 15MB.<br> </blockquote></div><br></div> --e89a8f64715bee2ad404bec1a588--
Apr 28 2012
prev sibling parent Rory McGuire <rjmcguire gmail.com> writes:
--e89a8fb201706317d004bee1a37c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=

 of the code adding overhead of any kind.

Thanks. I wonder how vibe.d performs vs a gevent based web server. --e89a8fb201706317d004bee1a37c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Apr 30, 2012 at 9:57 AM, S=C3=B6nke Ludw= ig <span dir=3D"ltr">&lt;<a href=3D"mailto:sludwig outerproduct.org" target= =3D"_blank">sludwig outerproduct.org</a>&gt;</span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"><br> How difficult would it be for you to split the async IO parts into a<br> separate library? This would be very much like gevent (python:<br> <a href=3D"http://www.gevent.org/" target=3D"_blank">http://www.gevent.org/= </a>).<br> </blockquote> <br></div> That would basically be vibe.core and vibe.stream. Those have no dependenci= es to other modules so they can already be used without the rest of the cod= e adding overhead of any kind.</blockquote><div><br></div><div>Thanks.</div=

er.=C2=A0</div><div><br></div></div> --e89a8fb201706317d004bee1a37c--
Apr 30 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 "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
prev sibling next sibling parent 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
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 =?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 :)

 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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
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 "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
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 "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 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

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
next sibling 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 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.


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 parent "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.


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
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 =?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
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
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
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: &#39;center&#39;, tabPosition: &#39;bottom&#39;" data-dojo-type="dijit.layout.TabContainer"></div>
May 03 2012
prev sibling next sibling parent 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
prev sibling next sibling parent 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
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 "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 next sibling 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 "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 parent =?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
prev sibling next sibling 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

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.

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 "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
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--bcaec554e0f8ea274904bf026594
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=


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


 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. --bcaec554e0f8ea274904bf026594 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 1, 2012 at 5:04 PM, Matt Peterson <span dir=3D"ltr">&lt;<a href= =3D"mailto:ricochet1k gmail.com" target=3D"_blank">ricochet1k gmail.com</a>= &gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im">On Tuesday, 1 May 2012 at 21:46:42 UTC, S=F6nke Ludwig wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I made a post with Steve Teale&#39;s MySQL driver as an example:<br> <a href=3D"http://vibed.org/blog/posts/writing-native-db-drivers" target=3D= "_blank">http://vibed.org/blog/posts/<u></u>writing-native-db-drivers</a><b= r> <br> There were some hidden gotchas, but I hope the current port doesn&#39;t bre= ak anything from the original code.<br> </blockquote> <br></div> The table in that post has no styling, which makes it a bit annoying to rea= d.<br> </blockquote></div><br><div>Seems to be cached. =A0Forcing a refresh fixed = it for me.</div> --bcaec554e0f8ea274904bf026594--
May 01 2012
prev sibling next 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.

full, performance drops drastically, as it's essentially a disk backed in memory database.
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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