Skip to content

help! what's wrong with setBreakpoint

7 messages · Michael, michael.weylandt at gmail.com (R. Michael Weylandt, Duncan Murdoch

michael.weylandt at gmail.com (R. Michael Weylandt
# 
A function is a parsed object stored in memory; your edit applies to the source, but not to the memory object being executed. There is no way, to my knowledge, to use browser to alter the execution flow of an function once it's going (other than changing values of course). You need to edit the function definition to put the breakpoint where desired and then reread and rerun the function. 

Michael
On Dec 5, 2011, at 10:32 PM, Michael <comtech.usa at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 11-12-05 10:32 PM, Michael wrote:

            

      
      
      
    

        
What did it print?

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

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

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 06/12/2011 11:11 AM, Michael wrote:

            

      
      
      
    

        
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