Re: why isn't idMyCellDelegate an id?
On 4 Oct 2013, at 10:53, Jens Alfke j...@mooseyard.com wrote: On Oct 4, 2013, at 9:59 AM, Matt Neuburg m...@tidbits.com wrote: But why is either of those necessary? Surely an idMyCellDelegate is, by definition, an id - which inherits from NSObject ‘id’ is not a type that inherits from NSObject. ‘id’ is explicitly untyped. ‘idMyCellDelegate’ is _not_ untyped — its type is ‘any class that implements MyCellDelegate'. And unless that protocol inherits from the NSObject protocol, it does not include the -respondsToSelector: method. This may seem inconsistent, but if ‘idSomeProtocol’ were really untyped, then you’d lose all type-checking for calls to it, so you could make typos like [cellDelegate f:] without any compile-time error. Right, really the confusion stems from the fact that objective-c has a strange behaviour when dealing with the type “id”. To objective-c “id” means “any object”, and the compiler takes that to mean “I don’t know what it is, so I’m going to assume this all-powerful human knows what they’re doing, and allow them to call any method at all on it.” The more mathematically correct thing to do (and what it does for all other types) is “I don’t know what it is, so I can’t ‘prove’* anything at all about whether this is correct, therefore it’s not correct. Puny human, you must provide me with more information to make proofs”. Unfortunately, thanks to obj-c’s lack of parametric polymorphism, the “I have no clue what this thing is” situation comes up an awful lot, and it becomes decidedly inconvenient to have that second, more correct behaviour, so I guess someone made a pragmatic decision to effectively disable all checking when ids come up. My recommendation would be to file a radar about this, along with the fact that ids come up all the time, and show some support for wanting a language where the compiler can make more proofs for us. Thanks Tom Davie * prove is a loaded term when it comes to objective-c, as the runtime can mess up your compile time proof by dynamically switching things about under your feet. ___ 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: Analyser reports memory leak… where?
On 12 Sep 2013, at 18:15, Daniel Höpfl ap...@hoepfl.de wrote:
On 2013-09-12 17:52, Graham Cox wrote:
I believe it does. I think your reading of the getter convention may
be incorrect. If you can point to explicit documentation that states
that the returned object must belong to an autorelease pool, I'll
stand corrected, but that would be the first time I've ever heard that
in 13 years of Cocoa programming!
Even if there is such a rule:
- (id) eventTypes
{
// [self lazyInitEventTypes];
return [[mEventTypes retain] autorelease];
}
It’s not a hard and fast rule, and in fact collection access does not do this,
so it’s entirely possible to do things like:
id a = x[5];
[x removeObjectAtIndex:5];
[a crashMyProgram];
Tom Davie
___
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: 64-bit iOS
On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote: For ARM, 64 bit matters because the instruction set has been updated to provider better performances. I just hope the performance boost provided by this architecture change will be enough to balance the slow-down due to the increase of instruction and pointer size. Note, this was actually more significant on x86, where most of the mess caused by CISC (like having bugger all registers) got sorted out. Tom Davie ___ 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: 64-bit iOS
On 10 Sep 2013, at 22:48, Scott Ribe scott_r...@elevated-dev.com wrote: On Sep 10, 2013, at 2:39 PM, Joseph Dixon s...@dixondata.com wrote: Some operations that would have taken 2 cycles may now be done in one. Some. Probably not many. Surely that leads to a performance boost, right? Maybe, maybe not. The flip side is that pointers are twice as large, so half as many fit in cache. And off when you do need to hit RAM you need to fetch more data. Tom Davie ___ 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: Unicode chars in string
On 9 Sep 2013, at 09:13, Damien Cooke dam...@smartphonedev.com wrote: Hi all, I am pulling my hair out here trying to replace the unicode (r) symbol with \\00ea in a string. Is there a way of doing this as the NSString is a unicode String so it is interpreting it. As convenient that might be to most people it is killing me here. NSStrings already support unicode quite happily. clang will even let you use unicode directly in the source, so [string stringByReplacingOccurancesOfString:@“r” withString:@“somethingElse”] will work happily, as will [string stringByReplacingOccurancesOfString:@“→” withString:@“⤜”]. Tom Davie ___ 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
On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. Tom Davie ___ 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
On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? 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). It’s fair to say that large chunks of this code could be optimised by removing a bunch of object allocation/deallocation, but I think it’s fairly representative of the style most obj-c code will be written in, and hence a pretty fair test. 100 % slowdown! i suggest you push the Continue button after hitting your breakpoint :) Joking apart, i am surprised that you find things slower, but i never did any adequate performance comparisons myself. Yes, I too was surprised by that, this was in fact the first example I tried profiling, so I was even more surprised, and went out and tested a bunch more bits of code. I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. For me the distinction is more along performance lines. If you’re dealing with code that you’re already thinking “hmm, rewriting the cores of this in C, rather than high level obj-c would get me a nice performance gain”, then ARC is probably not for that code. If on the other hand, you’re writing an application that does normal interactions with the user, that’s presenting bits of UI, and grabbing data from the internet, and not really doing much CPU intensive stuff, then ARC is almost certainly a major boon for that code. Tom Davie ___ 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
On 9 Sep 2013, at 11:49, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 11:33, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? 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). I'd be interested to dig a little further in what cause the slowdown. Do you have some sample code/file that can be used to stress the library and profile it ? Sure, there’s a simple example at https://github.com/beelsebob/ParseTest/, alternatively, you can profile the test cases included with CoreParse. Tom Davie ___ 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: 30x faster JSON date parsing
On 9 Sep 2013, at 20:29, Rick Mann rm...@latencyzero.com wrote: On Sep 9, 2013, at 09:25 , Maxthon Chan xcvi...@me.com wrote: This may not be that useful in all circumstances - I always send dates as milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way* faster to parse. Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or other human-readable format) dates. Yes, it absolutely is, when no human is going to read them. Tom Davie ___ 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: Threadsafe copy of objective c object
What I’m surprised no on has mentioned here is the trivial… Remove the mutation methods. Make your object immutable, the referential transparency will give you “free” parallelism. If you want a mutated version of the object, create a new object. Tom Davie ___ 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: Introducing ioscomponents.com
For reference, I’m not convinced that you needed them here, but instead, that you didn’t devote enough thought to how that UI should work on a touch screen. There’s no reason why your preferences couldn’t have used a column of UISwitches. Your export panel could have used a UISegmentedControl to select the export type, and a UIPicker to select the export format. That said, don’t get disheartened – a good, high quality data table is something that would be very useful on iOS – just try to polish it up more! Tom Davie On 27 Aug 2013, at 04:56, Jason Gibbs iosmaniac...@gmail.com wrote: Also one more thing - A few of you messaged me about this privately - I am quite surprised why everyone is looking at the checkbox/radio button exclusively - This is such a tiny part of the whole thing - we actually built it just because we needed it inside the our main DataGrid product (multi select filter has checkboxes) But we built everything as stand alone so they can be used indepentant of each other. our real product is the iOSDataGridView : http://www.ioscomponents.com/Home/IOSDataGrid Is our site not pushing that message very well? On Mon, Aug 26, 2013 at 10:42 PM, Jason Gibbs iosmaniac...@gmail.comwrote: All, thanks for your candid feedback - I realize we have some work to do, but I am glad to see the feedback. If there is anything else you think we can address, please free to bring it on - we can take it! The one thing I would like to add, we;re not a design company - we are a component vendor - all those components are meant to be skinnable and styleable. In fact we have a number of examples of themes and such. But you are right - we need a good iOS theme which is the default. On Mon, Aug 26, 2013 at 5:33 PM, Fritz Anderson fri...@manoverboard.orgwrote: [It happens I'm replying to Jonathan Hill, when my use of you refers to Jason Gibbs. A vagary of how I try to cut down quotes and recipient lists.] And to pile on, intercaps (camelCase) is a good idea in code (or underscores, I'm not picking a fight here), and common in cheesy trademarks (sorryApple), but when you address normal people, they aren't acceptable. Cheesier still if it isn't even a trademark. Nor are initial caps used in mid-sentence for words that are not proper names, including trademarks. It's a check box, not a CheckBox. Perhaps that's how you spell it in your API. Nobody cares how you spell it in your API, except when they're writing to your API. I'd like to see how this works out. Some very smart people have devoted a lot of thought to how mouse-and-keyboard UI would work on four-inch touch screens. — F On 26 Aug 2013, at 2:17 AM, Jonathan Hull jh...@gbis.com wrote: Good URL. The components don't really feel like they fit on iOS. Feels more like a XP UI than iOS. From your website, it seems like the components have lots of good features, but you should definitely hire a designer with iOS experience to help them feel at home on the platform... ___ 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/iosmaniacdev%40gmail.com This email sent to iosmaniac...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to fix warning?
On 28 Aug 2013, at 22:26, Dave d...@looktowindward.com wrote: Hi, I am getting the following warning warning: format specifies type 'unsigned short' but the argument has type 'int' [-Wformat] on this statement: NSCharacterSet *stopCharacters = [NSCharacterSet characterSetWithCharactersInString:[NSString stringWithFormat:@ \t\n\r%C%C%C%C, 0x0085, 0x000C, 0x2028, 0x2029]]; What is the best way to fix this? The type of integer literals in C is “int” by default. If you want them to be shorts (or unsigned, as is the bigger issue in this case), you must cast them either explicitly (by adding the casts in this expression), or implicitly, by assigning the littorals to a variable of the desired type. Tom Davie ___ 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: IB autolayout is impossible
In general, please file a bug report at bugreport.apple.com. For what it’s worth, I agree, and I don’t think IB should be doing anything at all to try and guess what constraints we want, or even to keep them consistent. The spirit of the dev tools is to allow you to do whatever you want (even if it’s wrong), and to tell you when it’s wrong. The unsatisfiable constraints should simply come up as errors/warnings when the xib is compiled. This would lead to a whole lot less frustration when it comes to IB deciding to change everything you already set up simply because you added one extra view. Tom Davie On 20 Aug 2013, at 01:48, dangerwillrobinsondan...@gmail.com wrote: In general in 4.x add your constraints that will make a satisfiable layout, then remove the ones you don't want. The next one does less trying without asking but this one is not that bad if people follow the flow: add yours, remove theirs. Sent from my iPhone On 2013/08/20, at 7:40, Rick Mann rm...@latencyzero.com wrote: I want to create a view with size 74 x 74, containing three subviews, all centered on it. But IB is just a game of whack-a-mole. So angry. -- Rick _ ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: IB autolayout is impossible
Right, I agree, radarweb’s behaviour is pretty abominable, you can’t see anything at all going on. But that doesn’t change the fact, making radars is the only way these things get fixed. I’m glad to hear you’ve reported many already. Please make more if you can think of unique things that IB is doing very wrong here :D Tom Davie On 20 Aug 2013, at 09:55, Rick Mann rm...@latencyzero.com wrote: I have filed literally hundreds of bug reports. I get the spirit of what you're saying, but I'm so stressed from this project (and IB's hand in it), and so demoralized from having my bugs come back as either Duplicate, or Behaves Correctly, or just stay Open forever, and finally, having to wait for the next major release to see them fixed (rather than fixed in a dot release), that it's getting nearly impossible to summon the will to write more bugs. On Aug 20, 2013, at 00:51 , Tom Davie tom.da...@gmail.com wrote: In general, please file a bug report at bugreport.apple.com. For what it’s worth, I agree, and I don’t think IB should be doing anything at all to try and guess what constraints we want, or even to keep them consistent. The spirit of the dev tools is to allow you to do whatever you want (even if it’s wrong), and to tell you when it’s wrong. The unsatisfiable constraints should simply come up as errors/warnings when the xib is compiled. This would lead to a whole lot less frustration when it comes to IB deciding to change everything you already set up simply because you added one extra view. Tom Davie On 20 Aug 2013, at 01:48, dangerwillrobinsondan...@gmail.com wrote: In general in 4.x add your constraints that will make a satisfiable layout, then remove the ones you don't want. The next one does less trying without asking but this one is not that bad if people follow the flow: add yours, remove theirs. Sent from my iPhone On 2013/08/20, at 7:40, Rick Mann rm...@latencyzero.com wrote: I want to create a view with size 74 x 74, containing three subviews, all centered on it. But IB is just a game of whack-a-mole. So angry. -- Rick _ ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com -- Rick ___ 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: NSLog object = nil?
On 20 Aug 2013, at 23:32, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: Dear list, I have the following structure: An itemStore object creates a worker object (property of itemStore object) that hold a weak reference back to the itemStore object; When the worker classes is done, it sets the itemStore object (of which the worker class itself is a property) to nil. This project uses ARC. So within itemStore I do: self.worker = [[Worker alloc] init]; [self.worker setItemStore:self]; In Worker.h I do @property (nonatomic, weak) ItemStore *itemStore; In Worker.m, when all its tasks are done, I do self.itemStore = nil; I assume this completely destroys the itemStore object and all objects it exclusively owns. Is there any way to NSLog the destruction of the itemStore object? I tried putting a log in itemStore's dealloc method, but it doesn't show up in the console. No, this doesn’t destroy the item store at all. If the Worker holds a weak reference, then it setting its reference to nil will not do anything at all re memory management. Instead, whatever is holding strong references to the item store needs to release those references. Tom Davie ___ 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 detect a Retina Mac
On 18 Aug 2013, at 15:03, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I just noticed that the program I use to create Png files creates files with twice the number of pixels in each dimension. Obviously because since I last used it, I have switched to a Retina Mac Book. Ok, so I have to fix this program. The correct way to fix this problem is to create an image via CGContextCreate and CGContextCreateImage. When doing this you specify pixel rather than point dimensions, and do not have the issue you’re experiencing. You detect a retina device by testing scaleFactor as you suggested, it’s just unnecessary here. Tom Davie ___ 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 detect a Retina Mac
On 18 Aug 2013, at 15:56, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 18 Aug 2013, at 20:09, Tom Davie tom.da...@gmail.com wrote: On 18 Aug 2013, at 15:03, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I just noticed that the program I use to create Png files creates files with twice the number of pixels in each dimension. Obviously because since I last used it, I have switched to a Retina Mac Book. Ok, so I have to fix this program. The correct way to fix this problem is to create an image via CGContextCreate and CGContextCreateImage. When doing this you specify pixel rather than point dimensions, and do not have the issue you’re experiencing. You detect a retina device by testing scaleFactor as you suggested, it’s just unnecessary here. I just asked Xcode about CGContextCreate and it told me that there is absolutely no information available. Could anybody help me with some link to some documentation? Uhh sorry, my bad, I meant CG*Bitmap*ContextCreate… http://developer.apple.com/library/ios/documentation/graphicsimaging/Reference/CGBitmapContext/Reference/reference.html Tom Davie ___ 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 detect a Retina Mac
On 18 Aug 2013, at 16:27, Simone Tellini cocoa-...@tellini.info wrote: Il giorno 18/ago/2013, alle ore 15:03, Gerriet M. Denkmann gerr...@mdenkmann.de ha scritto: I just noticed that the program I use to create Png files creates files with twice the number of pixels in each dimension. Obviously because since I last used it, I have switched to a Retina Mac Book. Ok, so I have to fix this program. you can do something like this: NSSize size = ...; NSBitmapImageRep*bitmapRep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes: NULL pixelsWide: size.width pixelsHigh: size.height bitsPerSample: 8 samplesPerPixel: 4 hasAlpha: YES isPlanar: NO colorSpaceName: NSCalibratedRGBColorSpace bitmapFormat: NSAlphaFirstBitmapFormat bytesPerRow: 0 bitsPerPixel: 0]; NSGraphicsContext *bmCtx; NSAffineTransform *transform = [NSAffineTransform transform]; [bitmapRep setSize: size]; bmCtx = [NSGraphicsContext graphicsContextWithBitmapImageRep: bitmapRep]; bmCtx = [NSGraphicsContext graphicsContextWithGraphicsPort: [bmCtx graphicsPort] flipped: YES]; [NSGraphicsContext saveGraphicsState]; [NSGraphicsContext setCurrentContext: bmCtx]; [transform translateXBy: 0 yBy: size.height]; [transform scaleXBy: 1 yBy: -1]; [transform set]; ...do some drawing... [NSGraphicsContext restoreGraphicsState]; data = [bitmapRep representationUsingType: NSPNGFileType properties: nil]; [bitmapRep release]; No need for the complex cocoa to CG manoeuvrings there, this will do fine: NSSize size = …; CGColorSpaceRef rgbColorSpace = CGColorSpaceCreateDeviceRGB(); CGContextRef ctx = CGBitmapContextCreate(NULL, size.width, size.height, 8, 8 * 4 * size.width, rgbColorSpace, kCGBitmapAlphaInfoMask kCGAlphaLast); CFRelease(rgbColorSpace); … do some drawing … CGImageRef img = CGBitmapContextCreateImage(ctx); CGContextRelease(ctx); return [[[NSImage alloc] initWithCGImage:img size:size] autorelease]; Thanks Tom Davie ___ 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: reverse scanner
Heh, I’d actually argue that NSScanner is a much much better API to use here (and in fact nearly everywhere). Regular expressions constrain you only to regular grammars, which are a pretty small set. In my experience 99% of the use of them is actually trying to parse something that’s not *quite* a regular grammar, and uses a hack on top of regular expressions to do something not-quite-right. NSScanner by comparison makes the separation of what’s scanning/tokenisation, and what’s up to your (turing complete) program much more clear. So basically, (at least in my opinion), if you want to parse something that’s regular, NSScanner is a great choice. If you want to parse something that’s context free, look at CoreParse (Not tooting my own horn, honest). And finally, if you want to parse something that’s more even than that, then you’re probably back to NSScanner and a turing complete program. About the only use for regular expressions I can think of is asking NSScanner to scan something that it doesn’t by default know about. Tom Davie On 10 Aug 2013, at 19:53, Jerry Krinock je...@ieee.org wrote: On 2013 Aug 10, at 10:07, Boyd Collier bcolli...@cox.net wrote: but if someone has already come up with a clean way of scanning in reverse In Mac OS X 10.7+, we have NSRegularExpression. In earlier systems, call out to Perl. Regexes are fun. ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: reverse scanner
On 10 Aug 2013, at 22:44, Keary Suska cocoa-...@esoteritech.com wrote: On Aug 10, 2013, at 12:17 PM, Tom Davie wrote: Heh, I’d actually argue that NSScanner is a much much better API to use here (and in fact nearly everywhere). Regular expressions constrain you only to regular grammars, which are a pretty small set. In my experience 99% of the use of them is actually trying to parse something that’s not *quite* a regular grammar, and uses a hack on top of regular expressions to do something not-quite-right. NSScanner by comparison makes the separation of what’s scanning/tokenisation, and what’s up to your (turing complete) program much more clear. So basically, (at least in my opinion), if you want to parse something that’s regular, NSScanner is a great choice. If you want to parse something that’s context free, look at CoreParse (Not tooting my own horn, honest). And finally, if you want to parse something that’s more even than that, then you’re probably back to NSScanner and a turing complete program. About the only use for regular expressions I can think of is asking NSScanner to scan something that it doesn’t by default know about. I would agree that NSScanner is a better API than NSRegularExpression, but I think that is Apple's fault because there are better regex API's, such as RegexKit. I would argue, however, that it is NSScanner that only functions well with fixed and unvarying grammars and has no context, other than a specific, unvarying linear progression. Regular expressions have a huge grammar and when you consider conditionals and zero-width assertions you can parse information that would send NSScanner into dizzying fits. Not to mention that NSScanner can't even touch the problem that the OP is experiencing, while regular expressions will handle it very nicely. No, some hacked on extensions to regular expressions can do this. Because people keep repeatedly bumping into the problem that they’re not as powerful as CFGs, and most parsing problems aren’t regular. Tom Davie ___ 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: Mixing Obj-C and C methods
On 30 Jul 2013, at 15:44, Maxthon Chan xcvi...@me.com wrote:
My common way of handling this would be NSNotificationCenter. It is a
singleton so I am always sure that it is there, and I can wrap all parameters
into the userInfo dictionary.
NSNotificationCenter is not a singleton:
$ cat test.m
#import Foundation/Foundation.h
int main (int argc, char **argv)
{
@autoreleasepool
{
NSNotificationCenter *a = [[[NSNotificationCenter alloc] init]
autorelease];
NSNotificationCenter *b = [[[NSNotificationCenter alloc] init]
autorelease];
NSLog(@%p, %p, a, b);
}
$ clang -framework Foundation test.m
$ ./a.out
2013-08-07 09:13:25.508 a.out[6155:507] 0x7fcb1040a090, 0x7fcb1040a190
It just happens to have one instance (defaultNotificationCenter) which is
common to want to use in lots of locations in your program.
You can not “be sure that [a singleton] is there” any more or less than any
other class in your program.
For reference though, both designs for effectively making all objects in your
program global objects are pretty horrible for exactly that reason – making
everything effectively a global is just terrible design.
Tom Davie
___
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: Synchronous Serial Port Protocol messaging With NSOperationQueue/GCD
On 1 Aug 2013, at 12:03, Vanni Parronchi vanniparron...@gmail.com wrote: hi everyone, I'm writing a mac osx app that needs to talk to a serial device. There's a well known protocol to adhere to (implemented in the device firmware) and is a kind of a half-duplex synchronous protocol where if i send a message to the device from my app i have to wait till i get a response from the device, inspect it and then i'm allowed to send another message. This has to go for several messages i need to send to the device. Given this synchronous nature, i'm trying to keep the UI free so i'm doing all the messaging stuff on background threads. My choice is to use NSOperation and NSOperationQueue, where the queue is configured with maxConcurrentOperations set to 1 in order to have a strict serial behavior (this is due to the constraints given by the implemented protocol). How can i make an NSOperation subclass waiting for a signal given by the serial port delegate to make it fire isFinished KVO to the queue and make that queue consequently execute the next NSOperation? Does this approach make sense to you? My suggestion would instead be to make an NSOperation subclass for sending a message to the device. That subclass should require you to specify to which device you are talking. Each device object should carry around a dispatch_semaphore. When a message is sent, the semaphore should be checked and set to stop any other operations proceeding until the semaphore is unset. When the device responds, the semaphore should be unset. You can then make your operation queue a concurrent queue, rather than a serial one, so that you can send messages to more than one device at the same time, while still maintaining your one-thing-at-a-time per device rule. Tom Davie ___ 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 convert an NSString to
On 7 Aug 2013, at 09:24, Igor Elland igor.ell...@me.com wrote: Or if you just want to convert the spaces: string = [@Ich möchte am Wettbewerb teilnehmen stringByReplacingOccurrencesOfString:@ withString:@%20”]; Please avoid using that, if you really need **only** white space to be replaced, you want to use [@Ich möchte am Wettbewerb teilnehmen stringByReplacingCharactersInSet:[NSCharacterSet whitespaceCharacterSet] withString:@%20”] instead, as there are different UTF-8 characters for different kinds of whitespace. This is incorrect. %20 is specifically for representing the 0x20th Unicode character – that is “space”. It is not for representing other whitespace characters like tab (%09) etc. Tom Davie ___ 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: when __bridge isn't required
The first gives me the following error: Implicit conversion of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef' (aka 'const struct __CFString *') requires a bridged cast Tom Davie On Jul 27, 2013, at 8:31 PM, Matt Neuburg m...@tidbits.com wrote: I feel like I've asked this before, but I don't feel I'm grasping the answer. Why don't these work the same way under ARC: NSString* answer = @42; int ans = CFStringGetIntValue((CFStringRef)answer); and NSURL* imageSource = [NSURL new]; CGImageSourceRef src = CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. But why? They look completely parallel to me. The mystery is compounded by the fact that if you omit the cast entirely in the first example, the compiler claims that you need a bridged cast. But you don't; you just need a cast. That feels like a bug; if a mere cast is sufficient, the compiler should say so (and Fix-It should offer it as a possible fix). m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: LATIN SMALL LETTER U WITH DIAERESIS
A workaround would be to use +[NSFileHandle fileHandleForWritingAtURL: error:] and -[NSFileHandle fileDescriptor] to get you a FD to use in C land. Tom Davie On Jul 17, 2013, at 11:26 PM, koko k...@highrolls.net wrote: With this character: LATIN SMALL LETTER U WITH DIAERESIS Unicode: U+00FC, UTF-8: C3 BC in a file path (as the folder name) which I get from the NSSavePanel -filename I cannot save to the path. Some code NSString *filepath = [savePanel filename]; const char * cFilePath = [[NSFileManager defaultManager] fileSystemRepresentationWithPath:filepath]; Then in my low level I/O: FILE* f = NULL; f = fopen(path, mode); f is NULL i.e. path (the cFilePath from above) cannot open a file file writing. How should I get around this? -koko ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 11, 2013, at 8:27 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jul 10, 2013, at 23:18 , dangerwillrobinsondan...@gmail.com wrote: Is there an appropriate way to subclass NSViewController to return a custom view class or is casting the return of view or loadView the only way? You can just re-declare the 'view' property in a subclass to have the desired return type. In the implementation, you can provide an override that simply calls super, or you can cheat slightly by using '@dynamic view' in the subclass to make it use the superclass implementation. Except that view is a read/write property, and this is a type error, because of this situation: UIVCSubclass *s = [[UIVCSubclass alloc] init...]; UIViewController *vc = s; [vc setView:[[[UIView alloc] init] autorelease]; Tom Davie ___ 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: Isolated process for each NSDocument of my app
The best way is to write an application that's stable. The only reason browsers started doing this was because they had to deal with 3rd party code (e.g. flash) that was giving them a terrible reputation for instability. If you're controlling the entire app, you have no reasonable reason to do this. Simply fix your crasher bugs instead. On Thu, Jun 13, 2013 at 12:52 PM, Daniele Margutti m...@danielemargutti.comwrote: Hi guys, While I’m making an app (it’s docs based) I would to have a separated process for each opened NSDocument. The main idea is to have the main app which launch a process for each opened NSDocument/NSWindow and forward all messages to foreground window/process. In this case each process is isolated from the others as like with Safari. What’s the best way to accomplish it on OS X? Thanks a lot Daniele ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Isolated process for each NSDocument of my app
On 13 Jun 2013, at 20:29, Daniele Margutti m...@danielemargutti.com wrote: On 13 Jun 2013, at 20:05, Tom Davie tom.da...@gmail.com wrote: The best way is to write an application that's stable. The only reason browsers started doing this was because they had to deal with 3rd party code (e.g. flash) that was giving them a terrible reputation for instability. If you're controlling the entire app, you have no reasonable reason to do this. Simply fix your crasher bugs instead. Overall stability is not my reason to evaluate this kind of a architecture; for a particular reason each document should interact with an external singleton class but each singleton must be unique around the app; think about UIApplication on iOS; I need to work with a similar thing so I need to “run” multiple projects and each one must see a single instance of this object. I cannot change this kind for several reason, so an architecture like this could be a great answer to enable multiple documents support in my application. So really, what you're saying is Someone stuck a singleton where a singleton shouldn't be (anywhere at all), and now I'm screwed that I need more than one of them. Your solution to this should be to not use a singleton (ever), rather than to try and hack about the application structure to carry on using a singleton. Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 09:20, Oleg Krupnov oleg.krup...@gmail.com wrote: Blocks in Obj-C seem convenient and powerful but in fact they are very dangerous because they retain all objects referenced from the block and thereby can implicitly create circular references. If you are not vigilant about every object you mention in the block, you can create one, two or more cycles of circular references causing your objects to never be freed afterwards. This breaks encapsulation of objects with block properties (e.g. MyAnimation.completionBlock) and forces the users of such objects to always keep in mind what they can, and what the cannot write in the block body, and still they can shoot themselves in the feet at any moment by losing vigilance. It seems to me that it's much better to drop the convenience of blocks in favor of safety and full control of retain/assign relationships between my objects. This is a shocker for me too, but I do not see a good solution to this problem. The solution suggested in Session 712 WWDC 2012 is ugly - call some kind of cancel method for every block when it's no longer needed. Even with ARC, declaring a weak ref to self and then strong ref to weak ref inside the block is ugly too - you have to add this crap to each and every block you write. Your argument can equally well be applied to any object that keeps strong references to other objects. It's not blocks that are doing any of the above, it's reference counting. And we know that the issues are there – we just choose to have them because the issues with the less leaky solutions are even more severe (especially in C like languages). Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 09:34, Oleg Krupnov oleg.krup...@gmail.com wrote: Tom, I disagree, because unlike other objects with strong refs, or say @property(retain), the strong refs in blocks are created implicitly and it's just too easy to let them slip out of attention. There is no direct command to create the strong ref, unlike @property(retain). All you do is *mention* self or even an ivar, and voila, you're done. I wish there was a safe and elegant solution to this, like we did with proxy for NSTimer. I'm not really convinced that the fact that these objects are easier to dynamically create makes the problem that retain counting inherently can't deal with retain cycles any worse. That said, I wonder if the correct solution to what some are clearly finding an issue here is to look to the compiler. At least superficially, I could see it being possible to detect a lot of cycles with a static analyser. Obviously you couldn't detect all of them, but this would probably get a good way to stomping on the you used an ivar here, and self retains the block, that's bad m'kay bugs. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: I don't agree, blocks are very powerful. I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings when a block reference to a property caused a retain cycle. This is how I found it and why I mentioned it in another thread in the first place. I haven't tested it extensively, but it looks as if the compiler recognises these situations easily and then tells you about it. So I wouldn't call blocks dangerous at all… You're right – the compiler *is* detecting some simple cases, as I suggested! Note – this does not make throwing blocks around without paying attention to retain cycles inherently safe though, the compiler can not statically infer all potential cycles. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 18:35, Lee Ann Rucker lruc...@vmware.com wrote: It's easier to just use the __weak attribute, if you're using ARC: Ah, so that's when you get to use it. Well, a couple hundred files written over the course of 7 years isn't going to be ARC any time soon, nice as it might be. Luckily, if you grab Landon Fuller's PLWeakCompatibility (and possibly Mike Ash's MAZeroingWeakRef too), you'll be able to use __weak in your non-arc code too. Thanks Tom Davie ___ 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: ^Block statement considered harmful for callbacks?
On 25 Apr 2013, at 20:48, Oleg Krupnov oleg.krup...@gmail.com wrote: Yes, this is jumping through hoops, and even then you are not entirely safe. How about referencing ivars from blocks? How about referencing other objects that may in their turn reference self etc.? You have to keep it all in mind and constantly fight with the side-effects by adding more crappy hoops to your code. And it is a problem that does not even exist with delegates. On the other hand, delegates add the problem that they desiccate the code for dealing with the results from the code for setting up the request in the first place. I would consider that a much much much higher penalty than having to a bit careful about retain cycles. Thanks Tom Davie ___ 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: Followup - Re: Is there a pattern for creating an object with global scope?
On 15 Apr 2013, at 00:25, Graham Cox graham@bigpond.com wrote: On 14/04/2013, at 2:08 PM, YT y...@redwoodcontent.com wrote: My struggle is partially due to my lack of experience in OOP. I just have not written enough OO code as of yet. AND I'm very new to Objective-C. Hence my lack of experience and working knowledge of Objective-C. extern int gFoobar; I understand that solution and its working for me right now. I understand how tempting it is to go with whatever you can get working, especially when you're new to something. But in this case I believe you should resist the temptation and try and gain a little more understanding before you get too far down this road. GLOBALS ARE BAD NEWS. That is a pretty good rule and well worth sticking to. If you can get rid of globals (and you always can) then you should avoid them. There is NO problem in application programming that requires a global to solve it. Singletons are a much safer and more predictable means of achieving something that has global scope but prevents the hidden state/parameters problem that globals bring with them. Wow, I really can't get my head around this one. You make bold statements like GLOBALS ARE BAD NEWS (which I 100% agree with), but then follow up with effectively use singletons instead. Singletons bring with them 95% of the problems globals bring. They still break any attempts at threading, they still break any attempts at testing, they still break separation of concerns, and they're always avoidable. So I'd follow up with SINGLETONS ARE BAD NEWS TOO! In 95% of cases where you have a singleton, you should almost certainly be using dependancy injection instead, or some other method of avoiding it. Note also – simply using your app delegate as a store for things that aren't singletons, but only one of them is pointed at by your app delegate is also horrific – you're just substituting one singleton for another. Thanks Tom Davie ___ 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: Is there a pattern for creating an object with global scope?
On 13 Apr 2013, at 13:45, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 13.04.2013, at 06:08, Jens Alfke j...@mooseyard.com wrote:
On Apr 12, 2013, at 6:54 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
Yes, extremely easy, just create the var, as in:
int gFoobar = 42;
YT wants to create an object, which isn’t as straightforward because you
can’t have an object literal in Objective-C. Instead you declare a global
pointer and initialize it early on.
MyClass* gMyObject;
Then early at launch time:
gMyObject = [[MyClass alloc] init];
That second line could go into the -applicationDidFinishLaunching: method,
which is the usual place where stuff gets initialized.
Note that such a global variable has to be declared outside any functions.
I.e. best put it at the top of a .m file, right under the #includes. This is
essentially what you use to implement a singleton like NSUserDefaults (unless
you use dispatch_once, which might be a bit complicated for a beginner to
understand, but would be the best solution I'm told).
However, the bad thing about exposing such a global directly is that you have
no control over who accesses it when. So if you create the object in
applicationDidFinishLaunching: but some document class accesses it when a
document is opened, they'll quietly do nothing because gMyObject is NIL (or
it could crash if you call a method on it that doesn't return an object or
number).
A singleton solves that by having a method you go through to get at the
singleton object:
+(MyClass*) sharedMyClass
{
if (gMyObject == nil)
gMyObject = [[MyClass alloc] init];
return gMyObject;
}
Just a heads up, if you really want global state, and really think that a
singleton is the right way to go (I'm not gonna get into why you shouldn't
think these things as the entire premise of the thread is that you do), then
the singleton pattern is much better implemented as:
+ (instancetype)sharedMyClass
{
static MyClass *_sharedMyClass = nil;
static dispatch_once_t token;
dispatch_once(token, ^
{
_sharedMyClass = [[MyClass alloc] init];
});
return _sharedMyClass;
}
This makes the access to the singleton thread safe when it's first created. Of
course, you then get into the nightmare of trying to maintain thread safety
when you have a chunk of global state lying around, but that's a whole
different story.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
On 5 Apr 2013, at 14:55, Pax 45rpmli...@googlemail.com wrote:
On 5 Apr 2013, at 14:20, Mike Abdullah cocoa...@mikeabdullah.net wrote:
For a start, trying to access instance variables directly is almost always a
bad idea. Expose proper accessor methods instead.
Why is it a bad idea? I do this quite often, and I find it has the double
benefit of improving readability and reducing the number of lines of code.
But if it's bad then I shall look to mend my ways - but I'll need to
understand the badness first!
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the class
with the ivar, without also changing the implementation of the other class now.
I don't really understand your argument about lines of code or readability, you
would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
1) yes you could use the code you outlined to access the property
2) @property (assign, nonatomic) IBOutlet NSWindow *iWindow;
Note though to be careful about the assign tag there – you may well want that
to be a retain.
Thanks
Tom Davie
On 5 Apr 2013, at 15:06, Pax 45rpmli...@googlemail.com wrote:
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;' an
IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
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: Accessing members from NSDictionary
On 5 Apr 2013, at 16:54, Joseph Dixon s...@dixondata.com wrote: I never retain IBOutlet properties. The view retains the object when it is added, so also retaining the property would increase the retain count to 2. This assumes that the property you're talking about is a view, and that it's a subview of another view that's retained. The issue isn't quite as simple as never retain IBOutlets. Thanks Tom Davie ___ 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: cocoa bindings performance
Sorry I can't be of more direct help, but… Cocoa bindings are unfortunately one of many tools that apple produces with the thought we can make this small task I do repeatedly much easier in their head, that typically doesn't cover the general case. They're enormously productive if all you're doing is one of the obvious, standard UIs. Unfortunately, as soon as you want to do something more complex, that typically breaks down with almost any structure. This is due to 3 things: 1) Debugging them is near impossible – you end up wasting as much time as you save trying to track down what's wrong. 2) Lack of flexibility – you eventually hit a wall where bindings simply can't do what you want any more and need to rewrite everything. 3) Performance – you can't tune anything with these technologies typically. My advice would simply be to steer well clear of bindings (along with a couple of other techs that supposedly make life easier, like CoreData and Storyboards). Thanks Tom Davie On 15 Feb 2013, at 19:42, Maximilian Marcoll m...@dis.playce.info wrote: Hi everyone! I have a problem with bindings, or so it seems. In my application, I need to programmatically create lots of small views embedded in a big view. Think of them as draggable items on a plane. Thus far I'm controling the views using bindings. Four bindings per view to be precise. The bindings bind the views to controller objects, which are connected to my model objects. The bindings are used to change the model objects' values according to their size and their position on the plane and vice versa. If I the app has to manage only a small number of items everything works fine. But when there are very many items (views) to create, the app slows down considerably and is basically unuseable. I assumed that I somehow wrote very unefficient code in my views or something like that and I used the Time Profiler to see what actually is the most time consuming operation. It appears that the method consuming 90% of the time is: -[NSObject(NSKeyValueBindingCreation) bind:toObject:withKeyPath:options:] . Now, I'm obviously missing something here. What I want is to have lots of small rectangular items on a plane. Hundreds, or even thousands of them. I want to be able to drag them around, change their size and have those properties change values in my model. It seems very unlikely to me that creating bindings for those views is actually that time consuming by itself. Or is it? Any help is much appreciated! Thank you!! ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: faster deep copies?
On 14 Feb 2013, at 02:07, James Maxwell jbmaxw...@rubato-music.com wrote: I've run into a situation where I really need a deep copy of an object. I've implemented this using Apple's recommended approach with NSKeyedArchiver/Unarchiver, and it's nice, simple, and functional. But it's also pretty darn slow -- as in a clear, subjectively apparent performance hit. Has anybody had to find a way around this, and if so, what did you do? Or if anybody just has a nice, creative thought about another way of doing it, I'd love to hear about it. The object(s) being copied are custom classes, and there's a chance I may be able to get away with copying only certain properties (i.e., rather than archiving the entire graph from the root object), so I'll look into making a deepCopy method that's more selective. But I'd appreciate any thoughts in the meantime. One possible approach to this (though not one that's going to be as fast as a custom deepCopy method), would be to implement your own NSCoder subclass. I have in the past made keyed archivers which are substantially quicker than apple's, and encode into substantially smaller byte formats. Thanks Tom Davie ___ 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 avoid warning?
On 21 Jan 2013, at 18:14, Dave d...@looktowindward.com wrote: Hi All, I have the following code: if (class_RespondsToSelector(myClass,@selector(initWithManager:) == NO) myObj = [[myClass alloc] init]; else myObj = [[myClass alloc] initWithManager:sel]]; I get a warning on the initWithManager: statement (Obviously), how to avoid the warning or otherwise fix it? Simple, Write better code where you know the types you're dealing with ;). Bob ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 05:58, Tamas Nagy tamas.lov.n...@gmail.com wrote: It's a live video app, where rendering happening on a CVDisplayLink thread, so the app still running and do its job while an OpenPanel (or SavePanel) displaying. I just need to block the UI to make sure the users can't interact the app while an open panel displaying. But why? What's the issue with the user pausing a video while an open panel happens to be open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 09:26, Tamas Nagy tamas.lov.n...@gmail.com wrote: I really appreciate your continuous curiosity guys, but we just getting off-topic :) BTW, its a realtime graphics application, where UI events should not blocking rendering. Think about a concert where some videos projected behind the band, it would be bad if opening the next video - putting it into some kind of queue - blocks the rendering/displaying the current video. You're right, it would be bad… Surely that's a good reason why it would be bad that the user of such an app couldn't go oh crap, I forgot to start that fade, and start it, with the open panel for the next video open? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 09:42, Tamas Nagy tamas.lov.n...@gmail.com wrote: The user is still able to control things like fading with a MIDI/OSC controller - they definitely do not do that with mouse. But there are things which only controllable with the UI, deleting layers for example. And there are some circumstances - for example, loading a whole project, where the app's state just reseted before displaying the open panel, and the loading process presume everything is clear when iterating thru the load data, so it could would be bad if the app's clear state can change when an open panel is opened. Wouldn't the correct thing in this state be to create a new project window associated with the project document, and then fire of an open sheet for that window so that it's only modal for the window? Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 10:11, Tamas Nagy tamas.lov.n...@gmail.com wrote: There is a chance in the application where only one, borderless window displayed on the secondary screen, so there are possible circumstances where displaying a window-modal panel not quite useful. Okay, but your example of when modality was required involved a project being in an inconsistent state, and requiring information from the open dialog before it was complete… In this scenario the open dialog can be attached to the inconsistent project's window. Or are you trying to assert that you can have the app sat there, doing nothing, with no significant windows open, yet in an inconsistent state, and requiring modal interaction to sort it out? If that's your assertion, then I'd suggest you have a deeper seated design bug. Thanks Tom Davie ___ 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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 10:45, Tamas Nagy tamas.lov.n...@gmail.com wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The panel
displays, but no files going to be displayed - the circle just spinning on
the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
NSInteger returnCode = [oPanel runModal];
if (returnCode == NSOKButton) {
NSLog(@OK!);
} else {
NSLog(@Cancel!);
}
});
I can't see off the top of my head what's going wrong here, but I just thought
I'd comment that that looks like a pretty bizarre way of creating a constant
array.
1) You know exactly how big the array's going to be – 1 object, so why hint
that it's going to contain 0 objects?
2) Why use insertObject: atIndex:0 rather than addObject:
3) Why use a mutable array at all? You could just use a constant array –
NSArray *filetype = [NSArray arrayWithObject:@txt];
4) The above can then be further condensed with the new syntactic sugar for
arrays: NSArray *filetype = @[ @txt ];
Thanks
Tom Davie
___
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: NSOpenPanel runModal on a dispatch
Performing asynchronously and blocking the main *queue* are not related things. The main queue is a serial queue, it only executes one block at a time. At the moment, it's executing your block, stuck in your runModal call. That runModal call will not come off the stack, and the block finish executing until the open dialog is closed. If the openDialog methods dispatch to the main queue, their dispatches will not occur until the main queue is able to run another block, which won't happen until your block finishes. You are very much blocking the main queue. Thanks Tom Davie On 16 Dec 2012, at 20:04, Tamas Nagy tamas.lov.n...@gmail.com wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. On Dec 16, 2012, at 8:39 PM, Kyle Sluder k...@ksluder.com wrote: On Sun, Dec 16, 2012, at 11:28 AM, Kyle Sluder wrote: My guess is that NSOpenPanel is doing some work on a background thread, and that work is trying to use the main queue to inform the open panel of its completion. By using the dispatch_async approach, the main queue is blocked, and the background thread can't inform the open panel. The -performSelector::: approach uses a timer, so the nested invocation of the runloop that -runModal performs is still able to dequeue the background task completion's block off the main queue. To follow up: In general, it's just a bad idea to block the main queue. It so happens that currently CFRunLoop is responsible for draining the main queue in a runloop-based app, so your app is able to hobble along firing timers and doing delayed-performs. But one can envision that dependency being inverted in a future release of OS X such that it's the main queue that's responsible for driving the runloop. At that point, blocking the main queue would cause deadlock when you tried to reentrantly run the runloop. In 10.6, NSOpenPanel and NSSavePanel gained a -beginWtihCompletionHandler: method that lets you run the panel as a non-modal window. Consider using that instead of -runModal. --Kyle Sluder ___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 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?
Not really, as your block may be released (by the setter) between getting the
block and invoking it.
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.
Your comments are welcome!
Grand Central Dispatch is your friend.
@implementation MyClass
static dispatch_once_t onceToken;
static dispatch_queue_t dispatchQueue;
typedef (void(^ProgressHandler)(RXProgressState progressState, NSInteger
totalBytesWritten, NSInteger totalBytesExpectedToWrite);
- (void)setProgressHandler:(ProgressHandler)progressHandler
{
dispatch_once(onceToken, ^
{
dispatchQueue = dispatch_queue_create(RXProgressQueue,
DISPATCH_QUEUE_SERIAL);
});
dispatch_sync(dispatchQueue, ^()
{
if (_progressHandler != progressHandler)
{
[_progressHandler release];
_progressHandler = [progressHandler copy];
}
});
}
- (void)progressHandler
{
return _progressHandler;
}
- (void)callSite
{
…
dispatch_once(onceToken, ^
{
dispatchQueue = dispatch_queue_create(RXProgressQueue,
DISPATCH_QUEUE_SERIAL);
});
dispatch_sync(dispatchQueue, ^()
{
ProgressHandler handler = [self progressHandler];
handler(…);
});
…
}
Tom Davie
___
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
NSSearchField selecting after sending its action
I'm having an issue with NSSearchField selecting its contents when it sends its action. This is pretty bloody annoying, as it means that if a user pauses while entering some text in the field, he starts overwriting the contents (because the action is sent in between, and the contents selected). Does anyone know what weird property I've ended up accidentally selecting (or not selecting) here? Thanks Tom Davie ___ 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 implement readonly property
On 12 Nov 2012, at 12:56, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
I have a property:
@property (readonly) NSDictionary *someDictionary;
This property should be computed on demand, and should be accessible by
several threads.
My current implementation is:
- (NSDictionary *)someDictionary;
{
static NSDictionary *someDictionary;
static dispatch_once_t justOnce;
dispatch_once( justOnce, ^
{
// create a temp dictionary (might take some time)
someDictionary = temp;
}
);
return someDictionary;
}
The first thread which needs someDictionary will trigger its creation. Ok.
But what happens when another thread wants to access someDictionary while it
is still being created? I guess it will receive just nil.
This would be not correct; it really should wait until the dictionary is
ready.
How to achieve this? Use a lock? Use @synchronize?
This is completely the wrong way to implement a property. The static variable
will be shared between all instances. Here's how you should be doing a lazy
loaded var:
@implementation MyClass
{
NSDictionary *_someDictionary
}
- (NSDictionary *)someDictionary
{
static dispatch_once_t justOnce;
dispatch_once(justOnce, ^
{
someDictionary = [[NSDictionary alloc] initWithObjectsAndKeys: ……
nil];
});
return someDictionary;
}
In answer to your threading question. If multiple threads ask for the
dictionary at once, the second one to hit the dispatch_once will block until
the first one has finished the dispatch_once block, and then continue to
execute (without touching the contents). Thus, both threads will receive the
same dictionary (assuming it's the same instance it's called on), and it will
be allocated only once.
Tom Davie
___
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 implement readonly property
On 12 Nov 2012, at 13:39, Marco Tabini mtab...@me.com wrote:
This is completely the wrong way to implement a property. The static
variable will be shared between all instances. Here's how you should be
doing a lazy loaded var:
@implementation MyClass
{
NSDictionary *_someDictionary
}
- (NSDictionary *)someDictionary
{
static dispatch_once_t justOnce;
dispatch_once(justOnce, ^
{
someDictionary = [[NSDictionary alloc] initWithObjectsAndKeys: ……
nil];
});
return someDictionary;
}
I don't think this does what you think it does; my understanding is that
dispatch_once will execute only once for the lifetime of an app, so the code
you posted will only run once for the first object that requires is, and then
never run again, resulting in _dictionary being Nil in all other instances.
Very good point! My bad.
I understood the OP's request as wanting to implement a singleton, which,
based on your reading, may not be the case. dispatch_once will be fine for a
singleton, but if you need a thread-safe, lazily-instantiated read-only
property, maybe something like this will do the trick:
I'm pretty sure he doesn't want a singleton, as he was talking about a
property. And yeh, sorry about the misinformation there!
@implementation MyClass {
NSDictionary *_someDictionary
}
- (NSDictionary *) someDictionary {
@synchronized(self) {
if (!_someDictionary) {
_someDictionary = [[NSDictionary alloc] initWith… ]
}
}
return _someDictionary;
}
___
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 implement readonly property
On 12 Nov 2012, at 14:18, Joerg Simon j_si...@mac.com wrote: You can use dispatch_sync. The blog post of oliver dobnigg (cocoanetics) summs that up quite nicely: http://www.cocoanetics.com/2012/02/threadsafe-lazy-property-initialization/ Or you can use dispatch_once, but make sure the once token is an ivar, unlike I did. Tom Davie ___ 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: Is ARC any smarter than Xcode's 'Analyze'?
On 12 Nov 2012, at 17:19, Jerry Krinock je...@ieee.org wrote: I'm debugging a crash in a large project which evidence indicates is caused by a retain/release imbalance. The project is written with manual retain/release, not ARC. The project is built in Xcode 4.5.2, and when I 'Analyze', I get no warnings pertaining to memory management. So the problem must be some edge case which is not caught by 'Analyze'. Further, I think that ARC is built upon 'Analyze', and therefore if I converted this project to ARC, it would still crash. Am I correct? Yes, ARC is significantly smarter than analyse. ARC is guaranteed to get memory management right (modulo retain cycles and weak refs that shouldn't be weak). Meanwhile the analyser is trying to understand what *you* did to try and make memory management right, which is a much much harder task. Tom Davie ___ 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: a way to clear inactive RAM
On 6 Nov 2012, at 11:01, Nick Rogers roger...@mac.com wrote: Hi, Thanks for the replies. I was trying to achieve what essentially free memory apps on the Mac AppStore do. The RAM usage can be divided into four parts as shown in Activity Monitor. 1. Free 2. In-active 3. Active 4. Wired When I used my earlier app to allocate memory equal to free + inactive bytes, for the execution of the program it used to make the system less responsive for a few seconds and on release and quitting the app, most of the inactive memory would shift under free. e.g. if free is 1GB and inactive is 1.5GB, then after run, free would be 2.45GB and inactive just 50MB. Why on earth would you want to release inactive memory? This is memory that is in use by applications, just ones that haven't been scheduled in for a while. This RAM IIRC is automatically paged out to disk, so that if it is needed it can simply be overwritten, just like free memory, but has the side benefit that if it's not overwritten, then the inactive applications can be brought back to life very fast. Freeing it all would not gain anything, but would cause inactive apps to take much longer to return to the foreground. As an aside - free memory is a bad thing – having free memory means your system is not using all the RAM it has available to make things nice and fast. I fully expect my machine to use free memory for things like disk caches if I currently do not need the RAM for applications. Tom Davie ___ 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: Cocoa equivalent for 'InstallApplicationEventHandler'
You want NSEvent's
+ (id)addGlobalMonitorForEventsMatchingMask:(NSEventMask)*mask* handler:(void
(^)(NSEvent*))*block*
*and*
*
+ (id)addLocalMonitorForEventsMatchingMask:(NSEventMask)mask handler:(NSEvent*
(^)(NSEvent*))block
Bob
*
On Sat, Feb 20, 2010 at 11:45 AM, Vikram Sethi vik@gmail.com wrote:
Hi,
I am rewriting the event handling mechanism of my app in Cocoa. It is in
Carbon as of now. Is there a Cocoa equivant for
InstallApplicationEventHandler(), so that I can listen to event at the
application level? As I understand, as per the NSResponder chain hierarchy,
I can get the events on the NSWindow. However, I would want to do some
special processing in my app in the no-window state as well. Some events
like application activation/deactivation are dispatched to the application
delegate. However, events like keyDown are not handled by the NSApplication
class or its delegate.
In the absence of a true Cocoa equivalent for application or system level
events, one of the ways that comes to mind is to override the sendEvent
method of the NSApplication class and prior to calling sendEvent on
super,
do some preprocessing, and then decide whether to propagate that further.
The sendEvent method would look like this.
- (void)sendEvent:(NSEvent *)anEvent
{
bool propagate = [self preProcessEvent:anEvent];
if(propagate)
[super sendEvent:anEvent];
[self postProcessEvent:anEvent];
}
Do you think this approach is okay? What do I stand to loose with this
approach? Do you foresee any problems? Is there a better way to do this?
Any pointers and/or suggestions would be helpful and would be appreciated.
Thanks,
Vikram
P.S. I am not sure if this has been asked earlier. I could not find it.
Pardon me if this is a repeat question.
___
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/tom.davie%40gmail.com
This email sent to tom.da...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Open panel is permanently dead?
Hi,
I'm having some problems with an open panel. I display the panel, allow the
user to chose and image, and then do some work, which involves showing a
sheet while the work is done. This all works wonderfully, until the user
clicks the set texture button again, and my method is called again. The
second time, for some reason, the open panel is never displayed.
Can anyone tell what's going on here? I've added code below:
- (IBAction)setTexture:(id)sender{
NSOpenPanel
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html
*panel = [NSOpenPanel
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html
openPanel];
[panel setCanChooseFiles:YES];
[panel setCanChooseDirectories:NO];
[panel setResolvesAliases:YES];
[panel setAllowsMultipleSelection:NO];
[panel setTitle:@Select Texture];
[panel setAllowedFileTypes:[NSArray
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSArray.html
arrayWithObject:@png]];
[panel beginSheetModalForWindow:[delegate windowForSheet]
completionHandler:^(NSInteger result)
{
if (result == NSFileHandlingPanelOKButton)
{
NSURL
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSURL.html
*selection = [[panel URLs] objectAtIndex:0];
NSImage
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSImage.html
*image = [[[NSImage
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSImage.html
alloc] initWithContentsOfURL:selection] autorelease];
[self.item addObserver:self
forKeyPath:@textureIsCompressed
options:NSKeyValueObservingOptionNew context:nil];
self.item.texture = image;
[panel close];
[NSApp beginSheet:compressingTexturePanel
modalForWindow:[delegate windowForSheet]
modalDelegate:self
didEndSelector:@selector(compressionSheetDidEnd:)
contextInfo:nil];
[compressingProgress startAnimation:self];
}
}];}
Thanks
Tom Davie
___
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
Overriding NSMenuItem's drawing
I need an NSMenuItem that rather than drawing an NSImage in it's cell draws *part* of an NSImage, is it possible to override NSMenuItem's drawing in any way to achieve this? I don't see the relevant methods. Thanks Tom Davie ___ 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
Bizarre locking issue
Hi,
I have a project, based on the non-document-based core data application
template. I've added a small amount of UI, and a tiny bit of code to fill
an NSOutlineView with one item. Since doing so though, I'm getting a bit of
an odd error. When my outline view's data is first loaded, I get the error
-[NSRecursiveLock unlock]: lock (NSRecursiveLock: 0x200032720
'(null)') unlocked when not locked*
Break on _NSLockError() to debug.*
*on the console. Commenting out a line that (on it's first attempt) loads
an object out of CoreData gets the log to go away, and it doesn't appear to
be producing any adverse affects other than the log message, but I'd like to
understand what's going on here.*
*
*
Here's the code that seems to be causing the problem:
In the app delegate:
- (Library *)library
{
if (nil == library)
{
NSError *error = nil;
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSManagedObjectContext *moc = [self managedObjectContext];
[fetchRequest setEntity:[NSEntityDescription entityForName:@Library
inManagedObjectContext:moc]];
NSArray *libraries = [moc executeFetchRequest:fetchRequest error:error];
if (nil == libraries || [libraries count] 1)
{
library = [[Library alloc] initWithEntity:[[[self managedObjectModel]
entitiesByName] objectForKey:@Library] insertIntoManagedObjectContext
:moc];
if (![moc save:error])
{
[NSApp presentError:error];
}
}
else
{
library = [libraries objectAtIndex:0];
}
}
return library;
}
In my view controller:
- (BOOL)outlineView:(NSOutlineView *)outlineView isItemExpandable:(id)item
{
return NO;
}
- (NSInteger)outlineView:(NSOutlineView *)outlineView
numberOfChildrenOfItem:(id)item
{
if (nil == item)
{
return 1;
}
else
{
return 0;
}
}
- (id)outlineView:(NSOutlineView *)outlineView child:(NSInteger)index
ofItem:(id)item
{
if (nil == item)
{
return self.library;
}
else
{
return nil;
}
}
- (id)outlineView:(NSOutlineView *)outlineView objectValueForTableColumn:(
NSTableColumn *)tableColumn byItem:(id)item
{
return @Library;
// if (item == self.library)
// {
// return @Library;
// }
}
Note that commenting out both lines that requests self.library cause the
error to go away.
Any help would be much appreciated.
Thanks
Tom Davie
p.s. Here's a stack trace when the lock error is logged (breaking on
_NSLockError doesn't work)
#0 0x7fff87e0528f in NSLog
#1 0x7fff87d96fee in -[NSRecursiveLock unlock]
#2 0x7fff883473c1 in -[NSOutlineView
_rowEntryForRow:requiredRowEntryLoadMask:]
#3 0x7fff88347664 in -[NSOutlineView _frameOfOutlineCellAtRow:]
#4 0x7fff8834759c in -[NSOutlineView frameOfOutlineCellAtRow:]
#5 0x7fff88347abd in -[NSOutlineView _adjustDrawingTestFrame:atRow:column:]
#6 0x7fff88346bc1 in -[NSTableView drawRow:clipRect:]
#7 0x7fff883465cb in -[NSTableView drawRowIndexes:clipRect:]
#8 0x7fff8834644c in -[NSOutlineView drawRowIndexes:clipRect:]
#9 0x7fff88344f78 in -[NSTableView drawRect:]
#10 0x7fff8833afae in -[NSView _drawRect:clip:]
#11 0x7fff88339c21 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#12 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#13 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#14 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#15 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#16 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#17 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#18 0x7fff88339f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#19 0x7fff883382f3 in -[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#20 0x7fff88337e17 in -[NSThemeFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#21 0x7fff883346bf in -[NSView
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
#22 0x7fff882adf37 in -[NSView displayIfNeeded]
#23 0x7fff88275f87 in -[NSWindow
_reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]
#24 0x7fff88275b1c in -[NSWindow orderWindow:relativeTo:]
#25 0x7fff88241a2c in -[NSIBObjectData
nibInstantiateWithOwner:topLevelObjects:]
#26 0x7fff8823fb49 in loadNib
#27 0x7fff8823f059 in +[NSBundle(NSNibLoading)
_loadNibFile:nameTable:withZone:ownerBundle:]
#28 0x7fff8823ee91 in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#29 0x7fff8823c413 in NSApplicationMain
#30 0x10fb5 in main at main.m:13
___
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: UIImageView display as multiply?
An image doesn't carry a blend mode, merely the image data. You *draw* the
image in a given blend mode.
Bob
On Fri, Jan 22, 2010 at 3:52 PM, Eric E. Dolecki edole...@gmail.com wrote:
I'm not combining two or more images, I merely would like a single uiimage
in a uiimageview to have a blend mode applied to it that works so that no
matter what is beneath it, there will be a blend mode applied.
Is this not possible?
On Fri, Jan 22, 2010 at 10:43 AM, Bertil Holmberg
bertilholmb...@telia.comwrote:
Here is a snippet that I saved for another day, perhaps it will get you
going?
Regards,
Bertil
- (UIImage *)blendOverlay:(UIImage *)topImage withBaseImage:(UIImage
*)baseImage toSize:(CGFloat)imageSize
{
UIGraphicsBeginImageContext(CGSizeMake(imageSize, imageSize));
[baseImage drawInRect:CGRectMake(0.0, 0.0, imageSize, imageSize)];
[topImage drawInRect:CGRectMake(0.0, 0.0, imageSize, imageSize)
blendMode:kCGBlendModeNormal alpha:0.5];
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return image;
}
Okay, how would I go about doing that?
On Fri, Jan 22, 2010 at 9:52 AM, Luke the Hiesterman
luket...@apple.com
wrote:
You should perform whatever blending you need to do on the image
itself
to
create a new image which you can then just put into a UIImageView like
you
would any other image. This way, you only have to blend once, and then
it's
just image that can be straight drawn rather than performing a
blending
algorithm every time your image has to draw.
___
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/edolecki%40gmail.com
This email sent to edole...@gmail.com
--
http://ericd.net
Interactive design and development
___
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/tom.davie%40gmail.com
This email sent to tom.da...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: [iphone] Release Navigation View Controller Question
Yes, that code is 100% fine. Here's the logic from purely your point of view. You allocate browserviewController and in doing so take ownership. You do some stuff with browserviewController. You are finished with browserviewController, and don't want to do anything else with it, so you resign ownership. From a more global perspective, the navigationController becomes interested in browserviewController when you ask it to push it, and it too takes ownership, so when *you* release, the navigationController still has a handle on the controller, and keeps hold of it until it decides it's done with it. Bob On Sun, Jan 17, 2010 at 10:30 AM, Philip Vallone philip.vall...@verizon.net wrote: Hi, I have Navigation based application. When I switch from one view to the next I use the following code. In the below code, is it ok to release browseviewController? BrowseViewController *browseviewController = [[BrowseViewController alloc] initWithNibName:@BrowseViewController bundle:nil]; [browseviewController setTitle:@Browse By Title]; [self.navigationController pushViewController:browseviewController animated:YES]; // ok to release? [browseviewController release]; Thanks, Phil___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Encrypting Binary Strings
Simple answer: no. If your application can still read the strings, so can a clever person, if by nothing else than sitting and patiently emulating a CPU with a piece of paper and a pencil. In order to actually secure something *you, or your recipient* have to be involved in decrypting it, by knowing something secret (the key). Bob On Wed, Dec 30, 2009 at 5:17 PM, Mr. Gecko grmrge...@gmail.com wrote: Is it possible for me to encrypt the strings in my binary so hackers can't easily figure out what my application has in it? Reason I'm asking is I have some private keys that encodes data that I/parents don't want kids or teenagers to find. Thanks, Mr. Gecko___ 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/tom.davie%40gmail.com This email sent to tom.da...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Removing the dragging image
I have a view that when dragged over displays a preview of where the dragged item is going to end up. The problem is, the dragging image gets drawn on top of this. Is it possible for the dragging destination to request that the dragging image is not drawn while something is dragged over the top of it? Thanks Tom Davie ___ 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
Scanning
I'm trying desperately to find where the API for scanning images is, I've found the Image Capture API on developer.apple.com, but I can't find a more recent version than one for 10.4, and none of the sample code compiles any more, worse the sample apps crash on launch. What should I be searching the docs for here? Thanks Bob ___ 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
Changing the edit behaviour of a cell
I've been busy reading the documentation all day, and can't for the life of me figure out how to change the editing behavior of an NSCell. I have a cell, which I'd like to pop up a window over when the user attempts to edit it (much like many websites do to present a date picker for example). I have tried overriding ** * - (void)editWithFrame:(NSRect)aRect inView:(NSView *)controlView editor:(NSText *)textObj delegate:(id)anObject event:(NSEvent *)theEvent - (void)selectWithFrame:(NSRect)aRect inView:(NSView *)controlView editor:(NSText *)textObj delegate:(id)anObject start:(NSInteger)selStart length:(NSInteger)selLength and - (void)endEditing:(NSText *)textObj with only limited success. selectWithFrame... appears to give me a slightly bogus rectangle (about 50 pixels off to the upper left, after running it through [controlView convertPointToBase:aRect.origin]), while editWithFrame... and endEditing... never seem to be called. What is the correct way to set up such behaviour? Thanks Bob * ___ 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
