date:20110414

I haven't managed to work out how to get the behaviour I want from my 
interface, and I'm hoping somebody can help me out. It may be that I am 
misusing my interface elements, but any suggestions would be welcome.

What I believe I want is for the appropriate setXXX method to be called when I 
press return for a text field, even if its contents have NOT changed. i.e. I 
type in 10 and press return and setXXX is called, but if I then press return 
again, setXXX is called a second time (or at least I have some way of knowing 
that return was pressed a second time).

The rationale behind why I want to do this is as follows:

I am controlling a stepper motor, and the user can direct command the position 
it should move to using the following interface:
www.dur.ac.uk/j.m.taylor/commanded_and_current_value.png
In that screenshot I have just commanded a move to z=2000um and it is in motion 
to that target, currently at 755.43um.

However, as well as this direct command of the position, there are various 
actions the user can take that will trigger the motor to move, potentially on a 
relatively complex trajectory. My design choice, which I think makes sense, is 
for the current value readout to update during that trajectory, but for the 
commanded value to remain unchanged. [At the end of the trajectory the 
commanded value changes to reflect the final resting point of the motor]. 
Otherwise the commanded value, a user-editable field, may be continuously 
updating without any user intervention, which I don't feel is right.

That's all fine, but I would additionally like the user to be able to interrupt 
the trajectory in progress by issuing a new direct command. From a user's point 
of view, if you click back onto the command text field and press return again 
I think you would expect that this would command the motor to move again to the 
value in that text field. However, because that is the same value as the one 
set last time for the property, setXXX is not called a second time, and my 
code is not aware that the user has done anything.

I think the desired behaviour I am describing here is effectively a sort of 
write only behaviour for the bound property, but writeonly does not appear to 
be a valid specified (and I can see why...). Hopefully what I have described 
here makes sense. Can anybody suggest how I can achieve the sort of thing I am 
after here? I can see various notifications etc that I may be able to hook into 
to do the sort of thing I want, but I am not sure where the best place to hook 
in would be. I wonder if it may be within the binding-related messages 
themselves (something I am not familiar with the internal workings of...)

Thanks for your help
Jonny___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Make text field set value even if apparently unchanged

2011-04-14 Thread Mike Abdullah

Bindings will not do this for you. Instead, hook your controller up to the text 
field's action, which will be sent every time the user hits return.

On 14 Apr 2011, at 13:24, Jonathan Taylor wrote:

 I haven't managed to work out how to get the behaviour I want from my 
 interface, and I'm hoping somebody can help me out. It may be that I am 
 misusing my interface elements, but any suggestions would be welcome.
 
 What I believe I want is for the appropriate setXXX method to be called when 
 I press return for a text field, even if its contents have NOT changed. i.e. 
 I type in 10 and press return and setXXX is called, but if I then press 
 return again, setXXX is called a second time (or at least I have some way of 
 knowing that return was pressed a second time).
 
 The rationale behind why I want to do this is as follows:
 
 I am controlling a stepper motor, and the user can direct command the 
 position it should move to using the following interface:
 www.dur.ac.uk/j.m.taylor/commanded_and_current_value.png
 In that screenshot I have just commanded a move to z=2000um and it is in 
 motion to that target, currently at 755.43um.
 
 However, as well as this direct command of the position, there are various 
 actions the user can take that will trigger the motor to move, potentially on 
 a relatively complex trajectory. My design choice, which I think makes sense, 
 is for the current value readout to update during that trajectory, but for 
 the commanded value to remain unchanged. [At the end of the trajectory the 
 commanded value changes to reflect the final resting point of the motor]. 
 Otherwise the commanded value, a user-editable field, may be continuously 
 updating without any user intervention, which I don't feel is right.
 
 That's all fine, but I would additionally like the user to be able to 
 interrupt the trajectory in progress by issuing a new direct command. From a 
 user's point of view, if you click back onto the command text field and 
 press return again I think you would expect that this would command the motor 
 to move again to the value in that text field. However, because that is the 
 same value as the one set last time for the property, setXXX is not called 
 a second time, and my code is not aware that the user has done anything.
 
 I think the desired behaviour I am describing here is effectively a sort of 
 write only behaviour for the bound property, but writeonly does not appear 
 to be a valid specified (and I can see why...). Hopefully what I have 
 described here makes sense. Can anybody suggest how I can achieve the sort of 
 thing I am after here? I can see various notifications etc that I may be able 
 to hook into to do the sort of thing I want, but I am not sure where the best 
 place to hook in would be. I wonder if it may be within the binding-related 
 messages themselves (something I am not familiar with the internal workings 
 of...)
 
 Thanks for your help
 Jonny___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
 
 This email sent to cocoa...@mikeabdullah.net

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Lockless thread-safe accessor using blocks: how to?

Hi all,

I've started to use GCD in my projects and I found myself using a certain 
pattern that I now realize isn't actually thread safe. The goal is to write a 
thread-safe lazy accessor without using locks, @synchronized, or an atomic 
property. At first I thought that

- (SomeObjType) foo
{
__block SomeObjType foo = nil;

dispatch_sync(queue,
^{
// retrieve bah

if (nil == bah)
{
// compute and store bah
}

foo = bah;
});

return foo;
}

would do it. Here, bah is some resource that may be changed by multiple threads 
and queue is a serial GCD queue defined as a static variable in the class where 
this accessor is defined. The queue is not any of the global queues, but is 
created by the class.

I see two problems with this pattern.

The first is that if the method gets invoked already in the queue's automatic 
thread, there will be a deadlock. That's easy to fix, by wrapping the dispatch 
call into a function that tests queue against the currently executing queue and 
simply executes the block when they coincide.

