|
I'm responsible for the Mac port of a library known as StormLib. Recently support for memory-mapped files was added, and I intend to bring that support over here. My code uses the Carbon File Manager to do I/O, but the only way I can find to memory-mapped files is with calls like mmap(). I could rewrite everything to just use the BSD layer, but then I would lose the ability to handle Finder aliases. How can I do what I want and not make it look godawful? If that is impossible, I will settle for godawful.
|
#
?
Apr 24, 2012 02:15
|
|
|
|
| # ? May 21, 2024 07:06 |
|
|
What's the reasoning for using carbon? I guess legacy? And if you're thinking of a rewrite of the IO code anyway, why not an Obj-C wrapper for the lib? In Obj-C you can do memory-mapping like this: [NSData dataWithContentsOfFile:@"/path/to/file" options:(NSDataReadingMappedIfSafe) error:&err]; (docs)
|
|
#
?
Apr 24, 2012 02:33
|
|
|
Any reason you can't just use the Alias Manager to resolve the aliases and use mmap() to do the dirty work?
|
|
#
?
Apr 24, 2012 02:38
|
|
|
I think we'd all like to keep the code in one file with #ifdefs for Windows, Mac and Linux. I don't know if the original developer would want to add another file just for that code.Ender.uNF posted:Any reason you can't just use the Alias Manager to resolve the aliases and use mmap() to do the dirty work? None, except that the only way I can see to do it falls under "godawful" zergstain fucked around with this message at 02:47 on Apr 24, 2012 |
|
#
?
Apr 24, 2012 02:44
|
|
|
Carbon is a dead-end. It was never meant to be a long-term API, and is pretty much deprecated at this point (no 64-bit support, Apple is moving all their Carbon apps to Cocoa).
|
|
#
?
Apr 24, 2012 02:47
|
|
|
Doc Block posted:Carbon is a dead-end. It was never meant to be a long-term API, and is pretty much deprecated at this point (no 64-bit support, Apple is moving all their Carbon apps to Cocoa). That's only true for HIToolbox stuff (UI development). I believe everything else is available in 64-bit. I know the stuff I'm using is because I've had 64-bit support in the library for ages.
|
|
#
?
Apr 24, 2012 02:52
|
|
|
As far as I can tell Carbon Core (including the Alias manager) will be deprecated in 10.8 Mountain Lion. http://www.appleinsider.com/articles/12/02/18/mountain_lion_focuses_on_cocoa_drops_x11_and_deprecates_carbon.html http://developer.apple.com/legacy/mac/library/documentation/Carbon/Reference/Carbon_Spec_Porting/Carbon_Core.html I don't know any way of getting alias support without using either Carbon or Cocoa.
|
|
#
?
Apr 24, 2012 03:21
|
|
|
I should probably clarify. The library expects a path when you open/create a file, so currently I have a bunch of code to translate the path to an FSRef, deal with the case that the file doesn't exist, and handle resolving aliases. All I can see to do is after resolving the alias, translate the path back so I could use calls like open() to get a file descriptor to pass to mmap(). So yeah, godawful. gently caress I wish there was a way to get the fd from a file opened using the File Manager. I did find a hack involving using dup() and immediately close()ing so that you know what the next fd to be used will be, but I think I should use something that I know won't break in the future. I guess if support ever goes away entirely, I'll explain that I need to put the IO wrapper functions in a .mm file. Actually, it looks like NSOpenPanel will resolve aliases for you, so I think I will just go ahead with that rewrite.
|
|
#
?
Apr 24, 2012 03:46
|
|
|
Ugh, I just spent hours trying to debug a weird framebuffer object issue. Only to find out that, when using GLKit, you have to call bindDrawable instead of just good ol' glBindFramebuffer(GL_FRAMEBUFFER, oldFBO) to switch back to the UI-provided framebuffer object.  Also, Cocos2D's system for rendering to other FBOs is really slow  . I wonder how much effort it would take to write an actual postprocessing system for Cocos2D 2.x.
|
|
#
?
Apr 24, 2012 07:38
|
|
|
So I have this problem with presentModalViewController that I can't figure out. I have a view controller 'A' that presents another view controller 'B' via presentModalViewController. This works fine. I want to present another view controller 'C' from 'B' and I've tried doing this with presentModalViewController but once the present animation has finished it unloads the entire view hierarchy back to 'A'. I even get the viewDidUnload messages :/ What is going on? I thought you could have nested modal views? It's not crashing, it simply destroys the view hierarchy back to 'A'. xgalaxy fucked around with this message at 19:38 on Apr 24, 2012 |
|
#
?
Apr 24, 2012 19:36
|
|
|
You certainly can nest modal views. Are you doing anything goofy in -viewDidAppear: or similar? If you send '-dismissModalViewControllerAnimated:' to A, it will dismiss both B and C (and so on down the line). Is that getting sent somehow?
|
|
#
?
Apr 24, 2012 20:09
|
|
|
pokeyman posted:You certainly can nest modal views. Are you doing anything goofy in -viewDidAppear: or similar? Nope haven't even written that code yet! I see it cross fade in (animation I'm using) and immediately when that animation finishes the view controllers 'B' and 'C' are popped off the view hierarchy. The only thing I can think of is that the view controller 'A' is setup non-traditionally. What I mean is, it is in its own UIWindow from the main application. This hasn't caused me any problems so far though. EDIT: Sorry, it wasn't calling viewDidUnload, its calling viewDidDisappear. And it only calls it on view controller 'B'. Here is the callstack: #0 0x000f341c in -[GGWebView viewDidDisappear:] at /src/platform/ios/GGWebView.m:170 #1 0x00ed638f in -[UIViewController _setViewAppearState:isAnimating:] () #2 0x00ed67c1 in -[UIViewController __viewDidDisappear:] () #3 0x00ed69a7 in -[UIViewController _endAppearanceTransition:] () #4 0x00ed6b55 in -[UIViewController endAppearanceTransition] () #5 0x010f5b77 in -[UIWindowController transitionViewDidComplete:fromView:toView:] () #6 0x00eb2bf2 in -[UITransitionView notifyDidCompleteTransition:] () #7 0x00eb2902 in -[UITransitionView _didCompleteTransition:] () #8 0x00eb3724 in -[UITransitionView transition:fromView:toView:] () #9 0x010f4d6c in -[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] () #10 0x00edb857 in -[UIViewController presentViewController:withTransition:completion:] () #11 0x00edb9bc in -[UIViewController presentViewController:animated:completion:] () #12 0x00edb9fc in -[UIViewController presentModalViewController:animated:] () Interesting... xgalaxy fucked around with this message at 21:31 on Apr 24, 2012 |
|
#
?
Apr 24, 2012 20:58
|
|
|
That it happens after the animation is probably a red herring; it's almost certainly being popped off beforehand, but it doesn't get displayed until the current animation finishes. It makes sense that B's -viewDidDisappear: gets called. Its view is, after all, disappearing: when C pops up modally in front of B.
|
|
#
?
Apr 24, 2012 22:02
|
|
|
pokeyman posted:That it happens after the animation is probably a red herring; it's almost certainly being popped off beforehand, but it doesn't get displayed until the current animation finishes. DOH. Yea you are correct sir. View controller 'B' was telling controller 'A' to kill the hierarchy and destroy itself and the sub UIWindow from viewDidDisappear. Commenting that delegate call in 'B' fixes everything. Just need to find a better place for 'B' to tell 'A' that its safe to unload everything. Oops!
|
|
#
?
Apr 24, 2012 22:28
|
|
|
I have an object with a number of properties on it that are not represented by @properties as they are not known at compile-time. Internally, the properties are held in NSMutableDictionary *_properties which for a key may contain either just a single value or an NSMutableOrderedSet if the property allows multiple values. So to make things more convenient I'm overriding setValue:forKey:. NB: I have a bunch more logic in there that I cut out, this is just for the example: code:
|
|
#
?
Apr 25, 2012 03:36
|
|
|
I can't speak to whether -setValue:forUndefinedKey: would make more sense, but you should be calling -will/didChangeValueForKey: so observers get the heads up.
|
|
#
?
Apr 25, 2012 03:43
|
|
|
Thanks. Notifications are firing! Edit: Holy hell there's a lot of did/will logic to implement when you're working with to-many relationships. Carthag Tuek fucked around with this message at 04:44 on Apr 25, 2012 |
|
#
?
Apr 25, 2012 04:32
|
|
|
I think technically the to-many KVO stuff is an optimization and not strictly necessary.
|
|
#
?
Apr 25, 2012 06:00
|
|
|
I tried without first, and the change dictionary was wrong. The change dictionary when I added a property had identical "old" and "new" states, both containing the property I was adding as well as what was originally there. I guess as a side effect of my weirdo internal representation? It works as expected when using [self willChange:NSKeyValueChangeInsertion valuesAtIndexes:indexSet forKey:key]; instead of the simple one. In unrelated news I just saw I have 3 watchers on my repos on github 
|
|
#
?
Apr 25, 2012 06:09
|
|
|
Oh, no, you're totally right. I was thinking of the -insertObject:inWhateverAtIndex: and stuff like that, which is for KVC, not KVO.
|
|
#
?
Apr 25, 2012 06:33
|
|
|
Why do some of my merge conflict files refuse to show up in the git merge window? I cannot get it to show the current branch and merging branch for two of my files. Without resolving the conflicts, I can't merge into the master branch. So far nothing about working with source control has made me feel more confident about my source control.
|
|
#
?
Apr 25, 2012 17:25
|
|
|
Anyone who's gone through the Big Nerd Ranch 4th edition MacOS coding book: Is it normal to have absolutely no loving idea what is happening in the NSUndoManager chapter? I understand what is happening at the beginning where he talks about the KVC proxy objects, but he doesn't really go into any detail on what the code he's adding really does or how it fits into the grand scheme of things other than "oh the nscontentarray will use these". I'm really disliking bindings because there's so much happening under the hood that I feel I'm missing out on understanding things I ought to be seeing. I'd really prefer they just used the coded version of this app instead of the bindings version In the end I've gone through it twice now and I still feel like I'm just copying lines from the book without understanding why or how they tie together.
|
|
#
?
Apr 25, 2012 19:07
|
|
|
I've had that problem in the past, but only with huge files (like 500k+ project files). Between the poor performance, and various issues I've encountered, I've ended up only using XCode's source control to commit changes to my personal branch, and occasionally updating for small changes.
|
|
#
?
Apr 25, 2012 19:07
|
|
|
A couple hours ago I asked about this on StackOverflow and the Cocos2D forum, and although that's a small amount of time to get an answer, I'm eager to hear someones insight into a common problem I have. What I have is a sprite and sprite sheet that I made properties for in a CCLayer class (JoinedMapsLayer) where my update and draw methods are. I can call a method that actually adds the sprite sheet to the layer, but I found using an instance method and class method does not work properly. Even though I point to self(JoinedMapsLayer) in my class method, it does not add the sprite sheet to it. I checked the parent object on the sprite sheet after the method is called, and it is nil. Way more details on my StackOverflow thread: http://stackoverflow.com/questions/10319666/cocos2d-cant-seem-to-create-child-sprites-correctly-using-class-or-instance-me I was stuck on a similar problem all day yesterday that I called quits on for now, but since this method is simpler, I thought I'd have an easier time explaining it thoroughly, including all the details to make more apparent what I'm doing wrong.
|
|
#
?
Apr 25, 2012 20:01
|
|
|
Zhentar posted:Between the poor performance, and various issues I've encountered, I've ended up only using XCode's source control to commit changes to my personal branch, and occasionally updating for small changes. Yeah, I ended up just nuking the whole repository. It's just me working on this, and I was mainly doing it to get comfortable with source control in general. I might give it another go for a master / update branch type thing, but drat if it hasn't been unreliable.
|
|
#
?
Apr 25, 2012 20:49
|
|
|
Martytoof posted:Anyone who's gone through the Big Nerd Ranch 4th edition MacOS coding book: (my copy is 3rd ed, but I guess it's largely the same) As I understand it: So in KVC when you use for instance -mutableArrayValueForKey:, it'll give you a proxy object. This is because a "dumb" NSMutableArray does not know which object it sits on, or what key it is on that object, or anything like that. The proxy object, however, does. So when you add something to the proxy object, it'll hook into the object it sits on and ensure that the correct notifications are being fired, etc. This is also what allows relationships in a Core Data app to maintain integrity with regards to reverse relationships. When something is added to the proxy, it goes and sets the reverse too. A lot of the power of Objective-C/Cocoa comes from the fact that selectors can be constructed programmatically. When you ask the proxy object its count, it (knowing what key it is, and on what object) will check to see if the object has a method -countOfKey and call it if it does. This allows you to set up special handling there if you need to. In the context of undo management, Hillegass takes advantage of this by adding methods to his MyDocument class that the proxy object will call when adding/removing objects. Simply put, these methods construct the reverse of the performed operation and push it to the undo stack (as well as perform the operation). See also Apple's documentation on Collection Accessor Patterns for To-Many Properties
|
|
#
?
Apr 25, 2012 21:20
|
|
|
LP0 ON FIRE posted:A couple hours ago I asked about this on StackOverflow and the Cocos2D forum, and although that's a small amount of time to get an answer, I'm eager to hear someones insight into a common problem I have. I'm not sure I read your question right, but when you use "self" in a class method, "self" is the class, as in not an instance (there is no instance).
|
|
#
?
Apr 25, 2012 21:28
|
|
|
Carthag posted:Thanks for this. I think I understand the KVC aspect of what is happening now that I've gone over it a THIRD time along with your description, but my feeling of "I'm just typing poo poo in for some reason" is that NSArrayController is a very vague concept at this stage. I realize that it'll be using these methods at some point, but there is no clear indication of what happens when. Hence I would have much preferred if he had us work with the manually coded version we did as a challenge exercise a chapter or two back rather than this NSArrayManager bound one. The best analogy to how I'm feeling is that he told us to write some code and throw it in a sealed box and things happen magically. I'm sure this will get better as I start to understand more about how NSArrayManager works. I think my post was mostly out of frustration because up to that point I'd been following the book at a steady clip and this is the first thing that really gave me the fits.
|
|
#
?
Apr 25, 2012 21:36
|
|
|
Carthag posted:I'm not sure I read your question right, but when you use "self" in a class method, "self" is the class, as in not an instance (there is no instance). I read his question the same way here (the detail on SO makes it clearer) but that's not the mistake, just slightly confusing wording. He means a pointer to 'self' in his instance code is being passed into the class method as a parameter. Line for line it's the same apart from changing 'self' to this parameter, so I can't see why it would work any different in the class method compared to the instance method. LP0: I'm not all that experienced in ObjC but I can't see any reason why your code isn't working I'm afraid. Like you, I'd expect that to work fine.
|
|
#
?
Apr 25, 2012 21:38
|
|
|
Froist posted:LP0: I'm not all that experienced in ObjC but I can't see any reason why your code isn't working I'm afraid. Like you, I'd expect that to work fine. Well dang, it really feels like I've run out of ideas here. I've tried it with two different methods, and both as instance and class methods. Maybe there's something else I have in my code that's causing it but I don't know what it is.
|
|
#
?
Apr 25, 2012 21:44
|
|
|
Oh I get it now. LP0, put a breakpoint at the beginning of your class method and try doing po layer when it throws up the debugger. If it isn't what is expected, go to the previous method in the stacktrace in the navigator in the left side of the window, and see where it's being called from. Martytoof: While it really is the best introductory book, I agree Hillegass has a tendency to gloss things over a bit. NSController and bindings in particular. I had to read those parts multiple times as well as the Apple documentation.
|
|
#
?
Apr 25, 2012 21:49
|
|
|
Carthag posted:Oh I get it now. LP0, put a breakpoint at the beginning of your class method and try doing po layer when it throws up the debugger. If it isn't what is expected, go to the previous method in the stacktrace in the navigator in the left side of the window, and see where it's being called from. I think it's what is expected: (CCLayer *) $0 = 0x004af300 <JoinedMapsLayer = 004AF300 | Tag = -1>
|
|
#
?
Apr 25, 2012 22:25
|
|
|
So hypothetically suppose I have some code that I want to allow people to drop into their iPhone app, and I'm planning on doing this as a static library. Furthermore, for sake of example, maybe I'm using the SBJSON library internal to my plugin. It's a popular library and odds are good that if someone wants to link against my static library they might also be using SBJSON too. Or, I'm incorporating the Facebook SDK, same difference. How do I avoid getting duplicate symbol issues when a user of my library goes to link? Is it sufficient to put a prefix on the class names for whatever third party dependencies I want to end up bundling in? SBJSON uses a category to inject stuff into NSString so I assume I'd need to prefix injected method names there too, but assuming categories aren't involved, do I just need to munge up the class names otherwise? kitten smoothie fucked around with this message at 22:36 on Apr 25, 2012 |
|
#
?
Apr 25, 2012 22:33
|
|
|
LP0 ON FIRE posted:I think it's what is expected: It looks right yeah. Hmm. Looking at the docs for CCNode -parent is a weak reference. Your JoinedMapsLayer is still around when you check the parent of the spriteSheet, yeah? Otherwise if would silently be nil. (E: Oh I guess you call it right after. Yeah it should still be around then if you're in the same method). Try with a breakpoint right after [layer addChild:spriteSheet z:13]; maybe and seeing what the parent is then? You can do that with po [spriteSheet parent]. Basically if that is correct, step through the code and do the po again and see when it goes away. Carthag Tuek fucked around with this message at 22:47 on Apr 25, 2012 |
|
#
?
Apr 25, 2012 22:45
|
|
|
Carthag posted:Try with a breakpoint right after [layer addChild:spriteSheet z:13]; maybe and seeing what the parent is then? You can do that with po [spriteSheet parent]. Basically if that is correct, step through the code and do the po again and see when it goes away. With po [spriteSheet parent] right after [layer addChild:spriteSheet z:13]; I get (CCNode *) $0 = 0x00000000 <nil>.
|
|
#
?
Apr 25, 2012 23:40
|
|
|
What the gently caress. Just to be sure, JoinedMapsLayer is a descendant of CCNode (through CCLayer), and you haven't overridden any of the CCNode-inherited methods? I haven't used cocos2d but I assume CCNode's addChild: and its ilk are supposed to set the parent right? I'm out of ideas.
|
|
#
?
Apr 25, 2012 23:50
|
|
|
lord funk posted:Yeah, I ended up just nuking the whole repository. It's just me working on this, and I was mainly doing it to get comfortable with source control in general. I might give it another go for a master / update branch type thing, but drat if it hasn't been unreliable. I have stuck with MacHG/mercurial for partly this reason (and also because bitbucket.org has free repositories for just a few devs and didn't support git until recently) but all of my experiences with Xcode git support makes me very happy to stick with that choice. The timeline stuff would be great but on projects of any size it just seems to choke. Give it a few versions and it will get better. I presume that some day they will just have it commit in the background so theres no more saving at all just like regular apps.
|
|
#
?
Apr 26, 2012 00:34
|
|
|
Carthag posted:What the gently caress. I don't think I overrid any of the CCNode inherited methods. Does the thing in bold have to do with what you just said about addChild and setting the parent? http://forums.somethingawful.com/showthread.php?threadid=3400187&userid=0&perpage=40&pagenumber=54#post402701244 I know it may not directly relate, but because I'm using a class method the parent doesn't get set?
|
|
#
?
Apr 26, 2012 00:42
|
|
|
LP0 ON FIRE posted:With po [spriteSheet parent] right after [layer addChild:spriteSheet z:13]; I get (CCNode *) $0 = 0x00000000 <nil>. I responded to your StackOverflow question. I'm not 100% but something smells about what you are doing accessing the ivars directly in your first example - it should be self.selectionScreenOverlaySpriteSheet. In your second, your shared method is immediately overwriting it's parameters. The newly created spriteSheet will not be passed back to the caller. Whatever value was passed in is immediately thrown away and the new spriteSheet is not referenced anywhere unless the layer holds a strong reference to it. If you are on ARC, it is possible the compiler is releasing it after the call to the layer since it is no longer accessible to your code. It has no obligation to wait until the method returns. Edit: and if you aren't using ARC then assigning the ivar directly like your first example bypasses the property retain logic so who knows what the lifetimes if your objects are. In the static version one would presume the layer retains the object but you shouldn't depend on that. Simulated fucked around with this message at 00:57 on Apr 26, 2012 |
|
#
?
Apr 26, 2012 00:48
|
|
|
|
| # ? May 21, 2024 07:06 |
|
|
LP0 ON FIRE posted:I don't think I overrid any of the CCNode inherited methods. Yeah that says that the parent should indeed get set when using addChild: so on the face of it, you're doing that part correctly. I think Ender.uNF is onto something.
|
|
#
?
Apr 26, 2012 01:09
|
|