www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe.d 0.7.9 released

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Changes:

 - New HTML form interface generator similar to the REST interface
   generator that simplifies web front end development:
   http://vibed.org/api/vibe.http.form/registerFormInterface
   (thanks to Robert Klotzner aka eskimor)

 - Diet HTML templates now support includes and recursive
   blocks/extensions

 - The REST interface generator has got a new method to reference types
   in the generated string mixin, which makes it more robust to user
   defined types (thanks to Mihail Stra¨un aka mist)

 - Now includes API docs for offline viewing

 - A lot of small fixes and improvements


Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9

Download: http://vibed.org/download?file=vibed-0.7.9.zip
Oct 30 2012
next sibling parent "Tavi Cacina" <octavian.cacina outlook.com> writes:
cool, keep up the good work!
Oct 31 2012
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 31/10/12 07:59, En/na S=C3=B6nke Ludwig ha escrit:

 Changes:
=20
  - New HTML form interface generator similar to the REST interface
    generator that simplifies web front end development:
    http://vibed.org/api/vibe.http.form/registerFormInterface
    (thanks to Robert Klotzner aka eskimor)
=20
  - Diet HTML templates now support includes and recursive
    blocks/extensions
=20
  - The REST interface generator has got a new method to reference types=



    in the generated string mixin, which makes it more robust to user
    defined types (thanks to Mihail Stra=C5=A1un aka mist)
=20
  - Now includes API docs for offline viewing
=20
  - A lot of small fixes and improvements
=20
=20
 Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9
=20
 Download: http://vibed.org/download?file=3Dvibed-0.7.9.zip
=20


Congratulations for this new release!

New deb packages for vibe v0.7.9 available at https://code.google.com/p/d=
-apt/

--=20
Jordi Sayol
Oct 31 2012
parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On 2012-10-31 12:30, Jordi Sayol wrote:


 
 Congratulations for this new release!
 
 New deb packages for vibe v0.7.9 available at https://code.google.com/p/d-apt/
 


When I make an apt-get update I get.


W: Failed to fetch http://d-apt.googlecode.com/files/Release  Unable to
find expected entry 'Sources' in Release file (Wrong sources.list entry
or malformed file)

I anyone else getting this ?
Nov 07 2012
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 07/11/12 11:24, En/na Knud Soerensen ha escrit:

 On 2012-10-31 12:30, Jordi Sayol wrote:
 

 Congratulations for this new release!

 New deb packages for vibe v0.7.9 available at https://code.google.com/p/d-apt/


 
 When I make an apt-get update I get.
 
 
 W: Failed to fetch http://d-apt.googlecode.com/files/Release  Unable to
 find expected entry 'Sources' in Release file (Wrong sources.list entry
 or malformed file)
 
 I anyone else getting this ?
 


d-apt do not have debianized source packages.

Try to comment or delete the line "deb-src http://d-apt.googlecode.com/files /"
in "/etc/apt/sources.list" file, or in any file inside
"/etc/apt/sources.list.d/" directory.

Regards,
-- 
Jordi Sayol
Nov 07 2012
parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On 2012-11-07 11:59, Jordi Sayol wrote:

 Al 07/11/12 11:24, En/na Knud Soerensen ha escrit:

 On 2012-10-31 12:30, Jordi Sayol wrote:


 Congratulations for this new release!

 New deb packages for vibe v0.7.9 available at https://code.google.com/p/d-apt/


 When I make an apt-get update I get.


 W: Failed to fetch http://d-apt.googlecode.com/files/Release  Unable to
 find expected entry 'Sources' in Release file (Wrong sources.list entry
 or malformed file)

 I anyone else getting this ?


 
 d-apt do not have debianized source packages.
 
 Try to comment or delete the line "deb-src http://d-apt.googlecode.com/files
/" in "/etc/apt/sources.list" file, or in any file inside
"/etc/apt/sources.list.d/" directory.
 
 Regards,
 


Thanks, that worked.

