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