$ brew install ruby
$ gem install cocoapods
$ gem env
add /usr/local/Cellar/ruby/2.0.0-p0/bin to $PATH
$ pod setup
$ brew install ruby
$ gem install cocoapods
$ gem env
add /usr/local/Cellar/ruby/2.0.0-p0/bin to $PATH
$ pod setup
#pragma clang diagnostic push | |
#pragma clang diagnostic ignored "-Warc-performSelector-leaks" | |
NSLog(@"%@", [view performSelector:NSSelectorFromString(@"recursiveDescription")]); | |
#pragma clang diagnostic pop |
<UIDatePicker: 0x75561c0; frame = (0 0; 320 216); layer = <CALayer: 0x75563a0>> | |
| <_UIDatePickerView: 0x7556690; frame = (0 0; 320 216); autoresize = W+H; layer = <CALayer: 0x7172d70>> |
NSInteger column = 2; | |
SEL sel = NSSelectorFromString(@"numberOfRowsInColumn:"); | |
NSInvocation *inv = [NSInvocation invocationWithMethodSignature:[datePickerView methodSignatureForSelector:sel]]; | |
[inv setSelector:sel]; | |
[inv setTarget:datePickerView]; | |
[inv setArgument:&column atIndex:2]; | |
[inv invoke]; | |
NSUInteger length = [[inv methodSignature] methodReturnLength]; | |
NSInteger buffer = (NSInteger)malloc(length); | |
[inv getReturnValue:&buffer]; |
(lldb) po tb_descriptionForClassName(@"UIView") | |
$1 = 0x075ee730 --description-- | |
class: | |
UIView | |
ivars: | |
_layer, @"CALayer" | |
_tapInfo, @ | |
_gestureInfo, @ | |
_gestureRecognizers, @"NSMutableArray" |
NSObject *obj = [NSObject new]; | |
NSObject *copyObj = [obj copy]; |
WARNING: The locate database (/var/db/locate.database) does not exist. | |
To create the database, run the following command: | |
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.locate.plist | |
Please be aware that the database can take some time to generate; once | |
the database has been created, this message will no longer appear. |
https://developer.apple.com/jp/devcenter/ios/library/documentation/AutolayoutPG.pdf | |
https://developer.apple.com/library/ios/recipes/xcode_help-interface_builder/articles/UnderstandingAutolayout.html | |
https://developer.apple.com/library/ios/documentation/AppKit/Reference/NSLayoutConstraint_Class/NSLayoutConstraint/NSLayoutConstraint.html | |
https://developer.apple.com/videos/wwdc/2012/?id=202 |
https://developer.apple.com/jp/devcenter/ios/library/documentation/EventHandlingiPhoneOS.pdf | |
https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/multitouch_background/multitouch_background.html |
In OS X v10.6 and later, operation queues ignore the value returned by this method and always start operations on a separate thread.
Concurrent Versus Non-Concurrent Operations
If you plan on executing an operation object manually, instead of adding it to a queue, you can design your operation to execute in a concurrent or non-concurrent manner. Operation objects are non-concurrent by default. In a non-concurrent operation, the operation’s task is performed synchronously—that is, the operation object does not create a separate thread on which to run the task. Thus, when you call the start method of a non-concurrent operation directly from your code, the operation executes immediately in the current thread. By the time the start method of such an object returns control to the caller, the task itself is complete.
In contrast to a non-concurrent operation, which runs synchronously, a concurrent operation runs asynchronously. In other words, when you call the start method of a co