Taunting

[Robert Fraser]

Ary Borenszweig wrote:
> Robert Fraser escribió:
>> Ary Borenszweig Wrote:
>>
>>> Ary Borenszweig escribió:
>>>> http://www.youtube.com/watch?v=rtYCFVPfx4M
>>> Bah... I just realized debugging that kind of things might be really 
>>> hart to do. Imagine this:
>>>
>>> ---
>>> char[] something() {
>>>     return "x *= 3; x += 4;";
>>> }
>>>
>>> mixin("int bla(int x) { x *= 2; " ~ something ~ " return 4; }");
>>>
>>> void main() {
>>>     const something = bla(2);
>>> }
>>> ---
>>>
>>> Now I want to debug the invocation of bla: how the variable x is 
>>> being modified. But there's no such place in the source code for that 
>>> definition (well, there is, but it's split in pieces, and obviously 
>>> you'll get lost when debugging).
>>>
>>> So I'm starting to think that the compile-time debugger should work 
>>> on the (formatted) compile-time view of the modules. So you'll end up 
>>> debugging code like this:
>>>
>>> ---
>>> char[] something() {
>>>     return "x *= 3; x += 4;";
>>> }
>>>
>>> int bla(int x) {
>>>     x *= 2;
>>>     x *= 3;
>>>     x += 4;
>>>     return x;
>>> }
>>>
>>> void main() {
>>>     const something = bla(2);
>>> }
>>> ---
>>>
>>> But that's way more hard to do than what I'm doing right now.
>>>
>>> Finally, you might want to have both worlds together, like:
>>>
>>> ---
>>> char[] someOtherFunc() {
>>>    return "char[] x = \"whatever\";";
>>> }
>>>
>>> char[] someFunc() {
>>>    mixin(someOtherFunc());
>>>    return x;
>>> }
>>>
>>>
>>> mixin(someFunc());
>>> ---
>>>
>>> Now I want to debug someFunc(). But I also want to see that 
>>> someOtherFunc() is expanded well, so I can't just show the 
>>> compile-time view of the module, because doing this might have an 
>>> error already (the error I want to debug, for example!). (and also 
>>> the compile-time view dependens on the function I'm trying to debug)
>>>
>>> Aaah... I give up.
>>>
>>> (I came to this conclusion when trying to debug the scrappes:units 
>>> project).
>>
>> NO! Don't give up! I've already started using it, and it's very useful 
>> even if it can't debug compile-time-generated code; that's only a very 
>> small use case.
> 
> Cool! :-)
> 
> Well, I think I'll give up with string mixins for the moment.
> 
> What did you debug? What did you find useful? What would you improve?

I debugged my CTFE code that generates string mixins (essentially a 
compile-time parser for a limited domain-specific language). Worked like 
a charm once I increased Eclipse's memory limits.