www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compile-time generated code... not that nice

reply Ary Borenszweig <ary esperanto.org.ar> writes:
I just realized that code generated at compile-time (with string mixins) 
is hard (or impossible) to debug (I mean at runtime, not just at 
compile-time). Do you think it's a big shortcomming of D? How can this 
be solved?

Maybe the compiler can generate a file with the contents of a module 
with mixins expanded, and use these files as the input to the compiler 
and linker, so these can be used in the debugging process.
May 30 2009
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 30 May 2009 15:03:10 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 I just realized that code generated at compile-time (with string mixins)  
 is hard (or impossible) to debug (I mean at runtime, not just at  
 compile-time). Do you think it's a big shortcomming of D? How can this  
 be solved?

 Maybe the compiler can generate a file with the contents of a module  
 with mixins expanded, and use these files as the input to the compiler  
 and linker, so these can be used in the debugging process.


It already can:
pragma(msg,"Some string");
May 30 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, May 30, 2009 at 3:03 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:

 I just realized that code generated at compile-time (with string mixins) is
 hard (or impossible) to debug (I mean at runtime, not just at compile-time).
 Do you think it's a big shortcomming of D? How can this be solved?

 Maybe the compiler can generate a file with the contents of a module with
 mixins expanded, and use these files as the input to the compiler and
 linker, so these can be used in the debugging process.


FWIW templates have more or less the same problem.
May 30 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley escribió:

 On Sat, May 30, 2009 at 3:03 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:

 I just realized that code generated at compile-time (with string mixins) is
 hard (or impossible) to debug (I mean at runtime, not just at compile-time).
 Do you think it's a big shortcomming of D? How can this be solved?

 Maybe the compiler can generate a file with the contents of a module with
 mixins expanded, and use these files as the input to the compiler and
 linker, so these can be used in the debugging process.


 
 FWIW templates have more or less the same problem.


More or less... look, if you have:

---
template Foo(T) {
   T someMethod(T x) {
      x += 4;
      return x;
   }
}

void main() {
   Foo!(int).someMethod(4);
}
---

If you debug it, if you step into someMethod you'll get to correct lines 
and you'll understand what's going on. But if you do:

---
char[] one() {
   return "x += 4;\n";
}

char[] two() {
   return "return x;\n";
}

mixin("int someMethod(int x) {" ~
	one() ~
	two() ~
        "}";

void main() {
   someMethod(4);
}
---

Now if you step into someMethod, you'll go to the mixin line, and then 
stepping further you'll get to the "one()" line, but it'll be confusing. 
Even more, if you write more line breaks, like this:

mixin("int someMethod(int x) {\n\n\n\n\n\n\n" ~
	one() ~
	two() ~
        "}";

then when debugging you'll go to lines below the mixin, because the 
source is no longer in sync with the code.

I know this is a contrived example, but at least when debugging 
scrapple/units it happens. :-P
May 30 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, May 30, 2009 at 4:42 PM, Ary Borenszweig <ary esperanto.org.ar> wro=
te:

 Jarrett Billingsley escribi=F3:

 On Sat, May 30, 2009 at 3:03 PM, Ary Borenszweig <ary esperanto.org.ar>
 wrote:

 I just realized that code generated at compile-time (with string mixins=






)

 is
 hard (or impossible) to debug (I mean at runtime, not just at
 compile-time).
 Do you think it's a big shortcomming of D? How can this be solved?

 Maybe the compiler can generate a file with the contents of a module wi=






th

 mixins expanded, and use these files as the input to the compiler and
 linker, so these can be used in the debugging process.


 FWIW templates have more or less the same problem.


 More or less... look, if you have:

 ---
 template Foo(T) {
 =A0T someMethod(T x) {
 =A0 =A0 x +=3D 4;
 =A0 =A0 return x;
 =A0}
 }

 void main() {
 =A0Foo!(int).someMethod(4);
 }
 ---

 If you debug it, if you step into someMethod you'll get to correct lines =


and

 you'll understand what's going on. But if you do:

 ---
 char[] one() {
 =A0return "x +=3D 4;\n";
 }

 char[] two() {
 =A0return "return x;\n";
 }

 mixin("int someMethod(int x) {" ~
 =A0 =A0 =A0 =A0one() ~
 =A0 =A0 =A0 =A0two() ~
 =A0 =A0 =A0 "}";

 void main() {
 =A0someMethod(4);
 }
 ---

 Now if you step into someMethod, you'll go to the mixin line, and then
 stepping further you'll get to the "one()" line, but it'll be confusing.
 Even more, if you write more line breaks, like this:

 mixin("int someMethod(int x) {\n\n\n\n\n\n\n" ~
 =A0 =A0 =A0 =A0one() ~
 =A0 =A0 =A0 =A0two() ~
 =A0 =A0 =A0 "}";

 then when debugging you'll go to lines below the mixin, because the sourc=


e

 is no longer in sync with the code.

 I know this is a contrived example, but at least when debugging
 scrapple/units it happens. :-P


Oh I certainly don't disagree with you that string mixins make this
kind of stuff extremely difficult to debug.  It's even difficult for
the compiler to issue reasonable error messages; currently it seems to
issue errors within string mixins at (line of mixin expression + line
within string), which is usually completely bogus.  However, if we're
going to solve the debugging issues with string mixins, we may as well
try to find a solution that would improve the handling of templates in
conjunction with debug info as well.
May 30 2009
parent davidl <davidl nospam.org> writes:
ÔÚ Sun, 31 May 2009 05:31:45 +0800£¬Jarrett Billingsley  
<jarrett.billingsley gmail.com> дµÀ:


 Oh I certainly don't disagree with you that string mixins make this
 kind of stuff extremely difficult to debug.  It's even difficult for
 the compiler to issue reasonable error messages; currently it seems to
 issue errors within string mixins at (line of mixin expression + line
 within string), which is usually completely bogus.  However, if we're
 going to solve the debugging issues with string mixins, we may as well
 try to find a solution that would improve the handling of templates in
 conjunction with debug info as well.


a possible sulution:

in a file Blah.d:83, we have following
mixin(compile_time_string);

1. write the compile_time_string to file \mixin\Blah\mixin_001.d ( 001 is  
the id ) with the boilerplate: // mixed in file: Blah.d:83 (mixin LoC)
2. the debug info for the compile_time_string all points to that  
\mixin\Blah\mixin_001.d

if we have more strings to be mixed in, we can simply increase the id 001  
to 002, and generate another file into dir \mixin\Blah

For templates we can store them in  
\template\Blah\template_templateName_templateArgs.d


-- 
ʹÓà Opera ¸ïÃüÐԵĵç×ÓÓʼþ¿Í»§³ÌÐò: http://www.opera.com/mail/
May 30 2009
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Ary Borenszweig Wrote:


 I just realized that code generated at compile-time (with string mixins) 
 is hard (or impossible) to debug (I mean at runtime, not just at 
 compile-time). Do you think it's a big shortcomming of D? How can this 
 be solved?
 
 Maybe the compiler can generate a file with the contents of a module 
 with mixins expanded, and use these files as the input to the compiler 
 and linker, so these can be used in the debugging process.


Ary,

And because often the only way to make code compile with either d1 or d2 is to
use a mixin in the D2 version block, that means that it will be that D2 is a
pain to debug.

What are you using for debugging? I'm still using writefln, or failing that,
printf, but I would like to advance.

Steve
May 31 2009