www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.001 release

reply Walter Bright <newshound digitalmars.com> writes:
New pointer-aware GC. Should run significantly faster for some programs.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.1.001.zip
Jan 23 2007
next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Walter Bright wrote:

 New pointer-aware GC. Should run significantly faster for some programs.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.001.zip



Yay!!

Thanks Walter.

Are both features active when compiling with -v1?
Jan 23 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 New pointer-aware GC. Should run significantly faster for some programs.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.001.zip



 Yay!!
 
 Thanks Walter.
 
 Are both features active when compiling with -v1?



Yes, because it's a runtime issue. You can revert to the old behavior by 
calling std.gc.setV1_0(), which is handy for making timing comparisons.
Jan 23 2007
parent "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:


 Julio César Carrascal Urquijo wrote:

 Walter Bright wrote:

 New pointer-aware GC. Should run significantly faster for some
 programs.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.001.zip



 Yay!!
 
 Thanks Walter.
 
 Are both features active when compiling with -v1?



 Yes, because it's a runtime issue. You can revert to the old behavior
 by calling std.gc.setV1_0(), which is handy for making timing
 comparisons.



Yet it also means that code working in 1.0 might be horribly broken in
1.001...

--
Jan 23 2007
prev sibling next sibling parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:


 New pointer-aware GC. Should run significantly faster for some
 programs.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.001.zip



Nice to see a new release. Was getting used to weekly updates ;)

About the GC updates. I think it would be nice with some more
documentation on how it works now.
Your post about "Transitioning to a type aware Garbage Collector" has
some information that is critical to using it efficiently.

Until now I have been using some void[]'s for pixel data. As I
understand it I should change these to ubyte[] now to avoid the old
gc's conservative behaviour. (I realise I should probably have used
malloc or something before).

I see a few problems here, though I might be wrong. (not related to
pixels...)

Fx: If I used std.file.read to read a file I get a GC allocated void[].
It's not _that_ unlikely that some of the data could look like a
pointer. But the GC will handle the block as if it could all be
pointers as it is void[]. Is this correct?

In that case I would say these cases should be changed to ubyte[] as
the contents of a file does not hold any valid pointers.

I'm sure this applies to other areas of Phobos.

Hope I'm not talking completely out of my arse here! GC's is not really
something I know a whole lot about...
Jan 23 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 Fx: If I used std.file.read to read a file I get a GC allocated void[].
 It's not _that_ unlikely that some of the data could look like a
 pointer. But the GC will handle the block as if it could all be
 pointers as it is void[]. Is this correct?



Take a look at the source to std.file.read() <g>.
Jan 23 2007
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:


 Tomas Lindquist Olsen wrote:

 Fx: If I used std.file.read to read a file I get a GC allocated
 void[].  It's not that unlikely that some of the data could look
 like a pointer. But the GC will handle the block as if it could all
 be pointers as it is void[]. Is this correct?



 Take a look at the source to std.file.read() <g>.



LOL

*hides in shame*
Jan 23 2007
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Tomas Lindquist Olsen wrote:


 Walter Bright wrote:
 

 Tomas Lindquist Olsen wrote:

 Fx: If I used std.file.read to read a file I get a GC allocated
 void[].  It's not that unlikely that some of the data could look
 like a pointer. But the GC will handle the block as if it could
 all be pointers as it is void[]. Is this correct?



 Take a look at the source to std.file.read() <g>.



 LOL
 
 *hides in shame*



buuuuuut ;)

std.zlib is not doing this correctly.

which also makes me think about how to handle this case properly:

void[] dst = new void[1024];
dst.length = dst.length + 1024;
dst.length = dst.length + 1024;
dst.length = dst.length + 1024;
dst.length = dst.length + 1024;
dst.length = dst.length + 1024;

assuming one of these calls have to relocate how would I be sure that I
inform the GC properly?
A call to the GC in the end would obviously do, but what if you want to
make sure the GC doesn't scan the array while it's still being resized?

