On Feb 6, 2011, at 9:27 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> For projects that _don't_ have that problem but use druntime and Phobos, wouldn't they either just use prebuilt libraries for them or use druntime and Phobos' makefiles when building them, at which point whether they use -D on their project or not has nothing to do with druntime or Phobos.
> 
> Or am I missing something here?

If someone uses -D, then all imported code will be interpreted as the ddoc version. That could mess up template code and inlined functions imported from druntime and Phobos.

On Sunday 06 February 2011 18:41:04 Jason House wrote:
> On Feb 6, 2011, at 9:27 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > For projects that _don't_ have that
> > problem but use druntime and Phobos, wouldn't they either just use
> > prebuilt libraries for them or use druntime and Phobos' makefiles when
> > building them, at which point whether they use -D on their project or
> > not has nothing to do with druntime or Phobos.
> > 
> > Or am I missing something here?
> 
> If someone uses -D, then all imported code will be interpreted as the ddoc version. That could mess up template code and inlined functions imported from druntime and Phobos.

Ah, good point. That _does_ change things. Okay. I guess that Andrei's suggestion would be a good solution, though honestly, I would the problem to be more generally solved. If building with -D or version=D_Ddoc didn't actually generate code, then no one would ever run into this problem again. It _would_ force the documentation generation to be done separately, but that doesn't really strike me as being a big deal (though some people are likely to disagree with me on that). -unittest and -cov are already special in a similar manner.

If we go with Andrei's solution, then people won't run into the problem with Phobos or druntime, but anyone who runs into it with their own code will have to figure it out. So, Andrei's solution is a decent one, but I'd prefer that -D just didn't generate code.

- Jonathan M Davis

On 2/6/11 9:27 PM, Jonathan M Davis wrote:
> On Sunday 06 February 2011 18:05:27 Andrei Alexandrescu wrote:
>> Again, all we need to do is use a different macro than the default one. In hindsight, using D_Ddoc is a mistake as the user does not want to generate docs for Phobos but she does want to import stuff from it.
>
> So, essentially we decide to treat druntime and Phobos differently with regards to documentation by using a different macro on the assumption that no one wants to build their ddoc documentation normally?

That would be the case for any library. Say A writes a library Deimos and B uses it and wants to generate documentation for their own project. Would they expect to generate docs for Deimos along the way?

> I'm not sure how this really solves the problem. Anyone who is building their own code with version(D_Ddoc) blocks will find the problem relatively quickly but they at least will then know how to fix it (don't build your code with -D and generate your documentation separately). For projects that _don't_ have that problem but use druntime and Phobos, wouldn't they either just use prebuilt libraries for them or use druntime and Phobos' makefiles when building them, at which point whether they use -D on their project or not has nothing to do with druntime or Phobos.

Currently Phobos imports are distributed in full. So we need to figure out a way to not mess up their -D with ours. In fact we don't need to figure out anything - let's just defined and use our own version PhobosDoc or whatnot.


Andrei

On 2/6/11 9:54 PM, Jonathan M Davis wrote:
>  I'd prefer that -D just
> didn't generate code.

That's sensible and indeed Phobos works that way, yet it's not something we want to impose on users unless we have to. "People are different."

Andrei

Rainer Schuetze wrote:
> Walter Bright wrote:
>> Which patches do you need?
>>
> necessary:

Thanks!

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

did all but 4092 and 5051.

Rainer Schuetze wrote:
> Walter Bright wrote:
>> Which patches do you need?
>>
> necessary:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5382 [regression 2.051]
> DLL multi-threading broken
> http://d.puremagic.com/issues/show_bug.cgi?id=4017 const initializer
> cannot evaluate size of forward referenced alias
> http://d.puremagic.com/issues/show_bug.cgi?id=4092 broken memory
> management for COM objects derived from IUnknown
> http://d.puremagic.com/issues/show_bug.cgi?id=4069
> std.xml.Document.pretty saves empty elements with spaces and line breaks
> http://d.puremagic.com/issues/show_bug.cgi?id=1266 Cannot forward
> reference the typeof of the base type of a pointer whose base type is
> defined with typeof
> http://d.puremagic.com/issues/show_bug.cgi?id=4598 std.xml check is
> too restrictive
> http://d.puremagic.com/issues/show_bug.cgi?id=2810 Bogus forward
> reference error with auto function
>
> not show stoppers, but still nice to have:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4973 map file with spaces in file name passed without quotes to linker http://d.puremagic.com/issues/show_bug.cgi?id=4328 templated unittests fail to link when instantiated from other file if compiler order isn't correct
>
> convenient for debugging:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4013 Inconsistent codeview debug info for classes derived from IUnknown http://d.puremagic.com/issues/show_bug.cgi?id=4486 CodeView debug info should contain absolute path names http://d.puremagic.com/issues/show_bug.cgi?id=4014 CodeView debug type info not linked in from library http://d.puremagic.com/issues/show_bug.cgi?id=5051 dmd flag for partial compilation - patch to write mixin expansions http://d.puremagic.com/issues/show_bug.cgi?id=4372 type of enumerator values reduced to base type in debug info
>
> I try to keep a few more changes uptodate with the repo (like the shared phobos related stuff), but these do not affect visuald.
>
> Rainer
>
>> 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):
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>

