from:"Tom"


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

2013-09-03 Thread Tom Davie

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

2013-08-28 Thread Tom Davie

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?

2013-08-28 Thread Tom Davie


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

2013-08-20 Thread Tom Davie

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

2013-08-20 Thread Tom Davie

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?

2013-08-20 Thread Tom Davie


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

2013-08-18 Thread Tom Davie


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

2013-08-18 Thread Tom Davie

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

2013-08-18 Thread Tom Davie


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: Stale URL bookmarks?

2013-08-14 Thread Tom Harrington

On Tue, Aug 13, 2013 at 10:08 PM, Quincey Morris 
quinceymor...@rivergatesoftware.com wrote:

 On Aug 13, 2013, at 19:20 , Tom Harrington atomicb...@gmail.com wrote:

 What does stale mean in this context? And if the bookmark is stale, what
 if anything should I do (or not do) in response to that?


 Stale means that the referenced file could not be found using the
 explicit information in the bookmark (such as the parent directory and file
 name), but a plausible alternative *could* be found by assuming information
 that's either not in the bookmark or that contradicts what's in the
 bookmark.

 For example, if the file was renamed, and the bookmark has recorded the
 file system node number, the original file could be be found via the file
 number. However, it now has a conflicting name, even though bookmark
 resolution has decided it's the same file.

 Now imagine, for example, that the file is accidentally deleted and then
 restored from a backup, under the newest name. It will likely have a
 different file number and the original bookmark will now be unresolvable.

 When you're told that a bookmark is stale, you're being warned that file
 metadata has changed, and that further metadata changes may break the
 bookmark. That gives you the opportunity to re-create the bookmark using
 the latest metadata, rendering the bookmark more tolerant to future
 metadata changes.

 You can choose to re-create the bookmark or not. The upside to doing so is
 that your bookmark may more robustly follow a series of file metadata
 changes. OTOH you may not want to have your bookmark cling to files that
 are moved or renamed.


Thanks for the detailed explanation, just what I needed.

-- 
Tom Harrington
atomicb...@gmail.com
AIM: atomicbird1
___

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

Document scope security bookmark, catch 22?

2013-08-14 Thread Tom Harrington

I'm trying to create document scoped security URL bookmarks, for a document
format that needs to refer to other documents. But it seems like the first
time I save a document, there's a catch-22 in creating the bookmarks.

Creating a document scoped bookmark requires my document's URL as one of
the arguments.

If I implement dataOfType:error:, I can't create a document-scope bookmark
in my NSDocument subclass because [self fileURL] is nil. I end up creating
an app-scoped bookmark instead, though it's not what I want.

If I implement writeToURL:ofType:error:, I get a URL for my document as the
first argument. But, I still can't create the bookmark because my document
doesn't exist yet. I get an error reading 'The file “[name]” couldn’t be
opened because there is no such file'.

So, when am I supposed to create these bookmarks? Do I need to have the
user save an empty document first just so I can create these bookmarks the
next time around?

-- 
Tom Harrington
atomicb...@gmail.com
AIM: atomicbird1
___

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

Stale URL bookmarks?

2013-08-13 Thread Tom Harrington

When resolving a URL bookmark, one of the options is a BOOL * that on
return tells you if the bookmark data is stale.

What does stale mean in this context? And if the bookmark is stale, what
if anything should I do (or not do) in response to that?

-- 
Tom Harrington
atomicb...@gmail.com
AIM: atomicbird1
___

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

2013-08-10 Thread Tom Davie

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

2013-08-10 Thread Tom Davie


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

2013-08-07 Thread Tom Davie


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

2013-08-07 Thread Tom Davie


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

2013-08-07 Thread Tom Davie


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

2013-07-27 Thread Tom Davie

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

2013-07-18 Thread Tom Davie

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

2013-07-11 Thread Tom Davie


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

2013-06-13 Thread Tom Davie

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

2013-06-13 Thread Tom Davie


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: Wanted: new owner for Mac apps

2013-05-07 Thread Tom von Schwerdtner

