I don't suppose DMD has any way to output a copy of what the source files look like after things like mixins, CTFE and versions are applied? (Sort of like running a C compiler with a "preprocess-only" flag). I don't see anything like this in the listed command-line params, but maybe I missed it.

I have a program (that makes heavy use of mixins and CTFE and such) that gives wildly different output between two different versions of DMD/Tango (Tango's documented "breaking changes" don't appear to be the culprit and nothing in DMD's changelog or the latest bugzilla entries seem to immediately stick out). I'm sure I can track it down, but it would help to narrow things down if I could run the "preprocessed" results from both environments through a file diff.

On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a@a.a> wrote:

> I don't suppose DMD has any way to output a copy of what the source files
> look like after things like mixins, CTFE and versions are applied? (Sort of
> like running a C compiler with a "preprocess-only" flag). I don't see
> anything like this in the listed command-line params, but maybe I missed it.
>
> I have a program (that makes heavy use of mixins and CTFE and such) that
> gives wildly different output between two different versions of DMD/Tango
> (Tango's documented "breaking changes" don't appear to be the culprit and
> nothing in DMD's changelog or the latest bugzilla entries seem to
> immediately stick out). I'm sure I can track it down, but it would help to
> narrow things down if I could run the "preprocessed" results from both
> environments through a file diff.
>
>

D doesn't have a dedicated preprocessor and I believe all the mixins and stuff is applied and parsed of fly during AST construction, just like inlining is done on AST instead of codegen phase.

On Sun, Oct 5, 2008 at 8:28 AM, Denis Koroskin <2korden@gmail.com> wrote:
> On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a@a.a> wrote:
>
>> I don't suppose DMD has any way to output a copy of what the source files
>> look like after things like mixins, CTFE and versions are applied? (Sort
>> of
>> like running a C compiler with a "preprocess-only" flag). I don't see
>> anything like this in the listed command-line params, but maybe I missed
>> it.
>>
>> I have a program (that makes heavy use of mixins and CTFE and such) that gives wildly different output between two different versions of DMD/Tango (Tango's documented "breaking changes" don't appear to be the culprit and nothing in DMD's changelog or the latest bugzilla entries seem to immediately stick out). I'm sure I can track it down, but it would help to narrow things down if I could run the "preprocessed" results from both environments through a file diff.
>>
>>
>
> D doesn't have a dedicated preprocessor and I believe all the mixins and stuff is applied and parsed of fly during AST construction, just like inlining is done on AST instead of codegen phase.
>

Yes, but that doesn't necessarily preclude it from being able to i.e. output the post-meta code using the same mechanism that outputs headers.

One of the problems I do see with it, however, is template names - at least on Windows, DMD will attempt to compress and then ultimately MD5-hash long template names to work around limitations in the OMF object format it uses.  These would not be valid D identifiers.

On Sun, 05 Oct 2008 18:31:47 +0400, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:

> On Sun, Oct 5, 2008 at 8:28 AM, Denis Koroskin <2korden@gmail.com> wrote:
>> On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a@a.a> wrote:
>>
>>> I don't suppose DMD has any way to output a copy of what the source files
>>> look like after things like mixins, CTFE and versions are applied? (Sort
>>> of
>>> like running a C compiler with a "preprocess-only" flag). I don't see
>>> anything like this in the listed command-line params, but maybe I missed
>>> it.
>>>
>>> I have a program (that makes heavy use of mixins and CTFE and such) that
>>> gives wildly different output between two different versions of DMD/Tango
>>> (Tango's documented "breaking changes" don't appear to be the culprit and
>>> nothing in DMD's changelog or the latest bugzilla entries seem to
>>> immediately stick out). I'm sure I can track it down, but it would help to
>>> narrow things down if I could run the "preprocessed" results from both
>>> environments through a file diff.
>>>
>>>
>>
>> D doesn't have a dedicated preprocessor and I believe all the mixins and
>> stuff is applied and parsed of fly during AST construction, just like
>> inlining is done on AST instead of codegen phase.
>>
>
> Yes, but that doesn't necessarily preclude it from being able to i.e.
> output the post-meta code using the same mechanism that outputs
> headers.
>
> One of the problems I do see with it, however, is template names - at
> least on Windows, DMD will attempt to compress and then ultimately
> MD5-hash long template names to work around limitations in the OMF
> object format it uses.  These would not be valid D identifiers.

Agree. There could also be some kind of mapping from compressed to original form, so that's hardly an issue. Besides, identifier compression shouldn't take place unless object file is about to be generated, right?

Nick Sabalausky escribió:
> I don't suppose DMD has any way to output a copy of what the source files look like after things like mixins, CTFE and versions are applied? (Sort of like running a C compiler with a "preprocess-only" flag). I don't see anything like this in the listed command-line params, but maybe I missed it.
> 
> I have a program (that makes heavy use of mixins and CTFE and such) that gives wildly different output between two different versions of DMD/Tango (Tango's documented "breaking changes" don't appear to be the culprit and nothing in DMD's changelog or the latest bugzilla entries seem to immediately stick out). I'm sure I can track it down, but it would help to narrow things down if I could run the "preprocessed" results from both environments through a file diff. 

Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port).

Note that this will turn things like:

const int x = 1 + 2 + 3 + 4;

into

const int x = 10;

and:

const int x = someFuncThatCanBeEvaluatedAtCompileTime(2);

into:

const int x = 20;

I don't know if this is good or bad...

I'll let you know when I'll have it done.

On Sun, 05 Oct 2008 19:01:41 +0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:

> Nick Sabalausky escribió:
>> I don't suppose DMD has any way to output a copy of what the source files look like after things like mixins, CTFE and versions are applied? (Sort of like running a C compiler with a "preprocess-only" flag). I don't see anything like this in the listed command-line params, but maybe I missed it.
>>  I have a program (that makes heavy use of mixins and CTFE and such) that gives wildly different output between two different versions of DMD/Tango (Tango's documented "breaking changes" don't appear to be the culprit and nothing in DMD's changelog or the latest bugzilla entries seem to immediately stick out). I'm sure I can track it down, but it would help to narrow things down if I could run the "preprocessed" results from both environments through a file diff.
>
> Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port).
>
> Note that this will turn things like:
>
> const int x = 1 + 2 + 3 + 4;
>
> into
>
> const int x = 10;
>
> and:
>
> const int x = someFuncThatCanBeEvaluatedAtCompileTime(2);
>
> into:
>
> const int x = 20;
>
> I don't know if this is good or bad...
>
> I'll let you know when I'll have it done.

The best thing whould be to view the code transformation step by step (using some slider at the bottom of view):

// Step 1:
const int x = mixin!("someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3)");

// Step 2:
const int x = someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3);

// Step 3:
const int x = someFuncThatCanBeEvaluatedAtCompileTime(10);

// Step 4:
const int x = 42;

This would be awesome, but I guess it's hardly possible :(

Denis Koroskin escribió:
> On Sun, 05 Oct 2008 19:01:41 +0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> 
>> Nick Sabalausky escribió:
>>> I don't suppose DMD has any way to output a copy of what the source files look like after things like mixins, CTFE and versions are applied? (Sort of like running a C compiler with a "preprocess-only" flag). I don't see anything like this in the listed command-line params, but maybe I missed it.
>>>  I have a program (that makes heavy use of mixins and CTFE and such) that gives wildly different output between two different versions of DMD/Tango (Tango's documented "breaking changes" don't appear to be the culprit and nothing in DMD's changelog or the latest bugzilla entries seem to immediately stick out). I'm sure I can track it down, but it would help to narrow things down if I could run the "preprocessed" results from both environments through a file diff.
>>
>> Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port).
>>
>> Note that this will turn things like:
>>
>> const int x = 1 + 2 + 3 + 4;
>>
>> into
>>
>> const int x = 10;
>>
>> and:
>>
>> const int x = someFuncThatCanBeEvaluatedAtCompileTime(2);
>>
>> into:
>>
>> const int x = 20;
>>
>> I don't know if this is good or bad...
>>
>> I'll let you know when I'll have it done.
> 
> The best thing whould be to view the code transformation step by step (using some slider at the bottom of view):
> 
> // Step 1:
> const int x = mixin!("someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3)");
> 
> // Step 2:
> const int x = someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3);
> 
> // Step 3:
> const int x = someFuncThatCanBeEvaluatedAtCompileTime(10);
> 
> // Step 4:
> const int x = 42;
> 
> This would be awesome, but I guess it's hardly possible :(

