^Block statement considered harmful for callbacks?

[Oleg Krupnov]

Blocks in Obj-C seem convenient and powerful but in fact they are very
dangerous because they retain all objects referenced from the block
and thereby can implicitly create circular references.

If you are not vigilant about every object you mention in the block,
you can create one, two or more cycles of circular references causing
your objects to never be freed afterwards.

This breaks encapsulation of objects with block properties (e.g.
MyAnimation.completionBlock) and forces the users of such objects to
always keep in mind what they can, and what the cannot write in the
block body, and still they can shoot themselves in the feet at any
moment by losing vigilance.

It seems to me that it's much better to drop the convenience of blocks
in favor of safety and full control of retain/assign relationships
between my objects.

This is a shocker for me too, but I do not see a good solution to this
problem. The solution suggested in Session 712 WWDC 2012 is ugly -
call some kind of "cancel" method for every block when it's no longer
needed. Even with ARC, declaring a weak ref to self and then strong
ref to weak ref inside the block is ugly too - you have to add this
crap to each and every block you write.

Thoughts?
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Tom Davie]

On 25 Apr 2013, at 09:20, Oleg Krupnov  wrote:

> Blocks in Obj-C seem convenient and powerful but in fact they are very
> dangerous because they retain all objects referenced from the block
> and thereby can implicitly create circular references.
> 
> If you are not vigilant about every object you mention in the block,
> you can create one, two or more cycles of circular references causing
> your objects to never be freed afterwards.
> 
> This breaks encapsulation of objects with block properties (e.g.
> MyAnimation.completionBlock) and forces the users of such objects to
> always keep in mind what they can, and what the cannot write in the
> block body, and still they can shoot themselves in the feet at any
> moment by losing vigilance.
> 
> It seems to me that it's much better to drop the convenience of blocks
> in favor of safety and full control of retain/assign relationships
> between my objects.
> 
> This is a shocker for me too, but I do not see a good solution to this
> problem. The solution suggested in Session 712 WWDC 2012 is ugly -
> call some kind of "cancel" method for every block when it's no longer
> needed. Even with ARC, declaring a weak ref to self and then strong
> ref to weak ref inside the block is ugly too - you have to add this
> crap to each and every block you write.

Your argument can equally well be applied to any object that keeps strong 
references to other objects.  It's not blocks that are doing any of the above, 
it's reference counting.  And we know that the issues are there – we just 
choose to have them because the issues with the less leaky solutions are even 
more severe (especially in C like languages).

Thanks

Tom Davie
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Oleg Krupnov]

Tom, I disagree, because unlike other objects with strong refs, or say
@property(retain), the strong refs in blocks are created implicitly
and it's just too easy to let them slip out of attention. There is no
direct command to create the strong ref, unlike @property(retain). All
you do is *mention* self or even an ivar, and voila, you're done.

I wish there was a safe and elegant solution to this, like we did with
proxy for NSTimer.



On Thu, Apr 25, 2013 at 11:28 AM, Tom Davie  wrote:
>
> On 25 Apr 2013, at 09:20, Oleg Krupnov  wrote:
>
>> Blocks in Obj-C seem convenient and powerful but in fact they are very
>> dangerous because they retain all objects referenced from the block
>> and thereby can implicitly create circular references.
>>
>> If you are not vigilant about every object you mention in the block,
>> you can create one, two or more cycles of circular references causing
>> your objects to never be freed afterwards.
>>
>> This breaks encapsulation of objects with block properties (e.g.
>> MyAnimation.completionBlock) and forces the users of such objects to
>> always keep in mind what they can, and what the cannot write in the
>> block body, and still they can shoot themselves in the feet at any
>> moment by losing vigilance.
>>
>> It seems to me that it's much better to drop the convenience of blocks
>> in favor of safety and full control of retain/assign relationships
>> between my objects.
>>
>> This is a shocker for me too, but I do not see a good solution to this
>> problem. The solution suggested in Session 712 WWDC 2012 is ugly -
>> call some kind of "cancel" method for every block when it's no longer
>> needed. Even with ARC, declaring a weak ref to self and then strong
>> ref to weak ref inside the block is ugly too - you have to add this
>> crap to each and every block you write.
>
> Your argument can equally well be applied to any object that keeps strong 
> references to other objects.  It's not blocks that are doing any of the 
> above, it's reference counting.  And we know that the issues are there – we 
> just choose to have them because the issues with the less leaky solutions are 
> even more severe (especially in C like languages).
>
> Thanks
>
> Tom Davie

___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Tom Davie]

On 25 Apr 2013, at 09:34, Oleg Krupnov  wrote:

> Tom, I disagree, because unlike other objects with strong refs, or say
> @property(retain), the strong refs in blocks are created implicitly
> and it's just too easy to let them slip out of attention. There is no
> direct command to create the strong ref, unlike @property(retain). All
> you do is *mention* self or even an ivar, and voila, you're done.
> 
> I wish there was a safe and elegant solution to this, like we did with
> proxy for NSTimer.

I'm not really convinced that the fact that these objects are easier to 
dynamically create makes the problem that retain counting inherently can't deal 
with retain cycles any worse.

That said, I wonder if the correct solution to what some are clearly finding an 
issue here is to look to the compiler.  At least superficially, I could see it 
being possible to detect a lot of cycles with a static analyser.  Obviously you 
couldn't detect all of them, but this would probably get a good way to stomping 
on the "you used an ivar here, and self retains the block, that's bad m'kay" 
bugs.

Thanks

Tom Davie
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Diederik Meijer | Ten Horses]

I don't agree, blocks are very powerful.

I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings 
when a block reference to a property caused a retain cycle. This is how I found 
it and why I mentioned it in another thread in the first place.

I haven't tested it extensively, but it looks as if the compiler recognises 
these situations easily and then tells you about it.

So I wouldn't call blocks dangerous at all…

 


Op Apr 25, 2013, om 10:21 AM heeft Tom Davie  het volgende 
geschreven:

> 
> On 25 Apr 2013, at 09:34, Oleg Krupnov  wrote:
> 
>> Tom, I disagree, because unlike other objects with strong refs, or say
>> @property(retain), the strong refs in blocks are created implicitly
>> and it's just too easy to let them slip out of attention. There is no
>> direct command to create the strong ref, unlike @property(retain). All
>> you do is *mention* self or even an ivar, and voila, you're done.
>> 
>> I wish there was a safe and elegant solution to this, like we did with
>> proxy for NSTimer.
> 
> I'm not really convinced that the fact that these objects are easier to 
> dynamically create makes the problem that retain counting inherently can't 
> deal with retain cycles any worse.
> 
> That said, I wonder if the correct solution to what some are clearly finding 
> an issue here is to look to the compiler.  At least superficially, I could 
> see it being possible to detect a lot of cycles with a static analyser.  
> Obviously you couldn't detect all of them, but this would probably get a good 
> way to stomping on the "you used an ivar here, and self retains the block, 
> that's bad m'kay" bugs.
> 
> Thanks
> 
> Tom Davie
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/diederik%40tenhorses.com
> 
> This email sent to diede...@tenhorses.com
> 


