Re: The cost of using objects rather than plain C variables
Hi! Thanks to all for your quick and kind answers. > You're comparing apples to oranges. That’s a nice way of putting it! > You were storing strings for each numeric value, now you're storing doubles. Actually just floats, in order to save space. > You could have tried NSNumber objects instead of strings, but better would be > a custom object which holds the three doubles as ivars. The former uses > three objects per vertex, the latter using one object. I have tried NSNumber, but it didn’t save much space. I was unable to notice any significant gain. > Before you go much further, though, are you sure the memory was not just a > high-water mark due to accumulation of autoreleased objects? ARC isn't > magic. It doesn't relieve you of _all_ need to think about memory management > and the proper deployment of autorelease pools is one of the things you still > have to consider. I have put an @autorelease pool around the decoding code, but it didn’t change anything. You’re right, I think: the culprit is that the runloop never gets any opportunity to complete, so the autorelease pool cannot be drained. At a certain point, I receive a memory warning and shut all down. If I had run the decoding on a background thread, for example with [self performSelectorInBackground: withObject:] (which I ended up doing anyway, because I wanted to animate a UIProgressBar to keep the user informed of what was going on), would it have solved this issue? > > All of that said, though, it's perfectly reasonable to use C structs and > arrays for large collections of simple data types. I would not expect that > Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful). I plainly agree my initial scheme could have been vastly improved, even sticking with Obj-C objects, but I was really struck by the figures I got. Is there any hope in the future to be able to store simple types like int or floats in NSArrays? Thanks again to all for your enlightening comments and kindness! Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
Quincey, > Each NSString has at least 4 bytes of overhead (the 'isa' pointer); each > character is UTF-16; each object is a multiple of 16 bytes. Your values may > not fit in the remaining 12 bytes of the smallest object (an input format > something like '0.xe-nn', which isn't an unlikely format, wouldn't fit in 12 > bytes, even with only 1 significant digit in the mantissa). Well, I store GLshorts, GLfloats and GLints. The GLFloat is formatted like 0.xyztuvw I think, never more than seven digits after the decimal separator. But you’re right: I overlooked the UTF-16 default coding that doubles the size every ascii string. My initial reasoning was very (too) simple: I have a 20 MB file made up of strings, if I store those strings in objects, even with a small overhead, it should not top 30 or 40 MB. It turned out I was plainly wrong, at least the way I implemented it. > Actually, that's not so bad. 33-50MB instead of 20MB, for the objectified vs > scalar representation, isn't unbearable, I suspect. However, the C array of > scalars is probably the best choice. Well, the plain C way, I suspect, is also quicker. With the decoding taking around 30 seconds or so, I had better optimizing speed, too! Cheers and thanks a lot once again! Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTextField / NSSecureTextField toggl
Hello List, I'm somewhat heading down a road of pain with this. Maybe I approach the problem from the wrong angle, so I wanted to ask for advice. My goal is to have a NSTextField that can be toggled to display a Password in clear or bulleted format. Sort of NSTextField - NSSecureTextField I'm using a custom NSTextFieldCell to get a different look of the cell and also to add a toggle Button inside the Field. The drawing of the actual control is easy. As I can use a NSSecureTextField cell to draw hidden, and my normal cell to draw unhidden passwords. The point where I'm struggling is the field editor. My solutions (with none working fully) #1 Use a NSSecureTextField and supply a standard NSTextView Field editor to display plain text That's not working, as NSSecureTextField demands a NSSecureTextField as it's field editor. So the only way would be to subclass private API and buble all calls up to NSTextView's implementation. #2 Use a NSTextField and supply a custom FieldEditor that can draw bullets like the NSSecureTextField can. This leads to a custom NSLayoutManager and then the problems start. I tried supplying my own implementation of - (NSUInteger)getGlyphsInRange:(NSRange)glyphRange glyphs:(NSGlyph *)glyphBuffer characterIndexes:(NSUInteger *)charIndexBuffer glyphInscriptions:(NSGlyphInscription *)inscribeBuffer elasticBits:(BOOL *)elasticBuffer bidiLevels:(unsigned char *)bidiLevelBuffer; - (void)drawGlyphsForGlyphRange:(NSRange)glyphsToShow atPoint:(NSPoint)origin but I'm having difficulties with custom fonts, like if someone uses emojis I'm unable to get the correct character count, as emojis consist of 2bytes, not 1. The string length gets reported with 2. And the drawing is done a bit lower than the normal bullets. I'm beginning to think, that I'm at a very low level – even too low – and this problem can be dealt with at much higher points, but thus far I've not found a way to do it. Maybe I should spent some weeks digging through al the text system documentation :-( #3 An NSTabView with the two input fields side by side and just toggle them back and forth. Might be the easy way out but it seemed so overblown to use so many views for this "simple" problem. Maybe it's the simples solution altogether. -Michael ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField / NSSecureTextField toggl
Well, turns out you can use NSString's: - (void)enumerateSubstringsInRange:options:usingBlock: Using the NSStringEnumerationByComposedCharacterSequences option, you get the actual character count. But that's just a little bit nearer to the solution, as I'm guessing I need to intervene earlier to prevent the glyph count to got to hight. -Michael On 07.07.2013, at 14:46, Michael Starke wrote: > Hello List, > > I'm somewhat heading down a road of pain with this. Maybe I approach the > problem from the wrong angle, so I wanted to ask for advice. > > My goal is to have a NSTextField that can be toggled to display a Password in > clear or bulleted format. Sort of NSTextField - NSSecureTextField > I'm using a custom NSTextFieldCell to get a different look of the cell and > also to add a toggle Button inside the Field. > > The drawing of the actual control is easy. As I can use a NSSecureTextField > cell to draw hidden, and my normal cell to draw unhidden passwords. > > The point where I'm struggling is the field editor. > > My solutions (with none working fully) > > > #1 Use a NSSecureTextField and supply a standard NSTextView Field editor to > display plain text > That's not working, as NSSecureTextField demands a NSSecureTextField as it's > field editor. So the only way would be to subclass private API and buble all > calls up to NSTextView's implementation. > > #2 Use a NSTextField and supply a custom FieldEditor that can draw bullets > like the NSSecureTextField can. > > This leads to a custom NSLayoutManager and then the problems start. > > I tried supplying my own implementation of > > - (NSUInteger)getGlyphsInRange:(NSRange)glyphRange >glyphs:(NSGlyph *)glyphBuffer > characterIndexes:(NSUInteger *)charIndexBuffer > glyphInscriptions:(NSGlyphInscription *)inscribeBuffer > elasticBits:(BOOL *)elasticBuffer >bidiLevels:(unsigned char *)bidiLevelBuffer; > > - (void)drawGlyphsForGlyphRange:(NSRange)glyphsToShow atPoint:(NSPoint)origin > > but I'm having difficulties with custom fonts, like if someone uses emojis > I'm unable to get the correct character count, as emojis consist of 2bytes, > not 1. The string length gets reported with > 2. And the drawing is done a bit lower than the normal bullets. > > I'm beginning to think, that I'm at a very low level – even too low – and > this problem can be dealt with at much higher points, but thus far I've not > found a way to do it. > > Maybe I should spent some weeks digging through al the text system > documentation :-( > > #3 An NSTabView with the two input fields side by side and just toggle them > back and forth. > Might be the easy way out but it seemed so overblown to use so many views for > this "simple" problem. Maybe it's the simples solution altogether. > > > -Michael > > > ___m i c h a e l s t a r k e > geschäftsführer > HicknHack Software GmbH > www.hicknhack-software.com > > ___k o n t a k t > +49 (170) 3686136 > cont...@hicknhack.com > > ___H i c k n H a c k S o f t w a r e G m b H > geschäftsführer - maik lathan | andreas reischuck | michael starke > bayreuther straße 32 > 01187 dresden > amtsgericht dresden HRB 30351 > sitz - dresden > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/michael.starke%40hicknhack-software.com > > This email sent to michael.sta...@hicknhack-software.com ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField / NSSecureTextField toggl
I reckon this code of mine is what you want: https://github.com/karelia/SecurityInterface/blob/master/README.md Mike. Sent from my iPhone On 7 Jul 2013, at 13:46, Michael Starke wrote: > Hello List, > > I'm somewhat heading down a road of pain with this. Maybe I approach the > problem from the wrong angle, so I wanted to ask for advice. > > My goal is to have a NSTextField that can be toggled to display a Password in > clear or bulleted format. Sort of NSTextField - NSSecureTextField > I'm using a custom NSTextFieldCell to get a different look of the cell and > also to add a toggle Button inside the Field. > > The drawing of the actual control is easy. As I can use a NSSecureTextField > cell to draw hidden, and my normal cell to draw unhidden passwords. > > The point where I'm struggling is the field editor. > > My solutions (with none working fully) > > > #1 Use a NSSecureTextField and supply a standard NSTextView Field editor to > display plain text > That's not working, as NSSecureTextField demands a NSSecureTextField as it's > field editor. So the only way would be to subclass private API and buble all > calls up to NSTextView's implementation. > > #2 Use a NSTextField and supply a custom FieldEditor that can draw bullets > like the NSSecureTextField can. > > This leads to a custom NSLayoutManager and then the problems start. > > I tried supplying my own implementation of > > - (NSUInteger)getGlyphsInRange:(NSRange)glyphRange >glyphs:(NSGlyph *)glyphBuffer > characterIndexes:(NSUInteger *)charIndexBuffer > glyphInscriptions:(NSGlyphInscription *)inscribeBuffer > elasticBits:(BOOL *)elasticBuffer >bidiLevels:(unsigned char *)bidiLevelBuffer; > > - (void)drawGlyphsForGlyphRange:(NSRange)glyphsToShow atPoint:(NSPoint)origin > > but I'm having difficulties with custom fonts, like if someone uses emojis > I'm unable to get the correct character count, as emojis consist of 2bytes, > not 1. The string length gets reported with > 2. And the drawing is done a bit lower than the normal bullets. > > I'm beginning to think, that I'm at a very low level – even too low – and > this problem can be dealt with at much higher points, but thus far I've not > found a way to do it. > > Maybe I should spent some weeks digging through al the text system > documentation :-( > > #3 An NSTabView with the two input fields side by side and just toggle them > back and forth. > Might be the easy way out but it seemed so overblown to use so many views for > this "simple" problem. Maybe it's the simples solution altogether. > > > -Michael > > > ___m i c h a e l s t a r k e > geschäftsführer > HicknHack Software GmbH > www.hicknhack-software.com > > ___k o n t a k t > +49 (170) 3686136 > cont...@hicknhack.com > > ___H i c k n H a c k S o f t w a r e G m b H > geschäftsführer - maik lathan | andreas reischuck | michael starke > bayreuther straße 32 > 01187 dresden > amtsgericht dresden HRB 30351 > sitz - dresden > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mabdullah%40karelia.com > > This email sent to mabdul...@karelia.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
Sent from my iPhone On 2013/07/07, at 16:33, Vincent Habchi wrote: > Hi! > Thanks to all for your quick and kind answers. > >> You're comparing apples to oranges. > > That’s a nice way of putting it! > >> You were storing strings for each numeric value, now you're storing doubles. > > Actually just floats, in order to save space. > >> You could have tried NSNumber objects instead of strings, but better would >> be a custom object which holds the three doubles as ivars. The former uses >> three objects per vertex, the latter using one object. > > I have tried NSNumber, but it didn’t save much space. I was unable to notice > any significant gain. > >> Before you go much further, though, are you sure the memory was not just a >> high-water mark due to accumulation of autoreleased objects? ARC isn't >> magic. It doesn't relieve you of _all_ need to think about memory >> management and the proper deployment of autorelease pools is one of the >> things you still have to consider. > > I have put an @autorelease pool around the decoding code, but it didn’t > change anything. You’re right, I think: the culprit is that the runloop never > gets any opportunity to complete, so the autorelease pool cannot be drained. > At a certain point, I receive a memory warning and shut all down. If I had > run the decoding on a background thread, for example with [self > performSelectorInBackground: withObject:] (which I ended up doing anyway, > because I wanted to animate a UIProgressBar to keep the user informed of what > was going on), would it have solved this issue? >> >> All of that said, though, it's perfectly reasonable to use C structs and >> arrays for large collections of simple data types. I would not expect that >> Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful). > > I plainly agree my initial scheme could have been vastly improved, even > sticking with Obj-C objects, but I was really struck by the figures I got. Is > there any hope in the future to be able to store simple types like int or > floats in NSArrays? > http://www.cocoaintheshell.com/2010/12/collections-integers-performances/ You can put pointers to plain old C types in a CFArray or CFMutableArray Always consider Core Foundation collections when looking for performance ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:33 AM, Vincent Habchi wrote: > Is there any hope in the future to be able to store simple types like int or > floats in NSArrays? Why? What's wrong with a simple array? (Or, I would argue, though it's not a popular strategy, what's wrong with std::vector?) Now if you really want speed, stop converting from text to floats, convert the file to a binary format containing floats before your users have to load it. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
Hi! You’re right to point that CFtypes exist: I often overlook these and that’s stupid of me. > Why? What's wrong with a simple array? Nothing. Well, at first, I was looking for a self expanding array, given that I didn’t know the size beforehand. > (Or, I would argue, though it's not a popular strategy, what's wrong with > std::vector?) Oh, just that since I moved from plain BSD/Qt3 to MacOS/Cocoa, I swore not to write any line of C++ ever again. But that’s just a personal commitment ;) > Now if you really want speed, stop converting from text to floats, convert > the file to a binary format containing floats before your users have to load > it. That’s what I plan for the next step: I’ll try to set up an automatic translation from the ascii file as part of the build process. But I must admit while I am pretty familiar with Makefiles, I have still to figure out how to do that with Xcode (I suppose it’s not a hard task, it’s just that I hadn’t time to slog on that). Have a nice Sunday, Vincent ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField / NSSecureTextField toggl
On Jul 7, 2013, at 5:46 AM, Michael Starke wrote: > I'm somewhat heading down a road of pain with this. Maybe I approach the > problem from the wrong angle, so I wanted to ask for advice. > My goal is to have a NSTextField that can be toggled to display a Password in > clear or bulleted format. Sort of NSTextField - NSSecureTextField > I'm using a custom NSTextFieldCell to get a different look of the cell and > also to add a toggle Button inside the Field. I would avoid this complexity by simply having two views — a regular text field and a secure text field — at the same place in the window and swapping them out so one of them is hidden and the other visible. When you toggle which view is hidden, get the text from the old view and put it into the new view. I don’t think messing with or trying to duplicate NSSecureTextField is a good idea. There is more to it than simply drawing bullets instead of characters. For instance, IIRC it does some magic with the window-server and event system to prevent other software (via the accessibility APIs?) from eavesdropping on the keystrokes. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 10:38 AM, Vincent Habchi wrote: > Oh, just that since I moved from plain BSD/Qt3 to MacOS/Cocoa, I swore not to > write any line of C++ ever again. But that’s just a personal commitment ;) If Qt is the majority of your experience with C++, then I understand wanting to avoid it... > That’s what I plan for the next step: I’ll try to set up an automatic > translation from the ascii file as part of the build process. But I must > admit while I am pretty familiar with Makefiles, I have still to figure out > how to do that with Xcode (I suppose it’s not a hard task, it’s just that I > hadn’t time to slog on that). You add a script build phase to the target; in that script you do the conversion using whatever tools you want--I'd be tempted just to knock one out in C and invoke that from the script, but you may have other tools, or for all I know may have original data that's not yet text. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
And while we're on the subject of speed, you're already dealing with threads, you're already prefixing the values with a count, if you get to a format where values in the input file are fixed-length, then you can find sections 2 & 3 without reading 1 & 2, so you could load the sections in parallel in different threads... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
On Jul 7, 2013, at 1:08 AM, Vincent Habchi wrote: > My initial reasoning was very (too) simple: I have a 20 MB file made up of > strings, if I store those strings in objects, even with a small overhead, it > should not top 30 or 40 MB. It turned out I was plainly wrong, at least the > way I implemented it. Storing small values in individually malloc’ed heap blocks is relatively expensive. A malloc block has a minimum size of 16? bytes, is always allocated on a padded boundary (4-byte or 16-byte?) and has at least four? bytes of overhead for heap-management metadata. [Don’t trust those numbers; they’re from memory and may be obsolete or wrong.] Moreover, the malloc() and free() calls have nontrivial CPU overhead. It’s almost* always going to be a lot cheaper to store little fixed-size values/objects in C-style arrays. (If you’re willing to get down with Obj-C++, the std::vector class is useful for this.) Note: This overhead really only becomes noticeable when one is allocating huge numbers of tiny objects. In most circumstances it’s not noticeable; but your specific case is one where it does cause problems. —Jens * The exception is certain types of NSNumber, which are magically stored as tagged pointers rather than malloc’ed blocks. This makes them virtually free to allocate. In 32-bit processes I think this only applies to booleans and smallish integers. In 64-bit there’s a lot more room inside a pointer so more values are stored tagged; certainly larger ints, and I’m guessing 32-bit floats. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: The cost of using objects rather than plain C variables
> Is there any hope in the future to be able to store simple types like int or > floats in NSArrays? Have you tried using NSData to store C-arrays? *- * Frederick Bartram * PGP key id: 0x63fa758 keyserver: http://keyserver.pgp.com */ smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
pathForResource:ofType: iOS bug?
Hi, pathForResource:ofType: is returning a path string with 4 garbage characters added to the end of the string. To make sure it wasn't my program causing the problem I created a new iOS project to try it out and it does it too. Empty Application Devices - Universal No - Use Core Data No - Use ARC No - Include Unit Tests I added this to the end of application:didFinishLaunchingWithOptions: NSString *path = [[NSBundle mainBundle] pathForResource:@"Default" ofType:@"png"]; Anyone else have this problem? thanks Jeff OS X 10.7.5 Xcode 4.6.3 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: pathForResource:ofType: iOS bug?
How are you examining the return value? Show us that code too, please. On Sun, Jul 7, 2013 at 7:34 PM, Jeff Smith wrote: > > > Hi, > > > > pathForResource:ofType: is returning a path string with 4 garbage > characters added to the end of the string. > > To make sure it wasn't my program causing the problem I created a new iOS > project to try it out and it does it too. > > > Empty Application > Devices - Universal > No - Use Core Data > No - Use ARC > No - Include Unit Tests > > > I added this to the end of application:didFinishLaunchingWithOptions: > > > NSString *path = [[NSBundle mainBundle] pathForResource:@"Default" > ofType:@"png"]; > > > Anyone else have this problem? > > > thanks > Jeff > > > OS X 10.7.5 > Xcode 4.6.3 > > > > > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/cocoa-dev/stephen.butler%40gmail.com > > This email sent to stephen.but...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: pathForResource:ofType: iOS bug?
Whoops! It looks like it was my program after all. I quit Xcode and threw out all of the derived data and tried it again. Now it's working correctly in the test program. Sorry about that... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
10.8 & Sandbox & start at login
Hi all,
I've got problem with start at login in sandboxed environment on 10.8 (< 10.8
is not supported now). It simply doesn't work sometimes. What does it mean
exactly?
1. App is downloaded from the App Store
2. App is started by me/user and Start at login is checked (code below)
3. I do restart my Mac while main application is still running and application
is not started after restart. Console contains error message that start of my
helper is refused, because it wasn't previously launched by the user.
To fix this issue, I have to do this:
1. Start app after App Store download
2. Enable start at login in app
3. Quit application
4. Start app again manually
5. Restart Mac and now, it does work
In other words, it requires 2 steps - after enabling start at login, I have to
quit app and start it manually. And it magically started to work then.
Any idea what can be wrong? Do I need some kind of entitlements to add to start
my helper? According to logs, SMLoginItemSetEnabled call didn't fail and when I
do this quit/start dance, it works. Application is currently in the Mac App
Store (Moment), approved by Apple, I mean, correctly signed, etc. But we still
experience this issue reported by some users.
Anyone can sched some light on this issue? What can be wrong? Googling,
searching on SO, … but no helpful answer at all.
R.
Main application code to enable/disable/check start at login:
- (BOOL)willStartAtLogin:(NSString *)bundleID {
NSArray * jobDicts = (__bridge NSArray *)SMCopyAllJobDictionaries(
kSMDomainUserLaunchd );
if ( (jobDicts != nil) && [jobDicts count] > 0 ) {
BOOL bOnDemand = NO;
for ( NSDictionary * job in jobDicts ) {
if ( [bundleID isEqualToString:[job objectForKey:@"Label"]] ) {
bOnDemand = [[job objectForKey:@"OnDemand"] boolValue];
break;
}
}
CFRelease((__bridge CFDictionaryRef)jobDicts); jobDicts = nil;
return bOnDemand;
}
if ( jobDicts ) {
CFRelease((__bridge CFDictionaryRef)jobDicts); jobDicts = nil;
}
return NO;
}
- (BOOL)setStartAtLogin:(NSString *)bundleID enabled:(BOOL)enabled {
NSURL *bundleURL = [[[NSBundle mainBundle] bundleURL]
URLByAppendingPathComponent:@"Contents/Library/LoginItems/MomentHelper.app"];
LSRegisterURL( (__bridge CFURLRef)bundleURL, true);
return ( SMLoginItemSetEnabled ((__bridge CFStringRef)bundleID, enabled ) ==
0 );
}
Main application entitlements are com.apple.security.app-sandbox and
com.apple.security.network.client.
Here's the code in helper:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
BOOL alreadyRunning = NO;
BOOL active = NO;
NSArray *running = [[NSWorkspace sharedWorkspace] runningApplications];
for ( NSRunningApplication *app in running ) {
if ( [[app bundleIdentifier] isEqualToString:@"com.tapmates.Moment"] ) {
alreadyRunning = YES;
active = [app isActive];
}
}
if ( !alreadyRunning || !active ) {
NSString *path = [[NSBundle mainBundle] bundlePath];
NSArray *p = [path pathComponents];
NSMutableArray *pathComponents = [NSMutableArray arrayWithArray:p];
[pathComponents removeLastObject];
[pathComponents removeLastObject];
[pathComponents removeLastObject];
[pathComponents addObject:@"MacOS"];
[pathComponents addObject:@"Moment"];
NSString *newPath = [NSString pathWithComponents:pathComponents];
BOOL result = [[NSWorkspace sharedWorkspace] launchApplication:newPath];
}
[NSApp terminate:nil];
}
Helper's entitlements are com.apple.security.app-sandbox.
--
Robert @ Tapmates, Inc.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