-- 
Join me on
Skype	   knudhs
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Twitter    http://twitter.com/knudsoerensen
bitcoin donations: 13ofyUKqFL43uRJHZtNozyMVP4qxKPsAR2
Nov 07 2012
prev sibling next sibling parent "mist" <none none.none> writes:
AUR package updated:
https://aur.archlinux.org/packages.php?ID=61679
Oct 31 2012
prev sibling next sibling parent reply "Rob T" <rob ucora.com> writes:
On Wednesday, 31 October 2012 at 06:59:45 UTC, Sönke Ludwig 
wrote:

 Changes:

  - New HTML form interface generator similar to the REST 
 interface
    generator that simplifies web front end development:
    http://vibed.org/api/vibe.http.form/registerFormInterface
    (thanks to Robert Klotzner aka eskimor)

  - Diet HTML templates now support includes and recursive
    blocks/extensions

  - The REST interface generator has got a new method to 
 reference types
    in the generated string mixin, which makes it more robust to 
 user
    defined types (thanks to Mihail Strašun aka mist)

  - Now includes API docs for offline viewing

  - A lot of small fixes and improvements


 Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9

 Download: http://vibed.org/download?file=vibed-0.7.9.zip


To build Vibe.d you are using DMD 2.060 as released here? I'm 
just wondering what you found to be the best DMD version, or if 
you are using a newer pre-released version found in git? Thanks.

--rt
Oct 31 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 31.10.2012 17:11, schrieb Rob T:

 On Wednesday, 31 October 2012 at 06:59:45 UTC, Sönke Ludwig wrote:

 Changes:

  - New HTML form interface generator similar to the REST interface
    generator that simplifies web front end development:
    http://vibed.org/api/vibe.http.form/registerFormInterface
    (thanks to Robert Klotzner aka eskimor)

  - Diet HTML templates now support includes and recursive
    blocks/extensions

  - The REST interface generator has got a new method to reference types
    in the generated string mixin, which makes it more robust to user
    defined types (thanks to Mihail Strašun aka mist)

  - Now includes API docs for offline viewing

  - A lot of small fixes and improvements


 Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9

 Download: http://vibed.org/download?file=vibed-0.7.9.zip


 
 To build Vibe.d you are using DMD 2.060 as released here? I'm just
 wondering what you found to be the best DMD version, or if you are using
 a newer pre-released version found in git? Thanks.
 
 --rt
 


I'm using the standard 2.060 release. But I know that several people
also use it with the git master version.
Oct 31 2012
parent reply "Rob T" <rob ucora.com> writes:
On Wednesday, 31 October 2012 at 16:19:01 UTC, Sönke Ludwig 
wrote:

 Am 31.10.2012 17:11, schrieb Rob T:

 On Wednesday, 31 October 2012 at 06:59:45 UTC, Sönke Ludwig 
 wrote:

 Changes:

  - New HTML form interface generator similar to the REST 
 interface
    generator that simplifies web front end development:
    http://vibed.org/api/vibe.http.form/registerFormInterface
    (thanks to Robert Klotzner aka eskimor)

  - Diet HTML templates now support includes and recursive
    blocks/extensions

  - The REST interface generator has got a new method to 
 reference types
    in the generated string mixin, which makes it more robust 
 to user
    defined types (thanks to Mihail Strašun aka mist)

  - Now includes API docs for offline viewing

  - A lot of small fixes and improvements


 Full change log: 
 http://vibed.org/blog/posts/vibe-release-0.7.9

 Download: http://vibed.org/download?file=vibed-0.7.9.zip


 
 To build Vibe.d you are using DMD 2.060 as released here? I'm 
 just
 wondering what you found to be the best DMD version, or if you 
 are using
 a newer pre-released version found in git? Thanks.
 
 --rt
 


 I'm using the standard 2.060 release. But I know that several 
 people
 also use it with the git master version.


I'm relatively new to D but making good progress with it after a 
very slow start (it is a very complex language). Some of what I 
am working on shares similarities with what vibe.d is doing, so 
I'm very interested in how vibe.d is progressing.

