View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2011
Re: Plot2kill 0.2
"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.
March 11, 2011
Re: Plot2kill 0.2
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
March 11, 2011
Re: Plot2kill 0.2
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.
March 11, 2011
Re: Plot2kill 0.2
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
March 12, 2011
Re: Plot2kill 0.2
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
March 12, 2011
Re: Plot2kill 0.2
"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.
March 12, 2011
Re: Plot2kill 0.2
"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.
March 12, 2011
Re: Plot2kill 0.2
"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");
March 12, 2011
Re: Plot2kill 0.2
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
March 16, 2011
Re: Plot2kill 0.2
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.
1 2 3 4 5
Top | Discussion index | About this forum | D home