___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Tom Davie]

On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses  
wrote:

> I don't agree, blocks are very powerful.
> 
> I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings 
> when a block reference to a property caused a retain cycle. This is how I 
> found it and why I mentioned it in another thread in the first place.
> 
> I haven't tested it extensively, but it looks as if the compiler recognises 
> these situations easily and then tells you about it.
> 
> So I wouldn't call blocks dangerous at all…

You're right – the compiler *is* detecting some simple cases, as I suggested!  
Note – this does not make throwing blocks around without paying attention to 
retain cycles inherently safe though, the compiler can not statically infer all 
potential cycles.

Thanks

Tom Davie
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Oleg Krupnov]

The compiler indeed warns, but only for ARC projects, and for non-ARC
projects it perfectly allows blocks to create retain cycles without
any warnings, even Xcode's Analyze doesn't help.

Besides, I'm afraid the compiler is not always capable to detect all
such dangerous situations even with ARC on.

So I am afraid it ends up with lots of retain cycles in virtually
every project that uses blocks, but programmers just don't notice
and/or just don't care. Do you often check your projects for leaks of
this kind? You will be surprised if you do try.

My point remains: blocks are dangerous and there is no easy way to
ensure they are safe. You can't avoid referencing "self" in blocks,
because it is the very point of almost every callback block. So you
have to every time to remind yourself to jump through hoops to avoid
the retain cycles. Nah.



On Thu, Apr 25, 2013 at 1:45 PM, Tom Davie  wrote:
>
> On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses 
>  wrote:
>
>> I don't agree, blocks are very powerful.
>>
>> I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings 
>> when a block reference to a property caused a retain cycle. This is how I 
>> found it and why I mentioned it in another thread in the first place.
>>
>> I haven't tested it extensively, but it looks as if the compiler recognises 
>> these situations easily and then tells you about it.
>>
>> So I wouldn't call blocks dangerous at all…
>
> You're right – the compiler *is* detecting some simple cases, as I suggested! 
>  Note – this does not make throwing blocks around without paying attention to 
> retain cycles inherently safe though, the compiler can not statically infer 
> all potential cycles.
>
> Thanks
>
> Tom Davie

___

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

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

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

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

sandboxd deny hid-control weirdness

[Pax]

I am writing a program that I hope to get into the App Store.  During testing, 
all went well - no errors, no crashes, nothing to be concerned about.  Having 
Archived it, and exported a Developer ID-signed Application (for further 
testing), I find myself facing a rather annoying problem.  My program still 
works correctly (no crashes or problems of that nature), but the console is 
showing the following error on a regular basis:

25/04/2013 13:02:06.100 sandboxd[701]: ([458]) DeviceInfo(458) deny hid-control

How can I track down what is causing this 'deny hid-control' error?  The full 
report leaves me none the wiser:

DeviceInfo(458) deny hid-control

Process: DeviceInfo [458]
Path:/Applications/DeviceInfo.app/Contents/MacOS/DeviceInfo
Load Address:0x1
Identifier:  com.paxsoftware.DeviceInfo
Version: 1 (1.0)
Code Type:   x86_64 (Native)
Parent Process:  launchd [178]

Date/Time:   2013-04-25 13:02:06.093 +0100
OS Version:  Mac OS X 10.8.3 (12D78)
Report Version:  8

Thread 0:
0   libsystem_kernel.dylib  0x7fff98e9e686 mach_msg_trap + 10
1   CoreGraphics0x7fff954ed259 _CGSPostEventRecord 
+ 201
2   CoreGraphics0x7fff956b1494 
encode_event_record_for_posting + 42
3   CoreGraphics0x7fff9530d645 CGSEncodeEventRecord 
+ 117
4   CoreGraphics0x7fff956b1458 CGSPostEventRecord + 
657
5   Ink 0x7fff96373f01 -[InkClientSideEvent 
repostCGEventToCGConnection:markAsReposted:] + 155
6   Ink 0x7fff96364dc7 -[InkContext 
dispatchQueuedEvent:withDisposition:andRepostType:isFinalDispatch:] + 472
7   Ink 0x7fff96364ad0 -[InkContext 
metaDispatch:triggerEventDisposition:] + 560
8   Ink 0x7fff963645eb -[InkContext 
inspectEvent:] + 929
9   Ink 0x7fff96363145 
_InkInspectCarbonEvent + 202
10  HIToolbox   0x7fff96d0431e InkPreflight + 413
11  HIToolbox   0x7fff96cfbc8c 
AcquireEventFromQueue + 270
12  HIToolbox   0x7fff96cf1c77 
ReceiveNextEventCommon + 393
13  HIToolbox   0x7fff96cf1ae3 
BlockUntilNextEventMatchingListInMode + 62
14  AppKit  0x7fff8da9e563 _DPSNextEvent + 685
15  AppKit  0x7fff8da9de22 -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
16  AppKit  0x7fff8da951d3 -[NSApplication run] 
+ 517
17  AppKit  0x7fff8da39c06 NSApplicationMain + 
869
18  DeviceInfo  0x00011db4 start + 52

Thread 1:
0   libsystem_kernel.dylib  0x7fff98ea0d16 kevent + 10
1   libdispatch.dylib   0x7fff9730e9ee _dispatch_mgr_thread 
+ 54

Thread 2:
0   libsystem_kernel.dylib  0x7fff98e9e686 mach_msg_trap + 10
1   CoreFoundation  0x7fff91697233 
__CFRunLoopServiceMachPort + 195
2   CoreFoundation  0x7fff9169c916 __CFRunLoopRun + 1078
3   CoreFoundation  0x7fff9169c0e2 CFRunLoopRunSpecific 
+ 290
4   CoreFoundation  0x7fff916aadd1 CFRunLoopRun + 97
5   Foundation  0x7fff8fc4ccd2 __NSThread__main__ + 
1345
6   libsystem_c.dylib   0x7fff8d24c7a2 _pthread_start + 327
7   libsystem_c.dylib   0x7fff8d2391e1 thread_start + 13

Thread 3:
0   libsystem_kernel.dylib  0x7fff98ea06d6 __workq_kernreturn + 
10
1   libsystem_c.dylib   0x7fff8d24ed13 _pthread_wqthread + 
412
2   libsystem_c.dylib   0x7fff8d2391d1 start_wqthread + 13

Thread 4:
0   libsystem_kernel.dylib  0x7fff98ea06d6 __workq_kernreturn + 
10
1   libsystem_c.dylib   0x7fff8d24ed13 _pthread_wqthread + 
412
2   libsystem_c.dylib   0x7fff8d2391d1 start_wqthread + 13