While I'm at it I have been wondering why we can't have:

void[1024] sa;

when

void[] da = new void[1024];

is perfectly fine.
Jan 23 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 std.zlib is not doing this correctly.



I should look at that.


 which also makes me think about how to handle this case properly:
 
 void[] dst = new void[1024];
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 
 assuming one of these calls have to relocate how would I be sure that I
 inform the GC properly?



Inform it with the last one.


 A call to the GC in the end would obviously do, but what if you want to
 make sure the GC doesn't scan the array while it's still being resized?



Depends on what data you put in it.


 While I'm at it I have been wondering why we can't have:
 
 void[1024] sa;
 
 when
 
 void[] da = new void[1024];
 
 is perfectly fine.



You're probably right.
Jan 24 2007
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Walter Bright wrote:


 Tomas Lindquist Olsen wrote:
 

 which also makes me think about how to handle this case properly:
 
 void[] dst = new void[1024];
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 dst.length = dst.length + 1024;
 
 assuming one of these calls have to relocate how would I be sure
 that I inform the GC properly?



 Inform it with the last one.
 

 A call to the GC in the end would obviously do, but what if you
 want to make sure the GC doesn't scan the array while it's still
 being resized?



 Depends on what data you put in it.
 



Let me clarify what I mean. Consider this code:

import std.gc;

void test()
{
	void[] buf = new void[1024];
	std.gc.hasNoPointers(ret.ptr);
	// invoking gc will not scan buf. ok
	buf.length = buf.length*2;
	// could invoking gc now potentially scan buf?
}

I'm thinking how to make sure a void[] is _never_ scanned.
A somewhat realistic case for this would be (again) the std.file.read
function.
If we append some data to this buffer will the GC be smart enough to
know it still holds no pointers? That is even with the reallocation and
potential relocation.
Just putting the hasNoPointers in the end when no more resizing will
happen is not good enough as the GC could easily be invoked in between
and 'buf' would be scanned.

I guess you could be unlucky and the GC could be triggered (by another
thread) after 'new void[1024]' but before
'std.gc.hasNoPointers(buf.ptr)', in which case there is not much to do.
Is a ubyte[] safe from this problem? (if it even exists)


 While I'm at it I have been wondering why we can't have:
 
 void[1024] sa;
 
 when
 
 void[] da = new void[1024];
 
 is perfectly fine.



 You're probably right.



Given the new meaning of void arrays, I definitely think it should be
reconsidered.
Jan 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 Let me clarify what I mean. Consider this code:
 
 import std.gc;
 
 void test()
 {
 	void[] buf = new void[1024];
 	std.gc.hasNoPointers(ret.ptr);
 	// invoking gc will not scan buf. ok
 	buf.length = buf.length*2;
 	// could invoking gc now potentially scan buf?
 }
 
 I'm thinking how to make sure a void[] is _never_ scanned.
 A somewhat realistic case for this would be (again) the std.file.read
 function.
 If we append some data to this buffer will the GC be smart enough to
 know it still holds no pointers? That is even with the reallocation and
 potential relocation.



It'll reallocate based on the type of buf, which is void[], so you'll 
need to invoke gc.hasNoPointers again.


 Is a ubyte[] safe from this problem? (if it even exists)



ubyte[]s won't get scanned for pointers.
Jan 24 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 Let me clarify what I mean. Consider this code:

 import std.gc;

 void test()
 {
     void[] buf = new void[1024];
     std.gc.hasNoPointers(ret.ptr);
     // invoking gc will not scan buf. ok
     buf.length = buf.length*2;
     // could invoking gc now potentially scan buf?
 }

 I'm thinking how to make sure a void[] is _never_ scanned.
 A somewhat realistic case for this would be (again) the std.file.read
 function.
 If we append some data to this buffer will the GC be smart enough to
 know it still holds no pointers? That is even with the reallocation and
 potential relocation.



 It'll reallocate based on the type of buf, which is void[], so you'll 
 need to invoke gc.hasNoPointers again.



