Problem: Using genstrings to create Localizable.strings files from a project. A few weeks later, some things changed and I run genstrings again. 75% of the new file is already in the old file. How could I merge the new file with the old file, so that the old file contains all of those 25% new key-value-pairs?
I recommend Localizable Strings Merge too. I use it on my projects and it really a simple to use and powerful software.
I just found the Localization Suite. Incredible powerful tool for free. I tried it on my project and it just works. Lacks documentation though.
I use a script to run genstrings with existing translations merged automatically when I build a project. Updated strings are detected by git or another source control you use. The script supports storyboard and xib localization too.
To run the script automatically, put the script into your project root directory, and add a Run Script phase with the following line to a target build phases in your project settings.
./mergegenstrings.py PathToSourceDir
My script is based on the script in this post. I modified it to support Swift and to add the arguments.
What about 3rd party applications like BBEdit? After all Localizable.strings file is a text file. BBEdit has a find differences feature and you can merge from old to new or opposite.
If you install XCode, there is also a standard application installed to merge files called FileMerge.app, you can find it in /Developer/Applications/FileMerge.app
I'm not sure but ReSharper may help you. teake a look at it.
Related
vscode keeps adding a file named .dccache. How can I prevent this?
It messes up the github diffs and I keep on having to add .dccache to the .gitignore for several different projects.
I can't find anything about why .dccache is being created in the first place
It can also be created by the Snyk extension.
I have the same file, I believe this is being created from DeepCode: https://www.deepcode.ai/
This is a code analysis tool to try to find issues. Check if you installed the DeepCode extension in VSCode if you want to get rid of this file, otherwise ignoring it should be fine.
The DeepCode plugins or the CLI is using this file to create a cache for the source code bundles send to the analysis engine. Without this cache, the collection and upload would be very time-consuming.
As it only serves as a caching mechanism, you can exclude it from git uploads and ignore it otherwise.
Snyk extention has a Help&Feedback tab, on the FAQ there is a 'Add custom .dcignore file to your workspace'.
Sometimes git ignore doesn't work for me
I used this file: https://github.com/DeepCodeAI/dcignore/blob/master/full.dcignore.js
just create .dcignore and copy all contents to that. I manually add .dccache and .dcignore just in case.
I had the same issue and when I disabled Snyk extension on VS code editor is disappeared, if you don't have Snyk installed and still have .dccache appearing every now and them, just keep an eye on the other extensions, disable each one at a time and see which one is creating the .dccache file
reccently, I want to test how does the autoscheduler "Li2018" work on GPU. Firstly, I need to load the plugin of this autoscheduler into my project with function "load_plugin("gradient_autoscheduler")" like the example: https://github.com/halide/Halide/blob/master/apps/gradient_autoscheduler/test.cpp but the biggest problem is, that I cannot generate the plugin on Windows. I have tried to add the "generate_autoscheduler" into the CMakeList.txt in the /apps folder, but it can not work. To compare with autoscheduler "Admas2019" which in the folder /apps/autoscheduler, "Li2018" need a CMakeList.txt to generate the dll plugin, Does some one know how to generate the plugin of "Li2018" on windows? Thanks in advance!
As you have noticed, we don't have a CMake configuration for Li's autoscheduler, so Windows is not supported yet. I'll put this in my TODO list, but contributions are always welcome. It shouldn't be hard to come up with a CMakeLists.txt based on the Makefile content.
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
What should I check in/not check in? Since many of the files are sometimes auto-generated I'm not entirely sure how to handle this using version control...does it have something to do with tags?
For instance in ANT, I know not to check-in my target/bin directories...but Grails adds another level of confusion to this...since some of code is generated and some of it is not.
(It may become clearer as I go...but it seems to be that there needs to be some way of being able to tell what was just generated and what was modified by a developer so that it needs to be placed in version control)
Here's the .hgignore directory I've got on my most recent grails project (with a couple of project specific things taken out):
syntax: glob
out
target
logs
*.iml
.idea
*.iws
*.war
workspace.xml
lib/build
lib/compile
lib/runtime
lib/test
~$*
stacktrace.log
*.tmproj
*.launch
reports/
*.orig
*.zip
.DS_Store
*/.DS_Store
web-app/WEB-INF/classes
cobertura.ser
The generated code in Grails should be placed under version control. It's not secondary executable code that is generated by the build process like class files, but instead is code that is part of your source. The generated code is intended to be just a starting point for your application and will most likely be modified at some point anyway.
Also check this:
http://www.grails.org/Checking+Projects+into+SVN
and this:
https://stackoverflow.com/questions/4201578
I have created a web part using VSeWSS 1.3. It creates a wsp file and my web part gets installed, everything works great.
I would like to also create a folder in the LAYOUTS directory of the 12 hive and place a couple files in there. How do I go about doing this? I know that I can manually place the files there, but I would prefer to have it all done in one fell swoop when I uses stsadm to install my solution.
Is there a best practices guide out there for using VSeWSS 1.3 to do this? They changed a bunch of stuff with this new version and I want to make sure I don't mess anything up.
You can create a new folder structure in your webpart project, like:
Templates/Layouts/CustomFolder and put your files in the CustomFolder directory and include them in your project.
When you go to the WSP View in Visual Studio, you can see in the manifest.xml that your files are being included in the deployment.
I have done this successfully on multiple projects now.
In case anyone is wondering, the VSeWSS 1.3 user guide is incredibly helpful. It is installed to the same directory as the tool itself, default in C:\Program Files\Microsoft SharePoint Developer Tools 9.0\VSeWSS13.CHM
You can see a working example with screenshots Here
A simple step-by-step tutorial for the above, along with deploy/retract scripts is here at Add New Files To 12-Hive Through A SharePoint Solution. Just follow the steps and in a few minutes you'll be able to add whatever you want to the 12-Hive!