|
Doc Block posted:So just calculate it then. Yah, looks like I was mistaken. I don't know why I thought it was that way, but this is definitely much more manageable.
|
#
?
Jul 11, 2013 20:46
|
|
|
|
| # ? May 16, 2024 07:38 |
|
|
Doh004 posted:I think you're partially right? It gets called when you set the data source and reloadData gets called for all of the rows, even ones that aren't visible yet. At least that's what I'm currently seeing with my NSLogs. Not sure what I was thinking. Of course it needs the height when reloading cells!
|
|
#
?
Jul 11, 2013 21:24
|
|
|
Cocos2D... Does anyone know how to access an entire tile layer and apply a color property to it? Looping through all the tiles and applying the color one at a time really slows down the load time of a new map, and mine are usually transitioning onto the screen, so I can't have that! I made a Stack Overflow if anyone wants to check it out: http://stackoverflow.com/questions/17603375/changing-the-color-of-an-entire-tile-layer-in-cocos2d-for-ios
|
|
#
?
Jul 11, 2013 22:28
|
|
|
My account expires August 2013. If I renew now, does it then expire in August 2014 or July 2014?
|
|
#
?
Jul 11, 2013 23:21
|
|
|
tarepanda posted:My account expires August 2013. If I renew now, does it then expire in August 2014 or July 2014? It extends one year from the old expiration date.
|
|
#
?
Jul 13, 2013 00:23
|
|
|
A lot of people who read this thread probably also follow John Gruber, but he linked to this article, which has some really good stuff about why Apple's getting rid of garbage collection, and what ARC means in terms of mobile performance.
|
|
#
?
Jul 14, 2013 15:24
|
|
|
Just a heads up for everyone, that is an extremely long article, but it's absolutely worth the time.
|
|
#
?
Jul 14, 2013 23:10
|
|
|
Speaking of articles, dunno if you guys have noticed objc.io which seems to be shaping up decently.
|
|
#
?
Jul 14, 2013 23:18
|
|
|
Axiem posted:A lot of people who read this thread probably also follow John Gruber, but he linked to this article, which has some really good stuff about why Apple's getting rid of garbage collection, and what ARC means in terms of mobile performance. Guy doesn't really seem to understand that it's a mobile CPU vs desktop-class CPU issue, not an ARM vs x86 one. Putting an x86 CPU in a mobile phone is going to mean the same performance trade-offs to get the power consumption, heat dissipation, and die size down to acceptable quantities that you see in current ARM SoCs. Which is why Intel hasn't really been able to do it yet. Also, he seriously needs an editor.
|
|
#
?
Jul 15, 2013 00:26
|
|
|
Carthag posted:Speaking of articles, dunno if you guys have noticed objc.io which seems to be shaping up decently. Thanks for this.
|
|
#
?
Jul 15, 2013 01:44
|
|
|
Carthag posted:Speaking of articles, dunno if you guys have noticed objc.io which seems to be shaping up decently. These are nice!
|
|
#
?
Jul 15, 2013 03:37
|
|
|
Doc Block posted:Guy doesn't really seem to understand that it's a mobile CPU vs desktop-class CPU issue, not an ARM vs x86 one. Putting an x86 CPU in a mobile phone is going to mean the same performance trade-offs to get the power consumption, heat dissipation, and die size down to acceptable quantities that you see in current ARM SoCs. Which is why Intel hasn't really been able to do it yet. That was the main part where I just couldn't figure out if he knows what he's talking about. He's got some sort of x86 supremacy thing going on that doesn't make sense. Intel is just now getting close to power use:processing done parity with ARM, partially because of the x86 instruction set's die requirements. I mean if Intel has 22nm chips for mobile that are better, that's because of Intel, not x86. Really I'm not sure what to argue against, because I don't really think he knows what he's arguing. Carthag posted:Speaking of articles, dunno if you guys have noticed objc.io which seems to be shaping up decently. NICE! This is a pro click. Definitely gonna follow this.
|
|
#
?
Jul 15, 2013 04:16
|
|
|
ultramiraculous posted:That was the main part where I just couldn't figure out if he knows what he's talking about. He's got some sort of x86 supremacy thing going on that doesn't make sense. Intel is just now getting close to power use:processing done parity with ARM, partially because of the x86 instruction set's die requirements. I mean if Intel has 22nm chips for mobile that are better, that's because of Intel, not x86. Really I'm not sure what to argue against, because I don't really think he knows what he's arguing. Frankly, I didn't follow most of the processor hardware talk. I just really thought the discussion of GC vs. ARC to be interesting, especially since I like those high level "here's how software architecture works" sorts of things, and figured other people on here might also. I wonder if other languages will follow in Apple's footsteps, or if they'll maintain down the GC road.
|
|
#
?
Jul 15, 2013 04:20
|
|
|
Carthag posted:Speaking of articles, dunno if you guys have noticed objc.io which seems to be shaping up decently. I hope they continue with this. These are well written and very useful.
|
|
#
?
Jul 15, 2013 04:47
|
|
|
Axiem posted:I wonder if other languages will follow in Apple's footsteps, or if they'll maintain down the GC road. Apple had it easy- GC was never a fundamental part of ObjC, it was added later as an extension and could be removed just as easily, and the language and class library already had a robust alternative in the form of pervasive reference counting. Something like JavaScript has the garbage collector written into the spec and doesn't even have allocate and free commands, because it's deliberately abstracted out. I don't know what the solution is but it's not going to be as simple as just not doing GC because without it the whole runtime environment becomes nonviable.
|
|
#
?
Jul 15, 2013 05:16
|
|
|
Axiem posted:Frankly, I didn't follow most of the processor hardware talk. That may be for the best. He was pretty confused about a lot of things, so you're avoiding negative knowledge. I work on processors somewhat similar to ones which go into mobile phones. Ask me whatever if you want to clarify something from that article. I thought the most interesting thing in it was the link to that paper which demonstrates that GC has no performance penalty only when you have about 5x as much RAM as you need with a theoretically perfect trace-based allocator, one which can be reasonably approximated with ordinary refcounting. And that when this is not the case, GC can consume a lot of CPU cycles. As a hardware engineer I sometimes use EDA tools, and some of these are written in Java. These tools are prime candidates for putting some severe stress on memory allocators, because they're for modeling or laying out chips with millions of objects (logic gates and wires). (Why yes, we do have some computers with 128GB RAM, or more.) I've definitely seen Java tools get horribly slow when the system is under memory pressure. Not that any program in a swap storm is pleasant, but these are worse, if that makes sense. Now I have something more objective than these impressions to justify my Java hate 
|
|
#
?
Jul 15, 2013 11:28
|
|
|
Also, package-on-package memory is used mostly to save space. Despite what the article says, there's no limitation in ARM that requires it; Apple could totally use separate memory modules if they wanted to.
|
|
#
?
Jul 15, 2013 17:24
|
|
|
Eh, his arguments about GC fall flat to me, at least when you are talking about languages designed for it. On the large multi-GB datasets I work on in C#, GC is faster because most objects are long-lived and allocation is just moving a pointer forward, no searching or compacting free block lists and the collector is a concurrent non-pausing one. It doesn't save you from bad programming practices, it just guarantees no buffer overflows, zombie objects, stack smashing, etc. The problem with Apple's GC is the problem with all C garbage collection... You can stuff pointers anywhere and they can be of any type (read:size) so it becomes impossible to move objects, thus you still have the fragmentation / heap compaction problem. I think ARC is the correct choice for Objective-C and Apple is totally doing the right thing by ditching their GC. Ultimately I think all code will move to a managed memory model in the long term, even kernels and drivers, but it may take many decades to get there. It has surprising implications... See the Singularity project from MS research where they found that writing the entire kernel and drivers in C# meant they could run the entire system in ring 0, removing the performance penalty for calling into kernel space, because the system could verify the security of programs before execution. It also made the microkernel/Mach IPC mechanism more feasible because the system could guarantee only one process has ownership of a message at a time so no cross-process copying is required and no ring transitions are needed. Of course they allowed each process to choose its own memory management strategy, with different GC and ref-counting mechanisms available. You can't think of such things as entirely good or bad, they are trade-offs. The ability to recover from a core driver crash because you can actually cleanly unwind exceptions, or the complete lack of buffer-overflow attacks system-wide is an interesting capability. There is a lot of work going on in this space but it remains to be seen if any of it gets traction or if we'll still be basically writing Unix programs using C in 2050, in which case there isn't an  big enough.Actually I think the same thing about Objective-C... If we are still prefixing class names, dumping enums into the global namespace, arrays are still just id, etc 10 years from now then I'll be really disappointed. ARC was a massive step forward though! Edit: completely unrelated, I finally whipped up a test project and created a radar bug for the CoreData sync issues. It's still as busted as ever. Any model violations and sync dies permanently. So you can just forget enforcing any constraints and smear special-casing code across the rest of your app, or you know... Just use a syncing solution that accepts conflicts will arise and need to be resolved by the program. I am proposing they do just that, who knows if it will make it in time for release or ever. Simulated fucked around with this message at 06:22 on Jul 16, 2013 |
|
#
?
Jul 16, 2013 06:18
|
|
|
I just implemented pull to refresh (on a view that isn't a table, so I couldn't use UIRefreshControl) and I can't figure out how to animate resetting the scroll view to its normal content size. When I remove the edge inset, the content instantly pops back up to fill the empty space where the refreshing view used to be and I haven't been able to use setContentOffset to make it smoothly slide there like I want. How do I do this?
|
|
#
?
Jul 16, 2013 21:22
|
|
|
haveblue posted:I just implemented pull to refresh (on a view that isn't a table, so I couldn't use UIRefreshControl) and I can't figure out how to animate resetting the scroll view to its normal content size. When I remove the edge inset, the content instantly pops back up to fill the empty space where the refreshing view used to be and I haven't been able to use setContentOffset to make it smoothly slide there like I want. How do I do this? You have to wrap the part where you call setContentOffset in a UIView animation, for example: code:
|
|
#
?
Jul 16, 2013 22:24
|
|
|
Axiem posted:A lot of people who read this thread probably also follow John Gruber, but he linked to this article, which has some really good stuff about why Apple's getting rid of garbage collection, and what ARC means in terms of mobile performance. Carmack linked this on Twitter and said it was a good article. He also wrote: "I tend to think that garbage collection in some contexts even for games is justified on big platforms."
|
|
#
?
Jul 17, 2013 05:32
|
|
|
I'm using Xcode 4.6's Organizer. I'm clicking the Renew button for a provision profile and nothing seems to happen. What's the deal? edit: Looks like design bug in Organizer. If I click the Provisioning Profiles section instead of the device, the renew button actually does something. Just kind of confused how this works because it's saying it doesn't have a certificateID but I'll hopefully figure it out. edit 2: Argh the certificateID thing is apparently a bug too and I can't figure out how to renew in the new portal. edit 3: Now it's giving me the error Provisioning profile '(some long string of numbers here)' can't be found. The only way I can see to fix it is to edit the project in a text editor, according to this answer, but I can't find a text editor that will actually open it! Why doesn't Apple fix their poo poo!?!?! edit 4: Resolved!! Maybe this will help someone else out. If this happens, click on all the code signing ID's for the project, target and any libraries. Even though what is shown there might say one thing, when you click it may say something else! Hideous, hideous bug, but two and half hours later, it's finally solved. LP0 ON FIRE fucked around with this message at 23:42 on Jul 17, 2013 |
|
#
?
Jul 17, 2013 22:12
|
|
|
Just got the email about Transporter for bulk localization metadata (screenshots!) uploading. Who was it here that had hundreds of localized screenshots?
|
|
#
?
Jul 17, 2013 23:08
|
|
|
lord funk posted:Just got the email about Transporter for bulk localization metadata (screenshots!) uploading. Who was it here that had hundreds of localized screenshots? That would be me. Fantastic news! Also, anyone who wants to read the CoreData iCloud thread please let me know if I am way off base because it sounds like Apple has no plans to change anything at the moment: https://devforums.apple.com/message/833355
|
|
#
?
Jul 18, 2013 02:18
|
|
|
I understand a total of 3 words from that thread! 
|
|
#
?
Jul 18, 2013 03:25
|
|
|
Ender.uNF posted:Also, anyone who wants to read the CoreData iCloud thread please let me know if I am way off base because it sounds like Apple has no plans to change anything at the moment: https://devforums.apple.com/message/833355 I'm surprised that "file a radar" came as late as it did. You got some good interaction there. Overall you come across as fairly levelheaded, if frustrated. All I can think of to do now, assuming you've filed the bugs you said you would, is get in touch with the relevant evangelist (developer evangelist?). That might be more redeeming than the radar black hole.
|
|
#
?
Jul 18, 2013 03:59
|
|
|
Ender.uNF posted:Also, anyone who wants to read the CoreData iCloud thread please let me know if I am way off base because it sounds like Apple has no plans to change anything at the moment: https://devforums.apple.com/message/833355
|
|
#
?
Jul 18, 2013 04:07
|
|
|
lord funk posted:Just got the email about Transporter for bulk localization metadata (screenshots!) uploading. Who was it here that had hundreds of localized screenshots? When they talked about this in the session, I was tempted to start writing an app to manage iTunes Connect poo poo. At least Apple is opening up an API for that. It might be an admission that they're never gonna give that terrible update process enough love for it to be decent.
|
|
#
?
Jul 18, 2013 05:48
|
|
|
ultramiraculous posted:When they talked about this in the session, I was tempted to start writing an app to manage iTunes Connect poo poo. Just to make sure, you know of the iTC Mobile app and cupertino right?
|
|
#
?
Jul 18, 2013 06:00
|
|
|
pokeyman posted:Just to make sure, you know of the iTC Mobile app and cupertino right? I meant the localization stuff. Until now there wasn't a defined API for uploading multiple localizations and you had to do each one by hand, screenshots and all. cupertino is great, though.
|
|
#
?
Jul 18, 2013 06:16
|
|
|
Doc Block posted:Also, package-on-package memory is used mostly to save space. Despite what the article says, there's no limitation in ARM that requires it; Apple could totally use separate memory modules if they wanted to. Isn't that pretty much what he said? The Article posted:What I don’t know is why, in the face of these problems with PoP, manufacturers continue to use package-on-package delivery for system memory. I haven’t found an ARM engineer who can explain it to me yet. Perhaps one will show up in the comments. It may be that we could move away from PoP architecture and toward separate memory modules like you have in computers. But I suspect that it is not feasible, for the simple reason that breaking the memory into separate modules would almost certainly be cheaper to manufacture than bigger chips or process shrinks, yet every single manufacturer keeps doing process shrinks or bigger chips rather than moving memory modules off the die. And then he quotes two people on the issue who know more than he does.
|
|
#
?
Jul 18, 2013 06:35
|
|
|
lord funk posted:Just got the email about Transporter for bulk localization metadata (screenshots!) uploading. Who was it here that had hundreds of localized screenshots?
|
|
#
?
Jul 18, 2013 08:35
|
|
|
Hey, I already have a custom container view controller set as my root view controller for our iPad app. Just got a design to add on to our app that is basically a UISplitViewController inside the "content" part of our own custom container. Since a UISplitViewController has to be set as the root view controller, would I be better off rolling another custom view controller, or are you guys aware of a third party UISplitViewController that doesn't have to be the root view controller? Thanks. *edit* Maybe UISplitViewControllers dont NEED to be the root view controller anymore? Couldn't find it in the docs: http://developer.apple.com/library/ios/#documentation/uikit/reference/UISplitViewController_class/Reference/Reference.html Doh004 fucked around with this message at 17:14 on Jul 18, 2013 |
|
#
?
Jul 18, 2013 17:06
|
|
|
samiamwork posted:Isn't that pretty much what he said? Not really. He's talking about PoP like it's a bad thing and an arbitrary ARM limitation. My point was that it has nothing to do with ARM, and that while Apple could move the RAM to separate modules like the author wants, they don't because there isn't enough room.
|
|
#
?
Jul 18, 2013 17:30
|
|
|
Doc Block posted:Not really. He's talking about PoP like it's a bad thing and an arbitrary ARM limitation. My point was that it has nothing to do with ARM, and that while Apple could move the RAM to separate modules like the author wants, they don't because there isn't enough room. He's not really saying that it's necessarily bad, but he's arguing that, given PoP, memory improvements are tied to process improvements or a larger die size. As far as PoP being an arbitrary ARM limitation, in the first sentence of the bit I quoted he says that he doesn't understand why they only use PoP given that it would be easier and cheaper to manufacture by using modules. So its not that he thinks it's an intrinsic property but all the designs he's seen use it. He does admit ignorance about the advantages but there are quotes to fill that in. (of course as pointed out in the comments the iPad 3 has separate memory modules, going by ifixiit anyway) Not trying to be antagonistic. I can definitely see how it could be read the way you did given what he wrote a few paragraphs above that bit, but taken as a whole, I think he was clear about what he did and didn't understand and was right about what he did understand (with respect to memory anyway). Anyway I guess I'm sticking up for the article because I wish there were more blog posts this well argued (whether or not I agree with the conclusions). But maybe I'm a weirdo for thinking that. Sorry for the derail.
|
|
#
?
Jul 19, 2013 05:42
|
|
|
I don't think it's all that well argued, even though I agree with his ultimate conclusion (native mobile apps are faster and generally superior to mobile web apps or some Phonegap-like hybrid). The article is generally poorly written, and is badly in need of structure; it's less an article and more a sea of words. His poor choice of color and font don't help, either. And then there's the fact that he's just plain wrong about some things. Framing mobile vs desktop CPUs as ARM vs x86 instead, for one. Lastly, the iPad 3 can have separate memory modules because the iPad has plenty of space for them. The author really doesn't understand this. Great, he's got some quotes from Intel engineers saying that PoP memory has lower latency, and completely ignores the space issue. Have you ever seen the inside of an iPhone? The logic board is a good deal smaller than the actual phone and is packed.
|
|
#
?
Jul 19, 2013 06:21
|
|
|
Doc Block posted:I don't think it's all that well argued, even though I agree with his ultimate conclusion (native mobile apps are faster and generally superior to mobile web apps or some Phonegap-like hybrid). The article is generally poorly written, and is badly in need of structure; it's less an article and more a sea of words. His poor choice of color and font don't help, either. I thought it had good structure, but I don't want to argue about that here. I agree with you on font and color though. quote:And then there's the fact that he's just plain wrong about some things. Framing mobile vs desktop CPUs as ARM vs x86 instead, for one. That's not how I read it, but that's okay. We cool. quote:Lastly, the iPad 3 can have separate memory modules because the iPad has plenty of space for them. The author really doesn't understand this. Great, he's got some quotes from Intel engineers saying that PoP memory has lower latency, and completely ignores the space issue. Have you ever seen the inside of an iPhone? The logic board is a good deal smaller than the actual phone and is packed. I'm not sure why you're telling me this. Actually it's probably because I just plopped that comment in a parenthetical without much explanation. I just pointed it out because I thought it was amusing that his area of expertise is iOS and yet he didn't even know that even apple has used separate memory modules in their ARM stuff. It's not like it's some obscure Chinese Android device. Yeah, he totally misses the space issue, but my original point was just that he understands that PoP is not an ARM arch requirement.
|
|
#
?
Jul 20, 2013 03:31
|
|
|
I have a UIScrollview which covers the screen on the app, and has an UIView animation of 3 buttons which scroll from left-to-right. The buttons don't sit in any view, so I'm moving them UIView animations. Whenever I move the scrollview, the buttons reset to the original positions they were at. How do I prevent this, and have the animation persist, rather than stop and reset?
|
|
#
?
Jul 20, 2013 13:08
|
|
|
So what horror has befallen the Apple Dev Center site? It's been down for something like two days now with a cryptic "maintenance" message. Provisioning, forums, downloads, you name it, it is dead.
|
|
#
?
Jul 20, 2013 16:37
|
|
|
|
| # ? May 16, 2024 07:38 |
|
|
kitten smoothie posted:So what horror has befallen the Apple Dev Center site? It's been down for something like two days now with a cryptic "maintenance" message. Provisioning, forums, downloads, you name it, it is dead. Now they're apologizing in the message. This never would have happened under Scully.
|
|
#
?
Jul 20, 2013 16:40
|
|