Shouldn't it copy pointer-ness from the original to the new array? That 
seems like the logical thing to do.
The same applies to concatenating arrays, though perhaps that should 
follow the rule "the new array contains pointers if either original 
array contained pointers".
Jan 24 2007
parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
Frits van Bommel wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 Let me clarify what I mean. Consider this code:
 
 import std.gc;
 
 void test()
 {
    void[] buf = new void[1024];
    std.gc.hasNoPointers(ret.ptr);
    // invoking gc will not scan buf. ok
    buf.length = buf.length*2;
    // could invoking gc now potentially scan buf?
 }
 
 I'm thinking how to make sure a void[] is never scanned.
 A somewhat realistic case for this would be (again) the
 std.file.read function.
 If we append some data to this buffer will the GC be smart enough
 to know it still holds no pointers? That is even with the
 reallocation and potential relocation.



 It'll reallocate based on the type of buf, which is void[], so
 you'll  need to invoke gc.hasNoPointers again.



 Shouldn't it copy pointer-ness from the original to the new array?
 That seems like the logical thing to do.  The same applies to
 concatenating arrays, though perhaps that should follow the rule "the
 new array contains pointers if either original array contained
 pointers".



This is what I'm thinking as well. Just dropping the information is not
acceptable IMHO. It means that you have to call hasNoPointers every
time you resize a void[] to be sure the GC is handling it like you
indended.
Jan 25 2007
parent Sean Kelly <sean f4.ca> writes:
Tomas Lindquist Olsen wrote:

 Frits van Bommel wrote:
 

 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 Let me clarify what I mean. Consider this code:

 import std.gc;

 void test()
 {
    void[] buf = new void[1024];
    std.gc.hasNoPointers(ret.ptr);
    // invoking gc will not scan buf. ok
    buf.length = buf.length*2;
    // could invoking gc now potentially scan buf?
 }

 I'm thinking how to make sure a void[] is never scanned.
 A somewhat realistic case for this would be (again) the
 std.file.read function.
 If we append some data to this buffer will the GC be smart enough
 to know it still holds no pointers? That is even with the
 reallocation and potential relocation.



 you'll  need to invoke gc.hasNoPointers again.



 That seems like the logical thing to do.  The same applies to
 concatenating arrays, though perhaps that should follow the rule "the
 new array contains pointers if either original array contained
 pointers".



 This is what I'm thinking as well. Just dropping the information is not
 acceptable IMHO. It means that you have to call hasNoPointers every
 time you resize a void[] to be sure the GC is handling it like you
 indended.



I've been mulling this over the past few weeks, and even went so far as 
to begin a patch to do this, but I'm undecided.  First, it could work 
one of two ways: either it could be made to only affect resizing of the 
original array itself, or it could be made to affect resizing of that 
array and any slices of that array.  The latter behavior seems to make 
the most sense from a consistency perspective, but I worry that making 
such an attribute "viral" could result in unpredictable behavior in 
large applications where slices are passed into contexts which may be 
unaware of the slice's origin.  For the moment, I've decided to wait and 
see how much of an issue this turns out to be, and I'll probably finish 
the GC mods to support it efficiently just in case.


Sean
Jan 25 2007
prev sibling next sibling parent John <kmk200us yahoo.com> writes:
Walter Bright Wrote:


 New pointer-aware GC. Should run significantly faster for some programs.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.001.zip



Very nice. Thanks Walter.
Jan 23 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ep6asn$aer$1 digitaldaemon.com...

 New pointer-aware GC. Should run significantly faster for some programs.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.001.zip



Yay, update time!  I've missed these.
Jan 23 2007
prev sibling next sibling parent reply "JohnC" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ep6asn$aer$1 digitaldaemon.com...

 New pointer-aware GC. Should run significantly faster for some programs.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.001.zip



It appears that overriding TypeInfo implementations is no longer allowed. 
Was this intentional?
Jan 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer allowed. 
 Was this intentional?



