www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Oh Dear

reply Steve Teale <steve.teale britseyeview.com> writes:
D Friends/Enemies,

Looking at the current crop of postings, it seems like people are staying off
the subject of where D is going (we've had a lot of that lately, without any
result), and concentrating on less and less important particulars.

So we are we doomed, like the Oomigooly bird, to fly around in ever decreasing
circles, until we eventually disappear up our own asshole?

As per the current fashion, I apologize profusely for any offense I may cause
to anyone as a result of this message. But we do need to arrive at conclusions.
D2 should be stabilized and D1 deprecated, there should be one standard
library, there should be a new linker and object file format, and there should
be a change made to the acceptable content of the primary newsgroup (the learn
suggestion is the best we have so far).

Steve
Jul 11 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Steve Teale wrote:
 D Friends/Enemies,
 
 Looking at the current crop of postings, it seems like people are staying off
the subject of where D is going (we've had a lot of that lately, without any
result), and concentrating on less and less important particulars.
 
 So we are we doomed, like the Oomigooly bird, to fly around in ever decreasing
circles, until we eventually disappear up our own asshole?
 
 As per the current fashion, I apologize profusely for any offense I may cause
to anyone as a result of this message. But we do need to arrive at conclusions.
D2 should be stabilized and D1 deprecated, there should be one standard
library, there should be a new linker and object file format, and there should
be a change made to the acceptable content of the primary newsgroup (the learn
suggestion is the best we have so far).
 
 Steve
Woooaaahh.. dejavu! Wait a minute...
Jul 11 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steve Teale:
D2 should be stabilized<
That will happen in time, but rushing things is very bad. There are some other things to be fixed/done first, like: - concurrency; - making D2 fitter for the LLVM back-end; - fixing the import semantics; - improving arrays and slices; - improving operator overloading; - maybe improving matrices and slices; - maybe improving the data parallelism. Plus a lot of smaller details to fix, add or improve. I have surely missed something.
and D1 deprecated,<
I see no purpose in deprecating D1 in the short term. D1 is simpler than D2, so some people may prefer it. Eventually D1 may vanish, but it doesn't need to be killed on purpose.
there should be one standard library,<
I don't agree, I'd like to have both Phobos and Tango at the same time, and useful for different purposes, like I have both STL and Boost (among other things, like Qt) installed with the C++ compiler.
there should be a new linker and object file format,<
Once LDC supports exceptions on Windows I think LDC can slowly become the reference implementation of D1/D2, and it will use a new linker, etc.
and there should be a change made to the acceptable content of the primary
newsgroup (the learn suggestion is the best we have so far).<
I don't fully understand you, but it doesn't sound like a too much hard thing to do. Bye, bearophile
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
bearophile wrote:

D2 should be stabilized<
That will happen in time, but rushing things is very bad. There are some other things to be fixed/done first, like: - concurrency; - making D2 fitter for the LLVM back-end; - fixing the import semantics; - improving arrays and slices; - improving operator overloading; - maybe improving matrices and slices; - maybe improving the data parallelism. Plus a lot of smaller details to fix, add or improve. I have surely missed something.
I believe that what D really needs is a complete formal specification of the language grammar and semantics. Last I heard, there wasn't any. Just my two cents.
there should be one standard library,<
I don't agree, I'd like to have both Phobos and Tango at the same time, and useful for different purposes, like I have both STL and Boost (among other things, like Qt) installed with the C++ compiler.
There would seem to be a difference. Boost was designed to complement the STL. Boost does not offer features that the STL already possesses. As I understand it, Tango and Phobos both try to be the one and only D standard library. Perhaps if the two teams sat down together, they could design one terrific library. But who has the time? I agree with the Qt analogy. I use it for designing GUIs. But it annoys me greatly that they try to reinvent every functionality that's already in the STL. QString, QList, QEverything. There was simply no need. Disclaimer: My information on the D specification and Tango/Phobos may be out of date. I haven't actually programmed in D for years. I mostly lurk in the newsgroup to read the language design discussions. -- Michiel Helvensteijn
Jul 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 I believe that what D really needs is a complete formal specification of the
 language grammar and semantics. Last I heard, there wasn't any.
There is a specification. It isn't complete and there are bugs in it, but it constantly gets worked on to improve it. Anyone can submit improvements on it to bugzilla. The lack of a 100% specification has never hindered any language I can think of from attaining wide use. What mattered there was that the language solved the problems that needed solving.
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 I believe that what D really needs is a complete formal specification of
 the language grammar and semantics. Last I heard, there wasn't any.
There is a specification. It isn't complete and there are bugs in it, but it constantly gets worked on to improve it. Anyone can submit improvements on it to bugzilla. The lack of a 100% specification has never hindered any language I can think of from attaining wide use. What mattered there was that the language solved the problems that needed solving.
I'm not sure. You may be right. But in my opinion, the language specification should define the language, whereas any single compiler should merely implement it. It looks like D works the other way around. The D website offers a reference manual for the general workings of D. It gives examples. Most of it is explained clearly. But it's not a formal specification. Words are very imprecise. For example, from the MulExpression sections of D (1.0 and 2.0): ---------- For integral operands, the *, /, and % correspond to multiply, divide, and modulus operations. For multiply, overflows are ignored and simply chopped to fit into the integral type. If the right operand of divide or modulus operators is 0, an Exception is thrown. ---------- What does "chopped to fit the integral type" mean? What if it's a multiplication between two differently sized integral types? And how does D handle integer division when one or both of the operands are negative? Does it use truncated division, Euclidean division, floored division? I can't tell by the modulo operator, since it is implementation defined for negative operands (which seems like a strange decision, since this makes modulo utterly unreliable in those cases). ---------- (continued) For integral operands of the % operator, the sign of the result is positive if the operands are positive, otherwise the sign of the result is implementation defined. ---------- I believe you want "non-negative" there. See what I mean? When you get down to the details, the reader is left guessing, because formal semantics should be given in math, not in English. That's how compiler writers know how to implement their compiler. I can understand that when you start designing a programming language, you write the compiler and document the language from there. But I believe a language as far along as D should not be working that way anymore. -- Michiel Helvensteijn
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Michiel Helvensteijn wrote:

 What does "chopped to fit the integral type" mean? What if it's a
 multiplication between two differently sized integral types?
