Re: Determining available or installed RAM on iOS device?
On 11 Feb 2014, at 15:46, Jens Alfke j...@mooseyard.com wrote: I'm well aware that on most modern operating systems available RAM is not a very informative number because virtual memory makes RAM and address space very different things. But on iOS, as I understand it, there is no swap file and address space is always allocated out of physical RAM. Watch out - that's the truth, but not the whole truth: memory is still freed up by discarding or writing memory-mapped stuff out to disk, and freeing purgeable regions (although how this plays with the memory warning system I don't exactly know, and I don't believe it's documented). Jamie. ___ 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: CVPixelBufferCreateWithPlanarBytes does not execute callback when released
I'm not an expert on planar video formats, but I tried out your code anyway and noticed that if I pass a non-NULL value as the dataPtr parameter then the callback gets called. Jamie. On 5 Jan 2014, at 11:04, Matthieu Bouron matthieu.bou...@gmail.com wrote: On Mon, Nov 25, 2013 at 12:45 PM, Matthieu Bouron matthieu.bou...@gmail.com wrote: On Sun, Nov 10, 2013 at 10:50 PM, Matthieu Bouron matthieu.bou...@gmail.com wrote: Hello, First of all, sorry in advance if i'm not addressing the right mailing list. I'm currently using the CVPixelBufferRef API and more precisely the CVPixelBufferCreateWithPlanarBytes function so I can use my own video buffers. This function let the user provide a callback so the user can provide a function to free its buffer on release. However I can't get my own callback to be executed which leads to severe memory leaks in my application. You can find attached to this email, an example to reproduce the issue. Note that the first example with CVPixelBufferCreateWithBytes works but the CVPixelBufferCreateWithPlanarBytes one don't. Maybe i'm missing something ? I'm facing this issue on OSX 10.9. To compile the example: gcc -framework CoreVideo test_cvbuffer.m -o test_cvbuffer Thanks in advance for your help. ping Any comments on this issue ? Best regards, Matthieu ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: ARC vs Manual Reference Counting
When performance testing ARC code, remember to test in a release configuration, with compiler optimisations on. In my experience, it can really make a big difference; a lot of 'spurious' retain/release pairs are optimised away, and many objects are released earlier. Jamie. On 9 Sep 2013, at 11:15, Kevin Meaney k...@yvs.eu.com wrote: On 9 Sep 2013, at 10:33, Tom Davie tom.da...@gmail.com wrote: Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. My new project is still so far from ready that optimizing at this point is not sensible. I do have however a bunch of utility functions that do a lot and currently use cocoa for doing the work but that nearly all the cocoa can be replaced by their toll free bridged core foundation equivalents. So if measurement proves that a lot of time is spent in these methods I'll rewrite them then. Kevin ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: iCloud Key-Value Store not Syncing ?
On 1 Jun 2013, at 06:16, Peng Gu pan...@gmail.com wrote: * Questions: * 0. Any thoughts on the problems? 1. Is there any way to check if the data is uploaded to the iCloud storage. 2. I'm not a iOS developer membership yet, so the app isn't code-signed. Can I test the iCloud functionality with the iphone simulator in Xcode without code signing the iOS app? iCloud key value storage doesn't work fully on the simulator - the data is saved locally, but it's never synced with the cloud. To test this, you'll need to get a developer program membership and test on a real device. Jamie. ___ 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: Simple Vector Based Line Charts
If you have quite simple requirements, a CAShapeLayer might work. You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can help with creating the CGPath if you don't want to drop to the CGPath API (no such luck on Mac - NSBezierPath can't be trivially converted to a CGPath AFAIK). The C-based CGPath API is not bad though. Jamie. On 10 Apr 2013, at 06:31, YT y...@redwoodcontent.com wrote: So I was looking for a graphics library in the Developer Docs that serves both Mac-Apps and iOS-Apps. I found references to polylines in a MapKit. There is of course Quartz2D and OpenGL. So which of these libraries or perhaps there is another I have not heard of yet is best at building simple vector line charts? YT ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: Understanding user defaults
On 19 Mar 2013, at 10:02, Marcel Weiher marcel.wei...@gmail.com wrote: On Mar 19, 2013, at 1:19 , Jens Alfke j...@mooseyard.com wrote: On Mar 18, 2013, at 5:14 PM, Rick Mann rm...@latencyzero.com wrote: NSArchiver calls look like -setValue:forKey:, so it seems reasonable that the protocol could be usurped to write out fairly clean user defaults plists. There’s a lot of other gunk the archiver needs to store so it can handle pointer cycles and remember what classes to re-instantiate. As I said, look at some XML generated by NSArchiver sometime. Yes, but those can be handled in a cleaner way than what NSKeyedArchiver does. As an example, check out the MPWXmlArchiver in Objective-XML ( https://github.com/mpw/Objective-XML ). It reflects the object-graph as directly in XML as possible, using the id/idref mechanism specified in the XML spec to handle repeated occurrences of the same object. I remember people using it for debugging by dumping complex object graphs as XML. It currently doesn't restrict the objects in the graph on reading, but that would be a fairly simple exercise. On a hopefully-not-overly-self-promotional tangent: If you're looking to debug - or just easily read - NSKeyedArchiver output, my 'YACYAML' NSKeyedArchiver implementation produces YAML output that's really easy to read (and write). It uses YAML 'anchors' to cope with deduplication similarly to MPWXmlArchiver. It's available at https://github.com/th-in-gs/YACYAML. It does, of course, come with the same security caveats that any NSArchiver subclass should come with, as already discussed. There is a YACYAMLKeyedUnarchiverOptionDisallowInitWithCoder option that you can use though, which restricts it to decoding YAML-native classes (sets , dictionaries, strings, arrays etc.). Jamie. ___ 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: Uploading photos to iCloud programatically
If you save images to the camera roll the system will automatically upload them to the photo stream, just as if they'd been taken with the camera. Jamie. On 7 Feb 2013, at 05:42, Balaji M balaji06n...@gmail.com wrote: Hi, I am writing a Mac application which is expected to support uploading photos to iCloud. After browsing many sites, I feel there is NO developer API to enable application to upload directly to photostream. My question is: Is there any alternative way for applications to upload photos to Photostream? If not, how about considering photos as NSDocuments and uploading to iCloud? Please provide me some pointers for accomplishing this feature in my Mac app. Thanks in advance. Regards, Balaji M. +91 8088640610 ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: Coordinate conversions in CALayer
On 24 Jan 2013, at 08:19, Graham Cox graham@bigpond.com wrote: I've made some progress, in that I managed to make the two code snippets work the same, by changing this line: tfm = CGAffineTransformConcat( tfm, layer.transform ); to this: tfm = CGAffineTransformConcat( layer.transform, tfm ); I do appreciate that matrix concatenation isn't commutative, but it's still not clear to me why it needs to be this way round when the equivalent line when manipulating the CTM is: CGContextConcatCTM( ctx, layer.transform ); This suggests that internally, this call passes the CTM as the second parameter, not the first. If so, then the documentation could do well to spell that out, since matrix order is so important. If not, then my understanding is still off, which does not surprise me. I looked this up again, because it's hit me in the past - it feels unintuitive to me half the times I use it too, but it is actually spelled out in the docs: -- CGContextConcatCTM (http://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/CGContext/Reference/reference.html): Transforms the user coordinate system in a context using a specified matrix. void CGContextConcatCTM(CGContextRef c, CGAffineTransform transform); ... Discussion: When you call the function CGContextConcatCTM, it concatenates (that is, it combines) two matrices, by multiplying them together. The order in which matrices are concatenated is important, as the operations are not commutative. When you call CGContextConcatCTM, the resulting CTM in the context is: CTMnew = transform * CTMcontext. -- CGAffineTransformConcat (http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/CGAffineTransform/Reference/reference.html): Returns an affine transformation matrix constructed by combining two existing affine transforms. CGAffineTransform CGAffineTransformConcat(CGAffineTransform t1, CGAffineTransform t2); ... Return Value: A new affine transformation matrix. That is, t’ = t1*t2. -- Jamie. ___ 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: Operations Beachball
On 4 Dec 2012, at 18:29, Jens Alfke j...@mooseyard.com wrote: On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: My app creates lots of MyOperations (subclass of NSOperation) and puts them into an NSOperationQueue. I would expect that the app thus remains responsive, but sometimes it is not. Welcome to the joys of multithreaded programming. :-P You have to be pretty careful about how you do things, or all sorts of unintuitive and flaky behaviors can result. + 1343 MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, unsigned char) (in HIToolbox) + 625 [0x7fff90ea5063] + 1343 BroadcastToolboxMessage (in HIToolbox) + 294 [0x7fff90e6e12a] + 1343 HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 [0x7fff8e57f174] + 1343 CFNotificationCenterPostNotification (in CoreFoundation) + 115 [0x7fff95edbbf3] + 1343 _CFXNotificationPost (in CoreFoundation) + 1109 [0x7fff95ecced5] + 1343 -[_NSDNXPCConnection sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] + 1343 _dispatch_semaphore_wait_slow (in libdispatch.dylib) + 241 [0x7fff97ed0486] + 1343 semaphore_wait_trap (in libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] I have no idea, what this means. Maybe someone can enlighten me. The main thread is sending a cross-process (XPC) message and waiting for a reply. Presumably this has something to do with arbitration of the menu bar state since the menu bar is a shared resource between apps? But it doesn’t seem related to anything you’re doing. Is it possible that the XPC that's being waited for here is stalled because whatever's meant to respond to it is a default priority GCD-dispatched block that can't run because GCD has scheduled a lot of your operations, also at the default priority, and won't schedule another (e.g. the one to reply to that message) until the load lightens? I know this sounds unlikely, but it bit me in an iOS project - I was seeing multi-second stalls on the main thread because of this. I 'solved' my problem by lowering the CGD queue priority of my operations. This took care of the large stalls, but to actually get a non-jerky UI, I also had to limit the maxConcurrentOperationCount on my queue to stop GCD from scheduling too many of the operations at once and bogging down the CPU. GCD scheduled too many otherwise because it was fooled into thinking there were resources available whenever a running operation stalled on I/O for a short period. Full details, including samples, are here: https://devforums.apple.com/message/756881. One of the selling points of GCD is that it manages all of this for you, of course, but I've found that's not the case when multiple parts of the system are expecting to be able to use it at once and don't coordinate - especially if there's I/O going on anywhere. Jamie. ___ 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: How To Safely Invoke a Block
On 21 Nov 2012, at 10:56, Andreas Grosam agro...@onlinehome.de wrote:
I've defined a class Foo that defines a block via a property:
@property (copy) void (^progressHandler)(RXProgressState progressState,
NSInteger totalBytesWritten, NSInteger totalBytesExpectedToWrite);
The property is synthesized by the compiler, ARC enabled.
The block is usually invoked on a private thread for several times until an
action finishes (an asynchronous NSURLConnection).
A client of class Foo should be able to set the block property at any time
from any thread - that is it should also be able to set the block to NULL.
Now, I'm worried about thread safety.
First, is it a good measurement to use a property with the atomic attribute?
Secondly, I'm invoking the block as follows (from within a
NSURLConnectionDelegate method):
progress_handler_block_t block;
if ( (block=self.progressHandler) != NULL) {
block(RXProgressStateStart, 0, self.source.size);
}
since it appears to me, that
if (_progressHandler) {
_progressHandler(RXProgressStateStart, 0, self.source.size);
}
or
if (self.progressHandler) {
self.progressHandler(RXProgressStateStart, 0, self.source.size);
}
isn't thread safe.
People are making this seem very complicated!
You say you're running with ARC, so the way you are doing things is fine if you
mark the property as atomic to make sure the contents are not inadvertently
released 'during' your call to the accessor. The local reference to the block
will retain it after it's returned from the accessor.
The only caveat (and I think this is already obvious to you given what you've
said) is that the 'old' block might be run instead of the 'new' block if
another thread assigns to the property between the block=self.progressHandler
and your invocation of the block.
Jamie.
___
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: NSMapTable thread safety (with with ARC and weak objects)
On 16 Nov 2012, at 22:36, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Nov 16, 2012, at 09:53 , James Montgomerie ja...@montgomerie.net wrote: Let's assume I'm using ARC. If I create an NSMapTable with [NSMapTable strongToWeakObjectsMapTable], is it safe to put objects into it that might be referenced from, and perhaps deallocated on, a background thread? Specifically, might I get a half-deallocated or retain-count-zero object back from -objectForKey: if a 'right' race condition happens? It's a mutable collection, and it's listed in the thread safety guide as unsafe. Specifically, that means you shouldn't be modifying a map table (in the sense of adding, replacing or deleting objects) while a different thread might be accessing the map table, not even just reading it. This is not a memory management issue, but rather a data integrity issue. As for the objects themselves, what do you mean by half-deallocated or retain-count-zero? If an object is strongly referenced in the map table (whether as a key or a value), its lifetime can't end before it's removed from the table. If an object is ARC-weakly referenced, the reference can go to zero at any time, but that happens in a thread-safe manner. Anyway, because this is ARC, if you get a non-nil value from the table, the referenced object is kept alive while you have the reference (until the end of the referencing scope, assuming you do nothing to prolong the lifetime beyond that point). Basically, I'm worried that the NSMapTable reacting to a weak object disappearing on a background thread is the moral equivalent of me mutating the NSMapTable on a background thread (turning the memory management issue into a data integrity issue). It seems like, since I don't see any documentation about it, there's a possibility that although ARCs handling of __weak is atomic and thread-safe, NSMapTable's reaction to the disappearance of a weak object it contains is not. From your answer, you would say that this is not the case? Jamie. ___ 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
NSMapTable thread safety (with with ARC and weak objects)
How thread safe is NSMapTable? I know that's a pretty nebulous question, so more concretely: Let's assume I'm using ARC. If I create an NSMapTable with [NSMapTable strongToWeakObjectsMapTable], is it safe to put objects into it that might be referenced from, and perhaps deallocated on, a background thread? Specifically, might I get a half-deallocated or retain-count-zero object back from -objectForKey: if a 'right' race condition happens? Does the answer to this change if I guarantee that the NSMapTable itself (but not the objects it contains) will be used only on the a single thread? Jamie. ___ 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: Code Comments
On 9 Sep 2012, at 17:57, koko k...@highrolls.net wrote:
On Sep 9, 2012, at 7:35 AM, Mike Abdullah wrote:
NSXMLParser supports NSInputStream directly these days; consider moving to
that
That is excellent but for now I must run on 10.5.8 …
Aside from the memory management issues already pointed out, there a
performance improvement you can make here. Since you know that the parser will
not continue to use the data after the parse, you can avoid physically copying
the buffer when you create the NSData by using NSData's initWithBytesNoCopy:...
methods. These cause the NSData to be backed by the buffer you pass in rather
than copying it to a new one owned by the NSData as usual.
- (void)startMessageParse:(void*)msgStart end:(void*)msgEnd
{
NSInteger length = msgEnd-msgStart+1;
if(length 0)
{
NSData *data = [[NSData alloc] initWithBytesNoCopy:msgStart
length:length freeWhenDone:NO];
if(data)
{
NSXMLParser *xmlParser = [[NSXMLParser alloc] initWithData:data];
[xmlParser setDelegate:m_xmlParserDelegate];
[xmlParser parse];
[xmlParser release];
[data release];
}
}
m_state = NEWMESSAGE;
}
By the way, that length = msgEnd-msgStart+1 looks odd to me. Your msgEnd
really points to the last valid character, not one past it?
Jamie.
___
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: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?
On 10 Sep 2012, at 11:40, Motti Shneor su...@bezeqint.net wrote: My question is general. Supposedly I could NOT start observing once, and stop it once. Reasons: 1. There are many instances of that NSViewController 2. This observation is quite frequent in time (could reach 100 times a second) 3. The code to filter-out unwanted value-changes is CPU intensive. (Accounting for 5 orthogonal conditions, upon which I should actually do something with the attribute change) Does your view controller need to be aware of all these changes? 100s of changes a second is faster than your display can operate so, if this code is just to keep your UI up to date, there's potentially a lot of redundant work going on. Is it possible that you could, instead of observing, do something simpler like poll for changes while whatever's causing them to happen is underway? For example, could you use an NSTimer firing once every 30th or 15th of a second, calling a method that updates the UI? This would avoid the overhead of processing all those 100s of changes per second in the view controller. Jamie. ___ 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: ARC Extending Lifetime of Objects
I think this does what you want. It works by [arguably ab-] using the CF
bridging casts:
NSUInteger count = [dictionary count];
// Are you sure you don't want to malloc and free these? Might blow the
// stack if they're large.
id __unsafe_unretained values[count];
id __unsafe_unretained keys[count];
[dictionary getObjects:values andKeys:keys];
for (NSUInteger i = 0; i count; ++i) {
keys[i] = (__bridge id)CFBridgingRetain([keys[i] copy]);
values[i] = (__bridge id)CFBridgingRetain([values[i] copy]);
}
NSDictionary *other = [NSDictionary dictionaryWithObjects:values
forKeys:keys
count:count];
for (NSUInteger i = 0; i count; ++i) {
CFBridgingRelease((__bridge CFTypeRef)keys[i]);
CFBridgingRelease((__bridge CFTypeRef)values[i]);
}
I second the thoughts already expressed here though that doing:
[NSKeyedUnarchiver unarchiveObjectWithData:[NSKeyedArchiver
archivedDataWithRootObject: dictionary]]
would be more readable and more maintainable (and less likely to be wrong), so
I'd say do that if performance does not prove to be an issue.
Jamie.
On 23 Jul 2012, at 09:00, Andreas Grosam wrote:
Suppose, I have C-arrays defined as follows:
int count = [dictionary count];
id __unsafe_unretained values[count];
id __unsafe_unretained keys[count];
I fill these arrays with:
[dictionary getObjects:values andKeys:keys];
Now, I would like to reuse these arrays through holding objects maintained
by ARC (if possible):
for (int i = 0; i count; ++i) {
keys[i] = [keys[i] copy];
values[i] = [values[i]] copy];
}
NSDictionary *other = [NSDictionary dictionaryWithObjects:values forKeys:keys
count:count];
This won't work in ARC, since the arrays are declared __unsafe_unretained and
this would cause the newly created object immediately be deallocated once it
is assigned to the array's element.
What I would like to avoid is to use separate arrays (appropriately
declared), and also avoid to disable ARC and maintain the release counts
manually.
Is there a way to extend the lifetime of the created objects, or is there a
way to re-declare the arrays so that ARC can maintain the references - or
is there any other simple trick?
Thanks for suggestions! ;)
Andreas
___
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/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net
___
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: @synchronized crashing with ARC
It looks a bit suspicious to me that you're instantiating the dictionary in
your hidden … work ... code, then using it in the visible code, but not
releasing it.
Is it possible that the dictionary started out as an ObjC object that you don't
own, and you used a (__bridge CFDictionaryRef) cast to assign it to
myDictionary, expecting it to stick around until the autorelease pool pops?
That's not what is guaranteed to happen under ARC - the system is now free to
release the dictionary when the last strong pointer referring to it goes out of
scope. A CF reference is not an ARC-managed pointer, so it doesn't count as a
strong pointer.
If this is the case, there are a few solutions. Making myDictionary an
'NSDictionary *' is the easiest one, since that will be fully managed by ARC,
so it will keep a reference to it until you test it and the function exits.
Jamie.
On Thursday, 31 May 2012 at 16:47, Antonio Nunes wrote:
I have a function that looks essentially like this:
static void *kMyVLFContext = kMyVLFContext;
Boolean myFunction(CFURLRef path)
{
CFDictionaryRef myDictionary = NULL;
@synchronized(kMyVLFContext) {
… work …
}
return myDictionary != NULL;
}
This function works fine with manual memory management. After compiling with
ARC though, a crash occurs on line @synchronized(kMyVLFContext) {. I
wouldn't think this should be affected by ARC at all. Any hints as to what
might be afoot here, or is it more likely something else, earlier on is
causing a failure here (e.g. stomping kMyVLFContext)?
Removing the lock causes the function to return successfully, but may of
course cause issues on occasions when the function is called from several
threads at once.
-António
It isn't so important to do great things,
as to do what you do with great love.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
(mailto: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
(http://lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net (mailto:ja...@montgomerie.net)
___
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: Losing memory
On Monday, 28 May 2012 at 03:20, Charlie Dickman wrote: My application is using (leaking) too much memory and eventually dies because no more can be allocated. I have used Instruments to measure the usage and leaks and have addressed those it told me about. Now, however, Instruments indicates that memory reaches a steady state (no more increases) yet the app continues to die for lack of memory. Does anyone know of a next step I can take to help track down this problem? One thing I always find helpful in situations like this is to use Instruments' Allocations template, then, ignoring the graph and byte counts, sort the Statistics view at the bottom by # Living and see if there's anything that seems to be allocated a surprising number of times. Often there are large numbers of small objects that are really just handles to other things - for example, objects holding on to memory-mapped files, or OpenGL textures. These objects don't contribute much to the Allocations count, because they themselves are very small. The things they're holding on to also don't contribute, because they're not 'allocated' in a way the instrument tracks, but they could be taking up a lot of your address space. Jamie. ___ 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: stringWithFormat / Rendering Text (iOS)
On 24 May 2012, at 15:36, Manfred Schwind wrote: CGContextShowTextAtPoint(contextRef, 0, 40, [textToDraw UTF8String], [textToDraw length]); One bug I see here: you're passing a wrong length parameter. CGContextShowTextAtPoint expects the length of the char array (number of bytes of the UTF-8 encoded string), but you'e passing the number of Unicode characters in the string. That's not the same; one character may be represented by multiple chars in UTF-8 encoding. E.g. use it this way: const char *myUTF8String = [textToDraw UTF8String]; CGContextShowTextAtPoint(contextRef, 0, 40, myUTF8String, strlen(myUTF8String)); That's not true. CGContextShowText... routines expect the length to be in bytes, and the encoding to be what you specified in your CGContextSelectFont call. At the moment, you have a choice between the 8-bit MacRoman, and 'kCGEncodingMacRoman' and the cryptic 'kCGEncodingFontSpecific'. You should never pass UTF-8 text to a CGContextShowText... routine - if there's anything in there that isn't in the intersecting subset of ASCII and MacRoman, you're likely to just get garbled symbols out. You can pass byte strings that you've converted to MacRoman, but MacRoman encoding represents quite a small subset of Unicode by modern standards - I would not recommend using it. The CG levels don't do any sort of character to glyph mapping beyond this, so it's /impossible/ to display unicode text with them without parsing the fonts and doing the character to glyph mapping yourself (and then potentially worrying about font substitution if there are no glyphs to represent the characters you want etc...) then using the CGContextShowGlyphs... routines. Really, just stick to UIKit string drawing, or CoreText if you want more control than that gives you. These frameworks might be more expensive than CoreGraphics in runtime terms, but that's because they're doing all the things that are necessary to render text well nowadays, not because they're inefficient. Jamie. ___ 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: NSDocument disc undo stack
I don't think it's likely to be true in practice on 64-bit systems either. In theory, yes, the old data could get paged out, and will not be paged back in until the user uses it. In practice though, unless these pieces of old data are big, contiguous buffers taking up pages by themselves, the old data will likely live in pages that also contain at least a few things that are at least intermittently used, so you'll be constantly paging. Jamie. On Sunday, 1 April 2012 at 11:42, Mike Abdullah wrote: I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, it's fairly easy to exhaust your address space if all deleted files are kept in-memory. On 26 Mar 2012, at 00:57, Steven wrote: Thanks for the info Graham. I'm using NSUndoManager. I thought that many large objects in the stack would cause memory pressure and would be better occupying disc space as they are only needed at undo/redo time. Good to know that the VM system will take care of it. Steven. On 24 Mar 2012, at 01:04, Graham Cox wrote: You can read and write to the Application Support folder. But FILES in an Undo stack? That makes little sense to me. If you want to undo changes to a file, store the changes or the command that will cause the changes in the undo stack. If you are changing the organisation of files on disc then save a description of that organisation in the undo stack. You may want to read up on the way Cocoa utilises Undo, because it sounds like you might not have a good grasp on it. Even if you need to store very large objects in the undo stack, unless you can prove it's a serious problem, just let the memory get paged to disk VM naturally. It's rare that users need to undo a very long history, so even if the older history is paged out, the chances are the user will never know. --Graham On 24/03/2012, at 10:17 AM, Steven wrote: Hello, Where is the correct place to store an on-disc undo stack associated with a NSDocument instance ? The stack may contain several potentially large files so we don't want them to occupy memory. For a compound document the stack could reside in a directory NSFileWrapper. For a single file document should a temporary directory be used ? I guess the chosen location may need to persist beyond the occurrence of the automatic termination feature. Any advice appreciated. Thanks. Steven. ___ 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/graham.cox%40bigpond.com This email sent to graham@bigpond.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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: [Obj-C] if (self) vs. if (self != nil)
On 24 Feb 2012, at 20:36, Sean McBride s...@rogue-research.com wrote: On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said: I don't believe this is the case. There can be funny issues with BOOL types, such that BOOL == YES is an inadvisable construct, since your BOOL could be an integer of any value. Indeed, and it's extremely frustrating. I encourage you to file bugs on this, or maybe add a comment here: http://llvm.org/bugs/show_bug.cgi?id=9194 Danger! The code in that bug report is unsafe in another unintended manner too. BOOL isOK = someBitField someFlag; Is equivalent to signed char isOK = (signed char)(someBitField someFlag); If someFlag is 256, the bit that's left set after the '' is executed will be truncated off by the assign converting down to 8 bits. It's safer to do: BOOL isOK = (someBitField someFlag) == someFlag; Or simply our controversial friend: if(someBitField someFlag); Although I'd do: if((someBitField someFlag) == someFlag) If only to silence compiler warnings about the naked single '' in the if. Slight tangent: I find the safest way, always, to approach 'if' is not to pretend that it's doing anything other than checking for non-zero values. Once you accept that, lots of 'what's clearer' questions go away, because neither way is 'clearer', they're just more or less verbose. Jamie. [Apologies for formatting, edited on my phone.] ___ 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: copy isEqual nightmares
On 13 Feb 2012, at 17:29, Quincey Morris wrote: It's a mistake to calculate the hash from *mutable* object state, including ivars that can be changed after creation. The NSObject protocol documentation on 'hash' is worth recalling: hash Returns an integer that can be used as a table address in a hash table structure. (required) - (NSUInteger)hash Return Value An integer that can be used as a table address in a hash table structure. Discussion If two objects are equal (as determined by the isEqual: method), they must have the same hash value. This last point is particularly important if you define hash in a subclass and intend to put instances of that subclass into a collection. If a mutable object is added to a collection that uses hash values to determine the object’s position in the collection, the value returned by the hash method of the object must not change while the object is in the collection. Therefore, either the hash method must not rely on any of the object’s internal state information or you must make sure the object’s internal state information does not change while the object is in the collection. Thus, for example, a mutable dictionary can be put in a hash table but you must not change it while it is in there. (Note that it can be difficult to know whether or not a given object is in a collection.) There are 3 points to take away, beyond the basic requirements: 1. the value returned by the hash method of the object must not change…. It sounded like you were contradicting this, above. 2. … while the object is in the collection. This seems to promise that the only parts of the Cocoa frameworks that actually make use of the hash are the collection classes. 3. The hash is primarily intended to support hash table storage mechanisms. Any performance benefits in other contexts are secondary (and, given #2, aren't even necessarily valid if the object isn't in a collection). Now, although #2 gives you permission to violate #1 while the object is *not* in a collection, its sounds like a terrible idea to do so. I don't think this is as concrete as you are analysing it to be. Take a mutable string as the canonical example - obviously its hash should change when its contents changes (and it should no longer be isEqual: with a copy of its older self). It's up to the user of the string to ensure that they don't mutate it while it's being used in a collection (i.e. as a key) to ensure predictable program behaviour. Jamie. ___ 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: Allocating too much memory kills my App rather than returning NULL
On 9 Nov 2011, at 17:33, Dave Camp wrote: This was discussed at a WWDC session a couple of years ago. If your app attempts to allocate a large block of memory, and the OS cannot get other processes to give up memory in a timely fashion, your app will be killed. It's the reverse of you getting the low memory messages. As you take up more and more memory, the OS has to send the low memory messages to other apps to get them to release memory for you. If you allocate memory faster than the OS can re-claim it from other processes, your app will be terminated. Maybe you didn't mean it this way, but this makes sound as if the foreground app never gets memory warnings, it's just terminated if it uses too much RAM. This is not true. In general, the opposite is true - other apps that have been suspended are not 'woken up' just to be given warnings - they're just terminated. The foreground app will get warnings, and a short chance to clean up - that's what the warnings are for. Remember, before iOS 4 there were no background apps, but the memory warning mechanism has been around for ever. Again, I /absolutely do not/ think that allocating in a tight loop and waiting for the warnings to find out how much memory you can allocate is a very good strategy. I'm skeptical that it will work at all, given the rate of allocation you'll have and how long it might take you to clean things up, and it's bad from an OS citizenship standpoint too. I just want to clear up some potential misinformation on the warnings. Jamie.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allocating too much memory kills my App rather than returning NULL
On 10 Nov 2011, at 17:52, Kyle Sluder wrote: On Nov 10, 2011, at 9:33 AM, James Montgomerie ja...@montgomerie.net wrote: On 9 Nov 2011, at 17:33, Dave Camp wrote: This was discussed at a WWDC session a couple of years ago. If your app attempts to allocate a large block of memory, and the OS cannot get other processes to give up memory in a timely fashion, your app will be killed. It's the reverse of you getting the low memory messages. As you take up more and more memory, the OS has to send the low memory messages to other apps to get them to release memory for you. If you allocate memory faster than the OS can re-claim it from other processes, your app will be terminated. Maybe you didn't mean it this way, but this makes sound as if the foreground app never gets memory warnings, it's just terminated if it uses too much RAM. This is not true. In general, the opposite is true - other apps that have been suspended are not 'woken up' just to be given warnings - they're just terminated. Read carefully: “If you allocate memory faster than the OS can re-claim it from other processes…” In other words, the system protects against apps that might've gotten trapped in an infinite loop of allocating memory. Better to kill the errant app without sacrificing other apps to its unsatisfiable demands. Oh, yes, certainly - that's why I later said I'm skeptical that it [listening for them while in an allocation loop] will work at all, given the rate of allocation you'll have and how long it might take you to clean things up. Reading my message again though, it is rather unclear itself (especially for a message attempting to clarify things...) What I was trying to say is that, contrary to the impression that might be being given (and that, again, that I don't think Dave meant to imply) it's not true that a foreground app /never/ gets memory warnings; under most circumstances it will. Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Allocating too much memory kills my App rather than returning NULL
On 9 Nov 2011, at 08:08, Don Quixote de la Mancha wrote: That would be great if I actually received any memory warnings. I don't. ... However, I did set a breakpoint at both methods. That breakpoint was never hit. I dont want to wade in to the religious war here (although I'm on the side of pragmatism, as you might be able to tell soon anyway...), so just on a practical level: Reading between the lines (and with apologies if I've inferred incorrectly), I think the reason you're not getting these warnings is because you are allocating your memory in a loop on the main thread. The main thread must be free to run the application runloop to deliver these warnings - that's how they work, they're not delivered asynchronously in the background. If you want to listen for them while your allocation loop is going on, you'll need to run it on a background thread or queue or (or otherwise free up the runloop to run by e.g. batching allocation calls). To be honest though, I would be very skeptical that you could respond to the warnings in a reliable or timely enough manner to satisfy the OS in all cases, so although you might want to try this out to see how the system works first-hand, I don't think it's a plausible strategy to use in shipping software. Also, again on a practical level, you might not /like/ the fact that there's no way to know if an allocation call will succeed, how much physical memory is available to you, or that, even if you could know that, the value would vary over time, but that's how iOS works. Your program will need to cope with that. Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessing information from applications
Note that, depending on what you're wanting to do, this might not actually give you what you want (and getting what you want may be impossible). Lots of apps (word processors etc.) that have document files 'open' as far as the user is concerned actually open the file, read/unarchive it into memory, close it, then use the in-memory representation while the document is displayed. Jamie. On 2 Jun 2011, at 11:29, Jens Alfke wrote: On Jun 2, 2011, at 11:18 AM, Abhinav K Tyagi wrote: Is there any method to know what files are opened by any application? I think you have to use fairly low-level POSIX or BSD APIs. The tool /usr/bin/lsof does this; you could get its source code from the Darwin repository (opensource.apple.com) and see how it does it. (Or more clumsily, you could use NSTask to invoke lsof and parse its output.) This is kind of off-topic for the Cocoa list, though. People on lists like darwin-userlevel might know more. —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: http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessing information from applications
This is indeed impossible to do generally. If you have /specific/ apps in mind (rather than 'any application'), it might be possible to tell this on an app-by-app basis at a higher level. For example, for Safari, you could use Applescript to get the URLs of the open windows: tell application Safari get the URL of the document of every window end tell The way to do this will be different for every app - you'll need to work out how to do it for each app separately. Jamie. On 2 Jun 2011, at 11:50, Abhinav K Tyagi wrote: Hi list members, I have searched for and have seen lsof command can be used and the output can be then filtered out. Although i can filter the information based on the extensions of files but how can i get the information if the opened file is a url. The best case can be of an audio stream or something like that. I am not getting way hoe to do it. Thanks Abhinav K Tyagi abhityag...@gmail.com --- On Jun 2, 2011, at 11:48 PM, Abhinav K Tyagi wrote: Hi, Is there any method to know what files are opened by any application? Thanks Abhinav K Tyagi abhityag...@gmail.com --- * Composed using Mac Mail. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using asynchronous APIs with NSOperation
Dave Dribin has written excellent blog posts about this - start here: http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/ Jamie On 24 Feb 2011, at 15:08, Matt DeFoor wrote: I have been doing research in preparing to switch from manual threading to the usage of NSOperation. Because my operations will be executing asynchronous APIs from the CoreServices framework, it appears that I'd be better off using concurrent operations. What is not clear to me is, if I provide a callback to an asynchronous API, on which thread is the callback called? Also, does anyone have experience using NSOperation with asynchronous APIs that take a runloop and a runloop mode as parameters? From my research, it is not clear to me how one would pass the required runloop parameters in the concurrent operation's start: method. Perhaps it is as simple as using the main thread's runloop, but that doesn't seem right. Thanks in advance, Matt ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net This email sent to ja...@montgomerie.net ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Canceling NSInvocationOperation
I think you are exposing yourself to a race condition here, even if you did get
this to work - imagine:
---
// Some Code:
- (void)myOperationInController;
{
// Do stuff
if (![self isCancelled])
-- main thread sets isCancelled to YES --
[self performSelectorOnMainThread...]
}
Presuming you're not saying waitUntilDone:YES, a similar thing could also
happen if the main thread sets isCancelled after your myOperationInController
method has returned, but before the queued method call created by the
performSelectorOnMainThread... on the main thread's run loop is actually
executed.
Since you're going to have to deal with the fact that supposedly cancelled
operations may initiate the performSelectorOnMainThread's callback (to fix this
edge case), a simpler approach to the whole problem might be to /always/
performSelector..., even if the operation is cancelled, and deal with (probably
just ignore) 'cancelled' operations in the callback itself.
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Fixed pattern with colorWithPatternImage
On 04/09/2010, at 14:52, Quincey Morris quinceymor...@earthlink.net wrote: The pattern is tiled relative to the window, not to the view. So, the 'colorWithPatternImage:' isn't a viable approach in this case. Quincey may be right that drawing the image directly is the easier approach, but it /is/ possible to change the offset of a pattern image by altering the graphics context's pattern phase. Before you draw: CGFloat offset = calculate the offset required to get the image to align at the top of the view here; CGContextSetPatternPhase((CGContextRef)[[NSGraphicsContext currentContext] graphicsPort], CGSizeMake(0, offset)); [Typed in Mail, so not checked for syntax errors]. Jamie.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Math.h functions with CGFloat
You should, I believe, be able to include tgmath.h ('type generic math' - a
C99 addition) instead, and then just 'use' the non-suffixed versions of the
functions. Hidden macro magic is supposed to then make the compiler call the
double or float versions as appropriate for the type used.
Having said that, I had a lot of trouble when trying this in my iPhone app a
year or so ago. Things seemed very slow when complied, and disassembly showed
all sorts of float-double conversion going on. I ended up explicitly calling
the f-suffixed ones anyway. I don't think I should have needed to though, and
if there was a bug back then (rather than just me doing something incorrect) it
could be fixed now.
Jamie.
On 10 Aug 2010, at 15:04, steven Hooley wrote:
Sorry, 'safe' was a bad choice. I do care because i have compiler
warnings. I have started defining macros for each function and thought
i better check that they didn't already exist.
Thankyou
On 10 August 2010 14:54, Alastair Houghton alast...@alastairs-place.net
wrote:
On 10 Aug 2010, at 13:42, steven Hooley wrote:
Is there a preferred way to use the Math.h functions with CGFloats
that is 32 and 64 bit safe?
Why would they be unsafe? (They aren't.)
It's possible that using the double versions (the ones without the f
suffix) is inefficient in 32-bit mode, but in practice you're very unlikely
to notice. If you particularly cared, you could #define some macros for
them, but I doubt it's worthwhile unless you're going to do some heavy-duty
geometry (and in that case, you might find that you want to use double
anyway, for accuracy).
BTW, math.h isn't capitalised; please don't use random upper-case letters
when including header files... it causes grief if your source code is ever
moved somewhere case-sensitive.
Should i even be using Math.h functions in Cocoa?
Why should you not?
Kind regards,
Alastair.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
You should really use 'integerValue' rather than 'intValue' if you're otherwise
using NSIntegers. 'integerValue' will return an NSInteger (which may be 32 or
64 bits wide depending on your platform), but 'intValue' will return a C 'int'
(which is always 32 bit on the Mac and iPhone, regardless of the 'natural' bit
width of the platform).
Jamie.
On 22 Apr 2010, at 18:21, Arnold Nefkens wrote:
Hi Thanks
Yeah the keys are ints and this helps a lot.
Thanks again...
On 22 apr 2010, at 18:31, Reinhard Segeler wrote:
Hi,
correct me if I'm wrong, but what you're doing is a calculation with the
pointers ( * of NSNumber) not the values. You have to calculate it like this:
NSInteger fieldOne= [ [ managedObject valueForKey:@key1] intValue]; //
if it's an integer
NSInteger fieldTwo = [ [ managedObject valueForKey:@key2] intValue];
NSInteger fieldThree = [ [ managedObject valueForKey:@key3] intValue];
if ( fieldTwo 0 )
{
NSNumber *answer = [ NSNumber numberWithInt:fieldTwo - fieldOne +
fieldThree];
[ self.managedObject setValue:answer forKey:@key4];
// maybe you need to this instead
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
}
Don't know if intValue in this context works, if not then use this
alternative, which must work in any way:
Your code and change the following lines:
NSNumber *answer = [ NSNumber numberWithInt: [fieldTwo intValue] - [fieldOne
intValue] + [fieldThree intValue] ];
[ self.managedObject setValue:answer forKey:@key4];
//or
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
//stringValue to present it in a textfield
Hope that helped... MacMeideln
Am 22.04.2010 um 17:36 schrieb Arnold Nefkens:
Hello list,
Im quite new, and probably missing something.
I want to do a calculation of three fields inside of a entity in CoreData.
Below is the code, what is wrong?
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
if (fieldTwo 0) {
NSNumber *answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
If I debug the right values are being shown in the fieldOne, fieldTwo and
fieldThree. But the calculation answer is all the time out of scope.
What am I missing?
hope someone can help...
Arnold Nefkens___
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:
http://lists.apple.com/mailman/options/cocoa-dev/macmeideln%40googlemail.com
This email sent to macmeid...@googlemail.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:
http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Weird exception
On 25 Jan 2010, at 10:21, Alexander Bokovikov wrote: On 24.01.2010, at 14:08, vincent habchi wrote: Under XCode, you select 'run with performance tool' - 'zombies'. This will launch your app with the 'zombie instrument' attached, that will signal you if you app tries to message a released entity. I'm sorry, but I don't see zombies item within Start with Performance Tool menu. I'm using XCode 3.1.4. Also it's not clear how to launch the app. Is it enough to set the target SDK to 10.4 or should I transfer my project into 10.4 system completely, then build it and run? I think you're on a wild goose chase here - the most likely explanation to me is that something somewhere is deliberately calling -[NSString boolValue] (and it may not be 'your' code - I wouldn't put it out of the realms of possibility that a call to it sneaked into Sparkle), which didn't exist until 10.5. If this is the problem, and you want to target Tiger, the best solution would be to find the use of boolValue in the code base and replace it with something that will work on 10.4. The category method you made on NSString is not the right solution - it almost certainly does less than the 10.5+ framework implementation, and it'll replace that method when system frameworks call it, which could cause all sorts of problems (this hit me in the past - the SYCK YAML parsing framework implemented -[NSString boolValue], and it caused problems with, of all things, the iPhone keyboard in iPhone OS 3.0). Jamie.= ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to animate the drawing of UIImages inside a drawRect: method of a UIView?
On 2 Apr 2009, at 22:33, WT wrote: 25 was just a test. The actual app has 2 interlocking 7x7 grids, so the number of image views is actually 98. I should explain that this animated laying out of image views happens only once and, from that point on, the image views all remain in the same place, though each image itself is animated. Here's a screen shot to clarify things: grid.png Presuming that this is full-size, It is uncommon to have views that are so small (the balls must be, what, 4X4 pixels or something?), I'd say. Intuitively, it 'looks' to me like the 'normal' architecture for something like this would be to have one custom view for the entire grid (of course, there are always exceptions, and I don't know the full background of your app). The balls pulsate, growing and shrinking in size, an effect that I accomplish using UIImageView's -startAnimating, but the animation I was referring to in my previous posts has to do with adding each image view to its proper place. My question boils down to this: if I am going to use -startAnimating for the pulsation, then each ball *has* to be an instance of UIImageView, which requires me to add 98 subviews to the superview and the laying out animation is as I described in the 25-image example. On the other hand, I could forgo using 98 subviews and do everything (one-time animated layout *and* animated pulsation) inside the superview's -drawRect. This second option is where I'm unsure how to proceed. The solution I have now (98 subviews) works and is convenient but is taxing the device, so I'm looking for a better alternative, performance-wise. If it's taxing the device, then I would recommend creating your own view, and compositing the images yourself in drawRect:, as you suggest. To get your animation, just set a timer at your frame rate and call setNeedsDisplay on the view in its callback. Inside drawRect, you could either work out what to display based on the time, or you could set some flags in your timer routine setting 'state' for drawrect to use before you make the setNeedsDisplay call. Look at the UIImage's drawInRect and/or drawAtPoint: methods for how to draw the images. There are methods that let you specify alpha and blend mode, and the drawInRect method will scale the image to fit the rect you specify. Note that you won't need an UIImage instance for every 'ball' - ones that are the same looking can just be drawn by reusing the same UIImage instance and drawing it multiple times. If this is still taxing, you might want to look into using a custom OpenGL view to do your rendering (although you might want to run through a few OpenGL tutorials first if you've never used OpenGL before, I'd say it's quite a different style of API in many ways). Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to animate the drawing of UIImages inside a drawRect: method of a UIView?
This is not doing exactly what you think it is.
You are certainly right that UIKit calls should /always/ be made from
the main thread, but the performSelector:withObject:AfterDelay
method actually performs the selector on the same thread that you call
it from, not a separate thread. This means that - presuming
viewDidLoad: is getting called on the main thread, which it is if it's
the system that's calling it - your addViewInSeparateThread: is in
fact getting called on the main thread.
You could not have the addViewInSeparateThread: method at-all, and
just call performSelector:withObject:AfterDelay with your
@selector(addViewInMainThread:) selector, and it would have the same
effect.
Jamie.
On 31 Mar 2009, at 17:20, WT wrote:
Hello again,
in anticipation that the answer to my question might be to add
UIImageViews as subviews rather than to draw UIImages from within
the superview's drawRect:, I tried the following little test, which
works like a charm. The question remains, though, whether this is
the right/best approach.
Wagner
The following code goes in the view controller managing the view
where the images should be drawn into. It adds 25 image views to the
view managed by the view controller, as a 5 x 5 grid, with a
separation of 40 pixels between images. The grid rectangle has an
origin at x = 30, y = 50. The time delay between images is 0.1
second, for a total animation time of 2.5 seconds.
- (void) viewDidLoad
{
for (int i = 0; i 5; ++i)
{
CGFloat x = 40*i + 30;
for (int j = 0; j 5; ++j)
{
CGFloat y = 40*j + 50;
UIImageView* imgView = [[UIImageView alloc]
initWithImage: [UIImage imageNamed: @img.png]];
CGRect frame = imgView.frame;
frame.origin.x = x - frame.size.width / 2.0;
frame.origin.y = y - frame.size.height / 2.0;
imgView.frame = frame;
[self performSelector: @selector(addViewInSeparateThread:)
withObject: imgView
afterDelay: (5*j + i) / 10.0];
[imgView release];
}
}
}
- (void) addViewInSeparateThread: (UIView*) imgView
{
[self performSelectorOnMainThread: @selector(addViewInMainThread:)
withObject: imgView
waitUntilDone: YES];
}
- (void) addViewInMainThread: (UIView*) imgView
{
[self.view addSubview: imgView];
}
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Memory Leak, part I
Presuming th rest of your code is following the rules, I can't see
anything obviously wrong with this code leak-wise.
Do these leaks build up every time you run the code you pasted, or is
there just one in the app's lifetime? Can you post a full backtrace
for the leak? (It may be easier to copy-and-paste this from output
from the 'leaks' command-line took - just run 'leaks myapp' in the
Terminal). I vaguely remember that there may be spurious false-
positive leaks of small bits of memory like this when creating threads
(I can't find reference to it on the Internet though - maybe someone
else remembers this too and can comment?).
What you're doing with the thread's dictionary looks a little weird
(though I don't think it's the source of a leak, presuming that
itsCalcStatus behaves correctly regarding memory management) - you're
consulting the main thread's dictionary in startBgCalculation, but,
though you don't show the full code, you're presumably consulting the
newly created thread's dictionary inside the calls to itsCalcStatus
in shouldExit and endBgCalculation?
Note, by the way, that you wight want to put an autorelease pool
inside the loop in (3). If you don't, objects created within it and
autoreleased will not get the change to be fully released until the
loop finishes, which may be a problem depending on how many
autoreleased objects are created (this is certainly not a leak though
- they will get released when control returns to (2), it'll just mean
your app has a high peak memory requirement).
If you can't get to the bottom of this, a good approach would be to
create a test Xcode project and see how little code you can put in it
to re-create the problem; that would help us on the mailing list debug
the problem with you more than copy-and-pasted code, and I often find
that just thinking about it like this helps me when I'm trying to
debug a problem of my own. It'd also be valuable to include in a bug
report to Apple if it's not something you've done that's causing the
problem.
Jamie.
On 18 Feb 2009, at 23:09, John Love wrote:
[this is part I of a two-part plea for help]
I I have read Apple's ManagingMemory.pdf and am still having
difficulty understanding the use of MallocDebug which is detailed in
MemoryMgmt.pdf. I have 5 methods in the generation of a
background thread and I cannot figure out where the memory leak is:
MallocDebug states that there is zero leakage for each of these
methods, but there is a leakage = 480 bytes in 24 nodes for
thread_start
(1)
- (void) startBgCalculation {
/*
setCalcStatus calls:
itsDictionary = [[NSThread currentThread]
threadDictionary];
[itsDictionary setValue:[NSNumber
numberWithInt:kCalculating] forKey:staticString#1];
*/
[self setCalcStatus:kCalculating];
[NSThread detachNewThreadSelector:@selector(bgCalcThread)
toTarget:self withObject:nil];
}
(2)
- (void) bgCalcThread {
NSAutoreleasePool *bgCalcThreadPool = [[NSAutoreleasePool
alloc] init];
[self doCalculation];
[self performSelectorOnMainThread:@selector(endBgCalculation/
*:*/)
withObject:nil
waitUntilDone:YES];
[bgCalcThreadPool release];
}
(3)
- (void) doCalculation {
for (row=1; row = 1; row++) { // many rows, therefore
much time
if ([self shouldExit]) break;
[self doCalculationForEachRow];
}
}
(4)
- (BOOL) shouldExit {
[self pingWorkbook]; // calls –setExcelError
(NSMutableDictionary, with 2nd key)
int NoExcelAppOrNoWorkbookErr = [self itsExcelError];
if (NoExcelAppOrNoWorkbookErr != kNoError) { // kNoError = 0
[self setCalcStatus:NoExcelAppOrNoWorkbookErr];
return YES;
}
CalcStatus theCalcStatus = [self itsCalcStatus]; //
(NSMutableDictionary, 1st key)
if (theCalcStatus == kStopped) { // = a 2nd int
return YES;
}
else {
return NO;
}
}
(5)
- (void) endBgCalculation/ {
CalcStatus theCalcStatus = [self itsCalcStatus]; //
(NSMutableDictionary, 1st key)
if (theCalcStatus == kCalculating) { // a 3rd int
// do stuff
}
else {
// do stuff
}
}
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Memory Leak, part I
On 19 Feb 2009, at 09:41, James Montgomerie wrote: If you don't, objects created within it and autoreleased will not get the change to be fully released until the loop finishes, Not quite sure how I came up with sentence construction like that. What I meant was, If you don't, objects autoreleased within it will not be fully released until the loop finishes. Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Returning to this months-old thread... Apologies for the length of
the mail, I thought it best to summarise what went before.
I suggested that an appropriate implementation for
didReceiveMemoryWarning in a UIViewController subclass would be
On 22 Nov 2008, at 15:58, James Montgomerie wrote:
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
// Will not call loadView if the view is not loaded, because
// we can assume that if we get past the check for anOutlet
// the view must already be loaded.
self.anOutlet = nil;
}
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
}
mmalc looked into it, and said:
On 23 Nov 2008, at 20:10, mmalcolm crawford wrote:
It seems that, for various reasons, the setView: approach is still
preferred.
I left the code in my app as-is, because I didn't fancy changing it
all, and the response didn't indicate (to me, at least) that I was
doing anything unsafe, but after some testing I'm rethinking that.
Is the reason that the setView: approach is preferred that, despite
what the docs and comments in the files say, the superclass'
didReceiveMemoryWarning might /not/ actually release the view, even if
it doesn't have a superview? This would lead to the situation in
which, when the UIViewController is next used, loadView is not called
(because the view is not nil), but my resources /are/ nil, because I
released them in didReceiveMemoryWarning when I saw that the view had
no superview.
That's what my playing around seems to suggest, in the simulator,
calling didReceiveMemoryWarning directly, at least:
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
NSLog(@Released);
}
[super didReceiveMemoryWarning];
// accessing the ivar directly to avoid loadView - very much just
for testing purposes!
NSLog(@View: %p, %@, self-_view, self-_view);
}
produces, when I call didReceiveMemoryWarning directly, with the view
not visible:
2009-02-19 19:56:00.625 MyApp[76455:20b] Released
2009-02-19 19:56:00.626 MyApp[76455:20b] View: 0x43b24c0, UIView:
0x43b24c0
Jamie.
For those who didn't follow the original thread, the setView:
approach is, by the way:
On Nov 18, 2008, at 1:19 PM, Greg Titus wrote:
The way to handle this is to _not_ respond to memory warnings in
subclasses (at least not for the purposes of view outlet handling -
there may be other non-view memory you want to free up in response
to a memory warning). Instead, implement -setView: in your
UIViewController subclass, and release outlets when the argument is
nil. For example:
- (void)setView:(UIView *)aView;
{
if (!aView) {
self.anOutlet = nil;
self.anotherOutlet = nil;
self.thirdOutlet = nil;
}
[super setView:aView];
}
This will correctly clean up all of your outlets whenever the
UIViewController unloads its view, and not otherwise.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On 19 Feb 2009, at 21:41, Ricky Sharp wrote: On Feb 19, 2009, at 2:18 PM, James Montgomerie wrote: Returning to this months-old thread... Apologies for the length of the mail, I thought it best to summarise what went before. I now have shipping iPhone OS apps and during all my tests and analyzing things in Instruments (connected to real hardware), I didn't see a reason to put the proposed code in. Perhaps this is just how I've coded things, but I've seen views get unloaded and reloaded perfectly without any leaks. This included my main screen view that was currently on the bottom of a nav controller stack (not the current view). When I popped the current screen, it was appropriately re-loaded. All IBOutlets re-wired, etc. My dealloc code is doing stuff like: self.someIBOutlet = nil; self.someOtherIvar = nil; ... [super dealloc] I'm _definitely_ not trying to be argumentative or propose that others avoid the proper solution. Just wanted to point out that in my real-world situation, I just haven't had the need for it. I feel like I may have opened a can of worms here. To be clear, I was not saying that there were any problems at-all with default implementations of these methods - the only potential problem is if you try to be 'smart' in the wrong way about what you do in didReceiveMemroyWarning with respect to outlets or other resources loaded manually in loadView. There's also no problem if you follow the now-recommended route of nilling out outlets in setView - I was just enquiring if my way of doing things was actively /wrong/ (which seems to be the case, unfortunately for me). Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSXML Auto Release Pools
On 4 Feb 2009, at 18:06, Alan Shouls wrote: I am using NSXML in a C++ and am working through some test cases and have come across something I can't quite figure out. Here is what I do: 1. Create an Auto Release Pool 2. Create an NSXML object using [NSXMLDocument alloc] initWithData: (NSData *)data options:NSXMLNodeOptionsNone error:pError] 3. Release the Auto Release Pool 4. Release my NSXML object I then get a warning NSCFString autoreleased with no pool in place - just leaking If, however I do things so that I release my NSXML object before releaseing the Auto Release Pool - no message. The NSXML object is probably calling autorelease on something in its dealloc method (this is perfectly legal, and should generally be seen as implementation detail - you're just seeing a side effect of it here). In general, you need to wrap your /entire/ Cocoa usage in an autorelease pool if you're using it in a non-Cocoa app (or a thread that doesn't otherwise have a pool pre-created for you), to account for just this sort of thing. Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App Listener?
On 8 Jan 2009, at 14:14, Rainer Brockerhoff wrote:
Today, the only solution seems to be to install a Carbon Event
handler for the {kEventClassApplication, kEventAppFrontSwitched}
event.
Even if such a NSWorkspace notification were to appear in a future
version of Mac OS X, I'd be interested in a lower-level solution. I
have a background process that can't link to AppKit due to security
restrictions, and Carbon Events have gone away for 64-bit processes.
I did look at how HIToolbox does its magic, but it appears to be
listening to a private notification from the Process Manager. And
BSD, of course, has no concept of front process. If nobody knows
another public API for an app activation notification, I'll file an
enhancement request.
If you don't mind asking your users to switch on accessibility access
(enable access for assistive devices in the Universal Access
preferences), you can use the Accessibility APIs to monitor app
switching (this is what's used in the iChatStatusFromApplication
sample code, for example - http://developer.apple.com/samplecode/iChatStatusFromApplication/)
.
I say this informationally - I don't think it's a great solution either.
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Printing PDF Documentation
On 6 Jan 2009, at 13:20, Development wrote: No, I do not need to write code to work with PDF; the example program to do this is pretty good. However, lots of documentation from Apple and other companies are not available exclusively as PDF file. Does anyone know of a good reliable source for printing out hard copy of the documents? Let's say I have a specific PDF reference that I am constantly looking at. Having the 100 page document printed and bound into a simple binding would be worth the cost for me. Has anyone found a printing company online that can handle one time job like this? At reasonable rate? My local print/copy shop did a great job of printing and binding (half size, with a metallic comb so it sits on my desk nicely) something like this for me. You could look yours up in the yellow pages and give them a call for pricing. Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to pass arguments by reference
What you're looking to do is a C++ism, it's not available in Objective-
C; there's no explicit support for pass by reference.
It's certainly possible to achieve the same ends though. For
primitive types, you'll have to pass a pointer. Declare the method as
taking, for example 'int *' if you want to pass a pointer-to-int, and
call it by taking the address of the thing you want to pass a pointer
to (e.g. use 'myInt' if 'myint' is the primitive you want to pass by
reference).
For Obj-C objects, 'pass by reference' effectively always happens,
because you have to pass a pointer to the object (like an
'NSMutableString *') anyway.
Jamie.
On 10 Dec 2008, at 15:53, Nick Rogers wrote:
Hi, thanks for the reply.
Now I have:
- (UInt32)traverseTreeStraightReturnedDirection:(int)treeDirection
returnedTreeDepth:(int)treeDepth
returnedKey:(HPlusCatalogKey)catKey
lookForKey:(HPlusCatalogKey)lastKey
{
// code here
}
Still the same error: parse error before token
Thanks,
Nick
On 10-Dec-08, at 9:15 PM, Dave DeLong wrote:
Put the before the variable type:
- (UInt32) traverseTreeStraightReturnedDirection:
(int)treeDirection...
HTH,
Dave
On Dec 10, 2008, at 8:43 AM, Nick Rogers wrote:
Hi,
I have the following in my .m file:
- (UInt32)traverseTreeStraightReturnedDirection:(int)treeDirection
returnedTreeDepth:(int)treeDepth
returnedKey:(HPlusCatalogKey)catKey
lookForKey:(HPlusCatalogKey)lastKey
{
// code here
}
But the error when compiling is parse error before token.
Is passing by reference not allowed or is there any other syntax
that I should follow?
Thanks,
Nick
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/roger_s1%40mac.com
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: to get handle to File/1.jpg
On 26 Nov 2008, at 14:56, Nick Rogers wrote: Hi, How do I obtain a NSFileHandle to this file which has a forward slash in the name to be able to write to this file. Supplying the path to NSFileHandle with filename in quotes also fails. If not possible is there any other way to write to such a file. I can't use open(), as the file name could contain chars from other language. This file is only presented as having a '/' in the Finder UI (and hopefully other places that present filenames on-screen). At the filesystem level, that '/' is really a ':' (to avoid clashing with the '/' directory seperator character). Just replace the '/' with a ':' and you'll be set. As an aside, there's no reason you can't use open with files that have non-ASCII characters in their filenames. All the BSD-level filesystem APIs accept UTF-8. If you have an NSString containing the non-ASCII filename, you can just call '[myString fileSystemRepresentation]' to get an appropriate char * for use with the BSD level APIs (you'll still need to replace your '/'s with ':'s first though). Jamie, ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: to get handle to File/1.jpg
On 26 Nov 2008, at 15:28, Jean-Daniel Dupas wrote: Le 26 nov. 08 à 16:19, James Montgomerie a écrit : On 26 Nov 2008, at 14:56, Nick Rogers wrote: Hi, How do I obtain a NSFileHandle to this file which has a forward slash in the name to be able to write to this file. Supplying the path to NSFileHandle with filename in quotes also fails. If not possible is there any other way to write to such a file. I can't use open(), as the file name could contain chars from other language. This file is only presented as having a '/' in the Finder UI (and hopefully other places that present filenames on-screen). At the filesystem level, that '/' is really a ':' (to avoid clashing with the '/' directory seperator character). Just replace the '/' with a ':' and you'll be set. In fact, this is the contrary. It is presented as having a colon at the UNIX level, but really have a slash at the FS level. http://www.macgeekery.com/gspot/2006-09/when_a_colons_a_slash_and_a_slashs_a_colon True (on HFS and HFS-derived systems). I'd call that more of an implementation detail though - It's not as if the filenames are stored on disk as UTF-8 strings either, but I'd still way that 'at the filesystem level', from an API-user's perspective, that's true. Anyway, for someone who just wants to open a file, this is a bit academic. The API's require UTF-8, and accept ':' characters, but not '/' characters. '/' characters displayed in the Finder must be translated to ':' characters for interaction with the filesystem APIs, and vice-versa. Jamie.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On 22 Nov 2008, at 00:53, mmalcolm crawford wrote:
Context:
UIViewController provides a method, didReceiveMemoryWarning, which
is invoked on view controllers when the amount of memory available
to the application is severely constrained. The goal of the method
is to allow view controllers to dispose of resources that are
currently not needed and that can be recreated later if required.
One such resource is the view controller's view itself. Assuming
that it does not have a superview, the view is disposed of ([self
setView:nil];).
A issue arises in that outlets to elements within the nib file are
typically declared as follows:
@property (nonatomic, retain) IBOutlet ElementClass *element;
Thus even though the main view is disposed of, absent any further
action the outlets are still retained. This is not in and of itself
a problem -- if and when the main view is reloaded, they will simply
be replaced -- but it does mean that the beneficial effect of the
didReceiveMemoryWarning is reduced.
There are, currently, a couple of possible remedies...
Maybe I'm missing something (I stopped following the previous thread),
but, presuming that super's -didreceiveMemoryWarning does indeed
Release[] the view if it doesn't have a superview, as documented,
couldn't these contortions be avoided (in a future-proof way) by doing
something like this in -didReceiveMemoryWarning, and not touching -
setView:?
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
// Will not call loadView if the view is not loaded, because
// we can assume that if we get past the check for anOutlet
// the view must already be loaded.
self.anOutlet = nil;
}
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
}
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
But I'm assuming that self.anOutlet will be valid if and only if
self.view is already valid (in which case the call to
self.view.superview should be safe, no?).
Under this assumption, if self.anOutlet is nil, the be short-
circuited and self.view never called; if it is valid, it's safe to
call self.view.
It seems like, for this assumption not to hold, the outlets must not
be being set up at the same time as the view (which I guess could be
true if the programmer of the subclass we're talking about is doing
something strange, but is not what I would expect).
Jamie.
On 22 Nov 2008, at 16:16, mmalcolm crawford wrote:
On Nov 22, 2008, at 7:58 AM, James Montgomerie wrote:
if(self.anOutlet !self.view.superview) {
On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote:
You could invoke 'view':
- (void)didReceiveMemoryWarning {
if ([self.view superview] == nil) {
// set outlets to nil
}
[super didReceiveMemoryWarning];
}
but this has the disadvantages that (a) in some situations it will
cause the view to be loaded before it is subsequently unloaded, and
(b) it isn't future proof.
mmalc
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On 22 Nov 2008, at 16:29, mmalcolm crawford wrote: On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. Oops, sorry, looks like we're mailing around each other now... Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21 Aug 2008, at 09:06, Clark Cox wrote:
This is not a hack or a coincidence, this is by design. A non-NULL
pointer *is* a boolean expression that evaluates to true, just as a
non-zero integer is. Again, it doesn't work by coincidence, it is a
guarantee of the language standard.
To go off on a bit of a tangent, if you read this without thinking of
all the implications of other parts of the language you /can/ still
run into problems. For example:
BOOL b = (BOOL)v;
could leave you with b == NO even if v != 0.
If BOOL is a shorter type than value's type (e.g. if BOOL is char and
v is long), and if the lower bits of v are all 0 but the higher bits
are not, the higher bits will just get truncated off in the conversion.
i.e. this:
---
#include Foundation/Foundation.h
int main() {
int myFlags = 0x01000200;
int myBitMask = 0x0100;
BOOL isFlagSet = (BOOL)(myFlags myBitMask);
if(isFlagSet == NO) { // Could (of course) use if(!isMasked)
here, I just used this for clarity
printf(Oh No!\n);
}
return 1;
}
---
gives:
---
Thing:tmp jamie$ gcc test.m -framework Foundation
Thing:tmp jamie$ ./a.out
Oh No!
---
This has puzzled me for a while in the past when I was wondering why
my bit masks were not evaluating correctly.
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Receive notifications about frontmost application change
On 9 Jul 2008, at 18:46, Bill Cheeseman wrote: on 2008-07-09 11:44 AM, Jens Alfke at [EMAIL PROTECTED] wrote: On 9 Jul '08, at 3:22 AM, Александр Даровских wrote: Hi, Is there any way to subscribe to frontmost application change notification? For example, via NSDistributedNotificationCenter or some other facility? I have managed to get process startup and shutdown notifications, but I cannot get active application change notification. Maybe it is done in somehow another way? You can register to observe the accessibility notifications AXApplicationActivated and AXApplicationDeactivated. These require you to register to observe a specific target application. Therefore, in order to catch every application switch, use the NSWorkspace -activeApplication method to get the name of the current active application, register to observe when it deactivates, then when it does deactivate get the new -activeApplication and register to observe when it deactivates, and so on. See Apple's iChatStatusFromApplication sample code for Leopard to see exactly how to implement this. This does require, though, that the user has Enable access for assistive devices enabled in the Universal Access preferences pane (the Carbon method does not). Jamie.___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
A question of style: Returning 'pairs'
Say I have a method that needs to return two equally important values (in my case, a string and an offset into it). I am overthinking how to do it, and I though it would be interesting to see what others have done. I see these opportunities (my use of 'object' and 'value' is blurred below, since I'm thinking of the abstract case - assume that both values could be objects): 1) Just return the first value, and have the caller supply an argument that the second value gets written into (akin to how NSError is customarily used). This seems a bit unclean, since one value is not more important than the other, and both are necessarily returned. 2) Define a custom C struct (like NSRect, but with e.g. 'string' and 'offset' members) and return objects in it. Just like any other returned objects, the caller would be expected to retain them individually if it needed to keep them around. 3) Define a custom Obj-C class with two properties [e.g. 'string' and 'offset'] and return an object of that class (with properties appropriately set). 4) Create a 'Pair' C struct with two ids in it. Use it like the custom struct in (2). This struct is more reusable than the one in (2), so this solution seems less 'heavyweight', but it is less descriptive. 5) Define a 'Pair' Obj-C class with 'first' and 'second' properties, use as (3). Again, more reusable, less 'heavy' seeming than (3), but less descriptive. 6) Return an NSArray with two items in it (this seems the least descriptive option, from the point of view of someone reading the header). 7) Return an NSDictionary with two items in it, keyed by their property names. This seems a bit wasteful, since the dynamicisim of a dictionary is not required, and is also not so descriptive from a header-reading perspective. Oh, and there's also 8) Rename the file .mm, and use a C++ std::pairid, id class. (Only joking :-) How would you do this? Are there other, better options? Jamie. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Regular Expressions?
On 6 Jun 2008, at 08:03, Jens Alfke wrote:
On 6 Jun '08, at 3:23 AM, Jason Stephenson wrote:
As a long time UNIX programmer, I'll suggest looking into the
regexp library that already comes with OS X.
man regcomp on the command line to find out how to use.
It doesn't look as though this library is Unicode-aware. The strings
it takes are C string (char*) with no indication of what encoding is
used, and Unicode or UTF-8 aren't mentioned in the man page. From
that, I'd guess that this library only works with single-byte
encodings (like ISO-Latin-1 or CP-1252, not UTF-8 or the various non-
Roman encodings) and that it will treat all non-ascii characters as
being not spaces and not letters.
In short, I think it only works correctly with plain ascii. IMHO
that's much too limited for most purposes nowadays. Even if you
don't touch user-visible text with it, it's still pretty common to
find non-ascii characters in HTML, XML, even source code.
Of the regex libraries mentioned so far, I recommend RegexKitLite.
It's based on ICU, which is Unicode-savvy, already built into the
OS, and used by lots of Apple apps.
You are correct, but in my casual usage, feeding UTF-8 to the POSIX
regex routines works just fine if you take into account that the
defined character classes are ASCII-aware only, and are aware that the
results you get back are byte offsets, not character offsets - i.e.
don't convert them to NSRanges and expect them to be correct against
the NSString you got the UTF-8 from (similar caveats apply to match
counts etc. - i.e. .{3} will happily match two characters if they
take up three bytes).
I wouldn't want to present the regexes to the user, of course, but for
pre-defined regexes in code, it's okay (not great with those caveats
obviously, but alright).
My main complaint about it is that it's /extremely slow/ compared to
most modern regex libraries, but for casual usage, you at least don't
have to link any extra libraries to use it.
I do think that good regex additions to NSString, or an NSRegex class,
are highly overdue in Cocoa.
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: iChat theater
As you say, there is no way for an app to cause a transition to IMAVRequested, the user has to initiate the session from iChat. If your app is not document based, the user can request a session by selecting your app in the Share a file via iChat Theater file requester (or by dragging your app's icon to the video window). [EMAIL PROTECTED] is a better list for iChat Theater questions, by the way. Jamie. On 10 May 2008, at 20:44, Chilton Webb wrote: Hi Ben, I've been looking for the same answer for some time now. -Chilton On Saturday, May 10, 2008, at 01:49PM, Ben Lachman [EMAIL PROTECTED] wrote: Hey everybody. Quick question; Does anyone know a way to start an iChat theater session programatically? The IMAVManger needs to be in IMAVRequested state, but seemingly there is no way for an app to request an session, the user actually has to select share a file via iChat Theater or whatever from iChat. Apple script doesn't seem to have access to the iChat theater option either. Calling -start on the manager doesn't do anything is a session hasn't been requested (as documented). Thoughts? Thanks, -Ben -- Ben Lachman Acacia Tree Software http://acaciatreesoftware.com email: [EMAIL PROTECTED] twitter: @benlachman mobile: 740.590.0009 ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
