Re: Remus
On 10/29/2012 06:09 PM, bearophile wrote: Otherwise you risk creating another Delight (http://delight.sourceforge.net/ ) that no one uses, it's just a waste of time for you too. I'm waiting for the bearD programming language :)
Re: Remus
Namespace:
or other suggest other features that they would like
to see in remus. I look forward to suggestions. :)
There is a D problem that in my opinion is worth exploring.
Usually I prefer const/immutable variables/collections, but there
are several different situations where this is hard to do. In
some cases to do this you even have to create a function in-place
that is called in-place, that creates an array, returns it, and
the result is assigned to const. There are other different
situations.
One other case is at global scope:
immutable foo = bar + baz
where {
auto foo = ...;
auto baz = ...;
};
Bye,
bearophile
Re: Remus
On Thursday, 1 November 2012 at 15:41:26 UTC, bearophile wrote:
Namespace:
or other suggest other features that they would like
to see in remus. I look forward to suggestions. :)
There is a D problem that in my opinion is worth exploring.
Usually I prefer const/immutable variables/collections, but
there are several different situations where this is hard to
do. In some cases to do this you even have to create a function
in-place that is called in-place, that creates an array,
returns it, and the result is assigned to const. There are
other different situations.
One other case is at global scope:
immutable foo = bar + baz
where {
auto foo = ...;
auto baz = ...;
};
Bye,
bearophile
When did you use something like this? In this case you could take
a function that assign foo:
immutable foo;
void assignFoo() {
string bar, barz; // ...
foo = bar + baz;
}
or not?
Re: Remus
Namespace:
When did you use something like this?
Now and then :-)
In this case you could take a function that assign foo:
Usually in that case I use the module static this. But the point
immutable foo;
void assignFoo() {
string bar, barz; // ...
foo = bar + baz;
}
or not?
That doesn't work because foo has no type, and because you can
only initialize immutable global variables inside the static
this.
But the main point of what I was saying is not that it's
impossible to do some things, most times there is already some
way to do it in D.
I was saying that the current ways to assign immutable
values/collections is sometimes not handy in D. So Remus seems
the right place to experiment several different ideas to improve
those situations. A where is just one of the different
possibilities.
Bye,
bearophile
Re: DConf 2013 on kickstarter.com: we're live!
On 10/31/12 8:35 PM, Faux Amis wrote: On 22/10/2012 19:25, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Looking at the graph and excluding the super-villains (who are they?) the current pool seems close to empty. We currently have one generous $5K contribution from Andrew Edwards (an enlisted US Marine) and another one from Sociomantic.com. Since Andrew is not competing for branding or recruiting, we're considering offering one extra Kryptonite slot should we receive requests. Excluding the large contributions is actually not indicative because most conferences actually finance via sponsorships. There will probably be an end spurt if the goals seems in sight, but as it stand I don't see this happening. The way I see it, we have 16 firm early bird attendees, and we're six corporate sponsorships away from reaching our goal. We must make this happen. One thing we could all do is to mention the conference to our recruiting managers. This is a golden opportunity to recruit straight in the Bay Area. A contribution as simple as offering a conference room for three days would mean huge goodwill in the D community for next to no cost to the company. My reason for not having pledged: Too expensive: flight + ticket. I will pledge 100$ if that would mean videos. Understood. Note that if you submit a talk proposal, it's possible (no promise though at this point) we'd be able to defray transportation costs. Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 10/31/12 8:35 PM, Faux Amis wrote: I will pledge 100$ if that would mean videos. I second that. Many of us won't be able to attend to the conference due to travel costs and it would be nice if there are videos.
Re: Remus
I see. My comprehension ATM is, that you want to concatenate two or more strings at compile time, but this works fine: immutable string test = abc ~ def; Because of that it would be greatly helped if you can give me a concrete example.
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).