I'm sorry. I missed the first sentence of that section, which explains this part of it nicely: ---------- They undergo integral promotions, and then are brought to a common type using the usual arithmetic conversions. ---------- But the rest of my example stands. -- Michiel Helvensteijn
Jul 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 But the rest of my example stands.
I agree with you that it should be better. I just don't agree with it being a showstopper. I invite you to contribute spec corrections to the examples you pointed out.
Jul 11 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Michiel Helvensteijn wrote:
 But the rest of my example stands.
I agree with you that it should be better. I just don't agree with it being a showstopper. I invite you to contribute spec corrections to the examples you pointed out.
Said corrections to preferably be submitted through bugzilla so they don't get lost.
Jul 11 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Walter Bright wrote:
 Michiel Helvensteijn wrote:
 But the rest of my example stands.
I agree with you that it should be better. I just don't agree with it being a showstopper. I invite you to contribute spec corrections to the examples you pointed out.
Said corrections to preferably be submitted through bugzilla so they don't get lost.
Yes, absolutely. I should have mentioned that.
Jul 11 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 I agree with you that it should be better. I just don't agree with it
 being a showstopper.
You know that the D Wikipedia article states: "The official compiler by Walter Bright defines the language itself."? In other words, every bug in DMD is really a feature of the language. Until you fix it. That kind of permanent instability may be part of the reason people have been so negative around here lately.
 I invite you to contribute spec corrections to the examples you pointed
 out.
I will file those corrections. However, the MulExpression thing was only an example. The first one I checked, too. The mentality behind "compiler first, specification later" just seems wrong to me. And that's not something I can report to bugzilla (or can I). By the way, what kind of integer division *does* D use? -- Michiel Helvensteijn
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 Walter Bright wrote:
 
 I agree with you that it should be better. I just don't agree with it
 being a showstopper.
You know that the D Wikipedia article states: "The official compiler by Walter Bright defines the language itself."?
That's often the way many successful languages are. They only get formal standards for them written after they become mainstream, not before.
 In other words, every bug in DMD is really a feature of the language. Until
 you fix it. That kind of permanent instability may be part of the reason
 people have been so negative around here lately.
I don't agree with that characterization. Bugs get reported to bugzilla, and get fixed in a regular cycle.
 I invite you to contribute spec corrections to the examples you pointed
 out.
I will file those corrections.
Thank you, I look forward to it.
 However, the MulExpression thing was only an
 example. The first one I checked, too. The mentality behind "compiler
 first, specification later" just seems wrong to me. And that's not
 something I can report to bugzilla (or can I).
 
 By the way, what kind of integer division *does* D use?
To be frank, it is what the x86 DIV instruction does. But I agree that the modulus should be defined, regardless of whether that makes it less efficient on some machines.
Jul 12 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 In other words, every bug in DMD is really a feature of the language.
 Until you fix it. That kind of permanent instability may be part of the
 reason people have been so negative around here lately.
I don't agree with that characterization. Bugs get reported to bugzilla, and get fixed in a regular cycle.
Sure they do. But if it's really true that the DMD implementation *is* the D language specification, any bug in DMD would also be part of that specification. And as the compiler changes, so does the spec. It's the danger of that approach.
 I will file those corrections.
Thank you, I look forward to it.
Issue 3165, Issue 3166.
 By the way, what kind of integer division *does* D use?
To be frank, it is what the x86 DIV instruction does.
After a quick Google search, it would seem DIV is the x86 "unsigned divide" instruction. Are you sure you aren't using IDIV ("signed divide") for negative operands? If not, you'd actually be interpreting 2's complement signed ints as unsigned ints. (And surely such a thing would have been noticed before now?)
 But I agree that 
 the modulus should be defined, regardless of whether that makes it less
 efficient on some machines.
Good. Make sure that your divide operation and your modulo operation are consistent. The following identity should hold: if a / n = q and a % n = r a = q*n + r -- Michiel Helvensteijn
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 Walter Bright wrote:
 
 In other words, every bug in DMD is really a feature of the language.
 Until you fix it. That kind of permanent instability may be part of the
 reason people have been so negative around here lately.
I don't agree with that characterization. Bugs get reported to bugzilla, and get fixed in a regular cycle.
Sure they do. But if it's really true that the DMD implementation *is* the D language specification, any bug in DMD would also be part of that specification. And as the compiler changes, so does the spec. It's the danger of that approach.
Looking at the kinds of issues reported in bugzilla makes it pretty plain that D users well understand the difference between a bug and a problem with the specification. I don't believe there is any danger there. Nobody is going to mistake a compiler crash, for example, as specified behavior.
 
 I will file those corrections.
Thank you, I look forward to it.
Issue 3165, Issue 3166.
Thank you.
 By the way, what kind of integer division *does* D use?