vibe.d looks like a rather complex project, so I am wondering if 
you've made use of any shared libs with D (i.e., .so and/or .a 
compiled for PIC)?

I know that the druntime will not link as-is without a rebuild to 
enable PIC, so have you found this to be a problem, not using 
shared libs, or have you rebuilt druntime to allow for it?

I'm also wondering how the co-routines are working out with vibe? 
I thought of using them, but my current design will be using 
message passing instead, where the code is broken up into small 
parts to perform the co-processing. When messages are received at 
a location, the code fragment executes. I've done this before in 
C++ and it worked great, but with D I now have an alternative 
using fibers, but I have no exerience with using them.

Thanks for any input you can provide.

--rt
Nov 01 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-01 19:53, Rob T wrote:


 I know that the druntime will not link as-is without a rebuild to enable
 PIC, so have you found this to be a problem, not using shared libs, or
 have you rebuilt druntime to allow for it?


It's not enough to just recompile druntime. It's missing functionality 
to allow true dynamic linking (i.e. dlopen).

-- 
/Jacob Carlborg
Nov 01 2012
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Thursday, 1 November 2012 at 19:23:49 UTC, Jacob Carlborg 
wrote:

 On 2012-11-01 19:53, Rob T wrote:


 I know that the druntime will not link as-is without a rebuild 
 to enable
 PIC, so have you found this to be a problem, not using shared 
 libs, or
 have you rebuilt druntime to allow for it?


 It's not enough to just recompile druntime. It's missing 
 functionality to allow true dynamic linking (i.e. dlopen).


I understand what you are saying, however I was told that you can 
still use shared libs in a limited way. The tricky part is 
knowing what will work and what will not, and why.

I'm used to coding apps that use shared libs, and loadable 
plugins are rather essential to have for some apps, so this is an 
area of interest that maybe I can work on resolving down the 
road. I'm also interested in understanding how people are 
managing without shared libs. It's nice to be able to upgrade 
code by compiling one shared lib and installing it, as opposed to 
rebuilding an entire set of apps that statically link the lib.

--rt
Nov 01 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 01 Nov 2012 21:29:25 +0100
"Rob T" <rob ucora.com> wrote:


 On Thursday, 1 November 2012 at 19:23:49 UTC, Jacob Carlborg 
 wrote:

 On 2012-11-01 19:53, Rob T wrote:


 I know that the druntime will not link as-is without a rebuild 
 to enable
 PIC, so have you found this to be a problem, not using shared 
 libs, or
 have you rebuilt druntime to allow for it?


 It's not enough to just recompile druntime. It's missing 
 functionality to allow true dynamic linking (i.e. dlopen).


 
 I understand what you are saying, however I was told that you can 
 still use shared libs in a limited way. The tricky part is 
 knowing what will work and what will not, and why.
 


This was discussed fairly recently over on 'digitalmars.D'. Although I'm
afraid I don't remember the subject line offhand or have a link.
Nov 01 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-01 21:29, Rob T wrote:


 I understand what you are saying, however I was told that you can still
 use shared libs in a limited way. The tricky part is knowing what will
 work and what will not, and why.

 I'm used to coding apps that use shared libs, and loadable plugins are
 rather essential to have for some apps, so this is an area of interest
 that maybe I can work on resolving down the road. I'm also interested in
 understanding how people are managing without shared libs. It's nice to
 be able to upgrade code by compiling one shared lib and installing it,
 as opposed to rebuilding an entire set of apps that statically link the
 lib.


What's need to be taken care of in general:

* Module infos
* Exception handling tables
* TLS

-- 
/Jacob Carlborg
Nov 02 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 08:19, Jacob Carlborg wrote:


 What's need to be taken care of in general:

 * Module infos
 * Exception handling tables
 * TLS


A slightly better answer of what one can expect of not working:

* Exceptions (at least crossing application/library boundaries)
* Module (de)constructors and many things related to runtime 
introspection, i.e. typeid(), TypeInfo and so on
* Thread local variables
* Probably issues with the GC as well