TypeInfo is meant to be generated by the compiler.
Jan 24 2007
parent reply "JohnC" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ep7b0h$155a$2 digitaldaemon.com...

 JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer allowed. 
 Was this intentional?



 TypeInfo is meant to be generated by the compiler.



I understand that. But it was nice to be able to alter the default behaviour 
of TypeInfo_Aa, for example, to be locale-aware. That way I could easily get 
things like the .sort property for string arrays working correctly for 
languages with diacritics etc.
Jan 24 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7b0h$155a$2 digitaldaemon.com...

 JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer allowed. 
 Was this intentional?






 I understand that. But it was nice to be able to alter the default behaviour 
 of TypeInfo_Aa, for example, to be locale-aware. That way I could easily get 
 things like the .sort property for string arrays working correctly for 
 languages with diacritics etc. 



How did you alter it?
Jan 24 2007
parent reply "JohnC" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ep7fhf$1d3g$1 digitaldaemon.com...

 JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7b0h$155a$2 digitaldaemon.com...

 JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer 
 allowed. Was this intentional?






 I understand that. But it was nice to be able to alter the default 
 behaviour of TypeInfo_Aa, for example, to be locale-aware. That way I 
 could easily get things like the .sort property for string arrays working 
 correctly for languages with diacritics etc.



 How did you alter it?



Well, I simply redefined TypeInfo_Aa, deriving from TypeInfo, in a new 
module and overrode the appropriate methods. But now I get "previous 
definition different" optlink errors.
Jan 24 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7fhf$1d3g$1 digitaldaemon.com...

 JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7b0h$155a$2 digitaldaemon.com...

 JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer 
 allowed. Was this intentional?






 behaviour of TypeInfo_Aa, for example, to be locale-aware. That way I 
 could easily get things like the .sort property for string arrays working 
 correctly for languages with diacritics etc.






 Well, I simply redefined TypeInfo_Aa, deriving from TypeInfo, in a new 
 module and overrode the appropriate methods. But now I get "previous 
 definition different" optlink errors. 



Perhaps he meant "Could you give me the patch so I can include it in the 
next release"?
Jan 24 2007
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7fhf$1d3g$1 digitaldaemon.com...

 JohnC wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ep7b0h$155a$2 digitaldaemon.com...

 JohnC wrote:

 It appears that overriding TypeInfo implementations is no longer 
 allowed. Was this intentional?






 behaviour of TypeInfo_Aa, for example, to be locale-aware. That way I 
 could easily get things like the .sort property for string arrays working 
 correctly for languages with diacritics etc.






 Well, I simply redefined TypeInfo_Aa, deriving from TypeInfo, in a new 
 module and overrode the appropriate methods. But now I get "previous 
 definition different" optlink errors. 



Look for the defining module for TypeInfo_Aa in std\typeinfo\*
Jan 24 2007
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
The following code stopped working in 1.001. It works fine in 1.00:

void main()
{
	auto rs = std.string.split("a\tb\nc\td\ne\tf","\n");
	assert(rs.length==3);

	foreach(r;rs) {
	    auto f = std.string.split(r,"\t");
	    assert(f.length==2);
	}
}


std.string did not change, so I suspect there's something in the GC :(

L.
Jan 24 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 24 Jan 2007 12:31:37 +0200, Lionello Lunesu wrote:


 The following code stopped working in 1.001. It works fine in 1.00:
 
 void main()
 {
 	auto rs = std.string.split("a\tb\nc\td\ne\tf","\n");
 	assert(rs.length==3);
 
 	foreach(r;rs) {
 	    auto f = std.string.split(r,"\t");
 	    assert(f.length==2);
 	}
 }
 
 
 std.string did not change, so I suspect there's something in the GC :(



