www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.063 and 2.048 release

reply Walter Bright <newshound2 digitalmars.com> writes:
This is probably the last FreeBSD 7 release for D1. The next will be for
FreeBSD 8!

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

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.048.zip
Aug 11 2010
next sibling parent F. Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 This is probably the last FreeBSD 7 release for D1. The next will

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.063.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.048.zip

I'm always especially happy when a new release has an emphasis on bug fixes. I hope that this trend continues :) I've seen the change log, and most of the annoyances I had encountered with some std.math functions and arrays have been fixed. Thank you so much and congratulations to all involved!
Aug 11 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-11 09:15, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

Very nice. One small thing, on the D1 change log this is mentioned: "Bugzilla 4303: __traits(compiles) returns wrong result when used recursively" This is a D2 only bug. -- /Jacob Carlborg
Aug 11 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 11 Aug 2010 00:15:07 -0700, Walter Bright wrote:

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

Has std.concurrency been brought in line with TDPL for this release? If so, that should be clearly stated in the change log. -Lars
Aug 11 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Lars T. Kyllingstad Wrote:

 On Wed, 11 Aug 2010 00:15:07 -0700, Walter Bright wrote:
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.048.zip

Has std.concurrency been brought in line with TDPL for this release? If so, that should be clearly stated in the change log.

Yes, and it's my fault for not adding it. There wasn't a bugzilla entry for it but it wasn't really a new feature so I left it out.
Aug 11 2010
prev sibling next sibling parent Adrian Matoga <epi atari8.info> writes:
On 2010-08-11 09:15, Walter Bright wrote:
 
 This is probably the last FreeBSD 7 release for D1. The next will be for 
 FreeBSD 8!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.063.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.048.zip

Thanks very, very much! One little thing (D2): it seems that in some cases int array literals are no longer implicitly converted to uint arrays, I'll try to prepare a minimal testcase. Adrian
Aug 11 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 This is probably the last FreeBSD 7 release for D1. The next will be for
FreeBSD 8!
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.063.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.048.zip

Awesome release. Despite having tested the beta, etc. I still couldn't believe how many bugs got fixed when I looked at the full changelog.
Aug 11 2010
prev sibling next sibling parent reply dickl <dick221z yahoo.com> writes:
On 8/11/2010 3:15 AM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

static this() does not seem to be getting called, at least in D2.
Aug 11 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
dickl wrote:
 static this() does not seem to be getting called, at least in D2.

Works for me: ------------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } static this() { printf("betty\n"); } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>
Aug 11 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Michal Minich wrote:
 Are there some changes to runtime initialization, or it is a bug? (in 
 that case I will submit it).

You should submit it.
Aug 11 2010
prev sibling next sibling parent reply dickl <dick221z yahoo.com> writes:
On 8/11/2010 12:04 PM, Walter Bright wrote:
 dickl wrote:
 static this() does not seem to be getting called, at least in D2.

Works for me: ------------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } static this() { printf("betty\n"); } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>

I should have been a little more clear, a static this() as a member of a class.
Aug 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
dickl wrote:
 I should have been a little more clear, a static this() as a member of a 
 class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>
Aug 11 2010
next sibling parent reply dickl <dick221z yahoo.com> writes:
On 8/11/2010 1:09 PM, Walter Bright wrote:
 dickl wrote:
 I should have been a little more clear, a static this() as a member of
 a class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>

Aug 11 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Works for me as well. 2.048   Win32.

dickl Wrote:

 On 8/11/2010 1:09 PM, Walter Bright wrote:
 dickl wrote:
 I should have been a little more clear, a static this() as a member of
 a class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>


Aug 11 2010
prev sibling parent reply dickl <dick221z yahoo.com> writes:
On 8/11/2010 1:09 PM, Walter Bright wrote:
 dickl wrote:
 I should have been a little more clear, a static this() as a member of
 a class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>

Looks like it might be windows specific. This doesn't work (only prints out "again" import std.stdio; import std.string; import std.c.windows.windows; import core.runtime; extern (Windows) int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) { try { Runtime.initialize(); return myWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow); }//end try catch (Object o) // catch any uncaught exceptions { MessageBoxA(null, toStringz(o.toString()), "Fatal Error", MB_OK | MB_ICONERROR); }finally { Runtime.terminate(); } return 0; }//end int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) int myWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { foo f = new foo; return 1; }//end int myWinMain HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) class foo { public: static this() { writeln("Hello"); } static ~this() { } this() { writefln(" again"); } }
Aug 12 2010
next sibling parent reply dickl <dick221z yahoo.com> writes:
On 8/12/2010 11:46 PM, Yao G. wrote:
 On Thu, 12 Aug 2010 22:09:40 -0500, dickl <dick221z yahoo.com> wrote:

 On 8/11/2010 1:09 PM, Walter Bright wrote:
 dickl wrote:
 I should have been a little more clear, a static this() as a member of
 a class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>

