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


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


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 reply bearophile <bearophileHUGS lycos.com> writes:
All the bugs reported by me present in the list of the bug fixed in this
release look indeed fixed, and I have closed the ones that were open still
(3961).


With 2.048beta I have found two bugs (4603 and 4604) that are present in 2.048
too (Walter has asked me to test the betas too, and I am now doing it).


I want to draw some attention to two related Phobos2 problems, I have updated a
bug report and I have added one new, 3813 and 4605. Hopefully bug
http://d.puremagic.com/issues/show_bug.cgi?id=3813 explains the situation well.
I'd also like people to vote for this, comment about this, become vocal about
this silly situation. I don't want to manage my own Phobos2 version just to
keep a patch for this couple of problems. Thank you very much.


Regarding bug 4077 ("Bugs caused by bitwise operator precedence") I want to
thank Stewart Gordon for finding a possible solution, Don for writing a first
implementation and coordinating it, and Walter for all the remaining things. I
hope such fortunate combination of events will happen again regarding some
other minor but significant issues in the D2 language :-)

Bye,
bearophile
Aug 11 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
 I have updated a bug report and I have added one new, 3813 and 4605


If someone here thinks that AA printing is 'good enough', such person has to
try to print a int[int[int]], like:

import std.stdio;
void main() {
    int[int[int]] aa;
    aa[[5:6, 7:8]] = 2;
    writeln(aa);
}


The output is:
5:6 7:8:2

Bye,
bearophile
Aug 11 2010
parent Mafi <mafi example.org> writes:
Am 12.08.2010 03:52, schrieb bearophile:

 I have updated a bug report and I have added one new, 3813 and 4605


 If someone here thinks that AA printing is 'good enough', such person has to
try to print a int[int[int]], like:

 import std.stdio;
 void main() {
      int[int[int]] aa;
      aa[[5:6, 7:8]] = 2;
      writeln(aa);
 }


 The output is:
 5:6 7:8:2

 Bye,
 bearophile


Theoretically this output is perfectly fine. I just needs some brackets: 
[[5:6, 7:8]:2]. I think dynamic arrays are allready printed like that.
Aug 12 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
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 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 reply 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
parent reply 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
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 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 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
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.


 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


Fixed:

http://www.dsource.org/projects/druntime/changeset/368
Aug 16 2010
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.


 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


 
 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
next sibling parent reply 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
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 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.


 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


 
 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 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>


hmmm doesn't for me, but works just fine in the previous rev.
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>


 hmmm doesn't for me, but works just fine in the previous rev.
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 "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
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.


The point is the static if isn't getting called at all...
and writeln does work in this example...
Aug 12 2010
parent reply "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.


 The point is the static if isn't getting called at all...
 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
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.


 The point is the static if isn't getting called at all...
 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 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
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


 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.


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


 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.


 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


 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.


 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 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
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.


 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


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.


 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


 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
next sibling 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.


 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


 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 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