Re: Poll: Primary D version
div0 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bane wrote: OMG! I can't even spell OMG right! OBG! I'm minority! (still stuck on 1.030) rofl. you tool. (i mean that in a good way) I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I'm keeping an eye on D.
Re: Poll: Primary D version
Sun, 23 May 2010 04:14:30 -0400, bearophile wrote: Walter Bright: Doing it in an automated way requires whole program analysis, something not entirely practical in a language designed to support separate compilation. Compiling programs of a dynamic language like Lua was seen as hopelessly inefficient. But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. So it's all in having a positive attitude toward technological problems: if the need to do something grows strong enough, people usually find a way to do it :-) I don't think the D community is really interested in hearing something positive about dynamically typed non-native languages. Traditionally that's the best way to wreck your efficiency and it's tough to admit that those languages are now better. The traditional native code way is to use primitive compilers and brute force via inline asm.
Re: Poll: Primary D version
On Sun, May 23, 2010 at 1:14 AM, bearophile bearophileh...@lycos.com wrote: Walter Bright: Compiling programs of a dynamic language like Lua was seen as hopelessly inefficient. But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. Do you have any citations of that? All I can find on LuaJIT.org is comparisons of LuaJIT vs other versions of Lua. --bb
Re: Poll: Primary D version
Bill Baxter: Do you have any citations of that? All I can find on LuaJIT.org is comparisons of LuaJIT vs other versions of Lua. On my site you can see a version of the SciMark2 benchmark (that contains several sub-benchmarks, naive scientific kernels, mostly) for D with numerous timings. LDC is able to compile it quite well. You can find a version of that code here: http://luajit.org/download/scimark.lua I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings against ldc, dmd. I have taken similar timings for another benchmark (nboby, from Shootout site). Bye, bearophile
Re: Poll: Primary D version
On Tue, May 25, 2010 at 12:11 PM, bearophile bearophileh...@lycos.com wrote: Bill Baxter: Do you have any citations of that? All I can find on LuaJIT.org is comparisons of LuaJIT vs other versions of Lua. On my site you can see a version of the SciMark2 benchmark (that contains several sub-benchmarks, naive scientific kernels, mostly) for D with numerous timings. LDC is able to compile it quite well. You can find a version of that code here: http://luajit.org/download/scimark.lua I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings against ldc, dmd. I have taken similar timings for another benchmark (nboby, from Shootout site). So LuaJIT beats D on some or all of those benchmarks? I can't quite remember what your website URL is. But I did find this: http://shootout.alioth.debian.org/u64/benchmark.php?test=alllang=luajitlang2=gpp I was thinking LuaJIT would be too new and/or fringe for it to be on the Alioth shootout, but it's there. From that it looks like LuaJIT can't beat g++ for speed on any of the benchmarks. You disagree with those results? --bb
Re: Poll: Primary D version
Bill Baxter: So LuaJIT beats D on some or all of those benchmarks? It's faster or close, D code compiled with dmd. From that it looks like LuaJIT can't beat g++ for speed on any of the benchmarks. You disagree with those results? I don't disagree with those results, in my original post I have said: But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. This means comparing FP-heavy programs compiled with LUA jit 2.0a4 and DMD 2.x. I have not given hard timings because the point of my post was qualitative and not quantitative :-) Bye, bearophile
Re: Poll: Primary D version
On Tue, May 25, 2010 at 12:45 PM, Bill Baxter wbax...@gmail.com wrote: On Tue, May 25, 2010 at 12:11 PM, bearophile bearophileh...@lycos.com wrote: Bill Baxter: Do you have any citations of that? All I can find on LuaJIT.org is comparisons of LuaJIT vs other versions of Lua. On my site you can see a version of the SciMark2 benchmark (that contains several sub-benchmarks, naive scientific kernels, mostly) for D with numerous timings. LDC is able to compile it quite well. You can find a version of that code here: http://luajit.org/download/scimark.lua I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings against ldc, dmd. I have taken similar timings for another benchmark (nboby, from Shootout site). So LuaJIT beats D on some or all of those benchmarks? I can't quite remember what your website URL is. But I did find this: http://shootout.alioth.debian.org/u64/benchmark.php?test=alllang=luajitlang2=gpp I was thinking LuaJIT would be too new and/or fringe for it to be on the Alioth shootout, but it's there. From that it looks like LuaJIT can't beat g++ for speed on any of the benchmarks. You disagree with those results? Nevermind. I realize you didn't say that LuaJIT was faster than g++, just faster than DMD.But that last part made it sound like you thought LuaJIT was on track to eventually outperform all compilers. As in the need for fast JIT is strong enough that eventually people will figure out how to make it faster than everything else out there. --bb
Re: Poll: Primary D version
retard wrote: I don't think the D community is really interested in hearing something positive about dynamically typed non-native languages. Traditionally that's the best way to wreck your efficiency and it's tough to admit that those languages are now better. The traditional native code way is to use primitive compilers and brute force via inline asm. If this were true, C and C++ would be dead languages. C++, for example, is often used in combination with Python. The C++ part is for the bits that need to be fast. BTW, even the best compilers fall far short of what an expert can do with assembler.
Re: Poll: Primary D version
Tue, 25 May 2010 14:22:47 -0700, Walter Bright wrote: retard wrote: I don't think the D community is really interested in hearing something positive about dynamically typed non-native languages. Traditionally that's the best way to wreck your efficiency and it's tough to admit that those languages are now better. The traditional native code way is to use primitive compilers and brute force via inline asm. If this were true, C and C++ would be dead languages. C++, for example, is often used in combination with Python. The C++ part is for the bits that need to be fast. BTW, even the best compilers fall far short of what an expert can do with assembler. It's impossible to say whether e.g. LuaJIT is faster than some C++ compiler. The code matters. Bad code written by a novice programmer often works faster when a higher level language is used because there's more room for optimizations. However, it really depends on the quality of the optimzations done by the compiler. What I wanted to point out was that if a person needs to choose between D (DMD) and Lua (LuaJIT), it would probably make more sense to use LuaJIT if the user wants better performing code. However, D (LDC) and D (some other vendor who uses modern backends like LLVM/GCC) probably win DMD here. Almost all compilers probably beat it.
Re: Poll: Primary D version
Andrei Alexandrescu wrote: You both have a point. Clearly not a lot of individual applications really need more than 4GB (though unfortunately, many are pushing up for the wrong reasons), but then a whole category of them would greatly benefit of expanded RAM availability. Andrei I've written at least one application (for my thesis) which ended up using all of my 4GB RAM and 6GB swap. Of course, that was at least partially because I was writing it in Haskell and hadn't taken its laziness into proper account. It was reading in the hundreds of files before it actually calculated anything since it didn't write anything to disk until it was done processing (which it naturally never did since it ran out of memory). Fixing it to write to disk after processing each file (thereby forcing it to actually process each file before reading in the next one) made it only take 3+ GB of RAM. But I was doing a lot of string processing, and it wasn't at all a typical app. Haskell was a poor match for the problem as it turns out, but given D's current lack of 64-bit support, it would have been too - though for very different reasons. Still, you work with what you've got. We'll get 64-bit support eventually. At least I can say that I wrote a program that used up all of my memory and swap doing something useful (or trying anyway). I don't think that many people can say that - especially when it was around 10GB total. That project definitely lead me to upgrade my RAM. But anywho, D is great. And for the most part, 64-bit isn't necessary. But it will be nice when we do get it. - Jonathan M Davis
Re: Poll: Primary D version
Walter Bright: 1. D has to work with the corresponding C compiler, which does not support such a memory model. This kills it right there. But the 'need' to do it can resurrect this feature from the dead. Sometimes you just need to do something, even such thing was not seen as possible in the past. The Oracle JavaVM is already using this optimization, but indeed it doesn't need to keep compatibility with the C compiler. This shows pointer compression in C and the like: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html Even if pointer compression can cause problems at the interface between C and D, there can be ways to decompress pointers when they are given to C libraries. So you can perform more efficient computations inside D code, and adapt (inflate) your pointers when they are needed for processing inside C code. There are things (like pointer compression, de-virtualization, dynamic decompilation, and so on) that future C-class languages can find useful to do that C compilers ten years ago didn't even think possible. Things are not set in stone, there's change too. Don't kill an idea just because it was kind of impossible (and probably kind of useless too) fifteen years ago. Bye, bearophile
Re: Poll: Primary D version
bearophile wrote: Walter Bright: 1. D has to work with the corresponding C compiler, which does not support such a memory model. This kills it right there. But the 'need' to do it can resurrect this feature from the dead. Sometimes you just need to do something, even such thing was not seen as possible in the past. The Oracle JavaVM is already using this optimization, but indeed it doesn't need to keep compatibility with the C compiler. This shows pointer compression in C and the like: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html Even if pointer compression can cause problems at the interface between C and D, there can be ways to decompress pointers when they are given to C libraries. So you can perform more efficient computations inside D code, and adapt (inflate) your pointers when they are needed for processing inside C code. There are things (like pointer compression, de-virtualization, dynamic decompilation, and so on) that future C-class languages can find useful to do that C compilers ten years ago didn't even think possible. Things are not set in stone, there's change too. Don't kill an idea just because it was kind of impossible (and probably kind of useless too) fifteen years ago. The paper describes an automatic way to do what I'd suggested previously - replacing the pointers with offsets from a base pointer. This is a lot like how the 'far' memory model in 16 bit code worked. Doing it in an automated way requires whole program analysis, something not entirely practical in a language designed to support separate compilation. On the other hand, D has plenty of abstraction abilities to make this doable by hand for selected data structures.
Re: Poll: Primary D version
bearophile wrote: The Oracle JavaVM is already using this optimization, but indeed it doesn't need to keep compatibility with the C compiler. This shows pointer compression in C and the like: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html Oh, I forgot to mention. Back in the 16 bit days, I invented something called a handle pointer. http://www.digitalmars.com/ctg/handle-pointers.html It was a special pointer type that was dereferenced through a function call. The particular implementation of it was to enable to use bank-switched EMS memory as if it were regularly addressible memory. In D this would be better off making the special pointer types a user defined struct type. Compiler support isn't necessary.
Re: Poll: Primary D version
Rainer Deyke wrote: On 5/22/2010 23:16, Mike Parker wrote: That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args. There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'. I understand that. But, ignoring the fact that toStringz in D1 seems to have functioned perfectly fine for several years without a const return, it doesn't change the fact that a C function call that accepts a char* expects it to be null-terminated, regardless of what happens to it on the other side. And I would argue that it's unreasonable to expect the declarations of C functions to be declared const-correct based on their usage. To my knowledge, all of the C bindings for D to date either don't use const at all (because they were created for D1) or use it according to the declarations in the C headers. Which means there are numerous C functions out there with non-const params that do not modify them. Then there's the issue of compatibility between D1/D2. I've bound several C libraries for D that need to support both D1/D2, Phobos/Tango. Supporting const was one of the first headaches I encountered when porting the original D1 bindings to D2. Finding that toStringz returned a const string was a big surprise.
Re: Poll: Primary D version
Walter Bright: Doing it in an automated way requires whole program analysis, something not entirely practical in a language designed to support separate compilation. Compiling programs of a dynamic language like Lua was seen as hopelessly inefficient. But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. So it's all in having a positive attitude toward technological problems: if the need to do something grows strong enough, people usually find a way to do it :-) Bye, bearophile
Re: Poll: Primary D version
Walter Bright: In D this would be better off making the special pointer types a user defined struct type. Compiler support isn't necessary. Nice, thank you :-) I will try to implement this, I have already written something similar in D2. Bye, bearophile
Re: Poll: Primary D version
On 05/23/2010 10:14 AM, Mike Parker wrote: And I would argue that it's unreasonable to expect the declarations of C functions to be declared const-correct based on their usage. To my knowledge, all of the C bindings for D to date either don't use const at all (because they were created for D1) or use it according to the declarations in the C headers. Which means there are numerous C functions out there with non-const params that do not modify them. I do them according to the C headers, and the constness is almost always correct. Otherwise, it's a bug in the C headers! Then there's the issue of compatibility between D1/D2. I've bound several C libraries for D that need to support both D1/D2, Phobos/Tango. Supporting const was one of the first headaches I encountered when porting the original D1 bindings to D2. Finding that toStringz returned a const string was a big surprise. It should probably be inout(char)* toStringz(inout(char)[]), or something like that.
Re: Poll: Primary D version
On 05/23/2010 09:39 AM, Walter Bright wrote: Oh, I forgot to mention. Back in the 16 bit days, I invented something called a handle pointer. http://www.digitalmars.com/ctg/handle-pointers.html You must be sure your program frees memory when it exits; otherwise, it will be unavailable to other programs until the machine is re-booted. Ha ha, oh wow. :)
Re: Poll: Primary D version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Walter Bright wrote:
div0 wrote:
Well I'm still using 2.028. Every version I've tried since has had a
compiler bug that's been a show stopper. However I'm in no major rush,
there's enough momentum in progress for me to be confidant that it will
work eventually.
Which one is your current showstopper?
http://d.puremagic.com/issues/show_bug.cgi?id=3712
Except for me, it's something to do with the change to struct initializers.
Error: struct clr has constructors, cannot use { initializers }, use
clr( initializers ) instead
ty.
- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFL+Qa/T9LetA9XoXwRApAzAKCTy5B+j+jh/UPsUEuSU7INQIgadACfUlWU
t/lY1I7V1FP+yWPx1APeUJg=
=ckRX
-END PGP SIGNATURE-
Re: Poll: Primary D version
On 05/23/2010 12:16 AM, Mike Parker wrote: Walter Bright wrote: Robert Clipsham wrote: On 22/05/10 17:42, Andrei Alexandrescu wrote: - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness. extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it. What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it. That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args. Yah, and that's intentional. APIs that use zero-terminated strings for output are very rare and most often inherently unsafe. Andrei
Re: Poll: Primary D version
On 05/23/2010 12:30 AM, Rainer Deyke wrote: On 5/22/2010 23:16, Mike Parker wrote: That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args. There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'. There is a way, you could simply allocate a copy plus the \0 on the GC heap. In fact that's what happens right now. Andrei
Re: Poll: Primary D version
On 05/23/2010 04:47 AM, Pelle wrote: On 05/23/2010 10:14 AM, Mike Parker wrote: And I would argue that it's unreasonable to expect the declarations of C functions to be declared const-correct based on their usage. To my knowledge, all of the C bindings for D to date either don't use const at all (because they were created for D1) or use it according to the declarations in the C headers. Which means there are numerous C functions out there with non-const params that do not modify them. I do them according to the C headers, and the constness is almost always correct. Otherwise, it's a bug in the C headers! Yes. My experience with C headers is that they're always careful about inserting const for read-only pointer parameters. Then there's the issue of compatibility between D1/D2. I've bound several C libraries for D that need to support both D1/D2, Phobos/Tango. Supporting const was one of the first headaches I encountered when porting the original D1 bindings to D2. Finding that toStringz returned a const string was a big surprise. It should probably be inout(char)* toStringz(inout(char)[]), or something like that. It could, but what C functions output to a zero-terminated char*? I can only think of unsafe ones, such as strcat() and gets(). Both are inherently unsafe. Andrei
Re: Poll: Primary D version
On 5/23/2010 07:33, Andrei Alexandrescu wrote: On 05/23/2010 12:30 AM, Rainer Deyke wrote: There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'. There is a way, you could simply allocate a copy plus the \0 on the GC heap. In fact that's what happens right now. No, the problem is getting any changes to the copy back to the original. It can be done, but not with a simple conversion function. -- Rainer Deyke - rain...@eldwood.com
Re: Poll: Primary D version
Am 21.05.2010 23:14, schrieb Matthias Pleh: Am 21.05.2010 22:27, schrieb Nick Sabalausky: Matthias Plehmatthias.p...@gmx.at wrote in message news:ht6p7t$27s...@digitalmars.com... Oh god, we have to inform micropoll, there is more than the USA ... Kagamins...@here.lot wrote in message news:ht6jgv$1tb...@digitalmars.com... I'd appreciate js, but pissed off by flash. Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) ) Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows It says See how users are polling in Vorarlberg : Total Votes : 2 So it seems that in every erea of us life 2 D-enthusiasts ...
Re: Poll: Primary D version
Am 20.05.2010 08:52, schrieb Nick Sabalausky: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. For all who want to see the current result, without voting twice: http://www.micropoll.com/akira/mpresult/928402-256449
Re: Poll: Primary D version
On 20/05/10 07:52, Nick Sabalausky wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. I put my vote with D1 2, although truthfully I've moved back to D1 for the most part. I found D2 almost impossible to use, for a few reasons: - Safe D was impossible to use due to phobos not supporting this (although this seems to be close to a fix) - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions - to!() didn't work in most cases where I tried to use it, I ended up writing my own conversion functions - Various bugs I encountered which have already been reported (I forget which ones). - Lack of an x86_64 compiler. I spent far too long messing around setting up a multilib system, and ended up making a chroot for dmd. This is far too much effort/messing around, and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). - Lack of containers in phobos, although dcollections may have solved this now, I haven't had chance to look There were some other reasons I've forgotten, but until at least some of these are fixed I'll stick to D1/Tango... I hope I can move back to D2 at some point in the future once it's stabilized a bit more.
Re: Poll: Primary D version
On 05/22/2010 08:29 AM, Robert Clipsham wrote: On 20/05/10 07:52, Nick Sabalausky wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. I put my vote with D1 2, although truthfully I've moved back to D1 for the most part. I found D2 almost impossible to use, for a few reasons: - Safe D was impossible to use due to phobos not supporting this (although this seems to be close to a fix) - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness. - to!() didn't work in most cases where I tried to use it, I ended up writing my own conversion functions to is deliberately defined to be restrictive; parse is more forgiving. Anyway, I'd be glad to improve to if you gave me a few hints. - Various bugs I encountered which have already been reported (I forget which ones). - Lack of an x86_64 compiler. I spent far too long messing around setting up a multilib system, and ended up making a chroot for dmd. This is far too much effort/messing around, and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). - Lack of containers in phobos, although dcollections may have solved this now, I haven't had chance to look There were some other reasons I've forgotten, but until at least some of these are fixed I'll stick to D1/Tango... I hope I can move back to D2 at some point in the future once it's stabilized a bit more. Yah, for most of these things are definitely looking up. Thanks, and I'd appreciate any more detail you might have. Andrei
Re: Poll: Primary D version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sean Kelly wrote: retard Wrote: What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I've yet to use a compiler that had zero bugs I needed to consider when writing code. What's more important to me is that the bugs that do exist shouldn't unduly inconvenience me, nor should they hurt my ability to easily move to a newer compiler later. VC6 was terrible in this respect--it crashed constantly, and so badly supported the language spec that I had to purposefully write screwed up code just so it would compile. Moving to VC7 took a lot of rewriting. Assuming there are no sufficiently annoying bugs in DMD2 I'd rather work with the latest language spec to make my app more maintainable over time. In a work environment, I think it's more important that a compiler be supported than that it be bug-free. Well I'm still using 2.028. Every version I've tried since has had a compiler bug that's been a show stopper. However I'm in no major rush, there's enough momentum in progress for me to be confidant that it will work eventually. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL+BW1T9LetA9XoXwRAthRAJ9lrqaoqWj7QAZxc3Aye4Mldk/OiACfWvT0 sjc5M0Q5/zhzDoCQ7y1V4CQ= =P4EP -END PGP SIGNATURE-
Re: Poll: Primary D version
Robert Clipsham rob...@octarineparrot.com wrote in message news:ht8m7t$2qu...@digitalmars.com... - and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem.
Re: Poll: Primary D version
On 22/05/10 17:42, Andrei Alexandrescu wrote: - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness. extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it. extern(C)void someFunc(wchar*); This is impossible with phobos, there's no function to convert a D string to wchar*, not even one where I could cast away constness. This includes dchar* too. - to!() didn't work in most cases where I tried to use it, I ended up writing my own conversion functions to is deliberately defined to be restrictive; parse is more forgiving. Anyway, I'd be glad to improve to if you gave me a few hints. Any of the above conversions would be nice, although I appreciate that there's no way to tell if it's a C style string or a pointer to a single char. There were several other situations which I worked around but didn't note down, so I can't list them here.
Re: Poll: Primary D version
On 05/22/2010 08:26 PM, Robert Clipsham wrote: extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string You could use (array.dup ~ '\0').ptr, right? extern(C)void someFunc(wchar*); This is impossible with phobos, there's no function to convert a D string to wchar*, not even one where I could cast away constness. This includes dchar* too. to!(wchar[])(chararray) works.
Re: Poll: Primary D version
Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote: Robert Clipsham rob...@octarineparrot.com wrote in message news:ht8m7t$2qu...@digitalmars.com... - and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem. You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. In addition, x86 programs might be tuned for i586 or i386, forcing them to not utilize only 50% of the registers available. In the worst case they don't even use SSE at all! Some assembly experts here probably know how much slower x87 is when compared to SSE2+. Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at http://www.bestbuy.com/site/HP+-+Factory-Refurbished+Desktop+with+AMD +Athlon%23153;+II+X2+Dual-Core+Processor/9880623.p? id=1218188306780skuId=9880623 I already have 24 GB in my Core i7 system. I can't imagine how a 32-bit system would benefit modern users.
Re: Poll: Primary D version
On 5/22/10, retard r...@tard.com.invalid wrote: On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries.
Re: Poll: Primary D version
Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote: On 5/22/10, retard r...@tard.com.invalid wrote: On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries. I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture.
Re: Poll: Primary D version
On 5/22/10, retard r...@tard.com.invalid wrote: I can't believe the 64-bit processes are twice as large. They probably aren't. I don't think we're talking about the same thing here. I, and I don't think Nick is either, am not saying that 64-bit is bad. We're just saying not having 64 bit isn't a big deal for most applications, since 32-bit apps aren't bad either. Yes, it would be nice to have a 64 bit compiler for when you need it, but odds are, your application doesn't need it.
Re: Poll: Primary D version
div0 wrote: Well I'm still using 2.028. Every version I've tried since has had a compiler bug that's been a show stopper. However I'm in no major rush, there's enough momentum in progress for me to be confidant that it will work eventually. Which one is your current showstopper?
Re: Poll: Primary D version
retard r...@tard.com.invalid wrote in message news:ht9atu$ro...@digitalmars.com... Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote: Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem. You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. I never said it was. All I said was that most apps don't need native 64-bit versions. Don't go pulling out strawmen. On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. In addition, x86 programs might be tuned for i586 or i386, forcing them to not utilize only 50% of the registers available. In the worst case they don't even use SSE at all! Some assembly experts here probably know how much slower x87 is when compared to SSE2+. Take a 32-bit executable optimized for i386 or i586, that runs acceptably well on a 32-bit system (say, a P4, or even a P4-era Celeron). Take that same binary, put it on a 64-bit system (say, your Core i7). It will run *at least* at fast, most likely faster. Could it be made even faster than that with a 64-bit-native recompile? Sure. But if the 32-bit binary already ran acceptably well on the 32-bit system, and even faster on the 64-bit system, then who gives a shit? Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at Guess how much more that costs me than using my 32-bit system that already does everything I need it to do? $379. Keep in mind, I live in a normal place, not some fantasy land like California where a million dollars is pocket change. If I had hundreds of dollars to toss around, I'd get my bad tooth pulled. At least then I'd be getting a non-trivial benefit.
Re: Poll: Primary D version
Andrei Alexandrescu: to is deliberately defined to be restrictive; parse is more forgiving. Anyway, I'd be glad to improve to if you gave me a few hints. If you are interested, I have written: http://d.puremagic.com/issues/show_bug.cgi?id=3961 http://d.puremagic.com/issues/show_bug.cgi?id=4165 http://d.puremagic.com/issues/show_bug.cgi?id=4168 For the 4168 I can write some kind of patch too... Bye, bearophile
Re: Poll: Primary D version
On 5/22/10, bearophile bearophileh...@lycos.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=4165 I don't think that's a bug. It should only worry about converting, not filtering out bad stuff. That's an orthogonal problem that the other function does well, and easily too.
Re: Poll: Primary D version
Adam Ruppe: I don't think that's a bug. It should only worry about converting, not filtering out bad stuff. That's an orthogonal problem that the other function does well, and easily too. It's not a bug, right. But saying that there are other functions orthogonal to it that solve this problem is not enough. There is a balance you have to adopt between having a so flexible language/stdlib that's sloppy and can lead to bugs, and to have as much orthogonal functions as possible that are fussy and can lead to opposite kinds of bugs. Very often if I have to convert strings to numbers I have leading or trailing spaces, often a leading newline. Converting such string to a number is not sloppiness because my experience shows me it can hardly cause bugs in general. The way to!() is currently designed forces me to remove the spaces often. This has caused a bug in one of my small script-like D programs. So if to!() will not strip spaces I'll have to define a stripping+conversion function in my dlibs2, and I'd like dlibs2 to be as small as possible. Bye, bearophile
Re: Poll: Primary D version
On 05/22/2010 02:38 PM, retard wrote: Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote: On 5/22/10, retardr...@tard.com.invalid wrote: On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries. I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture. It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. Andrei
Re: Poll: Primary D version
On 05/22/2010 02:22 PM, retard wrote: Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote: Robert Clipshamrob...@octarineparrot.com wrote in message news:ht8m7t$2qu...@digitalmars.com... - and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem. You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. In addition, x86 programs might be tuned for i586 or i386, forcing them to not utilize only 50% of the registers available. In the worst case they don't even use SSE at all! Some assembly experts here probably know how much slower x87 is when compared to SSE2+. Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at http://www.bestbuy.com/site/HP+-+Factory-Refurbished+Desktop+with+AMD +Athlon%23153;+II+X2+Dual-Core+Processor/9880623.p? id=1218188306780skuId=9880623 I already have 24 GB in my Core i7 system. I can't imagine how a 32-bit system would benefit modern users. You both have a point. Clearly not a lot of individual applications really need more than 4GB (though unfortunately, many are pushing up for the wrong reasons), but then a whole category of them would greatly benefit of expanded RAM availability. Andrei
Re: Poll: Primary D version
Robert Clipsham wrote: On 22/05/10 17:42, Andrei Alexandrescu wrote: - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness. extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it. What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it.
Re: Poll: Primary D version
Andrei Alexandrescu wrote: You both have a point. Clearly not a lot of individual applications really need more than 4GB (though unfortunately, many are pushing up for the wrong reasons), but then a whole category of them would greatly benefit of expanded RAM availability. I would phrase it as the greatly expanded address space. This offers a ton of benefits even if your app uses very little actual memory. For example, the stack size problem for threads pretty much goes away. Garbage collection can get much better. You can have much better hardware detection of wild pointers.
Re: Poll: Primary D version
Sat, 22 May 2010 16:23:35 -0500, Andrei Alexandrescu wrote: On 05/22/2010 02:38 PM, retard wrote: Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote: On 5/22/10, retardr...@tard.com.invalid wrote: On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries. I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture. It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. Ah, good to know. I haven't really seen many comparisons of 32-bit code vs 64-bit code. Haven't researched to topic much, either. But it makes sense when the payload is small vs the size of the pointer. I think some VMs deal with the issue by compressing pointers ( http://wikis.sun.com/ display/HotSpotInternals/CompressedOops ). In JVM, the maximum size of compressed pointer heap is only 32 GB, though, so we need to invent something new for desktop systems in 2020.
Re: Poll: Primary D version
Andrei Alexandrescu: It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. Some of that extra space is used by the pointers that are twice larger. The latest JavaVM are able to compress pointers in some situations, this can contain some info: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.8725 The main LLVM designer has studied that in C-like languages too, such ideas can be usable in D too: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html If you are interested in this, you can find more papers, with examples, benchmarks, etc. Bye, bearophile
Re: Poll: Primary D version
Sat, 22 May 2010 16:25:55 -0400, Nick Sabalausky wrote: retard r...@tard.com.invalid wrote in message news:ht9atu$ro...@digitalmars.com... Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote: Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem. You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. I never said it was. All I said was that most apps don't need native 64-bit versions. Don't go pulling out strawmen. Sorry for pulling out that, but I thought the claim most apps was a bit overoptimistic. If D is The next gen language, it probably also should solve the next generation of problems. I don't see much point in rewriting notepad, mspaint or solitaire in D. If you only need to deal with a small amount of data, why use native low-level languages? The fact is that resource usage will grow and artificial limitations (32-bit code) just makes the language irrelevant a lot faster. Another problem with x86 code is that you need to install all kinds of 32- bit libraries on a x86-64 (Linux) system. You also don't have the full 2.5 - 3.7 GB (depending on of RAM available for processes, the limit is something like 2 or 3 GB depending on the OS settings [1] (in some cases you need to assume the user has only allowed 2 GB for user mode processes). So in reality you could probably have even less than 2 GB available. Is that a problem? Yes, it is a serious problem in professional audio/video/photo applications, soon games (huge game worlds, complex SVM/ANN AI), and all kinds of servers. Take a 32-bit executable optimized for i386 or i586, that runs acceptably well on a 32-bit system (say, a P4, or even a P4-era Celeron). Take that same binary, put it on a 64-bit system (say, your Core i7). It will run *at least* at fast, most likely faster. Yea, it will run faster, but who said the original application ran fast enough? CPU demanding applications never run fast enough. The applications tend to require more and more resources. It seems the x87 instructions (i386/586) have 5-6x larger latency than SSE2+ and SSE2+ has 2-4x greater throughput. Combined, that could mean 20x slower loops. Could it be made even faster than that with a 64-bit-native recompile? Sure. But if the 32-bit binary already ran acceptably well on the 32-bit system, and even faster on the 64-bit system, then who gives a shit? Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at Guess how much more that costs me than using my 32-bit system that already does everything I need it to do? $379. Sure. And I have to admit I don't really know what's your target audience. It might even be 8086 systems since IIRC dmd/dmc support old 16- bit dos environments. But most commercial applications aren't geared towards Your 32-bit system. There's a good reason - people do upgrade their systems at least once in 5 years (x86-64 appeared 7 years ago..). Your system *will* physically break at some point and you have to replace it, probably with a faster one, because they won't be selling compatible parts anymore. Computers have a limited life time. Ordinary people don't lubricate their fans or replace bad capacitors themselves. You can find used parts, but those are more expensive than new ones. For example a used 128MB/SDRAM-100 module typically costs as much as a 1GB/ DDR2-800 here. Budget GPUs for the PCI bus cost 4x as much as similar PCI Express cards. A 750GB PATA disk costs as much as a 1500GB SATA-2 disk. And let's be honest, $379 isn't that much - if you only upgrade the cpu +mobo+ram+gpu, it's closer to $100-150. If you can't afford that much once in 5 years, you should stop developing software, seriously. If Your application doesn't require new hardware, the 3rd party software forces you to upgrade. For example, recently I noticed that the Ati/ Nvidia GPU control panel requires a .NET version that is not available for Windows 2000 (and that's not the only program not working on Windows 2000 anymore..). So I must buy a new operating system.. but people can't legally sell their used OEM Windows without also selling me their 64-bit machines =) And I can't buy a new Windows XP/Vista license, only Windows 7 available on stores. So basically I'm forced to also upgrade the hardware. [1] http://www.brianmadden.com/blogs/brianmadden/archive/2004/02/19/ the-4gb-windows-memory-limit-what-does-it-really-mean.aspx
Re: Poll: Primary D version
retard wrote: Sorry for pulling out that, but I thought the claim most apps was a bit overoptimistic. If D is The next gen language, it probably also should solve the next generation of problems. FWIW, I fully agree with the notion that D needs to fully support 64 bit compilation.
Re: Poll: Primary D version
retard r...@tard.com.invalid wrote in message news:ht9n8n$ro...@digitalmars.com... Sat, 22 May 2010 16:25:55 -0400, Nick Sabalausky wrote: retard r...@tard.com.invalid wrote in message news:ht9atu$ro...@digitalmars.com... Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote: Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem. You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. I never said it was. All I said was that most apps don't need native 64-bit versions. Don't go pulling out strawmen. Sorry for pulling out that, but I thought the claim most apps was a bit overoptimistic. If D is The next gen language, it probably also should solve the next generation of problems. I never said D or DMD shouldn't support x64, hence, yea, I agree that it should support 64-bit to, as you say solve the next generation of problems. I just think that, for most apps, it's silly for someone to feel that they must have a 64-bit binary. I don't see much point in rewriting notepad, mspaint or solitaire in D. For someone who seems to believe so strongly in out with the old, in with the new, it seems rather odd that you expect apps along the lines of notepad, mspaint, etc to all stick around forever and with the same old langauge. If you only need to deal with a small amount of data, why use native low-level languages? 1. Why not? There's nothing about smaller apps that necessitates anything like a VM. 2. To avoid pointless bloat. Just because some people have a gajillion cores and petabytes of ram doesn't mean there's any reason to settle for a notepad that eats up a third of that. 3. I know this isn't in line with the current trendiness-compliant viewpoints, but I'd much rather find a good language and be able to stick with it for whatever I need than constantly bounce around a hundred different languages for every little thing. The fact is that resource usage will grow and artificial limitations (32-bit code) just makes the language irrelevant a lot faster. Why do you still imply that I've advocated keeping D/DMD 32-bit-only? Another problem with x86 code is that you need to install all kinds of 32- bit libraries on a x86-64 (Linux) system. If your Core i7 system with 24 GB RAM has any trouble keeping around the 32-bit libs in addition to 64-bit ones, then you got royally screwed over. But if you're talking about the bother of installing the 32-bit libs, well, that's Linux for you (Not that I'm a fan of any particular OS). You also don't have the full 2.5 - 3.7 GB (depending on of RAM available for processes, the limit is something like 2 or 3 GB depending on the OS settings [1] (in some cases you need to assume the user has only allowed 2 GB for user mode processes). So in reality you could probably have even less than 2 GB available. I only have 1 GB installed, so I couldn't care less. (Although I could have sworn I had 2 GB. Weird...Maybe I moved the other stick over to my Linux box when I built it...) Is that a problem? Yes, it is a serious problem in professional audio/video/photo applications, soon games (huge game worlds, complex SVM/ANN AI), and all kinds of servers. Video: By what I admit is a rather big coincidence, I have some video processing going on in the background right as I type this. Seriously. I do video processing on this machine and I get by fine. Obviously, I would want to get a 64-bit multi-core with gobs of RAM if I were doing it professionally, but I think you're seriously underestimating the capabilities of P4-era hardware. Games: I'll put it this way: I bought a Wii, and not a 360 or a PS3, specifically because I don't give a rat's ass about game graphics that are anything more than, frankly, Gamecube or XBox 1 level. One of my favorite games is Megaman 9. So you can't tell me that all that fancy hardware is, or will ever be, necessary for games. It is necessary for *some* types of games, but these days that's only because developers like Epic are in bed with the hardware manufacturers and refuse to care one bit about anyone who isn't a High-Def graphics whore. Also, I hate playing games at a desk (or on a laptop, for that matter), so I almost always play on a console system, and therefore don't need my PC to play games anyway. A lot of gamers feel the same way (and there's plenty of other issues with games-on-a-PC too, like rootkit DRM and lack of second-hand-market). And for that matter, most PC users never go anywhere near the sorts of games that require fancy hardware anyway. So
Re: Poll: Primary D version
Andrei Alexandrescu Wrote: It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. It's always possible to trim down the bits used for a pointer inside a data structure if the savings really matters. Doing so can create some really interesting bugs though.
Re: Poll: Primary D version
Sean Kelly wrote: Andrei Alexandrescu Wrote: It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. It's always possible to trim down the bits used for a pointer inside a data structure if the savings really matters. Doing so can create some really interesting bugs though. The 'reduced' pointer memory model is a bad fit for D because: 1. D has to work with the corresponding C compiler, which does not support such a memory model. This kills it right there. 2. This will kill off a lot of the benefits of having a large address space that have nothing to do with allocating a lot of memory. I mentioned these in another post. 3. Having to support 2 memory models doubles the work. Two libraries, two test suite runs, more documentation, inevitable user confusion and mismatching, everyone shipping a library has to ship two, etc. If you must shrink the space required by pointers for a particular data structure, I suggest instead storing an offset instead of the pointer. Then, follow the indirection by adding said offset to a base pointer.
Re: Poll: Primary D version
Walter Bright wrote: Robert Clipsham wrote: On 22/05/10 17:42, Andrei Alexandrescu wrote: - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness. extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it. What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it. That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args.
Re: Poll: Primary D version
On 5/22/2010 23:16, Mike Parker wrote: That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args. There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'. -- Rainer Deyke - rain...@eldwood.com
Re: Poll: Primary D version
Nick Sabalausky Wrote: Nick Sabalausky a...@a.a wrote in message news:ht3uj4$30f...@digitalmars.com... div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: ... - Troll and/or trolls. I turned on enable IP logging, but I didn't turn on prevent multiple votes from same IP, since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. ... I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia. Thats great. It proves my point - even D trolls are loyal to the project. 72 votes? That is some dedication.
Re: Poll: Primary D version
Fri, 21 May 2010 11:00:32 -0400, Bane wrote: Nick Sabalausky Wrote: Nick Sabalausky a...@a.a wrote in message news:ht3uj4$30f...@digitalmars.com... div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: ... - Troll and/or trolls. I turned on enable IP logging, but I didn't turn on prevent multiple votes from same IP, since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. ... I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia. Thats great. It proves my point - even D trolls are loyal to the project. 72 votes? That is some dedication. What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby.
Re: Poll: Primary D version
What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I'm in serious business with it. I think D1 is up to it pretty well.
Re: Poll: Primary D version
Bane Wrote: What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I'm in serious business with it. I think D1 is up to it pretty well. D1 I mean. Shit. I lack clarity.
Re: Poll: Primary D version
retard wrote: What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. What matters not is the number of bugs, it is whether they block reasonable use of the compiler. Just one bug can make it unusable, whereas a thousand insignificant ones may not.
Re: Poll: Primary D version
Nick Sabalausky Wrote: I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. I'd appreciate js, but pissed off by flash.
Re: Poll: Primary D version
Walter Bright wrote: What matters not is the number of bugs, it is whether they block reasonable use of the compiler. Just one bug can make it unusable, whereas a thousand insignificant ones may not. In Steven's dcollections excerpt starting from dcollections/model/List.d, line #80: // workaround for compiler deficiencies. Note you MUST repeat this in // derived classes to achieve covariance (see bug 4182). alias concat opCat; alias concat_r opCat_r; alias add opCatAssign; http://d.puremagic.com/issues/show_bug.cgi?id=4182 Could you please explain is this a bug or feature? -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Re: Poll: Primary D version
Am 20.05.2010 08:52, schrieb Nick Sabalausky: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. Oh god, we have to inform micropoll, there is more than the USA ...
Re: Poll: Primary D version
Matthias Pleh matthias.p...@gmx.at wrote in message news:ht6p7t$27s...@digitalmars.com... Oh god, we have to inform micropoll, there is more than the USA ... Kagamin s...@here.lot wrote in message news:ht6jgv$1tb...@digitalmars.com... I'd appreciate js, but pissed off by flash. Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )
Re: Poll: Primary D version
Am 21.05.2010 22:27, schrieb Nick Sabalausky: Matthias Plehmatthias.p...@gmx.at wrote in message news:ht6p7t$27s...@digitalmars.com... Oh god, we have to inform micropoll, there is more than the USA ... Kagamins...@here.lot wrote in message news:ht6jgv$1tb...@digitalmars.com... I'd appreciate js, but pissed off by flash. Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) ) Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows
Re: Poll: Primary D version
On Thu, 2010-05-20 at 14:19 -0400, Nick Sabalausky wrote: div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: - There are a lot of people who are keeping a close eye on D, but aren't ready/able to commit to any use just yet. In fact, I've already been under the impression that that's the case. That's exactly my case. I'm waiting for D2 to stabilise, for D2 compilers to hit Debian unstable, and for me having both some time and a good itch to scratch. For the time being, I find this newsgroup very informative, versatile and yet not too busy to follow as an infrequent visitor. Thanks to everyone who makes this possible, Viktor.
Re: Poll: Primary D version
On 5/21/2010 1:57 PM, retard wrote: hat is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. Or possibly, D newsgroup followers are mostly early-adopters, which makes the poll skewed toward D2.
Re: Poll: Primary D version
Matthias Pleh Wrote: Am 21.05.2010 22:27, schrieb Nick Sabalausky: Matthias Plehmatthias.p...@gmx.at wrote in message news:ht6p7t$27s...@digitalmars.com... Oh god, we have to inform micropoll, there is more than the USA ... Kagamins...@here.lot wrote in message news:ht6jgv$1tb...@digitalmars.com... I'd appreciate js, but pissed off by flash. Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) ) Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows Does it say See how users are polling in Bohinj : Total Votes : 2 for you too?
Re: Poll: Primary D version
Eric Poggel dnewsgr...@yage3d.net wrote in message news:ht7i0u$hv...@digitalmars.com... On 5/21/2010 1:57 PM, retard wrote: hat is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. Or possibly, D newsgroup followers are mostly early-adopters, which makes the poll skewed toward D2. I also posted on the Tango message board, which is definitely skewed towards D1. But then again, that only has 25 views and I know at least five of them were me reloading the page.
Re: Poll: Primary D version
Matthias Pleh matthias.p...@gmx.at wrote in message news:ht6t33$2fv...@digitalmars.com... Am 21.05.2010 22:27, schrieb Nick Sabalausky: Matthias Plehmatthias.p...@gmx.at wrote in message news:ht6p7t$27s...@digitalmars.com... Oh god, we have to inform micropoll, there is more than the USA ... Kagamins...@here.lot wrote in message news:ht6jgv$1tb...@digitalmars.com... I'd appreciate js, but pissed off by flash. Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) ) Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows I was surprised to see that there's another D user in Ohio besides me. From what I've seen, all the good programmers usually leave Ohio, and we're just left with the cruft.
Re: Poll: Primary D version
retard Wrote: What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I've yet to use a compiler that had zero bugs I needed to consider when writing code. What's more important to me is that the bugs that do exist shouldn't unduly inconvenience me, nor should they hurt my ability to easily move to a newer compiler later. VC6 was terrible in this respect--it crashed constantly, and so badly supported the language spec that I had to purposefully write screwed up code just so it would compile. Moving to VC7 took a lot of rewriting. Assuming there are no sufficiently annoying bugs in DMD2 I'd rather work with the latest language spec to make my app more maintainable over time. In a work environment, I think it's more important that a compiler be supported than that it be bug-free.
Re: Poll: Primary D version
Hello Nick, I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. your missing Mosty Dx but some of the other. -- ... IXOYE
Re: Poll: Primary D version
Nick Sabalausky, el 20 de mayo a las 02:52 me escribiste: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. Oh, yeah! Only USA uses D... Nice =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- We're rotten fruit We're damaged goods What the hell, we've got nothing more to lose One gust and we will probably crumble We're backdrifters
Re: Poll: Primary D version
OBG! I'm minority! (still stuck on 1.030) Nick Sabalausky Wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one.
Re: Poll: Primary D version
OMG! I can't even spell OMG right! OBG! I'm minority! (still stuck on 1.030) Nick Sabalausky Wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one.
Re: Poll: Primary D version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bane wrote: OMG! I can't even spell OMG right! OBG! I'm minority! (still stuck on 1.030) rofl. you tool. (i mean that in a good way) I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL9XkwT9LetA9XoXwRAslqAKCGBjh2XR3WJ1Pc6wAn0kiMZgTYbACfSXy5 UujYfGkxvmEj/e8TBDZfCIQ= =+GPH -END PGP SIGNATURE-
Re: Poll: Primary D version
BCS n...@anon.com wrote in message news:a6268ff13eaa8ccc5f8db8fc...@news.digitalmars.com... Hello Nick, I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one. your missing Mosty Dx but some of the other. The idea was just to gauge which one a person leans more heavily towards.
Re: Poll: Primary D version
div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: - There are a lot of people who are keeping a close eye on D, but aren't ready/able to commit to any use just yet. In fact, I've already been under the impression that that's the case. - Troll and/or trolls. I turned on enable IP logging, but I didn't turn on prevent multiple votes from same IP, since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. - Maybe people misunderstood what I meant by Which version of D do you primarily use?. What I meant was When you use D, which version do you use more heavily?. Maybe there are people thinking Well, I use D, but my primary language is C/Python/Java/whatever, so I'll say 'None'. Question to all, including lurkers: Did anyone say None because that's what they thought it meant?
Re: Poll: Primary D version
Nick Sabalausky a...@a.a wrote in message news:ht3uj4$30f...@digitalmars.com... div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: ... - Troll and/or trolls. I turned on enable IP logging, but I didn't turn on prevent multiple votes from same IP, since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. ... I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia.
Re: Poll: Primary D version
As a thought, when/if you decide to write your own polling system, I think it should log the website referrer as well as the voter's ip and choice. It'd be interesting to see stats about skewing from a certain site, like if everyone who followed a link on d-sucks-ass.org voted none and never will, you might be able to discount them as trolls.
Re: Poll: Primary D version
Nick Sabalausky a...@a.a wrote: I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia. Looking at the statistics, if we assume all those 72 votes are for 'None - Not likely to use D anytime soon', we get these nice numbers: D2 43 % Both D1 and D2 fairly equally 3 % D1 - Not likely to use D2 anytime soon 28 % D1 - Likely to switch to D2 soon 6 % D1 - Likely to do both D1 and D2 soon 5 % None - Not likely to use D anytime soon 9 % None - Likely to use D2 soon 6 % None - Likely to use D1 soon 0 % None - Likely to use both D1 and D2 soon 0 % Honestly, I find this to seem more likely as a serious result. That said, I do not expect 43% of programmers to be using D at the moment. :P -- Simen
