Re: Introducing vibe.d!
Hi Alexandre, I'll try to answer as good as I can, please excuse if I got part of your question wrong. So I see two parts that can be slow: 1. The application runtime performance. Due to additional debug checks and less optimization, debug builds will run slower than release builds, but this usually gets important only for very high load scenarios for typical vibe.d/D applications. So this is usually nothing to worry about during development. If, however, a release build is required to get acceptable performance, it can easily double the build time. 2. The edit-compile-run-test cycle during development. This will be similar to Java in that it will usually require the whole application to be rebuilt and restarted. Building a vibe.d application currently takes about 12 s for most applications. It can get much slower, though, if the application makes heavy use of templates or compile-time function execution (this is the case for Diet templates [1], for example). Having said that, there are ways to get around this in certain situations. At least on Linux (on DMD 2.064 and up) this is now possible relatively easily using core.runtime.Runtime.loadLibrary. Using that, individual components can be built as small shared libraries and loaded dynamically into the running process. Remedy Entertainment has done something similar before Runtime.loadLibrary was available [2]. Best regards, Sönke [1]: http://vibed.org/docs#html-templates [2]: http://www.youtube.com/watch?v=FKceA691Wcg Am 04.11.2013 17:40, schrieb Alexandre Riveira: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke
Re: Introducing vibe.d!
Am 04.11.2013 18:35, schrieb Dicebot: On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Seconded, some parts are still moving fast and some parts still don't have good enough test coverage. And while it can already be used for many production tasks when used with some care, I wouldn't suggest to start a million+ user service in the next 6 months or so, before a rigorous regression free stabilization process is in effect.
Re: Introducing vibe.d!
Hi Sönke, My concern is actually in development time. Compilation, debugging, etc.. Ruby on rails applications had their reload classes optimized effecting only reload the classes changed instead of the entire environment. Today we have the application of ERP type integrated e-commerce with 342 models, reload wait around this set can be a really time consuming process for development. I appreciate your work, appreciate languagem d, successful community On Tuesday, 5 November 2013 at 15:35:19 UTC, Sönke Ludwig wrote: Am 04.11.2013 18:35, schrieb Dicebot: On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Seconded, some parts are still moving fast and some parts still don't have good enough test coverage. And while it can already be used for many production tasks when used with some care, I wouldn't suggest to start a million+ user service in the next 6 months or so, before a rigorous regression free stabilization process is in effect.
Re: Introducing vibe.d!
Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke
Re: Introducing vibe.d!
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira Alexandre, Vibe.D now has its own forum, might be a better place to post your question. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke
Re: Introducing vibe.d!
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Once this stuff is back under control though, there is no reason why it shouldn't scale to complex business logic scenarios. It may require writing own modules for something like XML-based configuration or similar Java-ish stuff as vibe.d itself is more declarative / procedural in style but foundation is pretty solid. I also recommend asking more specific questions in vibe.d own newsgroup as Sonke pays more attention to it, he is obviously quite a busy guy :)
Re: Introducing vibe.d!
How do a manual install on linux ? I am a fedora user they are no specialized or common install documentation!
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d! SOAP .. REST?
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.
Re: Introducing vibe.d! SOAP .. REST?
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
Re: Introducing vibe.d!
On Wednesday, 2 May 2012 at 22:18:12 UTC, bls wrote: Am 01.05.2012 23:46, schrieb Sönke Ludwig: I made a post with Steve Teale's MySQL driver as an example: http://vibed.org/blog/posts/writing-native-db-drivers There were some hidden gotchas, but I hope the current port doesn't break anything from the original code. Looks good. Unfortunately I spend some time with MongoDB and I have to say : Amazing db. I thought key/value databases are just toys. At least regarding MongoDB is was completely wrong. It does have its scaling problems, though. As soon as RAM is full, performance drops drastically, as it's essentially a disk backed in memory database.
Re: Introducing vibe.d! SOAP .. REST?
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.
Re: Introducing vibe.d! SOAP .. REST?
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.
Re: Introducing vibe.d!
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 ?
Re: Introducing vibe.d!
Am Mon, 30 Apr 2012 15:52:36 -0700 schrieb Sean Kelly s...@invisibleduck.org: On Apr 30, 2012, at 8:26 AM, Sönke Ludwig wrote: 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. 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).
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
On Tue, May 1, 2012 at 5:04 PM, Matt Peterson ricoche...@gmail.com wrote: 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-drivershttp://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. Seems to be cached. Forcing a refresh fixed it for me.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d! SOAP .. REST?
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
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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 slud...@outerproduct.org mailto:slud...@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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
On Mon, Apr 30, 2012 at 9:57 AM, Sönke Ludwig slud...@outerproduct.orgwrote: 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. Thanks. I wonder how vibe.d performs vs a gevent based web server.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote: On 2012-04-30 09:00, Sönke Ludwig wrote: They will also soon wonder why they cannot put top-level code in their other files. Yeah, I guess that will most likely be a problem. Also, doesn't ImportExpression require passing -J to the compiler? That'd potentially only add another source of confusion for newcomers. David
Re: Introducing vibe.d!
On 2012-04-30 13:05, David Nadlinger wrote: On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote: On 2012-04-30 09:00, Sönke Ludwig wrote: They will also soon wonder why they cannot put top-level code in their other files. Yeah, I guess that will most likely be a problem. Also, doesn't ImportExpression require passing -J to the compiler? That'd potentially only add another source of confusion for newcomers. David You're correct, it does. -- /Jacob Carlborg
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
On Mon, 30 Apr 2012 17:26:54 +0200, Sönke Ludwig slud...@outerproduct.org wrote: 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. Yup, pretty annoying. Use addr2line.
Re: Introducing vibe.d!
On Apr 30, 2012, at 8:26 AM, Sönke Ludwig wrote: 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. 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.
Re: Introducing vibe.d!
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)
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 08:13:40 +0200, bls b...@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
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig slud...@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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
Am 29.04.2012 11:52, schrieb simendsjo: On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig slud...@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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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?
Re: Introducing vibe.d!
On Sunday, 29 April 2012 at 08:52:09 UTC, simendsjo wrote: On Sun, 29 Apr 2012 08:13:40 +0200, bls b...@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.
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 20:28:38 +0200, Sönke Ludwig slud...@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 :)
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
[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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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önke Ludwig slud...@outerproduct.orgwrote: 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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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?
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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(htmlheadtitle); 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
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
Sönke Ludwig slud...@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.
Re: Introducing vibe.d!
Am 27.04.2012 11:06, schrieb Nick Sabalausky: Sönke Ludwigslud...@outerproduct.org wrote in message news:jndl9l$26eh$1...@digitalmars.com... We still have a more comprehensive benchmark on the table but it seemed to get along happily with about 60MB of RAM usage during a C10k test. The average request time went down to about 6s if I remember correctly. The test was using a dual-core Atom server over a WiFI connection so the results may have been skewed a litte. I guess I don't have much of a frame of reference, but that certainly sounds very impressive. Especially the RAM usage (you could probably kill lighttpd, from what I've heard about it) and also the fact that was all over WiFi. Have you looked at long-term memory usage? I wonder if D's imprecise GC could be a liability and would need to be ? I'm starting to monitor it now. Directly after startup, the website is at 32 MB. The traffic has dropped a bit but hopefully it's enough to see something if there is a hidden leak. After the C10k test, the memory usage dropped back to normal if I remember right so there should be nothing too bad in the core. In terms of HTTP/1.1 implementation it is most importantly lacking multipart form uploads (will be added shortly). Otherwise the protocol supports most HTTP features. I'll put a more detailed comparison on my TODO list. Thanks, I'm anxious to take a look. I'm particulary curious how much of your intended scope does/doesn't overlap with Nginx's domain and it's (rather Apache-competetive) suite of modules: http://wiki.nginx.org/Modules From going just over the module index, the features that are in or planned are: - most of Core is there - Basic auth - check - Auto index - part of a separate library that is still in dev. - FastCGI client is planned, possible also a server - Gzip responses (the static file server componen does this) - Headers - check - Limit Requests/Zone is planned - Limit Conn is planned - Log - check - Proxy - check - scgi - maybe instead of FastCGI - Split Clients - easy to do programmatically - Upstream - planned - SSL - check - WebDAV - planned - simplistic SMTP - check Do you see this as eventually (or even currently) competing with Nginx in general? Or is it more focused on web framework and general async I/O? (Actually that's another thing, how general is the async I/O in it? Is it intended to be used for just...whatever general I/O uses...or is it more intended as a means-to-an-end for web?) The way it's designed, I suppose the features of many of Nginx's modules could simply be implemented using vibed, for example directory listings. In general it's more a general application framework or an extension library. But a stand-alone webserver would be an easy project - nothing that I have directly planned myself though. The I/O is supposed to be as general as possible. Right now the focus has been on web applications but we also plan a desktop application that is going to use it for all of its I/O. For this I'm also looking into how to integrate the event loop with the OS message queue efficiently on all platforms. There are still some things missing for the libevent driver but with the upcoming libuv driver everything that libuv provides should be available.
Re: Introducing vibe.d!
Am 27.04.2012 10:26, schrieb Andrej Mitrovic: On 4/27/12, Sönke Ludwigslud...@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.
Re: Introducing vibe.d!
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?).
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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?
Re: Introducing vibe.d!
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);
});
Re: Introducing vibe.d!
Am 27.04.2012 13:07, schrieb Puming: Excellent work Sönke! Vibe.d seems very promising :) Thanks :) I've played with vibe.d with a hello project as described in the document, and downloaded vibenotes and vibeblog from git and poked around a little. vibe.d gives me a very smooth experience, and I'll try learn about it more :) two little things to note: 1. In the tutorial it didn't say how to start vibe.d project. I spent some minutes to find it: by running vibe at the root of a project. Maybe its clear to state that in the tutorial It definitely needs some improvements. My idea would be to change it to a step-by-step tutorial and also add support for something like vibe init appname to generate the basic app skeleton. 2. It seems that diet templates doesn't support soft tab. I looked into the code, and in indentLevel(line) it only dectects '\t'. Will vibe.d support soft tab? I put an item in the TODO list to detect the indent style from the first indented line. This indent style would then be used for the rest of the document.
Re: Introducing vibe.d!
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!
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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..
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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);
Re: Introducing vibe.d!
In _d_throw call abort(). That'll give you a core file. On Apr 26, 2012, at 11:13 PM, Sönke Ludwig slud...@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.
Re: Introducing vibe.d!
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 Ludwigslud...@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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
On Apr 27, 2012, at 1:27 AM, Sönke Ludwig slud...@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?
Re: Introducing vibe.d!
Am 27.04.2012 18:54, schrieb Sean Kelly: On Apr 27, 2012, at 1:27 AM, Sönke Ludwigslud...@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 1 connections concurrently.. not exactly sure who is reposible but probably either the network or libevent. But some diagnostic benchmarking is in order.
Re: Introducing vibe.d!
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!
Re: Introducing vibe.d!
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()!
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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?
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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...
Re: Introducing vibe.d!
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...
Re: Introducing vibe.d!
Wow, thanks :) Definately going to play with it.
Re: Introducing vibe.d!
Am 26.04.2012 23:18, schrieb ponce: Wow, thanks :) Definately going to play with it. Same here, I think using vibe with nginx as reverse proxy will work great!
Re: Introducing vibe.d!
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?
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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/
Re: Introducing vibe.d!
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.
Re: Introducing vibe.d!
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.
