[dmd-beta] 64 bit beta for Linux

[Rainer Schuetze]

Rainer Schuetze wrote:
> Jonathan M Davis wrote:
>> Do _not_ expect your code to work if you compile with ddoc enabled.
>>
>>   
> That's what I was afraid of ;-) The dmd command line interface 
> suggests that you could do so, and so does Visual D. I'd hate to do 
> have to split it into two commands, as this will probably double the 
> compilation time.

I like Andrei's suggestion :-)

>> DayOfWeek is supposed to be ubyte. It doesn't need more space than 
>> that. I haven't seen any problem with it before, so I don't know what 
>> the problem is there. It _should_ work just fine.
>>
>>   
> It seems I can build phobos with dmd from the master branch and 
> visuald from my branch and the problem goes away, so it's probably one 
> of my debugging patches that causes the problems here.
>

This is due to http://d.puremagic.com/issues/show_bug.cgi?id=4372 (type 
of enumerator values reduced to base type in debug info). A minimal test 
case is

import datetime;
void main() {}

and compile with "-g" to include debug information (I had forgotten the 
command line option yesterday). I think the patch is still correct, as 
the enumerator type debug info is never referenced otherwise and thus 
does not pose a problem to the linker. It seems optlink does not like 
enumerator base types other than int (type index 0x74 - I tried patching 
the object file to use type 0x70, but it did not help. The type index 
generated by dmd for ubyte is 0x20).


>>> - I'm still using the d_time functions (e.g. std.file.getTimes), but it
>>> seems the conversion from SysTime is wrong by a month (plus an hour, 
>>> but
>>> that might be due to wrong timezone settings).
>>>     
>>
>> If you find in any bugs in std.datetime, please report them with as 
>> much information as is reasonably possible - including what your 
>> local time zone is and what OS you're on (that matters a lot). As far 
>> as I know, there are no bugs in std.datetime, so if you find any, 
>> they need to be reported.
>>
>>   
> I will try to create a small test tomorrow.
>
While doing so, I noticed that my usage was wrong all the time, because 
I failed to see that monthFromTime() returns values 0 to 11 while 
dateFromTime() returns 1 to 31. Sorry for the noise.
The one hour difference is due to missing UTC to local time translation 
in the compatibilty layer for d_time, but this was also wrong in 2.051. 
The SysTime versions return the same file time as the dir command. 
That's good!

Rainer