• "Nick Sabalausky" <a a.a> Oct 04 2008
• "Denis Koroskin" <2korden gmail.com> Oct 05 2008
• "Jarrett Billingsley" <jarrett.billingsley gmail.com> Oct 05 2008
• "Denis Koroskin" <2korden gmail.com> Oct 05 2008
• Ary Borenszweig <ary esperanto.org.ar> Oct 05 2008
• "Denis Koroskin" <2korden gmail.com> Oct 05 2008
• Ary Borenszweig <ary esperanto.org.ar> Oct 05 2008
• BCS <ao pathlink.com> Oct 05 2008
• Hoenir <mrmocool gmx.de> Nov 19 2008
• Ary Borenszweig <ary esperanto.org.ar> Nov 19 2008

"Nick Sabalausky" <a a.a> writes:

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. 

"Denis Koroskin" <2korden gmail.com> writes:

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.

"Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:

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.

"Denis Koroskin" <2korden gmail.com> writes:

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?

Ary Borenszweig <ary esperanto.org.ar> writes:

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.

"Denis Koroskin" <2korden gmail.com> writes:

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

Ary Borenszweig <ary esperanto.org.ar> writes:

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

BCS <ao pathlink.com> writes:

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!

Hoenir <mrmocool gmx.de> writes:

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?

Ary Borenszweig <ary esperanto.org.ar> writes:

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