To be frank, it is what the x86 DIV instruction does.
After a quick Google search, it would seem DIV is the x86 "unsigned divide" instruction. Are you sure you aren't using IDIV ("signed divide") for negative operands? If not, you'd actually be interpreting 2's complement signed ints as unsigned ints. (And surely such a thing would have been noticed before now?)
If there's any question about it, you can do a quick test and check what the compiler generates with obj2asm. If it wasn't doing things correctly, you bet people would have noticed by now. A divide that doesn't work is going to be very, very obvious.
 But I agree that 
 the modulus should be defined, regardless of whether that makes it less
 efficient on some machines.
Good. Make sure that your divide operation and your modulo operation are consistent. The following identity should hold: if a / n = q and a % n = r a = q*n + r
Jul 12 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 If there's any question about it, you can do a quick test and check what
 the compiler generates with obj2asm. If it wasn't doing things
 correctly, you bet people would have noticed by now. A divide that
 doesn't work is going to be very, very obvious.
Actually I suspect that integer division with negative values is rare enough that a problem might escape notice for some time. Python uses floor division, which is 99% of the time the type of division I want. C++ uses truncating division, which is almost never what I want. D does not specify the type of division used, although if it uses IDIV then it uses truncating division. Result: in C++ (and D) I use my own library function to perform floor division instead of relying on the built-in division operator. Signed integer division never gets tested for negative values. -- Rainer Deyke - rainerd eldwood.com
Jul 12 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Rainer Deyke wrote:

 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.
Yep. It's possible. I suggest someone tests this. I don't have a D compiler installed, and I don't really have time for this.
 floor division, which is 99% of the time the type of division I want.
Agreed. I'm using floored division in my new programming language. The quotient rounds towards negative infinity and the result of the mod operation has the same sign as the divisor. However, it seems D prides itself on its speed. And since truncated division is implemented by the hardware, D will probably use that. And that's acceptable, as long as it's guaranteed (predictable). -- Michiel Helvensteijn
Jul 12 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:
 Rainer Deyke wrote:
 
 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.
Yep. It's possible. I suggest someone tests this. I don't have a D compiler installed, and I don't really have time for this.
 floor division, which is 99% of the time the type of division I want.
Agreed. I'm using floored division in my new programming language. The quotient rounds towards negative infinity and the result of the mod operation has the same sign as the divisor. However, it seems D prides itself on its speed. And since truncated division is implemented by the hardware, D will probably use that. And that's acceptable, as long as it's guaranteed (predictable).
My personal bug-bear is that D inherited C's insane % behaviour. I had this cause a really horrible bug in my simulator where if you set the virtual date to before the epoch (which you would do in the course of simulating historical events), the scheduling system went completely bananas. Took ages to find that one because I'd been testing dates post-epoch.
Jul 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Keep:
 My personal bug-bear is that D inherited C's insane % behaviour.
I too don't like that %. Is this something that can be fixed in D? Bye, bearophile
Jul 12 2009
next sibling parent BCS <none anon.com> writes:
Hello bearophile,

 Daniel Keep:
 
 My personal bug-bear is that D inherited C's insane % behaviour.
 
I too don't like that %. Is this something that can be fixed in D? Bye, bearophile
Short of overflow detection (and the overhead that causes) I think this is an issue inherent to discreet systems (a.k.a. all computer systems) that we just have to live with.
Jul 12 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:
 Daniel Keep:
 My personal bug-bear is that D inherited C's insane % behaviour.
I too don't like that %. Is this something that can be fixed in D? Bye, bearophile
No, because that would mean having valid C code which has different semantics in D. BCS wrote:
 Short of overflow detection (and the overhead that causes) I think
 this is an issue inherent to discreet systems (a.k.a. all computer
 systems) that we just have to live with.
I was referring to what happens when you have a%b and a is negative. Every sane language I've used ensures the result is 0<=x<b, whereas C doesn't. *grumbles*
Jul 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 I don't have a D compiler
 installed, and I don't really have time for this.
Thanks to Ary, there's now a one click installer for Windows: http://ftp.digitalmars.com/dinstaller.exe
Jul 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Michiel Helvensteijn wrote:
 I don't have a D compiler
 installed, and I don't really have time for this.
Thanks to Ary, there's now a one click installer for Windows: http://ftp.digitalmars.com/dinstaller.exe
Awesome! Is everything automated such that whenever you release the installer will be in good shape? Andrei
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Is everything automated such that whenever you release the 
 installer will be in good shape?
Of course not!
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Is everything automated such that whenever you release the installer 
 will be in good shape?
Of course not!
What steps do we need to take to automate the process? Andrei
Jul 12 2009
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Jul 12, 2009 at 03:28:43PM -0500, Andrei Alexandrescu wrote:
 Walter Bright wrote:
Andrei Alexandrescu wrote:
Is everything automated such that whenever you release the installer 
will be in good shape?
Of course not!
What steps do we need to take to automate the process? Andrei
Here's an idea: make it download d1-latest.zip* and d2-latest.zip. Then, on the server, make those names redirect to whatever the latest actually is, using a symlink or a HTTP redirect header. * Or .php, see below. My preference would be the HTTP redirect, so you see the correct filename before the download begins; you could differentiate between the different versions. It looks like you have PHP installed on the Digital Mars .com server. This could be done in just a few lines of that language: ===== <?php header("Location: dmd-1.x.zip"); ?> ===== Then, instead of fetching d1-latest.zip, fetch d1-latest.php. The script that publishes the new release could them simply overwrite those php files telling the new file location. I put it up on my server so you can see what it is like to the user: http://arsdnet.net/latest.php Notice how it prompts you to download file.zip automatically. Granted, going with this, the installer's downloader would need to understand the http location header, but if you are using a http library, it probably already does. And if not, it isn't terribly difficult to code it up yourself. This shouldn't require much changes to the way things are done, and would offer a nice generic place for people to fetch the new things. -- Adam D. Ruppe http://arsdnet.net
Jul 12 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribió:
 Michiel Helvensteijn wrote:
 I don't have a D compiler
 installed, and I don't really have time for this.
Thanks to Ary, there's now a one click installer for Windows: http://ftp.digitalmars.com/dinstaller.exe
Very nice! You took the time to modify it to download both D1 and D2, and also dmd. :-) Just one thing: when you select both D1 and D2, both directories are added to the path and when you execute dmd it defaults to the first one found (D1). How could this be solved?
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 You took the time to modify it to download both D1 and D2, and also dmd. 
 :-)
 
 Just one thing: when you select both D1 and D2, both directories are 
 added to the path and when you execute dmd it defaults to the first one 
 found (D1). How could this be solved?
I don't know. I also didn't figure out how to set the menu shortcuts properly depending on what was or was not installed. I was hoping you could help!
Jul 12 2009
next sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Ary Borenszweig wrote:
 You took the time to modify it to download both D1 and D2, and also
 dmd. :-)

 Just one thing: when you select both D1 and D2, both directories are
 added to the path and when you execute dmd it defaults to the first
 one found (D1). How could this be solved?
I don't know. I also didn't figure out how to set the menu shortcuts properly depending on what was or was not installed. I was hoping you could help!
Easy suggestion.. rename dmd 2's executable to dmd2.
Jul 12 2009
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Jul 12, 2009 at 01:30:26PM -0700, Walter Bright wrote:
 Ary Borenszweig wrote:
You took the time to modify it to download both D1 and D2, and also dmd. 
:-)

Just one thing: when you select both D1 and D2, both directories are 
added to the path and when you execute dmd it defaults to the first one 
found (D1). How could this be solved?
I don't know. I also didn't figure out how to set the menu shortcuts properly depending on what was or was not installed. I was hoping you could help!
The Windows SDK uses a little script and an environment variable to pick your platform. You can do (I forget the actual syntax...): setenv /x64 make And it builds you the 64 bit version. Or setenv /XP And it sets everything up to target Windows XP. Perhaps the D installer could set up something similar. It could be very simple: dversion /d2 dmd And you get dmd for D2. Then dversion /d1 dmd And you get D1. Indeed, this could be taken to another level: dversion /d2 will use the newest version of dmd2 available, but also dversion /v2.013 will specifically use dmd 2.013. All dversion does is adjust the PATH to point at the right folder. It could be a pretty simple script (especially if you limit it to just the /d1 and /d2 switches). -- Adam D. Ruppe http://arsdnet.net
Jul 12 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Adam D. Ruppe wrote:
 (stuff)
Urgh. I *hate* programs that screw with my PATH. Personally, I've found that the simplest way to solve the multiple compiler problem is to just shove them all in different directories. AFAIK, dmd works just fine with relative directories, so it's not like you HAVE to have the compiler on the PATH. For example, my system has DMD 1.035 + Tango 99.somethingorother as the "default" compiler (it's the one on PATH). It's in \bin\dmd\dmd-default. Then I have the following other directories in \bin\dmd: * dmd-1.035 * dmd-1.042-tango * dmd-1.046-tango * dmd-2.023 * dmd-2.025 * dmd-2.026 * dmd-2.028 * dmd-2.029 * dmd-2.030 * dmd-custom (was playing around with compiler patches) * tango-trunk (Odd that I have so many 2.x compilers, and yet I don't use them... :P) Compiling with a particular version is pretty easy; instead of typing 'dmd BLAH', I use '\bin\dmd\dmd-x.yyy\bin\dmd BLAH'. I also have rebuild set up to have most of these available as separate compilers. So, for example, when I was testing a project with 1.046+Tango trunk, I went from building like so:
 dsss build
to this:
 dsss build -dc=tango-trunk
The only time this system doesn't work is building Tango which doesn't provide any way to override which compiler gets used. But then I solve that with a batch file that just shoves the appropriate compiler on to the front of the PATH. Incidentally, thanks for making DMD work like this, Walter. I have a big, fairly important project that has its own private copy of the entire toolchain so it's compiler version is stable. Absolutely indispensable. :D
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 Incidentally, thanks for making DMD work like this, Walter.  I have a
 big, fairly important project that has its own private copy of the
 entire toolchain so it's compiler version is stable.  Absolutely
 indispensable.  :D
A long time ago, I got sick of tools that required environment variables to be set.
Jul 13 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 I don't have a D compiler
 installed, and I don't really have time for this.
Thanks to Ary, there's now a one click installer for Windows: http://ftp.digitalmars.com/dinstaller.exe
That's nice. But I run Linux. Walter, surely this test shouldn't take more than a minute for you (or anyone else with a D compiler installed). Just see what DMD outputs for: 8 / 3 8 / (-3) (-8) / 3 (-8) / (-3) 8 % 3 8 % (-3) (-8) % 3 (-8) % (-3) If D uses DIV instead if IDIV, this should be immediately visible. In any case, we will see exactly what kind of division and modulo D uses. You can compare with the table on the bottom of page 3 of: http://www.cs.uu.nl/~daan/download/papers/divmodnote.pdf That's an informative article, by the way. -- Michiel Helvensteijn
Jul 12 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Michiel Helvensteijn wrote:

 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed).
Ok, ok. I'll do it. Here's the results: ---------------------------------- import std.stdio; int main() { writefln(8/3); writefln(8/(-3)); writefln((-8)/3); writefln((-8)/(-3)); writefln(8%3); writefln(8%(-3)); writefln((-8)%3); writefln((-8)%(-3)); return 0; } ---------------------------------- outputs the following ---------- 2 -2 -2 2 2 2 -2 -2 ---------- So DMD uses truncated division. The quotient rounds towards zero and the remainder has the same sign as the dividend. I've updated issue 3165 with this information. Hope that helps. -- Michiel Helvensteijn
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 Michiel Helvensteijn wrote:
 
 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed).