Very cool. Thanks a lot!

I'll comment on 4092 in the bug report.

Rainer

Walter Bright wrote:
> did all but 4092 and 5051.
>
> Rainer Schuetze wrote:
>> Walter Bright wrote:
>>> Which patches do you need?
>>>
>> necessary:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=5382 [regression 2.051]
>> DLL multi-threading broken
>> http://d.puremagic.com/issues/show_bug.cgi?id=4017 const initializer
>> cannot evaluate size of forward referenced alias
>> http://d.puremagic.com/issues/show_bug.cgi?id=4092 broken memory
>> management for COM objects derived from IUnknown
>> http://d.puremagic.com/issues/show_bug.cgi?id=4069
>> std.xml.Document.pretty saves empty elements with spaces and line breaks
>> http://d.puremagic.com/issues/show_bug.cgi?id=1266 Cannot forward
>> reference the typeof of the base type of a pointer whose base type is
>> defined with typeof
>> http://d.puremagic.com/issues/show_bug.cgi?id=4598 std.xml check is
>> too restrictive
>> http://d.puremagic.com/issues/show_bug.cgi?id=2810 Bogus forward
>> reference error with auto function
>>
>> not show stoppers, but still nice to have:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=4973 map file with spaces in file name passed without quotes to linker http://d.puremagic.com/issues/show_bug.cgi?id=4328 templated unittests fail to link when instantiated from other file if compiler order isn't correct
>>
>> convenient for debugging:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=4013 Inconsistent codeview debug info for classes derived from IUnknown http://d.puremagic.com/issues/show_bug.cgi?id=4486 CodeView debug info should contain absolute path names http://d.puremagic.com/issues/show_bug.cgi?id=4014 CodeView debug type info not linked in from library http://d.puremagic.com/issues/show_bug.cgi?id=5051 dmd flag for partial compilation - patch to write mixin expansions http://d.puremagic.com/issues/show_bug.cgi?id=4372 type of enumerator values reduced to base type in debug info
>>
>> I try to keep a few more changes uptodate with the repo (like the shared phobos related stuff), but these do not affect visuald.
>>
>> Rainer
>>
>>> 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):
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

I saw you mentioned "dmd flag for partial compilation - patch to write mixin expansions". Have you tried using Descent with the compile time debugger and view?

On 8 feb 2011, at 08:50, Rainer Schuetze wrote:

> Very cool. Thanks a lot!
> 
> I'll comment on 4092 in the bug report.
> 
> Rainer
> 
> Walter Bright wrote:
>> did all but 4092 and 5051.
>> 
>> Rainer Schuetze wrote:
>>> Walter Bright wrote:
>>>> Which patches do you need?
>>>> 
>>> necessary:
>>> 
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5382 [regression 2.051] DLL multi-threading broken
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4017 const initializer cannot evaluate size of forward referenced alias
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4092 broken memory management for COM objects derived from IUnknown
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4069 std.xml.Document.pretty saves empty elements with spaces and line breaks
>>> http://d.puremagic.com/issues/show_bug.cgi?id=1266 Cannot forward reference the typeof of the base type of a pointer whose base type is defined with typeof
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4598 std.xml check is too restrictive
>>> http://d.puremagic.com/issues/show_bug.cgi?id=2810 Bogus forward reference error with auto function
>>> 
>>> not show stoppers, but still nice to have:
>>> 
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4973 map file with spaces in file name passed without quotes to linker http://d.puremagic.com/issues/show_bug.cgi?id=4328 templated unittests fail to link when instantiated from other file if compiler order isn't correct
>>> 
>>> convenient for debugging:
>>> 
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4013 Inconsistent codeview debug info for classes derived from IUnknown http://d.puremagic.com/issues/show_bug.cgi?id=4486 CodeView debug info should contain absolute path names http://d.puremagic.com/issues/show_bug.cgi?id=4014 CodeView debug type info not linked in from library http://d.puremagic.com/issues/show_bug.cgi?id=5051 dmd flag for partial compilation - patch to write mixin expansions http://d.puremagic.com/issues/show_bug.cgi?id=4372 type of enumerator values reduced to base type in debug info
>>> 
>>> I try to keep a few more changes uptodate with the repo (like the shared phobos related stuff), but these do not affect visuald.
>>> 
>>> Rainer
>>> 
>>>> 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):
>>> 
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>> 
>>> 
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> 
> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-- 
/Jacob Carlborg

On Tue, Feb 8, 2011 at 9:20 AM, Jacob Carlborg <doob at me.com> wrote:
> I saw you mentioned "dmd flag for partial compilation - patch to write mixin expansions". Have you tried using Descent with the compile time debugger and view?

Well if his project is VisualD, I would assume he wants to put that feature into his IDE, and having the compiler provide it means even more tools can use it with out ripping apart the front end.

>>>>> 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):