It's possible. Another idea that I have is to be able to debug compile-time evaluation. So you would right click an expression, select "Debug Compile-Time Evaluation", and you'd be able to step through the evaluation, seeing values as they are transformed. That's a bit harder than the former idea. I wonder if somebody would find this useful... It seems like a really entertaining thing to implement. :-)

Reply to Ary,

> It's possible. Another idea that I have is to be able to debug
> compile-time evaluation. So you would right click an expression,
> select "Debug Compile-Time Evaluation", and you'd be able to step
> through the evaluation, seeing values as they are transformed. That's
> a bit harder than the former idea. I wonder if somebody would find
> this useful... It seems like a really entertaining thing to implement.
> :-)
> 


Please Man, I'm begg'in you! Do it!

BCS schrieb:
> Reply to Ary,
> 
>> It's possible. Another idea that I have is to be able to debug
>> compile-time evaluation. So you would right click an expression,
>> select "Debug Compile-Time Evaluation", and you'd be able to step
>> through the evaluation, seeing values as they are transformed. That's
>> a bit harder than the former idea. I wonder if somebody would find
>> this useful... It seems like a really entertaining thing to implement.
>> :-)
>>
> 
> 
> Please Man, I'm begg'in you! Do it!
> 
> 

Any news?

Hoenir wrote:
> BCS schrieb:
>> Reply to Ary,
>>
>>> It's possible. Another idea that I have is to be able to debug
>>> compile-time evaluation. So you would right click an expression,
>>> select "Debug Compile-Time Evaluation", and you'd be able to step
>>> through the evaluation, seeing values as they are transformed. That's
>>> a bit harder than the former idea. I wonder if somebody would find
>>> this useful... It seems like a really entertaining thing to implement.
>>> :-)
>>>
>>
>>
>> Please Man, I'm begg'in you! Do it!
>>
>>
> 
> Any news?

Sorry, exams time. :(