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: A little Py Vs C++
On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. -- /Jacob Carlborg
Re: A little Py Vs C++
On 02/11/12 09:07, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. He just knows how to convince Walter. (Hint: use real-world use cases. Arguments from theoretical computer science carry almost no weight with Walter). Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. Yes, and they could cure cancer. AST macros can do anything, because they are completely undefined. Without even a vague proposal, it seems like a rather meaningless term.
Re: A little Py Vs C++
Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. Why do I vote anyway? Regarding SIMD I have the feeling that because it is built into the compiler static vectors have actually failed what they promised. I thought D proposed a portable way of vector operations such that you write float[4] = a[] + b[] and the compiler generates SIMD code for you. Jens
Re: Scaling Scala Vs Java
Andrei Alexandrescu wrote: On 11/1/12 11:26 PM, bearophile wrote: This blog post shows few interesting aspects of the Scala ecosystem: http://jazzy.id.au/default/2012/11/02/scaling_scala_vs_java.html Bye, bearophile I have a dream that one day there will be a guy with the ID philobear discussing D-related stuff on Java and Scala forums. :) What a nice dream. Jens
Re: A little Py Vs C++
Don Clugston wrote: On 02/11/12 09:07, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. He just knows how to convince Walter. (Hint: use real-world use cases. Arguments from theoretical computer science carry almost no weight with Walter). I think there are lots of issues in the bug tracker which describe real use cases. The point is that these are more like bugs whereas Manu's proposals are more like feature requests. Jens
Re: A little Py Vs C++
On 02/11/12 10:12, Jens Mueller wrote: Don Clugston wrote: On 02/11/12 09:07, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. He just knows how to convince Walter. (Hint: use real-world use cases. Arguments from theoretical computer science carry almost no weight with Walter). I think there are lots of issues in the bug tracker which describe real use cases. The point is that these are more like bugs whereas Manu's proposals are more like feature requests. Jens The SIMD stuff has no workarounds. I don't know of many other feature requests in that category.
Re: Scaling Scala Vs Java
On Friday, 2 November 2012 at 04:33:33 UTC, bearophile wrote: Andrei Alexandrescu: I have a dream that one day there will be a guy with the ID philobear discussing D-related stuff on Java and Scala forums. It's very important to look at how other very good languages solve common problems :-) While i like many of your posts on different languages, there are also too much noise. I now realize that noise cost me a great deal. After nearly 10 years of programming i finally gave a try to lisp, just because of a phrase programmable programming language. This might offend some people but i have to say regardless. Lisp is the most beautiful language i have seen. If i didn't need a system language there would be no reason for me to drop everything else but only use it. It took me 10 years to get to know it because of no advertisement and the noise and the hatred generated by 1000s other random languages that cater mediocre programmers and the business. Because of similar reasons, i worry about D's future too. When a language is powerful, it creates programmers that is not replaceable and we know it is not a good thing.
Re: A little Py Vs C++
On 02/11/12 10:01, Jens Mueller wrote: Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. Why do I vote anyway? Regarding SIMD I have the feeling that because it is built into the compiler static vectors have actually failed what they promised. I thought D proposed a portable way of vector operations such that you write float[4] = a[] + b[] and the compiler generates SIMD code for you. Not for short vectors. They are more like the builtin operations in Fortran, ie designed for large vectors. More for scientific kinds of applications than games. (The two applications look superficially similar, but in practice they have little in common).
Re: A little Py Vs C++
Don Clugston wrote: On 02/11/12 10:12, Jens Mueller wrote: Don Clugston wrote: On 02/11/12 09:07, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. He just knows how to convince Walter. (Hint: use real-world use cases. Arguments from theoretical computer science carry almost no weight with Walter). I think there are lots of issues in the bug tracker which describe real use cases. The point is that these are more like bugs whereas Manu's proposals are more like feature requests. Jens The SIMD stuff has no workarounds. I don't know of many other feature requests in that category. Then I have a serious misunderstanding. I thought D introduced array operations to allow the compiler to generate efficient vector operations (in the long run), i.e. generate SIMD code. Why is this not working out? Jens
Re: A little Py Vs C++
On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote: Then I have a serious misunderstanding. I thought D introduced array operations to allow the compiler to generate efficient vector operations (in the long run), i.e. generate SIMD code. Why is this not working out? It works fine for large vectors. For small vectors, it is horrendously slow. The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back. The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores. Both have their purposes.
Re: A little Py Vs C++
Don Clugston wrote: On 02/11/12 10:01, Jens Mueller wrote: Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. Why do I vote anyway? Regarding SIMD I have the feeling that because it is built into the compiler static vectors have actually failed what they promised. I thought D proposed a portable way of vector operations such that you write float[4] = a[] + b[] and the compiler generates SIMD code for you. Not for short vectors. They are more like the builtin operations in Fortran, ie designed for large vectors. More for scientific kinds of applications than games. (The two applications look superficially similar, but in practice they have little in common). Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting? Jens
Re: A little Py Vs C++
Peter Alexander wrote: On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote: Then I have a serious misunderstanding. I thought D introduced array operations to allow the compiler to generate efficient vector operations (in the long run), i.e. generate SIMD code. Why is this not working out? It works fine for large vectors. For small vectors, it is horrendously slow. The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back. The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores. Both have their purposes. I see. But can't the alignment problem be solved by using align. Then have the compiler emits a call that checks for alignment if none was specified else use a faster version. Jens
'with' bug?
After reading this:
http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
I thought, does D have the same problem, and according to:
http://dlang.org/statement.html#WithStatement
No, it doesn't. D detects local variable shadowing and produces an
error. But, then I thought does that apply to global variables as well?
Turns out, no it doesn't.
// [withd.d]
import std.stdio;
int global;
struct S
{
int global;
int local;
}
void main()
{
int local;
S s;
with(s)
{
local = 3; // withd.d(18): Error: with symbol withd.S.local is
shadowing local symbol withd.main.local
global = 5;
}
writefln(local = %d, local);
writefln(global = %d, global);
writefln(s.local = %d, s.local);
writefln(s.global = %d, s.global);
}
The above (if you comment out the line producing the expected error)
compiles and runs. It updates s.global at least. The risk is fairly
small, I guess, that someone will mis-type a member name, and hit a global
with that mis-typed name, but it's possible. And in that case it would
compile and then do something unexpected.
Should I raise a bug for this?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
OT: NAND to Tetris
Stumbled across this recently and thought it was pretty damn cool: http://www.nand2tetris.org/ Got there, from here: http://www.ted.com/talks/shimon_schocken_the_self_organizing_computer_course.html Got there, from here: http://hackaday.com/2012/11/01/how-computers-work-starting-with-transistor-gates/ Apologies in advance if this is the wrong place to share it (let me know where instead). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: 'with' bug?
On Friday, 2 November 2012 at 12:04:28 UTC, Regan Heath wrote:
Should I raise a bug for this?
This one is ok I think because D normally lets locals shadow
globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good
thing because it means adding a variable elsewhere won't
annoyingly break your functions.
You could argue that doing it on structs is a little harder to
keep track of than regular locals, but, meh.
Re: A little Py Vs C++
On Friday, 2 November 2012 at 10:50:56 UTC, Jens Mueller wrote: Don Clugston wrote: On 02/11/12 10:01, Jens Mueller wrote: Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. Why do I vote anyway? Regarding SIMD I have the feeling that because it is built into the compiler static vectors have actually failed what they promised. I thought D proposed a portable way of vector operations such that you write float[4] = a[] + b[] and the compiler generates SIMD code for you. Not for short vectors. They are more like the builtin operations in Fortran, ie designed for large vectors. More for scientific kinds of applications than games. (The two applications look superficially similar, but in practice they have little in common). Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting? Jens The auto vectorization code in Visual Studio 2012 seems to work pretty well.
Re: Scaling Scala Vs Java
On Friday, 2 November 2012 at 10:09:10 UTC, so wrote: On Friday, 2 November 2012 at 04:33:33 UTC, bearophile wrote: Andrei Alexandrescu: I have a dream that one day there will be a guy with the ID philobear discussing D-related stuff on Java and Scala forums. It's very important to look at how other very good languages solve common problems :-) While i like many of your posts on different languages, there are also too much noise. I now realize that noise cost me a great deal. After nearly 10 years of programming i finally gave a try to lisp, just because of a phrase programmable programming language. This might offend some people but i have to say regardless. Lisp is the most beautiful language i have seen. If i didn't need a system language there would be no reason for me to drop everything else but only use it. It took me 10 years to get to know it because of no advertisement and the noise and the hatred generated by 1000s other random languages that cater mediocre programmers and the business. Because of similar reasons, i worry about D's future too. When a language is powerful, it creates programmers that is not replaceable and we know it is not a good thing. That is currently the problem in my line of work. Nowadays enterprise applications are all JVM or .NET based. C++ in the cloud is viewed as something for the HPC crowd. Finance enterprise world is currently jumping to the FP boat. Enterprise mobile applications are use the platform default tools or are web based anyway. This leaves little space free for D in the enterprise. :( -- Paulo
Re: A little Py Vs C++
On 11/1/12 6:51 PM, Walter Bright wrote: On 11/1/2012 2:20 PM, bearophile wrote: Some complexity comes from the desire to do more and more. As example see this recent request from Manu, What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. I'd argue this actually is part of a category of features that does not increase the complexity of the language (quite the contrary in fact). This is because stating that declaration+definition in the same file won't work takes actually more cognitive load than just allowing it. By the consistency principle, one should infer unknown parts of a complex system from knowing the others. Consider then this setup: * Declarations (without definition) of functions are allowed. * Definitions are allowed. * Declarations and definitions are allowed in distinct files in the same project as long as they match. At this point, it is more tenuous to argue that same file is a special case that should prevent declarations and definitions to coexist, than to just let it happen and let the consistency principle take care of explaining it. Andrei
Re: 'with' bug?
On 11/2/12 8:03 AM, Regan Heath wrote: After reading this: http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/ I thought, does D have the same problem, and according to: http://dlang.org/statement.html#WithStatement No, it doesn't. D detects local variable shadowing and produces an error. It took quite some fighting to get that implemented. I vaguely recall we didn't figure that issue until I tried to explain with in TDPL. Or it had been already discussed in the forum? Anyhow, it made with quite cool. But, then I thought does that apply to global variables as well? Turns out, no it doesn't. [snip] Should I raise a bug for this? I personally think we're in good shape here, but an argument could be made either way. Andrei
Re: 'with' bug?
Adam D. Ruppe:
D normally lets locals shadow globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good
thing because it means adding a variable elsewhere won't
annoyingly break your functions.
You could argue that doing it on structs is a little harder to
keep track of than regular locals, but, meh.
I try to minimize (possibly to zero) the number of global
variables/constants, but I have had some troubles caused by
silent shadowing of global names by local names in functions.
Having global variables with the same name of local variables is
sometimes a source for troubles, so I try to keep their name
distinct. But I'd like D to spot such duplications (shadowing of
a global) for me.
Bye,
bearophile
To take a part in development
I would like to take a part in development of D programming language or Phobos library. I opened bugtracker and found some bugs that i could to fix. Maybe I should read something (specifically for development) or you can give me some advice before i create first pull request? Thanks
Re: To take a part in development
On Friday, 2 November 2012 at 13:33:17 UTC, Habibutsu wrote: I would like to take a part in development of D programming language or Phobos library. I opened bugtracker and found some bugs that i could to fix. Maybe I should read something (specifically for development) or you can give me some advice before i create first pull request? Thanks There's not really anything to read (I certainly haven't read anything). Just fork the relevant project on github, fix the bug, and create the pull request. Is there anything in particular that you wanted to know?
Re: To take a part in development
General: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel DMD Source Guide: http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide I do not know how up to date these are.
Re: Scaling Scala Vs Java
On 11/02/2012 12:18 AM, Andrei Alexandrescu wrote: I have a dream that one day there will be a guy with the ID philobear discussing D-related stuff on Java and Scala forums. You're lucky to have bearophile on this group. Cross-pollination is a good thing.
Re: To take a part in development
On 02/11/12 14:04, Habibutsu wrote: I would like to take a part in development of D programming language or Phobos library. I opened bugtracker and found some bugs that i could to fix. Maybe I should read something (specifically for development) or you can give me some advice before i create first pull request? Thanks Join the dmd-internals and/or phobos lists at lists.puremagic.com
Re: A little Py Vs C++
On 02/11/12 11:57, Jens Mueller wrote: Peter Alexander wrote: On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote: Then I have a serious misunderstanding. I thought D introduced array operations to allow the compiler to generate efficient vector operations (in the long run), i.e. generate SIMD code. Why is this not working out? It works fine for large vectors. For small vectors, it is horrendously slow. The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back. The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores. Both have their purposes. I see. But can't the alignment problem be solved by using align. Then have the compiler emits a call that checks for alignment if none was specified else use a faster version. No. For SIMD, you cannot afford to have even a single machine instruction inserted, or the benefit is entirely lost.
Re: To take a part in development
On 11/2/12, Habibutsu habibu...@gmail.com wrote: Maybe I should read something (specifically for development) or you can give me some advice before i create first pull request? Thanks http://prowiki.org/wiki4d/wiki.cgi?Contributing_To_The_D_Compiler http://prowiki.org/wiki4d/wiki.cgi?PullRequest
Re: A little Py Vs C++
Don Clugston wrote: On 02/11/12 11:57, Jens Mueller wrote: Peter Alexander wrote: On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote: Then I have a serious misunderstanding. I thought D introduced array operations to allow the compiler to generate efficient vector operations (in the long run), i.e. generate SIMD code. Why is this not working out? It works fine for large vectors. For small vectors, it is horrendously slow. The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back. The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores. Both have their purposes. I see. But can't the alignment problem be solved by using align. Then have the compiler emits a call that checks for alignment if none was specified else use a faster version. No. For SIMD, you cannot afford to have even a single machine instruction inserted, or the benefit is entirely lost. But the compiler knows about the alignment, doesn't it? align(16) float[4] a; vs float[4] a; In the former case the compiler can generate better code and it should. The above syntax is not supported. But my point is all the compiler cares about is the alignment which can be specified in the code somehow. Sorry for being stubborn. Jens
Re: OT: NAND to Tetris
Le 02/11/2012 13:06, Regan Heath a écrit : Stumbled across this recently and thought it was pretty damn cool: http://www.nand2tetris.org/ Got there, from here: http://www.ted.com/talks/shimon_schocken_the_self_organizing_computer_course.html Got there, from here: http://hackaday.com/2012/11/01/how-computers-work-starting-with-transistor-gates/ Apologies in advance if this is the wrong place to share it (let me know where instead). R That is awesome ! Thank for sharing.
Re: A little Py Vs C++
On 11/02/2012 09:07 AM, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. SIMD support is necessary and the fix for 8108 is very simple. If the way default arguments work shall be improved though, it would add additional ways that the compiler can screw up conditional compilation. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. A sufficiently well/badly designed macro feature can potentially replace most other language features.
Re: Scaling Scala Vs Java
On 11/2/12 9:53 AM, Jeff Nowakowski wrote: On 11/02/2012 12:18 AM, Andrei Alexandrescu wrote: I have a dream that one day there will be a guy with the ID philobear discussing D-related stuff on Java and Scala forums. You're lucky to have bearophile on this group. Cross-pollination is a good thing. Cross-pollination is a good thing indeed. The pattern I'm not a fan of is posting entries scraped from reddit or google searches, featuring little insightful filtering or added value, and with the all-too-transparent bias language X does/doesn't Y, we don't do/do it, so we either should change D or agree to being troglodytes. A telling example that got me as close to cursing to my monitor as any other forum post is: You should show more respect for them and their work. Their ideas seem very far from being crazy. They have also proved their type system to be sound. This kind of work is lightyears ahead of the usual sloppy designs you see in D features, where design holes are found only years later, when sometimes it's too much late to fix them :) In one breath we get a call to respect for people who are unknown to the poster and unlikely to ever read this, a gratuitous insult to people who are active on this forum and have long interacted with the poster, a complete lack of consideration for the many differences between the dynamics of a language design focused on one feature group in an academic context versus the realities of designing and implementing a general-purpose language with many conflicting requirements, and a tactless attempt at making it look like a joke. Quite the handiwork. A better approach would take into account the rich context established by each language's environment and how an end goal can be accomplished without wheelbarrowing features from other languages just because they have them. Andrei
Re: Transience of .front in input vs. forward ranges
On Thu, Nov 01, 2012 at 11:40:52PM +0100, deadalnix wrote:
This is up to the consumer to choose if .front can be oblitered on
popFront, not to an intermediate algorithm.
joiner isn't a consumer, this is a « transformer ». transformer have
to propagate the .fast (I don't like this name, but this is
unimportant for now) to its source.
What would be a better name for it?
Let'(s consider the following sheme :
source - transformer (possibly several of them) - consumer.
Now see example below :
auto transform(R)(R range) {
struct Transfomer(R) {
// Operations . . .
@property
auto fast() {
return transform(source.fast);
}
}
}
So the fast is used by the consumer and bubble throw all ranges that
support it up to the source. Or is made a NOOP in the process in one
of the transformers or the source do not support that optimization.
As said before, this is up to the consumer to know it it accept
.front to be obliterated. In your case, writeln don't support that,
so .fast must not be used with writeln.
Ah, I see. That makes sense. So basically it's not the source (or any
intermediate step) that decides whether to use the optimization, but the
final consumer.
Though now we have the issue that all intermediate ranges must propagate
.fast, which is troublesome if every range has to do it manually. Can
this be handled automatically by UFCS?
T
--
What doesn't kill me makes me stranger.
D vs C++11
Hello student here, I have started to learn D a few months ago with Andrei's book (I really liked arguments about design decisions), but as the same time I was learning new features of C++11, and now I'm really confused. (As learning projects, I've done an IRC Bot in D and an IPv6 stack in C++11) D is a great language and introduce a lot of features I really like (range, property, UFCS, great metaprogramming, ...) but C++11 and the new standard librairy are well supported now. I have some solid experience with C++, so I know how cumbersome C++ could be (C++11 and universal reference ?), but D has a lot of features too and (as C++) a slow learning curve. I would like to konw the point of view of the community about C++11 in regard of D ? Is the gap between D and C++11 is getting thinner ? Do you think D will keep attracting people while at the same time C++11 has more support (debugger, IDE, Librairies, Documentation) ?
Re: 'with' bug?
On 02/11/2012 14:13, bearophile wrote:
Adam D. Ruppe:
D normally lets locals shadow globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good thing
because it means adding a variable elsewhere won't annoyingly break
your functions.
You could argue that doing it on structs is a little harder to keep
track of than regular locals, but, meh.
I try to minimize (possibly to zero) the number of global
variables/constants, but I have had some troubles caused by silent
shadowing of global names by local names in functions.
Having global variables with the same name of local variables is
sometimes a source for troubles, so I try to keep their name distinct.
But I'd like D to spot such duplications (shadowing of a global) for me.
Bye,
bearophile
When talking about global variables are we talking about module scope
variables?
As I see the module as the most primary data encapsulation in D, I often
use module scope variables (in combo with static import).
I didn't know you could shadow globals and in my situation it sounds bug
prone.
Re: A little Py Vs C++
On 11/2/2012 2:01 AM, Jens Mueller wrote: I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post).
Re: A little Py Vs C++
On 11/2/2012 10:22 AM, Walter Bright wrote: such as the big push for Win64 support I want to give a shoutout here for Rainer Schuetze who has been a big help behind the scenes in getting the Win64 symbolic debug support working. He's saved me a ton of time.
Re: A little Py Vs C++
On 11/2/12, Walter Bright newshou...@digitalmars.com wrote: Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. Wow that's really cool! Manu if you know of any trivial-type bugs you'd like to get fixed (for example error messages) let me know so I can prioritize them. There's a ton of open issues and I usually select the ones for fixing by random. I've managed to fix a few so far. :)
Simple implementation of __FUNCTION
Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is
used for basic execution monitoring and for automated logging of
exception errors.
Here's what I did.
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier,
__traits(parent, {}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
The ONLY thing left that I would like to have, is ability to
display the function signature along with the name. The signature
will be very useful to show which version of an overloaded or
templated function was called.
If anyone can suggest imporvements, like how to get rid of need
to explicitly call mixin, and better yet a solution to get the
function signature, please post away. Thanks!
I have to mention that we need a real solution that can only be
provided through improved reflection support, eg
__scope.function, __scope.line, __scope.file, etc, or whatever
the D community thinks will fit in best.
--rt
Re: A little Py Vs C++
On 11/2/12 1:22 PM, Walter Bright wrote: On 11/2/2012 2:01 AM, Jens Mueller wrote: I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post). I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. Andrei
Re: Simple implementation of __FUNCTION
On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
Thanks to input from the D community, I've managed to implement
a reasonable way to log the name of a calling function.
Huh, that's pretty brilliant!
The ONLY thing left that I would like to have, is ability to
display the function signature along with the name.
template __FUNCTION_SIGNATURE() { const char[]
__FUNCTION_SIGNATURE = typeof(__traits(parent, {})).stringof; }
int main(string[] args) {
assert(0, mixin(__FUNCTION_SIGNATURE!()));
}
core.exception.AssertError@test4.d(7): int(string[] args)
Re: A little Py Vs C++
On Thursday, 1 November 2012 at 18:06:21 UTC, Peter Alexander wrote: On Wednesday, 31 October 2012 at 23:04:15 UTC, bearophile wrote: The thread contains some sad comments: It's unfortunate that there's still bad press circulating about a situation that is long gone. I suppose you just have to try and ignore those people. A more interesting comment is this one: But the real problem here is that in order to achieve even that, the complexity and amount of concepts you have to deal with in C++11 is mind boggling. The same is true in D. Well-written D code often does look rather elegant, but the amount of understanding needed to write beautiful D code is staggering. I think that is the case of any multi-paradigm language. It is already enough to allow both functional and OO style of programming to have hundreds of things to think about... That is exactly one of the major reasons why people prefer Java over other languages...
Re: A little Py Vs C++
On 11/2/2012 10:32 AM, Andrej Mitrovic wrote: Manu if you know of any trivial-type bugs you'd like to get fixed (for example error messages) let me know so I can prioritize them. There's a ton of open issues and I usually select the ones for fixing by random. I've managed to fix a few so far. :) Thanks, any help would be appreciated. I'll ask Manu for a list of his priority issues, and even minor ones. What will also help is trying out the beta Win64 target. I've been posting nightly new betas for it.
Re: A little Py Vs C++
On 11/2/2012 3:50 AM, Jens Mueller wrote: Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting? Another excellent question. Most languages have taken the auto-vectorization approach of reverse engineering loops to turn them into high level constructs, and then compiling the code into special SIMD instructions. How to do this is explained in detail in the (rare) book The Software Vectorization Handbook by Bik, which I fortunately was able to obtain a copy of. This struck me as a terrible approach, however. It just seemed stupid to try to teach the compiler to reverse engineer low level code into high level code. A better design would be to start with high level code. Hence, the appearance of D vector operations. The trouble with D vector operations, however, is that they are too general purpose. The SIMD instructions are very quirky, and it's easy to unwittingly and silently cause the compiler to generate absolutely terribly slow code. The reasons for that are the alignment requirements, coupled with the SIMD instructions not being orthogonal - some operations work for some types and not for others, in a way that is unintuitive unless you're carefully reading the SIMD specs. Just saying align(16) isn't good enough, as the vector ops work on slices and those slices aren't always aligned. So each one has to check alignment at runtime, which is murder on performance. If a particular vector op for a particular type has no SIMD support, then the compiler has to generate workaround code. This can also have terrible performance consequences. So the user writes vector code, benchmarks it, finds zero improvement, and the reasons why will be elusive to anyone but an expert SIMD programmer. (Auto-vectorizing technology has similar issues, pretty much meaning you won't get fast code out of it unless you've got a habit of examining the assembler output and tweaking as necessary.) Enter Manu, who has a lot of experience making SIMD work for games. His proposal was: 1. Have native SIMD types. This will guarantee alignment, and will guarantee a compile time error for SIMD types that are not supported by the CPU. 2. Have the compiler issue an error for SIMD operations that are not supported by the CPU, rather than silently generating inefficient workaround code. 3. There are all kinds of weird but highly useful SIMD instructions that don't have a straightforward representation in high level code, such as saturated arithmetic. Manu's answer was to expose these instructions via intrinsics, so the user can string them together, be sure that they will generate real SIMD instructions, while the compiler can deal with register allocation. This approach works, is inlineable, generates code as good as hand-built assembler, and is useable by regular programmers. I won't say there aren't better approaches, but this one we know works.
Re: A little Py Vs C++
On Friday, 2 November 2012 at 08:38:21 UTC, Don Clugston wrote: On 02/11/12 09:07, Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. He just knows how to convince Walter. (Hint: use real-world use cases. Arguments from theoretical computer science carry almost no weight with Walter). Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. Yes, and they could cure cancer. AST macros can do anything, because they are completely undefined. Without even a vague proposal, it seems like a rather meaningless term. How do you think people came up with those bug reports? By some magic? :) You think they did not actually *pull their hair off* trying to figure out why their REAL LIFE program does not work, and when we could not find the reason we naturally started thinking oh, it might be yet another missing thing in D or oh, yet another DMD/phobos/druntime bug!... Or, another scenario (a very typical one) - after DMD/phobos/druntime is updated, my production application no longer compiles...
Re: A little Py Vs C++
On 2012-11-02 09:38, Don Clugston wrote: Yes, and they could cure cancer. AST macros can do anything, because they are completely undefined. Without even a vague proposal, it seems like a rather meaningless term. I know, I know. It's be brought up before and without any more detailed specification/definition is hard to do anything about it. I've done some research in the subject in the hope I can write down something useful that could be a proposal for D, but I don't have anything yet. -- /Jacob Carlborg
Re: Simple implementation of __FUNCTION
On 02-11-2012 18:31, Rob T wrote:
Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception errors.
Here's what I did.
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
The ONLY thing left that I would like to have, is ability to display the
function signature along with the name. The signature will be very
useful to show which version of an overloaded or templated function was
called.
If anyone can suggest imporvements, like how to get rid of need to
explicitly call mixin, and better yet a solution to get the function
signature, please post away. Thanks!
I have to mention that we need a real solution that can only be provided
through improved reflection support, eg __scope.function, __scope.line,
__scope.file, etc, or whatever the D community thinks will fit in best.
--rt
You should totally submit this for inclusion into std.traits in Phobos.
(Though, to follow naming conventions, it should be functionName and
functionSignature or so.)
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Simple implementation of __FUNCTION
On Fri, 02 Nov 2012 18:06:19 -, Alex Rønne Petersen a...@lycus.org
wrote:
On 02-11-2012 18:31, Rob T wrote:
Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception
errors.
Here's what I did.
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent,
{}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
The ONLY thing left that I would like to have, is ability to display the
function signature along with the name. The signature will be very
useful to show which version of an overloaded or templated function was
called.
If anyone can suggest imporvements, like how to get rid of need to
explicitly call mixin, and better yet a solution to get the function
signature, please post away. Thanks!
I have to mention that we need a real solution that can only be provided
through improved reflection support, eg __scope.function, __scope.line,
__scope.file, etc, or whatever the D community thinks will fit in best.
--rt
You should totally submit this for inclusion into std.traits in Phobos.
(Though, to follow naming conventions, it should be functionName and
functionSignature or so.)
+1 :)
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: A little Py Vs C++
On 2012-11-02 19:03, Dejan Lekic wrote: How do you think people came up with those bug reports? By some magic? :) You think they did not actually *pull their hair off* trying to figure out why their REAL LIFE program does not work, and when we could not find the reason we naturally started thinking oh, it might be yet another missing thing in D or oh, yet another DMD/phobos/druntime bug!... Or, another scenario (a very typical one) - after DMD/phobos/druntime is updated, my production application no longer compiles... Good point. When you do put the whole real life program in the bug report it's too big, you need to create a small test case. When you do create a small test case for the feature/bug it's suddenly not real life code. -- /Jacob Carlborg
Re: A little Py Vs C++
Le 02/11/2012 18:46, Andrei Alexandrescu a écrit : On 11/2/12 1:22 PM, Walter Bright wrote: On 11/2/2012 2:01 AM, Jens Mueller wrote: I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post). I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. Andrei I still don't understand the benefice over align(16) float[4] .
Re: A little Py Vs C++
On Fri, 02 Nov 2012 18:10:39 -, deadalnix deadal...@gmail.com wrote: Le 02/11/2012 18:46, Andrei Alexandrescu a écrit : On 11/2/12 1:22 PM, Walter Bright wrote: On 11/2/2012 2:01 AM, Jens Mueller wrote: I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post). I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. Andrei I still don't understand the benefice over align(16) float[4] . http://forum.dlang.org/thread/jauixhakwvpgsghap...@forum.dlang.org?page=4#post-k711rd:242786:242:40digitalmars.com R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Simple implementation of __FUNCTION
On Fri, Nov 02, 2012 at 07:06:19PM +0100, Alex Rønne Petersen wrote:
On 02-11-2012 18:31, Rob T wrote:
[...]
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
[[...]
You should totally submit this for inclusion into std.traits in Phobos.
(Though, to follow naming conventions, it should be functionName and
functionSignature or so.)
[...]
+1.
T
--
Тише едешь, дальше будешь.
Re: A little Py Vs C++
On 2012-11-02 18:22, Walter Bright wrote: It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post). I can absolutely see the point in this. Thanks for taking the time and explaining this. -- /Jacob Carlborg
Re: A little Py Vs C++
On 2012-11-02 18:46, Andrei Alexandrescu wrote: I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. -- /Jacob Carlborg
Re: Simple implementation of __FUNCTION
Sweet! You may also find my pull request for phobos ( #863,
fullyQualifiedTypename ) useful for adding function signature
once it gets finalised and merged.
On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
Thanks to input from the D community, I've managed to implement
a reasonable way to log the name of a calling function. This is
used for basic execution monitoring and for automated logging
of exception errors.
Here's what I did.
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier,
__traits(parent, {}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
The ONLY thing left that I would like to have, is ability to
display the function signature along with the name. The
signature will be very useful to show which version of an
overloaded or templated function was called.
If anyone can suggest imporvements, like how to get rid of need
to explicitly call mixin, and better yet a solution to get the
function signature, please post away. Thanks!
I have to mention that we need a real solution that can only be
provided through improved reflection support, eg
__scope.function, __scope.line, __scope.file, etc, or whatever
the D community thinks will fit in best.
--rt
Re: A little Py Vs C++
Le 02/11/2012 19:19, Jacob Carlborg a écrit : On 2012-11-02 18:46, Andrei Alexandrescu wrote: I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. I couldn't agree more.
Re: A little Py Vs C++
On Friday, 2 November 2012 at 18:19:54 UTC, Jacob Carlborg wrote: On 2012-11-02 18:46, Andrei Alexandrescu wrote: I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. So true. Strong mid-term vision of rationales of main language developers really helps to reason about it.
Re: D vs C++11
On 2012-11-02 18:03, Erèbe wrote: Hello student here, I have started to learn D a few months ago with Andrei's book (I really liked arguments about design decisions), but as the same time I was learning new features of C++11, and now I'm really confused. (As learning projects, I've done an IRC Bot in D and an IPv6 stack in C++11) D is a great language and introduce a lot of features I really like (range, property, UFCS, great metaprogramming, ...) but C++11 and the new standard librairy are well supported now. I have some solid experience with C++, so I know how cumbersome C++ could be (C++11 and universal reference ?), but D has a lot of features too and (as C++) a slow learning curve. I would say that D is fairly scalable in it's set of features. You can (mostly) program in D as you would in, say, Java. Then you can start bringing in more features of the language as you see fit in your own comfortable speed. I would like to konw the point of view of the community about C++11 in regard of D ? Is the gap between D and C++11 is getting thinner ? Do you think D will keep attracting people while at the same time C++11 has more support (debugger, IDE, Librairies, Documentation) ? I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. -- /Jacob Carlborg
Re: A little Py Vs C++
On 11/2/2012 11:19 AM, Jacob Carlborg wrote: I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. I apologize for being circumspect about this, but I have to respect peoples' privacy and I cleared what I posted about Remedy with them before posting it.
Re: Simple implementation of __FUNCTION
On 2012-11-02 18:31, Rob T wrote:
Thanks to input from the D community, I've managed to implement a
reasonable way to log the name of a calling function. This is used for
basic execution monitoring and for automated logging of exception errors.
Here's what I did.
template __FUNCTION()
{
const char[] __FUNCTION = __traits(identifier, __traits(parent, {}));
}
Example use in code:
throw new Exception( Error: Function , mixin(__FUNCTION!()) );
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION!()), __LINE__ );
That's pretty darn cool, well done :D .
--
/Jacob Carlborg
Re: A little Py Vs C++
Le 02/11/2012 19:25, mist a écrit : On Friday, 2 November 2012 at 18:19:54 UTC, Jacob Carlborg wrote: On 2012-11-02 18:46, Andrei Alexandrescu wrote: I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. So true. Strong mid-term vision of rationales of main language developers really helps to reason about it. Yeah, and avoid noise and help people concentrate on main points.
Re: A little Py Vs C++
Uh oh, I just caught wind of this thread! ;) If there's a single argument I'd like to make in defense of the changes that have gone through as a result of my motivating, it's that they're either big tickets and mutually beneficial for the whole community anyway (DMD-win64), or relatively trivial (function prototypes + definitions) details that enable us to realistically consider proceeding with D commercially. The SIMD types support may be considered a little grey, but I've encountered loads of general D users who appreciate the SIMD work already, and while it's certainly not trivial, it's nowhere the mammoth scale of task auto-vectorisation would be. I can't see it as a loss for the language or the community, and again, it has further enabled our consideration of D commercially; which I'd like to think is a general goal for the language. I know plenty of you don't care about me or my industry, but I maintain that it's an entire industry in desperate need of salvation from C++, there's a lot of potential in the games industry to get fantastic value from using D, and I'm interested in proving that it's a realistic consideration. I'd also like to note that we are also very conscious of the time Walter and other contributors have kindly offered to our support, and we are hopeful to be able to give reasonable value back to the community should it all go well for us, in whatever way that manifests... On 2 November 2012 11:01, Jens Mueller jens.k.muel...@gmx.de wrote: Jacob Carlborg wrote: On 2012-11-01 23:51, Walter Bright wrote: What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least! :-) As for Manu's request http://d.puremagic.com/issues/show_bug.cgi?id=8108 I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application. This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language. I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. Why do I vote anyway? Regarding SIMD I have the feeling that because it is built into the compiler static vectors have actually failed what they promised. I thought D proposed a portable way of vector operations such that you write float[4] = a[] + b[] and the compiler generates SIMD code for you. As I mentioned above, I think that is a MUCH larger task, and probably fairly unrealistic in the near-term regardless. But secondly, it's just not that simple. (I can see Walter has already addressed it in a previous post) It's worth considering that a very significant portion of the silicon on modern processors (well in excess of 50% on some chips) is dedicated to hardware acceleration of SIMD/media functions. Until recently, D simply offered no mechanism at all to interact with half of the silicone in your box. That's a massive language hole. At least as a starting point, low level access to this hardware is vital. Portable libraries can be built using this technology, which are immediately useful. The definition of hardware SIMD types doesn't rule out possible future auto-vectorisation either. And you can probably access auto-vectorising backends right now if you use GDC or LDC.
Re: A little Py Vs C++
On 2 November 2012 19:32, Andrej Mitrovic andrej.mitrov...@gmail.comwrote: On 11/2/12, Walter Bright newshou...@digitalmars.com wrote: Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. Wow that's really cool! Manu if you know of any trivial-type bugs you'd like to get fixed (for example error messages) let me know so I can prioritize them. There's a ton of open issues and I usually select the ones for fixing by random. I've managed to fix a few so far. :) Hey cheers man! :) Actually, one thing that does consistently bite me are nonsensical error messages. I'll start keeping tabs on them.
Re: A little Py Vs C++
On 2 November 2012 20:02, Walter Bright newshou...@digitalmars.com wrote: On 11/2/2012 3:50 AM, Jens Mueller wrote: Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting? Another excellent question. Most languages have taken the auto-vectorization approach of reverse engineering loops to turn them into high level constructs, and then compiling the code into special SIMD instructions. How to do this is explained in detail in the (rare) book The Software Vectorization Handbook by Bik, which I fortunately was able to obtain a copy of. This struck me as a terrible approach, however. It just seemed stupid to try to teach the compiler to reverse engineer low level code into high level code. A better design would be to start with high level code. Hence, the appearance of D vector operations. The trouble with D vector operations, however, is that they are too general purpose. The SIMD instructions are very quirky, and it's easy to unwittingly and silently cause the compiler to generate absolutely terribly slow code. The reasons for that are the alignment requirements, coupled with the SIMD instructions not being orthogonal - some operations work for some types and not for others, in a way that is unintuitive unless you're carefully reading the SIMD specs. Just saying align(16) isn't good enough, as the vector ops work on slices and those slices aren't always aligned. So each one has to check alignment at runtime, which is murder on performance. If a particular vector op for a particular type has no SIMD support, then the compiler has to generate workaround code. This can also have terrible performance consequences. So the user writes vector code, benchmarks it, finds zero improvement, and the reasons why will be elusive to anyone but an expert SIMD programmer. (Auto-vectorizing technology has similar issues, pretty much meaning you won't get fast code out of it unless you've got a habit of examining the assembler output and tweaking as necessary.) Enter Manu, who has a lot of experience making SIMD work for games. His proposal was: 1. Have native SIMD types. This will guarantee alignment, and will guarantee a compile time error for SIMD types that are not supported by the CPU. 2. Have the compiler issue an error for SIMD operations that are not supported by the CPU, rather than silently generating inefficient workaround code. 3. There are all kinds of weird but highly useful SIMD instructions that don't have a straightforward representation in high level code, such as saturated arithmetic. Manu's answer was to expose these instructions via intrinsics, so the user can string them together, be sure that they will generate real SIMD instructions, while the compiler can deal with register allocation. Well, I wouldn't claim any credit for the approach ;) .. I think this is the standard for maximum performance, and also very well understood. But the thing that excites me most is the potential quality of libraries that can be built on top. D has so much potential to extend on this SIMD foundation with it's templates being able to intelligently handle far more context specific situations. What we do already in other languages will be far more convenient, more portable, and possibly even produce better code in D. And the biggest bonus, it will be readable! :) I think it's a low risk investment, and it doesn't prohibit higher level support in the future. This approach works, is inlineable, generates code as good as hand-built assembler, and is useable by regular programmers. I won't say there aren't better approaches, but this one we know works. Aye, and it's relatively un-intrusive too. Some new types and a few intrinsics, build useful libraries on top. It shouldn't have complex side effects, and if offers something that was sorely missing from the language today.
Re: 'with' bug?
Faux Amis: When talking about global variables are we talking about module scope variables? Right, in D with global scope I meant module scope. As I see the module as the most primary data encapsulation in D, I often use module scope variables (in combo with static import). In my opinion that's a bad practice in D. I didn't know you could shadow globals and in my situation it sounds bug prone. It's not terrible, I am able to write code. But I think it doesn't help. Bye, bearophile
Re: A little Py Vs C++
On 2 November 2012 20:10, deadalnix deadal...@gmail.com wrote: Le 02/11/2012 18:46, Andrei Alexandrescu a écrit : On 11/2/12 1:22 PM, Walter Bright wrote: On 11/2/2012 2:01 AM, Jens Mueller wrote: I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones. It's a very fair question. Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence. Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post). I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. Andrei I still don't understand the benefice over align(16) float[4] . It's a mechanism to insist on register placement and usage semantics. On the vast majority of architectures, floats and simd are absolutely incompatible. It's awfully dangerous to describe them both with a single type when they are mutually exclusive...
Re: A little Py Vs C++
On 2 November 2012 20:19, Jacob Carlborg d...@me.com wrote: On 2012-11-02 18:46, Andrei Alexandrescu wrote: I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision. I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. This is probably my fault, and a matter of corporate transparency. We didn't want to make a noise about it until we reached a particular level of confidence. We're fairly invested now, and quietly hopeful it will go ahead from here.
Re: A little Py Vs C++
On 2 November 2012 20:36, Walter Bright newshou...@digitalmars.com wrote: On 11/2/2012 11:19 AM, Jacob Carlborg wrote: I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community. I apologize for being circumspect about this, but I have to respect peoples' privacy and I cleared what I posted about Remedy with them before posting it. That said, I think we'd perhaps appreciate that it doesn't appear all over the internets just yet. It would be much more interesting, and probably have a lot more impact if we made such an announcement alongside something to show.
Re: D vs C++11
Jacob Carlborg: I would say that D is fairly scalable in it's set of features. You can (mostly) program in D as you would in, say, Java D offers most features present in Java, but the relative efficiency of some operations is not the same. HotSpot de-virtualizes, unroll run-time-bound loops, and most importantly has an efficient generational GC (and other newer GCs like G1) that changes significantly the efficiency of allocations and memory releases. The result is that if you program in D creating lot of short lived garbage as you do in Java, you will see a low(er) performance. So in D it's better to allocate in-place with structs where possible. I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. C++ is a moving target :-) http://root.cern.ch/drupal/content/c14 Bye, bearophile
Re: A little Py Vs C++
On 2012-11-02 19:36, Walter Bright wrote: I apologize for being circumspect about this, but I have to respect peoples' privacy and I cleared what I posted about Remedy with them before posting it. This has nothing to do with what Manu does for a living (sure, mentioning Remedy gives it more weight, at least for me). It's more in the line of creating a post/starting a new thread saying something like: After a throughout discussion with Manu (or 'a fellow D programmer' if he/she prefers to be anonymous) we have decided it would be in best interest of D if we implement this particular feature. From now on this is where I will focus most most of my time. Something like this would be far better then suddenly seeing commits regarding SIMD (or whatever feature it might be) for out of the blue. -- /Jacob Carlborg
Re: A little Py Vs C++
On 2012-11-02 20:22, Manu wrote: This is probably my fault, and a matter of corporate transparency. We didn't want to make a noise about it until we reached a particular level of confidence. We're fairly invested now, and quietly hopeful it will go ahead from here. This has nothing to do with corporate transparency. It has to do with transparency to the community, see my reply to Walter: http://forum.dlang.org/thread/jauixhakwvpgsghap...@forum.dlang.org?page=6#post-k718iu:242iu6:241:40digitalmars.com -- /Jacob Carlborg
Re: mixin functions
On 1 November 2012 17:58, Gor Gyolchanyan gor.f.gyolchan...@gmail.comwrote:
OR, better yet:
mixin MyMixin
{
foreach(i; 0..10)
MyMixin ~= writeln( ~ to!string(i); ~ );\n'
}
And this could be printed out as a pragma(msg, ...) or into a .log file or
anywhere else. This way it's easy to see what did end up being mixed in.
I bumped into this today actually. It's certainly a nice idea.
I see a lot of noise about said AST macros...
I understand the idea, but I have no idea how it might look in practice.
Are there any working proposals?
I find myself using mixins wy too much. They're just too convenient,
and enable lots of things that just aren't possible any other way. But I
always feel really dirty! It can be so tedious dealing with all the string
mess.
Re: D vs C++11
On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote: I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. Serious? It doesn't even have a static if.
Re: Transience of .front in input vs. forward ranges
On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote: Ah, I see. That makes sense. So basically it's not the source (or any intermediate step) that decides whether to use the optimization, but the final consumer. Though now we have the issue that all intermediate ranges must propagate .fast, which is troublesome if every range has to do it manually. Can this be handled automatically by UFCS? It's no different form propogating slicing or random access or whatnot. Wrapper ranges have to look at the capabilities of the ranges that they're wrapping and create wrappers for each of the range functions where appropriate. If we added isTransient or fastRange or whatever, wrapper ranges would then have to take it into account, or the wrapper wouldn't have it. - Jonathan M Davis
Re: A little Py Vs C++
After a throughout discussion with Manu (or 'a fellow D programmer' if he/she prefers to be anonymous) we have decided it would be in best interest of D if we implement this particular feature. From now on this is where I will focus most most of my time. Something like this would be far better then suddenly seeing commits regarding SIMD (or whatever feature it might be) for out of the blue. SIMD support was discussed here at length in the days before it was implemented. See this thread: http://forum.dlang.org/thread/jdhb57$10vf$1...@digitalmars.com#post-wdjdcrkiaakmkzqtdhxu:40dfeed.kimsufi.thecybershadow.net and this thread: http://forum.dlang.org/post/mailman.76.1325814175.16222.digitalmar...@puremagic.com
Re: D vs C++11
On Friday, 2 November 2012 at 20:12:05 UTC, so wrote: On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote: I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. Serious? It doesn't even have a static if. .. and not even an array type, or string type, and the template system remains in a semi-useless state in terms of practicality. But it is true that C++11 has added features that attempt to catch up. I recall being very eager to try the new improvements out as soon as they were available, yet soon afterwards I find myself investing my time in D. C++ is permanently bogged down by too much legacy features that are difficult to remove or repair, and I'm convinced that C++ cannot be fixed without a redesign from the ground up. D has effectively fixed C++ already, so I agree with the claims that D can be considered as a good C++ replacement. Also I expect that D will continue to evolve and improve, so it may be that C++ can never catch up. --rt
Re: D vs C++11
On Friday, November 02, 2012 21:12:02 so wrote: On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote: I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. Serious? It doesn't even have a static if. C++11 definitely makes the gap thinner than it was with C++98/03. That doesn't mean that the gap isn't there, and with pretty much anything involving conditional compilation, D is way, way ahead of C++11. C++ templates are virtually unusable in comparison to D templates. There's no reason that C++ couldn't gain those abilities, but even with C++11, it still isn't there yet (though at least they finally have variadic templates). That said, there _are_ some cool things in C++11 that we don't have (e.g. async is pretty cool, and while we have some cool threading stuff, we don't have anything quite like it yet). So, we can still learn from C++ even if we do better than they do in general. - Jonathan M Davis
Re: Simple implementation of __FUNCTION
On Friday, 2 November 2012 at 17:55:33 UTC, Adam D. Ruppe wrote:
The ONLY thing left that I would like to have, is ability to
display the function signature along with the name.
template __FUNCTION_SIGNATURE() { const char[]
__FUNCTION_SIGNATURE = typeof(__traits(parent, {})).stringof;
}
int main(string[] args) {
assert(0, mixin(__FUNCTION_SIGNATURE!()));
}
core.exception.AssertError@test4.d(7): int(string[] args)
That was fast, thanks!
template __PRETTY_FUNCTION()
{
const char[] __PRETTY_FUNCTION = __traits(identifier,
__traits(parent, {})) ~ ~ __FUNCTION_SIGNATURE!();
}
--rt
Re: Simple implementation of __FUNCTION
By changing this to a standard function:
const(char[]) __FUNCTION() @property
{
return __traits(identifier, __traits(parent, {}));
}
... the calling syntax is slightly easier on the eye:
void main()
{
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION), __LINE__ );
//throw new Exception( Error: Function ~ mixin(__FUNCTION) );
}
That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
Is there any downside to this?
Re: A little Py Vs C++
On Friday, 2 November 2012 at 14:22:34 UTC, Jens Mueller wrote: But the compiler knows about the alignment, doesn't it? align(16) float[4] a; vs float[4] a; In the former case the compiler can generate better code and it should. The above syntax is not supported. But my point is all the compiler cares about is the alignment which can be specified in the code somehow. Sorry for being stubborn. Jens Note: My knowledge of SIMD/SSE is fairly limited, and may be somewhat out of date. In other words, some of this may be flat out wrong. First, just because you have something that can have SIMD operations performed on it, doesn't mean you necessarily want to. SSE instructions for example have to store things in the XMM registers, and accessing the actual values of individual elements in the vector is expensive. When using SSE, you want to avoid accessing individual elements as much as possible. Not following this tends to hurt performance quite badly. Yet when you just have a float[4], you may or may not be frequently or infrequently accessing individual elements. The compiler can't know whether you use it as a single SIMD vector more often, or use it to simply store 4 elements more often. You could be aligning it for any reason, so it's not too fair a way of determining it. Secondly, you can't really know which SIMD instructions are supported by your target CPU. It's safe to say SSE2 is supported for pretty much all x86 CPUs at this point, but something like SSE4.2 instructions may not be. Just because the compiler knows that the CPU compiling it supports it doesn't mean that the CPU running the program will have those instructions. Lastly, we'd still need SIMD intrinsics. It may be simple to tell that a float[4] + float[4] operation could use addps, but it would be more difficult to determine when to use something like dotps (dot product across two SIMD vectors), and various other instructions. Not to mention, non-x86 architectures.
Re: D vs C++11
On 2012-11-02 21:12, so wrote: Serious? It doesn't even have a static if. I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. -- /Jacob Carlborg
Re: A little Py Vs C++
On 2012-11-02 21:22, jerro wrote: SIMD support was discussed here at length in the days before it was implemented. See this thread: Yeah, I know it's been talked about and discussed, but it's the final decision that's missing. -- /Jacob Carlborg
Re: mixin functions
On 2012-11-02 21:03, Manu wrote: I bumped into this today actually. It's certainly a nice idea. I see a lot of noise about said AST macros... I understand the idea, but I have no idea how it might look in practice. Are there any working proposals? No, not for D. But there are several other languages that have AST macros: Scala: http://scalamacros.org/ Nimrod: (templates and macros) http://nimrod-code.org/tut2.html#templates Nemerle: http://nemerle.org/wiki/index.php?title=Macros Nemerle also supports creating new syntax for the language. -- /Jacob Carlborg
Re: D vs C++11
On 11/2/2012 2:33 PM, Jacob Carlborg wrote: I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.
Re: Simple implementation of __FUNCTION
On Friday, November 02, 2012 22:34:15 Philippe Sigaud wrote:
By changing this to a standard function:
const(char[]) __FUNCTION() @property
{
return __traits(identifier, __traits(parent, {}));
}
... the calling syntax is slightly easier on the eye:
void main()
{
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION), __LINE__ );
//throw new Exception( Error: Function ~ mixin(__FUNCTION) );
}
That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
Is there any downside to this?
Identifiers starting with __ are reserved for the compiler/language. It should
be __FUNCTION__ if it's built-in, but if it's in the library, I see no reason
to name it in a way that conflicts with Phobos' naming conventions like this.
- Jonathan M Davis
Re: D vs C++11
On Fri, 02 Nov 2012 21:25:49 +0100 Rob T r...@ucora.com wrote: On Friday, 2 November 2012 at 20:12:05 UTC, so wrote: On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote: I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. Serious? It doesn't even have a static if. .. and not even an array type, or string type, and the template system remains in a semi-useless state in terms of practicality. But it is true that C++11 has added features that attempt to catch up. I recall being very eager to try the new improvements out as soon as they were available, yet soon afterwards I find myself investing my time in D. C++ is permanently bogged down by too much legacy features that are difficult to remove or repair, and I'm convinced that C++ cannot be fixed without a redesign from the ground up. D has effectively fixed C++ already, so I agree with the claims that D can be considered as a good C++ replacement. Also I expect that D will continue to evolve and improve, so it may be that C++ can never catch up. ///ditto To be fair though, asking C++ vs D on a D newsgroup is clearly going to be tilted more towards the D end ;) But yea, personally, I feel that C++11 is merely playing catch up, and doing so on a broken leg. C++ does have the advantage of being almost universally supported with mature toolchains on pretty much any platform. D's toolchain is very mature on Linux, OSX and (aside from the COFF/OMF stuff) Win32, but still needs work for other platforms and also could use some work for dynamic libs. So whenever D is a viable option, I always go for it because I find it to be vastly superior, even to C++11 (which is merely slightly less crappy than old C++, IMO). And then when I *have* to use C++, I do so while wishing I was doing it in D. FWIW, I did this little writeup (ok, rant ;) ) on my opinion of C++ vs D: https://semitwist.com/articles/article/view/top-d-features-i-miss-in-c
Re: Simple implementation of __FUNCTION
On 11/02/2012 10:34 PM, Philippe Sigaud wrote:
By changing this to a standard function:
const(char[]) __FUNCTION() @property
{
return __traits(identifier, __traits(parent, {}));
}
... the calling syntax is slightly easier on the eye:
void main()
{
writefln( File: %s, Func: %s, Line: %d, __FILE__,
mixin(__FUNCTION), __LINE__ );
//throw new Exception( Error: Function ~ mixin(__FUNCTION) );
}
That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
Is there any downside to this?
I'd make it
enum currentFunction = q{ __traits(identifier, __traits(parent, {})) };
Re: A little Py Vs C++
Walter Bright wrote: On 11/2/2012 3:50 AM, Jens Mueller wrote: Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting? Another excellent question. Most languages have taken the auto-vectorization approach of reverse engineering loops to turn them into high level constructs, and then compiling the code into special SIMD instructions. How to do this is explained in detail in the (rare) book The Software Vectorization Handbook by Bik, which I fortunately was able to obtain a copy of. This struck me as a terrible approach, however. It just seemed stupid to try to teach the compiler to reverse engineer low level code into high level code. A better design would be to start with high level code. Hence, the appearance of D vector operations. The trouble with D vector operations, however, is that they are too general purpose. The SIMD instructions are very quirky, and it's easy to unwittingly and silently cause the compiler to generate absolutely terribly slow code. The reasons for that are the alignment requirements, coupled with the SIMD instructions not being orthogonal - some operations work for some types and not for others, in a way that is unintuitive unless you're carefully reading the SIMD specs. Just saying align(16) isn't good enough, as the vector ops work on slices and those slices aren't always aligned. So each one has to check alignment at runtime, which is murder on performance. If a particular vector op for a particular type has no SIMD support, then the compiler has to generate workaround code. This can also have terrible performance consequences. So the user writes vector code, benchmarks it, finds zero improvement, and the reasons why will be elusive to anyone but an expert SIMD programmer. (Auto-vectorizing technology has similar issues, pretty much meaning you won't get fast code out of it unless you've got a habit of examining the assembler output and tweaking as necessary.) Enter Manu, who has a lot of experience making SIMD work for games. His proposal was: 1. Have native SIMD types. This will guarantee alignment, and will guarantee a compile time error for SIMD types that are not supported by the CPU. 2. Have the compiler issue an error for SIMD operations that are not supported by the CPU, rather than silently generating inefficient workaround code. 3. There are all kinds of weird but highly useful SIMD instructions that don't have a straightforward representation in high level code, such as saturated arithmetic. Manu's answer was to expose these instructions via intrinsics, so the user can string them together, be sure that they will generate real SIMD instructions, while the compiler can deal with register allocation. This approach works, is inlineable, generates code as good as hand-built assembler, and is useable by regular programmers. I won't say there aren't better approaches, but this one we know works. I see. Thanks for clarifying. If I want fast vector operations I have to use core.simd. The built-in vector operations won't fit the bill. I was of the opinion that a vector operation in D should (at some point) generate vectorized code. Jens
Re: Simple implementation of __FUNCTION
On Fri, Nov 2, 2012 at 10:59 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
Is there any downside to this?
Identifiers starting with __ are reserved for the compiler/language. It should
be __FUNCTION__ if it's built-in, but if it's in the library, I see no reason
to name it in a way that conflicts with Phobos' naming conventions like this.
Er, yes, but __FUNCTION comes the OP. My question was more about using
a function instead of a template.
And Timon makes a good point, using a token string q{ } should make
this more mixin-able.
Re: D vs C++11
On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote: On 11/2/2012 2:33 PM, Jacob Carlborg wrote: I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this. Agree with everything, but D is a hard sell in the enterprise given C++'s maturity.
