www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.058 and 2.043 release

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.058.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.043.zip

Thanks to the many people who contributed to this update!
Apr 08 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Thank you for the release and your work, and thank you to Don for all the bug
fixes.
I will need some more time to test this release better. In the meantime, is it
possible to use BigInts into an AA? This gives a Range violation:

import std.bigint: BigInt;
void main() {
    BigInt[BigInt] aa;
    aa[BigInt(1)]++;
}

Bye,
bearophile
Apr 09 2010
next sibling parent biozic <dransic free.fr> writes:
Le 09/04/10 13:35, bearophile a écrit :

 Thank you for the release and your work, and thank you to Don for all the bug
fixes.
 I will need some more time to test this release better. In the meantime, is it
possible to use BigInts into an AA? This gives a Range violation:

 import std.bigint: BigInt;
 void main() {
      BigInt[BigInt] aa;
      aa[BigInt(1)]++;
 }

 Bye,
 bearophile


Maybe this is the same problem as with:

import std.variant;
void main() {
     Variant[string] aa;
     aa["one"] = 1;
}

Bug 2451?
Apr 09 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:

 Thank you for the release and your work, and thank you to Don for all the bug
fixes.
 I will need some more time to test this release better. In the meantime, is it
possible to use BigInts into an AA? This gives a Range violation:
 
 import std.bigint: BigInt;
 void main() {
     BigInt[BigInt] aa;
     aa[BigInt(1)]++;
 }
 
 Bye,
 bearophile



Could this have anything to do with BigInt not having a toHash() function?

-Lars
Apr 09 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Now I have tested this release a little better, it seems to work well. I have
to say two things:

1) The bug 3911 was a mix of two different bugs, Don has fixed one of them, so
I have closed the bug 3911 and I have opened a new cleaned bug report, number
4075:
http://d.puremagic.com/issues/show_bug.cgi?id=3911
http://d.puremagic.com/issues/show_bug.cgi?id=4075

Because this code generates an error still:
auto foo() { return 0; }
enum int _ = foo();
void main() {}



2) Bug 3972 is not fixed, it's open still. The error message produced is not
good yet. I have added a comment at the bottom:
http://d.puremagic.com/issues/show_bug.cgi?id=3972

In the situation I've shown in 3972 a better error message is the two error
messages (or something similar):

spam.d(2): Error: module 'test' has mismatched file name 'spam.d'.
foo.d(2): Error: module 'bar' has mismatched file name 'foo.d'.

Bye,
bearophile
Apr 09 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 In the situation I've shown in 3972 a better error message is the two error
 messages (or something similar):
 
 spam.d(2): Error: module 'test' has mismatched file name 'spam.d'. foo.d(2):
 Error: module 'bar' has mismatched file name 'foo.d'.



The error is not a mismatched file name, which is perfectly legitimate in D.
The 
error is two different files have the same module name.
Apr 09 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

Thank you for your answer.


 The error is not a mismatched file name, which is perfectly legitimate in D.


Do you mean that in D it is OK to have a file named "foo.d" with inside it at
the top written "module bar;" ?
What's the rationale behind this? (I don't like this).



The error is two different files have the same module name.<


Maybe I am missing something, but:
- there is a module "bar" in the file named "foo.d"
- and there is the module "test" in the file named "spam.d".
All four names are distinct, there are no name duplication (and the imports
can't change this basic fact).

Bye,
bearophile
Apr 09 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:
 
 Thank you for your answer.
 

 The error is not a mismatched file name, which is perfectly legitimate in
 D.


 
 Do you mean that in D it is OK to have a file named "foo.d" with inside it at
 the top written "module bar;" ?


Yes.


 What's the rationale behind this? (I don't like this).


The flexibility comes in handy now and then.
Apr 09 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,


 bearophile wrote:
 

 Walter Bright:
 
 Thank you for your answer.
 

 The error is not a mismatched file name, which is perfectly
 legitimate in D.
 


 Do you mean that in D it is OK to have a file named "foo.d" with
 inside it at the top written "module bar;" ?
 


 Yes.
 

 What's the rationale behind this? (I don't like this).
 


 The flexibility comes in handy now and then.
 


For example, having foo_linux.d and foo_win.d both claiming to be foo.


-- 
... <IXOYE><
Apr 09 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 For example, having foo_linux.d and foo_win.d both claiming to be foo.


OK.
And I presume you don't want to use a single module with a mega version(linux)
{...} else {...} inside.

Thank you,
bearophile
Apr 09 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 09/04/10 23:11, bearophile wrote:

 BCS:

 For example, having foo_linux.d and foo_win.d both claiming to be foo.


 OK.
 And I presume you don't want to use a single module with a mega version(linux)
{...} else {...} inside.

 Thank you,
 bearophile


No need for a huge module, or module names mismatching file names:
----
module foo;