The second problem is that the pattern isn't actually thread safe. If two 
threads (that aren't the automatic thread of the queue) enter the accessor, two 
blocks will be enqueued serially. The two threads will then block, waiting for 
their blocks to finish executing.

So far so good but when the first block finishes, it could happen that the 
first thread blocks until the second block finishes, at which time the foo 
value computed by the first block will have been replaced by the value computed 
by the second block, since foo is shared among all blocks that captured it.

Thus, when the first thread resumes, it will report the wrong foo value.

So, what is the correct pattern to write a thread-safe lazy accessor without 
using locks, @synchronized, or an atomic property?

Thanks in advance.
WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Make text field set value even if apparently unchanged

On 14 Apr 2011, at 13:45, Mike Abdullah wrote:
 
 Bindings will not do this for you. Instead, hook your controller up to the 
 text field's action, which will be sent every time the user hits return.

Thanks very much, that's working nicely. Requires a few more outlets etc to be 
set up, but I guess that's what I get for wanting something a bit non-standard!
Cheers
Jonny___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

I am afraid I am not completely sure what you mean by your first problem, but 
hopefully my answer to your second one sidesteps your concern there. In answer 
to your second (once I had parsed out the two different uses of the word 
block in what you said!)...

 The second problem is that the pattern isn't actually thread safe. If two 
 threads (that aren't the automatic thread of the queue) enter the accessor, 
 two blocks will be enqueued serially. The two threads will then block, 
 waiting for their blocks to finish executing.
 
 So far so good but when the first block finishes, it could happen that the 
 first thread blocks until the second block finishes, at which time the foo 
 value computed by the first block will have been replaced by the value 
 computed by the second block, since foo is shared among all blocks that 
 captured it.

If I understand you correctly, what you're saying about your variable __block 
SomeObjType foo is not true. Regardless of the __block qualifier, foo is 
effectively a stack-based variable, so two simultaneously-executing threads 
have their own independent instance of that variable. There can be no 
cross-talk between the variables in separate threads - all you are doing is 
enabling the block that a given thread executes to have access to that specific 
thread's stack variable.

However I don't think you should need to do this anyway. I would change your 
code to something like this:

- (SomeObjType) foo
{
   dispatch_sync(queue,
   ^{
   // Code in this block ensures bah is valid
   if (nil == bah)
   {
   // Code to compute and store bah goes here
   }
   });

   return bah;
}

I'm pretty sure that will behave as you want. This does of course assume that 
bah is created once and once only, and will never be released and set to nil 
while threads are using it. That is a big assumption, but I'm pretty sure that 
if you violate that condition then you are going to have to think VERY 
carefully about how to actually specify sensible behaviour at all based on 
this sort of accessor pattern, and do a lot of additional 'retain'ing of 
objects.

What do you reckon?
Jonny___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: isDeletableFileAtPath: returns YES for locked files???

2011-04-14 Thread Vera Tkachenko


 Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for a 
 locked file? Based on the result it returns, when I try to send it a 
 removeItemAtPath:error:, it fails and the error localized description is 
 '„This is a test.docx‰ couldn‚t be removed because you don‚t have permission 
 to access it.'. That seems wrong to me. First, isDeletableFileAtPath: 
 shouldn't return YES for a locked file.
 
 Comments?
 
 -Laurent.
 -- 
 Laurent Daudelin
 AIM/iChat/Skype:LaurentDaudelin   
 http://www.nemesys-soft.com/
 Logiciels Nemesys Software
 laur...@nemesys-soft.com

After unsuccessful experience with isDeletableFileAtPath: I've come up with 
trying to remove file at first and if failed try to unlock file if it's locked 
and try to remove it again. But I agree, isDeletableFileAtPath: behavior is 
incorrect in this case.

--  
Thanks,
Vera Tkachenko
Developer @macpaw___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Cocoa witch's broom

2011-04-14 Thread Rodrigo Zanatta Silva

Hi. I am starting a project that will be a program to learn. My idea is use
every single function of Cocoa framework to show any behavior. For newbie
like me, same time is difficult read the Apple docs and know what the
function exact do, and what object I have to use in same cases.

Ok, but firstly I have to chose a name. First I thought use Cocoa with
hate, a joke because exist the site Cocoa with love (I am not hate Cocoa,
not all the time :P ). But I thought this a bit bad.

My new idea was use the disease of cocoa, namely witch's broom. Here in
Brazil, this is a pest and isn't a easy to prevent. There are two meanings
in this name. First is the joke because we have to fight with cocoa to
learn. The disease itself is a (don't know the correct english name for
this) huddle, congeries... of wood and leaves that look like a witch's
broom. http://www.sierrapotomac.org/W_Needham/WitchesBroom_R041220.htm And
this will be the program, a lot of thing in a small place.

Witch's broom isn't disease only for cocoa. So Witch's broom itself isn't
a good name for a program. My ideas was:

   - Cocoa Witch's Broom (Do this the most correct?)
   - Cocoa Witches Broom  (Isn't it the correct?)
   - Cocoa's With Broom (With Broom of cocoa)
   - Cocoa's Witch's Broom
   - Witch's Broom of Cocoa
   - Witches Broom of Cocoa

For you, English speaker, what is the most correct, The first is not the
correct? Witches is the plural? Give-me a idea for this.
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

Hi Jonathan,

thanks for replying.

On Apr 14, 2011, at 11:12 AM, Jonathan Taylor wrote:

 I am afraid I am not completely sure what you mean by your first problem,

That's ok. As I said, it's easy to fix. I don't want to get sidetracked here by 
going through it in detail. If you'd like to discuss that problem in more 
detail, we can do it off the list.

 but hopefully my answer to your second one sidesteps your concern there. In 
 answer to your second (once I had parsed out the two different uses of the 
 word block in what you said!)...

Yeah, the use of 'block' as both a verb and a noun is a bit confusing. Blame 
Apple for that... :)

 If I understand you correctly, what you're saying about your variable 
 __block SomeObjType foo is not true. Regardless of the __block qualifier, 
 foo is effectively a stack-based variable, so two simultaneously-executing 
 threads have their own independent instance of that variable. There can be no 
 cross-talk between the variables in separate threads - all you are doing is 
 enabling the block that a given thread executes to have access to that 
 specific thread's stack variable.

I'm afraid you're incorrect there. According to the documentation (or, more 
precisely, my understanding of the documentation), a variable qualified with 
__block starts in the stack but is moved to the heap, precisely because it's 
shared by all blocks capturing it and by all function scopes where it's 
declared. Therefore, I do not believe two simultaneously-executing threads 
have their own independent instance of that variable to be true.

 However I don't think you should need to do this anyway. I would change your 
 code to something like this:
 
 - (SomeObjType) foo
 {
   dispatch_sync(queue,
   ^{
   // Code in this block ensures bah is valid
   if (nil == bah)
   {
   // Code to compute and store bah goes here
   }
   });
 
   return bah;
 }

I don't see how that could possibly work as is because bah is out of scope by 
the time the return statement is executed. Perhaps you meant that bah is an 
ivar or property declared in the same class as the accessor. I'm suddenly 
drawing a blank here because I considered this before and came to the 
conclusion that it wouldn't work but now I can't remember why I thought that 
way. I need to think this through a bit more.

Thanks again for your input.
WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Allyn Bauer

I'm not sure creating a program to use every method in Cocoa is such a great 
idea. What you should probably do instead is pick a small simple idea and 
implement it. Perhaps you can make an app that lists the native trees of Brazil 
and their diseases. :)

Allyn

On Apr 14, 2011, at 9:28 AM, Rodrigo Zanatta Silva wrote:

 Hi. I am starting a project that will be a program to learn. My idea is use
 every single function of Cocoa framework to show any behavior. For newbie
 like me, same time is difficult read the Apple docs and know what the
 function exact do, and what object I have to use in same cases.
 
 Ok, but firstly I have to chose a name. First I thought use Cocoa with
 hate, a joke because exist the site Cocoa with love (I am not hate Cocoa,
 not all the time :P ). But I thought this a bit bad.
 
 My new idea was use the disease of cocoa, namely witch's broom. Here in
 Brazil, this is a pest and isn't a easy to prevent. There are two meanings
 in this name. First is the joke because we have to fight with cocoa to
 learn. The disease itself is a (don't know the correct english name for
 this) huddle, congeries... of wood and leaves that look like a witch's
 broom. http://www.sierrapotomac.org/W_Needham/WitchesBroom_R041220.htm And
 this will be the program, a lot of thing in a small place.
 
 Witch's broom isn't disease only for cocoa. So Witch's broom itself isn't
 a good name for a program. My ideas was:
 
   - Cocoa Witch's Broom (Do this the most correct?)
   - Cocoa Witches Broom  (Isn't it the correct?)
   - Cocoa's With Broom (With Broom of cocoa)
   - Cocoa's Witch's Broom
   - Witch's Broom of Cocoa
   - Witches Broom of Cocoa
 
 For you, English speaker, what is the most correct, The first is not the
 correct? Witches is the plural? Give-me a idea for this.
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/allyn.bauer%40gmail.com
 
 This email sent to allyn.ba...@gmail.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

Hi WT,

 If I understand you correctly, what you're saying about your variable 
 __block SomeObjType foo is not true. Regardless of the __block qualifier, 
 foo is effectively a stack-based variable, so two simultaneously-executing 
 threads have their own independent instance of that variable. There can be 
 no cross-talk between the variables in separate threads - all you are 
 doing is enabling the block that a given thread executes to have access to 
 that specific thread's stack variable.
 
 I'm afraid you're incorrect there. According to the documentation (or, more 
 precisely, my understanding of the documentation), a variable qualified with 
 __block starts in the stack but is moved to the heap, precisely because it's 
 shared by all blocks capturing it and by all function scopes where it's 
 declared. Therefore, I do not believe two simultaneously-executing threads 
 have their own independent instance of that variable to be true.

I tested this out before replying as I wasn't 100% certain. It may be that we 
have misunderstood each other somehow, but the following code (in a clean new 
project) was what I used to confirm to myself that two concurrently-executing 
threads have independent instances of the variable:
http://www.dur.ac.uk/j.m.taylor/block_test_code.m

 However I don't think you should need to do this anyway. I would change your 
 code to something like this:
 
 - (SomeObjType) foo
 {
  dispatch_sync(queue,
  ^{
  // Code in this block ensures bah is valid
  if (nil == bah)
  {
  // Code to compute and store bah goes here
  }
  });
 
  return bah;
 }
 
 I don't see how that could possibly work as is because bah is out of scope by 
 the time the return statement is executed. Perhaps you meant that bah is an 
 ivar or property declared in the same class as the accessor. I'm suddenly 
 drawing a blank here because I considered this before and came to the 
 conclusion that it wouldn't work but now I can't remember why I thought that 
 way. I need to think this through a bit more.
OK, well since you do not declare bah locally, and from what you are doing it 
is presumably meant to be persistent, I assumed that it was indeed a property 
(or a global?). If you are doing something else with it (though I'm not quite 
sure what...) then obviously what I wrote may be wrong...

Jonny___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Jeff Kelley

Agreed. You wouldn’t go to the hardware store and try to build something
using every product they carried.

As for the English, Wikipedia has an article for “Witch’s Broom” in English,
so I would go with the first (“Cocoa Witch’s Broom”). Not that I would build
the app.

Jeff Kelley


On Thu, Apr 14, 2011 at 11:56 AM, Allyn Bauer allyn.ba...@gmail.com wrote:

 I'm not sure creating a program to use every method in Cocoa is such a
 great idea. What you should probably do instead is pick a small simple idea
 and implement it. Perhaps you can make an app that lists the native trees of
 Brazil and their diseases. :)

 Allyn

 On Apr 14, 2011, at 9:28 AM, Rodrigo Zanatta Silva wrote:

  Hi. I am starting a project that will be a program to learn. My idea is
 use
  every single function of Cocoa framework to show any behavior. For newbie
  like me, same time is difficult read the Apple docs and know what the
  function exact do, and what object I have to use in same cases.
 
  Ok, but firstly I have to chose a name. First I thought use Cocoa with
  hate, a joke because exist the site Cocoa with love (I am not hate
 Cocoa,
  not all the time :P ). But I thought this a bit bad.
 
  My new idea was use the disease of cocoa, namely witch's broom. Here in
  Brazil, this is a pest and isn't a easy to prevent. There are two
 meanings
  in this name. First is the joke because we have to fight with cocoa to
  learn. The disease itself is a (don't know the correct english name for
  this) huddle, congeries... of wood and leaves that look like a witch's
  broom. http://www.sierrapotomac.org/W_Needham/WitchesBroom_R041220.htm
 And
  this will be the program, a lot of thing in a small place.
 
  Witch's broom isn't disease only for cocoa. So Witch's broom itself
 isn't
  a good name for a program. My ideas was:
 
- Cocoa Witch's Broom (Do this the most correct?)
- Cocoa Witches Broom  (Isn't it the correct?)
- Cocoa's With Broom (With Broom of cocoa)
- Cocoa's Witch's Broom
- Witch's Broom of Cocoa
- Witches Broom of Cocoa
 
  For you, English speaker, what is the most correct, The first is not the
  correct? Witches is the plural? Give-me a idea for this.
  ___
 
  Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
  Please do not post admin requests or moderator comments to the list.
  Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
  Help/Unsubscribe/Update your Subscription:
  http://lists.apple.com/mailman/options/cocoa-dev/allyn.bauer%40gmail.com
 
  This email sent to allyn.ba...@gmail.com

 ___

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

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

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

 This email sent to slauncha...@gmail.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

2011-04-14 Thread David Duncan

On Apr 14, 2011, at 9:19 AM, Jonathan Taylor wrote:

 Hi WT,
 
 If I understand you correctly, what you're saying about your variable 
 __block SomeObjType foo is not true. Regardless of the __block qualifier, 
 foo is effectively a stack-based variable, so two simultaneously-executing 
 threads have their own independent instance of that variable. There can be 
 no cross-talk between the variables in separate threads - all you are 
 doing is enabling the block that a given thread executes to have access to 
 that specific thread's stack variable.
 
 I'm afraid you're incorrect there. According to the documentation (or, more 
 precisely, my understanding of the documentation), a variable qualified with 
 __block starts in the stack but is moved to the heap, precisely because it's 
 shared by all blocks capturing it and by all function scopes where it's 
 declared. Therefore, I do not believe two simultaneously-executing threads 
 have their own independent instance of that variable to be true.
 
 I tested this out before replying as I wasn't 100% certain. It may be that we 
 have misunderstood each other somehow, but the following code (in a clean new 
 project) was what I used to confirm to myself that two concurrently-executing 
 threads have independent instances of the variable:
 http://www.dur.ac.uk/j.m.taylor/block_test_code.m

On this point Jonathan is correct. What __block does is ensure that a declared 
variable has the ability to survive its stack frame, not that a variable of 
that name is shared with all invocations of that stack frame. If you want a 
variable that will be shared with all instances of that stack frame, you want 
the static qualifier.

 However I don't think you should need to do this anyway. I would change 
 your code to something like this:
 
 - (SomeObjType) foo
 {
 dispatch_sync(queue,
 ^{
 // Code in this block ensures bah is valid
 if (nil == bah)
 {
 // Code to compute and store bah goes here
 }
 });
 
 return bah;
 }


Fundamentally however, this will not work. If you want to do lazy 
initialization of a variable with thread safety then you should use 
dispatch_once() to initialize the variable. This is also not something you can 
do with a __block or static variable (unless you want all instances to have the 
same value, which seems to be against the way you've declared the method). 
Basically you need to do this:

- (SomeObjectType) foo
{
dispatch_once(ivar_predicate, ^ { ivar_value = /* initialization */ });
return ivar_value;
}
--
David Duncan

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

On Apr 14, 2011, at 1:19 PM, Jonathan Taylor wrote:

 I tested this out before replying as I wasn't 100% certain. It may be that we 
 have misunderstood each other somehow, but the following code (in a clean new 
 project) was what I used to confirm to myself that two concurrently-executing 
 threads have independent instances of the variable:
 http://www.dur.ac.uk/j.m.taylor/block_test_code.m

More likely, I've misunderstood the documentation. It's happened before, many 
times. :)

I looked at your code only briefly now but will return to study it in detail 
later (kinda busy right now). I must say that I'm confused now more than 
before, because I really thought that the __block qualifier meant that there is 
only one instance of that variable, shared by all scopes that declare it and 
shared by all blocks that capture it.


 However I don't think you should need to do this anyway. I would change 
 your code to something like this:
 
 - (SomeObjType) foo
 {
 dispatch_sync(queue,
 ^{
 // Code in this block ensures bah is valid
 if (nil == bah)
 {
 // Code to compute and store bah goes here
 }
 });
 
 return bah;
 }
 
 I don't see how that could possibly work as is because bah is out of scope 
 by the time the return statement is executed. Perhaps you meant that bah is 
 an ivar or property declared in the same class as the accessor. I'm suddenly 
 drawing a blank here because I considered this before and came to the 
 conclusion that it wouldn't work but now I can't remember why I thought that 
 way. I need to think this through a bit more.

 OK, well since you do not declare bah locally, and from what you are doing it 
 is presumably meant to be persistent, I assumed that it was indeed a property 
 (or a global?). If you are doing something else with it (though I'm not quite 
 sure what...) then obviously what I wrote may be wrong...

No, actually you are totally correct here. As it happens, I do use the pattern 
you suggest, in several places where the conditions are precisely those you 
laid out: the ivars are meant to be instantiated only once and never released. 
It's in other cases where those conditions break that I'm struggling with.

Clearly I need to refine my understanding of blocks and discussions like this 
greatly help.

Thanks again.
WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

2011-04-14 Thread Dave Zarzycki


On Apr 14, 2011, at 6:20 AM, WT wrote:

 Hi all,
 
 I've started to use GCD in my projects and I found myself using a certain 
 pattern that I now realize isn't actually thread safe. The goal is to write a 
 thread-safe lazy accessor without using locks, @synchronized, or an atomic 
 property. At first I thought that
 
 - (SomeObjType) foo
 {
__block SomeObjType foo = nil;
 
dispatch_sync(queue,
^{
// retrieve bah
 
if (nil == bah)
{
// compute and store bah
}
 
foo = bah;
});
 
return foo;
 }
 
 would do it. Here, bah is some resource that may be changed by multiple 
 threads and queue is a serial GCD queue defined as a static variable in the 
 class where this accessor is defined. The queue is not any of the global 
 queues, but is created by the class.

Please keep in mind that while GCD is certainly is more efficient than locks, 
@synchronized, or atomic properties, it isn't magic. In a retain/release (not 
GC) world, it simply is impossible to implement a lockless accessors around 
instance variables that are objects. It doesn't matter if one uses GCD or other 
kinds of locks or lock-like APIs:

- (Obj *j)foo
{
Obj *tmp;
lock(); // to ensure that 'ivar' isn't changing because the act of 
retaining dereferences 'ivar'
tmp = [ivar retain];
unlock();
return [tmp autorelease];   
}

Note: like atomic properties, the above code ONLY ensures thread safety at the 
memory management layer. It doesn't ensure concurrent design correctness. In 
fact, with the above code and with atomic properties, nothing stops multiple 
threads from concurrently mutating the returned result, and it blatantly 
encourages time-of-use-vs-time-of-check bugs.

 
 I see two problems with this pattern.
 
 The first is that if the method gets invoked already in the queue's automatic 
 thread, there will be a deadlock. That's easy to fix, by wrapping the 
 dispatch call into a function that tests queue against the currently 
 executing queue and simply executes the block when they coincide.

Actually, this isn't easy to fix due to X-A-B-A problems, where X is the 
current queue, then A, then B, and then the code deadlocks trying to 
dispatch_sync() against A because it isn't the current queue.

If you want to permit thread local reentrancy, one must use pthread_self(), not 
dispatch_get_current_queue() to detect and allow safe reentrancy.

Personally speaking, reentrant behavior is a sign that the object graph of your 
code contains cycles, which are problematic for all sorts of reasons, not just 
synchronization. If you fix the design, then you can avoid the thread local 
reentrancy problem entirely.

 
 The second problem is that the pattern isn't actually thread safe. If two 
 threads (that aren't the automatic thread of the queue) enter the accessor, 
 two blocks will be enqueued serially. The two threads will then block, 
 waiting for their blocks to finish executing.
 
 So far so good but when the first block finishes, it could happen that the 
 first thread blocks until the second block finishes, at which time the foo 
 value computed by the first block will have been replaced by the value 
 computed by the second block, since foo is shared among all blocks that 
 captured it.
 
 Thus, when the first thread resumes, it will report the wrong foo value.

Can you please provide a compilable test case?

davez___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

Hi David,

thanks for pitching in.

On Apr 14, 2011, at 1:40 PM, David Duncan wrote:

 I tested this out before replying as I wasn't 100% certain. It may be that 
 we have misunderstood each other somehow, but the following code (in a clean 
 new project) was what I used to confirm to myself that two 
 concurrently-executing threads have independent instances of the variable:
 http://www.dur.ac.uk/j.m.taylor/block_test_code.m
 
 On this point Jonathan is correct. What __block does is ensure that a 
 declared variable has the ability to survive its stack frame, not that a 
 variable of that name is shared with all invocations of that stack frame. If 
 you want a variable that will be shared with all instances of that stack 
 frame, you want the static qualifier.

I see. It's final, then: I have misunderstood the documentation. Thank you both 
for pointing me in the right direction.


 However I don't think you should need to do this anyway. I would change 
 your code to something like this:
 
 - (SomeObjType) foo
 {
 dispatch_sync(queue,
 ^{
// Code in this block ensures bah is valid
if (nil == bah)
{
// Code to compute and store bah goes here
}
 });
 
 return bah;
 }
 
 
 Fundamentally however, this will not work. If you want to do lazy 
 initialization of a variable with thread safety then you should use 
 dispatch_once() to initialize the variable. This is also not something you 
 can do with a __block or static variable (unless you want all instances to 
 have the same value, which seems to be against the way you've declared the 
 method). Basically you need to do this:
 
 - (SomeObjectType) foo
 {
   dispatch_once(ivar_predicate, ^ { ivar_value = /* initialization */ });
   return ivar_value;
 }

I looked at dispatch_once() at one point, but I'm still confused by how it 
works. In any case, here's an actual example of where I use the pattern 
Jonathan suggested, and I can't see why it would not work.

stSerialQueue is a static variable in the class where -shortStyleDateFormatter 
is declared.

shortStyleDateFormatter_ is an ivar in that same class, backing the property 
for which the accessor is being written.

WLT_GCDUtils' +dispatchToQueue: async: guarantees that the dispatch is 
deadlock-free regardless of which thread the block is executed in.

- (NSDateFormatter*) shortStyleDateFormatter;
{
[WLT_GCDUtils dispatchToQueue: stSerialQueue
async: NO
block:
^{
if (nil == shortStyleDateFormatter_)
{
shortStyleDateFormatter_ = [[NSDateFormatter alloc] init];

[shortStyleDateFormatter_ setLocale:
[NSLocale autoupdatingCurrentLocale]];

[shortStyleDateFormatter_ setDateStyle:
NSDateFormatterShortStyle];
}
}];

return shortStyleDateFormatter_;
}

// In WLT_GCDUtils.m

+ (void) dispatchToQueue: (dispatch_queue_t) queue
   async: (BOOL) async
   block: (void (^)(void)) block;
{
if (dispatch_get_current_queue() != queue)
{
if (async)
{
dispatch_async(queue, block);
}
else
{
dispatch_sync(queue, block);
}
}
else // already in target queue
{
// Just in case we might need one...
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

block();

[pool release];
}
}

Thanks again for your help.
WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

2011-04-14 Thread David Duncan

On Apr 14, 2011, at 10:02 AM, WT wrote:

 I looked at dispatch_once() at one point, but I'm still confused by how it 
 works.

dispatch_once uses a predicate (just a flag) to determine if it should run the 
block or not. If that flag is false, then it sets the flag to true and executes 
the block. If the flag is true, it does nothing. What makes dispatch_once 
useful over a simple if statement is that it ensures that if you execute 
dispatch_once concurrently from multiple threads that flag gets updated exactly 
once, and the block gets called exactly once.
--
David Duncan

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Rodrigo Zanatta Silva

Lol, this will be a open source project. I will not do this alone and not do
in one day. Like I say, there are function in same objects that you will
only understand what it do if you use it and you will lose a lot of time in
this trial and error.

Exist even difficult function to implement. I started using NSString, a
trivial object and I saw how difficult is implement the function
*initWithFormat:locale:arguments:*
*
*
You will see a lot of people in this forum saying to see code in my program
in the future :P*
*

2011/4/14 Allyn Bauer allyn.ba...@gmail.com

 I'm not sure creating a program to use every method in Cocoa is such a
 great idea. What you should probably do instead is pick a small simple idea
 and implement it. Perhaps you can make an app that lists the native trees of
 Brazil and their diseases. :)

 Allyn

 On Apr 14, 2011, at 9:28 AM, Rodrigo Zanatta Silva wrote:

  Hi. I am starting a project that will be a program to learn. My idea is
 use
  every single function of Cocoa framework to show any behavior. For newbie
  like me, same time is difficult read the Apple docs and know what the
  function exact do, and what object I have to use in same cases.
 
  Ok, but firstly I have to chose a name. First I thought use Cocoa with
  hate, a joke because exist the site Cocoa with love (I am not hate
 Cocoa,
  not all the time :P ). But I thought this a bit bad.
 
  My new idea was use the disease of cocoa, namely witch's broom. Here in
  Brazil, this is a pest and isn't a easy to prevent. There are two
 meanings
  in this name. First is the joke because we have to fight with cocoa to
  learn. The disease itself is a (don't know the correct english name for
  this) huddle, congeries... of wood and leaves that look like a witch's
  broom. http://www.sierrapotomac.org/W_Needham/WitchesBroom_R041220.htm
 And
  this will be the program, a lot of thing in a small place.
 
  Witch's broom isn't disease only for cocoa. So Witch's broom itself
 isn't
  a good name for a program. My ideas was:
 
- Cocoa Witch's Broom (Do this the most correct?)
- Cocoa Witches Broom  (Isn't it the correct?)
- Cocoa's With Broom (With Broom of cocoa)
- Cocoa's Witch's Broom
- Witch's Broom of Cocoa
- Witches Broom of Cocoa
 
  For you, English speaker, what is the most correct, The first is not the
  correct? Witches is the plural? Give-me a idea for this.
  ___
 
  Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
  Please do not post admin requests or moderator comments to the list.
  Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
  Help/Unsubscribe/Update your Subscription:
  http://lists.apple.com/mailman/options/cocoa-dev/allyn.bauer%40gmail.com
 
  This email sent to allyn.ba...@gmail.com


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

Hi Dave,

thanks for replying. I must say some of what you said went above my head. :)

On Apr 14, 2011, at 2:02 PM, Dave Zarzycki wrote:

 The first is that if the method gets invoked already in the queue's 
 automatic thread, there will be a deadlock. That's easy to fix, by wrapping 
 the dispatch call into a function that tests queue against the currently 
 executing queue and simply executes the block when they coincide.
 
 Actually, this isn't easy to fix due to X-A-B-A problems, where X is the 
 current queue, then A, then B, and then the code deadlocks trying to 
 dispatch_sync() against A because it isn't the current queue.

Why isn't the following deadlock-free?

// In WLT_GCDUtils.m

+ (void) dispatchToQueue: (dispatch_queue_t) queue
   async: (BOOL) async
   block: (void (^)(void)) block;
{
if (dispatch_get_current_queue() != queue)
{
if (async)
{
dispatch_async(queue, block);
}
else
{
dispatch_sync(queue, block);
}
}
else // already in target queue
{
// Just in case we might need one...
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

block();

[pool release];
}
}

 The second problem is that the pattern isn't actually thread safe. If two 
 threads (that aren't the automatic thread of the queue) enter the accessor, 
 two blocks will be enqueued serially. The two threads will then block, 
 waiting for their blocks to finish executing.
 
 So far so good but when the first block finishes, it could happen that the 
 first thread blocks until the second block finishes, at which time the foo 
 value computed by the first block will have been replaced by the value 
 computed by the second block, since foo is shared among all blocks that 
 captured it.
 
 Thus, when the first thread resumes, it will report the wrong foo value.
 
 Can you please provide a compilable test case?

I don't have an actual sample case where it has happened. Admittedly, this was 
just a thought experiment.

Thanks again for your help.
WT

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

On Apr 14, 2011, at 2:09 PM, David Duncan wrote:

 On Apr 14, 2011, at 10:02 AM, WT wrote:
 
 I looked at dispatch_once() at one point, but I'm still confused by how it 
 works.
 
 dispatch_once uses a predicate (just a flag) to determine if it should run 
 the block or not. If that flag is false, then it sets the flag to true and 
 executes the block. If the flag is true, it does nothing. What makes 
 dispatch_once useful over a simple if statement is that it ensures that if 
 you execute dispatch_once concurrently from multiple threads that flag gets 
 updated exactly once, and the block gets called exactly once.

Thanks for explaining it, David. The bit that was throwing me off is the 
predicate part. I understand now that all I need is to declare a static 
variable of the appropriate type and pass a pointer to it to dispatch_once().

Here's another question, though. In the example I've mentioned already 
(reproduced below so you won't have to look it up in a previous message)

stSerialQueue is a static variable in the class where -shortStyleDateFormatter 
is declared.

shortStyleDateFormatter_ is an ivar in that same class, backing the property 
for which the accessor is being written.

WLT_GCDUtils' +dispatchToQueue: async: guarantees that the dispatch is 
deadlock-free regardless of which thread the block is executed in.

- (NSDateFormatter*) shortStyleDateFormatter;
{
   [WLT_GCDUtils dispatchToQueue: stSerialQueue
   async: NO
   block:
   ^{
   if (nil == shortStyleDateFormatter_)
   {
   shortStyleDateFormatter_ = [[NSDateFormatter alloc] init];

   [shortStyleDateFormatter_ setLocale:
   [NSLocale autoupdatingCurrentLocale]];

   [shortStyleDateFormatter_ setDateStyle:
   NSDateFormatterShortStyle];
   }
   }];

   return shortStyleDateFormatter_;
}

// In WLT_GCDUtils.m

+ (void) dispatchToQueue: (dispatch_queue_t) queue
  async: (BOOL) async
  block: (void (^)(void)) block;
{
   if (dispatch_get_current_queue() != queue)
   {
   if (async)
   {
   dispatch_async(queue, block);
   }
   else
   {
   dispatch_sync(queue, block);
   }
   }
   else // already in target queue
   {
   // Just in case we might need one...
   NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

   block();

   [pool release];
   }
}

the locale is autoupdating. The instance of the class in question listens to 
notifications of the locale changing, invokes a method that releases and 
nillifies all the ivars such as shortStyleDateFormatter_ when those 
notifications arrive, and then posts its own notification so that the rest of 
the application can update its UI. Naturally, the rest of the application may 
need to invoke -shortStyleDateFormatter and similar methods and the work needs 
to be redone for the new locale.

From my understanding of dispatch_once(), I can't use it for this purpose 
because it really executes the block only once in the application's life time.

WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

2011-04-14 Thread Dave Zarzycki


On Apr 14, 2011, at 10:11 AM, WT wrote:

 Hi Dave,
 
 thanks for replying. I must say some of what you said went above my head. :)
 
 On Apr 14, 2011, at 2:02 PM, Dave Zarzycki wrote:
 
 The first is that if the method gets invoked already in the queue's 
 automatic thread, there will be a deadlock. That's easy to fix, by wrapping 
 the dispatch call into a function that tests queue against the currently 
 executing queue and simply executes the block when they coincide.
 
 Actually, this isn't easy to fix due to X-A-B-A problems, where X is the 
 current queue, then A, then B, and then the code deadlocks trying to 
 dispatch_sync() against A because it isn't the current queue.
 
 Why isn't the following deadlock-free?

Because once we subtract the layers of abstraction that your code is adding, 
we're left with this bug:



test.c
Description: Binary data



davez
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

2011-04-14 Thread David Duncan

On Apr 14, 2011, at 10:26 AM, WT wrote:

 On Apr 14, 2011, at 2:09 PM, David Duncan wrote:
 
 On Apr 14, 2011, at 10:02 AM, WT wrote:
 
 I looked at dispatch_once() at one point, but I'm still confused by how it 
 works.
 
 dispatch_once uses a predicate (just a flag) to determine if it should run 
 the block or not. If that flag is false, then it sets the flag to true and 
 executes the block. If the flag is true, it does nothing. What makes 
 dispatch_once useful over a simple if statement is that it ensures that if 
 you execute dispatch_once concurrently from multiple threads that flag gets 
 updated exactly once, and the block gets called exactly once.
 
 Thanks for explaining it, David. The bit that was throwing me off is the 
 predicate part. I understand now that all I need is to declare a static 
 variable of the appropriate type and pass a pointer to it to dispatch_once().

The lifetime of the predicate needs to match that of the initialization done by 
the block. If the block's initialization is done for an instance variable, then 
the predicate should also be an instance variable. If the initialization is for 
a global, the predicate should also be a global.

 From my understanding of dispatch_once(), I can't use it for this purpose 
 because it really executes the block only once in the application's life time.


There are complications in doing this due to the fact that resetting the 
predicate may introduce race conditions. But then as DaveZ mentioned, your 
pattern can introduce deadlocks too. I don't think there is a good pattern for 
doing exactly what you want to do with the conditions you impose on it, but I 
suspect if you re-evaluate your design you can find a better solution with 
fewer issues.
--
David Duncan

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Dan Treiman

This sounds like a very interesting project.

For inspiration/an example of something similar, I'd recommend taking a look at 
Philippe Mougin's F-Script. ( http://www.fscript.org/ )

Its a scripting system that lets you explore and manipulate cocoa objects 
interactively.  It also is a very good learning tool for newcomers to cocoa. 


On Apr 14, 2011, at 12:11 PM, Rodrigo Zanatta Silva wrote:

 Lol, this will be a open source project. I will not do this alone and not do
 in one day. Like I say, there are function in same objects that you will
 only understand what it do if you use it and you will lose a lot of time in
 this trial and error.
 
 Exist even difficult function to implement. I started using NSString, a
 trivial object and I saw how difficult is implement the function
 *initWithFormat:locale:arguments:*
 *
 *
 You will see a lot of people in this forum saying to see code in my program
 in the future :P*
 *
 
 2011/4/14 Allyn Bauer allyn.ba...@gmail.com
 
 I'm not sure creating a program to use every method in Cocoa is such a
 great idea. What you should probably do instead is pick a small simple idea
 and implement it. Perhaps you can make an app that lists the native trees of
 Brazil and their diseases. :)
 
 Allyn
 
 On Apr 14, 2011, at 9:28 AM, Rodrigo Zanatta Silva wrote:
 
 Hi. I am starting a project that will be a program to learn. My idea is
 use
 every single function of Cocoa framework to show any behavior. For newbie
 like me, same time is difficult read the Apple docs and know what the
 function exact do, and what object I have to use in same cases.
 
 Ok, but firstly I have to chose a name. First I thought use Cocoa with
 hate, a joke because exist the site Cocoa with love (I am not hate
 Cocoa,
 not all the time :P ). But I thought this a bit bad.
 
 My new idea was use the disease of cocoa, namely witch's broom. Here in
 Brazil, this is a pest and isn't a easy to prevent. There are two
 meanings
 in this name. First is the joke because we have to fight with cocoa to
 learn. The disease itself is a (don't know the correct english name for
 this) huddle, congeries... of wood and leaves that look like a witch's
 broom. http://www.sierrapotomac.org/W_Needham/WitchesBroom_R041220.htm
 And
 this will be the program, a lot of thing in a small place.
 
 Witch's broom isn't disease only for cocoa. So Witch's broom itself
 isn't
 a good name for a program. My ideas was:
 
  - Cocoa Witch's Broom (Do this the most correct?)
  - Cocoa Witches Broom  (Isn't it the correct?)
  - Cocoa's With Broom (With Broom of cocoa)
  - Cocoa's Witch's Broom
  - Witch's Broom of Cocoa
  - Witches Broom of Cocoa
 
 For you, English speaker, what is the most correct, The first is not the
 correct? Witches is the plural? Give-me a idea for this.
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/allyn.bauer%40gmail.com
 
 This email sent to allyn.ba...@gmail.com
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/dtreiman%40mac.com
 
 This email sent to dtrei...@mac.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Mike Abdullah


On 14 Apr 2011, at 18:11, Rodrigo Zanatta Silva wrote:

 Lol, this will be a open source project. I will not do this alone and not do
 in one day. Like I say, there are function in same objects that you will
 only understand what it do if you use it and you will lose a lot of time in
 this trial and error.
 
 Exist even difficult function to implement. I started using NSString, a
 trivial object and I saw how difficult is implement the function
 *initWithFormat:locale:arguments:*

Do you really mean implement, or use? Implementing that method is highly 
rare.

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Anybody using NSFileManager here?

Just wondering. I've been using it more lately and after posting a few 
questions over the last couple of weeks, I've been surprised by the lack of 
response, which might explain while it is so buggy.

So, anybody on the list using NSFileManager for serious stuff besides me?

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

2011-04-14 Thread Fritz Anderson

On 14 Apr 2011, at 12:51 PM, Laurent Daudelin wrote:

 So, anybody on the list using NSFileManager for serious stuff besides me?

Constantly, though for undemanding, synchronous tasks: Existence, deletion, 
creation, properties, rename, move, standard directory paths. I almost never 
use the POSIX equivalents.

What sort of problems are you having? I'm sorry I don't remember your questions.

— F

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

On Apr 14, 2011, at 11:18, Fritz Anderson wrote:

 On 14 Apr 2011, at 12:51 PM, Laurent Daudelin wrote:
 
 So, anybody on the list using NSFileManager for serious stuff besides me?
 
 Constantly, though for undemanding, synchronous tasks: Existence, deletion, 
 creation, properties, rename, move, standard directory paths. I almost never 
 use the POSIX equivalents.
 
 What sort of problems are you having? I'm sorry I don't remember your 
 questions.

Fritz,

Maybe I didn't post my question at the right time. The latest question that 
went under the pile of messages about lockless thread-safe accessor from blocks 
and other UI stuff was this one:

Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for a 
locked file? Based on the result it returns, when I try to send it a 
removeItemAtPath:error:, it fails and the error localized description is '“This 
is a test.docx” couldn’t be removed because you don’t have permission to access 
it.'. That seems wrong to me. First, isDeletableFileAtPath: shouldn't return 
YES for a locked file.

Not a big problem. I can check if it's writable at path and if it's not, then I 
know the delete won't work but I was wondering if this was the expected 
behavior for NSFileManager isDeletableFileAtPath: ...

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: isDeletableFileAtPath: returns YES for locked files???

2011-04-14 Thread Sean McBride

On Wed, 13 Apr 2011 16:33:19 -0700, Laurent Daudelin said:

Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for
a locked file? Based on the result it returns, when I try to send it a
removeItemAtPath:error:, it fails and the error localized description is
'“This is a test.docx” couldn’t be removed because you don’t have
permission to access it.'. That seems wrong to me. First,
isDeletableFileAtPath: shouldn't return YES for a locked file.

Sounds broken to me.  But in any case, using methods like
isDeletableFileAtPath: can lead to race conditions.  The file may be
unlocked when you check, but then locked right after, but before you
delete.  See:

http://developer.apple.com/library/mac/#documentation/Security/
Conceptual/SecureCodingGuide/Articles/RaceConditions.html

-- 

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

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

2011-04-14 Thread Mike Abdullah


On 14 Apr 2011, at 19:26, Laurent Daudelin wrote:

 On Apr 14, 2011, at 11:18, Fritz Anderson wrote:
 
 On 14 Apr 2011, at 12:51 PM, Laurent Daudelin wrote:
 
 Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for a 
 locked file? Based on the result it returns, when I try to send it a 
 removeItemAtPath:error:, it fails and the error localized description is 
 '“This is a test.docx” couldn’t be removed because you don’t have permission 
 to access it.'. That seems wrong to me. First, isDeletableFileAtPath: 
 shouldn't return YES for a locked file.
 
 Not a big problem. I can check if it's writable at path and if it's not, then 
 I know the delete won't work but I was wondering if this was the expected 
 behavior for NSFileManager isDeletableFileAtPath: ...

In general, Apple recommends that you go ahead and attempt an operation, 
handling any failure, rather than try to see if it will succeed ahead of time. 
For many operations/file systems/failures, it is not even possible to guess at 
the result without trying the op.___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

2011-04-14 Thread Gary L. Wade

The documentation sounds more like it's a convenience method for checking
the Unix permissions for deleting the file rather than the HFS locked
setting.  If you want to consider another non-HFS-aware issue in
NSFileManager, the file size info you get from the relevant message only
returns the size of a file's datafork, not its resource fork or any other
theoretical forks a file may have.  For those who believe no one uses
resource forks, just look at Safari's in-progress downloads and Finder
clippings.

On 04/14/2011 11:26 AM, Laurent Daudelin laur...@nemesys-soft.com
wrote:

Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for
a locked file? Based on the result it returns, when I try to send it a
removeItemAtPath:error:, it fails and the error localized description is
'³This is a test.docx² couldn¹t be removed because you don¹t have
permission to access it.'. That seems wrong to me. First,
isDeletableFileAtPath: shouldn't return YES for a locked file.



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lockless thread-safe accessor using blocks: how to?

Thanks to everyone who responded. Two things are clear: there is no 
one-size-fits-all answer here, and I need to do a more detailed analysis of the 
needs in my project.

WT___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Preventing View Update in NSTableView

2011-04-14 Thread Quincey Morris

On Apr 14, 2011, at 00:42, Peter Lübke wrote:

 This is of course true if the changes are made in the main thread.
 I should have mentioned that I'm changing the data in separate worker threads.
 
 Actually, it's possible that there are several worker threads changing data 
 of different tables in different windows at the same time, while the 
 associated windows display attached sheets showing progress. Permanently 
 redrawing the tables's cells at this stage is confusing and also undesirable 
 for performance reasons.

This *seems* to be wrong at several levels, although perhaps that's just 
because there's information missing.

If processing in background threads is causing table views to update directly, 
then your application design is very seriously broken. All drawing should be 
done from the main thread, which means that KVO notifications must be issued on 
the main thread, which means that the data model must be updated on the main 
thread, as far as KVO compliance is concerned. You cannot bind UI elements to 
objects whose KVO-compliant properties are updated directly by a background 
thread.

It's possible that you mean that the updates *are* happening on the main 
thread, and you have a mechanism that the background threads use to pass the 
updates to the main thread. But if not, you're going to have to invent such a 
mechanism.

Avoiding refreshes of the table views is a different issue. By binding your 
table columns to an array controller, which is in turn bound or connected to 
your data model, you have *opted in* to a mechanism (KVO) that is explicitly 
designed to push updates as and when they occur. So, complaining that refreshes 
occur as and when updates are pushed seems a bit misguided. You're going to 
have to either opt out of that mechanism, or you're going to have to modify its 
behavior:

-- You can use a data source instead of bindings. With a data source, nothing 
gets updated till you tell the table view to display or to reload (or till 
something a user does triggers redrawing). You'll lose some of the free 
functionality that array controllers provide (if you're using it), but it 
shouldn't be hard to implement for yourself.

-- You can invent a mechanism for deferring changes to your data model, until a 
point where UI refreshes are appropriate. It doesn't sound like you can take 
this approach, because it sounds like your background threads depend on the 
current state of the data model being generally available.

-- You can use a mediating controller, for example the window controller, to 
capture the KVO notification data from data model updates, and to withhold it 
from the UI until a suitable refresh time arrives. In this case, your array 
controller's content can't be the data model, but has to be a intermediate data 
model or a proxy data model in the mediating controller.


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Rodrigo Zanatta Silva

lol, bad english.. I mean use it.

Use it is rare too? You can do a dynamic format to create a string.

2011/4/14 Mike Abdullah cocoa...@mikeabdullah.net


 On 14 Apr 2011, at 18:11, Rodrigo Zanatta Silva wrote:

  Lol, this will be a open source project. I will not do this alone and not
 do
  in one day. Like I say, there are function in same objects that you will
  only understand what it do if you use it and you will lose a lot of time
 in
  this trial and error.
 
  Exist even difficult function to implement. I started using NSString, a
  trivial object and I saw how difficult is implement the function
  *initWithFormat:locale:arguments:*

 Do you really mean implement, or use? Implementing that method is
 highly rare.


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MPMoviePlayerController

2011-04-14 Thread Jeffrey Walton

On Wed, Apr 13, 2011 at 12:15 PM, Jeffrey Walton noloa...@gmail.com wrote:
 Hi All,

 I'm trying to play a M4V acquired from iTunes [1]. The movie is local
 and was transferred into my sandbox using iTunes via file sharing.

 Working from a Hillegass example ('Playing Movie Files', p. 294), the
 player appears to load/display but does not play.

 Unfortunately, PLAY is not documented [2]. In addition, I can't find a
 delegate (as with other controllers) and there are no notifications
 covering errors [2]. Finally, the error log is for network streams
 [2].

 How does one determine errors when using MPMoviePlayerController?

 More philosophical: why are the APIs so inconsistent? Why is there no
 readily apparent way to consistently retrieve error information
 (Windows has GetLastError and Linux has errno)?

The problem appears to be with the size of the M4V. For example,
Hillegass's Chapter 20 sample ('Layer.m4p') at 2.2 MB plays as
expected. The Simpsons episode, at 230 MB, does not play. The player
moves from a 'ready' state to a 'playing' state and then immediately
back to a 'ready' state without a Finished notification or error.

If anyone has experienced similar, work arounds would be appreciated.
So far, I have only figured out how to crash Xcode while the app was
under the debugger.

Jeff
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

On Apr 14, 2011, at 11:38, Mike Abdullah wrote:

 
 On 14 Apr 2011, at 19:26, Laurent Daudelin wrote:
 
 On Apr 14, 2011, at 11:18, Fritz Anderson wrote:
 
 On 14 Apr 2011, at 12:51 PM, Laurent Daudelin wrote:
 
 Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for a 
 locked file? Based on the result it returns, when I try to send it a 
 removeItemAtPath:error:, it fails and the error localized description is 
 '“This is a test.docx” couldn’t be removed because you don’t have permission 
 to access it.'. That seems wrong to me. First, isDeletableFileAtPath: 
 shouldn't return YES for a locked file.
 
 Not a big problem. I can check if it's writable at path and if it's not, 
 then I know the delete won't work but I was wondering if this was the 
 expected behavior for NSFileManager isDeletableFileAtPath: ...
 
 In general, Apple recommends that you go ahead and attempt an operation, 
 handling any failure, rather than try to see if it will succeed ahead of 
 time. For many operations/file systems/failures, it is not even possible to 
 guess at the result without trying the op.

That's a good point, Mike. In my app, I want to provide file operation but try 
to restrict them if they're going to fail. I still handle the failures in my 
code but I feel it's a better user experience that they know in advance, for 
example, that a file is locked and thus I won't be able to delete it or replace 
it.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

On Apr 14, 2011, at 11:44, Gary L. Wade wrote:

 The documentation sounds more like it's a convenience method for checking
 the Unix permissions for deleting the file rather than the HFS locked
 setting.  If you want to consider another non-HFS-aware issue in
 NSFileManager, the file size info you get from the relevant message only
 returns the size of a file's datafork, not its resource fork or any other
 theoretical forks a file may have.  For those who believe no one uses
 resource forks, just look at Safari's in-progress downloads and Finder
 clippings.
 
 On 04/14/2011 11:26 AM, Laurent Daudelin laur...@nemesys-soft.com
 wrote:
 
 Is it normal that NSFileManager's isDeletableFileAtPath: returns YES for
 a locked file? Based on the result it returns, when I try to send it a
 removeItemAtPath:error:, it fails and the error localized description is
 '³This is a test.docx² couldn¹t be removed because you don¹t have
 permission to access it.'. That seems wrong to me. First,
 isDeletableFileAtPath: shouldn't return YES for a locked file.
 

Yes, I did notice that, Gary. Not sure how convenient a method that returns yes 
when you can't do the operation can really be, but I duly notice your comment.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa witch's broom

2011-04-14 Thread Shawn Erickson

On Thu, Apr 14, 2011 at 11:52 AM, Rodrigo Zanatta Silva
rodrigozanattasi...@gmail.com wrote:
 lol, bad english.. I mean use it.

 Use it is rare too? You can do a dynamic format to create a string.

Using format strings to create human viewed strings is very common and
in fact the best way to create such strings when considering
internationalization / localization.

-Shawn
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?

2011-04-14 Thread Quincey Morris

On Apr 14, 2011, at 12:35, Laurent Daudelin wrote:

In my app, I want to provide file operation but try to restrict them if
they're going to fail. I still handle the failures in my code but I feel it's
a better user experience that they know in advance, for example, that a file
is locked and thus I won't be able to delete it or replace it.

I'm wondering about the intent of this thread, though.

If you're just venting, then I guess go ahead. Some of us will probably feel
your pain. Given that this is a technical list though, it would be nice if such
venting posts were limited to one per customer.

If you're raising a technical point, then the real question is: what is the API
contract for 'isDeletableFileAtPath:'? The answer to *that* comes only from the
documentation. This thread finally drove me to go look, and it says
(http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html):

Return Value
YES if the invoking object appears able to delete the file specified in path,
otherwise NO. If the file at path does not exist, this method returns NO.

Discussion
For a directory or file to be able to be deleted, either the parent directory
of path must be writable or its owner must be the same as the owner of the
application process. If path is a directory, every item contained in path
must be able to be deleted.

It seems to me that this is giving you fair warning that the concept of
deletability is vague. The only specific promise relates to the writability of
the enclosing directory. Everything else is hedged behind appears to be able.
It's possible that the writability of the enclosing directory is the *only*
thing it checks.

The other place to look is the header file (NSFileManager.h) which (in the 10.6
SDK) has this comment preceding the method in question:

The following methods are of limited utility. Attempting to predicate
behavior based on the current state of the filesystem or a particular file on
the filesystem is encouraging odd behavior in the face of filesystem race
conditions. It's far better to attempt an operation (like loading a file or
creating a directory) and handle the error gracefully than it is to try to
figure out ahead of time whether the operation will succeed.

So, the API contract appears pretty clear that the definition of deletability
is pretty vague, intentionally to some degree.

If you think that the API actually does something different from what's
documented, your only recourse is to submit a bug report.

If you think that the API should do something different from what's documented,
your only recourse is to submit a bug report.

There's one thing that's NOT going to happen, though: No Apple engineer is
going to read this thread, smack himself/herself on the forehead exclaiming,
Oh, I see what this API should really have been designed to do! and go change
the API.

So by all means vent, if that helps, but you've already found your technical
answer: that 'isDeletableFileAtPath:' isn't the solution to the deletability
check you wish to make.

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: UIViewControllers being reloaded on didReceiveMemoryWarning... ?

2011-04-14 Thread Martin Linklater

Thanks for the help guys. That makes a lot of sense now.

On 14 Apr 2011, at 01:53, Matt Neuburg wrote:

 On Wed, 13 Apr 2011 16:42:40 -0700, Chris Parker c...@apple.com said:
 2011-04-14 00:03:09.640 CRDev[18309:307] InGameViewController 
 implementation of -viewDidUnload caused the view to be reloaded. This will 
 adversely impact system performance.
 
 The log is trying to help you out; -viewDidUnload is called when the view 
 controller has discarded its view. The log is telling you that an 
 implementation of -viewDidUnload is causing the view to be loaded again.
 
 This can be caused by doing anything which accesses the -view property on 
 the view controller inside the -viewDidUnload implementation.
 
 That's really kind of wonderful.
 
 In my iOS book I talk about discovering that my loadView was being 
 mysteriously called twice, and then (by logging like crazy) realizing that 
 this due to my mentioning the view property in my awakeFromNib. That's how I 
 learned not to do that. :) I really applaud verbose explanatory log messages 
 from the framework such as this. m.
 
 --
 matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
 A fool + a tool + an autorelease pool = cool!
 Programming iOS 4!
 http://www.apeth.net/matt/default.html#iosbook___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/mslinklater%40gmail.com
 
 This email sent to mslinkla...@gmail.com

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Anybody using NSFileManager here?