help! what's wrong with setBreakpoint

I am not sure...

How do I make sure about that?

esp " Are you sure you were executing the same function after you hit c?"?
From a later one of your messages (adding a call to browser() didn't do 
anything), I think you weren't.  Now you know how to check.

Debugging code in packages can be tricky.  There are several strategies 
that I've used in different circumstances:

1.  source() the original source files from the command line.  Then 
you're not in a namespace, so you don't have that to confuse you.  (But 
if you don't source everything, you may find the source'd functions 
can't see the ones you skipped.)

2.  Set the environment variable R_KEEP_PKG_SOURCE to yes, then install 
the package; do all my debugging via things like

setBreakpoint("srcfile.R#30", env=somefunction)

where somefunction is in the package being debugged.  You can't make 
permanent changes to the functions this way, but you can add debugging 
code in the setBreakpoint call.

3.  Edit the source and re-install the package.   This is a bit of a 
pain, but it's the best way to reproduce the real execution environment.

Duncan Murdoch
Thanks again!

On Tue, Dec 6, 2011 at 8:57 AM, Duncan Murdoch<murdoch.duncan at gmail.com>wrote:

 On 06/12/2011 9:47 AM, Michael wrote:

 It printed:

 c:\R\myproject1\myfile.R#38:
  myfunc1 step  6,4,9 in<environment: R_GlobalEnv>

 What do you think?

 So that set a breakpoint in the copy of the function in the global
 environment.  Are you sure you were executing the same function after you
 hit c?  If you were working on code in a package, you may have been
 executing the function in the namespace of the package, not the one in the
 global environment.

 If that's not the case, then are you sure you ever got to that line?  You
 can see where the breakpoint was set using

 body(myfunc1)[[c(6,4,9)]]

 (Watch the parens and brackets!)

 Duncan Murdoch

  Thank you!
 On Tue, Dec 6, 2011 at 6:22 AM, Duncan Murdoch<murdoch.duncan at gmail.**com<murdoch.duncan at gmail.com>
 >wrote:

 >   On 11-12-05 10:32 PM, Michael wrote:
 >
 >>   Hi all,
 >>
 >>   I am in the middle of debugging which is stopped using "browser()"...
 in
 >>   myfile.R at around line #25.
 >>
 >>   I was then stuck in a big loop which I want to escape and stop the
 program
 >>   at the line after the big loop.
 >>
 >>   In the debugging mode, I used
 >>
 >>      Browse[2]>    setBreakpoint("myfile.R#38")
 >>
 >
 >   What did it print?
 >
 >
 >
 >>   I then typed "c" and "ENTER", thinking that it will continue to
 execute
 >>   until when it comes across line #38 and then stop there...
 >>
 >>   But it didn't work - it continued the execution until the end of the
 >>   function, right at the line "return(results)"...
 >>
 >>   What happened? How to solve this problem?
 >>
 >
 >   One of the complications in R is that you can have multiple copies of a
 >   function in memory.  You may (or may not, what did it print??) have
 set a
 >   breakpoint in one copy, then run another.  Or you may have edited that
 >   function after originally sourcing it, and lost the source reference.
 >
 >   An alternative to using setBreakpoint is just to edit a call to
 browser()
 >   into the function.  It's less convenient, but more robust.
 >
 >   Duncan Murdoch
 >
 >
 >   Thanks a lot!
 >>
 >>          [[alternative HTML version deleted]]
 >>
 >>   ______________________________****________________
 >>   R-help at r-project.org mailing list
 >>   https://stat.ethz.ch/mailman/****listinfo/r-help<https://stat.ethz.ch/mailman/**listinfo/r-help>
 <https://stat.**ethz.ch/mailman/listinfo/r-**help<https://stat.ethz.ch/mailman/listinfo/r-help>
 >
 >>   PLEASE do read the posting guide http://www.R-project.org/**<http://www.r-project.org/**>
 >>   posting-guide.html<http://www.**r-project.org/posting-guide.**html<http://www.r-project.org/posting-guide.html>>

 >>   and provide commented, minimal, self-contained, reproducible code.
 >>
 >
 >

help! what's wrong with setBreakpoint

Thread (7 messages)