|
LP0 ON FIRE posted:drat... I just upgraded my work's iPad to iOS 5.1, and it seems that I can no longer test on this device unless I upgrade to Lion to install the new Xcode. I get this when I try to run:
|
#
?
Mar 13, 2012 23:06
|
|
|
|
| # ? May 16, 2024 14:39 |
|
|
Xcode was the only reason I upgraded to Lion. I miss Snow Leopard. 
|
|
#
?
Mar 14, 2012 00:14
|
|
|
If memory serves, yes. 10.8 is gonna be out soon, man. Time to upgrade. edit: Lion seems a lot more stable and faster than Snow Leopard. You can always turn off natural scrolling and such if you don't like them.
|
|
#
?
Mar 14, 2012 00:29
|
|
|
LP0 ON FIRE posted:I have an enterprise provision mess on my shoulders right now. The company that I made an enterprise iPad app for did not renew their provision nor their account. As soon as they paid for a new yearly fee, I had access to their account but the provision was expired. There was no renew button, and the distribution certificate was gone from the portal. So I removed the provision, and made one with the same name and another certificate that associated with that provision, downloaded those both and synced with my iPad. And of course, the app does not launch, and why would I expect it to since the app is associated with the old provision.. Set up hockeykit on a server somewhere and do that. Its a pain in the arse, but its a tonne easier than trying to coordinate 100+ dumb arses to correctly set up their devices. plus the auto over-the-air updates solves it for future instances too. http://hockeykit.net/
|
|
#
?
Mar 14, 2012 01:10
|
|
|
duck monster posted:Set up hockeykit on a server somewhere and do that. Its a pain in the arse, but its a tonne easier than trying to coordinate 100+ dumb arses to correctly set up their devices. plus the auto over-the-air updates solves it for future instances too. Ugh.. yeah the problem with this or any solution like downloading is that the app is about 2 GB. In some places internet connection is really poor so this just wouldn't be satisfactory. We tested it and the app downloading and installing can take a half a day or more in some places. Hog Obituary posted:You need Xcode 4.3.1 to develop/debug with iOS 5.1, yes. That sucks I guess I will have to convince them to upgrade my computer even though it is very cheap. It's just that a lot of software we run is not compatible with Lion. I was pointed to some other solutions on Stack Overflow, but they are very hacky look like a pain to incorporate. May as well upgrade my OS X. LP0 ON FIRE fucked around with this message at 01:50 on Mar 14, 2012 |
|
#
?
Mar 14, 2012 01:48
|
|
|
LP0 ON FIRE posted:Ugh.. yeah the problem with this or any solution like downloading is that the app is about 2 GB. In some places internet connection is really poor so this just wouldn't be satisfactory. We tested it and the app downloading and installing can take a half a day or more in some places. how the gently caress did you make a 2Gb app?  e: Also yeah, feel your pain with the Lion upgrade. I was forced to upgrade due to Xcode , but it took 9months for loving Zoom to release drivers for my audio recording interface. Total cuntitude all around.
|
|
#
?
Mar 14, 2012 01:56
|
|
|
Doc Block posted:edit: Lion seems a lot more stable  The 'works-projects' folder actually has about 100 folders full of work in it. But about 10% of the time, when I click on it from the Favorites area, the window comes up empty. Nearly poo poo my pants the first time it happened. I've noticed a ton of annoying glitches with window activity in Lion. I wish Xcode didn't require Lion. :/
|
|
#
?
Mar 14, 2012 02:10
|
|
|
lord funk posted:I wish Xcode didn't require Lion. :/ As horrible as Lion is, Xcode still manages to be so much worse. So at least there's that!
|
|
#
?
Mar 14, 2012 02:54
|
|
|
Ender.uNF posted:Storm Sim users are getting active assertions errors that kill the app after updating to iOS 5.1... Is anyone aware of changes to audio handling in the latest update? The app is setup to allow mixing audio with other apps and to allow background playback. This has always worked before without issue but suddenly does not. Not sure if this is it (and it's a good warning to everyone else) but I just saw this: Xamarin blog posted:In iOS 5.1 Apple introduced restrictions to StdOut calls that cause any applications that are installed via the App Store or Ad-hoc deployment to be terminated if they attempt to write to the console. This includes calls to Console.Write* (Write, WriteLine). This problem affects all apps that attempt to use StdOut calls, including those written in Objective-C. e: The post is about MonoTouch, hence the note about Console.Write. pokeyman fucked around with this message at 06:23 on Mar 14, 2012 |
|
#
?
Mar 14, 2012 04:02
|
|
|
duck monster posted:how the gently caress did you make a 2Gb app? The bulk of it consists of high quality videos that can also be displayed on a TV when the iPad is connected to it, so they have to look good scaled up. The videos are still pretty well compressed, there's just a lot of them. Yeah, so I'm just going to have to remember for next time that when I update my iOS, I may also have to update my OS X so I can install a new Xcode! Although this happens so far apart though I know I'll forget..
|
|
#
?
Mar 14, 2012 05:43
|
|
|
In case you're curious, there's a good reason why Xcode is frequently tied to the absolute latest OS release: it's a GC application. The memory model of the ObjC collector is fundamentally unsound in some serious ways — for example, only object pointers are managed by the collector, but objects can explicitly own unmanaged memory using finalizers — that make it quite easy to introduce certain classes of bugs. Worse, those bugs can be masked by compiler vagaries (if a pointer is incidentally left around as garbage on the stack, the collector conservatively considers it live) or user-code vagaries (the collector does a lot of thread-local management, and thread-local collections trigger after a certain amount of work occurs, which in practice means that there are intervals during which transient liveness bugs will reliably not cause problems until the call pattern changes just slightly). This is exacerbated by there not being very many significant GC applications in the first place, which means that if anyone's going to find those bugs, it's usually Xcode. So when Xcode X.Y requires Mac OS A.B.C, it's usually because they found yet another latent bug somewhere in the system frameworks.
rjmccall fucked around with this message at 07:13 on Mar 14, 2012 |
|
#
?
Mar 14, 2012 07:10
|
|
|
Zhentar posted:It might help if you included how you present the UIImagePicker. Sorry: code:
|
|
#
?
Mar 14, 2012 15:33
|
|
|
Not to pin Xcode performance issues on GC without evidence, but I can't help wondering how an ARC conversion of Xcode would feel in comparison.
|
|
#
?
Mar 14, 2012 20:01
|
|
|
And since it already requires Lion it's not like you're leaving anyone behind. Should be as easy as hitting 'Refactor -> Convert project to ARC...'
|
|
#
?
Mar 14, 2012 20:44
|
|
|
Well, Xcode is perhaps Apple's most complicated application, and there's no way for us outsiders to know how much work might be needed to make all that code retain-release/ARC compliant and decently bug-free. 
|
|
#
?
Mar 14, 2012 22:06
|
|
|
pokeyman posted:And since it already requires Lion it's not like you're leaving anyone behind. Are there any risks to using that utility or is it pretty much guaranteed to work? The app I'm working on right now uses garbage collection and I was planning on switching to ARC at some point. It'd be nice if I could just run that and be done with it.
|
|
#
?
Mar 14, 2012 22:12
|
|
|
Toady posted:Well, Xcode is perhaps Apple's most complicated application, and there's no way for us outsiders to know how much work might be needed to make all that code retain-release/ARC compliant and decently bug-free. I was joking, I have no doubt it's not that trivial. Gordon Cole posted:Are there any risks to using that utility or is it pretty much guaranteed to work? The app I'm working on right now uses garbage collection and I was planning on switching to ARC at some point. It'd be nice if I could just run that and be done with it. Well I'm assuming your stuff's in version control, so there shouldn't be any risk either way. If your stuff is not in version control, stop immediately and make it happen. Other than that, the few times I've used the 'convert to ARC' tool it's been quite conservative and clearly marks areas where it needs help. I think I even had it refuse to run on something.
|
|
#
?
Mar 14, 2012 22:25
|
|
|
I'm using version control, of course, I just wasn't sure if the tool could potentially produce subtle bugs or memory leaks that could come back to haunt me down the line. It sounds like it's pretty safe to use so I'll give it a shot later.
|
|
#
?
Mar 14, 2012 22:26
|
|
|
GC performs cycle collection and ARC doesn't, so there's plenty of opportunity to introduce huge memory leaks with an ARC conversion.
|
|
#
?
Mar 14, 2012 22:34
|
|
|
It's a very nice, reliable utility, and a ton of effort has gone into making it robust, but still, just for sanity's sake, please do use source control and review the changes. Other than that, the tool tries to err on the side of making conservatively safe changes. That means that there are some patterns of code where're we going to give up and require manual intervention from the programmer. That should be a relatively modest amount of work, but who knows? One major caveat is that the utility can introduce retain cycles that you'll need to manually track down and eliminate. This is, of course, much more likely when you're migrating GC code, simply because it's unlikely that you worried about them when writing it. Also, the current utility is really designed for migrating manual retain/release code to ARC rather than migrating GC code. If you have the Mountain Lion seed available, that might be of interest.
|
|
#
?
Mar 14, 2012 22:38
|
|
|
rjmccall posted:Also, the current utility is really designed for migrating manual retain/release code to ARC rather than migrating GC code. If you have the Mountain Lion seed available, that might be of interest. So the utility in Mountain Lion's Xcode is better at converting GC code? If that's the case I'll just hold off until I start working with Mountain Lion. If the current utility doesn't handle retain cycles well, that could definitely cause a lot of issues with my current code.
|
|
#
?
Mar 14, 2012 22:49
|
|
|
Gordon Cole posted:So the utility in Mountain Lion's Xcode is better at converting GC code? If that's the case I'll just hold off until I start working with Mountain Lion. If the current utility doesn't handle retain cycles well, that could definitely cause a lot of issues with my current code. I can't really speculate here about what might be in some future Xcode release. That said, the retain-cycles thing is more of an inherent limitation (because the migrator can't really know what you object graph looks like) and not something that future updates are likely to make substantially better.
|
|
#
?
Mar 14, 2012 23:54
|
|
|
That makes sense. Thanks for the info
|
|
#
?
Mar 15, 2012 00:33
|
|
|
Well New xcode, new ios, and I still have no loving idea where this stupid simulator is saving screen-shots thanks to apples anti-feature of removing save dialogues. When the gently caress will apple realise getting rid of Save and Save as was a monumental blunder of a decision. Its not on the Desktop (I'd know, because it'd be the *only* thing on the desktop) , and its not in the ~/Library/Application Support/Developer/shared/xcode/screenshots location is empty too. duck monster fucked around with this message at 03:44 on Mar 15, 2012 |
|
#
?
Mar 15, 2012 03:41
|
|
|
duck monster posted:Well New xcode, new ios, and I still have no loving idea where this stupid simulator is saving screen-shots thanks to apples anti-feature of removing save dialogues. That's really strange, because they go directly to my desktop every time. Does your mac have some sort of strange user setup, are they going to an admin's dekstop or another user's desktop?
|
|
#
?
Mar 15, 2012 14:21
|
|
|
duck monster posted:Well New xcode, new ios, and I still have no loving idea where this stupid simulator is saving screen-shots thanks to apples anti-feature of removing save dialogues. Right-click the screenshot in the organizer and select "show in finder". Then get info. That's the only way I can ever manage to find the miserable loving things.
|
|
#
?
Mar 15, 2012 16:32
|
|
|
OK I managed to track down the problem while the wife was getting ready and it is a huge DOH on me but also a WTF on Apple (either why they ever allowed it or why it suddenly crashes). Normally, Storm Sim will clear out the GL contexts for the level meters on the NowPlaying screen when StormSim becomes inactive or backgrounded, to avoid triggering any GL calls (which will kill the app). To support random effects in Storm Sim I have to swap out the linked player when the effect changes so the NowPlaying screen will show the correct audio levels. Well it turns out that code didn't bother to check to see if the screen was locked or we were in the background. So it would compare the existing player (NULL since the screen is locked) and the new player (really just the existing one) and update it. That in turn would run through the meter's init routine. Now it still never made any draw calls but it turns out as of iOS 5.1 if you even init an EAGL CA Layer at all your app will be immediately killed, which is exactly what the meter's init routine did. TL;DR: Don't init an EAGL layer with the screen locked or your app will crash in iOS 5.1+ even though it worked fine in previous releases.
|
|
#
?
Mar 15, 2012 19:21
|
|
|
Is there any preference to doing:code:code:
|
|
#
?
Mar 15, 2012 19:29
|
|
|
I prefer the first for conciseness. It doesn't really matter though.
|
|
#
?
Mar 15, 2012 19:55
|
|
|
No good reason to do either. I do likecode:
|
|
#
?
Mar 15, 2012 20:12
|
|
|
pokeyman posted:No good reason to do either. I do like Same except I still like my @synthesize's one line per. eg. code:It's easier for me to see, and if I need to change, add, or remove it is easier to me. Probably because I use Vi-like editor and its just easier to jump to a line and 'dd' or whatever. Also for those curious, the answer to this Stackoverflow question explains fairly well: http://stackoverflow.com/questions/10314/how-do-you-name-your-instance-param-values xgalaxy fucked around with this message at 21:17 on Mar 15, 2012 |
|
#
?
Mar 15, 2012 21:11
|
|
|
Indeed, if you aren't already, adapting your code to use underscore-prefixed ivars now is a good idea for many reasons.
|
|
#
?
Mar 15, 2012 21:55
|
|
|
Also if you're subclassing a Cocoa object, use your own prefixes to avoid clashes with internal Apple-defined ivars. Like for instance if you're subclassing NSTableView to add extra functionality that can't be done via a delegate and you need to keep some stuff in ivars for that, use something like NSString *__XY_myString.
|
|
#
?
Mar 15, 2012 22:51
|
|
|
Toady posted:Indeed, if you aren't already, adapting your code to use underscore-prefixed ivars now is a good idea for many reasons. Why is that? I have an irrational, burning hatred for prefixing variable names with underscores.
|
|
#
?
Mar 15, 2012 23:00
|
|
|
EDIT: Early drafts of this post were needlessly opaque; it's open to discuss since it's been open-sourced. Some future release of Clang will provide default synthesis of properties. We went around on this a lot, but we ended up settling on adding an underscore prefix to the property name as the synthesized ivar name. Yes, sadly, this is inconsistent with the standard rule for @synthesize, which is part of why we went around on it a lot; ultimately, we felt it was better to add such a mangling, even without prior public blessing, in order to eliminate the significant risk of accidental use of the ivar vs. the property. EDIT 2: Also, we don't really care about people conflicting with our ivar names, so feel free to use simple underscore prefixes. I know there's probably still some documentation out there saying otherwise, but it is stale and should be reported. rjmccall fucked around with this message at 23:42 on Mar 15, 2012 |
|
#
?
Mar 15, 2012 23:27
|
|
|
Is mixing up the ivar and the property really a problem? I've never had that issue once myself.
|
|
#
?
Mar 15, 2012 23:54
|
|
|
I can assure you that some people feel very, very strongly about it.
|
|
#
?
Mar 16, 2012 00:04
|
|
|
Carthag posted:Also if you're subclassing a Cocoa object, use your own prefixes to avoid clashes with internal Apple-defined ivars. Like for instance if you're subclassing NSTableView to add extra functionality that can't be done via a delegate and you need to keep some stuff in ivars for that, use something like NSString *__XY_myString. This isn't necessary anymore with the modern runtime, because the compiler uses class names in ivar symbols. Gordon Cole posted:Is mixing up the ivar and the property really a problem? I've never had that issue once myself. There was a small debate over this on the developer forums, and Greg Parker made a good point (that he later posted on Twitter): quote:Our experience was that pretty much everybody gets this wrong, including our best and most experienced Cocoa developers, and the resulting bugs were hard to find and fix. Something had to change.
|
|
#
?
Mar 16, 2012 00:07
|
|
|
Gordon Cole posted:Is mixing up the ivar and the property really a problem? I've never had that issue once myself. I do it for parameters or function-local variables. For example, if I need to implement my own setter, code:The other reason was to avoid the compiler warning about shadowing ivars, though I imagine you can turn that off now.
|
|
#
?
Mar 16, 2012 00:22
|
|
|
|
| # ? May 16, 2024 14:39 |
|
|
I guess the reason I don't run into issues is that I almost always design my classes with the mindset that the properties are only for external use. But obviously that doesn't work for every situation so I can see the two getting mixed up in some cases.pokeyman posted:I do it for parameters or function-local variables. For example, if I need to implement my own setter, Yeah, if there wasn't a compiler warning about shadowing ivars with local variables I would mess that up all the time. In your setWindow: example I would personally go with calling the parameter 'newWindow' or 'theWindow'. I agree that it's kind of annoying, but underscores annoy me more, and making the parameter name ugly rather than the ivar name means the ugliness is confined to that one area rather than throughout the entire class. It's definitely a personal preference thing though.
|
|
#
?
Mar 16, 2012 00:37
|
|