"BCS" <ao@pathlink.com> wrote in message news:78ccfa2d417fc8cbae8318d2e5b0@news.digitalmars.com...
> Reply to Nick,
>
> [sniped rant about why the web sucks]
>
> I'll grant you most of that and I don't care about the rest.
>

"Cool" and "Fair enough" ;)

> It's ironic that this should come up in the D community because it sounds a lot like C++ template are to the web like D template are to what the web should be. That is; the Web has taken what it has and abused it (because nothing better was available) to get something it wants with no pity for the sucker who has to use it.
>

That's a very good assesement. I hadn't really thought of it that way, but that's a very good observation.

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.

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?

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.

Reply to Ary,

> (I came to this conclusion when trying to debug the scrapple:units
> project).
> 

I'm sorry <g> OTOH that is a rater pathological cases.

One option that might be doable (I don't know how the inside works so I'm guessing here) is to have the debug more highlight expression that can undergo CTFE and constant folding. The user would work by selecting an expression and it would be replace with it's value. to make things manageable, long string expressions could be truncated and accessed via pop up and as for string mixins, run the result thought the general code formatter.