|
By the way, are you guys using LLDB instead of GDB now? As far as I can tell, LLDB cannot evaluate an expression to save its life. The bug is supposedly fixed in Xcode 4.4, but I don't understand how a debugger is even shippable like this. https://devforums.apple.com/message/623694#623694
|
#
?
May 6, 2012 18:35
|
|
|
|
| # ? May 21, 2024 07:52 |
|
|
I assume 4.4 will be backported to 10.7 right? RIght now it's a 10.8 only beta thing, but I can't imagine that wouldn't be the case.
|
|
#
?
May 6, 2012 18:42
|
|
|
Martytoof posted:I assume 4.4 will be backported to 10.7 right? RIght now it's a 10.8 only beta thing, but I can't imagine that wouldn't be the case. It is supported on Lion. In fact, if you install the DP app on a Lion box, it should run just fine there. I wasn't actually sure if I could say that publicly, but Chris Lattner verified it in the thread Hog Obituary just linked, so there you go. 
|
|
#
?
May 6, 2012 21:55
|
|
|
Whaaaaat and all this time I've been booting my ML vmware image to play with 4.4  Thanks for the tidbit though
|
|
#
?
May 6, 2012 22:28
|
|
|
Ender.uNF posted:Of course not everything in C++11 is intelligent. Their lambda syntax sucks balls. I understand wanting to be able to declare whether the captured variables are by-ref or by-val but the [] should be optional and in that case capture any referenced vars and have the compiler default to by-val const. That would (IMHO) cover the 99% case without requiring you to stop and think about it. I agree that implicitly capturing values should be the default, but the language would be really hard to parse without something in front saying "hey, this is a lambda", because the next token is either a '(' or a '{', and those are pretty overloaded already. That's why block expressions start with a caret: it's totally unambiguous, since there isn't a unary caret operator. Ender.uNF posted:I think the way Apple designed Objective-C blocks is beautiful and makes way more sense - the rules are somewhat along those lines. Regular vars are copied by-val, except if qualified with __block in which case they are still stack-allocated unless you call Block_copy, then they get promoted to heap variables (Block_copy is generally required for a block to be useful outside its containing scope). Blocks were designed a bit before I got here, and there are a few aspects of the design that I'm really not satisfied with. The most important is that forcing programmers to worry about Block_copy is really unfortunate; the compiler should be allocating the block on the heap by default and treating stack-allocation as an optimization when a block provably doesn't escape (maybe the user can specifically request this optimization). The second objection is that the syntax is geared heavily towards center-embedding blocks (i.e. just writing them where you're using them), which is great for tiny blocks and really terrible for big ones; it's relatively awkward to define a block function on one line and then use it later on, and yet there are lots of use cases for doing exactly that. The third objection is that defining a recursive block (e.g. a dispatch_async block which can re-enqueue itself) is extremely awkward. The last objection is that, while implicit capture is a great default, it would be nice to be able to list the captures explicitly and maybe attribute them up (e.g. to request that a value be captured weakly). But overall I tend to agree that the block design is pretty good. Ender.uNF posted:On the other hand: about loving time with enums and that is something I'd like to see in C/Objective-C post-haste. Dumping all the enum members into the global namespace is the dumbest idea in the history of computer science, requiring everyone to essentially repeat the name of the enum in every member (except where the enum name is at the end for some enums in which case the Intellisense/hints are less than useless in showing you your options). On the one hand, I agree; on the other hand, at this point we can't fix this in the case where it really matters, namely the massive lists of enumerated constants in the system headers.
|
|
#
?
May 6, 2012 22:32
|
|
|
Is there a way to determine what kind of event is putting the application in the background? Are there any calls/events I can listen for other than "applicationWillResignActive" and "applicationDidEnterBackgriund:" events?
|
|
#
?
May 6, 2012 22:49
|
|
|
Can someone explain this code from the CocoaAsyncSocket library:code:I'm assuming this is an idiom of some sort? I didn't have any luck searching around. Does he do it because the queue the delegate is invoked in may not have an autorelease pool? Ie: A preventative measure?
|
|
#
?
May 6, 2012 23:47
|
|
|
Carthag posted:The Obj-C language mailing list has an interesting discussion on a proposed feature, Range literals: Just do: NSRange range = { 0, 9 };
|
|
#
?
May 7, 2012 17:19
|
|
|
rjmccall posted:I agree that implicitly capturing values should be the default, but the language would be really hard to parse without something in front saying "hey, this is a lambda", because the next token is either a '(' or a '{', and those are pretty overloaded already. That's why block expressions start with a caret: it's totally unambiguous, since there isn't a unary caret operator. True, I guess I'm just used to => from C#. Of course it will use type inference to construct a lambda so you can do crazy poo poo like "items.Where(item => item.IsFizzyWizz)". I am trying to think if there is any way to make that work in Objective-C. quote:Blocks were designed a bit before I got here, and there are a few aspects of the design that I'm really not satisfied with. The most important is that forcing programmers to worry about Block_copy is really unfortunate; the compiler should be allocating the block on the heap by default and treating stack-allocation as an optimization when a block provably doesn't escape (maybe the user can specifically request this optimization). The second objection is that the syntax is geared heavily towards center-embedding blocks (i.e. just writing them where you're using them), which is great for tiny blocks and really terrible for big ones; it's relatively awkward to define a block function on one line and then use it later on, and yet there are lots of use cases for doing exactly that. The third objection is that defining a recursive block (e.g. a dispatch_async block which can re-enqueue itself) is extremely awkward. The last objection is that, while implicit capture is a great default, it would be nice to be able to list the captures explicitly and maybe attribute them up (e.g. to request that a value be captured weakly). Good point... It is also really annoying that you can't test the type of a block. Obviously there is nothing like generics and it somewhat relates to the bullshit that @encode spits out, but I wish there was a runtime way to capture and work with the type information so I could ask [block hasSignature:xyz]. The rub is what goes in the xyz part. quote:On the one hand, I agree; on the other hand, at this point we can't fix this in the case where it really matters, namely the massive lists of enumerated constants in the system headers. True but if we don't start somewhere, it will be 10 years later and everyone will still prefixing class names and running into collisions. I followed the namespaces proposal on the mailing list a bit and I always thought that he was wrong about not allowing something to be in two namespaces. If you allow Apple stuff to live in the null namespace and a com.Apple namespace then you can just announce that namespaces are optional for the next two major releases but will be mandatory, so update you code to start using Animation.CurveEaseIn instead of UIAnimationCurveIn. xgalaxy posted:Can someone explain this code from the CocoaAsyncSocket IIRC a dispatch queue doesn't automatically have an enclosing autorelease pool so you have to create one.
|
|
#
?
May 8, 2012 23:17
|
|
|
Why doesn't this work?code:
|
|
#
?
May 9, 2012 06:58
|
|
|
I'm guessing it's a race condition. The code works with a sleep() or delayed perform between the two -start calls. I haven't used NSOperations before, but from what I can tell they can be both concurrent and non-. So possibly, a non-concurrent NSOperation might execute on another thread (and its isConcurrent/isExeecuting/isFinished are then used to determine whether others can run). Since they're called so close, the first NoOp is actuall still running (simply hasn't returned yet) while the second gets called.
|
|
#
?
May 9, 2012 07:22
|
|
|
Why the poo poo did apple implement these storyboard segues with a prepareforsegue method that despite its name is concurent with the segue rather than preparing (therefore before), and no way of cancelling the loving segue. I've spent 3 hours trying to figure out the secret method to cancel a segue when the form dont validate and welp, cant be done whoops. gently caress you apple, put some thought into these things please.
|
|
#
?
May 9, 2012 07:30
|
|
|
Carthag posted:I'm guessing it's a race condition. The code works with a sleep() or delayed perform between the two -start calls. Good catch on the sleep or delayed perform. This still doesn't add up though. The operation I have there is not a "concurrent" operation (what a terrible choice of word). My understanding is that "concurrent" operations were required to start their own thread or otherwise implement asynchronicity themselves. (I say "were" because, I believe, as of OS X 10.6 NSOperationQueue doesn't bother with "concurrent" or not and always pretends it's not.) If you simply override -main, you should get a synchronous operation (and it's up to an NSOperationQueue to take it to a background thread or queue). And the operation indeed appears to run on the main thread, and even complete: code:
|
|
#
?
May 9, 2012 07:55
|
|
|
I tried setting a symbolic breakpoints on -[NSOperation isReady] & isFinished and from what I can tell, when you add the dependency, it sets up KVO so second watches first. Also, I do see some KVO/GCD stuff relating to those breakpoints happening on other threads with those breakpoints, so maybe KVO uses GCD to send some state to dependants? I'm not very good at LLDB 
|
|
#
?
May 9, 2012 08:29
|
|
|
Has anyone managed to get a Core Data based app syncing reliably with iCloud yet? From what I've seen on the developer forums, while iCloud is working for document based apps, Core Data + iCloud is still kind of a clusterfuck.
|
|
#
?
May 9, 2012 09:51
|
|
|
Is there any way to interface with FCP 7 in a meaningful way? I'm working on a waveform analyzer for synchronizing clips, and rather than synchronizing an entire exported XML sequence (like pluraleyes), I want to just be able to highlight a couple of clips and have it work on them. All I'm coming up with is playing the clips manually and rerouting the output through something like jack. Does FCP have some API I'm not aware of? (Aside from FXplug or whatever it is).
|
|
#
?
May 9, 2012 09:53
|
|
|
duck monster posted:Why the poo poo did apple implement these storyboard segues with a prepareforsegue method that despite its name is concurent with the segue rather than preparing (therefore before), and no way of cancelling the loving segue. As far as I can tell, -prepareForSegue:sender: is for setting data on the destination view controller. Why not validate before initiating the segue yourself? Edit: 5-second Google search found StackOverflow - Xcode storyboard cancel push if a condition is not met
|
|
#
?
May 9, 2012 17:31
|
|
|
Toady posted:As far as I can tell, -prepareForSegue:sender: is for setting data on the destination view controller. Why not validate before initiating the segue yourself? Yeah I did that. It just seems like apple missed a very obvious way of making the whole thing a lot more elegant. If that method took the segue as its function that the storyboard was proposing, and you could either pass it back out its arse to say "Keep doing this!" modify the segue to do another one , ie "This guy isnt authenticated how about we do the segue to authentication instead" or alternatively Null meaning "Ah gently caress it, this is boring and the poo poo isnt ready to go yet", it would pack a tonne of power into a single method that'd be very easy to work with.
|
|
#
?
May 9, 2012 17:39
|
|
|
You should file a feature request for that kind of method, explaining your usage situation. Bug Reporter is the best way to bitch at engineers (politely, of course).
|
|
#
?
May 9, 2012 18:00
|
|
|
You should stop throwing a hissy fit every time your non-standard usage case doesn't line up with the way the API is designed. Also, big catch-all do-all methods are usually anything but elegant IMHO. The method responsible for loading data into the new view is not the place to decide whether or not the view should even be shown.
|
|
#
?
May 9, 2012 20:47
|
|
|
I've made a simple Mac OSX app that I'd like to release on the app store. I had it all working on my dev machine, added a mac developer license to my developer account, etc. I started going through the the "preparing your app" guide on developer.apple.com, set up provisioning and a bundle ID (correctly, I think) and now my app won't run - if I build it and run, the window doesn't pop up. The build completes successfully, the console pops up, etc, but my app window never arrives. I've tried backing out the changes I made to my targets, but nothing works. Is there a good and simple guide to the release process? The existing documentation makes my head spin sometimes. Also, is there some quick summary of the settings I can link/paste here for you guys to diagnose? Thanks! EDIT: VVVV not a dumb question at all! I opened the app up again and tested that, but it's not a document based app. Fate Accomplice fucked around with this message at 22:14 on May 9, 2012 |
|
#
?
May 9, 2012 21:53
|
|
|
I guess this is like a really dumb question, but do you have a document based app? If so, did you close the only window last time you opened the app? If you hit Cmd-N does your window show up? I'm not some kind of amazing developer but I've run across that a few times going through the Big Nerd Ranch book.
|
|
#
?
May 9, 2012 22:12
|
|
|
Did the defaults somehow get tweaked so that the window is in a weird space or size? Maybe resize and repoisition the NSWindow on init or something to something you know will work.
|
|
#
?
May 10, 2012 01:42
|
|
|
Doc Block posted:You should stop throwing a hissy fit every time your non-standard usage case doesn't line up with the way the API is designed. Sure as long as "validating input" is not considered a standard useage case. The problem is , there isnt a way of saying "Hey you should not follow that segue, short of ripping it out. It in effect disconnects the prototyping capacity of storyboards from the implementation capacity, and the simple inclusion of one method would have fixed that. It just seems a huge oversight.
|
|
#
?
May 10, 2012 06:10
|
|
|
UI should always be responsive on iOS, are you arguing for action that can be initiated and 'taken back'? The ideal is to not allow that interaction to be started in the first place. You can create segues that aren't attached to buttons or gestures, and just call them by Identifier. And they are still in IB.
|
|
#
?
May 10, 2012 20:20
|
|
|
Kallikrates posted:UI should always be responsive on iOS, are you arguing for action that can be initiated and 'taken back'? The ideal is to not allow that interaction to be started in the first place. You can create segues that aren't attached to buttons or gestures, and just call them by Identifier. And they are still in IB. But nothing in my suggestion removes responsiveness? You press the button, it pops up and says "Dude, fill in the password first". Removing the segue from the button, as is currently necessary leaves a wholly superfluous disconnect between prototyping and implementation, leading me to wonder why it was put there in the first place. All I'm saying is that there should be a way to sanity check the segue whilst still letting you use the storyboard created in the prototype. logic free UIs are of very limited use, and as it stands, the current implementation of button segues has a limited use case that could have been easily expanded with a very simple addition to the api. hell a canSegue:(uisegue *)segue method would be *perfect*. duck monster fucked around with this message at 23:27 on May 10, 2012 |
|
#
?
May 10, 2012 23:24
|
|
|
Can you create a custom segue and override -perform to do what you want? e.g. have it call -canSegue: on the source view controller?
|
|
#
?
May 10, 2012 23:39
|
|
|
Hey pokeyman did you figure out the NSOperation thing? I was looking at the docs some more because I might use them for another project, but they provide too little control in terms of re-ordering so I'll just stick with a GCD timer popping off custom operation NSObjects from a queue that's basically an ordered collection. But the thing that struck me in the docs is that they make a big deal out of the isStatus booleans that they're firing off KVO notifications, so I'm pretty sure once you introduce dependencies, you're not supposed to start them yourself anymore, but use the NSOperationQueue. I figure the flow is something like: (operation B depends on operation A) - A & B are added to Q - A fires "isReady" notification (B doesn't because of dep) - Q starts A - A finishes, sets isFinished - A fires "isFinished" notification - B receives notification, sets isReady - B fires "isReady" notification - Q receives notification, sends start to B
|
|
#
?
May 10, 2012 23:52
|
|
|
I'm trying to figure out if we need to join the MFi program to control one of our hardware products over Bluetooth. Searching the iOS developer site I get some confusing information. There is a CoreBluetooth Temperature Sensor example which says it shows how to read/write/notify a remote device. The ReadMe doesn't say anything about MFi ( although maybe it's implied? ) and just says you need a Bluetooth LE Device. This Technical Q&A says you need to join MFi to connect to something over Bluetooth but it's older than the previous link.
|
|
#
?
May 11, 2012 18:54
|
|
|
fankey posted:I'm trying to figure out if we need to join the MFi program to control one of our hardware products over Bluetooth. Searching the iOS developer site I get some confusing information. There is a CoreBluetooth Temperature Sensor example which says it shows how to read/write/notify a remote device. The ReadMe doesn't say anything about MFi ( although maybe it's implied? ) and just says you need a Bluetooth LE Device. This Technical Q&A says you need to join MFi to connect to something over Bluetooth but it's older than the previous link. You can use Bluetooth LE devices via CoreBluetooth without joining MFi and certifying. This support is new to iOS 5.
|
|
#
?
May 11, 2012 20:25
|
|
|
Cerebral Mayhem posted:I want to display a large amount of scrolling, changing text in real time. By way of example in C: Did you ever get a good solution to this? I'm going to be tackling something very similar shortly.
|
|
#
?
May 11, 2012 23:21
|
|
|
God drat Xcode is a piece of poo poo sometimes. It always seems to gently caress up when you are doing multiple targets and what you see in the interface is not what matches up with whats going on in the pbxproj. Always, always end up with dead XCConfigurationLists, duplicates, schemes out of sync, etc. xgalaxy fucked around with this message at 23:38 on May 11, 2012 |
|
#
?
May 11, 2012 23:25
|
|
|
duck monster posted:But nothing in my suggestion removes responsiveness? You press the button, it pops up and says "Dude, fill in the password first". I agree that validation should be something more built-in (along with some data binding/mapping ala Sensible Table View or RestKit TableController) But in this case I think the appropriate thing would be to create a method that checks the preconditions for further segues and either hides or disables the associated control if the segue isn't valid at this moment in time, then have event handlers call this method (should be able to hook all the relevant actions up to the same handler for the most part). In that case the "Login" button will never be enabled until the password has been provided. Thus no need for after the fact form validation. (It would be nice if you could wire that up entirely in IB but fat chance). It was a real switch in thinking for me personally - I was stuck in the more traditional "popup error when user hits save" mentality but if you just handle everything live it makes for a better user experience.
|
|
#
?
May 12, 2012 04:30
|
|
|
I wanted to run Xcode fullscreen in its own space, and I wanted to have a debug window in the desktop space behind my app during testing so I could see console output. I double-clicked to create a new secondary window and expanded the debug area to fill the whole thing. I was happy. Then I closed the main project window before I closed the debug window.
|
|
#
?
May 12, 2012 04:34
|
|
|
I get an exception in my code:code:code:
Carthag Tuek fucked around with this message at 15:49 on May 12, 2012 |
|
#
?
May 12, 2012 15:40
|
|
|
lord funk posted:Did you ever get a good solution to this? I'm going to be tackling something very similar shortly. No, I'm still looking. I need to find a way to force a window refresh while I'm still in my loop. I'm basically trying to recreate an old-school console output window to port some of my older C programs.
|
|
#
?
May 12, 2012 16:00
|
|
|
Cerebral Mayhem posted:No, I'm still looking. I need to find a way to force a window refresh while I'm still in my loop. I'm basically trying to recreate an old-school console output window to port some of my older C programs. Could you run your loop on a dispatch_queue but have your draw text call do a dispatch_sync on the main queue? The cross-thread communications might slow things down but it should give the main loop a chance to run and update the UI while not letting the loop get ahead until the output has been drawn.
|
|
#
?
May 12, 2012 16:29
|
|
|
Carthag posted:So I check out the dictionary in the debugger, and it has a key/value pair of (null) = (null);?!? How does this dictionary get created? Where are objects added to it?
|
|
#
?
May 12, 2012 18:09
|
|
|
Carthag posted:Now how the hell did I manage to put that in? As far as I know that shouldn't be possible? The docs say that it'll raise an exception (setObject:forKey:) or attempt to remove the key/value pair (setValue:forKey:) so it can't be those... I believe you can get NULLs into a dictionary using the CoreFoundation C API, and when toll-free bridged it will show up as a dictionary with nulls. You aren't supposed to do that but
|
|
#
?
May 12, 2012 18:30
|
|
|
|
| # ? May 21, 2024 07:52 |
|
|
It's an ivar, NSMutableDictionary *_properties; Gets initialized during -init like so: _properties = [NSMutableDictionary dictionary]; I only put stuff in via setObject:forKey: - but I just now see that it isn't thread-safe, and I actually did that in a concurrent enumeration on an array, so could that possibly be it (the allValues call being called right in the middle of something being added meaning the "space" has been created for the key/value pair, but it hasn't been set to anything yet).
|
|
#
?
May 13, 2012 01:43
|
|