Currently the only way to debug in RTVS is to first attach the debugger and then source the file, as shown in this official manual. However, this is rather inconvenient, since my script usually expands to hundreds of lines and it will take forever for the debugger to execute to the breakpoint, which usually at the last of the script.
The only workaround I can come up with now is to comment all the above lines before the codes of interests. But, is there any elegant way to achieve that?
So far there is no shortcut for it yet, to debug the certain line in R, we still have to launch the debugger with the code in script.R by either selecting the Source startup file button on the toolbar, selecting the Debug > Source startup file menu items, or pressing F5. Visual Studio enters its debugging mode and starts running the code. It stops on the line where you set the breakpoint:
https://learn.microsoft.com/en-us/visualstudio/rtvs/getting-started-with-r#debugging-your-code
Related
I have a C# WPF project that uses System.Console.WriteLine for debugging and in Visual Studio we can see the output in Output window.
I would like to move to JetBrain's Rider, but the Console output is not shown in the Debug Output window, unlike the output from System.Diagnostics.Debug.
I understand that I should've used System.Diagnostics to begin with and would be willing to brute force replace all calls in my code, but I'm wondering, if there is a setting in Rider that could spare me the hassle ...and discussions with colleagues ;o).
I want to make an executable R-file (for automation purposes). Therefore I concluded the following tutorial.
After completion however nothing happens... Only the .Rexec file opening in RStudio (in stead of running it and showing me the pop up...
Any more people experienced this? Any clues to where to look to fix this?
The tutorial you gave is useful. However, it missed something.
After done all the things in that blog, you still need to do one more thing. Right click on the "test.Rexec" file and choose "open with" and then select "RScript". Maybe you need to find RScript in your system which is usually here:
C:\Program Files\R\R-3.2.1\bin\Rscript.exe
Remeber to check the "Always use the selected program to open this kind of file".
Next time, when you double click the "test.Rexec" file, evethying would be okay.
I found no need to create Rexec file.
I created .bat file and then set it up in Task Scheduler.
The .bat file opens up the Rscript.exe, as shown in prev answer above. The .bat file then points to the .R file, that I want to be executed.
For some time, I could not get it to work, but solution was to point to Rscript.exe as mentioned above. Then it will not open up in compiler.
Works fine for me.
Maybe I got simple questions so I googled it but I can't find answer.
I am using Pydev/Eclipse and I want to run the script within Console.
First I want to modify the startup of the session - it means some modules are loaded during start (math, numpy, scipy, etc...).
Where/how can I modify Pydev Console startup?
Secondly, I execute the script using righ-click on script file and "Run as -> Python Run" then it's executed within console and terminated. So I want to stay within Console and to be interactive and not be terminated.
How can I get such feature?
Thank you!
Best regards,
Peter
The startup configuration can be found in the PyDev preferences menu. The preferences can be found in the upper menubar under 'Window'.
Window -> Preferences -> PyDev -> Interactive Console
There you will find a big text input field with a label 'Initial interpreter commands'. Often it is allready in use and imports sys only to print the name and version number of the starting console.
The only solution I am aware of for staying connected with your script is to set a breakpoint at the end and start your script in debug mode. But maybe there is another way. To do so just double click at the left corner of the editor window with your script opened. A green dot will appear marking a breakpoint. Now right click an choose 'Debug As'. Your script will run till the line is reached where you have set the breakpoint.
Hope I could help.
I think that what you want is the interactive console. See: http://pydev.org/manual_adv_interactive_console.html
You can configure the initial commands in the preferences page.
I am not able to set breakpoint in my program when debugging with CDB while the process is running. When I made a click on the left of the source line to set the break point, I got a red breakpoint with a busy status indicator on top of it. The busy indicator never goes away as expected. If I set a breakpoint prior to starting debugging, they will be applied successfully.
If I select Debug->interrupt from the menu while the process is running, QT Creator is not able to pause the process either. Therefore, I believe the cause of the problem is that QTC is not able to pause the process and apply the breakpoint.
If I use GDB, everything is fine. But I don't like to use GDB due to its much slower compiling speed.
Please check if you have the debugging tools for windows installed on your machine.
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
Check if CDB finds the microsoft symbols.
Go to Tools >> Options >> Debugger
Check if the following path is present in Symbol Paths Text field:
C:\Program Files\Debugging Tools for Windows (x64)
symsrv*symsrv.dll*C:\Users\vish6025\AppData\Local\Temp\symbolcache*http://msdl.microsoft.com/download/symbols
If it's your operating system is 32 bit, You point it to
C:\Program Files\Debugging Tools for Windows
I tried using freopen() to redirect the "cout" function to the console, but it doesn't produce the desired effect. Instead of just double clicking on the executable and having the console show it's message, I need to use a command prompt or a batch file, and that's a problem, because I want the user to be able to close the console after the message has been displayed without closing the SDL window. This is supposed to be a console application. I apologize if I am not clear enough.
If using freopen() doesn't work the SDL Console FAQ gives a tutorial on recompiling the SDLmain library that is relatively easy to understand, especially if you already have MSYS and MinGW installed. You can use the resulting SDLmain library instead of your current one and it should work (It did for my project).