Binary Images:
   0x1 -0x1cff7  com.paxsoftware.DeviceInfo (1.0 - 1) 
<543C3BAA-C385-3E8F-8F7B-6D9AA0B421D0> 
/Applications/DeviceInfo.app/Contents/MacOS/DeviceInfo
0x7fff8d238000 - 0x7fff8d304ff7  libsystem_c.dylib (825.26) 
<4C9EB006-FE1F-3F8F-8074-DFD94CF2CE7B> /usr/lib/system/libsystem_c.dylib
0x7fff8d949000 - 0x7fff8e576ff7  com.apple.AppKit (6.8 - 1187.37) 
 
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff8fbb7000 - 0x7fff8ff14ff7  com.apple.Foundation (6.8 - 945.16) 
<89BD68FD-72C8-35C1-94C6-3A07F097C50D> 
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff91667000 - 0x7fff91851ff7  com.apple.CoreFoundation (6.8 - 
744.18)  
/System/Library/Frameworks/Co

Re: Simple Vector Based Line Charts

[Marcel Weiher]

> So I was looking for a graphics library in the Developer Docs that serves 
> both Mac-Apps and iOS-Apps.  
> 
> I found references to polylines in a MapKit.
> There is of course Quartz2D and OpenGL.
> 
> So which of these libraries or perhaps there is another I have not heard of 
> yet is best at building simple vector line charts?  

MPWDrawingContext is a wrapper for Quartz.  Doesn't have chart drawing 
functionality, but makes things a little easier and more messaging-oriented.

https://github.com/mpw/MPWDrawingContext
http://blog.metaobject.com/2013/01/more-objective-c-drawing-context.html

Maybe it can help.

Marcel


___

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

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

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

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

Re: Simple Vector Based Line Charts

[dangerwillrobinsondanger]

Have you looked at CorePlot ?

Sent from my iPhone

On 2013/04/25, at 22:50, Marcel Weiher  wrote:

>> So I was looking for a graphics library in the Developer Docs that serves 
>> both Mac-Apps and iOS-Apps.  
>> 
>> I found references to polylines in a MapKit.
>> There is of course Quartz2D and OpenGL.
>> 
>> So which of these libraries or perhaps there is another I have not heard of 
>> yet is best at building simple vector line charts?  
> 
> MPWDrawingContext is a wrapper for Quartz.  Doesn't have chart drawing 
> functionality, but makes things a little easier and more messaging-oriented.
> 
>https://github.com/mpw/MPWDrawingContext
>http://blog.metaobject.com/2013/01/more-objective-c-drawing-context.html
> 
> Maybe it can help.
> 
> Marcel
> 
> 
> ___
> 
> 

___

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

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

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

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

Re: Simple Vector Based Line Charts

[James Montgomerie]

If you have quite simple requirements, a CAShapeLayer might work.  

You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can 
help with creating the CGPath if you don't want to drop to the CGPath API (no 
such luck on Mac - NSBezierPath can't be trivially converted to a CGPath 
AFAIK).  The C-based CGPath API is not bad though.

Jamie.

On 10 Apr 2013, at 06:31, YT  wrote:

> 
> So I was looking for a graphics library in the Developer Docs that serves 
> both Mac-Apps and iOS-Apps.  
> 
> I found references to polylines in a MapKit.
> There is of course Quartz2D and OpenGL.
> 
> So which of these libraries or perhaps there is another I have not heard of 
> yet is best at building simple vector line charts?  
> 
> YT
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
> 
> This email sent to ja...@montgomerie.net


___

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

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

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

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

SMLoginItemSetEnabled ACL Problem

[Pax]

Forgive me for having two questions in flight at once.  This is an entirely 
separate issue - and this might not even be the right forum for it.  I can't 
find a sandbox / app store forum to ask though.

My app should be able to launch itself at start up - but the helper app doesn't 
seem to work.  In fact, it doesn't even launch!  All I get is this error:

25/04/2013 12:53:33.376 xpcd[226]: (null): Code identity[pid: 
273::com.PaxSoftware.DeviceInfoLoginHelperApp 
(/Applications/DeviceInfo.app/Contents/Library/LoginItems/DeviceInfoLoginHelperApp.app)]
 is not in ACL for container: 
~/Library/Containers/com.PaxSoftware.DeviceInfoLoginHelperApp/Data -- allowing 
access.

I haven't attached any source code because it's not getting as far as executing 
anything.  If anyone can suggest what I might look at (probably a plist, I'd 
have thought - so I've included those settings), I'd be most grateful.
Plist:

Bundle identifier = com.PaxSoftware.${PRODUCT_NAME:rfc1034identifier}
Application is background only = true

The login helper App is included in the main app, and the code in the main app 
seems to function correctly:

- (IBAction)autoLaunchChange:(id)sender
{

   
// Creating helper app complete URL

NSURL *url = [[NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]] 
URLByAppendingPathComponent:
 
@"Contents/Library/LoginItems/DeviceInfoLoginHelperApp.app"];


// Registering helper app

if (LSRegisterURL((__bridge CFURLRef)url, true) != noErr)
{

NSLog(@"LSRegisterURL failed!");

}

   
if (!SMLoginItemSetEnabled 
((CFStringRef)@"com.PaxSoftware.DeviceInfoLoginHelperApp", ([autoLaunch 
state]==NSOnState)))
{
[
autoLaunch setState:NSOffState];
NSAlert *alert = [NSAlert alertWithMessageText:@"An error occurred"
 defaultButton:@"OK"
   alternateButton:nil
   otherButton:nil

informativeTextWithFormat:@"Couldn't set DeviceInfo Launch State."];
[alert runModal];
}

}

___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Steven Degutis]

Using blocks with ARC just requires more discipline, that's all. It isn't
to be avoided, just carefully thought about at the appropriate times.


On Thu, Apr 25, 2013 at 6:07 AM, Oleg Krupnov wrote:

> The compiler indeed warns, but only for ARC projects, and for non-ARC
> projects it perfectly allows blocks to create retain cycles without
> any warnings, even Xcode's Analyze doesn't help.
>
> Besides, I'm afraid the compiler is not always capable to detect all
> such dangerous situations even with ARC on.
>
> So I am afraid it ends up with lots of retain cycles in virtually
> every project that uses blocks, but programmers just don't notice
> and/or just don't care. Do you often check your projects for leaks of
> this kind? You will be surprised if you do try.
>
> My point remains: blocks are dangerous and there is no easy way to
> ensure they are safe. You can't avoid referencing "self" in blocks,
> because it is the very point of almost every callback block. So you
> have to every time to remind yourself to jump through hoops to avoid
> the retain cycles. Nah.
>
>
>
> On Thu, Apr 25, 2013 at 1:45 PM, Tom Davie  wrote:
> >
> > On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses <
> diede...@tenhorses.com> wrote:
> >
> >> I don't agree, blocks are very powerful.
> >>
> >> I am using Xcode 4.6 and in a project that uses ARC it was throwing
> warnings when a block reference to a property caused a retain cycle. This
> is how I found it and why I mentioned it in another thread in the first
> place.
> >>
> >> I haven't tested it extensively, but it looks as if the compiler
> recognises these situations easily and then tells you about it.
> >>
> >> So I wouldn't call blocks dangerous at all…
> >
> > You're right – the compiler *is* detecting some simple cases, as I
> suggested!  Note – this does not make throwing blocks around without paying
> attention to retain cycles inherently safe though, the compiler can not
> statically infer all potential cycles.
> >
> > Thanks
> >
> > Tom Davie
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/sbdegutis%40gmail.com
>
> This email sent to sbdegu...@gmail.com
>
___

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

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

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

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