-- 
/Jacob Carlborg
Nov 02 2012
prev sibling parent reply Lubos Pintes <lubos.pintes gmail.com> writes:
It could be something like .NET assembly, i.e. everything needed is in 
.dll/.so itself. Any chance this happens sometimes?
Dòa 1. 11. 2012 20:23 Jacob Carlborg  wrote / napísal(a):

 On 2012-11-01 19:53, Rob T wrote:


 I know that the druntime will not link as-is without a rebuild to enable
 PIC, so have you found this to be a problem, not using shared libs, or
 have you rebuilt druntime to allow for it?


 It's not enough to just recompile druntime. It's missing functionality
 to allow true dynamic linking (i.e. dlopen).
Nov 02 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 09:45, Lubos Pintes wrote:

 It could be something like .NET assembly, i.e. everything needed is in


I'm not sure I understand. Would you build a dynamic library with all 
the functionality and a thin wrapper just to make it an executable?

-- 
/Jacob Carlborg
Nov 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 01 Nov 2012 19:53:37 +0100
"Rob T" <rob ucora.com> wrote:

 
 I'm also wondering how the co-routines are working out with vibe? 
 I thought of using them, but my current design will be using 
 message passing instead, where the code is broken up into small 
 parts to perform the co-processing. When messages are received at 
 a location, the code fragment executes. I've done this before in 
 C++ and it worked great, but with D I now have an alternative 
 using fibers, but I have no exerience with using them.
 


Personally, I think the fibers/coroutines are working out great for it.
The cool thing about the way vibe.d is designed is you really don't
even notice that you're using fibers. It's pretty much all handled
behind-the-scenes. You just give it your callbacks and don't worry
about how they get called. So it feels more like a
simplified message-passing. You rarely deal with the fibers/coroutines
yourself unless you want to.

About the only big thing to be careful of, in my experience, is
remembering not to reuse the same open connection (to a DB or other
server, for example) across different requests without using the
built-in connection pool stuff.

