www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.056 and 2.040 release

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


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

Thanks to the many people who contributed to this update!
Jan 29 2010
next sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
First, i would like to say: thank you.

Second, i would like to have your opinion:
"added static/final function implementations to interfaces"

Could you allow normal function imp to interfaces too? Interface will 
look like c++ struct, but the difference is the way inheritance 
organized, so that diamond shape problem does not exist.

And you could simplify something too. For example: for comparison 
between classes, we just inherit Comparable interface, which has 
implementation of many op<, op>, op<=, op>=, ...

(Well, in fact, this is done in Scala, it is named linearization). :)

For example:

class Biology
{
     ......
}

interface Animal
{
     void eat() { ... }
     void run() { ... }
}

interface Bird
{
     void fly() { ... }
}

class Penguin : Biology, Animal, Bird
{
}

The left most class / interface will be the top super. Each interface 
remain will solve its parent at definition site (line "class Penguin : 
Biology, Animal, Bird")
Result: Penguin -> Bird -> Animal -> Biology.

Details of linearization are in page 52, ScalaRef.
http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf

Thanks.
Jan 29 2010
parent Lionello Lunesu <lio lunesu.remove.com> writes:
On 30-1-2010 15:53, The Anh Tran wrote:
 First, i would like to say: thank you.
 
 Second, i would like to have your opinion:
 "added static/final function implementations to interfaces"
 
 Could you allow normal function imp to interfaces too? Interface will
 look like c++ struct, but the difference is the way inheritance
 organized, so that diamond shape problem does not exist.
Use "final". L.
Jan 30 2010
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Jan 30, 10 15:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Is the changelog page broken? On the 2.0 changelog it starts with "$(D_S D Change Log,", and without a navigation bar.
Jan 30 2010
parent torhu <no spam.invalid> writes:
On 30.01.2010 09:32, KennyTM~ wrote:
 On Jan 30, 10 15:13, Walter Bright wrote:
  http://www.digitalmars.com/d/1.0/changelog.html
  http://ftp.digitalmars.com/dmd.1.056.zip


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

  Thanks to the many people who contributed to this update!
Is the changelog page broken? On the 2.0 changelog it starts with "$(D_S D Change Log,", and without a navigation bar.
And 1.056 is missing, only its changelog is present, but under the 1.055 header.
Jan 30 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
This release makes me smile. Thank you so much Walter, and everybody who 
contributed too.
Jan 30 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Regarding this:
Bugzilla 3556: version(CTFE)

I have written the following little D2 program:


import std.stdio: printf;

static if (__ctfe) {
    int foo() {
        return 1;
    }
} else {
    int foo() {
        return 2;
    }
}

enum int x1 = foo();

void main() {
    int x2 = foo();
    printf("%d %d\n", x1, x2);
}


But it doesn't work, I don't understand why.
(Isn't the usage of __ctfe normally done at compile time? Otherwise this
feature introduces another very special case in the language).

----------------

Can you tell me the purpose of the following 3 changes?

ModuleInfo changed from class to struct

added static/final function implementations to interfaces

http://dsource.org/projects/dmd/changeset/339

Thank you,
bye,
bearophile
Jan 30 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Regarding this:
 Bugzilla 3556: version(CTFE)
 I have written the following little D2 program:
 import std.stdio: printf;
 static if (__ctfe) {
     int foo() {
         return 1;
     }
 } else {
     int foo() {
         return 2;
     }
 }
 enum int x1 = foo();
 void main() {
     int x2 = foo();
     printf("%d %d\n", x1, x2);
 }
 But it doesn't work, I don't understand why.
 (Isn't the usage of __ctfe normally done at compile time? Otherwise this
feature
introduces another very special case in the language).
 ----------------
 Can you tell me the purpose of the following 3 changes?
 ModuleInfo changed from class to struct
 added static/final function implementations to interfaces
 http://dsource.org/projects/dmd/changeset/339
 Thank you,
 bye,
 bearophile
Because a compile-time __ctfe turned out to be almost impossible to implement. Therefore, __ctfe is nominally a regular (runtime) variable that evaluatest to true at compile time and false at runtime. The proper use is if(__ctfe), not static if(__ctfe). However, if(0) statements are thrown out by the code gen, so there should be no runtime performance hit for using if(__ctfe).
Jan 30 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Can you tell me the purpose of the following 3 changes?
 
 ModuleInfo changed from class to struct
Eliminate unnecessary dependencies on Object's vtbl[]
 added static/final function implementations to interfaces
Support NVI (Non Virtual Inheritance) idiom.
Jan 30 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 1/30/10 08:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Very nice. What happened to the change log for 1.055? Why can't we get version(CTFE) in D1 also?
Jan 30 2010
parent reply grauzone <none example.net> writes:
Jacob Carlborg wrote:
 On 1/30/10 08:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Very nice. What happened to the change log for 1.055? Why can't we get version(CTFE) in D1 also?
You can ask this question for all other D2 features backwards compatible to D1 too. Why isn't __traits in D1? Why can't D1 have thread local variables (I'm not talking about TLS-by-default here)?
Jan 30 2010
parent Jacob Carlborg <doob me.com> writes:
On 1/30/10 14:24, grauzone wrote:
 Jacob Carlborg wrote:
 On 1/30/10 08:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Very nice. What happened to the change log for 1.055? Why can't we get version(CTFE) in D1 also?
You can ask this question for all other D2 features backwards compatible to D1 too. Why isn't __traits in D1? Why can't D1 have thread local variables (I'm not talking about TLS-by-default here)?
Because D1 has already got at least two new version identifier since it became feature freeze. But I see now that it's actually not a version identifier, it's a global bool.
Jan 30 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.040.zip
 
 Thanks to the many people who contributed to this update!
Very nice! Each release kills a lot of bugs and adds small but very powerful features. About the interface functions, this compiles: -- import std.stdio; interface One { final void foo() { writefln("One"); } } interface Two { final void foo() { writefln("Two"); } } class X : One, Two { } class Y : Two, One { } void main() { X x = new X(); x.foo(); // prints "One" Y y = new Y(); y.foo(); // prints "Two" } -- Is this intended behaviour? Might leads to obscure bugs...
Jan 30 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 30 Jan 2010 10:56:28 -0500, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Walter Bright wrote:
  http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip
   http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.040.zip
  Thanks to the many people who contributed to this update!
Very nice! Each release kills a lot of bugs and adds small but very powerful features. About the interface functions, this compiles: -- import std.stdio; interface One { final void foo() { writefln("One"); } } interface Two { final void foo() { writefln("Two"); } } class X : One, Two { } class Y : Two, One { } void main() { X x = new X(); x.foo(); // prints "One" Y y = new Y(); y.foo(); // prints "Two" } -- Is this intended behaviour? Might leads to obscure bugs...
This looks like a form of function hijacking, so it should be a accepts-invalid bug.
Jan 30 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Very nice! Each release kills a lot of bugs and adds small but very powerful features. About the interface functions, this compiles: -- import std.stdio; interface One { final void foo() { writefln("One"); } } interface Two { final void foo() { writefln("Two"); } } class X : One, Two { } class Y : Two, One { } void main() { X x = new X(); x.foo(); // prints "One" Y y = new Y(); y.foo(); // prints "Two" } -- Is this intended behaviour? Might leads to obscure bugs...
I think this should lead to a compile-time error. Andrei
Jan 30 2010
prev sibling next sibling parent reply Yao G <foo bar.com> writes:
Walter Bright Wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.040.zip
 
 Thanks to the many people who contributed to this update!
Looks like this doesn't work anymore with this release (D2): --- module Foo; import core.runtime; import std.c.windows.windows; class Bar {} extern(Windows) int WinMain(HINSTANCE instance, HINSTANCE, LPSTR cmdLine, int cmdShow ) { void exceptionHandler(Throwable e) { throw e; } Runtime.initialize( &exceptionHandler ); auto foo = new Foo(); Runtime.terminate ( &exceptionHandler ); return 0; } --- When I run the program it "segfaults" with the following message (when I debug it): Unhandled Exception: EXCEPTION_ACCESS VIOLATION(0xc000005) at object._moduleCtor2.ModuleInfo The exception is thrown from the runtime initializer. It used to work with the previous DMD version (2.039). I think that the change of ModuleInfo from class to struct somehow affected this (just speculating). I did a wrapper for the Windows API and now none of my programs run when I use DMD 2.040. Damn, I was excited by the new disable attribute. :(
Jan 30 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Yao G wrote:
 The exception is thrown from the runtime initializer. It used to work
 with the previous DMD version (2.039). I think that the change of
 ModuleInfo from class to struct somehow affected this (just
 speculating).
Make sure you recompile everything, or you'll get crashes.
Jan 30 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
$ dmd
Digital Mars D Compiler v2.040
Copyright (c) 1999-2009 by Digital Mars written by Walter Bright

Interestingly, copyright date is still 2009. Is this a bug or a feature?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 30 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 $ dmd
 Digital Mars D Compiler v2.040
 Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
 
 Interestingly, copyright date is still 2009. Is this a bug or a feature?
 
It takes a while for me to get all the years changed.
Jan 30 2010
prev sibling next sibling parent reply strtr <strtr spam.com> writes:
Walter Bright Wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.040.zip
 
 Thanks to the many people who contributed to this update!
Do you ever find new bugs while fixing other?
Jan 30 2010
parent Don <nospam nospam.com> writes:
strtr wrote:
 Walter Bright Wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Do you ever find new bugs while fixing other?
Yes. It's a big problem with forward references, because they can affect unrelated parts of the compiler. I think that's the reason that Walter's been slow to apply patches for forward reference bugs. Fortunately, most other bugs aren't like that. The progress is real.
Jan 31 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
D2 changelog points disable to attribute.html#deprecated, should be attribute.html#disable -- Simen
Jan 30 2010
parent Leandro Lucarella <llucax gmail.com> writes:
Simen kjaeraas, el 30 de enero a las 23:23 me escribiste:
 Walter Bright <newshound1 digitalmars.com> wrote:
 
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.056.zip


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

Thanks to the many people who contributed to this update!
D2 changelog points disable to attribute.html#deprecated, should be attribute.html#disable
I reported that in the beta ML but it seems that wasn't important enough to fix :S -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------
Jan 30 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-30 02:13:48 -0500, Walter Bright <newshound1 digitalmars.com> said:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.040.zip
It's great to have TLS working on Mac OS X. But it looks like it suffers from the same linking problem as the module info section. I've added some useful observations to bugzilla that might help fix the issue in case you want to revisit it: http://d.puremagic.com/issues/show_bug.cgi?id=3453 -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 30 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 It's great to have TLS working on Mac OS X. But it looks like it suffers 
 from the same linking problem as the module info section. I've added 
 some useful observations to bugzilla that might help fix the issue in 
 case you want to revisit it:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=3453
You have to recompile *everything* with the new dmd, or anything dependent on the ModuleInfo will not work.
Jan 30 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-30 22:35:28 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Michel Fortin wrote:
 It's great to have TLS working on Mac OS X. But it looks like it 
 suffers from the same linking problem as the module info section. I've 
 added some useful observations to bugzilla that might help fix the 
 issue in case you want to revisit it:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=3453
You have to recompile *everything* with the new dmd, or anything dependent on the ModuleInfo will not work.
This has nothing to do with a partially recompiled program. It's about something interesting I added to this bug report. And trust me, I compiled the test case from scratch before using dumpobj and objdump on the object files and the linked executables. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 30 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 This has nothing to do with a partially recompiled program. It's about 
 something interesting I added to this bug report. And trust me, I 
 compiled the test case from scratch before using dumpobj and objdump on 
 the object files and the linked executables.
All right, except that some others had the same problem, and discovered that they hadn't recompiled everything, and the problem went away when they did.
Jan 30 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 It's about 
 something interesting I added to this bug report.
I submitted a patch for it, 363.
Feb 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-04 01:39:44 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Michel Fortin wrote:
 It's about something interesting I added to this bug report.
I submitted a patch for it, 363.
Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 04 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 On 2010-02-04 01:39:44 -0500, Walter Bright <newshound1 digitalmars.com> 
 said:
 
 Michel Fortin wrote:
 It's about something interesting I added to this bug report.
I submitted a patch for it, 363.
Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections.
I think you're right.
Feb 04 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 On 2010-02-04 01:39:44 -0500, Walter Bright <newshound1 digitalmars.com> 
 said:
 
 Michel Fortin wrote:
 It's about something interesting I added to this bug report.
I submitted a patch for it, 363.
Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections.
Changeset 365
Feb 04 2010
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 30/01/2010 08:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Instead of complaining (as usual) I would like to say "Thank You" for opening the complete D source code. It is pretty clear that since D is open sourced we got much more fixes, and, not to forget, another level of ideas regarding future development tasks. well done. Bjoern
Feb 05 2010
parent reply grauzone <none example.net> writes:
BLS wrote:
 On 30/01/2010 08:13, Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.056.zip


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

 Thanks to the many people who contributed to this update!
Instead of complaining (as usual) I would like to say "Thank You" for opening the complete D source code.
Don't forget thanking Walter for using a public version controlled repository.
 It is pretty clear that since D is open sourced we got much more fixes, 
 and, not to forget, another level of ideas regarding future development 
 tasks.
 
 well done. Bjoern
Feb 05 2010
parent Trass3r <un known.com> writes:
 Don't forget thanking Walter for using a public version controlled  
 repository.
Hell yeah, thank god
Feb 05 2010