Re: DStep - Bindings Generator 0.0.1
On 7/7/12, Jacob Carlborg d...@me.com wrote:
snip
Nice work!
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
Re: DStep - Bindings Generator 0.0.1
On 2012-07-20 15:04, Andrej Mitrovic wrote:
Nice work!
Thanks.
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
Don't know, sorry. I have only worked with C and Objective-C code. I can
see if I can find out.
--
/Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2012-07-20 15:04, Andrej Mitrovic wrote:
On 7/7/12, Jacob Carlborg d...@me.com wrote:
snip
Nice work!
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
In libclang, the kind of Foo::Val1 in the above example is:
CXCursor_FirstExpr - CXCursor_DeclRefExpr - CXCursor_NamespaceRef.
What I did here was I checked the kind of Foo::Val1 cursor, drilled
down into the cursor children as far as possible.
Cursor kinds:
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013
--
/Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 7/20/12, Jacob Carlborg d...@me.com wrote: In libclang, the kind of Foo::Val1 in the above example is: CXCursor_FirstExpr - CXCursor_DeclRefExpr - CXCursor_NamespaceRef. What I did here was I checked the kind of Foo::Val1 cursor, drilled down into the cursor children as far as possible. Cursor kinds: http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013 Cool, this will come in handy. Thanks.
Re: DStep - Bindings Generator 0.0.1
On 7/7/12, Walter Bright newshou...@digitalmars.com wrote: so you could do things like: import stdio.h; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. Personally I think this is heading in the wrong direction. A D user shouldn't have to deal with C syntax or peculiarities of wrapper libraries, the experience of using a wrapper library should be as transparent as possible. Such a wrapper library should look just like any other D library to the user. Wrapper maintainers can use tools to generate bindings, and the users might have their own tools such as a package manager to make discovery installation of those libraries easy. There's compile-time performance issues to consider. Sure, you could cache the results of generating a library, but this is still a penalty because every user will have to wait for that import statement to finish the first time and cache the results before they can use the library, as opposed to the traditional way of downloading a maintained wrapper library which you don't have to re-wrap but just need to compile. I don't mean to sound discouraging, and this all might work for simple C libraries and Dstep, but there's a penalty for introducing special syntax and semantics into D for something that can be and is usually done externally by wrapper maintainers (think how we're always trying to move things away from the D language and replace it with more flexible and more easily debuggable library features). Maybe this feature would look great in a D vs Go comparison table, but I don't see the benefit of such a magical feature. I'd rather we have a package manager instead, which incidentally again Jacob is working on. Incidentally I'm also working on my own wrapper generator, although this one handles C and C++. But it won't be done soon (it's close though).
pfft 0.1
I'm announcing the release of pfft, a fast FFT written in D. Code: https://github.com/jerro/pfft/ Downloads: https://github.com/jerro/pfft/downloads Documentation: http://jerro.github.com/pfft/doc/pfft.pfft.html Benchmarks: http://jerro.github.com/pfft/benchmarks/
Re: pfft 0.1
jerro: I'm announcing the release of pfft, a fast FFT written in D. Everything looks nice. Are you using in, pure/nothrow/immutable/const enough? Is it worth changing the Phobos API to something similar to this API? Bye, bearophile
Re: pfft 0.1
On Friday, 20 July 2012 at 23:36:37 UTC, bearophile wrote: jerro: I'm announcing the release of pfft, a fast FFT written in D. Everything looks nice. Are you using in, pure/nothrow/immutable/const enough? Not yet, but I plan to add those. Is it worth changing the Phobos API to something similar to this API? Pfft already includes an API that is compatible with the Phobos one (pfft.stdapi). But I don't think it makes any sense to change the Phobos API to something like pfft.pfft. The main difference between the two is that std.numeric.Fft uses interleaved format for sequences of complex numbers and pfft.pfft uses a split format. Interleaved format is more convenient in most cases and I think it's more intuitive too. The FFT in Phobos also works on ranges, while pfft.pfft only works on aligned arrays. The only reason the pfft.pfft works the way it does is that it is supposed to be an interface to the underlying implementation with no loss of performance and that is how the implementation works. Even if the implementation in Phobos did use split format, I think it would still be better to use interleaved format for the API. It's just about 30% slower and I think that a nice API is more important for the standard library than a 30% difference in speed. There is one more important difference in the API between std.numeric.Fft and pfft.pfft. With Phobos you can use one instance of Fft for all sizes and types. With pfft.pfft, the Fft class is parametrized with a floating point type and you need a different instance for each size. I think what Phobos does in this case is wrong. The fact that one class works on all floating point types results in very poor precision when the data consists of doubles or reals. I guess that precomputed tables are stored as floats. You could only fix that by saving them as reals, but that would probably hurt performance quite a lot. The fact that one instance can be used for multiple sizes would be a problem if we wanted to change an implementation since not all FFT implementation can use one precomputed table for different data sizes. Bye, bearophile
Re: pfft 0.1
jerro: Are all your benchmarks done on a 64 bit system? I think what Phobos does in this case is wrong. The fact that one class works on all floating point types results in very poor precision when the data consists of doubles or reals. I guess that precomputed tables are stored as floats. You could only fix that by saving them as reals, but that would probably hurt performance quite a lot. The fact that one instance can be used for multiple sizes would be a problem if we wanted to change an implementation since not all FFT implementation can use one precomputed table for different data sizes. If you are right and this is a problem, are Andrei and others accepting to change this little part of Phobos? If the answer is positive, are you interested in creating a GIT patch that changes that? Bye, bearophile
Re: pfft 0.1
Are all your benchmarks done on a 64 bit system? They are. Here's one comparison with 32 bit (for complex single precision transform using sse)if you are interested in that: http://imgur.com/CTuCD . The 32 bit executable is slower, probably because there are less general purpose and SSE registers on x86 than on x86_64. If you are right and this is a problem, are Andrei and others accepting to change this little part of Phobos? If the answer is positive, are you interested in creating a GIT patch that changes that? I think that poor precision is a problem. I have checked now and std.numeric.Fft does indeed use floats for the lookup table. The precision problem could be solved by either changing that to real or by changing Fft to a template and using whatever the type parameter is. Just changing float to real doesn't require changing the API, but would probably result in worse performance. I haven't talked to Andrei or others about changing it, but I am willing to write a patch that changes the API, if it would be decided that would be the best thing to do. If it would be decided that it's best to just change the type of the lookup table that's trivial anyway, since it's just one typedef.
Re: Just where has this language gone wrong?
On 07/19/2012 09:35 PM, Damian wrote: On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote: Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) It would be great if D did do this, surely it would not be all that difficult! and wouldn't it also help in finding unused variables? Walter doesn't like it. Past discussions: http://forum.dlang.org/post/gon06s$1nbe$1...@digitalmars.com http://forum.dlang.org/post/ha37cf$4l2$1...@digitalmars.com http://forum.dlang.org/post/i4mlee$5a2$1...@digitalmars.com
Re: reference to 'self' inside a function
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote: I propose to introduce a reference to the current function, much like 'this' in a class method. Call it 'self' or 'thisFunc', or whatever ... What might this be good for ? For implementing recursion in a lambda function. Writing in functional style, one creates many functions, and looking for reasonable names for these functions becomes unnecessarily painful. May I suggest the recur or recursive keyword? auto factorials = map!(n = n ? n * recur(n-1) : 1)([1, 2, 3]).array; assert(factorials == [1, 2, 6]); NMS
Re: Just where has this language gone wrong?
On 2012-07-20 00:05, Nick Sabalausky wrote: No, this is why any C/C++ project should be replaced by D ;) I'm knee-deep in a C++ project right now, and the language is such a pedantic, anachronistic turd. C++'s *only* saving graces are: - It's a systems language (ie, native compiled with low-level access). - It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash (aka Corona). - D isn't mature on all platforms yet. I used Boost, for a C++ project I was working on, to make it more D-like. Foreach, auto, lambda, default initialization and other things. Most of these things are available in C++11 now. -- /Jacob Carlborg
Re: Just where has this language gone wrong?
On 2012-07-20 00:32, David Piepgrass wrote: Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language. -- /Jacob Carlborg
Re: Just where has this language gone wrong?
Jacob Carlborg wrote in message news:juaudk$2slh$1...@digitalmars.com... On 2012-07-20 00:05, Nick Sabalausky wrote: No, this is why any C/C++ project should be replaced by D ;) I'm knee-deep in a C++ project right now, and the language is such a pedantic, anachronistic turd. C++'s *only* saving graces are: - It's a systems language (ie, native compiled with low-level access). - It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash (aka Corona). - D isn't mature on all platforms yet. I used Boost, for a C++ project I was working on, to make it more D-like. Foreach, auto, lambda, default initialization and other things. Most of these things are available in C++11 now. -- /Jacob Carlborg I like D as a better C++, but in face of the available tooling, libraries and with the support C++11 is getting lateley, I'm still using C++ for private projects, while at work I spend most of my time in JVM and .NET worlds. It is a case of worse is better. D, Go, Rust have a big problem to gain adoption in the native world renaissance. As another programing language to develop normal applications, there are already lots of more established languages. Even if a VM free language is the prefered tool, there are actually native code compilers for JVM/.NET languages, and even Microsoft seems to be planning to offer native code compiler for C#, from their job postings. To become a widspread systems programming language, D needs to get support from an OS or driver vendor. -- Paulo
Re: Just where has this language gone wrong?
On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote: On 2012-07-20 00:32, David Piepgrass wrote: Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it :) Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language. I think that the worse part of this is that it make integers and floats needlessly different.. renoX
std.random and mersenne twister
I read that default RNG in phobos is Mersenne Twister. I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) And of course it's very easy to implement: http://en.wikipedia.org/wiki/Multiply-with-carry#Implementation
Re: #d_lang ---- #dlang on Twitter?
On Friday, 20 July 2012 at 05:22:43 UTC, Andrei Alexandrescu wrote: On 7/19/12 7:33 PM, Masahiro Nakagawa wrote: On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei No, problem. Our official website is dlang.org :) If hashtag changed to #dlang, I announce this change to other Japanese programmers. Let's make it so. Thanks, Masahiro! Andrei No problem. I follow official decision.
Re: Random sampling in D -- blog post
On 19/07/12 23:33, Andrei Alexandrescu wrote: You should know Chrome displays quite a weird stub while loading that page over a slow connection. Ack. That'll be the way that Chrome handles embedded website fonts -- doesn't display _anything_ until the fonts have loaded. I really must try and find a way round that. That would be awesome, and we'd put it on the website. I'll see what I can do. :-)
Re: std.random and mersenne twister
On Friday, 20 July 2012 at 09:47:52 UTC, Andrea Fontana wrote: I read that default RNG in phobos is Mersenne Twister. I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) And of course it's very easy to implement: http://en.wikipedia.org/wiki/Multiply-with-carry#Implementation I'd say the problem is that it is not a very widespread or known PRNG. While I wouldn't be against adding it to the library (I see no reason not to add it), making it the _default_ PRNG is a whole other story. Users that choose default want something reliable, documented, trustworthy etc... Multiply With Carry seems like it is Cutting Edge to me, not yet widespread, known or tested. I'd say it should only be used by those that explicitly request it's usage.
Re: std.random and mersenne twister
On 20/07/12 11:47, Andrea Fontana wrote: I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) That reminds me ... it might be an idea to implement the Diehard tests for D, as part of a test suite for std.random. Rigorously testing pseudorandom functionality is not really my area of expertise, but it's something that is important to do for any code that might have a scientific application (quite early on in my experience of writing simulations, I had the lovely experience of having to rewrite and rerun a whole load of code because of poor RNG choice; fortunately it didn't affect anything that had been published). Some years ago, there was an observed departure from randomness in the default MATLAB RNG which must have resulted in all kinds of false conclusions and results being out there in the scientific literature. On the subject of default RNG -- the use of Mersenne Twister is very widespread as a default method (used in MATLAB/Octave, R, and it's the recommended method in GSL and Boost). So it may be a good default choice for D just by virtue of easy comparison with other tools.
Re: std.random and mersenne twister
CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. He also developed the Marsiglia's Theorem where he demonstrate that LCG (that is the default algorithm for many languages for ex: glibc and vc++ lib, ...) has big issues. LCG is very widespread but d doesn't use it (phew!). If a user know difference between PRNG algorithms can use MT, but as default for people that use weak C rand() function as default (that neither passes diehard tests) it can just be a good improvement (why should we give them MT that is slower than CMWC if they neither know default rand() weakness?) MT has a complex implementation, I hope std.random MT was tested :) Il giorno ven, 20/07/2012 alle 13.16 +0200, monarch_dodra ha scritto: On Friday, 20 July 2012 at 09:47:52 UTC, Andrea Fontana wrote: I read that default RNG in phobos is Mersenne Twister. I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) And of course it's very easy to implement: http://en.wikipedia.org/wiki/Multiply-with-carry#Implementation I'd say the problem is that it is not a very widespread or known PRNG. While I wouldn't be against adding it to the library (I see no reason not to add it), making it the _default_ PRNG is a whole other story. Users that choose default want something reliable, documented, trustworthy etc... Multiply With Carry seems like it is Cutting Edge to me, not yet widespread, known or tested. I'd say it should only be used by those that explicitly request it's usage.
Re: Add CTFE execute function
On 20/07/2012 03:08, Chang Long wrote: Let me make myself more clear, what I suggestion is something like this: mixin( std.process.execute(/usr/bin/template_engine template_file_path.htm) ); When translate the template code to D code, need a lot D type arguments information. And one Web application may need very many page, and the type may change frequently. If I am not doing it on the CTFE will geometric increase workload. If D want to be participants in the web field, I think that this feature sooner or later will be needed. By coincidence, Walter recently mentioned something similar being integrated into D to support DStep: http://forum.dlang.org/post/jta97l$10hm$1...@digitalmars.com So perhaps the above mixin would be: import template_file_path.htm; According to the link, that would execute: htm_to_D template_file_path.htm The htm_to_D program would generate a .d module which would then get imported. Nick
Re: std.random and mersenne twister
On 20/07/12 14:51, Andrea Fontana wrote: He also developed the Marsiglia's Theorem where he demonstrate that LCG (that is the default algorithm for many languages for ex: glibc and vc++ lib, ...) has big issues. C and C++ have the bad luck to have been created before many of the high-quality PRNGs were developed. A lot of scientific software now has MT as the default. I'd personally never heard of CMWC before this email exchange -- a nice discovery :-) MT has a complex implementation, I hope std.random MT was tested :) I doubt there's anything wrong with the MT implementation per se; it looks largely like a close match to that in the Boost C++ random library, and they certainly generate identical output. There is an issue with the seeding, that D's MT can only take a number as seed, not a sequence of numbers -- see: http://forum.dlang.org/thread/jr0luj$1ctj$1...@digitalmars.com But I agree that there should be a proper set of unittests for the PRNGs that really check their implementation. Personally if there is a flaw in the current D random number generation, my money would be on the unpredictableSeed being responsible. It's a hunch rather than something I can justify technically, but the method of generating that seed looks too simple to me -- I'd be worried that for some PRNGs, different threads might wind up with correlated random sequences by accident, because the different unpredictableSeeds would not be different enough. So, given that D looks to be gaining traction in various areas of scientific simulation, I think it'd be well worth trying to make sure that multithreaded pseudo-random number generation is really rigorously tested. Unfortunately I don't know what kinds of test would be appropriate here.
Re: std.random and mersenne twister
On Friday, 20 July 2012 at 12:51:25 UTC, Andrea Fontana wrote: CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. He also developed the Marsiglia's Theorem where he demonstrate that LCG (that is the default algorithm for many languages for ex: glibc and vc++ lib, ...) has big issues. LCG is very widespread but d doesn't use it (phew!). If a user know difference between PRNG algorithms can use MT, but as default for people that use weak C rand() function as default (that neither passes diehard tests) it can just be a good improvement (why should we give them MT that is slower than CMWC if they neither know default rand() weakness?) MT has a complex implementation, I hope std.random MT was tested :) Il giorno ven, 20/07/2012 alle 13.16 +0200, monarch_dodra ha scritto: On Friday, 20 July 2012 at 09:47:52 UTC, Andrea Fontana wrote: I read that default RNG in phobos is Mersenne Twister. I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) And of course it's very easy to implement: http://en.wikipedia.org/wiki/Multiply-with-carry#Implementation I'd say the problem is that it is not a very widespread or known PRNG. While I wouldn't be against adding it to the library (I see no reason not to add it), making it the _default_ PRNG is a whole other story. Users that choose default want something reliable, documented, trustworthy etc... Multiply With Carry seems like it is Cutting Edge to me, not yet widespread, known or tested. I'd say it should only be used by those that explicitly request it's usage. But Mersenne Twister has a cooler name :o) 'Multiply with carry' is so blah. You'll need to come up with a sexy new name for it. Cheers, Craig
Re: std.random and mersenne twister
Il giorno ven, 20/07/2012 alle 16.05 +0200, Craig Dillabaugh ha scritto: On Friday, 20 July 2012 at 12:51:25 UTC, Andrea Fontana wrote: CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. He also developed the Marsiglia's Theorem where he demonstrate that LCG (that is the default algorithm for many languages for ex: glibc and vc++ lib, ...) has big issues. LCG is very widespread but d doesn't use it (phew!). If a user know difference between PRNG algorithms can use MT, but as default for people that use weak C rand() function as default (that neither passes diehard tests) it can just be a good improvement (why should we give them MT that is slower than CMWC if they neither know default rand() weakness?) MT has a complex implementation, I hope std.random MT was tested :) Il giorno ven, 20/07/2012 alle 13.16 +0200, monarch_dodra ha scritto: On Friday, 20 July 2012 at 09:47:52 UTC, Andrea Fontana wrote: I read that default RNG in phobos is Mersenne Twister. I think it would be a good idea to replace it with complementary-multiply-with-carry (cmwc). CMWC is faster (use simpler math), has a longer period (standard implementation has a 2^131104 period vs 2^19937 of current MT implementation in phobos) and passed diehard tests (mt passes them too) And of course it's very easy to implement: http://en.wikipedia.org/wiki/Multiply-with-carry#Implementation I'd say the problem is that it is not a very widespread or known PRNG. While I wouldn't be against adding it to the library (I see no reason not to add it), making it the _default_ PRNG is a whole other story. Users that choose default want something reliable, documented, trustworthy etc... Multiply With Carry seems like it is Cutting Edge to me, not yet widespread, known or tested. I'd say it should only be used by those that explicitly request it's usage. But Mersenne Twister has a cooler name :o) 'Multiply with carry' is so blah. You'll need to come up with a sexy new name for it. Cheers, Craig Marsaglia Tornado?
Re: std.random and mersenne twister
On Friday, 20 July 2012 at 14:11:18 UTC, Andrea Fontana wrote: Il giorno ven, 20/07/2012 alle 16.05 +0200, Craig Dillabaugh ha scritto: On Friday, 20 July 2012 at 12:51:25 UTC, Andrea Fontana wrote: clip... But Mersenne Twister has a cooler name :o) 'Multiply with carry' is so blah. You'll need to come up with a sexy new name for it. Cheers, Craig Marsaglia Tornado? Very nice ... and it even uses the same acronym. Craig
Re: Just where has this language gone wrong?
Am Thu, 19 Jul 2012 22:43:17 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-07-19 16:50, Alex Rønne Petersen wrote: In C++ it's even better (irony). It depends on what kind of variable is declared. I.e. a global variable, a local, instance or a class variable (static). Some of these are default initialized, some are not. I have no idea which are initialized and which are not. I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_. If it is stored in the .exe, it is 0! -- Marco
Re: Just where has this language gone wrong?
On 2012-07-20 16:33, Marco Leise wrote: I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_. If it is stored in the .exe, it is 0! Is it defined what is placed in the executable? -- /Jacob Carlborg
Re: Rust updates
On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote: So I've taken another look at the Rust tutorial: http://dl.rust-lang.org/doc/tutorial.html Does it handle angle brackets well?
Semantics of postfix ops for classes
According to TDPL postfix operators are rewritten to call prefix
operators, e.g. on this call for some user-type object named a:
auto b = a++;
// is converted to:
auto b = ((ref x) { auto t = x; ++x; return t; })(a);
But I don't see how this is reasonable for classes. Examine:
struct Struct {
int x = 1;
Struct opUnary(string op : ++)() {
x++;
return this;
}
}
class Class {
int x = 1;
Class opUnary(string op : ++)() {
x++;
return this;
}
}
void main()
{
Struct foo1;
Struct foo2 = foo1++;
assert(foo1.x != foo2.x); // ok
Class bar1 = new Class;
Class bar2 = bar1++;
assert(bar1.x != bar2.x); // fail
}
It's clear why, the rewrite that calls auto t = x simply binds
another reference to the same object.
Unfortunately this makes it hard to wrap C++ libraries which have both
prefix/postfix operators defined. Currently I wrap these in e.g.
preInc/postInc methods and I explicitly disable the prefix/postfix
opUnary methods.
Are the semantics of this rewrite ok with people who use op overloads?
I found them to be surprising, but then again I don't use op overloads
that much, I'm just noticing the difference between C++ and D.
Re: Semantics of postfix ops for classes
On 7/20/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: According to TDPL Oh and that's page 369 for those wondering.
Re: std.random and mersenne twister
On 7/20/12 8:51 AM, Andrea Fontana wrote: CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. Would be great if you wanted to contribute an implementation of CMWC to std.random. Thanks, Andrei
Re: Just where has this language gone wrong?
On Friday, 20 July 2012 at 08:17:03 UTC, renoX wrote:
On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote:
On 2012-07-20 00:32, David Piepgrass wrote:
Actually, C# has no default initialization* of local
variables, and I love it. Instead, it is a compile-time error
to read a variable if the compiler cannot guarantee that you
have initialized it. IMO this is much better than D's let's
initialize doubles to NaN so that something fishy will happen
at runtime if you forget to initialize it :)
Floats and doubles initialized to NaN can be really annoying
when interfacing to C or porting to D from another language.
I think that the worse part of this is that it make integers
and floats needlessly different..
chars initialize to 0xff by default. By putting the values as
close to a invalid state as possible helps them to stand out as
uninitialized. There's a small part in walter's article on
demystifying the floating point, where he went onto the bugs
involved which were hard to figure out.
http://dlang.org/d-floating-point.html
[quote]
My first floating-point nightmare occurred in a C++ program which
hung once in every hundred runs or so. I eventually traced the
problem to a while loop which occasionally failed to terminate.
The essence of the code is shown in Listing 1.
[code]
double q[8];
...
int x = 0;
while (x 8) {
if ( q[x] = 0 ) return true;
if ( q[x] 0 ) ++x;
}
return false;
[/code]
Initially, I was completely baffled as to how this
harmless-looking loop could fail. But eventually, I discovered
that q had not been initialized properly; q[7] contained random
garbage. Occasionally, that garbage had every bit set, which mean
that q[7] was a Not-a-Number (NaN), a special code which
indicates that the value of the variable is nonsense. NaNs were
not mentioned in the compiler's documentation - the only
information I could find about them was in Intel's assembly
instruction set documentation! Any comparison involving a NaN is
false, so q[7] was neither = 0, nor 0, killing my program.
Until that unwelcome discovery, I'd been unaware that NaNs even
existed. I had lived in a fool's paradise, mistakenly believing
that every floating point number was either positive, negative,
or zero.
My experience would have been quite different in D. The strange
features of floating point have a higher visibility in the
language, improving the education of numerical programmers.
Uninitialized floating point numbers are initialized to NaN by
the compiler, so the problematic loop would fail every time, not
intermittently.
[/quote]
Re: Re-thinking D's modules
Russel Winder rus...@winder.org.uk writes: I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it... Isn't the real question why is the same dynamic library linking problem happening again. Has nothing been learned from UNIX shared objects and Windows DLLs? ELF (aka unix) shared objects actually do support versioned symbols (and have since at least 1999) though they're not default and using them makes building a shared library somewhat more complex, as you have to tell the linker about ABI versions. But with properly done versioned symbols, linking two different versions of the same shared library into the same process space is perfectly safe; the C library itself uses it, for instance: wouter@carillon:~$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 | head -n 20 /lib/x86_64-linux-gnu/libc.so.6: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0001eb80 ld .text .text 0037d738 ld .tdata .tdata DO *UND* GLIBC_PRIVATE _rtld_global DO *UND* GLIBC_PRIVATE __libc_enable_secure DF *UND* GLIBC_2.3 __tls_get_addr DO *UND* GLIBC_PRIVATE _rtld_global_ro w D *UND* _dl_starting_up DO *UND* GLIBC_PRIVATE _dl_argv 000709d0 gDF .text 0115 GLIBC_2.2.5 putwchar 0008bbf0 gDF .text 001e GLIBC_2.2.5 __strspn_c1 000ec750 gDF .text 0017 GLIBC_2.4 __gethostname_chk 0008bc10 gDF .text 001a GLIBC_2.2.5 __strspn_c2 000f2660 gDF .text 00a5 GLIBC_2.2.5 setrpcent 00093760 gDF .text 000a GLIBC_2.2.5 __wcstod_l 0008bc30 gDF .text 0022 GLIBC_2.2.5 __strspn_c3 000d8c70 gDF .text 0025 GLIBC_2.3.2 epoll_create the GLIBC_* thingies (apart from the GLIBC_PRIVATE ones) are symbol versions. As you can see, it's even safe to have multiple versions in the same shared object, and (though it's not shown here) you can have multiple implementations of a particular symbol (but with different versions) in one shared object. For some details on how it works, see http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/symversion.html Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications. General Motors solves the problem of fatal car crashes by building cars without engines That's not a solution, that's avoiding the issue. Having said that, doing shared libraries properly is fairly complex, so it's not necessarily a bad idea to push the problem into the future until you've thought about it a lot; otherwise you'll probably end up with a broken solution. Certainly Gradle and Maven support this idea very well. Sadly Make, CMake, Autotools, SCons, Waf,… tend to delegate the problem to someone else. autotools has libtool, which does the shared object stuff, and which can do symbol versioning. I don't know about cmake; and scons and waf are both crap, so it's not surprising they've not even heard of symbol versioning. Make, of course, is a programming language for writing build systems, it's not a build system by itself. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a
Re: Preview LLVM Deimos bindings
Very interesting. I'd be interested in making some D Native feeling bindings, because the LLVM C bindings are A, inconsistent, and B, complete shit. So this is interesting.
OSCON 2012 notes
I'm back from OSCON 2012, where my talk has enjoyed a somewhat unexpected good reception (OSCON is not the most down-D's-alley audience). The talk abstract is at http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the slides are at http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. There will be a video up some time in the future for the entire talk. It would be really cool if we could enhance D's offering in the Web arena. People were really attracted by the notion of a language not requiring many type annotations, yet with the exploratory feel of a dynamic language. A small framework or simply a couple of standard library components that would make e.g. Vladimir's work (on forum.lang.org) or Adam Ruppe's work easy to assemble from preexisting parts would be just awesome. Go has enjoyed a stronger presence in numbers: http://www.oscon.com/oscon2012/public/schedule/detail/23910, http://www.oscon.com/oscon2012/public/schedule/detail/23906, but my perception (confirmed by ratings) is that the reception has been a tad colder. Cheers, Andrei
Re: Compilation failure
Timon Gehr: Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400 Thank you, already fixed, it seems. Even if the fix is the opposite of what I have thought (I was thinking about forbidding global immutables too to be used as compile-time constants, while this fix turns local immutables too into enums. I hope this change doesn't cause a large mess). Bye, bearophile
Re: ufcs and integer params
Marco: auto distance = 100.km; auto speed = 120.km/hour; Sounds fun. I mean, it makes me happy to see code written like this instead of Distance distance = new Kilometers(100); Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1)); Yeah, that was exactly one of my goals :) David: I find multiplication to read much more natural: --- enum km = kilo * meter; auto distance = 100.0 * km; auto speed = 100.0 * km / hour; auto timeToDest = distance / speed; --- This is good too. I have code that autogenerate the SI-prefixed versions (not on Github, I should clean it and push), but thought about offering prefix functions by themselves. Hmm, looking at it, I guess kilo is just 1000 as an enum in your code? That's a good idea. Anyway, multiplication is good, I just looked for an excuse to play with UFCS :) See http://klickverbot.at/code/units/ for a slightly neglected implementation of this scheme. It supports stuff like defining new units with arbitrary (potentially runtime) conversion factors, properly typechecked affine units (think degrees celsius), etc. Ah good. I remembered someone posting something on units-checking, but couldn't find the message. I also have something on celsius/kelvin and wondered if I needed to go beyond affine, to fully generalize the concept. Btw, is °C substraction authorized with your module, or multiplication? I wondered what to forbid and what to authorize. And I (re)discovered while browsing Wikipedia the numerous temperature units I saw at school 15 years ago :) – but any error messages and symbol names will probably look like if the compiler had a seizure. why?
More WinAPI problems
Hello everyone,
I encountered a few more problems while creating my system-wide
makro program.
1)
I can't load my dll with LoadLibraryW, only LoadLibraryA. Why?
2)
The LoadLibraryA function fails with Error Code 127 - I still
get a Handle and can register my function as a
LowLevelKeyboardProc, so I'm not really sure what went wrong.
Google tells me Code 127 means my .dll is dependant on other
.dlls which can't be found, but I have no idea which/why/how.
3)
I intend to use the SendInput function to simulate Unicode
character presses - to be precise, I want to inject this --
ಠ_ಠ -- whenever I press CTRL+SHIFT+ALT+Q (for example).
Sadly SendInput gives me Error Code 87 (Incorrect Parameter),
but I don't know what I'm doing wrong.
I hope you guys can help me out!
This is the .dll code:
- CODE BEGIN -
import std.c.windows.windows;
import core.sys.windows.dll;
import core.runtime;
import std.stdio;
//const auto INPUT_KEYBOARD = 1;
//const auto KEYEVENTF_UNICODE = 4;
extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _minit();
extern (C) void _moduleCtor();
extern (C) void _moduleDtor();
extern (Windows) struct KBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
};
extern (Windows) struct KEYBDINPUT {
WORD wVk;
WORD wScan;
DWORD dwFlags;
DWORD time;
ULONG_PTR dwExtraInfo;
};
extern (Windows) struct INPUT {
DWORD type;
KEYBDINPUT ki;
};
extern (Windows) LRESULT CallNextHookEx(
HANDLE hhk,
int nCode,
WPARAM wParam,
LPARAM lParam
);
extern (Windows) SHORT GetKeyState(
int nVirtKey
);
extern (Windows) UINT SendInput(
UINT nInputs,
INPUT* pInputs,
int cbSize
);
__gshared HINSTANCE g_hInst;
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
g_hInst = hInstance;
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
Runtime.initialize;
//dll_process_attach( hInstance, true );
break;
case DLL_PROCESS_DETACH:
//dll_process_detach( hInstance, true );
break;
case DLL_THREAD_ATTACH:
//dll_thread_attach( true, true );
break;
case DLL_THREAD_DETACH:
//dll_thread_detach( true, true );
break;
default:
return true;
}
return true;
}
extern (Windows) LRESULT LowLevelKeyboardProc(int code, WPARAM
wParam, LPARAM lParam)
{
Runtime.initialize;
//MessageBoxA(null, HALLO, OK,0);
KBDLLHOOKSTRUCT* details = cast(KBDLLHOOKSTRUCT*) lParam;
if(code == 0 wParam == WM_KEYDOWN)
{
if(details.vkCode == 0x51) {
SHORT shiftkey = GetKeyState( VK_SHIFT );
SHORT ctrlkey = GetKeyState( VK_CONTROL );
SHORT altkey = GetKeyState ( VK_MENU );
if( ( shiftkey == -127 || shiftkey == -128 ) ( ctrlkey ==
-127 || ctrlkey == -128 ) ( altkey == -127 || altkey == -128 )
)
{
//MessageBoxA(null, BOOM, OK,0);
INPUT[3] toSend = new INPUT[3];
toSend[0].type = 1;
toSend[0].ki.wVk = 0;
toSend[0].ki.wScan = 0x0CA0;
toSend[0].ki.dwFlags = 4;
toSend[0].ki.time = 0;
toSend[0].ki.dwExtraInfo = details.dwExtraInfo;
toSend[1].type = 1;
toSend[1].ki.wVk = 0;
toSend[1].ki.wScan = 0x005F;
toSend[1].ki.dwFlags = 4;
toSend[1].ki.time = 0;
toSend[1].ki.dwExtraInfo = details.dwExtraInfo;
toSend[2].type = 1;
toSend[2].ki.wVk = 0;
toSend[2].ki.wScan = 0x0CA0;
toSend[2].ki.dwFlags = 4;
toSend[2].ki.time = 0;
toSend[2].ki.dwExtraInfo = details.dwExtraInfo;
SendInput( cast(UINT)3, toSend.ptr,
toSend[0].sizeof );
writeln(GetLastError());
//MessageBoxA(null, cast(char*)GetLastError(),
OK,0);
return 1;
}
Re: ~= call copy ctor?
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln(CTOR);
}
this(this) {
writeln(COPY CTOR);
}
~this() {
writeln(DTOR);
}
}
void main() {
Test[] _arr;
_arr ~= Test(0);
writeln(end main);
}
[/code]
And as output i see:
CTOR
COPY CTOR
DTOR
end main
Why on earth?
I create a struct Test. It's not a local variable, it's directly
assigned,
but it is copied and the original is destroyed. Why?
If i store something important, like a pointer, in Test and will
free him in the DTOR i cannot assign this way Test's to an array,
because the pointer was deleted because the DTOr was called.
I think the correct output would be:
CTOR
end main
Maybe DTOR before end main. But not COPY CTOR anywhere.
Re: More WinAPI problems
On Fri, 20 Jul 2012 14:07:51 +0100, DLimited tanojo...@googlemail.com wrote: Hello everyone, I encountered a few more problems while creating my system-wide makro program. 1) I can't load my dll with LoadLibraryW, only LoadLibraryA. Why? How are you passing the DLL filename to LoadLibraryA/W? Are you passing a string literal, i.e. LoadLibraryW(C:\\folder\dllname.dll); Have you tried the string literal suffix 'w', e.g. LoadLibraryW(C:\\folder\dllname.dllw); R
Re: ~= call copy ctor?
On Fri, 20 Jul 2012 14:50:19 +0100, Namespace rswhi...@googlemail.com
wrote:
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln(CTOR);
}
this(this) {
writeln(COPY CTOR);
}
~this() {
writeln(DTOR);
}
}
void main() {
Test[] _arr;
_arr ~= Test(0);
writeln(end main);
}
[/code]
And as output i see:
CTOR
COPY CTOR
DTOR
end main
Why on earth?
I create a struct Test. It's not a local variable, it's directly
assigned,
but it is copied and the original is destroyed. Why?
Because that's how assignment works, rhs is evaluated, struct is
constructed, then assigned to lhs, lhs copies the variable into the
array. Your variable is a struct, so it is copied. Use a pointer instead
and the pointer is copied into the array. Use a reference and the
reference is copied into the array. The variable, whatever it is, is
/always/ copied into the array.
It's a long standing optimisation issue and the reason for the recent
distinction between lvalues and rvalues made in C++0x for their new 'move'
optimisation where assignments involving rvalues/temporaries can move the
rvalue instead of copying - or something like that, I'm a bit vague having
watched a vid a few days back and not paying a lot of attention to it,
sorry.
Does:
_arr[0] = Test(0);
avoid the copy construction?
R
Re: ~= call copy ctor?
For correctness: A copy call is still fine if I assign a local variable to _arr (even if i think that ref parameters should'nt be copied), but i think that it is not fine if I assign directly, as you see above.
Re: ~= call copy ctor?
Does:
_arr[0] = Test(0);
avoid the copy construction?
R
[code]
void main() {
Test[2] _arr = void;
_arr[0] = Test(0);
writeln(end main);
}
[/code]
puts
CTOR
DTOR
end main
DTOR
DTOR
If i wrote Test[] instead of Test[2] i get an exception.
There is no dynamic way for that problem? Even with move it
prints COPY CTOR...
Re: ~= call copy ctor?
On Friday, July 20, 2012 15:50:19 Namespace wrote: Why on earth? http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move- semantics If you want to guarantee that you don't get any copies while moving an object around, it needs to be a reference type (which would include a pointer to a value type). - Jonathan M Davis
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 13:50:20 UTC, Namespace wrote:
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln(CTOR);
}
Be careful about int i = O. Structs are not allowed to have
default constructors. This is so they can have a static default
value of Test.init which can be efficiently mem-copied.
this(this) {
writeln(COPY CTOR);
}
~this() {
writeln(DTOR);
}
}
void main() {
Test[] _arr;
_arr ~= Test(0);
writeln(end main);
}
[/code]
And as output i see:
CTOR
COPY CTOR
DTOR
end main
Why on earth?
I create a struct Test. It's not a local variable, it's
directly assigned, but it is copied and the original is
destroyed. Why?
Seems perfectly reasonable to me.
~= is an operator, eg, a function that needs arguments. Test(0)
_IS_ a local variable that you pass as an argument in main
(CTOR), and you pass it to the operator. From there,
operator!~= will build a new object straight from the old
object (COPY CTOR). Then, you return to main, and the stack local
Test(T) object is destroyed (DTOR). Finally, main ends (end main).
The last missing destructor is the one of the object in the array.
If i store something important, like a pointer, in Test and
will free him in the DTOR i cannot assign this way Test's to an
array, because the pointer was deleted because the DTOr was
called.
Well if you do that, then your object can't be copied ever.
Here is a funner test though:
Though:
Test TestBuilder(int i)
{
return Test(i);
}
void main() {
Test[] _arr;
_arr ~= TestBuilder(3);
writeln(end main);
}
Output:
CTOR
COPY CTOR
end main
_This_ smells funky to me. There should be a destroyer somewhere
in there: At the end of the day, there is only 1 element left in
memory, but two have been created, yet none have been destroyed !?
Re: ~= call copy ctor?
On Friday, July 20, 2012 08:08:47 Jonathan M Davis wrote: On Friday, July 20, 2012 15:50:19 Namespace wrote: Why on earth? http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move - semantics If you want to guarantee that you don't get any copies while moving an object around, it needs to be a reference type (which would include a pointer to a value type). Alternatively, you can @disable this(this), which would make copies illegal, but then I'd be worried about code breaking when the compiler adjusted some of its optimizations (though it would generally be unlikely for a move to become a copy - the opposite would be far more likely, which wouldn't break anything). - Jonathan M Davs
Re: ufcs and integer params
On Friday, 20 July 2012 at 12:28:52 UTC, Philippe Sigaud wrote: Hmm, looking at it, I guess kilo is just 1000 as an enum in your code? That's a good idea. Sorry, that should have been »kilo!gram«. It actually creates a new unit with a conversion factor of 1000 relative to the base unit (well, it does a few more things to handle cases like kilo!(milli!meter)), with the point being that the quantities are actually stored in memory verbatim, i.e. without being normalized to e.g. SI units. Making »kilo * gram« work would be easy, but I decided it could lead to confusing situations. David
Re: ~= call copy ctor?
If i @disable the postblit i get a strange behaviour:
[code]
struct Test {
public:
int _id;
this(int i) {
_id = i;
writeln(CTOR);
}
@disable
this(this);
~this() {
writeln(DTOR);
}
}
void main() {
Test[] _arr;
_arr ~= Test(42);
writeln(_arr[0]._id);
writeln(end main);
}
[/code]
prints:
CTOR
DTOR
42
end main
The DTor is called _before_ i write Test's id but i can still
print the correct id.
Implicit Copy CTor? ;)
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 16:02:18 UTC, Namespace wrote: If i @disable the postblit i get a strange behaviour: @disable this(this); I think @disable is broken right now, and does nothing (ei: allows a default implementation of this(this) ). If you replace by the C++ declare but don't implement scheme: this(this); Then you get a normal linker error. So to answer your question: Yes, implicit Copy CTor.
Re: ~= call copy ctor?
It seems structs are very broken right now... I would use classes, but they are nullable and without correct/good error handling instead of access violation i prefer structs. Funny, all variables are default initialized which would be even done by the OS. But Null Exceptions aren't exists and D let the OS thrown an uninformative message (at least on windows). I think the only good decision is to store important thinks like pointers eternal and let the GC free them. Or use an reference counter.
Re: ~= call copy ctor?
On 07/20/2012 09:02 AM, Namespace wrote: If i @disable the postblit i get a strange behaviour: Something is not right. Compiled with dmd 2.059, the linker says: undefined reference to `_D6deneme4Test10__postblitMFZv' 64 bit Linux... Ali
Predictable seed for pseudo-random number generation
Hello all, Often when writing simulations with pseudo-random number generation you want to be able to use a predictable seed for testing purposes, e.g. to confirm whether an alteration to the code produces changes in output. In a single-threaded piece of code this is easy -- one can just put rndGen.seed(/* my chosen seed here*/); ... in the main() function. But what about multithreaded code? rndGen is (by definition) thread-global, and so will be separately seeded in each thread. Again, it's surely possible to put in place something like the above in the controller function for each thread; perhaps rndGen.seed(baseSeed + threadID); ... but it would be nice if there was a simpler way of ensuring that all default RNG seeds will be predictable, without damaging the independence of the random number sequences in different threads. On a related note, is it possible to override the default random number generator with another type? Thanks and best wishes, -- Joe
Re: Predictable seed for pseudo-random number generation
On Friday, July 20, 2012 19:52:17 Joseph Rushton Wakeling wrote: On a related note, is it possible to override the default random number generator with another type? As long as rndGen isn't called with its full path (std.random.rndGen), any module which uses it could declare its own rndGen, and it would be used instead of std.random's, in which case you could do whatever you want with its type or seed. So, you could put it in a version(unittest) block if you want it specifically for unit testing. However, std.random.rndGen just returns std.random's default random number generator, and you can't mess with it. If you really want to be able to have control over the type or seed of the random number generator that you're using, you should declare your own. rndGen is provided merely for convenience, and it's simple enough to use other random number generators from std.random if just using the default doesn't fit your needs. - Jonathan M Davis
Problem: handling a function dependent on release mode.
Trying to convert the below code to D, for the life of me I cannot do it :( I'm guess I need to use a template for this but I just cannot get my head around it. Any help please? #ifdef SFML_DEBUG // If in debug mode, perform a test on every call #define alCheck(Func) ((Func), priv::alCheckError(__FILE__, __LINE__)) #else // Else, we don't add any overhead #define alCheck(Func) (Func) #endif void alCheckError(const std::string file, unsigned int line);
Re: ~= call copy ctor?
Something else which is against classes: incorrect scope
behaviour:
[code]
import std.stdio;
class TestC {
public:
this() {
writeln(CTOR class);
}
~this() {
writeln(DTOR class);
}
}
struct TestS {
public:
this(int i) {
writeln(CTOR struct);
}
~this() {
writeln(DTOR struct);
}
}
void main() {
{
writeln(begin scope);
TestC c = new TestC();
TestS s = TestS(42);
writeln(end scope);
}
writeln(end main);
}
[/code]
Prints
begin scope
CTOR class
CTOR struct
end scope
DTOR struct
end main
DTOR class
Why comes DTOR class _after_ end main and not before?
If i write scope TestC c = ...; it is correct, but i read that
scope will be deprecated. Can someone explain me that behaviour?
Re: Problem: handling a function dependent on release mode.
On Friday, 20 July 2012 at 21:36:59 UTC, Damian wrote:
Trying to convert the below code to D, for the life of me I
cannot do it :( I'm guess I need to use a template for this
but I just cannot get my head around it. Any help please?
#ifdef SFML_DEBUG
// If in debug mode, perform a test on every call
#define alCheck(Func) ((Func), priv::alCheckError(__FILE__,
__LINE__))
#else
// Else, we don't add any overhead
#define alCheck(Func) (Func)
#endif
void alCheckError(const std::string file, unsigned int line);
Maybe something like that?
void alCheck(lazy void Func, string filename = __FILE__, uint
line = __LINE__) {
Func();
debug {
alCheckError(filename, line);
}
}
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote: Why comes DTOR class _after_ end main and not before? If i write scope TestC c = ...; it is correct, but i read that scope will be deprecated. Can someone explain me that behaviour? The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David
Re: Compilation failure
On 07/20/2012 01:53 PM, bearophile wrote: Timon Gehr: Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400 Thank you, already fixed, it seems. Even if the fix is the opposite of what I have thought (I was thinking about forbidding global immutables too to be used as compile-time constants, while this fix turns local immutables too into enums. I hope this change doesn't cause a large mess). They are not enums. They are interpretable at compile time if their initializer is interpretable at compile time. This makes sense. This is a bug fix. Similar code already works.
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote: On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote: Why comes DTOR class _after_ end main and not before? If i write scope TestC c = ...; it is correct, but i read that scope will be deprecated. Can someone explain me that behaviour? The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David Really? Holy crap... Can i correct this? And will scope for classes really deprecated?
Re: Problem: handling a function dependent on release mode.
On Friday, 20 July 2012 at 21:47:55 UTC, Namespace wrote:
On Friday, 20 July 2012 at 21:36:59 UTC, Damian wrote:
Trying to convert the below code to D, for the life of me I
cannot do it :( I'm guess I need to use a template for this
but I just cannot get my head around it. Any help please?
#ifdef SFML_DEBUG
// If in debug mode, perform a test on every call
#define alCheck(Func) ((Func), priv::alCheckError(__FILE__,
__LINE__))
#else
// Else, we don't add any overhead
#define alCheck(Func) (Func)
#endif
void alCheckError(const std::string file, unsigned int line);
Maybe something like that?
void alCheck(lazy void Func, string filename = __FILE__, uint
line = __LINE__) {
Func();
debug {
alCheckError(filename, line);
}
}
That works perfect, you sir are a genius!
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Something else which is against classes: incorrect scope
behaviour:
[code]
import std.stdio;
class TestC {
public:
this() {
writeln(CTOR class);
}
~this() {
writeln(DTOR class);
}
}
struct TestS {
public:
this(int i) {
writeln(CTOR struct);
}
~this() {
writeln(DTOR struct);
}
}
void main() {
{
writeln(begin scope);
TestC c = new TestC();
TestS s = TestS(42);
writeln(end scope);
}
writeln(end main);
}
[/code]
Prints
begin scope
CTOR class
CTOR struct
end scope
DTOR struct
end main
DTOR class
Why comes DTOR class _after_ end main and not before?
If i write scope TestC c = ...; it is correct, but i read that
scope will be deprecated. Can someone explain me that
behaviour?
That happens because the destructor is being called when Garbage
collector is cleaning the memory used by the class instance.
Re: ~= call copy ctor?
On 07/20/2012 02:54 PM, Namespace wrote: On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote: On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote: Why comes DTOR class _after_ end main and not before? If i write scope TestC c = ...; it is correct, but i read that scope will be deprecated. Can someone explain me that behaviour? The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David Really? Holy crap... Can i correct this? And will scope for classes really deprecated? The truth is, the destructor may not ever be called. Yes scope is (will be?) deprecated and is replaced by std.typecons.scoped: import std.typecons; // ... auto c = scoped!TestC(); Prints: begin scope CTOR class CTOR struct end scope DTOR struct DTOR class end main Ali
Re: ~= call copy ctor?
That happens because the destructor is being called when Garbage collector is cleaning the memory used by the class instance. How can i call the DTOR or at least a Release method after end of scope? Optimally automatic without any explicit calls.
Re: ~= call copy ctor?
On Friday, 20 July 2012 at 21:54:05 UTC, Namespace wrote: On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote: On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote: Why comes DTOR class _after_ end main and not before? If i write scope TestC c = ...; it is correct, but i read that scope will be deprecated. Can someone explain me that behaviour? The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David Really? Holy crap... Can i correct this? And will scope for classes really deprecated? I suppose that you need this: http://dlang.org/phobos/std_typecons.html#scoped
Re: Predictable seed for pseudo-random number generation
On 20/07/12 19:59, Jonathan M Davis wrote:
As long as rndGen isn't called with its full path (std.random.rndGen), any
module which uses it could declare its own rndGen, and it would be used
instead of std.random's, in which case you could do whatever you want with its
type or seed.
I did consider that, but I found myself wondering what would happen if I did
something like this:
///
import std.random;
@property ref MyRNG rndGen()
{
// etc. ...
}
void main()
{
auto s = randomSample(iota(0, 100), 10);
// and do something with s
}
///
Calling randomSample like this ought to involve rndGen; but given that
randomSample is in std.random, would it use my self-defined rndGen, or that from
std.random?
OK, I probably should and certainly could have tested this myself ... :-) I was
just wondering if there was a _trivial_ way to override the default RNG type.
Re: Getting a range over a const Container
On 07/19/2012 06:09 PM, Ellery Newcomer wrote:
On 07/19/2012 02:51 AM, Artur Skawina wrote:
Range!Node opSlice() { return Range!Node(first); }
Range!(const Node) opSlice() const { return Range!(const
Node)(first); }
it looks like you could almost merge these two into one using inout, but
I'm not sure what you do about selecting the return type.
Re: Problem: handling a function dependent on release mode.
On Friday, July 20, 2012 23:36:58 Damian wrote:
Trying to convert the below code to D, for the life of me I
cannot do it :( I'm guess I need to use a template for this
but I just cannot get my head around it. Any help please?
#ifdef SFML_DEBUG
// If in debug mode, perform a test on every call
#define alCheck(Func) ((Func), priv::alCheckError(__FILE__,
__LINE__))
#else
// Else, we don't add any overhead
#define alCheck(Func) (Func)
#endif
void alCheckError(const std::string file, unsigned int line);
It is impossible to have a function which relies on -release unless you put
all calls to it in an assertion. There is _no_ way to check whether -release
is enabled or not.
-debug enables debug blocks:
debug
{
//my code that runs with -debug only
}
but that's only if -debug is used. It's perfectly possible to compile with
neither -release nor -debug. The result is that talking about debug mode in
D is really confusing and inaccurate.
- Jonathan M Davis
Re: Getting a range over a const Container
On Friday, July 20, 2012 17:15:53 Ellery Newcomer wrote:
On 07/19/2012 06:09 PM, Ellery Newcomer wrote:
On 07/19/2012 02:51 AM, Artur Skawina wrote:
Range!Node opSlice() { return Range!Node(first); }
Range!(const Node) opSlice() const { return Range!(const
Node)(first); }
it looks like you could almost merge these two into one using inout, but
I'm not sure what you do about selecting the return type.
If everywhere that you use const, you can use inout, then it may work. But the
return type is not only a difference in constness. It's a completely different
type.
The other problem is that the const opSlice is actually _very_ broken as far
as range-based functions typically go. Whil opSlice doesn't technically
require it (though it probably should), it's _very_ common for function using
opSlice to assign the result to the original range, and that's not possible
with this code.
I keep meaning to bring it up for discussion in the newsgroup, but it's a big
problem. You basically need tail-const, and I don't know of any way to
implement it, because the only way to get implicit conversions is to use alias
this, and that results in a recursive template instantiation, which kills the
compiler. I don't think that it's actually possible to properly implement a
const opSlice for many ranges right now.
- Jonathan M Davis
Parameter specialization
Hello,
I have a question about the semantic of parameter
specialization(TemplateTypeParameterSpecialization)
In this following code, there are 2 forms of the same function
'add' :
code
T add(T, U : T) (T a, U b) //doesn't work
{
return a + b;
}
T add(T, U) (T a, U b) if(is(U : T)) //works
{
return a + b;
}
void main()
{
assert(add(2, cast(short)2) == 4);
}
/code
So, I infer that, in this case,
TemplateTypeParameterSpecialization and TypeSpecialization(of
IsExpression) aren't semantically equal ? What are differences
between this 2 forms ?
Eyyub,
(I hope that I have an english a bit compréhensible)
Re: ~= call copy ctor?
On Saturday, July 21, 2012 00:04:21 Namespace wrote: That happens because the destructor is being called when Garbage collector is cleaning the memory used by the class instance. How can i call the DTOR or at least a Release method after end of scope? Optimally automatic without any explicit calls. You can use std.typecons.scoped, but then you can't pass the class around, which is exactly what would have happened with scoped. It's inherently unsafe. You can do something like MyObj obj = createObj(); scope(exit) clear(obj); but again, it's going to be destroyed immediately when it leaves scope, and any reference to it which escapes will blow up when you use it. In neither case is there any reference counting. You could use std.typecons.RefCounted, but unless _every_ instance of the object is wrapped in it (unfortunately, it uses alias this on its payload, making it easy to accidentally have references to its payload escape - which will be screwed up when the ref count reaches zero, and the payload is destroyed) The reality of the matter is that if you want deterministic destruction, you should be using a struct, not a class. There are ways to force a class to be destroyed when it leaves scope, but they're inherently unsafe, so they should only be used if you really need them and know what you're doing. Classes are intended to live on the GC heap and be destroyed and freed by the GC when a garbage collection cycle finds that nothing refers to that object anymore. - Jonathan M Davis
[Issue 8400] static array type cannot interpret dynamic array length
http://d.puremagic.com/issues/show_bug.cgi?id=8400 --- Comment #2 from github-bugzi...@puremagic.com 2012-07-19 23:53:42 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b4b6211c519cc744c83e2985fcfaafe68c0fad19 fix Issue 8400 - static array type cannot interpret dynamic array length Local variables always should be interpreted to detect whether it is really constant expression or not. https://github.com/D-Programming-Language/dmd/commit/0dad66820b826d4ee55a82f0a692548c5bd511af Merge pull request #1058 from 9rnsr/fix8400 Issue 8400 - static array type cannot interpret dynamic array length -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8121] scope ref is perfectly OK
http://d.puremagic.com/issues/show_bug.cgi?id=8121 Matthias Walter xa...@xammy.info changed: What|Removed |Added CC||xa...@xammy.info --- Comment #2 from Matthias Walter xa...@xammy.info 2012-07-19 23:58:04 PDT --- Does this bug report also cover the case of *returning* scope ref in order to make the following possible: scope ref T opIndex(...); For example in std.container.Array this is helpful in order to write array[0].method() because for by-value opIndex the method() is called on a *copy* of the first element! On the other hand returning by (the usual) ref prevents the container from being a 'sealed container' and hence the restriction would say: opIndex returns by reference but this reference may not be escaped but only be used to call a method (including operators) on the returned object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4301] BigInt * const(BigInt) doesn't work well
http://d.puremagic.com/issues/show_bug.cgi?id=4301 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Depends on||8395 --- Comment #2 from Don clugd...@yahoo.com.au 2012-07-20 00:07:13 PDT --- This is blocked by bug 8395. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8402] New: Lambda argument's default value is not taken into account
http://d.puremagic.com/issues/show_bug.cgi?id=8402
Summary: Lambda argument's default value is not taken into
account
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kolo...@bk.ru
--- Comment #0 from Artem Borisovskiy kolo...@bk.ru 2012-07-20 05:33:24 PDT
---
The following code does not compile (x.d):
void main()
{
auto fn = (int x = 0) = x + 1;
fn();
}
with message: x.d(4): Error: expected 1 function arguments, not 0
However, calling fn() with an explicit argument works fine as usual.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7176] Lambda = syntax for function and methods too
http://d.puremagic.com/issues/show_bug.cgi?id=7176
Artem Borisovskiy kolo...@bk.ru changed:
What|Removed |Added
CC||kolo...@bk.ru
--- Comment #10 from Artem Borisovskiy kolo...@bk.ru 2012-07-20 05:37:43 PDT
---
class Foo
{
@property int bar;
}
Is lowered to this:
class Foo
{
private int bar_;
@property int bar () { return bar_; }
@property int bar (int value) { return bar_ = value; }
}
Why not just make bar_ public? You do not add any code to the getter nor to the
setter anyway.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7176] Lambda = syntax for function and methods too
http://d.puremagic.com/issues/show_bug.cgi?id=7176 --- Comment #11 from Jacob Carlborg d...@me.com 2012-07-20 07:06:34 PDT --- (In reply to comment #10) Why not just make bar_ public? You do not add any code to the getter nor to the setter anyway. Perhaps I want it to be virtual, to be able to override it in a subclass. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7936] std.random.randomSample always returns the same first value when passed a random number generator
http://d.puremagic.com/issues/show_bug.cgi?id=7936 Joseph Rushton Wakeling joseph.wakel...@webdrake.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2012-07-20 07:07:26 PDT --- With the merging of pull request 553 this bug has now been fixed: https://github.com/D-Programming-Language/phobos/pull/553 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7176] Lambda = syntax for function and methods too
http://d.puremagic.com/issues/show_bug.cgi?id=7176 --- Comment #12 from David Piepgrass qwertie...@gmail.com 2012-07-20 08:59:15 PDT --- (In reply to comment #11) (In reply to comment #10) Why not just make bar_ public? You do not add any code to the getter nor to the setter anyway. Perhaps I want it to be virtual, to be able to override it in a subclass. Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7176] Lambda = syntax for function and methods too
http://d.puremagic.com/issues/show_bug.cgi?id=7176 --- Comment #13 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-20 10:06:53 PDT --- Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference). That's why I've been tempted to suggest that @property on a variable made it so that only operations which would still be legal if it were switched to being a property function were allowed. I can't remember whether I ever actually opened an enhancement request on that though. I'd have to go digging to find out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7176] Lambda = syntax for function and methods too
http://d.puremagic.com/issues/show_bug.cgi?id=7176 --- Comment #14 from Jacob Carlborg d...@me.com 2012-07-20 10:22:44 PDT --- (In reply to comment #12) Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference). Other good points. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8402] Lambda argument's default value is not taken into account
http://d.puremagic.com/issues/show_bug.cgi?id=8402 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-20 10:27:41 PDT --- Default arguments with lambda functions don't really make sense given that they're generally only used in one place, that default arguments are _not_ part of the type (they're just inserted at the call site), and that there's no way for lambdas or function pointers to carry default arguments with them. So, the fact that it doesn't compile is a _good_ thing, though it really should give an error for giving a default argument and not just an error at the call site. This is related to bug# 3646, but I'm not sure if it's strictly speaking a duplicate or not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8395] Templated struct constructors don't implicitly convert to const
http://d.puremagic.com/issues/show_bug.cgi?id=8395 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-07-20 10:46:53 PDT --- https://github.com/D-Programming-Language/dmd/pull/1060 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7803] scope(success) in nothrow/@safe functions causes compile errors
http://d.puremagic.com/issues/show_bug.cgi?id=7803 kekeni...@yahoo.co.jp changed: What|Removed |Added CC||kekeni...@yahoo.co.jp Severity|minor |normal --- Comment #2 from kekeni...@yahoo.co.jp 2012-07-20 17:30:10 PDT --- To make matters worse, the error message misses its location information. Raised the severity from 'minor'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8403] New: ^^ and ^^= missing from lex.html
http://d.puremagic.com/issues/show_bug.cgi?id=8403 Summary: ^^ and ^^= missing from lex.html Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-20 21:31:12 PDT --- http://dlang.org/expression.html mentions ^^ and ^^=, and lexer.c in dmd definitely includes it, but lex.html does not in the definition of Token. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8403] ^^ and ^^= missing from lex.html
http://d.puremagic.com/issues/show_bug.cgi?id=8403 --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-20 21:32:16 PDT --- https://github.com/D-Programming-Language/d-programming-language.org/pull/142 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1064] Tuples are not expanded in array initializers
http://d.puremagic.com/issues/show_bug.cgi?id=1064 --- Comment #3 from github-bugzi...@puremagic.com 2012-07-20 21:52:54 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0e6f6211aef226d913a3c29f3ff3f11a420cdf41 Issue 1064 - Tuples are not expanded in array initializers Expand any tuples in place. expandTuples from expression.c cannot be used because this is an array of ExpInitializers, not Expressions. https://github.com/D-Programming-Language/dmd/commit/162cf303c5e70bbb7b0a397b847e0b76c923ddd9 Merge pull request #690 from yebblies/issue1064 Issue 1064 - Tuples are not expanded in array initializers -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
