Walter Bright wrote:
> On 5/14/2011 2:49 PM, Timon Gehr wrote:
> > Also, not having the full druntime source handy apparently means some code wont CTFE.
>
> What is missing?

I stumbled over foreach(dchar c; char_array);
It will complain that "_aApplycd2" is not defined. Interestingly, it does not even
work when importing the druntime source after all.

druntime also has some deprecated volatile statements btw.


Timon

On 5/14/2011 4:41 PM, Timon Gehr wrote:
> Walter Bright wrote:
>> On 5/14/2011 2:49 PM, Timon Gehr wrote:
>>> Also, not having the full druntime source handy apparently means some code wont
>>> CTFE.
>>
>> What is missing?
>
> I stumbled over foreach(dchar c; char_array);
> It will complain that "_aApplycd2" is not defined. Interestingly, it does not even
> work when importing the druntime source after all.

It should be in dmd2/src/druntime/src/rt/aApply.d

>
> druntime also has some deprecated volatile statements btw.
>
>
> Timon

You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP, which does not work. You probably need some version 6.x, 6.11.1.404 from the "Microsoft Debugging Tools for Windows" worked for me.

http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi

There is a newer version available, but it seems you have to install the full Windows SDK for this.

Andrej Mitrovic wrote:
> Hmm.. so it might be an XP issue. I'll give Win7 a try later.

Am 14.05.2011 18:14, schrieb Mafi:
> Am 14.05.2011 17:09, schrieb Extrawurst:
>> On 14.05.2011 15:23, Mafi wrote:
>>> Am 13.05.2011 23:27, schrieb Walter Bright:
>>>> Thanks for everyone's hard work on this release!
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.067.zip
>>>>
>>>> Now includes FreeBSD:
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.2.052.zip
>>>
>>> I just wanted to say that you made my day but then I tried to compile
>>> one of my projetcs and assertion failures in the compiler! :0 !
>>> Finally I've tracked it done and the problem is
>>>
>>> import std.conv;
>>> enum s1 = to!string('\uE000'+ 6); //works without s
>>> enum s2 = cast(dchar)('\uE000'+ 6); //works without s
>>> enum s = to!string(cast(dchar)('\uE000'+ 6));
>>>
>>> causes "Assertion failure: '(newval->op == TOKarrayliteral || newval->op
>>> == TOKassocarrayliteral || newval->op == TOKstring || newval->op ==
>>> TOKslice || newval->op == TOKnull)' on line 2680 in file 'interpret.c'"
>>
>>
>> posted bugzilla ?
>>
>> http://d.puremagic.com/issues/
>
> Could somebody please do this for me.
>
> Mafi
Thanks
http://d.puremagic.com/issues/show_bug.cgi?id=6001

Looks like enum's are tighter (eg. 'enum last = media[ $ - 1 ];' doesn't work now). It was working in 52. I had heard it might be relaxed, not tightened. I get the error, 'cannot be read at compile time'.

Also immutable imstr = "test"; printf( toStringz( imstr ) ); wasn't working at first, but works now for some reason.

Good to have an update though.

bye,
joelcnz

On 2011-05-15 03:50, Joel Christensen wrote:
> Looks like enum's are tighter (eg. 'enum last = media[ $ - 1 ];' doesn't work now). It was working in 52. I had heard it might be relaxed, not tightened. I get the error, 'cannot be read at compile time'.
> 
> Also immutable imstr = "test"; printf( toStringz( imstr ) ); wasn't
> working at first, but works now for some reason.
> 
> Good to have an update though.

A lot of CTFE stuff was rewritten. What all of the implications of that are, I don't know, but according to Don (who did the rewrite), there are cases which compiled before but didn't generate correct code. I don't know if there were any cases which compiled which were supposed to be illegal. Regardless, because there was a major rewrite for CTFE, the risk of CTFE bugs or behavioral changes is higher than is the case for most releases.

- Jonathan M Davis

Thanks for the reply Jonathan.

I guess it promotes less buggy programs.

- Joel

On 5/15/11, Rainer Schuetze <r.sagitario@gmx.de> wrote:
> You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP, which does not work. You probably need some version 6.x, 6.11.1.404 from the "Microsoft Debugging Tools for Windows" worked for me.
>
> http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi
>
> There is a newer version available, but it seems you have to install the full Windows SDK for this.
>
> Andrej Mitrovic wrote:
>> Hmm.. so it might be an XP issue. I'll give Win7 a try later.
>

No, I have had version 6.12.2.633 installed. I also gave your older
link a try, it didn't help.
I've also tried it on Windows7 after installing debugging tools via
the SDK, and that also didn't help. I really don't understand what is
causing this issue.

Tried compiling via -debug -g, and -debug -gc.

The only other thing I can think of is if there is some other dependency which I might be missing. Maybe I'll take a look at the new phobos sources later and try figuring out what is going on.

On 5/15/2011 4:24 AM, Joel Christensen wrote:
> Thanks for the reply Jonathan.
>
> I guess it promotes less buggy programs.

Please submit bugzilla bug reports for any issues you think should work but do not.

Andrej Mitrovic wrote:
> On 5/15/11, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>> You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP,
>> which does not work. You probably need some version 6.x, 6.11.1.404 from
>> the "Microsoft Debugging Tools for Windows" worked for me.
>>
>> http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi
>>
>> There is a newer version available, but it seems you have to install the
>> full Windows SDK for this.
>>
>> Andrej Mitrovic wrote:
>>> Hmm.. so it might be an XP issue. I'll give Win7 a try later.
> 
> No, I have had version 6.12.2.633 installed. I also gave your older
> link a try, it didn't help.
> I've also tried it on Windows7 after installing debugging tools via
> the SDK, and that also didn't help. I really don't understand what is
> causing this issue.
> 
> Tried compiling via -debug -g, and -debug -gc.
> 
> The only other thing I can think of is if there is some other
> dependency which I might be missing. Maybe I'll take a look at the new
> phobos sources later and try figuring out what is going on.

Is it failing for every executable or only for more complex stuff?

I guess any version of dbghelp.dll might stumble over the debug info of larger programs, e.g. if they contain compressed symbols, symbols longer than 255 characters, inconsistent debug info, etc. cv2pdb also fixes various issues, but these might be unrelated to the symbols necessary for the stack dump.