[dmd-beta] 64 bit beta for Linux

[Jonathan M Davis]

On Sunday 06 February 2011 15:11:46 Rainer Schuetze wrote:
> Hi,
> 
> I cannot actually comment on the 64-bit version, but as it is probably
> also the candidate for dmd2.052 I'll take the opportunity to report on
> updating to the latest revision from github a couple of days ago. As I
> need a couple of patches, I cannot use the release version anyway. There
> were quite a few problems getting my project (visuald) to compile (on
> win32):
> 
> - bug 2962 was hitting me hard, asserting on
> std.conv.parse!(real,string). I reported the workaround in the bug report.
> 
> - join(stringarray,std.string.newline) no longer works, you have to copy
> std.string.newline to a local variable.
> 
> - the linker was bugging me with unresolved symbols from phobos until I
> noticed that I was creating documentation while compiling. This enables
> version D_Ddoc, which causes other declarations to be used in several
> places. Unfortunately, these were not the same as the ones that were
> used when compiling phobos, namely std.file.DirEntry.isDir and
> std.file.DirEntry.linkAttributes, but there might be more. I can
> understand the motivation of having a separate version with declarations
> for the documentation, but these are likely to get out of date pretty
> soon...

You really shouldn't be compiling with ddoc enabled unless you're building the 
documentation. There are just too many cases where you need separate 
declarations for ddoc - often because of differences between OSes. There are 
cases where the ddoc version is different _on purpose_. In the case of 
std.file.DirEntry.isDir, it's const on Windows because it can be. But because it 
can't be on Linux, the ddoc version doesn't list it that way. Now, maybe it's on 
negligble benefit to have isDir const on Windows given that it can't be on Linux, 
but there are definitely cases where ddoc is forced to be different from a 
particular OS' version of a declaration, simply because that declaration is 
different on different systems.

Do _not_ expect your code to work if you compile with ddoc enabled.

> - after fixing that, the linker complained with this:
> m:\s\d\dmd2\dmd\src\..\..\lib\phobos.lib(datetime)  Error 162: Bad Type
> Index reference to type 1003
> 
> which boiled down to the linker not liking the type information written
> for "enum DayOfWeek : ubyte". Using int as the base type fixed it, but I
> guess this is not intended. I could not reproduce the error with a small
> test file, though. While trying to narrow it down, I had to browse
> through std.datetime. This is really difficult due to the unittests
> distracting from the actual code so much. Actually I added a function to
> visuald to remove them all shrinking the file to a quarter of its size.
> I'm impressed by the completeness of the tests, but I would prefer to
> find them in a separate file.

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.

> - 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.

- Jonathan M Davis