[ESS] ess-tracebug - feature suggestion

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2010 10:23 AM, Vitalie S. wrote:
> Rainer M Krug <r.m.krug at gmail.com> writes:
> 
>> Hi
>>
>> I am debugging (again) at the moment, and am wondering, uf it would be
>> possible to have conditional breakpoints in ess-tracebug? At the moment,
>> I modify the source code with an if statement and put the breakpoint in
>> the if :
>>
>> if (x==0) {
>>   cat(x)   ## Add breakpoint here
>> }
>>
>> but it would be nice if a conditional breakpoint could be included.
> I agree. But, how do you see the work-flow? Here is what I think of it:
> 
> M-c B pop-ups a request in the minibuffer for the condition to use, and then insert
> the conditional breakpoint.

Sounds perfect to me.

> 
> For time being you can define your custom conditional breakpoints which are
> static:
> 
> (nconc ess-bp-type-spec-alist '((my-browser "browser(expr = exists(\"a\") && a >.5)" "My-Br>\n" filled-square font-lock-doc-face)))
> 
> makes available a conditional breakpoint which tests for a>.5 before being
> triggered. 

Nice - I will try to remember this and use it until you have implemented it.

> You probably already know that it can be set with M-c b b b :)

Actually not.
So multiple b are cycling through defined types of breakpoints? What is
the >R one?


> 
> To remove the appended custom breakpoint use (nbutlast ess-bp-type-spec-alist). 

OK. Thanks.

> 
>>
>> Also: would it be possible to define watch variables, whose values are
>> shown after each line executed? This could be in a new buffer, as the
>> main buffer could become quite cluttered.
> 
> Yes, this is a priority now. I have plans for full blown environments navigator
> but that will take some time. A basic watch window must be feasible unless there
> are some technical issues with sub-process communication during the debugging.
> 
> How about this  work flow:
> 
> M-c w pops up the minibuffer request for expression to watch for (like str(a),
> head(df, 2), a[2:3] etc), and registers it in the list of watched expressions.


Sounds good to me - and the w makes sense.

> 
> Once the list of watched expressions is non empty the watch buffer pop-ups
> whenever the debugging is active.

Yes - would it be possible to to have a variable which specifies if the
watch buffer is in a new window or a new frame - a new frame might be
useful.

> 
> To remove the variables from the watch list, navigate to watch window and kill
> lines with "k" key. Navigate in watch window with "p", "n". Move expression
> up/down with "u","d".

SOunds good for me - what about a to add an expression to watch?

> 
> Some things to think about.
> Should watch window be displayed only during the active debugging or all the
> time? 

what about a variable like close-watch-window-after-debugging ? But in
general, the window / frame should be closed, but the buffer should
still be there, so that I could go back to it.

> How the screen should be split? 

again a variable? similar to the one in ESS for the R process?

> Split only the iESS window, or the whole screen? 

> May be hide the iESS altogether?  

I think these depend on personal preferences, and it would be nice if
they could be, in a later stage, be configured by the user.

>

> Any ideas are welcome, since I already forgot the time I last used a watch
> window.

I just thought about one: what about logging points? like breakpoints,
but that values of expressions are logged, but the running of the
program is not interrupted? i.e:

M-c l a
brings up a request for the expression to be logged

M-c l f
brings up a request for the filename to which log he expression

M-c l o
brings up a request if the logs should be appended or overwritten

.
.
.

Another option for logging: Open a new R session, and store the logged
variable values there as a list - this would enable plotting for quick
checks, ....

Thinking of it, I would actually prefer the new R session.

> 
>>
>> And finally: the tab-completion is not working when debugging, but the
>> same applies when using browser() - so it has nothing to do with
>> ess-tracebug in particular, but is related to debugging.
>>
> 
> It works for me.  The  `ess-complete-object-name` which performs the
> completion and should be fine with you as well.

I'll try it out again by using `ess-complete-object-name` directly and
not tab.


> 
> I will get down to conditional breakpoint and watch window in the January.
> Hopefully you don't plan to do some heavy debugging  during the Christmas holidays:)

Don't worry - over the Christmas holidays, I will go into personal
recovery mode and not R / ess debug mode.

I am really looking forward to the new release of ess-tracebug.


> 
> Thanks for the feedback,

Pleasure - that's what I like about open-source software: even if I
don't have the knowledge (and time) to code myself, I can help to
improve the software by giving feedback.

Cheers,

Rainer

> Vitalie.
>> Cheers,
>>
>> Rainer


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:        +33 - (0)9 53 10 27 44
Cell:       +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:      Rainer at krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0J49IACgkQoYgNqgF2egpQ7gCeJDpPxa8xxg5BihAVyRIYeAJm
fJEAn2CtsQkWk6gmzKmH5z3uMDAtmoLz
=LFsx
-----END PGP SIGNATURE-----