Console My ## tag is not changing color, what can I do to change that?
I have tried looking for a solution in my settings, but there has been no luck.
The console isn't a place to make and keep notes. The console isn't something that gets saved, so if you are trying to add notes to a script, you probably want to create a new script.
In R itself, I am not sure if or how you have notes (in scripts) change colors, but this happens automatically in some "Integrated Development Environments (IDE)", such as RStudio. For learning how to use R, I would recommend downloading RStudio. When you create a script there, your comments starting with # will automatically be a different color than code.
Related
How can I turn of the report generation in OpenMDAO 3.17?
I've tried add the following code to the top of my script:
import os
os.environ['OPENMDAO_REPORTS'] = 'none'
In place of 'none', I've also tried '0', 'false', and 'off' as mentioned here in the OpenMDAO documentation. This is the only way I've seen to change the environment variables.
Are there other ways to permanently change them such as through the command prompt? I'm relatively new to python, so spelling it out for me would be helpful.
Also, I know this is a repost, but I don't have enough points to add a comment to that post. So I've had to create a new post. That post also mentioned a PR, but the summary indicates the report generation was only fixed for some Dymos functionality.
When you change the setting via a python script (as your question shows) you are only changing it for that active python session. Not permenantly.
You don't say whether you're on windows or linux, which changes the specific method you would use to achieve your goal; Generally though, you can set the environment variable so that its given whenever you open a terminal. This will have the effect you desire.
On windows, you set environment variables via a small system GUI. On linux you change them by adding a line to a config file (usually .bashrc). On Mac the file name is sometimes .bash_profile or .profile.
I couldn't get them to switch off via environmental variables, whether setting them in the python script or from the terminal, but when creating the problem this worked
p = om.Problem(model=om.Group(), reports=False)
When closing R Studio at the end of a R session, I am asked via a dialog box: "Save workspace image to [working directory] ?"
What does that mean? If I choose to save the workspace image, where is it saved? I always choose not to save the workspace image, are there any disadvantages to save it?
I looked at stackoverflow but did not find posts explaining what does the question mean? I only find a question about how to disable the prompt (with no simple answers...): How to disable "Save workspace image?" prompt in R?
What does that mean?
It means that R saves a list of objects in your global environment (i.e. where your normal work happens) into a file. When R next loads, this list is by default restored (at least partially — there are cases where it won’t work).
A consequence is that restarting R does not give you a clean slate. Instead, your workspace is cluttered with existing stuff, which is generally not what you want. People then resort to all kinds of hacks to try to clean their workspace. But none of these hacks are reliable, and none are necessary if you simply don’t save/restore your workspace.
If I choose to save the workspace image, where is it saved?
R creates a (hidden) file called .RData in your current working directory.
I always choose not to save the workspace image, are there any disadvantages to save it?
The advantage is that, under some circumstances, you avoid recomputing results when you continue your work later. However, there are other, better ways of achieving this. On the flip side, starting R without a clean slate has many disadvantages: Any new analysis you now start won’t be in a clean room, and it won’t be reproducible when executed again.
So you are doing the right thing by not saving the workspace! It’s one of the rules of creating reproducible R code. For more information, I recommend Jenny Bryan’s article on using R with a Project-oriented workflow
But having to manually reject saving the workspace every time is annoying and error-prone. You can disable the dialog box in the RStudio options.
The workspace will include any of your saved objects e.g. dataframes, matrices, functions etc.
Saving it into your working directory will allow you to load this back in next time you open up RStudio so you can continue exactly where you left off. No real disadvantage if you can recreate everything from your script next time and if your script doesn't take a long time to run.
The only thing I have to add here is that you should consider seriously that some people may be working on ongoing projects, i.e. things that aren't accomplished in one day and thus must save their workspace image so as to not start from the beginning again.
I think, best practice is: its ok to save your workspace, but your code only really works if you can clear your entire workspace and then rerun it completely with no errors!
I am new to the use of version control in RStudio. I would like to know what is the optimal way to do this:
I have a R project, and I can give one version of the project to a coworker.
Then he will modify some files (and me too).
When he gives the folder back to me, is there is simple way to compare two files and decide which which lines go to the final version?
The usual workflow for comparing files using builtin Rstudio is through version control tools such as git or subversion.
Your process is more "I give you the content of the project folder, make whatever you want and give it back to me" then "you want to know what have changed between your copy and his".
Rstudio won't help you in this case. You'd better use merge tools such as meld, winmerge, .. that will spot the differences between files and their content and allow you to copy changes in either way (from you to him or him to you)
I would like to access the history of what have been typed in the source panel in RStudio.
I'm interested in the way we learn and type code. Three things I would like to analyse are: i) the way a single person type code, ii) how different persons type code, iii) the way a beginner improve typing.
Grabbing the history of commands is quite satisfying as first attempt in this way but I would like to reach a finer granularity and thus access the successive changes, within a single line in a way.
So, to be clear, I'm neither looking for the history of commands or for a diff between different versions of and .R file.
What I would like to access is really the successive alterations to the source panel that are visible when you recursively press Ctrl+Z. I do not know if there is a more accurate word for what I describe, but again what I'm interested in is how bits of code are added/moved/deleted/corrected/improved in the source panel but not necessary passed to the Console and thus absent from the history of command.
This must be somewhere/somehow saved by RStudio as it is accessible by the later. This may be saved in a quite hidden/private/memory/process/... way and I have a very vague idea of how a GUI works. I do not know it if would be easily accessible, then programmaticaly analyzed, typically if we could save a file from it. Timestamps would be the cherry on top but I would be happy without.
Do you have idea how to access this history?
RStudio's source panel is essentially a view to an Ace Editor. As such you'd need to access the editor session's editSession and use getDocument or getWordRange along with the undo of the editSession's undoManager instance.
I don't think you'll be doing that from within RStudio without hacking on the RStudio code unless the RStudio Addin api is made to pass-thru editor events in the future.
It might be easier to write a session recorder as changes are made rather than try to mess with the undo history. I imagine you could write an Addin that calls a javascript to communicate over the existing RStudio port using the Ace Editor's events (ie. onChange).
As #GegznaV said, RStudio saves code history to a ".RHistory" file. It's in the "Documents" folder on my computer. It's probably the same folder if you're using Windows. If you do not know the location, you can find the file by searching.
It also allows saving RStudio history to a file manually. There is a "Save" button in the History panel. So you can also get a timestamp. You can ask different users to save their code history after they have finished writing code. It may be indirectly useful to your research.
I'm a little new to Grunt and am using it in our automated build system (on Windows). When running Grunt manually in the console, the coloring is extremely helpful. However, when running it in an automated setup, it results in color information in the build log, like this:
[4mRunning "sass:all" (sass) task [24m
The extra characters decrease the readability of the build log and I'd like to get rid of them.
I'm aware of the grunt.log.uncolor method for individual strings, but I'm wondering if there's a way to configure Grunt to output all logs without color information or if there's an existing plugin to do this. If not, I'll likely write my own plugin.
I feel like this would be a common occurrence — using Grunt in an automated system where you'd want to read the build log as plain text — so maybe I'm just missing something.
Of course, I finally find the answer right after asking the question...
Use the simple command-line option --no-color.
I was scouring the API but somehow missed the "Using the CLI" section of the documentation.