On Tue, May 7, 2013 at 9:54 AM, Steven Degutis sbdegu...@gmail.com wrote:

 These ones: https://github.com/sdegutis/grs

 (...)

 For the curious, I'm giving them away because


I think something got cut off here...?

-Tom
___

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: ANN: new open-source window manager for OS X

2013-04-19 Thread Tom von Schwerdtner

Looks interesting.

Any comment on how this relates to Slate (https://github.com/jigish/slate)?
 It seems to be roughly along the same lines (which would be fine, just
asking).

-Tom


On Wed, Apr 17, 2013 at 12:44 PM, Steven Degutis sbdegu...@gmail.comwrote:

 Called Windows.app. Source is on github:
 https://github.com/sdegutis/windowsapp

 What's particularly neat about it is how you configure it. It looks for a
 dotfile in your home dir, which can either be JavaScript or CoffeeScript.
 In this config file you, bind your hot keys as you want, using a very
 simple API that the app exposes in JS-land.

 I managed to get JavaScript scripting working via JSCocoa, and CoffeeScript
 via coffeescript.js and Coffeescript.compile(). Technically I hide the ObjJ
 syntax away, since most people are much more comfortable in pure JS than in
 ObjJ. I was looking into adding ClojureScript support, but I'm not yet sure
 how to avoid the start-up delay when running java. Waiting 5 seconds each
 time you reload your config isn't ideal.

 My first choice for scripting was to use MacRuby, but it only works with GC
 apps, and this one uses ARC. I hear they've got ARC in the works, so my
 fingers are crossed for the future. Also, PyObjC is really hard to
 integrate into an app. Ironically enough, when I was googling for how to do
 it, I found an article I wrote about it 3 years ago when I was working at
 BNR.

 Also, I created a technique for generating appcasts statically from the
 command line, and hosting the appcast on github, that might be interesting
 to other open source authors who don't want to have any other hosting but
 github. The details are in this build.sh file:
 https://github.com/sdegutis/windowsapp/blob/master/build.sh

 My apologies if new-app announcements are off-topic, but I think this one
 is particularly suitable for cocoa-dev because of the technical details.

 -Steven
 ___

 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com

 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/tomvons%40gmail.com

 This email sent to tomv...@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: Followup - Re: Is there a pattern for creating an object with global scope?

2013-04-15 Thread Tom Davie


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?

2013-04-13 Thread Tom Davie


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

2013-04-05 Thread Tom Davie


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

2013-04-05 Thread Tom Davie

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

2013-04-05 Thread Tom Davie


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

2013-02-17 Thread Tom Davie

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?

2013-02-14 Thread Tom Davie


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?

2013-01-21 Thread Tom Davie

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

2012-12-16 Thread Tom Davie


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

2012-12-16 Thread Tom Davie

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: NSFileManager - Incompatible persistent store

2012-11-25 Thread Tom Miller

Hey Sean,

Thank you! Though this didn't quite work. I'm getting an error response in
the code telling me No visible @interface for 'NSFileManger' declares the
selector 'createDirectoryAtURL:attributes'. Included in this message is the
code im playing with,
https://dl.dropbox.com/u/3783094/BlogDemoAppDelegate.m
https://dl.dropbox.com/u/3783094/BlogDemoAppDelegate.m

On Thu, Nov 22, 2012 at 10:58 AM, Sean McBride s...@rogue-research.comwrote:

On Wed, 21 Nov 2012 18:17:26 -0500, Tom Miller said:

Sorry my bad! The warning states 'createDirectoryAtPath:attributes:' is
depreciated. I was able to get rid of that window warning once the app
launched, miss spelled something in my code. Though I'm still unable to
save the imputed text to the XML. I can provide the entire set of code if
needed to.

Tom,

Most path-based and non-NSError-returning file APIs are deprecated, and
you should use URL+NSError methods instead:

createDirectoryAtURL:withIntermediateDirectories:attributes:error:

Also, using fileExistsAtPath: is rarely the right thing due to race
conditions: it's possible the file didn't exist when you checked, then gets
created by a different process before you get to create it. Instead, just
try to create it, and be ready for a returned error like 'already exists'.
See:

https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide/Articles/RaceConditions.html

Cheers,

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada

--
-
Tom Miller
t...@pxlc.me
pxlc.me
___

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

2012-11-21 Thread Tom Davie


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

NSFileManager - Incompatible persistent store

2012-11-21 Thread Tom Miller

I'm working with some code that accesses a data model in Xcode. String data
is written to an xml file in the app (Mac) and displayed in a list.
The inputted text is saved as body text and title. The app compiles but I
receive a warning upon launch,



*The managed object model version used to open the persistent store is
incompatible with the one that is used to create the persistent store.*



The app launches and I'm able to save (kinda) the inputted text, add title,
and view from a list of created titles/body text. The only problem is
the inputted text is not saved and reopened once the app launches again.
I'm assuming this has to be because of the persistent store.



I receive a warning in Xcode about this line of code dealing with the file
manager,



 fileManager = [NSFileManager defaultManager];
 applicationSupportFolder = [self applicationSupportFolder];
 if ( ![fileManager fileExistsAtPath:applicationSupportFolder
isDirectory:NULL] ) {
 [fileManager createDirectoryAtPath:applicationSupportFolder
attributes:nil];
 }

-- 
-
Tom Miller
t...@pxlc.me
pxlc.me
___

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: NSFileManager - Incompatible persistent store

2012-11-21 Thread Tom Miller

On Wednesday, November 21, 2012, Tom Miller wrote:

 Sorry my bad! The warning states 'createDirectoryAtPath:attributes:' is
 depreciated. I was able to get rid of that window warning once the app
 launched, miss spelled something in my code. Though I'm still unable to
 save the imputed text to the XML. I can provide the entire set of code if
 needed to.

 On Wednesday, November 21, 2012, Mike Abdullah wrote:


 On 21 Nov 2012, at 21:16, Tom Miller t...@pxlc.me wrote:

  I receive a warning in Xcode about this line of code dealing with the
 file
  manager,
 
 
 
  fileManager = [NSFileManager defaultManager];
  applicationSupportFolder = [self applicationSupportFolder];
  if ( ![fileManager fileExistsAtPath:applicationSupportFolder
  isDirectory:NULL] ) {
  [fileManager createDirectoryAtPath:applicationSupportFolder
  attributes:nil];
  }

 Care to tell us what the warning actually is?



 --
 -
 Tom Miller
 t...@pxlc.me javascript:_e({}, 'cvml', 't...@pxlc.me');
 pxlc.me



-- 
-
Tom Miller
t...@pxlc.me
pxlc.me
___

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: NSFileManager - Incompatible persistent store

2012-11-21 Thread Tom Miller

Sorry my bad! The warning states 'createDirectoryAtPath:attributes:' is
depreciated. I was able to get rid of that window warning once the app
launched, miss spelled something in my code. Though I'm still unable to
save the imputed text to the XML. I can provide the entire set of code if
needed to.

On Wednesday, November 21, 2012, Tom Miller wrote:

 Sorry my bad! The warning states 'createDirectoryAtPath:attributes:' is
 depreciated. I was able to get rid of that window warning once the app
 launched, miss spelled something in my code. Though I'm still unable to
 save the imputed text to the XML. I can provide the entire set of code if
 needed to.

 On Wednesday, November 21, 2012, Mike Abdullah wrote:


 On 21 Nov 2012, at 21:16, Tom Miller t...@pxlc.me wrote:

  I receive a warning in Xcode about this line of code dealing with the
 file
  manager,
 
 
 
  fileManager = [NSFileManager defaultManager];
  applicationSupportFolder = [self applicationSupportFolder];
  if ( ![fileManager fileExistsAtPath:applicationSupportFolder
  isDirectory:NULL] ) {
  [fileManager createDirectoryAtPath:applicationSupportFolder
  attributes:nil];
  }

 Care to tell us what the warning actually is?



 --
 -
 Tom Miller
 t...@pxlc.me javascript:_e({}, 'cvml', 't...@pxlc.me');
 pxlc.me



-- 
-
Tom Miller
t...@pxlc.me
pxlc.me
___

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

2012-11-17 Thread Tom Davie

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'?