Re: Temporarily disabling autosave

[Jerry Krinock]

On 2013 Apr 24, at 11:38, Steve Mills  wrote:

> Like the way TextEdit does it; you see the change take place, but then it 
> instantly blinks back to the way it was before. It's *very* un-Mac-like and 
> feels extremely half-baked.


On the contrary, I would suspect that it has been fully baked through many long 
heated meetings and memos at Apple, selected as the least worst fix for this 
corner case in which the the Auto Save clashes with an old tradition, in this 
case WYSIWYG.  I thought that NSBeep() was better for my app.

Here is an excerpt from a newsletter I just received from Smile Software…

"PDFpen 6.0.2 is now available from Smile.  This update includes an option to 
turn off autosave and versions."

H.  Two bug fixes after Autosave and Versions was adopted with great 
fanfare in 6.0.0.

Indeed, there are some users, some documents, and maybe even some apps for 
which ("Lion") Auto Save and Versions is not appropriate.  Anyhow, I'm glad 
that you and your marketeers appear to have have thought this through and know 
what you're doing.




___

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

Please do not post 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: Temporarily disabling autosave

[Steve Mills]

On Apr 25, 2013, at 11:01:08, Jerry Krinock 
 wrote:

> "PDFpen 6.0.2 is now available from Smile.  This update includes an option to 
> turn off autosave and versions."

Good. More apps need to offer that ability.

> H.  Two bug fixes after Autosave and Versions was adopted with great 
> fanfare in 6.0.0.
> 
> Indeed, there are some users, some documents, and maybe even some apps for 
> which ("Lion") Auto Save and Versions is not appropriate.  Anyhow, I'm glad 
> that you and your marketeers appear to have have thought this through and 
> know what you're doing.

Saving in place is not something most users expect, because it hasn't been done 
that way on all the common platforms. I can't begin to count the number of 
times I've opened documents, edited them in some way, not intending to save 
those changes. Maybe I just needed to, say, find an image in a particular layer 
of some image editing app, so I hid some layers. That sort of thing. But doing 
something as simple as quitting means those changes will automatically change 
my actual document file without even asking if I want to discard them. That's 
just dangerous. What if some other app is using that file? The autosaved 
changes *to the actual file* will affect that other app. It's just a horrible 
idea. Autosave as loss prevention in the event of a crash? Good idea. Autosave 
to dumb down the user experience? Bad idea.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Jens Alfke]

On Apr 25, 2013, at 1:20 AM, Oleg Krupnov  wrote:

> This breaks encapsulation of objects with block properties (e.g.
> MyAnimation.completionBlock)

I understand the problem you're describing (and yes, I've had a couple of 
memory leaks resulting from it) but I don't understand how you think it's 
breaking encapsulation.

> It seems to me that it's much better to drop the convenience of blocks
> in favor of safety and full control of retain/assign relationships
> between my objects.

It's a subjective decision, but for what it's worth, I disagree. Blocks are so 
useful that it's not worth giving them up. In any case, you're talking about 
only one use of blocks — as a way to tell an object an action to perform later, 
a replacement for delegates or target/action pairs. There are plenty of other 
good uses for blocks that don't have these issues.

In my code, most of the places I use a block as an onXXX property value it's 
going to be called exactly once. What I do then is, in the caller, set the 
corresponding _onXXX ivar to nil after calling through it, to break cycles.

- (void) xxxHappened {
if (_onXXX) {
_onXXX();
_onXXX = nil;
}
}

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

Please do not post 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: Find functions disabled while NSSearchField is first responder.

[Antonio Nunes]

On 24 Apr, 2013, at 21:46 , Antonio Nunes  wrote:

> I have an NSSearchField, and a menu bar submenu with the standard Find items. 
> When the search field receives some input, it performs its action and an 
> array controller is filled with search results. Now, while the search field 
> is the first responder, none of the Find items are enabled, so it is 
> impossible to issue, say a Find Next command. The Find functions perform fine 
> when just about any other item in the document window is first responder. I 
> find that surprising, but, more importantly, I cannot find a way to get the 
> Find functions to work, while the search command has focus. What am I missing?

I added a search field to a small test project, to see if it works correctly in 
a less complicated setup, but to no avail. The Find menu items are still 
disabled. Some more googling (previous queries did not yield any relevant 
info), showed me that this issue has bitten others before, but no solutions 
appear to have been put forward.

I've checked the responder chain, and tried to catch calls to validateMenuItem 
and validateUserInterfaceItem:, to see if I can find out the point at which 
these items are disabled. But the break points don't even trigger. When I check 
the window for its first responder, when the search field is receiving input, 
it returns the document window, not the search field. The document window 
though, has its own implementation of validateMenuItem:, but that is never 
called.

How can I find out where the validation for performFindPanelAction: fails?

-António
___

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

Please do not post 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: sandboxd deny hid-control weirdness

[Nick Zitzmann]

On Apr 25, 2013, at 7:10 AM, Pax <45rpmli...@googlemail.com> wrote:

> I am writing a program that I hope to get into the App Store.  During 
> testing, all went well - no errors, no crashes, nothing to be concerned 
> about.  Having Archived it, and exported a Developer ID-signed Application 
> (for further testing), I find myself facing a rather annoying problem.  My 
> program still works correctly (no crashes or problems of that nature), but 
> the console is showing the following error on a regular basis:
> 
> 25/04/2013 13:02:06.100 sandboxd[701]: ([458]) DeviceInfo(458) deny 
> hid-control
> 
> How can I track down what is causing this 'deny hid-control' error?  The full 
> report leaves me none the wiser:
[…]
> 8   Ink   0x7fff963645eb -[InkContext 
> inspectEvent:] + 929

You've turned on Ink, and Ink is attempting to send HID events, which the 
sandbox is striking down. This is normal, and there is no workaround because 
Apple refuses to allow sandboxed apps to send HID events. In the past, using 
Ink also blocked sandboxed apps from receiving mouse-up events, though I think 
that bug has been fixed by now.

