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

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