Works fine in Windows XP SP2.
-- 
Derek Parnell
Jan 24 2007
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Derek Parnell wrote:

 On Wed, 24 Jan 2007 12:31:37 +0200, Lionello Lunesu wrote:
 

 The following code stopped working in 1.001. It works fine in 1.00:

 void main()
 {
 	auto rs = std.string.split("a\tb\nc\td\ne\tf","\n");
 	assert(rs.length==3);

 	foreach(r;rs) {
 	    auto f = std.string.split(r,"\t");
 	    assert(f.length==2);
 	}
 }


 std.string did not change, so I suspect there's something in the GC :(



 Works fine in Windows XP SP2.



Doh! I had put it in a separate unittest and it tripped (the second 
assertion, by the way), but indeed when compiled alone it doesn't trip.

I guess I'll have to include more stuff to see what's going on.

L.
Jan 24 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Something's definitely broken:

auto f = std.string.split(r,"\t");
00405DC5 FF 75 C4         push        dword ptr [ebp-3Ch]
00405DC8 FF 75 C0         push        dword ptr [r]
00405DCB FF 35 44 ED 43 00 push        dword ptr 
[D24TypeInfo_AT5table6Record6__initZ+34h (43ED44h)]
00405DD1 FF 35 40 ED 43 00 push        dword ptr 
[D24TypeInfo_AT5table6Record6__initZ+30h (43ED40h)]
00405DD7 E8 20 67 00 00   call         (40C4FCh)

The second pair of pushes do not refer to that string constant!

The memory at 0x0043ED40 contains "s.taskdb", an arbitrary piece of a 
longer string:

.taskdb.TaskInfo.taskdb.TaskStatus.taskdb.TaskUpdate.taskdb.TaskDB.

("taskdb" is the module name. The other four are resp. struct, enum, 
struct, interface.)

