"dsimcha" <dsimcha@yahoo.com> wrote in message news:ildvns$2epk$1@digitalmars.com...
> == Quote from Kagamin (spam@here.lot)'s article
>> > > Just put a break point at the beginning of the line and step through it?
>> > May be m$ debugger sucks, but it's nontrivial to step through methods called
> in single statement: it tends to step through the whole statement, though
> you can
> step-in and step-out.
>> You will also step into functions called for arguments like getColor() in the
> example.
>
> Ok, I'll admit I don't know much about this stuff.  I debug mostly with
> asserts
> and print statements.  I very seldom use a debugger.

Same here. I got used to "printf-debugging" when dealing with a bunch of platforms that lacked debuggers. Plus it makes it a lot easier to look backwards in time (just scroll up instead of restarting and re-stepping through).

Unfortunately that makes debugging CTFE a royal pain in the ass since CTFE has absolutely zero way to send anything to stdout - or any other IO for that matter. And you can't work around it by appending to a log to then display at runtime because CTFE deliberately disallows any global mutable state *even* when order-of-evaluation doesn't matter for what you're trying to do.

On 11/03/2011 21:33, Nick Sabalausky wrote:
> "dsimcha"<dsimcha@yahoo.com>  wrote in message
>
> Unfortunately that makes debugging CTFE a royal pain in the ass since CTFE
> has absolutely zero way to send anything to stdout - or any other IO for
> that matter. And you can't work around it by appending to a log to then
> display at runtime because CTFE deliberately disallows any global mutable
> state *even* when order-of-evaluation doesn't matter for what you're trying
> to do.
>
>

huh?

just use:

pragma(msg, CTFE_string);

piss of piss.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

On 3/11/11 11:36 PM, Simon wrote:
> On 11/03/2011 21:33, Nick Sabalausky wrote:
>> Unfortunately that makes debugging CTFE a royal pain in the ass since
>> CTFE
>> has absolutely zero way to send anything to stdout - […]
> […]
> just use:
>
> pragma(msg, CTFE_string);

No, this doesn't quite cut it for debugging CTFE functions: While you can obviously use pragma(msg, …) to write the *result* of a function invoked via CTFE to standard output, this doesn't help you if you want to debug the stuff going on *in* that function itself, for example to track down one of the numerous CTFE bugs.

David


P.S.: As a last resort to get something printed during CTFE evaluation, it is possible to use »assert(false, message)« – DMD prints the (correctly evaluated) message as part of the compiler error message. Obviously, this screws up compilation though.

On 11/03/2011 22:52, David Nadlinger wrote:
> On 3/11/11 11:36 PM, Simon wrote:
>> On 11/03/2011 21:33, Nick Sabalausky wrote:
>>> Unfortunately that makes debugging CTFE a royal pain in the ass since
>>> CTFE
>>> has absolutely zero way to send anything to stdout - […]
>> […]
>> just use:
>>
>> pragma(msg, CTFE_string);
>
> No, this doesn't quite cut it for debugging CTFE functions: While you
> can obviously use pragma(msg, …) to write the *result* of a function
> invoked via CTFE to standard output, this doesn't help you if you want
> to debug the stuff going on *in* that function itself, for example to
> track down one of the numerous CTFE bugs.
>
> David
>
>
> P.S.: As a last resort to get something printed during CTFE evaluation,
> it is possible to use »assert(false, message)« – DMD prints the
> (correctly evaluated) message as part of the compiler error message.
> Obviously, this screws up compilation though.

Never had a problem myself; and I've used some really hairy string mixins to create runtime & CTFE functions.
Worse case, when composing functions is to print out the result and copy into a file and then debug as normal.

It's neither elegant or convenient, but it works.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

On 3/12/11 12:41 AM, Simon wrote:
>> No, this doesn't quite cut it for debugging CTFE functions: While you
>> can obviously use pragma(msg, …) to write the *result* of a function
>> invoked via CTFE to standard output, this doesn't help you if you want
>> to debug the stuff going on *in* that function itself, for example to
>> track down one of the numerous CTFE bugs.
>> […]
>
> Never had a problem myself; and I've used some really hairy string
> mixins to create runtime & CTFE functions.
> Worse case, when composing functions is to print out the result and copy
> into a file and then debug as normal.
>
> It's neither elegant or convenient, but it works.