Nick Zitzmann



___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Lee Ann Rucker]

> My point remains: blocks are dangerous and there is no easy way to
> ensure they are safe. You can't avoid referencing "self" in blocks,
> because it is the very point of almost every callback block. So you
> have to every time to remind yourself to jump through hoops to avoid
> the retain cycles. Nah.


Yes you can. 

MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];

^() = {
  Foo *wself = [weakRef originalObject];
  // wself may be nil, that's cool because we only want to doStuff if 'self' is 
still around.
  [wself doStuff];
}
___

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

Please do not post 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: Temporarily disabling autosave

[Quincey Morris]

On Apr 25, 2013, at 09:10 , Steve Mills  wrote:

> Saving in place is not something most users expect, because it hasn't been 
> done that way on all the common platforms.

Uh, you can't make statements like that without citing evidence. Have you 
surveyed most users on this point? There are plenty of users to whom the idea 
of saving is itself unexpected -- because the [pre-Lion] need to save changes 
implied that your computer was otherwise going to discard your changes, and why 
would it do that For people with this mindset, needing to save explicitly 
is like some kind of punishment.

> I can't begin to count the number of times I've opened documents, edited them 
> in some way, not intending to save those changes. Maybe I just needed to, 
> say, find an image in a particular layer of some image editing app, so I hid 
> some layers. That sort of thing. But doing something as simple as quitting 
> means those changes will automatically change my actual document file without 
> even asking if I want to discard them. That's just dangerous.

You have this exactly backwards. Autosaving-in-place never changes the *saved* 
document file. It writes the autosaved document elsewhere. When you quit with 
an open, dirty document, there are two copies until you relaunch. At that 
point, your document is *still* dirty, and you can *still* close the document 
window explicitly, and you get a dialog asking if you want to save or discard 
changes (back to the point of the original save, which was before you quit and 
relaunched).

Autosave-in-place was explicitly designed to avoid the problem you're 
complaining about!

Remember, way back in this discussion, I said that the post-Lion saving 
behavior made sense only in its own terms, not in terms of the pre-Lion 
behavior. It sounds like your approach to this is stuck in pre-Lion terms, and 
so of course the new behavior seems wrong to you.

___

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

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

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

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

Re: Temporarily disabling autosave

[Kevin Perry]

On Apr 25, 2013, at 10:05 AM, Quincey Morris 
 wrote:

>> I can't begin to count the number of times I've opened documents, edited 
>> them in some way, not intending to save those changes. Maybe I just needed 
>> to, say, find an image in a particular layer of some image editing app, so I 
>> hid some layers. That sort of thing. But doing something as simple as 
>> quitting means those changes will automatically change my actual document 
>> file without even asking if I want to discard them. That's just dangerous.
> 
> You have this exactly backwards. Autosaving-in-place never changes the 
> *saved* document file. It writes the autosaved document elsewhere. When you 
> quit with an open, dirty document, there are two copies until you relaunch. 
> At that point, your document is *still* dirty, and you can *still* close the 
> document window explicitly, and you get a dialog asking if you want to save 
> or discard changes (back to the point of the original save, which was before 
> you quit and relaunched).

Actually no—autosaving-in-place means exactly that changes are always saved to 
the main document file, hence "in place". There is only ever a single file per 
document, even when quitting.

However, in Mountain Lion, we added preferences that allow you to (1) force 
documents to close on Quit, and (2) ask if the user wants to keep changes that 
they haven't explicitly saved (Cmd-S). In the above scenario, when these 
preferences are enabled, you will be given the option to discard all the 
experimental / temporary changes (made possible by Versions).

-KP


___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Torsten Curdt]

> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
>
> ^() = {
>   Foo *wself = [weakRef originalObject];
>   // wself may be nil, that's cool because we only want to doStuff if 'self' 
> is still around.
>   [wself doStuff];
> }

How is that different from

  __typeof__(self) __weak wself = self;
  ^() = {
[wself doStuff];
  }

...or am I missing something from the beginning of the thread?

cheers,
Torsten
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Jens Alfke]

On Apr 25, 2013, at 9:54 AM, Lee Ann Rucker  wrote:

> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
> 
> ^() = {
>  Foo *wself = [weakRef originalObject];
>  // wself may be nil, that's cool because we only want to doStuff if 'self' 
> is still around.
>  [wself doStuff];
> }

It's easier to just use the __weak attribute, if you're using ARC:

__weak Foo *weakRef = self;
^() = {
Foo *wself = weakRef;
// wself may be nil, that's cool because we only want to doStuff if 
'self' is still around.
[wself doStuff];
}

Still, I think this is what Oleg called "jumping through hoops". You and I just 
don't think it's a very significant hoop :)

—Jens
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Lee Ann Rucker]

Figured there must be something like that :) We have complicated reasons for 
doing it with classes (C++ is involved) and since I'm at home hitting reload on 
the WWDC ticket site I don't have the docs available. 

- Original Message -
From: "Torsten Curdt" 
To: "Lee Ann Rucker" 
Cc: "Oleg Krupnov" , "Cocoa-Dev List" 

Sent: Thursday, April 25, 2013 10:27:14 AM
Subject: Re: ^Block statement considered harmful for callbacks?

> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
>
> ^() = {
>   Foo *wself = [weakRef originalObject];
>   // wself may be nil, that's cool because we only want to doStuff if 'self' 
> is still around.
>   [wself doStuff];
> }

How is that different from

  __typeof__(self) __weak wself = self;
  ^() = {
[wself doStuff];
  }

...or am I missing something from the beginning of the thread?

cheers,
Torsten
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Lee Ann Rucker]

> It's easier to just use the __weak attribute, if you're using ARC: 

Ah, so that's when you get to use it. Well, a couple hundred files written over 
the course of 7 years isn't going to be ARC any time soon, nice as it might be. 
___

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

Please do not post 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: Temporarily disabling autosave

[Quincey Morris]

On Apr 25, 2013, at 10:21 , Kevin Perry  wrote:

> Actually no—autosaving-in-place means exactly that changes are always saved 
> to the main document file, hence "in place". There is only ever a single file 
> per document, even when quitting.

Oops, I obviously got too focused on the "autosave elsewhere" part of this.

However, I think the essence of my point was correct. Without activating the 
options added in Mountain Lion, if you quit with a dirty document and relaunch, 
it comes back as a dirty document. You've neither lost nor gained anything by 
quitting. In fact, IIUC, even if you don't quit, a timed autosave will also 
save the document in place, right?

You can still discard your changes, if you wish, which seems to be one of the 
worries Steve had. Steve also seems worried that autosaved changes are visible 
to other apps using the same document, but that's a design choice of the 
post-Lion document architecture, with the whole coordinator/presenter mechanism 
to support it.

Steve might validly be worried about the privacy implications of this behavior, 
but it seems over-alarmist to call it dangerous or dumbed-down.