And similarly, you may want to be careful about updating global state
(because while globals are *thread*-local by default in D, they're
*NOT* fiber-local). But that's a LOT easier to deal with than writing
*thread*-safe code with shared state because unlike threads, the fiber
switches can only happen in very specific places (when you use vibe.d's
async I/O or manually yield the fiber yourself). So just don't do IO or
call yield in the middle of an atomic global-state update (or just
don't use global state), and you're golden.
Nov 01 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 01.11.2012 19:53, schrieb Rob T:

 
 I'm relatively new to D but making good progress with it after a very
 slow start (it is a very complex language). Some of what I am working on
 shares similarities with what vibe.d is doing, so I'm very interested in
 how vibe.d is progressing.
 
 vibe.d looks like a rather complex project, so I am wondering if you've
 made use of any shared libs with D (i.e., .so and/or .a compiled for PIC)?
 
 I know that the druntime will not link as-is without a rebuild to enable
 PIC, so have you found this to be a problem, not using shared libs, or
 have you rebuilt druntime to allow for it?


I haven't used shared libs in conjunction with vibe.d, but in a LLVM
based compiler project that was compiled as a DLL (where PIC is not
required). For OS X I dodged the PIC problems by compiling it as a
static library. But TLS required a lot of tweaking on GDC+Win64 and
remained very fragile. Before getting to the root of this and fixing it,
development priorities shifted and later I left the company. So
unfortunately I can't really offer really useful insights here apart
from confirming the already known problems.


 
 I'm also wondering how the co-routines are working out with vibe? I
 thought of using them, but my current design will be using message
 passing instead, where the code is broken up into small parts to perform
 the co-processing. When messages are received at a location, the code
 fragment executes. I've done this before in C++ and it worked great, but
 with D I now have an alternative using fibers, but I have no exerience
 with using them.


They are working out really well and are a great help to concentrate on
concepts rather than how to implement them. I'm also using them in a
Windows GUI application, where they are mixed with window message
processing, and it really helps to simplify some parts there, which were
formerly implemented as threads (with error prone locking/lockless data
sharing) or as fragmented jobs with an explicit state (complicating the
algorithm). Another place

I would like to have/add std.concurrency style message passing on top
though, as that sometimes is actually quite convenient and of course
it's also a very safe way to handle communication between fibers that
are running on different threads - provided that only
immutable/shared/unique data is sent, of course.
Nov 02 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 2 November 2012 at 11:27:22 UTC, Sönke Ludwig wrote:

 Am 01.11.2012 19:53, schrieb Rob T:

 I would like to have/add std.concurrency style message passing 
 on top
 though, as that sometimes is actually quite convenient and of 
 course
 it's also a very safe way to handle communication between 
 fibers that
 are running on different threads - provided that only
 immutable/shared/unique data is sent, of course.


Thanks for the input!

A huge advantage of the message passing concept is that it can 
scale up easily to include threads (I suppose fibres too), as 
well as independent processes on same machine, and to multiple 
machines across a network.

AFIK you simply cannot get that kind of scaling without message 
passing.

At this time the std.concurrency module only supports messaging 
across threads, so this part will need some work. I have enough 
C++ experience with messaging across nodes, so I'm at least not 
starting from scratch.

What I don't know yet, is if I should implement concurrency 
entirely through message passing, or to include co-routines for 
the execution part. If I do not use co-routines, then the 
execution units have to be broken up into parts, following the 
usual event processing model.

I can manage breaking up code into parts well enough, and there 
may actually be advantages to doing it that way, but I can also 
see advantages with using co-routines. I'll have to perform tests 
to see how it will all fit together, but this will take me a 
while.

--rt
Nov 02 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 12:27, Sönke Ludwig wrote:


 I haven't used shared libs in conjunction with vibe.d, but in a LLVM
 based compiler project that was compiled as a DLL (where PIC is not
 required). For OS X I dodged the PIC problems by compiling it as a
 static library.


On Mac OS X PIC is the default, no problems :)

-- 
/Jacob Carlborg
Nov 02 2012
prev sibling parent reply Faux Amis <faux amis.com> writes:
On 31/10/2012 07:59, Sönke Ludwig wrote:

 Changes:

   - New HTML form interface generator similar to the REST interface
     generator that simplifies web front end development:
     http://vibed.org/api/vibe.http.form/registerFormInterface
     (thanks to Robert Klotzner aka eskimor)

   - Diet HTML templates now support includes and recursive
     blocks/extensions

   - The REST interface generator has got a new method to reference types
     in the generated string mixin, which makes it more robust to user
     defined types (thanks to Mihail Stra¨un aka mist)

   - Now includes API docs for offline viewing

   - A lot of small fixes and improvements


 Full change log: http://vibed.org/blog/posts/vibe-release-0.7.9

 Download: http://vibed.org/download?file=vibed-0.7.9.zip


I have very little server exp and the little I have is from node.js 
tutorials. I have heard about node.js being used as a game server.
Could vibe.d be used as a multiplayer game server?
And, how (well) does it scale?
Nov 01 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 01 Nov 2012 23:45:17 +0100
Faux Amis <faux amis.com> wrote:

 I have very little server exp and the little I have is from node.js 
 tutorials. I have heard about node.js being used as a game server.
 Could vibe.d be used as a multiplayer game server?
 And, how (well) does it scale?
 


Far better than node.js. Actually, vibe.d is known to scale very well,
and it does scale very well in my own tests.

Node.js isn't something I would really recommend for much of anything,
especially a multiplayer game server. No matter how fast its JS engine
is, it's still JS and therefore will *always* be notably slower
than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
1* can run Quake 2).

Plus node.js's design is awkward to use (ie, it's async I/O is very
awkward compared to the way Vibe.d handles it, and it's EASY to end up
holding up the entire server just because of one slow request). Plus
IMO JS is just not a nice language to deal with in the first place.
People use JS on the client because it's the only real choice. The
server side other options.