But not for the case mentioned above – first, because there is often no sane way to »print out the result«, and second, because if there are CTFE bugs involved, running the code at runtime (I guess that's what you meant with »debug as normal«) obviously doesn't help you in any way.

And yes, I had (or rather have) this problem myself, with not even that crazy code…

David

"Simon" <s.d.hammett@gmail.com> wrote in message news:ilec50$cj0$1@digitalmars.com...
> On 11/03/2011 22:52, David Nadlinger wrote:
>> On 3/11/11 11:36 PM, Simon wrote:
>>> On 11/03/2011 21:33, Nick Sabalausky wrote:
>>>> Unfortunately that makes debugging CTFE a royal pain in the ass since
>>>> CTFE
>>>> has absolutely zero way to send anything to stdout - [.]
>>> [.]
>>> just use:
>>>
>>> pragma(msg, CTFE_string);
>>
>> No, this doesn't quite cut it for debugging CTFE functions: While you can obviously use pragma(msg, .) to write the *result* of a function invoked via CTFE to standard output, this doesn't help you if you want to debug the stuff going on *in* that function itself, for example to track down one of the numerous CTFE bugs.
>>
>> David
>>
>>
>> P.S.: As a last resort to get something printed during CTFE evaluation, it is possible to use »assert(false, message)« - DMD prints the (correctly evaluated) message as part of the compiler error message. Obviously, this screws up compilation though.
>
> Never had a problem myself; and I've used some really hairy string mixins
> to create runtime & CTFE functions.
> Worse case, when composing functions is to print out the result and copy
> into a file and then debug as normal.
>
> It's neither elegant or convenient, but it works.
>

Yes. Like I said, it's a pain in the ass. I never said it wasn't possible.

"Simon" <s.d.hammett@gmail.com> wrote in message news:ile8be$4as$1@digitalmars.com...
> On 11/03/2011 21:33, Nick Sabalausky wrote:
>> "dsimcha"<dsimcha@yahoo.com>  wrote in message
>>
>> Unfortunately that makes debugging CTFE a royal pain in the ass since
>> CTFE
>> has absolutely zero way to send anything to stdout - or any other IO for
>> that matter. And you can't work around it by appending to a log to then
>> display at runtime because CTFE deliberately disallows any global mutable
>> state *even* when order-of-evaluation doesn't matter for what you're
>> trying
>> to do.
>>
>>
>
> huh?
>
> just use:
>
> pragma(msg, CTFE_string);
>
> piss of piss.
>

s/piss/shit/

void foo(string str)
{
    pragma(msg, str);
}
enum x = foo("fubared");

Try it. Big fail.

"Nick Sabalausky" <a@a.a> wrote in message news:ilf11q$1l6l$1@digitalmars.com...
> "Simon" <s.d.hammett@gmail.com> wrote in message news:ile8be$4as$1@digitalmars.com...
>> On 11/03/2011 21:33, Nick Sabalausky wrote:
>>> "dsimcha"<dsimcha@yahoo.com>  wrote in message
>>>
>>> Unfortunately that makes debugging CTFE a royal pain in the ass since
>>> CTFE
>>> has absolutely zero way to send anything to stdout - or any other IO for
>>> that matter. And you can't work around it by appending to a log to then
>>> display at runtime because CTFE deliberately disallows any global
>>> mutable
>>> state *even* when order-of-evaluation doesn't matter for what you're
>>> trying
>>> to do.
>>>
>>>
>>
>> huh?
>>
>> just use:
>>
>> pragma(msg, CTFE_string);
>>
>> piss of piss.
>>
>
> s/piss/shit/
>
> void foo(string str)
> {
>    pragma(msg, str);
> }
> enum x = foo("fubared");
>
> Try it. Big fail.
>

Erm, I meant:

int foo(string str)
{
    pragma(msg, str);
    return 0;
}
enum x = foo("fubared");

On 12/03/2011 05:48, Nick Sabalausky wrote:
> "Nick Sabalausky"<a@a.a>  wrote in message
>
> Erm, I meant:
>
> int foo(string str)
> {
>      pragma(msg, str);
>      return 0;
> }
> enum x = foo("fubared");
>

lol, not come across that before. guess I just write my code a different way from you.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Nick Sabalausky Wrote:

> Same here. I got used to "printf-debugging" when dealing with a bunch of platforms that lacked debuggers. Plus it makes it a lot easier to look backwards in time (just scroll up instead of restarting and re-stepping through).

One man wrote a debug logger for .net, that instruments IL code and logs all operations at runtime and later you can browse the log with a visual debugger interface and easily go back and forth in time. He also claimed that the log wasn't very big.