___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Tom Davie]

On 25 Apr 2013, at 18:35, Lee Ann Rucker  wrote:

>> It's easier to just use the __weak attribute, if you're using ARC: 
> 
> Ah, so that's when you get to use it. Well, a couple hundred files written 
> over the course of 7 years isn't going to be ARC any time soon, nice as it 
> might be. 

Luckily, if you grab Landon Fuller's PLWeakCompatibility (and possibly Mike 
Ash's MAZeroingWeakRef too), you'll be able to use __weak in your non-arc code 
too.

Thanks

Tom Davie
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Oleg Krupnov]

Yes, this is jumping through hoops, and even then you are not entirely safe. 
How about referencing ivars from blocks? How about referencing other objects 
that may in their turn reference self etc.? You have to keep it all in mind and 
constantly fight with the side-effects by adding more crappy hoops to your 
code. And it is a problem that does not even exist with delegates. 

On Apr 25, 2013, at 8:29 PM, Jens Alfke  wrote:

> 
> On Apr 25, 2013, at 9:54 AM, Lee Ann Rucker  wrote:
> 
>> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
>> 
>> ^() = {
>>  Foo *wself = [weakRef originalObject];
>>  // wself may be nil, that's cool because we only want to doStuff if 'self' 
>> is still around.
>>  [wself doStuff];
>> }
> 
> It's easier to just use the __weak attribute, if you're using ARC:
> 
> __weak Foo *weakRef = self;
> ^() = {
>   Foo *wself = weakRef;
>   // wself may be nil, that's cool because we only want to doStuff if 
> 'self' is still around.
>   [wself doStuff];
> }
> 
> Still, I think this is what Oleg called "jumping through hoops". You and I 
> just don't think it's a very significant hoop :)
> 
> —Jens
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Tom Davie]

On 25 Apr 2013, at 20:48, Oleg Krupnov  wrote:

> 
> 
> Yes, this is jumping through hoops, and even then you are not entirely safe. 
> How about referencing ivars from blocks? How about referencing other objects 
> that may in their turn reference self etc.? You have to keep it all in mind 
> and constantly fight with the side-effects by adding more crappy hoops to 
> your code. And it is a problem that does not even exist with delegates. 

On the other hand, delegates add the problem that they desiccate the code for 
dealing with the results from the code for setting up the request in the first 
place.  I would consider that a much much much higher penalty than having to a 
bit careful about retain cycles.

Thanks

Tom Davie
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Oleg Krupnov]

> I understand the problem you're describing (and yes, I've had a couple of 
> memory leaks resulting from it) but I don't understand how you think it's 
> breaking encapsulation.

The encapsulation is broken by the fact that you can't place whatever code you 
need in the callback block and have to always remember about internal 
implementation of blocks, and its possible implications and side effects, even 
for the simplest cases. It's definitely not something you'd want to focus on, 
given that blocks were called to make life easier, not harder. Implicit 
side-effects are always harder to track and debug. 


> 
> In my code, most of the places I use a block as an onXXX property value it's 
> going to be called exactly once. What I do then is, in the caller, set the 
> corresponding _onXXX ivar to nil after calling through it, to break cycles.
> 

I made it clear in the subject that I was talking about callbacks. There are 
perhaps a number of cases (iterators, threading) where blocks are not copied 
and seem to be perfectly fine. 
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Oleg Krupnov]

> 
> On the other hand, delegates add the problem that they desiccate the code for 
> dealing with the results from the code for setting up the request in the 
> first place.  I would consider that a much much much higher penalty than 
> having to a bit careful about retain cycles.
> 

You are correct, and that was why I switched ruthlessly to blocks instead of 
delegates for callbacks... Until I found this nasty problem with retain cycles, 
which doesn't actually have an elegant solution, and the workarounds leave ugly 
scars in your code and an uneasy feeling of suspicion to every line of your 
code in blocks. 

In fact, blocks only give you an illusion of all code in one place, but just as 
with delegates, it is "dissected" in time, and personally I always find it more 
difficult to read code with blocks, because it takes me an effort to understand 
the context the code will ge running in, across the block scope. Now if you add 
the necessity to think about retain cycles, it's pretty much a nightmare. 

After some time of using blocks, after their novelty worn off, personally I 
don't find them so much more convenient for callbacks as they initially seemed 
(even if there were no retain cycles, which are there, don't forget). It is not 
always relevant to place the callback code in the same place where I set up the 
worker object, and I often find myself calling a single method in the block 
that does the callback down the code, like I would do with delegates. Besides, 
it's quite tricky with blocks if you need to cancel the previous worker and 
replace it with a new one, whereas with delegates you can simply retain the 
current worker and compare it with the callback's sender. 

All in all I come to personally find delegates more elegant and honest than 
blocks for callbacks. Am I alone here? :)
___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Marcel Weiher]

Hi Jens,


On Apr 25, 2013, at 18:10 , Jens Alfke  wrote:
> On Apr 25, 2013, at 1:20 AM, Oleg Krupnov  wrote:
> 
>> This breaks encapsulation of objects with block properties (e.g.
>> MyAnimation.completionBlock)
> 
> I understand the problem you're describing (and yes, I've had a couple of 
> memory leaks resulting from it) but I don't understand how you think it's 
> breaking encapsulation.

Seems pretty obvious to me:   blocks capture variables from their lexical scope 
implicitly and then let them escape this scope.  I explain this (briefly) in my 
HOM paper:  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4687

Sometimes that is exactly what you want, but often not.   Especially for 
multi-threading applications you want to explicitly control what you share, not 
have it implicitly captured.

>> It seems to me that it's much better to drop the convenience of blocks
>> in favor of safety and full control of retain/assign relationships
>> between my objects.
> 
> It's a subjective decision, but for what it's worth, I disagree. Blocks are 
> so useful that it's not worth giving them up. In any case, you're talking 
> about only one use of blocks — as a way to tell an object an action to 
> perform later, a replacement for delegates or target/action pairs.

I'd agree that these are application areas that blocks are not really well 
suited for.  For processing something later, I do think the HOM approach is 
simpler:  [[self afterDelay:0.1] pollSearchResults];

Target-action also seems ill-suited to blocks, and IMHO if Objective-C had had 
blocks at the time, IB would have been much less useful.

> There are plenty of other good uses for blocks that don't have these issues.

Agreed!  For example "around" processing.   No more -lockFocus / unlockFocus, 
gsave/grestore etc.  

> In my code, most of the places I use a block as an onXXX property value it's 
> going to be called exactly once. What I do then is, in the caller, set the 
> corresponding _onXXX ivar to nil after calling through it, to break cycles.
> 
>   - (void) xxxHappened {
>   if (_onXXX) {
>   _onXXX();
>   _onXXX = nil;
>   }
>   }

Interesting.  I can see how it works, not quite seeing how that would be a 
common idiom...but curios!

Cheers,

Marcel




___

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

Please do not post 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: NSScrollView in NSTabView autolayout problem

[Chuck Soper]

I ran into a very similar problem. Recently, I put my view hierarchy into
an NSTabView. When it's in the inactive tab, I get lots of "Unable to
simultaneously satisfy constraints" errors. When the view hierarchy is in
the active tab, there are no errors. I use auto layout in most of my views
accept for the views in document.subviews in NSScrollView.

I don't know if being in the inactive tab is exposing or causing auto
layout problems. I suspect that it will be time consuming to track down.

I'm not recommending this, but one less-than-ideal way to avoid the
problem is to completely deconstruct the view hierarchy before it's in the
inactive tab with code like this:
 [[self subviews] makeObjectsPerformSelector:
@selector(removeFromSuperview)];
Then rebuild the view hierarchy before it's in the active tab.


Chuck


On 4/22/13 5:26 PM, "kwic...@wichry.net"  wrote:

>Hello 
>My problems persist.
>So the NSScrolView as such work perfectly if they are in the active tab
>view.
>However if another tabview is active while window resizing the
>scrollviews on the inactive tabs get crazy and report NSClipVIew
>constraint with width 0.
>Best
>K
>
>On 19 Apr 2013, at 08:37, Krzysztof Wicher wrote:
>
>> Thank you Chuck for pointing me to the answer I will try that. I know
>>that NSScrollView is not build with Autolayout in mind but I hoped using
>>it would save several boring layout managment problems arising in my
>>design.
>> 
>> Also, I did send the message last week but as it was my first to this
>>mailing list, I was not sure how long it take so I did not resend.
>> 
>> Thanks again
>> 
>> K
>> 
>> On 18/04/2013 17:37, Chuck Soper wrote:
>>> This message may be relevant for your issue:
>>> http://prod.lists.apple.com/archives/cocoa-dev/2013/Feb/msg00426.html
>>> 
>>> Personally, I don't use auto layout in NSScrollView. I think that
>>> NSScrollView doesn't support it, but it appears that many people have
>>> gotten it to work.
>>> 
>>> Chuck
>>> P.S. It looks like your message was sent to the list on Saturday, but I
>>> didn't receive it until this morning.
>>> 
>>> 
>>> On 4/13/13 1:57 PM, "kwic...@wichry.net"  wrote:
>>> 
 Hi
 I have an NSTabView with multiple tabs, each containing an
NSScrollView.
 In the scrollviews I dynamically place custom views which are sized
using
 autolayout and constraints.
 
 Now if I add my custom views to a scrollview in tab1 and resize the
 window with this tab active everything works fine and autolayout does
not
 complain.
 
 On the other hand, if I add my custom views to a scrollview in tab1,
 switch to another tab, resize the window, and switch back to tab1
 autolayout breaks with the following exemplar message:
 
 Unable to simultaneously satisfy constraints: (
 ">>> H:|-(0)-[FlippedDocumentView:0x4011b76e0] (Names:
 '|':NSClipView:0x40120eb80 )>", ">>> H:|-(10)-[TextViewModuleView:0x401236e80] (Names:
 '|':FlippedDocumentView:0x4011b76e0 )>",
">>> H:[TextViewModuleView:0x401236e80]-(10)-| (Names:
 '|':FlippedDocumentView:0x4011b76e0 )>",
 ">>> H:[FlippedDocumentView:0x4011b76e0]-(0)-| (Names:
 '|':NSClipView:0x40120eb80 )>",
 ">>> H:[NSClipView:0x40120eb80(0)]>" )
 
 
 What I noticed in the message is this "H:[NSClipView:0x40120eb80(0)]".
 How come the NSClipView so in fact contentView of the scrollview has
 width = 0?
 My question is, why does the autolayout work fine for the active tab
and
 does for inactive?
 
 Thanks
 
 k.
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post 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/chucks%40veladg.com
 
 This email sent to chu...@veladg.com
>>> 
>>> 
>>> 
>>> 
>> 
>
>
>___
>
>Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
>Please do not post admin requests or moderator comments to the list.
>Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
>Help/Unsubscribe/Update your Subscription:
>https://lists.apple.com/mailman/options/cocoa-dev/chucks%40veladg.com
>
>This email sent to chu...@veladg.com


___

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

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

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

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

Re: ^Block statement considered harmful for callbacks?

[Seth Willits]

On Apr 25, 2013, at 1:32 PM, Oleg Krupnov wrote:

> All in all I come to personally find delegates more elegant and honest than 
> blocks for callbacks. Am I alone here? :)

Possibly. :)


> I always find it more difficult to read code with blocks, because it takes me 
> an effort to understand the context the code will ge running in, across the 
> block scope. Now if you add the necessity to think about retain cycles, it's 
> pretty much a nightmare. 

I don't know… I don't have any trouble with it. Perhaps it's with how often 
you're using a particular pattern but I use blocks wherever appropriate and 
rrely run into a retain cycle, and the context/scope thought process seems 
trivial to me.


I've only been skimming through this entire thread, but just to throw it out 
there, perhaps you could post a specific real-world use case where it's more 
trouble than it's worth; I'm thinking maybe you might be able to avoid the 
retain cycles etc by tweaking your interfaces rather than just thinking about 
memory management. I know one (of the only two I can think of) cases where I 
had a retain cycle in a block, I ended up tweaking the interface for an 
unrelated reason and it worked that retain cycle right out as a side effect.

*shrug*

Just a thought.



--
Seth Willits


___

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

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

More constraints confusion

[Rick Mann]

I put an NSImageView into a window. I want the NSImageView's frame to always 
fill the window content frame.

When I dropped it in, IB gave it a width and height constraint that I can't 
edit. I sized it to fit the window, and it also added leading and trailing 
space constraints.

I explicitly set top and bottom constraints.

But the width & height constraints can't be edited. If I promote them to user 
constraints, and then try to delete them, they just come back.

Why does IB think they are necessary?

-- 
Rick




___

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

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

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

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

Re: More constraints confusion

[Rick Mann]

No, pinning is not what I want. That's what I'm trying to avoid. IB in 
insisting on pinning the width and the height.

I think it assumes the NSImageWell MUST have a static size, rather than allow 
it to resize. I'm able to put an NSView without this problem.


On Apr 25, 2013, at 16:48 , Caylan Larson  wrote:

> Rick,
> 
> Search the help menu for "pin" and see if pinning the height or width gets 
> you to where you need to be. 
> 
> Caylan
> 
> On Apr 25, 2013, at 6:39 PM, Rick Mann  wrote:
> 
>> I put an NSImageView into a window. I want the NSImageView's frame to always 
>> fill the window content frame.
>> 
>> When I dropped it in, IB gave it a width and height constraint that I can't 
>> edit. I sized it to fit the window, and it also added leading and trailing 
>> space constraints.
>> 
>> I explicitly set top and bottom constraints.
>> 
>> But the width & height constraints can't be edited. If I promote them to 
>> user constraints, and then try to delete them, they just come back.
>> 
>> Why does IB think they are necessary?
>> 
>> -- 
>> Rick
>> 
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/i%40caylan.net
>> 
>> This email sent to i...@caylan.net


