The R Gui app on my Mac has been showing strange behavior lately. Whenever I use curser-up to get an item from the history, the App will add an empty line before the code. For every time I execute and re-call, it will add another. Below a screenshot of how that looks like.
Does anyone know how to fix this error, by any chance?
Related
I often code functions in the following way by creating a basic function, entering debug mode, and then writing the function in debugmode. E.g.,
myfun <- function(x) print(x)
debugonce(myfun)
myfun("test")
The benefits of this is that I can get real time feedback on whether my code is working with the arguments passed to it.
However RStudio appears to have recently changed it's behaviour to make this more difficult. I recently upgraded to 2021.09.0 Build 351.
Previously, it would open the Source Editor when you call this command.
But if you closed this screen, you could return to your code, edit the code, evaluate code, and so on without the viewer re-appering.
However, now it seems to reappear every time you evaluate your code.
For instance, if I close the viewer, go back to my main script, and evaluate x, the Viewer opens back up.
This is super annoying for someone used to editing and evaluating code while in debugmode using the source script file.
Is there any way of entirely disabling the Source Editor view in Rstudio? Or alternatively, is there a way of being able to edit and evaluate code without the Source Editor constantly re-appearing in Rstudio (like how it used to work)?
My current fix is to downgrade to Version 1.3.1093, where you could edit and evaluate code without the Viewer constantly re-appearing. But it would be a shame to miss out on future upgrades.
This issue was principally a bug that has now been fixed.
At time of posting, downloading a daily build fixes the issue, but eventually this fix will be incorporated into beta and standard builds.
https://github.com/rstudio/rstudio/issues/9943
I recently have encountered an issue in debugging package code in RStudio. Suppose I have a function in source file, say foo.R, and set a breakpoint in the body of that function. Then when I run something in the console that reaches that breakpoint, a second copy of foo.R shows up in the code panel, and it pops to the foreground. The line where I had set the breakpoint is highlighted in the new view, but the red dot shows up in the first copy. This is driving me crazy because it happens with every single source file and makes a mess out of my code window.
Moreover, if I make changes in the first copy of the file, rebuild, and don't close the debug copy, then the changes are not shown in the debug copy if I still have active breakpoints. This is very confusing.
Here's an illustration of what I see after I entered a call. The first version of the file has the red dot; and you can see the tab for the second copy:
The second copy of the file is where debugging is displayed:
And this is what I had entered in the console:
I had the idea that this might v\have something to do with its immediately going from Browse[1] to Browse[2]. However, I tried debuggingState(on = FALSE) and that doesn't make a difference.
This is not a bug I am able to reproduce. If I switch to a different project, this doesn't happen. It's apparently some setting in my project that got messed-up.
I figured this out. My setup maps a drive letter H: to a path I treat as my home directory. That means there are two different versions of the file path for any file in that mapped directory. The duplicate files were created in the other version of its path. I re-loaded the project from the path it wanted to use, and that solves the problem!
We are using Progress OpenEdge 10.2A for years and for the last 4 months we begin to receive unknown error messages from our customers.
We call our .w files using lines as follows:
RUN VALUE(myPath + "myProgram.r") PERSISTENT SET myPrograms[i].
Normally the same program calls work without any problem, but on rare occasions, the program window seems to get unresponsive, but in fact when we look at the windows taskbar, there is another entry in the taskbar which is a prowin32.exe window having title "Error". But when selected, there seems to have no visible window attached to it.
When we close it from the taskbar using Close Window option, it appears again in the taskbar 6-7 times again and then whole prowin32 session restarts.
We could not identify the error since it does not show any message or any error number.
If you encounter such a problem, I'd like to know how you solved it.
If not, it would be appreciated if you direct me to the way to solve the problem.
Edit 1:
After adding -errorstack -debugalert -clientlog myLogFile.log to my startup parameters, myLogFile.log is generated. The below part is written when the error occured.
**Unable to realise TEXT myText. (4025)
** ABL Debug-Alert Stack Trace **
--> enable_UI c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 21014
c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 14858
USER-INTERFACE-TRIGGER c:\myFolder\myFile2.r (c:\myFolder\myFile2.r) at line 2905
0) OpenEdge 10.2a is ancient, obsolete and unsupported. You should have moved to a modern release 10 years ago. At the very minimum you should be on 10.2b08. Do you also refuse to update Windows? OpenEdge 12 is the current release. It is possible, perhaps even likely, that unanticipated changes in Windows or other aspects of the environment are causing your problem. Progress is never going to update 10.2a to accommodate that sort of thing. You are just prolonging the agony by staying on an obsolete release.
1) What changed in your code or your environment 4 months ago?
2) You can get a stack trace for the extra prowin32 session by running proGetStack. That should help to explain what was launched, what the error is and why another 6-7 start after you kill it. Open a "proenv" window as "Administrator" and run proGetStack (you can get the process id from taskmgr).
proenv> proGetStack 123456
The stack trace will appear in the working directory of the target process. That is usually the same directory that proenv is in but it is possible that the application changes it so you might have to go hunting for it. (Administrator proenv windows sometimes do not start in %wrkdir%, you may also need to cd /d %wrkdir%)
3) If they are not already present you should add -debugalert and -errorstack to your client startup parameters. -clientlog logfileName.log would probably also be helpful.
4) Examine your code base for bits that invoke prowin32 sub-processes. There are many ways to do this such as OS-COMMAND, INPUT THROUGH or via Windows DLL calls. Directly invoking prowin32 can be found by searching for that string but it might also be indirect invocations via a BAT file or other technique.
5) if you have a repeatable way to produce the error then you could also add the 4GLTrace log entry type either at startup or in the code when you get to the proper point: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpspr/log-entry-types-(-logentrytypes).html
I am currently programming my first shiny application and I am having some difficulty with some of the more subtle user interface features. I am using the tcltk library to import a number of simple dialog boxes for the user to select local directories and files (the application is only going to be run locally so I will not be using shiny's fileInput commands). This also has the advantage of not being OS specific like the choose.dir command (see R Windows OS choose.dir() File chooser won't open at working directory for more discussion on that).
However, when I'm working in Windows (I'm testing on Windows 10 although I do most of the development work in Linux), I'm finding that calls to tkchooseDirectory only opens up the dialog box behind the shiny application, if I'm running a shiny application, or behind the RStudio IDE if I'm just calling it from the console there. This doesn't seem to be a new problem: http://r.789695.n4.nabble.com/tkchooseDirectory-opens-dialog-below-browser-window-td4729500.html but I haven't seen any solutions yet.
For my development work with the RStudio console then this is a minor nuisance but, given that the shiny application will be eventually be delivered to the client (a state agency), I would really rather not aggravate them with dialog boxes being hidden by the application.
Thank you for any help that you can provide!
[edit 1] Further information: it appears that when calling tkchooseDirectory from the RStudio console, only the first call to tkchooseDirectory results in a dialog box being displayed behind the application. Subsequent calls place the dialog box to the top of the display as expected. Also, this behaviour does not happen in the R for Windows GUI and seems to be something perculiar to RStudio and its associated products.
[edit 2] It appears that others have experienced similar problems with other tcltk library dialog boxes too: MessageBox in R
[edit 3] The easiest minimal example to see this is by running:
library(tcltk2)
tkchooseDirectory()
in the RStudio console on a Windows 10 system.
So, I don't think there's a direct solution to this unfortunately ...
One option is to raise a toplevel window and then the directory dialog on top of it (you have to run everything at once here, otherwise the root is in the background again).
library(tcltk2)
root = tktoplevel("width" = 1, "height" = 1)
tkraise(root)
tkchooseDirectory("-parent", root)
Another option would be to use gWidgets.
dir_ <- gWidgets::gfile(type = "selectdir")
I found it best to pause using Sys.sleep briefly prior to opening the dialog:
root = tktoplevel("width" = 1, "height" = 1)
tkraise(root)
Sys.sleep(1) #pause just a little for dailogs
selectedDir <-
tclvalue(tkchooseDirectory(
initialdir=getwd(),
title="Select directory"))
tkdestroy(root)
I am trying to configure Console2 to use the R terminal.
I created a new tab named "R" and under the shell directory I linked it to:
...\R\R-3.1.3\bin\x64\R.exe. Console 2 just hangs for a few seconds and then reappears in the corner of my desktop with the window completely resized as small as it will go. You cannot resize it in this state - it just jumps back. The only option is to quit.
If I instead link to ...\R\R-3.1.3\bin\R.exe it works fine except that if I alt-tab to another window and then return to the terminal I am unable to type anything in R tab for Console2 or delete previously typed characters. It's completely unusable and I have to restart.
Is this a bug or am I doing something wrong?
This is something I've been experiencing myself and it seems to be a bug - it happens with most other shells I used under Console2. The only solution that worked for me was to use a modified version of Console2 called ConsoleZ, which is found under: https://github.com/cbucher/console - it has many other useful options and it's more actively developed. Hope it helps.