I have an R script that doesn't throw what I expect it to. However, it does run all the way through. To fix it, I've tried setting a breakpoint in order to enter debug mode.
But when I do this, I get an error that says:
debugSource('~/mycode/konfio/Projects/Interest Rates/src/getPARS.R', echo=TRUE)
Error in if (length(funBody[[idx]]) != length(originalFunBody[[idx]]) || :
missing value where TRUE/FALSE needed
I've Googled this error, but only found one link which didn't help. If anyone knows how to get my hands on the Debugger, or somewhere else that I can search for the problem I'll be grateful.
Thank you.
RStudio's breakpoints work by rewriting your function to include debug code. The most likely cause of this problem is a bug in RStudio that's causing it to fail to rewrite your function. There are a few possible solutions:
Remove just the statements you want to debug and put them into a separate function. Set the breakpoint on that function and call it from your main script.
Use browser() based-debugging: just add browser() where you would have set a breakpoint (RStudio's debugger works with R debugging features, too).
Use a newer version of RStudio. Debugging R scripts (as opposed to functions) has improved a lot lately, and if you're feeling especially brave you can try a daily build.
If you have time, please post the contents of the file you're having trouble with to RStudio's support forum; we'd like to take a look and see if we can make a fix in an upcoming version.
Related
I am using PyCharm as Python IDE and debugging tool. Just upgraded to 2020.1.2.
Occasionally, while stepping over in debugger, it skips a line in a function which normally should be executed. I tried to a lot of fix it, like re-editing the function, format the code etc., without any luck. Only one route that is promising is to define another function as proxy only to call this problematic function, but this is really what I am not going to do because that makes the code so clumsy. If I copy this function into another new .py file and debugging stepping over it, it can be quite normal. I have got no clue what goes wrong except the chances are PyCharm has a bug.
Anybody same with me? Any solutions? thanks!
It might be related to this issue.
Try adding this environment variable to your run configuration:
PYDEVD_USE_CYTHON=NO
Various things are different in 1.0.136, e.g. running code with ctrl-enter has all sorts of strange behavior in an RMarkdown document, running code that has a syntax error somehow leads to all of the code being run in a block above (below?) the wrong code, etc. Sorry for not posting an MWE, but at the moment I just want to know if anyone is aware of these new "features" and if so how they can be turned off or better yet how I can just downgrade to the previous version of RStudio (which I can't currently find on the website).
Yes they changed some default settings that were present in the old interface.
Change the setting in markdown next to the knit button, from:
Chunk Output Inline -> Chunk Output in Console
Pictured here.
You can probably mess with the the Global Setting->Rmarkdowns under Tools to get it back the way it was before, but this was the fastest way for me.
I was debugging a GoLang program. I set break points and run the debugger. But the break points only works the first time I run the debugger and failed in the second, the third, and all following debugging whatever I do. I cancelled them and reset them, I close the debugging window and open a new one, I change the settings in the "Breakpoints" tool window. All these didn't work at all.
What's the problem?
Update, this has been fixed in the latest release of the plugin, please check it out
This is a well known problem and it lies in delve not the plugin itself. Please see this this issue for further reference.
When working on a large Firefox plugin, I sometimes accidentally make a syntax error not caught by my editor. When this happens, then calling
Components.utils.import("resource://modules/Foo.js")
will simply fail to import or return anything, without any kind of helpful hint as to where in the file to look for the syntax error. Is there any way I can get Firefox to give me some kind of clue when my imports fail?
EDIT: I fixed my own problem, which turned out to be that I was using code which had a global reference to the navigator object. What made this especially annoying was that the code would work when loaded in the browser (as Wladimir suggested below), but would still fail when importing in my extension.
Eventually I resorted to a sort of manual binary search: I'd delete half of the file and then see whether the import still failed. If so, then I'd delete half of what remained and repeat. As soon as it didn't fail, I had a more precise notion of where the problem was, which allowed me to either continue the binary search or scan the smaller area manually looking for the problem.
This is extremely time-consuming and I'd still appreciate any suggestions about how to speed up this debugging process.
The issue here is most likely the one described on https://developer.mozilla.org/en/Exception_logging_in_JavaScript and setting dom.report_all_js_exceptions preference to true should work. I must admit that I haven't tried that however because setting this preference makes the error console very noisy. Instead I use an ugly hack and load the module as a script in a local HTML file - this is enough to show me syntax errors and fortunately isn't something I need to do all too often (it is only an issue with syntax errors, runtime errors are reported as usually).
I’m having trouble to find a bug in my application.
The problem is random and don’t throw any error. The web site just keeps loading and loading and eventually gets a timeout.
Is a web application using MVC 3 in VS 2010 Pro.
Some time ago, I see a friend to write something in the url, and gets all the trace of the program…
Sadly, I don’t remember what the command was.
Anyone has an idea of what command is it?
Any suggestion on what to use to debug?
Thanks!
Edgar.
UPDATE!
I finally found the command... is trace.axd
But Its behave the same way... sometimes load without problems and show me all the trace info... and sometimes.. it keep loading and loading...
Maybe something related with IIS?
Turn on break on every thrown exception, run your application in debug mode and wait. If it executes too long then pause application and check where you are or wait for exception that is handled somewhere.
Your friend may have had something like the following built into his application, to dynamically set tracing on.
Trace.IsEnabled = Request.QueryString["trace"] != null ? true : false;
This provides info only if the page is fully loaded. It's probably best if you use the VS debugger to step through code.
If all you loops look ok, investigate code that could result in circular references or deadlocks. These can be difficult to spot sometimes, look for functions or constructors that require results from a calling class. So code that needs the result from a function which in turn need results from the first.
Well, this sounds like you have an infinite loop somewhere.
Look at the code that runs when you visit the URL that gives you trouble. See if there is any loops in there (for/while). If yes, see why if they never exit. You can do this by putting a breakpoint inside the loop and examining its behavior over the iterations.
in MVC the bugs you do not see are most of time (especially in Razor and Ajax work) view compile errors. Sometimes syntax bugs on views just does not show that view and do not stop working.
Try that:
put a breakpoint in view.
If program stops in there it means this view is working. Othervise there is a syntax error in this view.
Another way to see some bug information more than in visual studio is use browser tools.
I use google Chrome. Just open developer tools in it. Open network. And do your request. It will list the requests and responses. Click the response and see the information. After style (it is written Verdana etc) read exception details. Sometimes there is more information :)
I am using MVC 3 in Razor from start. So this is a small bug in asp.net mvc.