Looks like it might be windows specific. This doesn't work (only prints out "again" import std.stdio; import std.string; import std.c.windows.windows; import core.runtime; extern (Windows) int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) { try { Runtime.initialize(); return myWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow); }//end try catch (Object o) // catch any uncaught exceptions { MessageBoxA(null, toStringz(o.toString()), "Fatal Error", MB_OK | MB_ICONERROR); }finally { Runtime.terminate(); } return 0; }//end int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) int myWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { foo f = new foo; return 1; }//end int myWinMain HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) class foo { public: static this() { writeln("Hello"); } static ~this() { } this() { writefln(" again"); } }

You are mixing windows specific functions (WinMain) and console functions (writeln). This will either cause an exception or just fail to run. Try to replace calls to writeln with calls to MessageBox if you want to check if the static constructor/destructor is working correctly.

and writeln does work in this example...
Aug 12 2010
parent dickl <dick221z yahoo.com> writes:
On 8/13/2010 12:20 AM, Yao G. wrote:
 On Thu, 12 Aug 2010 23:04:54 -0500, dickl <dick221z yahoo.com> wrote:

 On 8/12/2010 11:46 PM, Yao G. wrote:
 You are mixing windows specific functions (WinMain) and console
 functions (writeln). This will either cause an exception or just fail to
 run. Try to replace calls to writeln with calls to MessageBox if you
 want to check if the static constructor/destructor is working correctly.

and writeln does work in this example...

Try using: shared static this() I had a similar problem with a Win32 wrapper that I did.

