|
Help! I'm locked out of my iPhone! I had the latest beta, and for some reason after the official iOS 7 announcement the update page on my iPhone always said I was up-to-date. I just figured the GM seed was still going to be supported indefinitely. And now I think Apple just invalidated the version of iOS 7 I had. I can't restore because it says I need to deactivate "Find My iPhone". But I can't do that because my phone is stuck in the "Activation" page! I tried removing my iPhone from my list of devices on icloud.com but to no avail. Can anyone help me? You can't possibly tell me my iPhone is bricked because of that. That's ridiculous.
|
#
?
Oct 6, 2013 04:51
|
|
|
|
| # ? May 16, 2024 23:19 |
|
|
http://www.graphitas.co.uk/blog/2013/10/ios-7-activation-required-error-on-iphone-and-ipad/
|
|
#
?
Oct 6, 2013 05:00
|
|
|
Had this happen with my tester iPhone 4 that I forgot to update. Just put it in DFU mode, then plug it into your computer. Open iTunes, which will say it's found a device in recovery mode. Let iTunes restore your phone; in doing so it will download and install the latest iOS. This will erase everything on the device. After that you can restore from an iTunes or iCloud backup.
|
|
#
?
Oct 6, 2013 05:42
|
|
|
For some reason Apple never posted the GM for OTA updates of the beta, so if you didn't take the time to download and update it manually congrats - you just hit the expiration time limit. You have to pay attention to their dev seed emails 
|
|
#
?
Oct 6, 2013 07:24
|
|
|
Ender.uNF posted:For some reason Apple never posted the GM for OTA updates of the beta, so if you didn't take the time to download and update it manually congrats - you just hit the expiration time limit. You have to pay attention to their dev seed emails I mean I can vaguely rationalize why they do this, but it's certainly annoying. At least OSX DPs don't expire, but both OSX and iOS should be allowed to upgrade to the GM without having to download the whole OS install.
|
|
#
?
Oct 7, 2013 23:31
|
|
|
I'm having some weird zombie object issues that could be explained by a very simple question. Does ARC retain instance variables referenced in GCD blocks? I have some nonatomic NSDictionary properties, some GCD code that may call mutableCopy and objectForKey on them from a background queue, and some UI code that may call allValues or objectForKey at the same time on the main thread. This is crashing horribly with zombie seg faults. It could all be explained away if ARC does not retain ivars in GCD blocks. If that is the case, can I simply hold some local strong references that I pass into the block?
|
|
#
?
Oct 8, 2013 02:53
|
|
|
References ivars results in self being retained. If you're ever assigning to the ivar from one thread while reading from it on another thread without locking, that's not at all safe and will result in crashes.
|
|
#
?
Oct 8, 2013 03:34
|
|
|
Plorkyeran posted:References ivars results in self being retained. To drive this home, remember that Objective-C code:Objective-C code:and the block captures that implicit self.
|
|
#
?
Oct 8, 2013 03:54
|
|
|
pokeyman posted:To drive this home, remember that I was in the middle of writing up a long, confused reply before this clicked. Now it makes sense. It sounds like I can keep a strong reference to the property's object itself in the block if I want to do that vs. making the properties atomic. Plorkyeran posted:If you're ever assigning to the ivar from one thread while reading from it on another thread without locking, that's not at all safe and will result in crashes. I thought that I should be safe since my collections are immutable; an assignment should be effectively atomic. My only problem is that some operations like mutableCopy and allValues are not increasing the retain count. The performance gain of using strong references vs. just making the properties in question atomic is probably trivial, so this is purely academic. I'm infatuated with GCD and blocks, but I obviously still have some mental blocks and misunderstandings of how they work. edit: All of my assignments happen on the main queue. Most of my reads do as well, but my problem areas are where I grabbed some data while processing in the background. ManicJason fucked around with this message at 04:29 on Oct 8, 2013 |
|
#
?
Oct 8, 2013 04:24
|
|
|
ManicJason posted:I thought that I should be safe since my collections are immutable; an assignment should be effectively atomic. My only problem is that some operations like mutableCopy and allValues are not increasing the retain count. This is a bit of a mixed bag and I'm not totally sure what you're trying to do, but I'm not sure what making the property atomic does for you here. Either way, your instinct is likely correct about the "performance gains". (Here's where I file my quarterly complaint with rjmccall about "atomic" being the default.) Furthermore, neither -mutableCopy nor -allValues should bump the receiver's retain count. Both should, however, return objects with a +1 retain count, and -allValues should bump the retain count of its contents. But if you don't capture the returned objects in your block they'll fall out of scope and disappear.
|
|
#
?
Oct 8, 2013 04:53
|
|
|
The problem seems to be that one thread is doing [class.thing mutableCopy] while another thread is doing class.thing = newThing. The mutableCopy method has its object ripped out from under it, either during or just before it executes. I wasn't suggesting that mutableCopy should result in a higher retain count; I was asking if it would retain and then release its self to prevent this zombie issue. This may be irrelevant if the container is being released before the background block even hits the call to mutableCopy. I may still be a bit off with the reasoning, but I'm 95% sure that changing my properties to atomic fixed this issue in the most readable way.
|
|
#
?
Oct 8, 2013 05:38
|
|
|
ManicJason posted:The problem seems to be that one thread is doing [class.thing mutableCopy] while another thread is doing class.thing = newThing. The mutableCopy method has its object ripped out from under it, either during or just before it executes. Yep, that sounds like the exact issue atomic properties are intended to handle. -mutableCopy might keep your object around longer, but I wouldn't count on it, as (I think) seemingly pointless retain/release pairs are rather aggressively optimized out. Keep a reference until you need it, nil it out when you're done, and you should be ok.
|
|
#
?
Oct 8, 2013 07:01
|
|
|
pokeyman posted:I don't make it a habit to dive into C++ but I'd love to see it, if it's not much work to put up a sample. As promised in the general programming thread (argh should have gone to sleep) https://gist.github.com/toulouse/ca501c3621992238ecf6 Things I haven't added to it are different options based on retina support, i.e.e retinaPhone, retinaPad, or the proper logic to distinguish them in an easily-derived manner, which would probably best be implemented as categories on UIDevice or with a class that wraps it. To use it, basically, define a subclass of it with its own set of fields in your header file, or inline in a relevant implementation file, either with the class it's mainly used in or in its own for reuse elsewhere, which overrides the methods to set the values. Too tired now to show an example. Also omitted is a method of subclassing the measurements one level deeper and casting it upwards, which relies on not adding any additional properties. Then to use, "SomeMeasurementsType blah = GetMeasurements<SomeMeasurementsType();" and use blah.fooHeight and stuff in your code. This pattern is a reconstruction of something I've seen, so some signal is lost along the way. Doctor w-rw-rw- fucked around with this message at 17:11 on Oct 8, 2013 |
|
#
?
Oct 8, 2013 11:15
|
|
|
ManicJason posted:an assignment should be effectively atomic I didn't want to let this pass by: this statement is laughably hilariously untrue. This is one case where understanding the underlying hardware really helps out. Assignment of a constructed object consists of allocating memory, setting the first few bytes to the isa pointer, running the super init, running your init, a blood sacrifice, whatever etc each of which may construct other objects, store their pointers in an ivar, and so on. Oh, and also store the pointer to the allocated object itself. The processor is free to reorder any of these instructions so long as, from the point of view of that thread of execution, it appears to have happened in-order. If another core is running a thread that accesses the pointer, it may see garbage, it may see a half-initialized object. The results are undefined. The processor may issue the store of the object pointer immediately after the allocation because it sees nothing else changes the pointer in the upcoming instruction stream, so why not get it out of the way while we can even though the object itself hasn't been constructed yet. When you start bringing cache lines into the picture it can get even crazier, as different cores will see a different view of main memory depending on what pieces of memory are cached at L1, L2, and L3 and which of those are shared (eg on an 8 core box with 4 L2 shared and one central L3, you can have anything from no disagreement to 8 ideas about what is at memory location X). The various atomic instructions essentially send cache control signals between cores to make sure they all agree, either by probing for changes to pull locally or pushing changes out (or asking the other cores to dump a cache line and reload from main memory). Memory barriers act like virtual walls, telling the processor not to move loads or stores beyond or before the line, eg by ensuring a store of an object pointer can't be published until the object construction is done. Short version: you have to think of memory in modern multi-core machines as the equivalent of an "eventually consistent" database and each core as a separate process, some of which are running on the same node and others which communicate over a network (in reality large numbers of cores do use a network to communicate due to increased cross-core traffic). Von Neumann is dead.
|
|
#
?
Oct 8, 2013 16:42
|
|
|
ManicJason posted:I may still be a bit off with the reasoning, but I'm 95% sure that changing my properties to atomic fixed this issue in the most readable way. Changing to 'atomic' is, by default, a code smell to me. Can you post pseudo code of the thing you're trying to do?
|
|
#
?
Oct 8, 2013 16:54
|
|
|
Doctor w-rw-rw- posted:Changing to 'atomic' is, by default, a code smell to me.
|
|
#
?
Oct 8, 2013 18:00
|
|
|
Ender.uNF posted:why making an object-typed property atomic is utterly pointless I always forget how poor my understanding is of how the code I write could possibly be executed. So, a question: what about a value-typed atomic property like @property BOOL? I'm thinking that it's no different. Even if it's an auto-synthesized property, you're dealing with a call to objc_msgSend and other cores can wander by anytime after that calls the method implementation.
|
|
#
?
Oct 8, 2013 19:00
|
|
|
Doctor w-rw-rw- posted:Changing to 'atomic' is, by default, a code smell to me. Can you post pseudo code of the thing you're trying to do? We have a set of ~250 or so events that we display on table views with several sorting/grouping options and one drilled down detail view. We asynchronously receive updates to individual entries or the entire list, often several single entry updates per second. I built a class to receive these updates off the wire and update the grouping, optimized to single insertions, deletions, and updates, which is what we get 99% of the time. The dictionaries giving me problems are NSSets of the entries keyed by NSString group names. In a single background GCD thread, I am taking a mutable copy of the existing dictionary and a mutable copy of the appropriate NSSet, adding/updating/deleting the entry, replacing the NSSet in the dictionary, then swapping the new dictionary into place back on the main thread. Our UI updates via KVO on that swap. We have other UI pieces that may occasionally grab small pieces of data from one of our dictionaries on the main thread. We occasionally have to iterate over this same data elsewhere, so I've tried to stay away from mutable collections.
|
|
#
?
Oct 8, 2013 19:09
|
|
|
Doctor w-rw-rw- posted:As promised in the general programming thread (argh should have gone to sleep) How do you use this in lieu of auto layout? I'm not quite following how this helps you specify a view's measurements.
|
|
#
?
Oct 8, 2013 19:25
|
|
|
pokeyman posted:I always forget how poor my understanding is of how the code I write could possibly be executed. So, a question: what about a value-typed atomic property like @property BOOL? I'm thinking that it's no different. Even if it's an auto-synthesized property, you're dealing with a call to objc_msgSend and other cores can wander by anytime after that calls the method implementation. In a preemptively scheduled multithreaded system, even with a single core, there could be arbitrary work performed by any number of other tasks between any two consecutive instructions. And a statement in a high-level language could contain many more instructions than it seems.
|
|
#
?
Oct 8, 2013 19:54
|
|
|
I understand why you want @property (copy) for things like NSArray, NSString, etc. because someone might pass you a mutable array then gently caress with it behind your back. But I just noticed that -[UIPopoverController backgroundColor] is a UIColor property declared copy. How is that useful?haveblue posted:In a preemptively scheduled multithreaded system, even with a single core, there could be arbitrary work performed by any number of other tasks between any two consecutive instructions. And a statement in a high-level language could contain many more instructions than it seems. I should tattoo that somewhere on me. It's been too long since my OS course.
|
|
#
?
Oct 8, 2013 20:30
|
|
|
UIColor subclasses are required to be thread-safe, but not immutable.
|
|
#
?
Oct 8, 2013 21:20
|
|
|
Plorkyeran posted:UIColor subclasses are required to be thread-safe, but not immutable. Which UIColor subclasses? All I can find is UIColor docs posted:"Color objects are immutable"
|
|
#
?
Oct 8, 2013 21:40
|
|
|
pokeyman posted:How do you use this in lieu of auto layout? I'm not quite following how this helps you specify a view's measurements. It makes it easier to statically size and layout stuff, i.e. in layoutSubviews, and modify as needed for different screen sizes / scales? I mean, I guess my solution is to just manually lay things out. This minimizes the redundant device checks by stuffing the differences in an easily-edited struct. EDIT: ManicJason posted:We have a set of ~250 or so events that we display on table views with several sorting/grouping options and one drilled down detail view. We asynchronously receive updates to individual entries or the entire list, often several single entry updates per second. dispatch_sync should be used sparingly if ever due to the potential for deadlock. Doctor w-rw-rw- fucked around with this message at 22:16 on Oct 8, 2013 |
|
#
?
Oct 8, 2013 22:11
|
|
|
I do just that when I say I swap in the new data on the main thread.
|
|
#
?
Oct 8, 2013 22:41
|
|
|
Doctor w-rw-rw- posted:It makes it easier to statically size and layout stuff, i.e. in layoutSubviews, and modify as needed for different screen sizes / scales? I mean, I guess my solution is to just manually lay things out. This minimizes the redundant device checks by stuffing the differences in an easily-edited struct. Oh ok, I get it now. It is a pain to go through the "is this a phone? how tall is it? etc." combinations.
|
|
#
?
Oct 8, 2013 23:46
|
|
|
I've been battling with an Epson POS printer (over TCP, not Bluetooth), and I'd like to give everyone here some advice in the case they might have to deal with such a thing in the future. Using the official iOS SDK was a pain in the rear end, and it seemed to be full of bugs, or, in the very best case, incredibly slow. I spent hours trying to track down where the problem was, and I never ended up finding it. I ended up re-doing everything with CFNetwork and the manual control codes, and, lo and behold, the printer is lightning-fast and there's no more strange bugs and ERR_UNSPECIFIED codes! So, in summary, don't even bother with their SDK. It's a horrible and terribly thin wrapper over the ESC/POS codes, and what's worse is that it doesn't appear to work (and when it does, it's incredibly slow). Since it was a pain in the rear end to find, I'll also add that the correct port for TCP communication with those printers is 9100. Just connect and start sending data.
|
|
#
?
Oct 9, 2013 05:29
|
|
|
haveblue posted:In a preemptively scheduled multithreaded system, even with a single core, there could be arbitrary work performed by any number of other tasks between any two consecutive instructions. And a statement in a high-level language could contain many more instructions than it seems. This is the answer. The bonus is in today's multicore environment it's virtually guaranteed that multithreaded code will hit disagreements about the contents of memory unless you use all the appropriate safeguards. PT6A posted:I've been battling with an Epson POS printer (over TCP, not Bluetooth), and I'd like to give everyone here some advice in the case they might have to deal with such a thing in the future. Using the official iOS SDK was a pain in the rear end, and it seemed to be full of bugs, or, in the very best case, incredibly slow. I spent hours trying to track down where the problem was, and I never ended up finding it. I ended up re-doing everything with CFNetwork and the manual control codes, and, lo and behold, the printer is lightning-fast and there's no more strange bugs and ERR_UNSPECIFIED codes! So, in summary, don't even bother with their SDK. It's a horrible and terribly thin wrapper over the ESC/POS codes, and what's worse is that it doesn't appear to work (and when it does, it's incredibly slow). You mean a device manufacturer poo poo out a horrible buggy SDK? 
|
|
#
?
Oct 9, 2013 15:38
|
|
|
Ender.uNF posted:You mean a device manufacturer poo poo out a horrible buggy SDK? Cut me a break, this is my first time dealing with a peripheral of this type. I just don't get why they'd bother to release such a buggy piece of poo poo, considering that some of the problems (judging by the bugs I encountered when I was using the control codes manually) actually came from not closing the NSStream. I have to think that'd be picked up during even the most rudimentary testing. As for the horrible, horrible slowness, I don't even have the faintest clue what could've caused that.
|
|
#
?
Oct 9, 2013 16:39
|
|
|
PT6A posted:Cut me a break, this is my first time dealing with a peripheral of this type. If you haven't already, it might be worth trying extra hard to find a manual for your particular device. Just to make sure you're not, I dunno, sending a control code that'll leave something turned on and drastically shorten the life of some component and/or start a fire. The slow and lovely SDK could be doing something important.
|
|
#
?
Oct 9, 2013 17:04
|
|
|
pokeyman posted:If you haven't already, it might be worth trying extra hard to find a manual for your particular device. Just to make sure you're not, I dunno, sending a control code that'll leave something turned on and drastically shorten the life of some component and/or start a fire. The slow and lovely SDK could be doing something important. I did, I followed the sample program in terms of initialization and teardown, so I don't foresee any issues there. ESC/POS is nicely documented, at least.
|
|
#
?
Oct 9, 2013 19:55
|
|
|
Is there any great way to set up side effects for an @property setter within an object? It seems like my options are: A. Override the setter and lose all the automagic @property stuff B. Have the object Key-Value observe itself Like if I wanted cell.model to update the cell when set, is there a cool way to do that?
|
|
#
?
Oct 9, 2013 22:09
|
|
|
ultramiraculous posted:Is there any great way to set up side effects for an @property setter within an object? 1. Do NOT KVO a table cell. It's slow as gently caress. Don't. Don't. Don't. 2. Just override the setter. Also, @property doesn't give you anything magical, other than wrap its stuff in NSLock (I think) when atomic, or call 'copy' for you. Which you won't be doing (the lock part, that is) because cells are UIKit objects, which you should never be mutating off the main thread, or any objects they contain. NOTE: ARC doesn't add copy method calls, so add that if you're using immutable objects. 3. Sometimes if you have multiple properties which should change a cell's contents I use the setNeeds* pattern, i.e. I make a method called setNeedsUpdate which sets a flag to YES and somewhere, something will call updateIfNeeded on the cell, which will flush the changes (alternatively to making this method, use layoutSubviews, especially if your changes will mean you need to change the cell layout)
|
|
#
?
Oct 9, 2013 22:30
|
|
|
PT6A posted:Cut me a break, this is my first time dealing with a peripheral of this type. That wasn't a dig at you; I agree and it baffles me how horrible hardware engineers are at doing SDKs. I have no idea why they never seem willing to hire one or two good software people. Same goes for cable box manufactures amongst many others.
|
|
#
?
Oct 10, 2013 02:26
|
|
|
Ender.uNF posted:That wasn't a dig at you; I agree and it baffles me how horrible hardware engineers are at doing SDKs. I have no idea why they never seem willing to hire one or two good software people. Same goes for cable box manufactures amongst many others. It's conceivable that they do hire one or two good software people, proceed to ignore them, and dump projects on them with a fifth of the time needed to do a good job. Either way it's a big poo poo sandwich. Definitely seems like a fixable problem.
|
|
#
?
Oct 10, 2013 02:51
|
|
|
Ender.uNF posted:That wasn't a dig at you; I agree and it baffles me how horrible hardware engineers are at doing SDKs. I have no idea why they never seem willing to hire one or two good software people. Same goes for cable box manufactures amongst many others. No worries, I meant that in a friendly way (tone is hard to convey in text). Ultimately, I'm kicking myself for trying to fight with the lovely SDK for so long, even as I suspected it could be the problem. The only thing I've seen in the SDK that outdoes what's basically trivial to do myself is the error reporting, which wasn't all that great, since I kept getting generic "unspecified" codes anyway when anything screwed up. I'm still at a loss for how they spent what I presume was a good amount of effort (and money) and still came away with such a terrible product when all is said and done. I'll admit, I restrained myself to about 10 basic control codes, but I'd rather take something with a limited feature set that's solid as a brick shithouse, instead of something that can almost do a whole bunch of complex things, yet does nothing well.
|
|
#
?
Oct 10, 2013 07:01
|
|
|
ManicJason posted:We have a set of ~250 or so events that we display on table views with several sorting/grouping options and one drilled down detail view. We asynchronously receive updates to individual entries or the entire list, often several single entry updates per second. I'm quoting myself here just to make sure nothing in what I'm doing is jumping out as retarded. I spared you guys the details until two people said using atomic properties is likely a mistake and asked for more details. The only alternative I see is manually taking the locks that will end up doing exactly what atomic properties give me. I've been taking huge steps toward optimizing this project that's been horribly inefficient main thread nonsense for its lifetime. I'm doing my best at leveraging GCD and whatever else I can scrape from WWDC videos, but I'm likely making some mistakes. There have already been some growing pains as I showed in my earlier posts, but overall I am thrilled with the improvements I've seen since tackling this.
|
|
#
?
Oct 10, 2013 08:15
|
|
|
ManicJason posted:I'm quoting myself here just to make sure nothing in what I'm doing is jumping out as retarded. I spared you guys the details until two people said using atomic properties is likely a mistake and asked for more details. The only alternative I see is manually taking the locks that will end up doing exactly what atomic properties give me. Wait a sec: "In a single background GCD thread, I am taking a mutable copy of the existing dictionary and a mutable copy" <--is the mutable copy being done in the main thread? If so, then maybe that's the problem. If you have a stream of changes coming in on one thread, and processing or modification on another, then you might need to trampoline dispatch_async back and forth to serialize the inputs/processing/output on the dispatch queue itself. If that doesn't apply, then perhaps you could use GCD's mutex primitives. Here's some reading: http://www.fieryrobot.com/blog/2010/09/01/synchronization-using-grand-central-dispatch/
|
|
#
?
Oct 10, 2013 10:06
|
|
|
PT6A posted:I've been battling with an Epson POS printer (over TCP, not Bluetooth), and I'd like to give everyone here some advice in the case they might have to deal with such a thing in the future. Using the official iOS SDK was a pain in the rear end, and it seemed to be full of bugs, or, in the very best case, incredibly slow. I spent hours trying to track down where the problem was, and I never ended up finding it. I ended up re-doing everything with CFNetwork and the manual control codes, and, lo and behold, the printer is lightning-fast and there's no more strange bugs and ERR_UNSPECIFIED codes! So, in summary, don't even bother with their SDK. It's a horrible and terribly thin wrapper over the ESC/POS codes, and what's worse is that it doesn't appear to work (and when it does, it's incredibly slow). I work on a point of sale product, and we're going to be developing an iOS offering in the relatively near future. I want you to know that this information will come in handy, so thank you for posting it.
|
|
#
?
Oct 11, 2013 13:11
|
|
|
|
| # ? May 16, 2024 23:19 |
|
|
Anyone else at CocoaSlopes?
|
|
#
?
Oct 12, 2013 16:38
|
|