Ok, ok. I'll do it. Here's the results: ---------------------------------- import std.stdio; int main() { writefln(8/3); writefln(8/(-3)); writefln((-8)/3); writefln((-8)/(-3)); writefln(8%3); writefln(8%(-3)); writefln((-8)%3); writefln((-8)%(-3)); return 0; } ---------------------------------- outputs the following ---------- 2 -2 -2 2 2 2 -2 -2 ---------- So DMD uses truncated division. The quotient rounds towards zero and the remainder has the same sign as the dividend. I've updated issue 3165 with this information. Hope that helps.
Thanks, Michiel. Here's what I have in TDPL. Is it 100% in sync with you? ======================================= The multiplicative expressions are multiplication (\ccbox{a * b}), division (\ccbox{a / b}), and remainder (\ccbox{a \% b}). They operate on numeric types only. The result type is same as the type of \ccbox{true ? a : b}. If~ b is zero in \ccbox{a / b} or \ccbox{a \% b}, a hardware exception is thrown. The sign\footnote{Sign, not signedness, i.e.,~the sign of the actual value.} of \ccbox{a \% b} is always the same as the sign of~ a . That is, \ccbox{a \% b} is the closest number to zero of the same sign of~ a that must be added to~ a to make it divisible by~ b . For example, \ccbox{-5 \% 2} and \ccbox{-5 \% -2} both yield~\cc{-1}. \dee\ also defines modulus for floating-point numbers in the same way as the IEEE~754 standard. When at least one of a and b is a floating-point value in \cc{a \% b}, the result is the floating-point number r satisfying the relation \cc{a = b * n + r}, where n is an integer\footnote{``integer'' in the mathematical sense here} and r is a positive number less than b 's absolute value. ======================================= Thanks, Andrei
Jul 12 2009
next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:

 Thanks, Michiel. Here's what I have in TDPL. Is it 100% in sync with you?
 
 =======================================
 ...
 
 If~ b   is  zero in  \ccbox{a  /  b} or  \ccbox{a  \%  b}, a  hardware
 exception   is  thrown.    The  sign\footnote{Sign,   not  signedness,
 i.e.,~the sign of  the actual value.}  of \ccbox{a  \% b} is always
 the same as  the sign of~ a .  That is, \ccbox{a \%  b} is the closest
 number to  zero of the same sign  of~ a 
Now that I read it again (the last words there), this is not completely accurate. I know I made the same mistake myself just now, but the remainder has not necessarily the same sign as 'a', since it may be zero, which is signless. Of course, such a triviality won't hinder anyone's understanding, but you may as well be accurate, no? Some thing like "same sign as~ a (or zero)", perhaps? (Also note the word 'as' instead of 'of', which is not strictly grammatically correct.)
 that must be  added to~ a  to 
 make it divisible by~ b .  For  example, \ccbox{-5 \% 2} and \ccbox{-5
 \% -2} both yield~\cc{-1}.
The rest of the information is accurate, but you still neglect to mention the type of division. D uses truncated division. The quotient rounds towards zero. In other words, it cuts off the fractional part of the result. Good luck with your book. -- Michiel Helvensteijn
Jul 12 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:

 \dee\ also defines modulus for  floating-point numbers in the same way
 as the  IEEE~754  standard.  When  at least one  of  a   and  b   is a
 floating-point value in \cc{a \%  b}, the result is the floating-point
 number  r  satisfying the relation \cc{a = b * n + r}, where  n  is an
 integer\footnote{``integer'' in  the mathematical sense  here} and  r 
 is a positive number less than  b 's absolute value.
Oh, about this part. I left it out because it's not about integer division, but while I'm at it anyway. I believe you wanted the word "non-negative" there, instead of "positive". However, I just ran the following test: ---------------------------- writefln(5.0%2.0); writefln(5.0%(-2.0)); writefln((-5.0)%2.0); writefln((-5.0)%(-2.0)); ---------------------------- it outputs: ---------- 1 1 -1 -1 ---------- So the remainder can still become negative, it seems. Same as with integer modulo. I would expect this consistency, but your paragraph there says something different. -- Michiel Helvensteijn
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:
 
 \dee\ also defines modulus for  floating-point numbers in the same way
 as the  IEEE~754  standard.  When  at least one  of  a   and  b   is a
 floating-point value in \cc{a \%  b}, the result is the floating-point
 number  r  satisfying the relation \cc{a = b * n + r}, where  n  is an
 integer\footnote{``integer'' in  the mathematical sense  here} and  r 
 is a positive number less than  b 's absolute value.
Oh, about this part. I left it out because it's not about integer division, but while I'm at it anyway. I believe you wanted the word "non-negative" there, instead of "positive". However, I just ran the following test: ---------------------------- writefln(5.0%2.0); writefln(5.0%(-2.0)); writefln((-5.0)%2.0); writefln((-5.0)%(-2.0)); ---------------------------- it outputs: ---------- 1 1 -1 -1 ---------- So the remainder can still become negative, it seems. Same as with integer modulo. I would expect this consistency, but your paragraph there says something different.
Walter? Andrei
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter?
D % for floating point arguments does what the C99 fmod function does:
 Description
 The fmod functions compute the floating-point remainder of x/y.
 Returns
 The fmod functions return the value x - ny, for some integer n such that, if y
