It compares my file to the latest version checked into git. How do I compare two files?
You need to use a package. I use split-diff which compares files in tow panes side by side. You need to open each file in a custom pane and then invoke command split-diff:toggle. See package documentation for more info.
Or you may use compare-files package showing a diff of two files
Related
So I use a lot of custom built functions in R which I save in the documents folder in my pc. I would like to bring these functions into my R environment (I usually use source()). At the moment I use the entire file path, i.e. C:\Users\usename\documents\R functions\my_function.r and then create a quick access shortcut link in my project directory to these functions (for easy reference in case its needed). However I was wondering if there is a better way to reference these files. By better I basically mean shorter, or a way to source the files through the quick access shortcut. An alternative to this would be to create a secondary directory so I could just type source("&/my_function.r") (the "&" means secondary directory). This is just a minor inconvenience I think would make life easier if resolved. What do yo think? is this unnecessary complication? Is there anyone in a similar situation as me that has any tips for easily sourcing functions?
Thanks a lot!
If these are functions you often use, you could wrap them in a minimalistic package. Then your call would just be library("myhelpers") and you have all of them available.
Creating this package is quite easy. Assuming you use RStudio, you just:
Create a package: File -> New Project -> New Directory -> R Package
Give it the name you want e.g. "myhelpers"
Specify the folder it should be in
Then RStudio directly creates the package structure for you.
Now you have the package structure in your folder. It will look like this:
- DESCRIPTION
- man
- NAMESPACE
- R
- myhelpers.Rproj
You just have to put your .R files with the functions in the R folder. It does not matter, if the functions are in one file or in multiple files.
Then in R Studio go to the Tab "Build" and click "Install and and Restart". That's it!
Now in your other projects or R files you can just type and use all the functions you put in the R folder:
library("myhelpers")
var <- myfunction1(x)
If you later on want to edit your package functions or add new ones, you can just go to the package folder and click on myhelpers.Rproj and RStudio will open your package project for you. After your changes just click again Build -> Install and and Restart to update the package.
Here is also a short explanation with pictures. This is all you need to use your functions for yourself. The nice thing is, from there you can also go further if needed. E.g. add documentation to your functions. (then you could also have a help() page to your function).
I have two different images which use a lot of common packages. One of them is the wpa-supplicant, which provides a file wpa_supplicant.conf installed by the default recipe. However, I want my own wpa_supplicant.conf to be installed.
I have this solved by having a .bbappend in my layer. But now I only want this append to be applied when I compile one of the images, but not the other.
In short: is there a way to enable/disable a .bbappend depending on the image compiled?
NOTES:
I have seen this answer which is similar, but creating a new package that install my file does not work: many packages will try to install the same file and Bitbake returns error.
The error here is that I cannot install the same file from two different packages, that's why this is not a duplicate of this question IMO.
Thanks!
Well, just as is stated in the answer that you link to, you can't have the image influence any other recipe. The reason is that each recipe is built indepent of which image you're building.
Are the different images intended to be installed onto the same MACHINE? Otherwise you could have different wpa_supplicant.conf for each MACHINE.
For the same MACHINE:
Using ROOTFS_POSTPROCESS_COMMAND is one way to solve this
Add both wpa_supplicant.conf-files (with differing names) andadd a pkg_post_inst_${PN}(){xxx} script to your wpa-supplicant, that during rootfs-creation time, detects which image is being built, and selects the corretct wpa_supplicant.conf.
Another solution is remove wpa_supplicant.conf from the wpa-supplicant package in your bbappend. Create two new packages wpa-supplicant-conf1 and wpa-supplicant-conf2, which just includes the respective wpa_supplicant.conf. Those two should ideally have a
wpa-supplicant-conf1:
RCONFLICTS_${PN} = "wpa-supplicant-conf2"
and for wpa-supplicant-conf2
RCONFLICTS_${PN} = "wpa-supplicant-conf1"
in their recipes.
At our site, we have a large amount of custom R code that is used to build a set of packages for internal use and distribution to our R users. We try to maintain the entire library in a versioning scheme so that the version numbers and the date are the same. The problem is that we've gotten to the point where the number of packages is substantial enough that manual modification of the DESCRIPTION file and the package .Rd file is very time consuming, and it would be nice to automate these pieces.
We could write a pre-script that goes through the full set of files and writes the current data and version number. This could be done with out a lot of pain, but it would modify our current build chain and we would have to adapt the various steps.
Is there a way that this can be done without having to do a pre-build file modification step? In other words, can the DESCRIPTION file and the .Rd file contain something akin to an environment variable that will be substituted with the current information when called upon by R CMD build ?
You cannot use environment variables as R, when running R CMD build ... or R CMD INSTALL ..., sees the file as fixed.
But the no problem that cannot be fixed by another layer of indirection saying remains true. Your R source code could simply be files within another layer in which you text substitution according to some pattern. If you like autoconf, you could just have DESCRIPTION.in and have a configure script query the environment variables, or a meta-config file or database, or something else, and have that written out. Similarly you could have a sed or perl or python or R or ... script doing the textual substitution.
I used to let svn fill in the argument to Date: in DESCRIPTION, and also encoded revision numbers in an included header file. It's all scriptable to your heart's content.
I'm creating an R package and I need it to include a couple of non R script files which get called by one of my functions. I need these script files to be distributed with the package, naturally. So that leaves me with two questions:
a) In which directory of the package
tree should I place these files? b) Is that location mandatory or just convention?
Do I need to change any other
settings or configurations or will
they just get copied to the
directory mentioned in #1 and then I
can figure out the path using
system.file()?
I've tried to find the answer in the Writing R Extensions document, but it didn't jump out at me. And, of course, I didn't read the whole thing. Am I being too honest here?
I think you want either exec/ at the top-level (even though that is labeled 'still experimental, or subdirectory of inst as everything in inst/ gets copied verbatim into the package.
A quick example from the packages I have expanded in source is gdata which has inst/perl, inst/xls and inst/bin. These you could then call from R itself by computing the path of the installed package using system.file().
On windows, I have two source files and want to create a patch with difference, like this one.
But I'm unsure, what format this patch is and what app to use in order to create it? GNU diff output is very different from the patch I can see in the link above.
Try WinMerge. You'll find a patch generator in the "Tools" menu.
Thanks, PhiLho & Lukáš! The diff program from UnxUtils works great under Windows 7 to generate the patch file:
diff -u oldfile newfile >patchfile
Likewise, the patch program from UnxUtils works great to apply the patch:
patch -u oldfile patchfile
The output format is called "unified diff", it can be generated using diff -u.
WinMerge is the best tool for windows.
To create a patch file, you need to do the following:
File>Open
-- Here you open the files for which you are generating patch file.
Tools>Generate Patch
-- Here you specify the path where to save the patch file. And WinMerge will save patch file for you.
WinMerge (http://winmerge.org/) is what you need. You also can compare whole file trees with this tool, which is an absolute must-have for some people.
The UnxUtils package offers lot of useful Unix tools for Windows, with a minimal impact on Windows installation (unzip, add location to path, use it).
It has a diff.exe
In Beyond Compare 4 you can generate a unified diff by selecting the 'Session' > 'Text Compare Report...' menu item and then selecting 'Patch' for the layout and 'Unified diff' for the patch style. Then save the output to file, or to the clipboard.
I've also made a tool to generate patch files (like WinMerge html format) between two sets of changesets/folders/commits (as a zip downloaded from github or azure or just folders sitting in your drive) since currently WinMerge does NOT support path file generation from command-line to support automation.
use it like:
python diff_generator.py --c1 "path_to_file1.zip" --c2 "path_to_file2.zip" [--git]
or
python diff_generator.py --c1 "path_to_folder1" --ddc1 --c2 "path_to_folder2" --ddc2