I'm slowly coming around to using CocoaPods.
I'm confused as to when I should use the ~> operator. Some libraries use it: https://github.com/AFNetworking/AFNetworking, some don't: https://github.com/jessesquires/JSQMessagesViewController.
The only reason I can think of when you should use the ~> operator is when you are concerned a major upgrade will break your system. Is this the main reason?
Or am I missing something obvious?
Yes... ~> will not upgrade to major version.
Look full (and good) explanation here: http://guides.cocoapods.org/using/the-podfile.html
Related
Sorry to bother with basic question.
would like to know which version of any cocoapods, suits particular xcode version. If I know the exact podfile version for my xcode directly can be used without any interruption
I would suggest to save everybody and yourself a lot of trouble and use a fairly recent verion of both xcode and cocoapods.
I had two separate CocoaPods, they're named like this,
4.3.1-test
4.3.1-testBeta
Then I created a third one and named it,
4.3.1-testX
When users users write the podfile like this:
pod 'Podname', '~>4.3.1-test'
It ends up downloading '4.3.1-testX'
Why is this happening? Is it because I pushed '4.3.1-testX' after '4.3.1-test'?
How to solve this? Please help!
Just found the answer to my own question,
The optimistic operator (~>) does not care about the string in the version name (x.y.z-string).
Therefore, even if the strings are different, it will download the most recently pushed pod.
I am following this tutorial
The tutorial states to add libz.1.2.3.dylib. library, but because I have downloaded newer or older library (I don't know exactly if my library is newer or older that the library in the tutorial, but 99% it is newer). So, when I tried to add the libz.1.2.3.dylib. library, I didn't find it. However, when I typed libz I found these choices:
which one should I choose please?
In using dynamic libraries the one you normally use is libX.major_version.dylib in this case libz.1.2.dylib. This is a link to a library libX.major_version.minor_version.dylib which here is libz.1.2.5.dylib
The rationale for this is that the major version is changed only when the API is changed, the minor version is updated when any change is made. Thus your program should work when it uses any of the same major version and so you want the latest version.
In this case the tutorial had an older install and so its libz.1.2.dylib. should have pointed to libz.1.2.3.dylib.
For you you should use libz.1.2.5.dylib which should be like the tutorials version but with bug fixes and possibly extra functions that don't matter here as the tutorial won't call the new functions.
Normally libX.1.x.dylib would be older than libX.2.y.dylib but the writers might produce bug fixes to the old API whilst also working on the new API
Following on from the rational I gave libz.dylib should be a link to the highest number library but I would not use it as you are writing to a particular API so I would use a version specific (In this case if missing a link the I would not trust what libz.dylib points to)
In need to in which version the feature2d module was first implemented. Couldn't find an answer on google. I know that it exists in 2.2, but I wanted to know if it existed already on 2.0 or 2.1.
Thanks
According to OpenCV's ChangeLog, it is first introduced in v2.2.
It looks like 2.2 is the first version with modules, including features2d. You can verify this yourself by examining the source code releases.
After adding the siren gem to my project, it started to give the following warning either running a test or starting rails console:
/Users/{user}/.rvm/gems/ruby-2.0.0-p247#project/gems/methodphitamine-1.0.0/lib/methodphitamine/it_class.rb:14: warning: undefining `object_id' may cause serious problems
/Users/{user}/.rvm/gems/ruby-2.0.0-p247#project/gems/methodphitamine-1.0.0/lib/methodphitamine/it_class.rb:14: warning: undefining `__send__' may cause serious problems
Does someone had the same problem?
I was looking for a gem who could provide Xpath like features for JSON. If someone know another one, i'll appreciate :)
Thanks
That gem is very old (last commit over five years ago). For basic JSON parsing you should us Ruby's built-in JSON support.
If you need more complex data structures (I see that Siren provides cross-referencing), maybe another data format like YAML or XML would suit you better.
If you need to use Siren for compatibility reasons, it's probably more compatible with an older version of Ruby.