version (linux) import foo_linux;
version (Windows) import foo_linux;
----
Sure it adds and extra file, it's a lot cleaner imo than having a huge 
module with both implementations or mismatching file/module names.
Apr 09 2010
parent reply BCS <none anon.com> writes:
Hello Robert,


 No need for a huge module, or module names mismatching file names:
 ----
 module foo;
 version (linux) import foo_linux;
 version (Windows) import foo_win;
 ----
 Sure it adds and extra file, it's a lot cleaner imo than having a huge
 module with both implementations or mismatching file/module names.


I don't think that works in one case; where you are forced to use fully
qualified 
name.

import foo;
import something.else;

bar(); // calls  something.else.bar;
foo.bar(); // IIRC this don't work

OTOH, you might be able to get around that with the following:

version (linux) { import foo_linux; alias foo_linux foo; }
version (Windows) { import foo_win; alias foo_win foo; }

(I haven't tested any of that because my systems are being shipped right 
now.)

-- 
... <IXOYE><
Apr 09 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 I don't think that works in one case; where you are forced to use fully
qualified 
 name.


You can probably use a "public import".

Bye,
bearophile
Apr 09 2010
parent reply BCS <none anon.com> writes:
Hello bearophile,


 BCS:
 

 I don't think that works in one case; where you are forced to use
 fully qualified name.
 


 You can probably use a "public import".
 


IIRC, all that does is make anything that imports you, import that as well. 
It doesn't do anything to the names.

-- 
... <IXOYE><
Apr 09 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 IIRC, all that does is make anything that imports you, import that as well. 
 It doesn't do anything to the names.


I meant to create a module named "foo" with inside:

module foo;
version (linux) public import foo_linux;
version (Windows) public import foo_win;

The module system has numerous holes (that Walter will need to take a look at,
because three of them alone cover almost 10% of all bugzilla votes), so this is
not going to work perfectly, but now if you import foo you have available all
the names inside foo_linux and foo_win.

Bye,
bearophile
Apr 09 2010
parent BCS <none anon.com> writes:
Hello bearophile,


 BCS:
 

 IIRC, all that does is make anything that imports you, import that as
 well. It doesn't do anything to the names.
 


 I meant to create a module named "foo" with inside:
 
 module foo;
 version (linux) public import foo_linux;
 version (Windows) public import foo_win;
 The module system has numerous holes (that Walter will need to take a
 look at, because three of them alone cover almost 10% of all bugzilla
 votes), so this is not going to work perfectly, but now if you import
 foo you have available all the names inside foo_linux and foo_win.


That's exactly what I thought you were suggesting.

The problem is that, IIRC and assuming foo_linux and foo_win both contain 
a bar, the the following still doesn't work:

foo.bar();

what works is:

foo_linux.bar();

or

foo_win.bar();

In the case that just bar() doesn't work (say there is another bar somewhere 
else), you're sunk.

-- 
... <IXOYE><
Apr 09 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 The flexibility comes in handy now and then.


OK, I have never felt the need of such extra flexibility in my D programs, so I
trust your judgement.

Every time a a semantic hole is left in a language (and this is a little hole),
you have to pay a price, in terms for example of:
- less easy to understand error messages (the currently generated error message
is not easy to understand and I think it's wrong, because in that program the
four names are distinct, there is no duplication);
- less simplicity for the D newbies to learn the language, because to learn
something faster you need a strict teacher;
- possible bugs caused by side effects of the semantic hole (because semantic
holes often create semantic loopholes).

In Delphi the "main unit" of a program is denoted with for example, at the top:
program Project1;

Bye,
bearophile
Apr 09 2010
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
  What's the rationale behind this? (I don't like this).


 The flexibility comes in handy now and then.


but isn't that an abstract form of hijacking then?
or an sideeffect smelling like that?
Apr 10 2010
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Now I have tested this release a little better, it seems to work well. I have
to say two things:
 
 1) The bug 3911 was a mix of two different bugs, Don has fixed one of them, so
I have closed the bug 3911 and I have opened a new cleaned bug report, number
4075:


Please don't clutter the announce newsgroup with bug reports.
And in general, do NOT put multiple bugs in one report. In particular, 
it's worth saying this to everyone: if something causes a compiler 
segfault or an internal compiler error, ALWAYS put it in its own report. 
In > 95% of cases it's a different bug, even if it looks the same as 
something else.
Apr 09 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Please don't clutter the announce newsgroup with bug reports.
 And in general, do NOT put multiple bugs in one report. In particular, 
 it's worth saying this to everyone: if something causes a compiler 
 segfault or an internal compiler error, ALWAYS put it in its own report. 
 In > 95% of cases it's a different bug, even if it looks the same as 
 something else.


Don's right. But it is ok to reply with a link to a bugzilla report.
Apr 09 2010