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.

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");

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.

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

On Sat, May 30, 2009 at 4:42 PM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> 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
>

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.

在 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/

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