January 24, 2007
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.
January 24, 2007
"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?
>>> 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.
>
> 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.


January 24, 2007
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?
>>>> 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.
>> 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. 

Perhaps he meant "Could you give me the patch so I can include it in the next release"?
January 24, 2007
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
January 24, 2007
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.
January 24, 2007
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.
>>  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.

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).
January 24, 2007
> 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

January 24, 2007
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.
January 24, 2007
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.
> >>  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.
> 
> 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
January 24, 2007
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?
>>>> 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.
>> 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. 

Look for the defining module for TypeInfo_Aa in std\typeinfo\*