Skip to content
This repository has been archived by the owner on Feb 2, 2023. It is now read-only.

Use correct format identifiers for logs on 64 bit systems. #1

Merged
merged 1 commit into from
Jun 27, 2014
Merged

Use correct format identifiers for logs on 64 bit systems. #1

merged 1 commit into from
Jun 27, 2014

Conversation

endocrimes
Copy link
Contributor

Incorrect format identifiers were being used for NS(U)Integer, and as such were generating warnings on 64 Bit Builds. Based on: https://twitter.com/gparker/status/377910611453046784

I've also silenced the insertSublayer:atIndex: implicit conversion warning.

secretiverhyme added a commit that referenced this pull request Jun 27, 2014
Use correct format identifiers for logs on 64 bit systems.
@secretiverhyme secretiverhyme merged commit 752b084 into facebookarchive:master Jun 27, 2014
@secretiverhyme
Copy link
Contributor

Thanks!

@secretiverhyme secretiverhyme deleted the feature/precision-warnings branch June 27, 2014 18:38
@ocrickard
Copy link
Contributor

nice.

appleguy pushed a commit that referenced this pull request Dec 7, 2015
Make MapKit a weak framework
appleguy pushed a commit that referenced this pull request Mar 20, 2016
pull changes from upstream
appleguy pushed a commit that referenced this pull request Apr 1, 2016
garrettmoon added a commit to garrettmoon/AsyncDisplayKit that referenced this pull request Apr 11, 2017
* Adding buildkite support

* Update build.sh to support all flag
nguyenhuy pushed a commit to nguyenhuy/AsyncDisplayKit that referenced this pull request Apr 18, 2017
* Adding buildkite support

* Update build.sh to support all flag
aimalygin pushed a commit to aimalygin/AsyncDisplayKit that referenced this pull request Apr 18, 2017
* Adding buildkite support

* Update build.sh to support all flag
peter-iakovlev pushed a commit to peter-iakovlev/AsyncDisplayKit that referenced this pull request Oct 10, 2018
…ve#1154)

This is a follow up on facebookarchive#1136. Our experiment results show that clearing data frequently is the cause of our facebookarchive#1 crash. @maicki and I believe that this is because if the collection view is being used, silently clearing its data without notifying the backing UICollectionView can put it out-of-sync and causes mayhem next time the collection view processes a batch update. If you look at the stack trace closely, you'll notice that the crash doesn't occur on the same run loop that clearData is called. This made it extremely tricky to investigate and identify the root cause.

Another interesting question would be whether or not we want to clear the data during deallocation at all, since the data will be cleared out soon anyway.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants