Re: Memory management about async object

[Steve Sisak]

There's some good information on this in TechNote 2009



Also, here is some sample code you might find very helpful:



as it does almost what you're describing.

HTH,

-Steve



At 5:28 PM +0800 12/28/10, ico wrote:

Hi Stephen,

Thanks for your reply, so there is no any perfect solution for this kind of
problem?
And can you give me a specific example to demonstrate why why it is not safe
to
release these async objects inside a callback method and why not safe to
autorelease it?
Thanks.

___

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

Please do not post 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: Asynchronous Notification Does NOT Work

[Steve Sisak]

At 3:45 AM +0800 6/6/11, Bing Li wrote:

In this case, notification might occur among two threads and both of them
are not the main thread. I think I can use synchronous notification and
threading together to replace asynchronous notification. How to you think
about that?


I suspect the problem is that your RunLoop is not being run, but WAYRTTD?

If you're trying to get messages processed on a specific 
thread/RunLoop and you're starting fresh, I'd highly recommend 
reading TN2109, which describes a really clean way to do it:




(Works on iOS or Mac OS X)

Then steal QRunLoopOperation out of the LinkedImageFetcher sample -- 
read the comments to see how hard this is to do right.


HTH,

-Steve
___

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

Please do not post 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: recomendations for creating a beta with date to expire

[Steve Sisak]

At 8:35 AM -0600 8/15/11, Scott Ribe wrote:
Generally, but closed betas are the one case where expirations 
really make sense. It is after all a beta, and you do not want 
someone still running the beta a year after the actual release, just 
because the person who was your contact for testing forgot where all 
he installed it.


I'm had good luck just using a dumb date check and telling users they 
can set their clock back to get around it if need be.


My goal to force users to test new betas rather than use the first 
one that works for them and to prevent having to support old betas 
left in the field.


(I have had bugs introduced late in the beta cycle ship because no 
one was testing the later betas)


-Steve
___

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

Please do not post 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: Task dispatching

[Steve Sisak]

At 2:39 PM -0600 9/13/11, Scott Ribe wrote:
\Note that your disk is not really providing 1.25GB/sec reads. What 
was probably happening is that the file contents were in system 
cache because of your prior reads. (Assuming that with the mmap code 
you were actually reading all the data...)


Actually, I believe that mmap just maps the the file into memory 
using the VM system -- it's initially paged out and read in as each 
page is touched.


This means you take the equivalent of a VM page miss the first time 
you touch a page but:


1) You also never read in pages that aren't touched (if your array is sparse)
2) Multiple process will share the same copy of the file in RAM
3) Page outs are "free" because the memory is backed by the file
4) Pages are read efficiently and don't pollute the FS cache

So, this is a very efficient way to handle a large data set.

BTW, if I were writing new code, I'd probably use NSOperation or 
dispatch queues and a single process.


Check out Quinn's QHTTPOperation sample code.

HTH,

-Steve
___

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

Please do not post 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: Retain/Release and Properties clarification

[Steve Sisak]

At 10:14 AM -0400 10/3/11, John Tsombakos wrote:
@interface AudioPlayerViewController : UIViewController {
AVAudioPlayer *audioPlayer;
}
@property (retain) AVAudioPlayer *audioPlayer;

In the .m file:
@synthesize audioPlayer;
in viewDidLoad:
audioPlayer = [self getSoundFile:"soundfile.wav"];


You got close with:


(side note... should that be self.audioPlayer = ... ? I keep getting
confused with accessors vs. ivars too ;) )


You do, indeed want:

self.audioPlayer = [self getSoundFile:"soundfile.wav"];

or

[self setAudioPlayer = [self getSoundFile:"soundfile.wav"]];

Without the self. you're bypassing the setter (which is responsible 
for retain/release) and just setting the instance variable directly. 
Therefore there's no retain.


This is one reason it's useful to use a different name for the 
instance variable than the property -- say _audioPlayer with


@synthesize audioPlayer = _audioPlayer;

In this case,

audioPlayer = [self getSoundFile:"soundfile.wav"];

now uses the setter and

_audioPlayer = [self getSoundFile:"soundfile.wav"];

accesses the instance variable directly (no retain), (hopefully) 
making the code more explicit preventing errors as you have to be 
explicit to access the instance variable directly.


HTH,

-Steve
___

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

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

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

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

Re: How to draw over a control in an NSView

[Steve Sisak]

At 7:09 PM -0700 10/30/11, Ken Ferry wrote:

On Oct 30, 2011, at 2:06 PM, Jens Alfke  wrote:
 > On Oct 30, 2011, at 12:46 PM, Alexander Reichstadt wrote:
 > Subviews are always drawn after their superview, so they are 
visually in front of it. You can't change that.
 > What you can try is adding a subview, positioning it over the 
control, and putting it in front (I think that means later in the 
subviews array.) Historically AppKit hasn't handled overlapping 
sibling views, but I think that nowadays if you make the parent view 
layer-backed it will work.


That's actually slightly reversed. AppKit has supported overlapping 
sibling views since 10.5. Layers complicate the story a bit, because 
a non-layer backed view can never draw over top of a layer.


Since I happen to be reading the Cocoa View Programming Guide at this 
instant, I'll mention that it currently says:


Note: For performance reasons, Cocoa does not enforce clipping among 
sibling views or guarantee correct invalidation and drawing behavior 
when sibling views overlap. If you want a view to be drawn in front 
of another view, you should make the front view a subview (or 
descendant) of the rear view.




It sounds like this section should be updated to reflect current reality.

It might be worth someone submitting a documentation bug on this.

HTH,

-Steve
___

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

Please do not post 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: Exceptions and autorelease pools

[Steve Sisak]

At 3:59 PM -0600 12/6/11, Ken Thomases wrote:
The workaround is necessary because the exception object raised in 
allocAndRaise() has been autoreleased.  It is no longer owned by 
anything and is only still around because the pool containing the 
pending release(s) has not been drained.  When you drain it, that 
executes the pending release(s) and ultimately deallocates it.


That is one of the reasons you are discouraged from 
releasing/draining autorelease pools in exception handlers or 
@finally blocks.


Ken,

Thanks -- that's something that never occurred to me and makes total 
sense given your explanation.


This leads to a follow-on question regarding operations as outlined 
in listing 2-3 on:




Implementations of [NSOperation main] are required to not throw exceptions.

The boilerplate code given is:

-(void)main {
   @try {
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

  // Do some work on myData and report the results.

  [pool release];
   }
   @catch(...) {
  // Do not rethrow exceptions.
   }
}

on my first read, it looked like it leaked and now I know why it 
doesn't leak that much. :-)


I realize that this is moot in the case of @autorelease, but in the 
context of "best practices" for code that can't depend on ARC, I 
still wonder if something like this is a cleaner solution:


-(void)main {
   NSAutoreleasePool* pool = nil;
   @try {
  pool = [[NSAutoreleasePool alloc] init];

  // Do some work on myData and report the results.

  [pool release];
   }
   @catch(...) {
  // Do not rethrow exceptions.
   }
   @finally {
   [pool drain];
   }
}

(Where code which could re-throw could implement the same workaround 
an set pool to nil and I assume we should be catching C++ exceptions 
as well)


Given that operations have much shorter lifespan than threads, I'd 
worry about the leaked NSAutoreleasePool objects in a long-running 
application.


Thoughts? Comments? Suggestions?

-Steve
___

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

Please do not post 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: __PRETTY_FUNCTION__.219635

[Steve Sisak]

At 12:11 PM + 12/24/11, Peter Hudson wrote:
I have been making a few ( trivial ) changes to some code and when 
the app runs it grinds to a halt with an
Objective-c exception and the next to last item on my stack is


__PRETTY_FUNCTION__.219635


IIRC, you'll get an exception if you accidentally use 
__PRETTY_FUNCTION__ in C function and maybe in a class (+) method 
(i.e. copy an NSLog call).


I got bit by this once and fact I got a runtime exception rather than 
a compile error was a complete surprise to me.


HTH,

-Steve
___

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

Please do not post 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: Static variables reset inside CFPlugin code

[Steve Sisak]

At 9:47 AM -0500 1/2/12, Grandinetti Philip wrote:
So, I can't really define the static variable pointing to my library 
in the plugin.It needs to be defined in the library that handles 
all the SI units.


Hi Philip,

This is dusting off brain cells that I haven't used in awhile but, 
assuming all the plugins run only in your application, you could put 
all of the code/data shared by the plugins into a framework that 
resides in your application bundle.


Your application and your plugins then link against this framework.

You could use either CFPlugin or NSBundle as Chris suggests.

The tough part here is all the Xcode magic to get the targets set up 
correctly -- I'm currently working out something similar, and will 
post results.


If someone has a recipe for setting this up in Xcode 4 and would be 
willing to post it, I'd be interested as well.


HTH,

-Steve
___

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

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

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

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

Re: How to get the dispatch queue for the current thread's runloop?

[Steve Sisak]

At 12:14 PM -0800 1/27/12, Jens Alfke wrote:
I'm really used to using 
-performSelector:withObject:afterDelay: to make 
something happen later. But I'd much rather use 
a block than a target/action. I can't find any 
API for this, however. Am I missing something? 
What I want is basically like

PerformBlockAfterDelay(^{ Šcode hereŠ}, 5.0);


Me too! PerformBlockOnThread would be nice as well.

It looks like I should just call dispatch_async, 
but I'm unsure which dispatch queue to use. 
dispatch_get_main_queue only works for the main 
thread. Can I use dispatch_get_current_queue?


As others have mentioned later in the thread, 
with the exception of the main queue, dispatch 
queues aren't tied to threads -- they execute 
blocks on a pool of threads managed by the system.


Later in the thread:

At 6:00 PM +1100 1/28/12, Shane Stanley wrote:

On 28/01/2012, at 1:41 PM, Ken Thomases wrote:


 Believe it or not, this also works:

 >[(id)^{ ... code here ... } 
performSelector:@selector(invoke) withObject:nil 
afterDelay:5.0];


 That is, you can target 
performSelector:withObject:afterDelay: at a 
block, itself, rather than some other helper 
object.  And, a block implements the -invoke 
selector to, well, invoke itself.


FWIW, on stackoverflow there's a post suggesting 
the use of a block as a target, and using 
-invoke to select it. In the comments is one 
from bbum from last October:


 This "works" by coincidence. It relies on 
private API; the invoke method on Block objects 
is not public and not intended to be used in 
this fashion.


, 
about fourth answer down.


This reminds me that, IIRC, a block (after it's 
copied to the heap) _is_ an object. I was going 
to suggest some form of calling BlockCopy 
manually, but given the example above, you might 
something like:


-(void)executeBlock:((^)(void) block  // <- someone help with this declaration
{
  block();
}

...

[self performSelector:@selector(executeBlock:) 
withObject:(id)^{ ... code here ... } 
afterDelay:5.0];


might work.

I'm still trying to get my head around all these 
issues as well, but hoping this might help you to 
a solution. I'm interested in the solution as 
well.


HTH,

-Steve


___

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

Please do not post 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 get the dispatch queue for the current thread's runloop?

[Steve Sisak]

At 12:14 PM -0800 1/27/12, Jens Alfke wrote:
I'm really used to using -performSelector:withObject:afterDelay: to 
make something happen later. But I'd much rather use a block than a 
target/action.


At 12:23 PM -0500 1/28/12, Steve Sisak wrote:
This reminds me that, IIRC, a block (after it's copied to the heap) 
_is_ an object. I was going to suggest some form of calling 
BlockCopy manually, but given the example above, you might something 
like:


-(void)executeBlock:((^)(void) block  // <- someone help with this declaration
{
  block();
}


This was interesting enough to stick my head in the documentation and 
build a test program.


The following appears to work:

- (void)performBlock:(void (^)(void)) block
{
block();
}

- (IBAction) doItNow:(id)sender
{
[self performSelector:@selector(performBlock:) withObject:^{
NSLog(@"Done");
}];
}

- (IBAction) doItLater:(id)sender
{
[self performSelector:@selector(performBlock:)
   withObject:^{
NSLog(@"Done Later");
}   afterDelay:1.0];
}

Does anyone see a problem with this technique?

-Steve
___

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

Please do not post 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 get the dispatch queue for the current thread's runloop?

[Steve Sisak]

At 12:39 PM -0800 1/28/12, Jens Alfke wrote:

On Jan 28, 2012, at 11:35 AM, Steve Sisak wrote:


[self performSelector:@selector(performBlock:)
   withObject:^{
NSLog(@"Done Later");
}   afterDelay:1.0];



Don't you need to copy the block? Or is 
-performSelector:withObject:afterDelay: smart enough to know to call 
-copy instead of -retain on the block?


My understanding is that copying the block happens implicitly when 
you call a function which takes a block as a parameter and doesn't 
return synchronously -- and/or it's the callee's responsibility to 
copy the block if it doesn't call it synchronously.


I would not be surprised if calling retain on a block passed as an 
(id) does this as a side effect. (Sorry, I don't know the exact 
implementation details)


Also, I'm not entirely happy with this solution because it's tied to 
an object when it shouldn't need to be.


Agreed -- just trying to find a way to solve the problem with the API 
available.


So your -doItLater: method only works in the class you declare it 
in, and it has the side effect of keeping the receiver alive until 
the block runs, even if it doesn't need to be (i.e. if the block 
doesn't refer to 'self' at all.)


You (theoretically) could use any object which implements 
-performBlock: as the target -- for instance you could have a 
singleton BlockServer object which implements -performBlock: and use 
that for the target of all requests.


Someone else had a solution that involved adding a category method 
to NSObject to invoke the block, but that seems a bit kludgy too.


That would also work -- and you'd need to worry about collisions in 
Obj-C's flat name space.


I'm still trying to figure this all out and poke around the boundary 
conditions too. I'd love to hear from "someone who 'knows'". :-)


-Steve
___

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

Please do not post 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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Steve Sisak]

At 1:40 PM -0700 3/14/12, JongAm Park wrote:

On 3/14/2012 10:27 AM, Scott Ribe wrote:

On Mar 14, 2012, at 11:23 AM, JongAm Park wrote:


it didn't sound harsh in a jungle with full of male creatures.

LOL! And you said your English was not so good. That was great!

Well, I was not born in English-speaking country. So, sometimes my 
English can sound (very) abnormal and sometimes doesn't follow your 
culture, etc. So, it's possible that I don't catch your idea or 
doesn't express my idea culturally correctly.


This conversation is a really great example of cross-cultural humor.


I apologize if I made you feel bad.


Actually, I think Scott was paying you a compliment(!), but stated it 
in an indirect way that didn't translate back. (Sarcasm/subtlety 
doesn't translate well)


Not being a native speaker, you described the situation in a way that 
no native (US) English speaker would but I'm quite sure everyone 
understood.


It was funny because it was far more direct and astute description 
than a native speaker might have used (or have gotten away with).


I think what Scott was saying was that you described the situation so 
well that your English is far better than you're giving yourself 
credit for -- no apology needed -- you played the "not a native 
speaker" card well.


I got a good laugh too!

Best,

-Steve
___

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

Please do not post 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: Strange Analyser Warning/Error

[Steve Sisak]

On Feb 8, 2016, at 10:01 AM, Ken Thomases  wrote:
>>> 
>>> In the case where you do not see a warning, you are calling -[NSDictionary 
>>> objectForKey:] which accepts a nil key value (returning nil).
>> 
>> Ah, for some reason I thought that is was illegal to pass a nil key to 
>> objectForkey:
> 
> It is illegal.  Michael is incorrect.  In general, when a method accepts an 
> object pointer argument, it is illegal to pass nil unless it's specifically 
> documented to be legal.

The nil key pointer is a red herring. -[NSDictionary objectForKey:] can return 
nil if the dictionary doesn’t contain a value for the key.

The analyser is correctly flagging that the code doesn’t handle this case.

I suspect the reason that this started recently is that Apple recently started 
annotation the Cocoa headers as to what can and can’t accept/return nil in 
support of Swift.

HTH,

-Steve
___

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

Please do not post 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: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?

[Steve Sisak]

> On Mar 4, 2016, at 4:14 PM, Alex Zavatone  wrote:
> 
> I'm working with PJSIP and PJ's docs clearly state, "we are going to crater 
> unless you do everything SIP related on the main thread."

Ugh. And of course, doing networking on the main thread is a no-no according to 
Apple.

——

First, it might be worth seeing if you can have a PJSIP queue (preferred) or 
thread, which isn’t the main thread — if there are no locks in PJSIP, but it 
doesn’t use thread-local storage, then it only need to be protected from 
reentrancy — then you can just make all your PJSIP calls from blocks wrapped in 
dispatch_async on the PJSIP queue. Thread-local storage complicates this. But I 
digress…

——

How is the storage of your C strings allocated? malloc()?

What I’d do is use CFString (from CoreFoundation, which is a C API and does all 
the right callback stuff) and take advantage of the fact the CFString is 
toll-free bridged to NSString.

Now your C code returns a CFString (C API) which can be cast to NSString as 
soon at it hits Obj-C code.

HTH,

-Steve



___

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

Please do not post 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: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)

[Steve Sisak]

This thread seems to have gone off into the weeds by way of tortured analogy. 
;-)

Going back to the OP’s question

> On Aug 11, 2016, at 2:32 AM, Sasikumar JP  wrote:
> 
> what was the reason NSNumber conforms to NSCopying protocol.
> 
> NSNumber is immutable class, Making a copy of NSNumber object returns the
> same reference.

There’s a standard idiom where immutable classes frequently have mutable 
subclasses (which expose the mutating methods).

In this case, it’s common for the immutable (super)class to adopt NSCopying and 
the mutable subclass to also adopt NSMutableCopying.

This way if you want to add an object to a collection, calling -copy has the 
effect of freezing the current value — the immutable class can optimize this by 
just returning a new reference to the same object, but the caller doesn’t have 
to know whether the object was immutable or a mutable subclass.

> Is there any case where NSNumber returns the new object? if not, then what
> is the purpose of conformance to NSCopying protocol.


NSString/NSMutableString is probably easier to get your head around — then just 
understand that NSNumber repeats the pattern for consistency.

For instance, NSDictionary “copies” keys to keep them from changing (which 
would be bad for hopefully obvious reasons).

HTH,

-Steve

___

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

Please do not post 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: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)

[Steve Sisak]

"On Aug 11, 2016, at 9:04 PM, dangerwillrobinsondan...@gmail.com wrote:
>> On Aug 12, 2016, at 9:16 AM, Steve Sisak  wrote:
>> 
>> There’s a standard idiom where immutable classes frequently have mutable 
>> subclasses (which expose the mutating methods).
>> 
>> In this case, it’s common for the immutable (super)class to adopt NSCopying 
>> and the mutable subclass to also adopt NSMutableCopying.
>> 
>> This way if you want to add an object to a collection, calling -copy has the 
>> effect of freezing the current value — the immutable class can optimize this 
>> by just returning a new reference to the same object, but the caller doesn’t 
>> have to know whether the object was immutable or a mutable subclass.
> 
> Almost.  
> 
> The design pattern for this is the class cluster. 
> Where the public interfaces may produce private subclasses that handle and 
> respond appropriately to the messages that make them one or the other.

Actually, to be pedantic, class cluster is an implementation detail — was 
trying to impedance match to OP’s experience level.

Was speaking purely in terms of public interfaces (since he’s a consumer rather 
than implementor).

-Steve
___

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

Please do not post 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: What's the difference between [NSOperationQueue currentQueue] and performSelectorOnMainThread (iOS platform)

[Steve Sisak]

At 3:58 PM +0800 2/4/13, õöâ¿ôb wrote:

Thanks Mike seem You are right, and I write like this

[self performSelector:@selector(doTheThing) withObject:nil afterDelay:0.5];
it can work correctly.

And thanks for your suggestion


I suspect that if you change


 > >//Case 3 hang up, HUD not show

 >

 > >//[self performSelectorOnMainThread:@selector(doTheThing)
 > > withObject:nil waitUntilDone:YES];


to ... waitUntilDone:NO... it will work as well.

It's hard to tell what's going on without looking 
at more of your code, but this smells a lot like 
a thread deadlock.


if you're using a lock to protect data shared 
between your UI and background task and were 
holding it when you called 
performSelectorOnMainThread: that's likely the 
source of the deadlock.


(Your main thread code won't run until you 
release the lock and you can't release the lock 
while you're blocked waiting for your main thread 
code to complete)


It also may be necessary for your main even loop 
to run a couple times before the HUD does 
anything.



 > It seems you need to take the time to learn a little about how
 > multithreading works and should be used with Cocoa.


If you haven't already, read the Concurrency Programming Guide:



this is a good place to start.

HTH,

-Steve

___

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

Please do not post 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: What's the difference between [NSOperationQueue currentQueue] and performSelectorOnMainThread (iOS platform)

[Steve Sisak]

At 8:13 AM -0800 2/5/13, Glenn L. Austin wrote:
I understand the *reasoning* behind 
performSelector:withObject:afterDelay:, but I've banned that from 
code I work on.


In the OP's case, I think he just needs to perform the selector 
asynchronously so he doesn't deadlock -- waitUntilDone:NO ought to be 
sufficient.


I agree on "magic numbers", but needing to be async is a classic 
threading "gotcha".


BTW, performSelector:withObject:afterDelay: makes total sense for 
retry logic in order to avoid hogging resources.


-Steve
___

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

Please do not post 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: [OT] Sync vs ASync Server Comms

[Steve Sisak]

At 12:26 PM + 2/24/13, Dave wrote:
I think I see what you mean, but I'd argue that there are still 
"threading" issues, the OS will create the Background Threads and 
take care of calling you back on the main thread, I agree, and, if 
that's all you were doing, it might be said to have "No Threading 
Issues", but, for instance, if the first ASync call, needs data to 
use on a later call, then there may well be "Threading Issues". 
Example 1:


Kick off ASync Operation A to get DataA.
Kick off ASync Operation B to get DataB.
Kick off ASync Operation C using DataA and DataB - You need to 
"worry" about "threading" (or at least the consequences of threading 
at this point).


Just to be pedantic, that's a dependency issue but, since the async 
operations always complete on the main thread (or the thread you told 
them to), you don't have to worry about being interrupted while 
manipulation the results.


In the case above, you issue operations A and B, cache the results as 
they come back, and as soon as you have both, kick off operation C.


...or you can just use NSOperation, set up your dependencies, and let 
the OS do it:


Created A, B, C, make C dependent on A, B, submit all of them to an 
NSOperationQueue and wait for C to complete (or put your completion 
code on a block dependent on C -- NSBlockOperation makes this really 
easy.


See the Concurrency Programming Guide:



Note that most of this discussion is covered in it.

In fact, I'd argue that using Sync on a user created Background 
thread would after a very small learning curve, actually result in 
less "Threading" issues but may well suffer performance wise. For 
instance in pseudo code, Example 1 would look something like:


You have something which looks like a "simple learning" curve until 
you start getting in uncomfortable places.


For a good example of async operations, look at the LinkedImageFetcher sample:

http://developer.apple.com/library/mac/#samplecode/LinkedImageFetcher/Listings/Read_Me_About_LinkedImageFetcher_txt.html

If you want to see how hard the threading issues really are, read the 
comments in QWatchedOperationQueue.m -- fortunately, you don't have 
to write this, you can just use it.


Also, you don't have to do everything on the main thread -- I 
frequently use a (single) background server thread which sits in a 
runloop and do everything but the UI from there.


This keeps both you UI and engine responsive.

HTH,

-Steve


___

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

Please do not post 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: [OT] Sync vs ASync Server Comms

[Steve Sisak]

At 3:18 PM + 2/25/13, Dave wrote:

On 25 Feb 2013, at 13:57, Steve Sisak wrote:
Created A, B, C, make C dependent on A, B, submit all of them to an 
NSOperationQueue and wait for C to complete (or put your completion 
code on a block dependent on C -- NSBlockOperation makes this 
really easy.


This was just a simplistic example, unfortunately in real life it's 
not possible to use an Operation Queue effectively for what needs to 
be done, and, anyway, the code is much harder to read and maintain 
to use one.


Why? I use them for some very high performance stuff.

Also, you don't have to do everything on the main thread -- I 
frequently use a (single) background server thread which sits in a 
runloop and do everything but the UI from there.


This keeps both you UI and engine responsive.


Yes, that's basically the same conclusion I came to, but if do this, 
it negates a lot of the initial simplicity of using that approach, 
so, at that point it's a toss up on which method is preferable.


The current trend is away from threads and toward asynchronous programming.

That's orthogonal to whether your tasks are run on a single 
(XXRunLoop) or multiple (GCD) threads -- the advantage of GCD is that 
the system gets do decide how many worker threads to fire up based on 
the number of cores available, system load, and who's blocked.


NSOperationQueue adds dependencies -- you can do similar things with 
blocks and dispatch_groups.


If you don't like NSOperationQueue, go bare metal and use GCD directly.

I suggested NSOperationQueue because it's exactly the right tool for 
your example.


WAYRTTD?

-Steve
___

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

Please do not post 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: Core Data Reverse Engineering KickStarter Project

[Steve Sisak]

At 8:52 PM -0500 6/22/13, Charles Srstka wrote:
2. Since the format isn't published, there's no reason that Apple 
might make changes to it in the future,


I think you'll find that the reason Apple doesn't publish some 
specifications is specifically so they CAN change them w/o breaking 
3rd party applications.


A counter-example would be QuickTime which is (was) a bit too well 
documented to make the transition to 64-bit.


-

The safest thing to would probably to be to implement a Core Data 
"workalike" with a documented database schema and possibly an 
importer for "real" code data files.


HTH,

-Steve
___

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

Please do not post 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: static acting like __block in GCD singleton pattern

[Steve Sisak]

At 9:20 AM -0700 6/29/13, Matt Neuburg wrote:

On Jun 28, 2013, at 5:26 PM, Kyle Sluder  wrote:
 > On Fri, Jun 28, 2013, at 05:17 PM, Matt Neuburg wrote:

 Why is the block permitted to assign to the variable sharedInstance
 outside the block? Evidently it is because "static" has an effect like
 "__block", in that it makes the variable outside the block assignable.

 >> But how, exactly? Is it some kind of side effect of being a local static?
 >

 Consult the blocks spec for more:

 > http://clang.llvm.org/docs/BlockLanguageSpec.html

Yes, I looked at the spec and searched on the word "static" but I 
can't really understand what the spec is telling me.


Hi Matt,

Thanks for asking the question and getting me to read the spec -- 
I've been trying to get this straight in my own head as well.


I found this part of the spec pretty readable (it's the minutia about 
declarations that makes my eyes glaze over).


What I think you wanted to be searching for is the opposite of 
static: "automatic".


The magic 3 paragraphs are:

The compound statement body establishes a new lexical scope within 
that of its parent. Variables used within the scope of the compound 
statement are bound to the Block in the normal manner with the 
exception of those in automatic (stack) storage. Thus one may access 
functions and global variables as one would expect, as well as 
static local variables.


Local automatic (stack) variables referenced within the compound 
statement of a Block are imported and captured by the Block as const 
copies. The capture (binding) is performed at the time of the Block 
literal expression evaluation.


and

In addition to the new Block type we also introduce a new storage 
qualifier, __block, for local variables. The __block storage 
qualifier is mutually exclusive to the existing local storage 
qualifiers auto, register, and static.


Variables qualified by __block act as if they were in allocated 
storage and this storage is automatically recovered after last use 
of said variable.




Here's my shot at simple rules:

1) With the exception of automatic (stack-based) variables declared 
outside of a block and used within it, everything works the same as 
it always has.


2) __block variables act as if all copies of the block (and the 
original scope) share a reference to the variable which lives as long 
as the last copy.


3) The block's view of all non-__block automatic variables is 
read-only and frozen at the time that the block is declared.




I think that's sufficient.

Everything else is either an implementation detail or an optimization

So, to answer your original question: static falls within 1) and 
works the way it always has because it's not an automatic variable.


Rather than make this any longer, feel free to poke holes in the 
description -- I want to make sure I'm not missing anything.


HTH,

-Steve




___

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

Please do not post 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: Apple Developer Update

[Steve Sisak]

While I agree with you, I think it is also essential to keep a 
thread open to sort of discharge the overflow of emotional 
frustration - we're not Vulcans! :)


Here's a better forum for that:



:-)

___

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

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

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

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

Re: Observing Time

[Steve Sisak]

At 7:36 AM -0600 7/26/13, Scott Ribe wrote:

On Jul 26, 2013, at 7:06 AM, Ken Thomases  wrote:


 On Jul 25, 2013, at 11:37 PM, dangerwillrobinsondan...@gmail.com wrote:


 On Jul 26, 2013, at 12:09 PM, Ken Thomases  wrote:

 Also, the above code doesn't adjust the 
timer to fire on the second as Rick 
suggested.  You're asking it to fire every so 
many seconds (delayInSeconds) but you aren't 
specifying when during the second to fire. 
Rather than passing 0 as the second parameter 
of dispatch_walltime(), you should compute an 
adjustment to try to get close to a whole 
second.  Since dispatch_walltime() uses 
gettimeofday() when you pass NULL for the 
first parameter, I'd use that same call to 
fill in a timeval structure and then pass 
NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC) 
as the second parameter.


 Regards,
 Ken

 Thanks Ken, no I hadn't yet bothered to do 
this, as dispatch_walltime() was initially 
close enough to work on the other bits of the 
app.

 It would make a difference to reduce some lag.
 What is the part in the second parameter your are doing thereŠ

 NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC)

 Looks like something to adust it but what is tp.tv_usec ?


 > I hypothesized a struct timeval variable 
named "tp" that you passed to gettimeofday(). 
Then you would use the sub-second part (the 
tv_usec field) to figure out roughly how far off 
of a whole second dispatch_walltime() would be 
when passed NULL for the first parameter, since 
it will also use gettimeofday().


FYI, in the past, for a quick & dirty solution, 
I've just set a timer to fire every 0.1 seconds. 
Then in the handler you check if the second 
changed since the last time, and do nothing if 
it hasn't. This gets you updating that appears 
smooth to the user, unless the main thread 
spends too much time doing something and updates 
don't happen--and that's a problem that's 
outside the timers & clocks whose solution is 
not related to the timers and clocks, whose 
solution is of course "don't do that".


It's worth noting that's very energy inefficient.

Once the WWDC sessions are back on line, watch 
the energy efficiency sessions to see what's 
happening with timers in Mavericks.


For what the OP is doing, using NSTimer on the 
main event loop with an offset would be a good 
implementation -- it might take adjusting the 
offset to get the timer to fire a little early 
and/or accomodate the actual fire time in the 
code.


HTH,

-Steve



___

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

Please do not post 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: Observing Time

[Steve Sisak]

At 12:36 AM +0900 7/27/13, dangerwillrobinsondan...@gmail.com wrote:

On 2013/07/27, at 0:26, Scott Ribe  wrote:


 On Jul 26, 2013, at 8:13 AM, Steve Sisak  wrote:


 It's worth noting that's very energy inefficient.

 Once the WWDC sessions are back on line, watch
 the energy efficiency sessions to see what's
 happening with timers in Mavericks.


Good point. Though this timer is pretty little and the app wouldn't 
be doing a lot else.
But it stands to reason that it could be battery friendly to suspend 
it when the app is not visible. And to offer a battery power pref to 
suspend when it's not the front application.


(Without going into any system-specific details)

One of the biggest ways that current-generation processors conserve 
power is to power down parts of the chip that aren't currently in 
use, however the act of powering up and down takes time and wastes 
power.


If you have lots of timers going off, the OS still has to wake up the 
CPU to service the timer -- even if it's got nothing to do.


A savvy OS could conserve power by grouping timers together, so 
they're all handled during a single "wake-up" -- that saves all the 
power (and time) wasted in waking and sleeping parts of the CPU. It 
also increases the jitter in the timers.


By giving the OS good information on what you're trying to do, you 
give it flexibility to balance conserving power and provide accurate 
timing.


-

BTW, from the NSTimer reference:

https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html

A repeating timer always schedules itself based on the scheduled 
firing time, as opposed to the actual firing time. For example, if a 
timer is scheduled to fire at a particular time and every 5 seconds 
after that, the scheduled firing time will always fall on the 
original 5 second time intervals, even if the actual firing time 
gets delayed. If the firing time is delayed so far that it passes 
one or more of the scheduled firing times, the timer is fired only 
once for that time period; the timer is then rescheduled, after 
firing, for the next scheduled firing time in the future.


This means you ought to be able to set up a repeating 1 second timer 
with an initial delay calculated to make it go off at the "top of the 
second".


With any luck, you'll get serviced on the same wake-up as the menu bar clock.

In your case, a little jitter is only cosmetic -- if you do wander, 
it's because the CPU was busy. You also might want to check in your 
callback to see if you're too far off and reschedule if needed. Don't 
forget that timers get suspended during sleep.


If you're stuck, I could probably figure out how to do the same thing 
with Mach time.


HTH,

-Steve
___

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

Please do not post 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: Exiting non-POSIX threads?

[Steve Sisak]

At 11:34 AM +0300 7/29/13, Oleg Krupnov wrote:

However for GCD thread (created with dispatch_async()) I get the
following signal:

pthread_exit() may only be called against threads created via pthread_create()

Is there a way to handle this case?


Just return from the block you passed to dispatch_async()


Is there a way to exit a GCD thread?


There's no such thing as a "GCD thread" only queues.

(OK, there's a pool of threads that GCD uses to service queues, but 
you don't own them)



At least, is there a way of telling POSIX threads from GCD / other threads?


WAYRTTD?

Exiting threads is bad form in general -- if you're really writing an 
exception handler, catch it at the outermost level and just return so 
the thread terminates normally.


Same for your outer block in GCD.

HTH,

-Steve
___

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

Please do not post 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: Threaded drawing - JPEG

[Steve Sisak]

At 10:25 AM -0800 12/10/13, Seth Willits wrote:

On Dec 10, 2013, at 1:32 AM, Graham Cox  wrote:
 > But my situation is that I need to draw VECTOR objects up to 
25,000% zoom with no pixelization.


You're given a CGContext to draw into; What's the difference? The 
tiled drawing is async, so if the drawing doesn't occur fast enough 
it'll scale up the low-scale bitmap, but what's evil about that? 
It's like Apple or Google maps.


Not to hijack the thread, but I'm just getting head into optimizing 
some code which displays live preview for a number of JPEG streams 
simultaneously.


Most implementations I've tried result in being CPU bound in JPEG 
code on the main thread with the 7 other cores idle.


I've tried variants of NSImageView, CGImage and CIImage and all 
that's needed to render them on alternate threads but Cocoa appears 
to so good at delaying evaluation as long as possible that it seems 
to end up calling the JPEG decoder synchronously from -drawRect of 
whatever view subclass I've chosen on the main thread.


Any suggestions for what technologies to use to run a JPEG through, 
say CIImage w/o blocking the main thread.


This has turned out to be way more complicated than I thought.

Thanks,

-Steve
___

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

Please do not post 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: Mod (%) function in C/Objective-C?

[Steve Sisak]

At 3:24 PM -0600 8/11/14, Scott Ribe wrote:

On Aug 11, 2014, at 3:03 PM, Dave  wrote:
The first edition of K&R mistakenly referred to it as modulus 
(apparently based on the PDP-11 instruction which was similarly 
misnamed).


When in doubt, remember what C was designed to be:

Machine independent PDP-11 assembly language.

;-)
___

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

Please do not post 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: asynchronous nsurlconnection in nsoperation

[Steve Sisak]

At 6:59 PM +0300 3/21/12, Ariel Feinerman wrote:

I wish to insert an asynchronous NSURLConnection into non-concurrent
NSOperation the reason is to allow necessarily unarchive actions on 
the streaming date so


Look at (and steal code from) the LinkedImageFetcher sample:



I'm pretty sure if you steal the Core Code directory, and subclass 
QHTTPOperation, that ought to do pretty much what you want.


HTH,

-Steve
___

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

Please do not post 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 throttle rate of NSInputStream?

[Steve Sisak]

At 10:36 PM +0100 3/27/12, jonat...@mugginsoft.com wrote:
You probably already have this sorted but it occurred to me that 
when you receive NSStreamEventHasBytesAvailable you don't have to 
read the data there and then.


Quinn (DTS) gave Jens the following complete answer on 
macnetworkp...@lists.apple.com:


At 8:52 AM +0100 3/27/12, Quinn \"The Eskimo!\" wrote:

On 26 Mar 2012, at 21:28, Jens Alfke wrote:

 What can I do about this? Ideally I'd like the stream to hold off 
on reading more from the socket until my code finishes processing 
the buffer..


If you don't call -read:maxLength:, the stream won't send you 
another NSStreamEventHasBytesAvailable event.  So you can handle 
this case by:


on NSStreamEventHasBytesAvailable
  if we're still processing a buffer
set a flag indicating that data is available
  else
read and start processing a buffer
  end if
end

on bufferProcessingDone
  if we ignored a NSStreamEventHasBytesAvailable event
read and start processing a buffer
  end if
end

Obviously the buffer processing will need to be async (either via an 
NSOperation or GCD), and you should organise to call 
-bufferProcessingDone back on the main thread.


Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


Seems this should be shared here as well.

HTH,

-Steve
___

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

Please do not post 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: NSInteger vs int vs int32_t

[Steve Sisak]

At 10:05 AM -0600 7/5/12, Scott Ribe wrote:
And theoretically, moving from 32-bit to 64-bit executable could 
slow you down because of fewer pointers fitting in cache--however 
the few people I've ever heard mention that were, in my opinion, 
seriously overblowing it. In my experience with data & algorithm 
heavy code, just switching from 32- to 64-bit produces about a 10% 
performance boost, because of the advantages of x86-64 (more 
registers and so on).


Now you may be getting to the crux of the matter:

For a processor family with reasonably clean 32- and 64-bit models 
(i.e. PowerPC) going to 64-bit is a speed hit in many circumstances 
due to the increase in size of everything.


However, i386 has so much baggage and so few registers that the 
performance gain from x86-64's much less sucky architecture/runtime 
more than makes up for the loss due to memory bloat.


;-)

-Steve

___

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

Please do not post 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: Network and DarkWake

[Steve Sisak]

At 9:42 AM -0400 8/31/12, Alex Zavatone wrote:

Well, I've never seen Macs wake themselves from sleep before when closed.

I'll make sure I keep my laptop open as I go on the commute (sarcasm).


Taking the serious side of this -- I have had multiple generations of 
Mac laptops wake up in my bag and get hot.


The cause seems to be that if there is enough vibration to trip the 
lid sensor, the Mac decides it's open and wakes up.


The workaround is to diable wake on open (I forget where the setting 
is), making it necessary to hit a key after opening to really wake 
the machine.


Never had a problem since.

HTH,

-Steve
___

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

Please do not post 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: Ordering of Completion Handlers

[Steve Sisak]

At 10:08 AM +0200 8/31/12, Andreas Grosam wrote:
I have a number of operations that will be received serially. Each 
operation can be processed concurrently with respect to each other. 
I would like to invoke the completion blocks for each operation in 
the order as they have been received.


I'm searching a simple approach to achieve this, implemented using 
NSOperationQueue, NSOperation and dispatch lib.


Check out the LinkedImageFetcher Sample:




This is a class utilizing NSURLConnection which can handle 
multipart/x-mixed-replace Content-types. For each part, a completion 
block will be invoked passing the corresponding response and the 
result of the corresponding data processor.


I have some improvements to the Apple code for this -- contact me off 
list if needed.


-Steve
___

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

Please do not post 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

[Steve Sisak]

At 7:56 PM +0700 11/12/12, Gerriet M. Denkmann wrote:

- (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;
}


Here's what I usually do:

assume that _someDictionary is an instance variable initialized to 
nil and never changed once initialized to non-nil


- (NSDictionary *)someDictionary;
{
  if (!_someDictionary)
  {
@synchronized (self)
{
  if (!_someDictionary)
  {
// create a temp dictionary (might take some time)
 _someDictionary = temp;
  }
}
  }

  return _someDictionary;
}

the outer if avoids the overhead of @synchronized if _someDictionary 
is already created -- this is just an optimization


the inner if is necessary to resolve the race condition if multiple 
threads make it past the outer one


HTH,

-Steve
___

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

Please do not post 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

[Steve Sisak]

At 8:57 PM -0600 12/7/12, Ken Thomases wrote:
 > the outer if avoids the overhead of 
@synchronized if _someDictionary is already 
created -- this is just an optimization


 the inner if is necessary to resolve the race 
condition if multiple threads make it past the 
outer one


This is a classic anti-pattern called 
double-checked locking.  It is not safe.  Don't 
rely on it.

https://en.wikipedia.org/wiki/Double-checked_locking
http://erdani.com/publications/DDJ_Jul_Aug_2004_revised.pdf


Hi Ken,

From the first link you cite:

The pattern, when implemented in some 
language/hardware combinations, can be unsafe. 
At times, it can be considered an 
anti-pattern.[2]


That is far different from being a "a classic anti-pattern".

In this example:

1) The language is Obj-C
2) I explicitly used @synchronized(self) and an instance variable

So, in this case, what I'm doing is explicitly supported by the language.

Your second article is explicitly focused on C++ 
(and singletons) -- it's also dated 2004.


On Mac OS X, the correct implementation of a 
singleton is dispatch_once() -- in fact, that is 
the function's raison d'être.


So, while I support the position that 
double-checked locking can be unsafe in con 
language/hardware combination, in this case we're 
using language features specifically designed for 
the purpose.


That said, it's worth noting that you need to 
understand your complier when dealing with 
synchronization.


I'm interested if there are an any issued I'm 
missing in the Obj-C, @synchronized(self), 
instance variable case.


-Steve



___

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

Please do not post 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

[Steve Sisak]

At 8:35 AM -0800 12/8/12, Kyle Sluder wrote:

On Dec 7, 2012, at 8:38 PM, Marco S Hyman  wrote:


 On Dec 7, 2012, at 8:18 PM, Steve Sisak  wrote:

 I'm interested if there are an any issued I'm missing in the 
Obj-C, @synchronized(self), instance variable case.



 Your pattern can fail if this line
_someDictionary = temp;
 isn't atomic.


The real issue with double-checked locking is whether the compiler 
promises to generate the proper memory barriers such that other 
threads are guaranteed to see the assignment to _someDictionary 
*after* the object has been constructed. C makes no such guarantee; 
other threads might see a non-nil value for _someDictionary before 
the first thread is done constructing the object.


I'm fairly sure that @synchronized, being a compiler built-in, rather 
than a function, makes that guarantee -- specifically the the values 
of instance variables can change across entry and exit of an 
@synchronized block.


Further, if writes were not complete at the end of the block, the 
construct would be essentially useless for its intended purpose.


In any case, removing the outer check makes the code correct 
regardless of compiler guarantees.

___

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

Please do not post 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

[Steve Sisak]

At 10:24 AM -0800 12/8/12, Kyle Sluder wrote:

On Dec 8, 2012, at 10:06 AM, Steve Sisak  wrote:

 > Further, if writes were not complete at the end of the block, the 
construct would be essentially useless for its intended purpose.


By the way, you're wrong about this too. All @synchronized does is 
act as a mutex around a code block. It does not cause the compiler 
to reorder instructions and issue memory barriers in such a way that 
initialization is guaranteed to precede assignment from the 
perspective of all threads.


Please cite a source for this assertion.

From:

<https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html>

"If you are already using a mutex to protect a section of code, do 
not automatically assume you need to use the volatile keyword to 
protect important variables inside that section. A mutex includes a 
memory barrier to ensure the proper ordering of load and store 
operations."


I acknowledge that, without proper memory barriers, double-checked 
locking is problematic, but am providing an example using a construct 
which I'm fairly sure uses proper memory barriers.


-Steve
___

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

Please do not post 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?

[Steve Sisak]

At 6:14 PM + 1/21/13, Dave wrote:

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?


You could try declaring initWithManager: in a category on the class 
visible only to your implementation code. (i.e. at the top of your .m 
file)


HTH,

-Steve
___

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

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

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

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

Re: Simple memory problem

[Steve Sisak]

At 12:17 AM + 2/6/09, harry greenmonster wrote:
So, how do I keep a copy hanging around AND kill the mysterious new 
copy then (which shares the same name as the old one presumably)?


Retain the copy you want to keep around manually:


while([inputString isMatchedByRegex:regexString])
{
NSAutoreleasePool* pool = [NSAutoreleasePool new];

range = [inputString rangeOfRegex:regexString];

	NSString * newString = [inputString 
stringByReplacingCharactersInRange:range withString:@""];


[inputString release]; // release old inputString

inputString = [newString retain]; // retain new inputString

[pool drain];
}

WARING: this code not tested for correctness but should give you the idea

The autorelease pool may or may not be necessary here, but given the 
size of the input may be good defensive coding.


-Steve
___

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

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

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

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

Re: Simple memory problem

[Steve Sisak]

At 1:32 PM + 2/6/09, harry greenmonster wrote:
But why can the compiler not replace the data at the memory location 
pointed to by the old 'inputString' without making a second pointer 
(with the same name). This would then pose no problems in the 
scenarios you put forward.?


If you use an Objective-C 2.0 property (rather than a variable) and 
specifying retain semantics, you'll get that behavior -- with a bit 
of overhead.


At 12:35 PM + 2/6/09, Jeremy Pereira wrote:

On 6 Feb 2009, at 06:32, Martin Wierschin wrote:
This sequence is not safe. As an optimization there is nothing 
preventing "inputString" from returning self if "range" is of zero 
length. If that ever happened, you could end up deallocating the 
string before the following retain occurs.


So retain newString before releasing inputString - or explicitly 
test for pointer equality and only do the release and retain if they 
are not equal.


Forgetting releasing before retain was a bug -- as a rule you always 
want to retain before release.


This is especially important with operations on arrays and 
dictionaries as elements could be shared between the source and 
result (testing for equality won't help you here).


So there's a complete copy:

while([inputString isMatchedByRegex:regexString])
{
NSAutoreleasePool* pool = [NSAutoreleasePool new];

range = [inputString rangeOfRegex:regexString];

	NSString * newString = [[inputString 
stringByReplacingCharactersInRange:range withString:@""] retain]; // 
retain new inputString


[inputString release]; // release old inputString

inputString = newString;

[pool drain];
}


(the error was probably instructive in this conversation, however)

___

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

Please do not post 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: Read lines from very large text file

[Steve Sisak]

At 1:38 PM +1100 2/3/09, Jacob Rhoden wrote:

On 3/02/2009 8:41 AM, Kenneth Bruno II wrote:
I am wondering what the best way to read a text file, line by 
line, when the file size is much larger than available memory.
For very large files you probably want to use NSFileHandle.  With 
the method readDataOfLength: you can read the file in chunks and 
then parse through for the line endings.


 I also find the non existence of a readLine type mechanism quite 
strange. Either way, this has given me enough to go on so thanks for 
the help!


I can just read in large blocks, read each line within the large 
block, then use the index of the last line ending to fetch the next 
large block.


Umm, unless I'm totally missing something, what's wrong with fopen() 
and fgets(), possibly followed with [NSString stringWithCString] on 
each line?


fgets() returns the EOL character, so you can detect lines that don't 
fit in the buffer. I'll leave handling this case as an exercise.


I'm guessing that Cocoa would assume access to the standard C library 
and doesn't bother duplicating functionality.


At 8:02 PM -0800 2/2/09, Peter Duniho wrote:
For line delimiters, it's almost always going to be \n or \r\n. 
It's simple enough to treat either as a line-break, or to ask the 
user if for some reason \n is a valid character within a line of a 
\r\n-delimited file (but that's very rare).  Certainly, line-breaks 
are a lot easier to deal with in a general, reliable way than 
character encodings.  :)


If you're doing your own line-end detection, I've used the following algorithm:

1) If you see either \r or \n you're at a line end.

2) If the next character is the other, skip it

This handles \r, \n, \r\n, \n\r, plus gracefully handles files with 
mangled line endings with the only possible failure of eating or 
emitting a stray blank line at the point were line endings change in 
the file.


(This thread seems to be off in the weeds)

Cheers,

-Steve


___

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

Please do not post 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: Read lines from very large text file

[Steve Sisak]

At 9:46 AM -0800 2/7/09, Joar Wingfors wrote:

On Feb 7, 2009, at 6:55 AM, Steve Sisak wrote:
Umm, unless I'm totally missing something, what's wrong with 
fopen() and fgets(), possibly followed with [NSString 
stringWithCString] on each line?


What's wrong is that they won't allow you to specify the text 
encoding to use. The same thing is true for the *deprecated* method 
"+stringWithCString:" by the way.


The OP specified he was working with ASCII logfiles before the 
conversation went off into the weeds on text encodings:


At 8:46 PM +1100 2/3/09, Jacob Rhoden wrote:
Exactly, I was looking for direction on the technically best way to 
read a very large file line by line. In future I will be sure to 
include a concrete example. (:


 It is not uncommon that I might have to deal with server logs that 
go into the gigabytes.  Most logs (apache, squid, etc...) are all 
ascii encoded. The line ending is irrelevant, see a \n or a \r and 
we know we have reached the end of a "entry" in the log.


Also, there are other initializers that will let you specify 
encodings, for instance:


- initWithBytes:(const void *)bytes length:(NSUInteger)len 
encoding:(NSStringEncoding)encoding;


you'll just need to do strlen() and check if that last character is 
\n and append another fgets() if it isn't.


I was trying to answer the OP's question (how to read an ASCII file 
line-by-line) in a simple manner, rather than the meta-discussion on 
character encodings.


Better?

-Steve
___

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

Please do not post 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: CGFloat and 64 Bit

[Steve Sisak]

At 12:41 PM -0500 2/9/09, Michael Ash wrote:

 > A very bad idea as it would force usage of float in 64bits applications

 where NSSize expect 64 bits CGFloat.


So? Float converts to double just fine. There are no bad consequences
for passing 11.2f to a function that takes double, aside from an
utterly negligible loss of precision when representing the fractional
part.


It depends if you care about that precision.

Remember that base 10 is not precisely represented in base 2.

Here's a test program for you:

int main (int argc, const char * argv[])
{
double d1 = 11.2;
double d2 = 11.2f;

printf("d1 = %.15f, d2 = %.15f\n", d1, d2);

return 0;
}


Produces:

d1 = 11.199, d2 = 11.19809265137

(On a 1st gen Core Duo MacBook Pro running 10.5.6, YMMV)

The "right thing" would be for the compiler to use the same precision 
as the type being assigned to if no explicit precision was supplied 
but, for whatever reason, that's not what the standard says.


Floating point is tricky to get right.

-Steve
___

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

Please do not post 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: CGFloat and 64 Bit

[Steve Sisak]

At 12:52 PM -0800 2/9/09, Clark Cox wrote:

On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride  wrote:
 > On 2/9/09 11:24 AM, Clark Cox said:
 >>That is, the preprocessor treats any undefined identifier in an '#if'

or '#elif" as if it were defined to be zero.



 > I'm not a language lawyer, but I believe the latter is not guaranteed to

 evaluate to 0 if the macro is not defined.  However, I imagine 99% of
 compilers will evaluate it to 0.  gcc certainly does.


I am 100% positive that this is guaranteed by the standard:


From 6.10.1.3:

"After all replacements due to macro expansion and the defined unary
operator have been performed, all remaining identifiers are replaced
with the pp-number 0"


Just to be pedantic, which standard?

You are definitely describing the behavior of the C++ preprocessor.

IIRC, in ANSI C, #if of an undefined symbol is an error, and I'm not 
sure about C99.


So, I belive #if defined(x) && (x) is good defensive programming.

-Steve

___

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

Please do not post 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: CFRunLoopStop exception

[Steve Sisak]

At 10:03 PM +0200 4/8/10, vincent habchi wrote:
I was running quite an intensive test on creating/freeing threads 
running RunLoops, and I got a rather unexpected crash while 
executing CFRunLoopStop ():


At 10:07 PM +0200 4/8/10, vincent habchi wrote:
Well, I forgot to mention that each thread is responsible for the 
drawing of a CATileLayer, if that matters.


At 7:40 AM +0200 4/9/10, vincent habchi wrote:
Okay, so that means it is impossible to ask a run loop to stop while 
it is being messaged to wake up. Practically, this might not be a 
severe threat, but when you begin to create/destroy threads at small 
intervals (say, 50 ms), the collision seems to be inevitable 
(especially since I also use timers to wake up the loops).


Pulling these out, it may be time to look at WAYRTTD.

Creating/destroying lots of threads to render tiles seems massively 
inefficient for lots of reasons and Mac OS X has much better 
mechanisms for this.


Depending on what minimum OS requirements you might get much better 
results using Grand Central Dispatch or any of a number of 
appropriate approaches like Operation Queues or Dispatch Queues, down 
to managing your own pool of worker threads with a number of threads 
on the order of the number of cores available.


Try starting here:



HTH,

-Steve

___

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

Please do not post 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