is nonzero,
 the result has the same sign as x and magnitude less than the magnitude of y.
If y is zero,
 whether a domain error occurs or the fmod functions return zero is
implementation-defined.
Jul 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter?
D % for floating point arguments does what the C99 fmod function does:
 Description
 The fmod functions compute the floating-point remainder of x/y.
 Returns
 The fmod functions return the value x - ny, for some integer n such 
 that, if y is nonzero,
 the result has the same sign as x and magnitude less than the 
 magnitude of y. If y is zero,
 whether a domain error occurs or the fmod functions return zero is 
 implementation-defined.
Great. Could you please now replace the implementation-defined part with something well-defined and appropriate? Thanks. Andrei
Jul 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 In any case, we will see exactly what kind of division and modulo D uses.
Given the code: void foo() { int x,y,z; x = y / z; x = y % z; uint ux,uy,uz; // unsigned for C ux = uy / uz; ux = uy % ux; } dmd produces: enter 010h,0 xor EAX,EAX mov -010h[EBP],EAX mov -0Ch[EBP],EAX mov EAX,-010h[EBP] cdq idiv dword ptr -0Ch[EBP] mov EAX,-010h[EBP] cdq idiv dword ptr -0Ch[EBP] xor ECX,ECX mov -8[EBP],ECX mov -4[EBP],ECX mov EAX,-4[EBP] xor EDX,EDX div ECX mov -8[EBP],EAX mov EAX,-4[EBP] xor EDX,EDX div dword ptr -8[EBP] mov -8[EBP],EDX leave ret For comparison, gcc produces: push EBP mov EBP,ESP sub ESP,038h mov EAX,-8[EBP] mov -034h[EBP],EAX mov EDX,-034h[EBP] mov EAX,EDX sar EDX,01Fh idiv dword ptr -0Ch[EBP] mov -4[EBP],EAX mov EDX,-8[EBP] mov EAX,EDX sar EDX,01Fh idiv dword ptr -0Ch[EBP] mov -4[EBP],EDX mov EAX,-014h[EBP] mov EDX,0 div dword ptr -018h[EBP] mov -010h[EBP],EAX mov EAX,-014h[EBP] mov -038h[EBP],EAX mov EAX,-038h[EBP] mov EDX,0 div dword ptr -010h[EBP] mov -010h[EBP],EDX leave ret Producing the same results as the corresponding C compiler does is quite deliberate. I'd like to emphasize that the code generator has been in use for 25 years for several hundred thousand users, and it is incredibly unlikely that nobody would notice if it is getting basic integer arithmetic wrong. If you'd like to write up a formal definition that can be inserted into the D specification, that would be great.
Jul 12 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:
 For comparison, gcc produces:
I think you'll find that VC, DMC, DMC++, g++, Intel C++, Borland C++, Watcom, etc., etc., all produce the same results for x86 on Linux, Windows, Mac OSX, FreeBSD, etc.
Jul 12 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 I'd like to emphasize that the code generator has been in
 use for 25 years for several hundred thousand users, and it is
 incredibly unlikely that nobody would notice if it is getting basic
 integer arithmetic wrong.
I didn't think the compiler would be wrong. I was just replying to your statement that D does what x86 DIV does (you didn't mention IDIV; hence my initial confusion).
 If you'd like to write up a formal definition 
 that can be inserted into the D specification, that would be great.
I've given an unambiguous description of D division and modulus in another subthread here. I've also updated issue 3165 with the information. You can use that. -- Michiel Helvensteijn
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:
 Walter Bright wrote:
 
 I'd like to emphasize that the code generator has been in
 use for 25 years for several hundred thousand users, and it is
 incredibly unlikely that nobody would notice if it is getting basic
 integer arithmetic wrong.
I didn't think the compiler would be wrong. I was just replying to your statement that D does what x86 DIV does (you didn't mention IDIV; hence my initial confusion).
No problem, my mistake.
 If you'd like to write up a formal definition 
 that can be inserted into the D specification, that would be great.
I've given an unambiguous description of D division and modulus in another subthread here. I've also updated issue 3165 with the information. You can use that.
Thank you, this is valuable. I appreciate it.
Jul 12 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michiel Helvensteijn:
 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed). Just see what DMD outputs for:
 
   8  /   3
   8  / (-3)
 (-8) /   3
 (-8) / (-3)
   8  %   3
   8  % (-3)
 (-8) %   3
 (-8) % (-3)