using shared works tnx
Aug 13 2010
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
dickl wrote:
 
 Looks like it might be windows specific. This doesn't work (only prints 
 out "again"

 
 extern (Windows) int WinMain(HINSTANCE hInstance,HINSTANCE 
 hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
 {

FYI, if you didn't already know, you can avoid WinMain entirely and just use a regular main function and still get a windowed app with no console. Just pass the following command line option to DMD: -L/SUBSYSTEM:windows:5 And you can replace the 5 with a 4 if you want to support Win 9x.
Aug 13 2010
parent dickl <dick221z yahoo.com> writes:
On 8/13/2010 4:28 AM, Mike Parker wrote:
 dickl wrote:
 Looks like it might be windows specific. This doesn't work (only
 prints out "again"


 extern (Windows) int WinMain(HINSTANCE hInstance,HINSTANCE
 hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
 {

FYI, if you didn't already know, you can avoid WinMain entirely and just use a regular main function and still get a windowed app with no console. Just pass the following command line option to DMD: -L/SUBSYSTEM:windows:5 And you can replace the 5 with a 4 if you want to support Win 9x.

This is just a test example to cut the code size down. It not a representation of the application.
Aug 13 2010
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Michal Minich Wrote:

 On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:
 
 Module constructor is not called when it is placed in imported module,
 and WinMain is used.

Are there some changes to runtime initialization, or it is a bug? (in that case I will submit it).

There were some changes and I must have missed updating rt_init(). Please submit a bug. What you'll likely see is shared static ctors being called but not thread-specific (ie. non-shared) static ctors called for the main thread.
Aug 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michal Minich wrote:
 On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:
 
 Michal Minich Wrote:

 On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:

 Module constructor is not called when it is placed in imported
 module, and WinMain is used.

that case I will submit it).

Please submit a bug. What you'll likely see is shared static ctors being called but not thread-specific (ie. non-shared) static ctors called for the main thread.

bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4622

Fixed: http://www.dsource.org/projects/druntime/changeset/368
Aug 16 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Michal Minich:
 the changeset only contains change to rt_term function - added call to 
 _moduleTlsDtor
 
 another bug? or miss to check-in some files?

You may copy this (plus what you thinks is missing) inside the bug report. Bye, bearophile
Aug 16 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
Module constructor is not called when it is placed in imported module, 
and WinMain is used.


module hello;

import core.runtime;
import std.c.windows.windows;
import std.stdio;
import a;

extern (Windows)
int WinMain(HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR lpCmdLine,
	int nCmdShow)
{
    int result;

    void exceptionHandler (Throwable ex) { throw ex; }
	
    Runtime.initialize(&exceptionHandler);

    result = myWinMain();

    Runtime.terminate(&exceptionHandler);

    return result;
}

int main ()
{
   writeln (i1); // <---------------- prints "1" wich is ok.
   writeln (i2); // <---------------- prints "0" wich is incorrect.
   return 1;
}


/------

module a;

int i1 = 1;
int i2;

static this () {

    i2 = 2;
}
Aug 11 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
Module constructor is not called when it is placed in imported module, 
and WinMain is used.


module hello;

import core.runtime;
import std.c.windows.windows;
import std.stdio;
import a;

extern (Windows)
int WinMain(HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR lpCmdLine,
	int nCmdShow)
{
    int result;

    void exceptionHandler (Throwable ex) { throw ex; }
	
    Runtime.initialize(&exceptionHandler);

    result = myWinMain();

    Runtime.terminate(&exceptionHandler);

    return result;
}

int main ()
{
   writeln (i1); // <---------------- prints "1" wich is ok.
   writeln (i2); // <---------------- prints "0" wich is incorrect.
   return 1;
}


/------

module a;

int i1 = 1;
int i2;

static this () {

    i2 = 2;
}
Aug 11 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:

 Module constructor is not called when it is placed in imported module,
 and WinMain is used.

Are there some changes to runtime initialization, or it is a bug? (in that case I will submit it).
Aug 11 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:

 Michal Minich Wrote:
 
 On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:
 
 Module constructor is not called when it is placed in imported
 module, and WinMain is used.

Are there some changes to runtime initialization, or it is a bug? (in that case I will submit it).

There were some changes and I must have missed updating rt_init(). Please submit a bug. What you'll likely see is shared static ctors being called but not thread-specific (ie. non-shared) static ctors called for the main thread.

bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4622
Aug 11 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Thu, 12 Aug 2010 22:09:40 -0500, dickl <dick221z yahoo.com> wrote:

 On 8/11/2010 1:09 PM, Walter Bright wrote:
 dickl wrote:
 I should have been a little more clear, a static this() as a member of
 a class.

Still works: -------------------------- H:\cbx>type test.d import std.stdio; void main() { printf("hello\n"); } class C { static this() { printf("betty\n"); } } H:\cbx>dmd test H:\cbx>test betty hello H:\cbx>

Looks like it might be windows specific. This doesn't work (only prints out "again" import std.stdio; import std.string; import std.c.windows.windows; import core.runtime; extern (Windows) int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) { try { Runtime.initialize(); return myWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow); }//end try catch (Object o) // catch any uncaught exceptions { MessageBoxA(null, toStringz(o.toString()), "Fatal Error", MB_OK | MB_ICONERROR); }finally { Runtime.terminate(); } return 0; }//end int WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) int myWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { foo f = new foo; return 1; }//end int myWinMain HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) class foo { public: static this() { writeln("Hello"); } static ~this() { } this() { writefln(" again"); } }

You are mixing windows specific functions (WinMain) and console functions (writeln). This will either cause an exception or just fail to run. Try to replace calls to writeln with calls to MessageBox if you want to check if the static constructor/destructor is working correctly. -- Yao G.
Aug 12 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Thu, 12 Aug 2010 23:04:54 -0500, dickl <dick221z yahoo.com> wrote:

 On 8/12/2010 11:46 PM, Yao G. wrote:
 You are mixing windows specific functions (WinMain) and console
 functions (writeln). This will either cause an exception or just fail to
 run. Try to replace calls to writeln with calls to MessageBox if you
 want to check if the static constructor/destructor is working correctly.

and writeln does work in this example...

Try using: shared static this() I had a similar problem with a Win32 wrapper that I did. -- Yao G.
Aug 12 2010
prev sibling next sibling parent reply Michal Minich <michal.minich gmail.com> writes:
On Mon, 16 Aug 2010 09:58:22 -0700, Walter Bright wrote:

 Michal Minich wrote:
 On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:
 
 Michal Minich Wrote:

 On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:

 Module constructor is not called when it is placed in imported
 module, and WinMain is used.

that case I will submit it).

Please submit a bug. What you'll likely see is shared static ctors being called but not thread-specific (ie. non-shared) static ctors called for the main thread.

bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4622

Fixed: http://www.dsource.org/projects/druntime/changeset/368

the changeset only contains change to rt_term function - added call to _moduleTlsDtor another bug? or miss to check-in some files?
Aug 16 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Michal Minich <michal.minich gmail.com> wrote:
 On Mon, 16 Aug 2010 09:58:22 -0700, Walter Bright wrote:
 
 Michal Minich wrote:
 On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:
 
 Michal Minich Wrote:
 
 On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:
 
 Module constructor is not called when it is placed in imported
 module, and WinMain is used.

(in that case I will submit it).

Please submit a bug. What you'll likely see is shared static ctors being called but not thread-specific (ie. non-shared) static ctors called for the main thread.

bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4622

Fixed: http://www.dsource.org/projects/druntime/changeset/368

the changeset only contains change to rt_term function - added call to _moduleTlsDtor another bug? or miss to check-in some files?

It's rev 369. Sorry.
Aug 17 2010
prev sibling parent Michal Minich <michal.minich gmail.com> writes:
On Mon, 16 Aug 2010 15:21:32 -0400, bearophile wrote:

 Michal Minich:
 the changeset only contains change to rt_term function - added call to
 _moduleTlsDtor
 
 another bug? or miss to check-in some files?

You may copy this (plus what you thinks is missing) inside the bug report. Bye, bearophile

thank you bearophile for taking care! - another check-in was made by Sean after. I think that one should do it.
Aug 16 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 11 Aug 2010 00:15:07 -0700, Walter Bright wrote:

 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.063.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.048.zip

This is a great release. Bug fixes galore! -Lars
Aug 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lars T. Kyllingstad wrote:
 This is a great release.  Bug fixes galore!

Yup. And all these fixes are due to quite a lot of people contributing.
Aug 11 2010
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i3v36f$1d81$1 digitalmars.com...
 Lars T. Kyllingstad wrote:
 This is a great release.  Bug fixes galore!

Yup. And all these fixes are due to quite a lot of people contributing.

...and a 2-month development cycle instead of the usual approx one month. **Not that I'm complaining, or being impatient, or trying to belittle the contributions!!** Just an observation!!!
Aug 11 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Thanks everybody for the hard work, good release!
Aug 12 2010
prev sibling next sibling parent reply Jordi <jordi rovira.cat> writes:
On 08/11/2010 04:15 PM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

Hi, Congratulations for this release! This time it really made a difference when i switched from 2.0.46. The framerate of my app used to degenerate with time very quickly and now it remains fast and stable! Maybe some of the many fixes helped the garbage collector? Congratulations again. j.
Aug 13 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jordi (jordi rovira.cat)'s article
 On 08/11/2010 04:15 PM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

Congratulations for this release! This time it really made a difference when i switched from 2.0.46. The framerate of my app used to degenerate with time very quickly and now it remains fast and stable! Maybe some of the many fixes helped the garbage collector? Congratulations again. j.

Probably the GC.minimize() patch. Previously the GC would **never** give memory back to the OS. In addition to the obvious reason, this is bad because the GC is currently not well optimized and slows down a lot when the heap gets large, even if most of it doesn't contain pointers and isn't scanned.
Aug 14 2010
parent reply Jordi <jordi rovira.cat> writes:
On 08/15/2010 01:50 PM, dsimcha wrote:
 == Quote from Jordi (jordi rovira.cat)'s article
 On 08/11/2010 04:15 PM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

Congratulations for this release! This time it really made a difference when i switched from 2.0.46. The framerate of my app used to degenerate with time very quickly and now it remains fast and stable! Maybe some of the many fixes helped the garbage collector? Congratulations again. j.

Probably the GC.minimize() patch. Previously the GC would **never** give memory back to the OS. In addition to the obvious reason, this is bad because the GC is currently not well optimized and slows down a lot when the heap gets large, even if most of it doesn't contain pointers and isn't scanned.

Great. I always thought i was missing some important point about garbage collection, and i was doing everything wrong. I am used to manage my own memory in C++... Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 some behaviour has changed in my program. I cannot really make a small reproduction case, because it involves dragging objects around the 3d scene: since 2.0.47 they follow weird curved paths instead of moving correctly on the camera plane. The code that calculate that (which is not new) just uses matrix and vector operations to project and unproject positions, but i cannot really find where do the numbers start to go wrong. j.
Aug 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Jordi" <jordi rovira.cat> wrote in message 
news:i48n8t$1jv$1 digitalmars.com...
 On 08/15/2010 01:50 PM, dsimcha wrote:
 == Quote from Jordi (jordi rovira.cat)'s article
 On 08/11/2010 04:15 PM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be 
 for
 FreeBSD 8!

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

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

Congratulations for this release! This time it really made a difference when i switched from 2.0.46. The framerate of my app used to degenerate with time very quickly and now it remains fast and stable! Maybe some of the many fixes helped the garbage collector? Congratulations again. j.

Probably the GC.minimize() patch. Previously the GC would **never** give memory back to the OS. In addition to the obvious reason, this is bad because the GC is currently not well optimized and slows down a lot when the heap gets large, even if most of it doesn't contain pointers and isn't scanned.

Great. I always thought i was missing some important point about garbage collection, and i was doing everything wrong. I am used to manage my own memory in C++... Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 some behaviour has changed in my program. I cannot really make a small reproduction case, because it involves dragging objects around the 3d scene: since 2.0.47 they follow weird curved paths instead of moving correctly on the camera plane. The code that calculate that (which is not new) just uses matrix and vector operations to project and unproject positions, but i cannot really find where do the numbers start to go wrong.

This may be a pain to do, but you could narrow it down from the other direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 and see which actual commit created the problem.
Aug 15 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 This may be a pain to do, but you could narrow it down from the other 
 direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 
 and see which actual commit created the problem.

Try mixing/matching the compiler & Phobos to see which one of those caused the issue.
Aug 15 2010
parent reply Don <nospam nospam.com> writes:
Brad Roberts wrote:
 On 8/15/2010 12:54 PM, Walter Bright wrote:
 Nick Sabalausky wrote:
 This may be a pain to do, but you could narrow it down from the other
 direction: recompile DMD from various trunk revisions between 2.046 and 2.047
 and see which actual commit created the problem.

issue.

While I agree that it's worth trying a bisection -- it's generally really quick and easy to do (the compiler and libraries build rather fast -- about a minute for me). It can be a very useful technique for finding where bugs were introduced. That said, it's likely to be rather difficult for this release due to the number of fixes in the compiler that the library requires and for the periods during which the two didn't work together. Do try it.. worst case is you've wasted a little bit of time. Best case you've found the cause of the bug. Later, Brad

The latest compiler should work with the old Phobos, except that it will complain about the a&b==c bugs. That's simple to do, it just involves copying the 2.048 compiler onto the 2.047 release. Knowing if it is the compiler or Phobos/druntime would be an enormous help.
Aug 16 2010
parent reply Jordi <jordi rovira.cat> writes:
On 08/16/2010 04:11 PM, Don wrote:
 Brad Roberts wrote:
 On 8/15/2010 12:54 PM, Walter Bright wrote:
 Nick Sabalausky wrote:
 This may be a pain to do, but you could narrow it down from the other
 direction: recompile DMD from various trunk revisions between 2.046
 and 2.047
 and see which actual commit created the problem.

caused the issue.

While I agree that it's worth trying a bisection -- it's generally really quick and easy to do (the compiler and libraries build rather fast -- about a minute for me). It can be a very useful technique for finding where bugs were introduced. That said, it's likely to be rather difficult for this release due to the number of fixes in the compiler that the library requires and for the periods during which the two didn't work together. Do try it.. worst case is you've wasted a little bit of time. Best case you've found the cause of the bug. Later, Brad

The latest compiler should work with the old Phobos, except that it will complain about the a&b==c bugs. That's simple to do, it just involves copying the 2.048 compiler onto the 2.047 release. Knowing if it is the compiler or Phobos/druntime would be an enormous help.

Found it. It took me 7 iterations of binary search across the svn repositories for dmd, druntime and phobos. The commit causing the issue is 505 in dmd. It is related to structs returning *this, which indeed i do in my maths structs. Now, i don't know if the bug is in dmd or in my code, but i suspect that something is being treated as a reference when it shouldn't. Should i add an issue even if i am not sure? j.
Aug 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jordi wrote:
 Found it. It took me 7 iterations of binary search across the svn 
 repositories for dmd, druntime and phobos. The commit causing the issue 
 is 505 in dmd. It is related to structs returning *this, which indeed i 
 do in my maths structs.
 
 Now, i don't know if the bug is in dmd or in my code, but i suspect that 
 something is being treated as a reference when it shouldn't. Should i 
 add an issue even if i am not sure?

Try to reduce it to the smallest possible reproducible test case, and then post it to bugzilla.
Aug 16 2010
parent reply Jordi <jordi rovira.cat> writes:
On 08/17/2010 02:35 AM, Walter Bright wrote:
 Jordi wrote:
 Found it. It took me 7 iterations of binary search across the svn
 repositories for dmd, druntime and phobos. The commit causing the
 issue is 505 in dmd. It is related to structs returning *this, which
 indeed i do in my maths structs.

 Now, i don't know if the bug is in dmd or in my code, but i suspect
 that something is being treated as a reference when it shouldn't.
 Should i add an issue even if i am not sure?

Try to reduce it to the smallest possible reproducible test case, and then post it to bugzilla.

Instead of "peeling off" my project, which is hundreds of files and a lot of code, i tried to reproduce it in a small test case emulating the matrix operations i was suspecting of. I didn't succeed though. I will try again when i come back from some holidays. I don't explicitly use "inline" anywhere though. I guess the compiler does some inlining anyway. Maybe if i can disable it, i can see if anything changes. I do "return this" however in some struct methods, for example: Transform opMulAssign( const Transform t ) { m_origin += m_basis * t.m_origin; m_basis *= t.m_basis; m_type |= t.m_type; return this; } and others. But even if "this" is a reference like Lars pointed out, the method should return a copy of the struct by value, right? Regards, j.
Aug 19 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Jordi wrote:
 But even if "this" is a reference like Lars pointed out, the 
 method should return a copy of the struct by value, right?

Yes.
Aug 19 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 16 Aug 2010 23:33:26 +0900, Jordi wrote:

 On 08/16/2010 04:11 PM, Don wrote:
 Brad Roberts wrote:
 On 8/15/2010 12:54 PM, Walter Bright wrote:
 Nick Sabalausky wrote:
 This may be a pain to do, but you could narrow it down from the
 other direction: recompile DMD from various trunk revisions between
 2.046 and 2.047
 and see which actual commit created the problem.

caused the issue.

While I agree that it's worth trying a bisection -- it's generally really quick and easy to do (the compiler and libraries build rather fast -- about a minute for me). It can be a very useful technique for finding where bugs were introduced. That said, it's likely to be rather difficult for this release due to the number of fixes in the compiler that the library requires and for the periods during which the two didn't work together. Do try it.. worst case is you've wasted a little bit of time. Best case you've found the cause of the bug. Later, Brad

The latest compiler should work with the old Phobos, except that it will complain about the a&b==c bugs. That's simple to do, it just involves copying the 2.048 compiler onto the 2.047 release. Knowing if it is the compiler or Phobos/druntime would be an enormous help.

Found it. It took me 7 iterations of binary search across the svn repositories for dmd, druntime and phobos. The commit causing the issue is 505 in dmd. It is related to structs returning *this, which indeed i do in my maths structs. Now, i don't know if the bug is in dmd or in my code, but i suspect that something is being treated as a reference when it shouldn't. Should i add an issue even if i am not sure?

Since DMD 2.021, 'this' for structs _is_ a reference. -Lars
Aug 17 2010
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 8/15/2010 12:54 PM, Walter Bright wrote:
 Nick Sabalausky wrote:
 This may be a pain to do, but you could narrow it down from the other
 direction: recompile DMD from various trunk revisions between 2.046 and 2.047
 and see which actual commit created the problem.

Try mixing/matching the compiler & Phobos to see which one of those caused the issue.

While I agree that it's worth trying a bisection -- it's generally really quick and easy to do (the compiler and libraries build rather fast -- about a minute for me). It can be a very useful technique for finding where bugs were introduced. That said, it's likely to be rather difficult for this release due to the number of fixes in the compiler that the library requires and for the periods during which the two didn't work together. Do try it.. worst case is you've wasted a little bit of time. Best case you've found the cause of the bug. Later, Brad
Aug 15 2010
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 08/11/2010 02:15 AM, Walter Bright wrote:
 This is probably the last FreeBSD 7 release for D1. The next will be for
 FreeBSD 8!

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

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

Just tried the rpm. It won't install on 64 bit fedora because there is a 32 bit gcc constraint in the rpm. In my experience, dmd has always worked fine with 64 bit gcc.
Aug 18 2010