Re: vibe.d 0.7.9 released
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 ?
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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).
Re: vibe.d 0.7.9 released
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.
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
On 02/11/2012 00:14, Nick Sabalausky wrote: On Thu, 01 Nov 2012 23:45:17 +0100 Faux Amis f...@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.
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
On Fri, 02 Nov 2012 18:28:55 +0100 Faux Amis f...@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.
Re: vibe.d 0.7.9 released
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.
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
On Thu, 01 Nov 2012 21:29:25 +0100 Rob T r...@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.
Re: vibe.d 0.7.9 released
On Thu, 01 Nov 2012 19:53:37 +0100 Rob T r...@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.
Re: vibe.d 0.7.9 released
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?
Re: vibe.d 0.7.9 released
On Thu, 01 Nov 2012 23:45:17 +0100 Faux Amis f...@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).
vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
cool, keep up the good work!
Re: vibe.d 0.7.9 released
AUR package updated: https://aur.archlinux.org/packages.php?ID=61679
Re: vibe.d 0.7.9 released
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
Re: vibe.d 0.7.9 released
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.