-- 
Rick




___

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

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

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

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

Re: Simple Vector Based Line Charts

[Graham Cox]

On 26/04/2013, at 12:07 AM, James Montgomerie  wrote:

> If you have quite simple requirements, a CAShapeLayer might work.  


I found that CAShapeLayer is not very good when it is scaled up significantly, 
e.g. in a view that gets zoomed by more than 4x or so. It depends on its size - 
because the path is always rendered in screen space, the size of the tile 
needed can quickly exceed the limits of OpenGL.

This is a severe limitation if you plan to use CAShapeLayer for a vector 
composition that you plan to make zoomable.

> 
> You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can 
> help with creating the CGPath if you don't want to drop to the CGPath API (no 
> such luck on Mac - NSBezierPath can't be trivially converted to a CGPath 
> AFAIK).  The C-based CGPath API is not bad though.

Converting a NSBezierPath to a CGPath is easy - just iterate over the elements 
and call the appropriate CGPath methods. Going the other way is harder, as it 
requires that you set up a callback for CGPathApply.

Using the Core Graphics API directly (maybe embedded in classes of your own 
device) is likely to be the most portable and fastest method for rendering 
vector graphics.


--Graham




___

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

Please do not post 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: More constraints confusion

[Chuck Soper]

IB adds constraints to both the NSImageView and its superview. I believe
that this is why deleting a constraint causes it to come back (it's in two
views).

Here's what I recommend:
- Delete the NSImageView which will also delete the associated constraints.
- Drag a new NSImageView to the window (i.e. the main view of the window).
- Resize the NSImageView to fit inside the frame of its containing view.
- Select NSImageView, by double clicking on the NSImageView in the list of
objects. Now, from the Editor menu select "Align -> Horizontal Center in
Container" and "Align -> Vertical Center in Container." (You can also do
that by clicking on the leftmost icon of the constraints control at the
bottom right of the IB view.)

That should do it. Adding those alignment constraints deleted the trailing
and bottom constraints.

Chuck


On 4/25/13 4:39 PM, "Rick Mann"  wrote:

>I put an NSImageView into a window. I want the NSImageView's frame to
>always fill the window content frame.
>
>When I dropped it in, IB gave it a width and height constraint that I
>can't edit. I sized it to fit the window, and it also added leading and
>trailing space constraints.
>
>I explicitly set top and bottom constraints.
>
>But the width & height constraints can't be edited. If I promote them to
>user constraints, and then try to delete them, they just come back.
>
>Why does IB think they are necessary?
>
>-- 
>Rick
>
>
>
>
>___
>
>Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
>Please do not post admin requests or moderator comments to the list.
>Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
>Help/Unsubscribe/Update your Subscription:
>https://lists.apple.com/mailman/options/cocoa-dev/chucks%40veladg.com
>
>This email sent to chu...@veladg.com


___

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

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

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

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

Re: More constraints confusion

[Charles Srstka]

On Apr 25, 2013, at 6:50 PM, Rick Mann  wrote:

> No, pinning is not what I want. That's what I'm trying to avoid. IB in 
> insisting on pinning the width and the height.
> 
> I think it assumes the NSImageWell MUST have a static size, rather than allow 
> it to resize. I'm able to put an NSView without this problem.

Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom Edge To 
Superview", and then the height and width constraints should become deletable.

If it still won't let you delete them even after that, then just give them a 
low enough priority in the Inspector that they cease to matter.

Charles

___

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

Please do not post 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: More constraints confusion

[Rick Mann]

On Apr 25, 2013, at 18:30 , Charles Srstka  wrote:

> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom Edge 
> To Superview", and then the height and width constraints should become 
> deletable.

Sorry, I misunderstood. Yes, I had already pinned the 
Leading/Trailing/Top/Bottom Edges To Superview.

> If it still won't let you delete them even after that, then just give them a 
> low enough priority in the Inspector that they cease to matter.

Like I said, I think this is something about Image Well (NSImageView). In its 
size inspector, it has three pre-defined sizes in a popup. I think IB is trying 
to require that it be of fixed size. I finally just gave up and wrote code to 
stick my image into the CALayer of an NSView, which does not exhibit this 
behavior in IB.


-- 
Rick




___

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

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

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

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

Re: More constraints confusion

[Charles Srstka]

On Apr 25, 2013, at 8:35 PM, Rick Mann  wrote:

> On Apr 25, 2013, at 18:30 , Charles Srstka  wrote:
> 
>> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom Edge 
>> To Superview", and then the height and width constraints should become 
>> deletable.
> 
> Sorry, I misunderstood. Yes, I had already pinned the 
> Leading/Trailing/Top/Bottom Edges To Superview.

Perhaps try it again. IB can be a little wonky sometimes WRT constraints; 
perhaps re-adding the constraints for the four edges to the superview again, 
and see if it makes IB realize that the height/width constraints aren't needed.

>> If it still won't let you delete them even after that, then just give them a 
>> low enough priority in the Inspector that they cease to matter.
> 
> Like I said, I think this is something about Image Well (NSImageView). In its 
> size inspector, it has three pre-defined sizes in a popup. I think IB is 
> trying to require that it be of fixed size. I finally just gave up and wrote 
> code to stick my image into the CALayer of an NSView, which does not exhibit 
> this behavior in IB.

I tried it myself in IB with an NSImageView after reading your original post, 
and was not able to reproduce this behavior, so that's not it.

Charles

___

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

Please do not post 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: More constraints confusion

[Chuck Soper]

On 4/25/13 6:35 PM, "Rick Mann"  wrote:

>On Apr 25, 2013, at 18:30 , Charles Srstka 
>wrote:
>
>> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom
>>Edge To Superview", and then the height and width constraints should
>>become deletable.
>
>Sorry, I misunderstood. Yes, I had already pinned the
>Leading/Trailing/Top/Bottom Edges To Superview.
>
>> If it still won't let you delete them even after that, then just give
>>them a low enough priority in the Inspector that they cease to matter.
>
>Like I said, I think this is something about Image Well (NSImageView). In
>its size inspector, it has three pre-defined sizes in a popup. I think IB
>is trying to require that it be of fixed size. I finally just gave up and
>wrote code to stick my image into the CALayer of an NSView, which does
>not exhibit this behavior in IB.

This would happen if you had the Image Cell selected instead of the Image
Well. If you shift-control click on the IB object that you're trying to
select, you'll get a popup menu. Make sure that you select Image Well not
Image Cell.

Chuck


___

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

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