digitalmars.D - Compile-time generated code... not that nice
- Ary Borenszweig (7/7) May 30 2009 I just realized that code generated at compile-time (with string mixins)...
- Robert Jacques (4/11) May 30 2009 It already can:
- Jarrett Billingsley (2/8) May 30 2009 FWIW templates have more or less the same problem.
- Ary Borenszweig (41/52) May 30 2009 More or less... look, if you have:
- Jarrett Billingsley (14/71) May 30 2009 )
- davidl (15/23) May 30 2009 a possible sulution:
- Steve Teale (5/13) May 31 2009 Ary,
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
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
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
Jarrett Billingsley escribió:On Sat, May 30, 2009 at 3:03 PM, Ary Borenszweig <ary esperanto.org.ar> wrote: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. :-PI 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
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=this 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=andMore 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 =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.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=eis no longer in sync with the code. I know this is a contrived example, but at least when debugging scrapple/units it happens. :-POh 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
ÔÚ 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
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