I have the latest version of Swiftlint (via brew). When I check github, I see that they have added a bunch of rules since the release, even a few a couple of days ago. How do I get those rules onto my mac? Do I have to uninstall the version I have and reinstall the same version? (will that even get the new rules?) Do I have to download the zip from github?
Use brew update. But some of the new code is not yet in the release branch. For the dev-branch you would need to pull the newest version manually. It is a shame that the new documentation on rules is so poor, because i ran into the exact same problem.
I would suggest waiting until the rules are in release branch and are deployed by brew. Sometimes those rules can be buggy and are not reliable.
An alternative to brew update is to integrate SwiftLint using CocoaPods, and in that case you would update it with pod update.
I recommend the CocoaPods approach as it garanties that all co-developers get the same errors (and warnings), and avoids situations were one developer doesn't get any error, pushes code and confronts another developer to build errors.
Related
I'm trying to build a Yocto image for a AWS Greengrass Core Device using meta-aws layer. I'm really new to this topic, so I already stuck at the very beginning... It seems as there are compatibility problems of meta-aws with older Yocto versions.
I've already created an image for my hardware (i.MX8MP processor) and this is running fine. The Yocto version I'm using is Hardknott.
Now I would like to add the AWS features. Hence I've cloned meta-aws layer to my source directory and checked out branch "hardknott" and also added the layer to my Yocto project. But when I try to bitbake the image, I always get parsing errors in severel recipes of meta-aws. The problem is, that in many recipes the "new" override syntax ":" instead of "_" is used, which was introduced with Honister.
I'm really wondering about this, as there is an explicit branch for Hardknott. Why is this branch using a syntax which is not compatible with Hardknott?
Could anybody explain this to me and may have a solution to this?
I already searched in the web, but information about intergrating meta-aws to Yocto project is really rare.
Thanks a lot in advance!
Huh. Well, that's inconvenient. A glance at the repo looks like they updated many of the recipes in the Hardknott branch of meta-aws, but some of those newer recipes use the new syntax, which would break the build as you describe. I'd submit this as an issue to the repo. Otherwise, fix the syntax yourself until it builds. If there are multiple versions of the recipe available perhaps try using PREFERRED_VERSION to select an earlier recipe that may have the correct syntax.
I'm trying to compile the examples under cpp starting with minimal_build. I don't have much cmake experience. Must this be run under docker, or can it just be compiled in a Linux shell? I'm running Centos7 on a AWS EC2 instance, and I've installed cmake 3.20.2. Executing sudo ./run.sh, errors immediately with "cd: /io: No such file or directory". When I try and make what I think are the necessary changes to the scripts, I keep hitting errors. So I just want to see is this is even possible before proceeding further.
Thanks.
Yes, it is possible. I recently built Arrow on CentOS 7. With any C++ project there are going to be challenges switching amongst Linux distributions. The docker image is a way to provide a single example that the Arrow project can verify. You will need to adapt your Linux environment based on the issues you encounter. #Tsyvarev is also correct, you will want to use run_static.sh instead of run.sh. In order to do this you will need to dive a bit further into the details.
The build script has two steps. First, it will build the Arrow project itself. This is probably going to be the more challenging step. This guide is helpful for this step and provides a lot more detail into how Arrow builds and what options there are. The second step will be to compile and build the example.
Specifically for CentOS 7 one of the challenges you will face is that you will need a newer version of CMake. I ended up building CMake from source. If you go this route you also need to make sure that CMake is built with curl/https support. I used the --system-curl option for this.
That is all I remember having to do special for CentOS 7 at the moment. As you go about this task if you run into further, more specific, issues, feel free to ask them here or on the Arrow dev/user mailing list.
I made a laucher application in c++ that use direct 2d and 3d. Now i making a installer for this. I followed microsoft docs and i made it but there is a issue.
I use 'Microsoft Visual Studio Installer Projects' extension to make that.
The issue is if i already installed my launcher with a previous installer msi file, if i rebuilt a new installer msi and try to run it it show me this error
This is the microft docs i followed to make this: https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=msvc-160
In the future maybe i need make a update for my laucher. It isn't good idea everytime need go to control panel, search and delete the previous application and install the new one manually.
Anyone know how can i make it automatic remove old version and install new one? Maybe there is a better way to create a installer?
Major Upgrade: In order to upgrade properly, you need to use a major upgrade so that your new version uninstalls the old one and then installs itself (this can happen in reverse order too: new version installed and old remnants deleted afterwards, but this is another story). There are further upgrade types, but stick to major upgrades for simplicity.
The message you are receiving is basically because you have a different package code for the new MSI, but not a new product code or version number (or just one of those problems). You need to get the settings straight.
Recommended step-by-step:
Set "RemovePreviousVersions" to True in the project properties.
In the same place: bump up your version number (one of the first 3 digits)
Answer yes when asked to change product code, or do so yourself manually.
Keep the UpgradeCode the same - it needs to be stable across releases.
Rebuild your setups. Clean out your box of old remnants before testing or test on a virtual.
Testing: Remember to simulate your full upgrade process from first version installed to the new one with different version numbers for a few core files and also try to add a few files and such things. Very important to verify.
Heads-Up: Before ending, it is standard procedure to warn about the potential limitations of VSInstaller Projects (shorter list form).
MSI Tools: Here is a short "review" of other MSI tools.
MSI Upgrade Types: Shamelessly stolen from the InstallShield help file (towards bottom):
Today after updating our projects it seems Xunit.KRunner is no longer available on NuGet. We checked the Microsoft projects and it looks like they are using the xunit.runner.kre package. When trying to install this the xunit.assert assemly is failing to download from Nuget. Any suggestions to get this working? I am guessing that the versions are messed up.
Here are my nuget package locations:
I'm also using the beta2 version of the kre.
There is/was an issue with the new xunit.runner.kre and VS CTP 5. See below discussion:
https://github.com/aspnet/Testing/issues/65
xunit.runner.xre is available only on myget/vnext feed. Include that in the Nuget.config that you should be able to restore the package
By running on the beta2 kre you're then having mismatched dependencies. If you look at the versions of your xunit bits they're all beta3. I'd recommend upping your kre to beta3 to fix your issue (will affect which packages your app pulls in).
Also as a side note I'd recommend ensuring your nuget.org/api/v2/ feed is enabled (in the SS you posted it wasn't). There's currently an issue where it'll occasionally disable itself; has definitely made my life frustrating several times when things don't build :).
Django 1.6 disabled the formerly automatically enabled sitesframework. This introduced a bug in the views section of admin docs.
The maintainers have already fixed and closed it
https://code.djangoproject.com/ticket/21386
I have a fresh pip install of 1.6, but the error is still present. My guess is that the fix is currently not built into the latest stable available over PIP?
My question is: What way would you suggest to get that fix into my running setup? (If possible I'd like to leave it on PIP instead of checking out django directly from Github)
Solution from the maintainers
If someone stumbles upon this issue see bouke's reply on the official ticket:
https://code.djangoproject.com/ticket/21386#comment:8
Setting SITE_ID=None in your settings.py solves the error.
This was fixed in the master branch, which is the place where development toward the new major 1.7 release happens. This means the problem will be fixed in 1.7, but the version is not out yet, and won't be for the next couple of months.
You may try asking the Django team (politely!) to backport the change to the stable/1.6.x branch, since its not a new future, but just a fix for a problem in 1.6. Changes in this branch will be included in the minor 1.6.2 release, when it comes out.
My question is: What way would you suggest to get that fix into my
running setup? (If possible I'd like to leave it on PIP instead of
checking out django directly from Github)
You will not find a version with the fix in the Python Package Index (used by pip), as long as a stable release which includes the change doesn't come out.
Here are some options:
Wait till a new stable version with the fix comes out.
NOT RECOMMENDED: You can install a current development version of Django from the master branch. This would solve your particular problem, but would be absolutely insane and most likely would introduce all kinds of other problems.
You can get the 1.6.1 stable version from git, and then try to manually cherry-pick the change from the master branch. It's quite likely this won't work or at least require some additional manual changes, since the change was not originally intended for the 1.6.x branch.
If you get the team to backport the change to the 1.6.x branch you can run Django from this branch. I wouldn't do this in production, but it is much safer than running from master. This of course would be a temporary solution, before a new minor 1.6.x version comes out.
If you get the team to backport the change to the 1.6.x branch, you can get the 1.6.1 stable version from git, and then manually cherry-pick the change from the 1.6.x branch.