To ensure that that memory did not get overwritten, I've inspected the 
memory at program startup, _main (C's main!) so before any static 
constructors.

L.
Jan 24 2007
prev sibling next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright wrote:

 New pointer-aware GC. Should run significantly faster for some programs.



Thank you! I'm sure this will be a tremendous improvement.

Unfortunately, the new GC results in segfaults for me. I was lucky to 
track it down and generate a small test case:

class C {
     private char[][char[]] data;
     void add(char[] a, char[] b) { data[a] = b; }
}

void main() {
     for (int i = 0; i < 1000; i++) {
         auto c = new C;
         for (int j = 0; j < 1000; j++) {
             c.add("test".dup,"test".dup);
         }
     }
}

It seems the ClassInfo.flags are incorrectly set to 2 when only private 
data members contain pointers.

/Oskar
Jan 24 2007
next sibling parent reply Georg Wrede <georg nospam.org> writes:
Oskar Linde wrote:

 Walter Bright wrote:
 

 New pointer-aware GC.



 Unfortunately, the new GC results in segfaults for me.



If one of the motives for a 1.0 release was to remove obstacles for 
using D in for-profit programming, the above quote blows it away.


What the Real User (as opposed to us, groupies, DIYs or academics) 
needs, is a surefire way to recognize which release to use for his 
paying customers!

This could be as simple as dividing the Change Log page into Stable and 
Unstable releases. And/or deciding on a numbering scheme. Or something.
Jan 24 2007
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 24 Jan 2007 07:01:55 -0500, Georg Wrede <georg nospam.org> wrote:


 Oskar Linde wrote:

 Walter Bright wrote:


 New pointer-aware GC.






 If one of the motives for a 1.0 release was to remove obstacles for  
 using D in for-profit programming, the above quote blows it away.


 What the Real User (as opposed to us, groupies, DIYs or academics)  
 needs, is a surefire way to recognize which release to use for his  
 paying customers!

 This could be as simple as dividing the Change Log page into Stable and  
 Unstable releases. And/or deciding on a numbering scheme. Or something.



Agreed! Perhaps the "D 1.0" should be a fork that only includes fixes.

Also, D and DMD seem to be used interchangeably; there should be a  
distinction. Not all D implementations have everything DMD has. e.g.  
"What's New for D 1.0" (changelog)... well that looks like a list for  
what's new in DMD, not D the language. Not all compilers have these issues  
and features and follow all the same formats (this type of linker, that  
particular implementation of a function, OMF object files, etc).
Jan 24 2007
parent reply renoX <renosky free.fr> writes:
Chris Miller Wrote:

 On Wed, 24 Jan 2007 07:01:55 -0500, Georg Wrede <georg nospam.org> wrote:
 

 Oskar Linde wrote:

 Walter Bright wrote:


 New pointer-aware GC.






 If one of the motives for a 1.0 release was to remove obstacles for  
 using D in for-profit programming, the above quote blows it away.

 What the Real User (as opposed to us, groupies, DIYs or academics)  
 needs, is a surefire way to recognize which release to use for his  
 paying customers!

 This could be as simple as dividing the Change Log page into Stable and  
 Unstable releases. And/or deciding on a numbering scheme. Or something.



 Agreed! Perhaps the "D 1.0" should be a fork that only includes fixes.



But the modification of the GC is a fix: after all in the old GC, there are
some programs which can slow down a lot the GC which I consider to be a design
bug/limitation.

IMHO the default GC should be a good 'all around' GC, not necessarily the
highest performance but it should not have easy to trigger pathological cases
or too long pause duration which would make it unsuitable for client
application (and this will be quite hard to do for multicore PC).

Of course fixing a GC is a high-risk operation, but cautious users can wait a
few weeks before using a new version of the compiler, checking if there is a
big regression before updating.


 Also, D and DMD seem to be used interchangeably; there should be a  
 distinction. Not all D implementations have everything DMD has. e.g.  
 "What's New for D 1.0" (changelog)... well that looks like a list for  
 what's new in DMD, not D the language. Not all compilers have these issues  
 and features and follow all the same formats (this type of linker, that  
 particular implementation of a function, OMF object files, etc).



Well DMD is the 'reference implementation' of D, so that's not too surprising
that both are used interchangeably..

renoX
Jan 24 2007
parent "Chris Miller" <chris dprogramming.com> writes:
On Wed, 24 Jan 2007 11:30:33 -0500, renoX <renosky free.fr> wrote:


 Chris Miller Wrote:

 On Wed, 24 Jan 2007 07:01:55 -0500, Georg Wrede <georg nospam.org>  
 wrote:


 Oskar Linde wrote:

 Walter Bright wrote:


 New pointer-aware GC.






 If one of the motives for a 1.0 release was to remove obstacles for
 using D in for-profit programming, the above quote blows it away.

 What the Real User (as opposed to us, groupies, DIYs or academics)
 needs, is a surefire way to recognize which release to use for his
 paying customers!

 This could be as simple as dividing the Change Log page into Stable  




 Unstable releases. And/or deciding on a numbering scheme. Or  




 Agreed! Perhaps the "D 1.0" should be a fork that only includes fixes.



 But the modification of the GC is a fix: after all in the old GC, there  
 are some programs which can slow down a lot the GC which I consider to  
 be a design bug/limitation.

 IMHO the default GC should be a good 'all around' GC, not necessarily  
 the highest performance but it should not have easy to trigger  
 pathological cases or too long pause duration which would make it  
 unsuitable for client application (and this will be quite hard to do for  
 multicore PC).

 Of course fixing a GC is a high-risk operation, but cautious users can  
 wait a few weeks before using a new version of the compiler, checking if  
 there is a big regression before updating.



Yep, too risky. It's not a fix if it causes more problems. It was untested.


 Also, D and DMD seem to be used interchangeably; there should be a
 distinction. Not all D implementations have everything DMD has. e.g.
 "What's New for D 1.0" (changelog)... well that looks like a list for
 what's new in DMD, not D the language. Not all compilers have these  
 issues
 and features and follow all the same formats (this type of linker, that
 particular implementation of a function, OMF object files, etc).



 Well DMD is the 'reference implementation' of D, so that's not too  
 surprising that both are used interchangeably..



I know, and that doesn't invalidate what I said; they're not the same  
thing. It's not JUST a reference; if it is, D sucks, GDC is not a valid D  
implementation, and there's really no way to have another implementation.
Jan 24 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:

 Oskar Linde wrote:

 Walter Bright wrote:


 New pointer-aware GC.



 Unfortunately, the new GC results in segfaults for me.



 If one of the motives for a 1.0 release was to remove obstacles for 
 using D in for-profit programming, the above quote blows it away.
 
 
 What the Real User (as opposed to us, groupies, DIYs or academics) 
 needs, is a surefire way to recognize which release to use for his 
 paying customers!
 
 This could be as simple as dividing the Change Log page into Stable and 
 Unstable releases. And/or deciding on a numbering scheme. Or something.



I wonder if it actually should be decided by Walter at all? You never 
know for sure if a release is truly stable until it's been exercised a 
bit. DStress seems like a good start; if there are any regressions, it's 
clearly not a stable release. And the more tests get added to it, the 
more confidence we can have in it.
Jan 24 2007
parent "Yauheni Akhotnikau" <eao197 intervale.ru> writes:
On Thu, 25 Jan 2007 10:23:27 +0300, Don Clugston <dac nospam.com.au> wrote:


 I wonder if it actually should be decided by Walter at all? You never  
 know for sure if a release is truly stable until it's been exercised a  
 bit.



I agree.

May be it is a good idea to use scheme with 'release candidates' for new  
stable versions? For example, when the next stable version (1.003) is  
ready to go out it will be published as 1.003-rc1. Then, if in a week or  
two nobody informs about any critical bug (like in the history with 1.001)  
1.003-rc1 republished as 1.003 (final stable). If some bug found then it  
fixed and new release candidate, 1.003-rc2 published and so on.

-- 
Regards,
Yauheni Akhotnikau
Jan 26 2007
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Oskar Linde wrote:

 Unfortunately, the new GC results in segfaults for me. I was lucky to 
 track it down and generate a small test case:



This is good. I'll try to get a fix out very soon.
Jan 24 2007
prev sibling next sibling parent Kazuhiro Inaba <kiki kmonos.net> writes:
 http://www.digitalmars.com/d/changelog.html
 tail recursion works again 



Fine!! But it seems buggy in some corner cases.

1. Nested function

    // quirky way to call dg() n times
    void repeat( int n, void delegate() dg ) {
      if( n&1 ) dg();
      if( n/2 ) repeat( n/2, {dg();dg();} );
    }
    void main() {
      repeat( 10, {printf("Hello\n");} );
    }

  If compiled with -O flag, this program goes into an infinite loop.
  Tail recursive call of repeat function reuses the stack frame, which is
  still referenced by the anonymous delegate, too early.

2. Scope statemenmt

    int scp( int n ){
      if( n==0 ) return 0;
      scope(exit) printf("%d",n);
      return scp(n-1);
    }
    void main() {
      scp(5);
    }

  Without -O flag, it emits 12345 (correct).
  With -O flag enabled, it emits 43210 (at least in my environment.)

3. Conditional expression

    // return in an if statement is optimized as a tail recursion
    long f_if( long n, long acc=0 ) {
      if(n) return f_if( n-1, n+acc ); else return acc;
    }
    // same function written with a conditional statement is not
    long f_cd( long n, long acc=0 ) {
      return n ? f_cd( n-1, n+acc ) : acc;
    }
    void main() {
      printf("%lld\n", f_if(1000000)); // 500000500000
      printf("%lld\n", f_cd(1000000)); // Error: Stack Overflow
    }

  This is not a bug, but it would be preferable if dmd detects and
  optimizes the "return cond ? recursive_call : ..." form.


-- 
Kazuhiro Inaba
Jan 24 2007
prev sibling parent Alexander Panek <a.panek brainsware.org> writes:
Walter Bright wrote:

 New pointer-aware GC. Should run significantly faster for some programs.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.001.zip



Great to see the progress. Though, seems like you got some petty "beta" 
tester, huh? *g
Jan 24 2007