You don't know codepad.org :-) D version: http://codepad.org/Mbi9HBjz void main() { writefln( 8 / 3); writefln( 8 / (-3)); writefln( (-8) / 3); writefln( (-8) / (-3)); writefln( 8 % 3); writefln( 8 % (-3)); writefln( (-8) % 3); writefln( (-8) % (-3)); } D output: 2 -2 -2 2 2 2 -2 -2 ------------- Python version: http://codepad.org/Mbi9HBjz print 8 // 3 print 8 // (-3) print (-8) // 3 print (-8) // (-3) print 8 % 3 print 8 % (-3) print (-8) % 3 print (-8) % (-3) Python output: 2 -3 -3 2 2 -1 1 -2 --------------------- BCS:
Short of overflow detection (and the overhead that causes) I think this is an
issue inherent to discreet systems (a.k.a. all computer systems) that we just
have to live with.<
I don't understand what's the purpose of overflow detection in this context. Are those differences between the D and Python output caused by overflows? Bye and thank you, bearophile
Jul 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Python output:
The result of / depends on which version of Python you're using: http://www.python.org/doc/2.2.3/whatsnew/node7.html
Jul 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html
I have used Python 2.6, and the numbers I have shown you are correct for Python 3.1 too. I don't like how the % behaves in C when there can be negative numbers. Bye, bearophile
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html
I have used Python 2.6, and the numbers I have shown you are correct for Python 3.1 too. I don't like how the % behaves in C when there can be negative numbers.
According to the python pep, the integer / divide semantics changed from "C" style to match what the floating point / does. While this makes sense for a language that is typeless, it doesn't work for D because: 1. it would cause D code to silently produce different results than the corresponding C/C++ code. This is extremely important, as I guarantee that when someone new tries porting existing C code to D, and it doesn't work, their conclusion will not be "perhaps I should recode the / expression", it will be "D sux". Note that there is no way the compiler could issue a warning about this as it cannot determine a dependency on the rounding method. 2. it is slower than the current method.
Jul 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 bearophile wrote:
 Walter Bright:
 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html
I have used Python 2.6, and the numbers I have shown you are correct for Python 3.1 too. I don't like how the % behaves in C when there can be negative numbers.
According to the python pep, the integer / divide semantics changed from "C" style to match what the floating point / does. While this makes sense for a language that is typeless, it doesn't work for D because: 1. it would cause D code to silently produce different results than the corresponding C/C++ code. This is extremely important, as I guarantee that when someone new tries porting existing C code to D, and it doesn't work, their conclusion will not be "perhaps I should recode the / expression", it will be "D sux". Note that there is no way the compiler could issue a warning about this as it cannot determine a dependency on the rounding method.
But C gives the implementation leeway to define '/' as they find fit. This is useless because it makes it difficult to write portable code. We must improve on that.
 2. it is slower than the current method.
We want something well-defined. I agree to adopt the semantics of IDIV but we must understand that those might be slower on other machines. Andrei
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 1. it would cause D code to silently produce different results than 
 the corresponding C/C++ code. This is extremely important, as I 
 guarantee that when someone new tries porting existing C code to D, 
 and it doesn't work, their conclusion will not be "perhaps I should 
 recode the / expression", it will be "D sux". Note that there is no 
 way the compiler could issue a warning about this as it cannot 
 determine a dependency on the rounding method.
But C gives the implementation leeway to define '/' as they find fit. This is useless because it makes it difficult to write portable code. We must improve on that.
Right, but the de-facto behavior for C compilers is do behave as D currently does.
 2. it is slower than the current method.
We want something well-defined. I agree to adopt the semantics of IDIV but we must understand that those might be slower on other machines.
Yes - not only do I think that is ok, but CPUs have been for a long time designed to accommodate C, and the de-facto way C does things, including the divide. I don't expect this to change, so I don't expect a penalty on some future processor because of it.
Jul 12 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 According to the python pep, the integer / divide semantics changed from
 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:
The PEP is wrong (which underlines the need for accurate documentation, I guess). Integer division in Python uses floor division instead of truncated division, and to the best of my knowledge has always used floor division. This is the result of a deliberate choice. Floor division is usually technically superior to truncated division The operator for integer division in Python has recently changed from '/' to '//', but Python still has an integer division operator and this operator still uses floor division. -- Rainer Deyke - rainerd eldwood.com
Jul 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:
 Walter Bright wrote:
 According to the python pep, the integer / divide semantics changed from
 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:
The PEP is wrong (which underlines the need for accurate documentation, I guess). Integer division in Python uses floor division instead of truncated division, and to the best of my knowledge has always used floor division. This is the result of a deliberate choice. Floor division is usually technically superior to truncated division The operator for integer division in Python has recently changed from '/' to '//', but Python still has an integer division operator and this operator still uses floor division.
If Python always used floor division, why did it add a // operator that does exactly the same thing as / ? http://www.python.org/doc/2.2.3/whatsnew/node7.html
Jul 12 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 If Python always used floor division, why did it add a // operator that 
 does exactly the same thing as / ?
See this (Python 2.6):
 500 / 30
16
 500 // 30
16
 500 / 30.0
16.666666666666668
 500 // 30.0
16.0
 from __future__ import division
 500 / 30
16.666666666666668
 500 // 30
16
 500 / 30.0
16.666666666666668
 500 // 30.0
16.0 // Always return a number with no fractional part. That "future" is the default in Python 3+ Bye, bearophile
Jul 12 2009
parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:
 That "future" is the default in Python 3+
So I was wrong in the precedent post, sorry. Bye, bearophile
Jul 12 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jul 12, 2009 at 5:36 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Rainer Deyke wrote:
 Walter Bright wrote:
 According to the python pep, the integer / divide semantics changed fro=
m
 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:
The PEP is wrong (which underlines the need for accurate documentation, I guess). =A0Integer division in Python uses floor division instead of truncated division, and to the best of my knowledge has always used floor division. =A0This is the result of a deliberate choice. =A0Floor division is usually technically superior to truncated division The operator for integer division in Python has recently changed from '/' to '//', but Python still has an integer division operator and this operator still uses floor division.
If Python always used floor division, why did it add a // operator that d=
oes
 exactly the same thing as / ?


 http://www.python.org/doc/2.2.3/whatsnew/node7.html