If you're not scared off of node.js yet, read this:
https://semitwist.com/mirror/node-js-is-cancer.html  (The original
link is dead, so I have it mirrored there, minus the CSS so it looks
ugly, sorry.)

Coincidentally, I actually *am* writing a multiplayer game server with
vibe.d right now (unfortunately I'm not sure I can open source it
though, it's for work, and it's relatively game-specific). I'm convinced
it's a great way to go, and I haven't come across any big problems. I
had stared out with Python at "the boss's" request, but it was a
disaster (at least partially b/c of learning curve though: I'm
experienced in D, not so much in Python).
Nov 01 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 00:14, Nick Sabalausky wrote:


 Node.js isn't something I would really recommend for much of anything,
 especially a multiplayer game server. No matter how fast its JS engine
 is, it's still JS and therefore will *always* be notably slower
 than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
 1* can run Quake 2).


It's JavaScript, don't use it, what more do one need to know :)

-- 
/Jacob Carlborg
Nov 02 2012
prev sibling parent reply Faux Amis <faux amis.com> writes:
On 02/11/2012 00:14, Nick Sabalausky wrote:

 On Thu, 01 Nov 2012 23:45:17 +0100
 Faux Amis <faux amis.com> wrote:

 I have very little server exp and the little I have is from node.js
 tutorials. I have heard about node.js being used as a game server.
 Could vibe.d be used as a multiplayer game server?
 And, how (well) does it scale?


 Far better than node.js. Actually, vibe.d is known to scale very well,
 and it does scale very well in my own tests.

 Node.js isn't something I would really recommend for much of anything,
 especially a multiplayer game server. No matter how fast its JS engine
 is, it's still JS and therefore will *always* be notably slower
 than real native code (Yea, JS can run Quake 2, but so what? A *Pentium
 1* can run Quake 2).

 Plus node.js's design is awkward to use (ie, it's async I/O is very
 awkward compared to the way Vibe.d handles it, and it's EASY to end up
 holding up the entire server just because of one slow request). Plus
 IMO JS is just not a nice language to deal with in the first place.
 People use JS on the client because it's the only real choice. The
 server side other options.

 If you're not scared off of node.js yet, read this:
 https://semitwist.com/mirror/node-js-is-cancer.html  (The original
 link is dead, so I have it mirrored there, minus the CSS so it looks
 ugly, sorry.)


I actually read that website when I tried out node.js. I thought vibe.d 
would suffer the same locking behaviour.
Nov 02 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 02 Nov 2012 18:28:55 +0100
Faux Amis <faux amis.com> wrote:


 On 02/11/2012 00:14, Nick Sabalausky wrote:

 If you're not scared off of node.js yet, read this:
 https://semitwist.com/mirror/node-js-is-cancer.html  (The original
 link is dead, so I have it mirrored there, minus the CSS so it looks
 ugly, sorry.)


 
 I actually read that website when I tried out node.js. I thought
 vibe.d would suffer the same locking behaviour.
 


It can if you're not careful, Ted is right about that. However, IMO it's
less of an issue with Vibe.d because using its I/O will automatically
yield to other requests running in their own fibers. Plus D code just
simply executes much faster than JS, even if it is V8 JS.

Also, the "event loop with built in HTTP server" approach *can* also
make it easier to write fast servers because unlike CGI-style it's a
lot easier to cache stuff in memory.
Nov 02 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 November 2012 at 22:21:42 UTC, Nick Sabalausky wrote:

 Also, the "event loop with built in HTTP server" approach *can* 
 also make it easier to write fast servers because unlike 
 CGI-style it's a lot easier to cache stuff in memory.


Of course, that's a double edged sword too because it isn't hard 
to accidentally inject bizarre cross-request bugs.

This is one of the reasons I still use classic CGI on most my 
live apps, despite being able to use a long lived process with 
just a recompile with my lib: it is just easier to ensure 
stability with the process separation.
Nov 02 2012