The new // forces integer division. / now means float division always. 1 // 2 --> 0 1 / 2 --> 0.5 They first introduced // as a synonym for / so people could start switching over to it, then they changed the behavior of / later. Python's good at staged introductions of major changes like that. Makes life a lot easier for developers to keep up. --bb
Jul 12 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 If Python always used floor division, why did it add a // operator that
 does exactly the same thing as / ?
Starting with Python 3.0, 'a / b' returns a float even when both operands are integers. 'a // b' performs floor division, even if both operands are floats. Python now has two division operators, neither of which has C-style truncation (i.e. round toward zero). This is explained further in the actual PEP 238 text: http://www.python.org/dev/peps/pep-0238/ -- Rainer Deyke - rainerd eldwood.com
Jul 12 2009
prev sibling parent Jussi Jumppanen <jussij zeusedit.com> writes:
Rainer Deyke Wrote:

 Integer division in Python uses floor division instead of
 truncated division, and to the best of my knowledge has always
 used floor division.  
Based on the results produced by Python 2.6.2 and Python 1.5.1 this does appear to be the case: Python Version: 2.6.2 (r262:71600, Jul 1 2009, 22:22:20) [MSC v.1500 32 bit (Intel)] 8 // 3 = 2 8 // (-3)= -3 (-8) // 3 = -3 (-8) // (-3)= 2 8 % 3 = 2 8 % (-3) = -1 (-8) % 3 = 1 (-8) % (-3) = -2 8 / 3 = 2 8 / (-3) = -3 (-8) / 3 = -3 (-8) / (-3) = 2 8 % 3 = 2 8 % (-3) = -1 (-8) % 3 = 1 (-8) % (-3) = -2 8 / 3 = 2 8 / (-3) = -3 (-8) / 3 = -3 (-8) / (-3) = 2 8 % 3 = 2 8 % (-3) = -1 (-8) % 3 = 1 (-8) % (-3) = -2 Cheers Jussi Note: These results where created by running the Zeus/Python script shown below using a very old version of the Zeus and the recent version of Zeus. import sys import zeus def key_macro(): zeus.screen_update_disable() zeus.FileNew() zeus.write("Python Version: " + sys.version); zeus.write("\n\n") zeus.write(" 8 / 3 = " + str( 8 / 3 ) + "\n", 0) zeus.write(" 8 / (-3) = " + str( 8 / (-3)) + "\n", 0) zeus.write("(-8) / 3 = " + str((-8) / 3 ) + "\n", 0) zeus.write("(-8) / (-3) = " + str((-8) / (-3)) + "\n", 0) zeus.write(" 8 % 3 = " + str( 8 % 3 ) + "\n", 0) zeus.write(" 8 % (-3) = " + str( 8 % (-3) ) + "\n", 0) zeus.write("(-8) % 3 = " + str((-8) % 3 ) + "\n", 0) zeus.write("(-8) % (-3) = " + str((-8) % (-3) ) + "\n", 0) zeus.screen_update_enable() zeus.screen_update()
Jul 12 2009
prev sibling parent BCS <none anon.com> writes:
Hello bearophile,
 BCS:
 
 Short of overflow detection (and the overhead that causes) I think
 this is an issue inherent to discreet systems (a.k.a. all computer
 systems) that we just have to live with.<
 
I don't understand what's the purpose of overflow detection in this context. Are those differences between the D and Python output caused by overflows?
After puzzling over that bit of thread for a bit, the only interpretation I came up with that seemed logical was that it was referring to integers being modulo 2^32: (int.max + 1 == int.min). In rereading it, I'm thinking you were talking about something else.
Jul 12 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:
 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.
Not for 25 years and a few hundred thousand users.
Jul 12 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Steve Teale wrote:

 D Friends/Enemies,
 
 Looking at the current crop of postings, it seems like people are staying
 off the subject of where D is going (we've had a lot of that lately,
 without any result), and concentrating on less and less important
 particulars.
 
 So we are we doomed, like the Oomigooly bird, to fly around in ever
 decreasing circles, until we eventually disappear up our own asshole?
 
 As per the current fashion, I apologize profusely for any offense I may
 cause to anyone as a result of this message. But we do need to arrive at
 conclusions. D2 should be stabilized and D1 deprecated, there should be
 one standard library, there should be a new linker and object file format,
 and there should be a change made to the acceptable content of the primary
 newsgroup (the learn suggestion is the best we have so far).
 
 Steve
Again, what's up with the doom and gloom people? We just had a very good D release, lots of bugs fixed and some lovely new features. Happy days! You are not asking the right questions I think. There *is* 1 standard library for D2 which is phobos and could be complemented with Tango if it will be ported to D2. But D1 is stable where D2 is in development and Tango the library of choice for many. I see no problems here. D2 will be stabilized as planned, current date is set for november this year already! (Way too soon, probably). The question is, HOW will it be stabilized (D3 backwards compatible with D2?) But come on, take a look at the changelog for example to see how fast D is developing, which platforms DMD already support, look at LDC becoming awesome, Descent's power, full D support in slickedit, GtkD, QtD etc. etc.
Jul 11 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:
 Looking at the current crop of postings, it seems like people are
 staying off the subject of where D is going (we've had a lot of that
 lately, without any result), and concentrating on less and less
 important particulars.
Discussions about the bikeshed colors tend to generate lots of postings because they are intellectually easy to participate in. That doesn't bother me. What does bother me is that such discussions tend to result in people digging in and hardening their positions to the point of setting their whole D experience on their particular preferred bikeshed color. More than once people have left D over such trivia. The actual development work that I, Andrei, Don, Sean, etc., engage in, however, remains focussed on the long term goals. I think you can see this in the regular changelog updates.
Jul 11 2009